Distributed feedback control system and logic for battery management system operation

Abstract

A feedback control system for monitoring the hardware of a battery system, a method for manufacturing / operating such a system, and a vehicle having a wireless battery management system (WBMS) controlled by distributed feedback control are provided. A method of operating a WBMS includes a wirelessly enabled manager device selecting a batch of cell module assemblies (CMAs) within the WBMS for communication to thereby retrieve data of their respective battery modules. A manager access control list (ACL) having corresponding media access control (MAC) addresses and ID data is created for the selected CMAs. Based on the corresponding MAC addresses and ID data in the manager ACL, a wireless connection is established between the manager device and the respective cell monitoring units (CMUs) for each selected CMA. The manager device downloads device data of each battery module associated with the selected CMAs from the CMUs of each selected CMA. The manager device then switches the operating mode for each CMU.

Description

[0001] Introduction. Technical Field

[0002] The present disclosure generally relates to battery systems. More specifically, aspects of the present disclosure relate to systems, methods, and apparatus for monitoring traction battery modules and associated hardware of a wireless battery management system. Background Art

[0003] Currently produced motor vehicles (such as modern cars) are equipped with a powertrain that operates to propel the vehicle and provide power for the vehicle's on-board electronic devices. For example, in automotive applications, the vehicle powertrain is typically represented by a prime mover that transfers drive torque to the vehicle's final drive system (e.g., differential, half shafts, road wheels, etc.) through an automatically or manually shifted power transmission. Historically, automobiles have been powered by reciprocating piston internal combustion engine (ICE) components due to their easy availability, relatively low cost, light weight, and overall efficiency. As some non-limiting examples, such engines include compression ignition (CI) diesel engines, spark ignition (SI) gasoline engines, two-stroke, four-stroke, and six-stroke architectures, as well as rotary engines. On the other hand, hybrid electric and all-electric ("electric drive") vehicles utilize alternative power sources to propel the vehicle and thus minimize or eliminate the reliance on traction power from fossil fuel-based engines.

[0004] An all-electric vehicle (FEV) - commonly referred to as an "electric car" - is an electric drive vehicle configuration that completely removes the internal combustion engine and associated peripheral components from the powertrain system and relies solely on a rechargeable energy storage system (RESS) and traction motors for vehicle propulsion. In an FEV, the engine components, fuel supply system, and exhaust system of an ICE-based vehicle are often replaced by one or more traction motors, a traction battery pack, and battery cooling and charging hardware. In contrast, a hybrid electric vehicle (HEV) powertrain uses multiple traction power sources to propel the vehicle, most commonly a traction motor powered by a battery or a fuel cell in combination with an internal combustion engine component. Since a hybrid electric drive vehicle can obtain power from sources other than the engine, the HEV engine can be shut off completely or partially while the vehicle is propelled by an electric motor.

[0005] Most commercial hybrid electric vehicles and all-electric vehicles employ a rechargeable traction battery pack to store and supply power required to operate the traction motor of the powertrain. To generate traction power with sufficient vehicle range and speed, the traction battery pack is significantly larger, more powerful, and higher in capacity (ampere-hours) than a standard 12-volt starting, lighting, and ignition (SLI) battery. Contemporary traction battery packs (also referred to as “electric vehicle batteries” or “EVBs”) group stacks of battery pack cells into individual battery modules that are mounted to the vehicle chassis, e.g., via a battery enclosure and / or support tray. The stacked electrochemical battery cells can be connected in series or parallel by using electrical interconnect boards (ICBs). The electrical tabs of the individual battery cells that protrude from the module enclosure are bent and welded to a shared busbar. A dedicated battery pack control module (BPCM) regulates the opening and closing of battery pack contactors through cooperative operation with the powertrain control module (PCM) to manage the operation of the battery pack in supplying power to the vehicle traction motor.

[0006] To help improve system performance, extend battery life, and increase vehicle range, a battery management system (BMS) monitors and adjusts the real-time operation of the individual modules within the traction battery pack. For some BMS architectures, dedicated microprocessor-based battery monitoring units (CMUs) are integrated into each battery module to collectively define a cell module assembly (CMA). A resident BMS manager device is wired to the CMU devices and systematically collects operation status information for the battery modules (e.g., state of charge (SOC) of the battery cells / modules, temperature, voltage, etc.). The use of a battery management system helps selectively collect battery data for on-vehicle data storage during both active use and dormant periods of the battery pack. A dormant period may occur before the assembled battery module or battery pack is installed into the host system. For example, a battery module can be manufactured in one location and then packaged and shipped—possibly over a long distance—to an assembly plant located in another location. The battery module can be warehoused before shipment or between the point of manufacture and the final point of integration into the host system. A long dormant period can result in an “information black hole” that, if unchecked, can reduce the long-term control accuracy and efficiency of the module. SUMMARY OF THE INVENTION

[0007] The present disclosure provides a distributed feedback control system having an accompanying control logic for monitoring the hardware of a battery system, a method of manufacturing such a system and a method of operating such a system, and an electric drive vehicle having a wireless battery management system (WBMS) governed by distributed feedback control. For example, the disclosed systems and processes allow for remote monitoring of wireless-enabled CMAs, traction battery packs, and other powertrain devices to, for example, derive real-time updates of the health state, operating mode, current and past operating data, etc. of each device. A database for collecting data is developed to provide simplified and accelerated access to WBMS device information. The intelligent feedback control system wirelessly monitors a batch of WBMS devices—whether in storage, shipment, or at an assembly plant—without the need to manually plug each device into a master control device.

[0008] Multiple wireless-enabled electrified powertrain devices can be monitored both pre- and post-production to regulate and track the location, destination, mode, SOH, etc. of each device. The host feedback control system can utilize a manager device having inventory software capable of effecting timer-based and continuous device monitoring, which can be implemented using media access control (MAC) address information extracted from the WBMS database for ACL exchange. In this regard, each CMU can be programmed for independent timer-based wake-up and continuous monitoring when connected to the manager device. New software written to the WBMS chips of each CMU enables data to be stored locally and transmitted to the manager device in different operating modes: a timed wake-up mode having a configurable timer that wakes up the CMU to collect and store device data; a management inventory mode for continuous device monitoring; and a manager wake-up mode in which the manager device wakes up the CMU, requests the stored data, reads from and then deletes the data from the device's resident memory, etc., while the manager device updates the WBMS database.

[0009] Accompanying benefits of at least some of the disclosed concepts include a distributed feedback control system for actively monitoring a distributed network of wireless-enabled devices, e.g., to aggregate device location, destination, SOH, SOC, MAC address, and / or historical data of devices in storage, transit, production, use, or service. This can provide a means to actively detect damaged and faulty devices, including those with thermal propagation issues, to help prevent faulty devices and modules from being put into use. In addition to enhancing customer confidence and reducing warranty claims, the disclosed functionality also helps to expand CMA and battery pack storage capabilities, increase vehicle range, and extend battery expected life.

[0010] The present disclosure provides feedback control methods for manufacturing or using any of the disclosed monitoring systems, battery management systems, and / or electric drive vehicles. In an example, a method for operating a wireless battery management system is provided. The WBMS manages a plurality of battery module assemblies, each of which may be represented by a battery module having a corresponding battery monitoring unit that helps track and manage the operating parameters of the stacked batteries within the module. Such a representative method includes, in any order and in any combination with any of the options and features disclosed above and below: selecting (e.g., via user input, a predetermined inventory management reminder, or a broadcast prompt received by a wireless-enabled manager device) a batch of CMAs, the manager device retrieving device data for their corresponding battery modules from the batch of CMAs; generating (e.g., via a remote host computer) a manager access control list having the corresponding MAC address and ID data (e.g., serial number, brand, model, etc.) for each selected CMA; establishing a wireless connection (e.g., via WiFi, radio frequency (RF), cellular network, near field communication (NFC), BLUETOOTH® etc.) between the manager device and the corresponding CMU of each selected CMA based on the corresponding MAC address and ID data in the manager ACL; downloading (e.g., via the manager device from the CMU of each selected CMA) the device data for each battery module associated with the CMA; and switching (e.g., via a command prompt transmitted by the manager device) the operating mode of each corresponding CMU.

[0011] The present disclosure also provides a distributed feedback control system for governing the operation of the WBMS. By way of example, a host system for monitoring the WBMS is provided. The host system includes a WBMS database for storing device data, a wireless-enabled manager device that exchanges data with the WBMS database, and an optional host computer that is remote from the manager device and wirelessly connected to the manager device. The manager device is programmed to: select a batch of CMAs from a plurality of battery module assemblies (each battery module assembly having a corresponding battery module and a corresponding battery monitoring unit) to communicate with and thereby retrieve data for their corresponding battery modules; invoke a manager access control list that has the corresponding media access control address and identification data for the selected CMAs; wirelessly connect to the CMU of each selected CMA using the corresponding MAC address and identification data in the manager ACL; download the device data for the battery modules associated with the selected CMAs from the CMU of each selected CMA; and command each CMU to switch its operating mode.

[0012] For any disclosed system, method, device, and vehicle, the CMAs can be programmed to transfer their respective MAC addresses and ID data to the WBMS database before creating the manager ACL. In this case, generating the manager ACL includes retrieving the respective MAC addresses and ID data of each selected CMA from the WBMS database. Additionally, generating the manager ACL can also include the remote host computer retrieving the respective MAC addresses and ID data, creating a text file with the retrieved MAC addresses of the selected CMAs, and uploading the text file to the manager device. To evaluate whether the ACL has been successfully updated, the manager ACL can be transferred from the manager device to the host computer; then, the host computer compares the manager ACL with the master ACL to determine whether the MAC addresses in the manager ACL correspond to the list of associated MAC addresses in the master ACL. For cases where the MAC addresses in the manager ACL do not correspond to the MAC addresses in the master ACL, the manager device can accordingly select a new batch of CMAs.

[0013] For any disclosed system, method, device, and vehicle, selecting a batch of CMAs can include receiving user input selections from a MAC address book using a wireless interface library (WIL) installed on or accessible through the manager device (e.g., the WIL can be hosted externally and connected to the manager interface via an established serial protocol). The WIL can accordingly push the newly created ACL or retrieve a predefined available ACL selected for a particular user. This user input selection from the WIL identifies which CMAs communicate with the management device. As yet another alternative, establishing a wireless connection includes the manager device wirelessly transmitting an electronic acoustic pulse to the CMU of each selected CMA. This electronic acoustic pulse can cause the CMU to transition from a sleep mode to a wake mode. In this case, the manager device can determine whether a wireless connection has been successfully established with each CMU; if not, the manager device can send a new electronic acoustic pulse to each CMU with which the wireless connection was not successfully established.

[0014] For any of the disclosed systems, methods, devices, and vehicles, after the manager device downloads the device data, the manager device may send a command prompt to the CMU of each selected CMA to clear the device data from the CMU's resident memory device. Another option may include the manager device transferring the downloaded device data of the battery modules of the selected CMA to the WBMS database. The device data may include battery voltage data, battery temperature data, state of charge data, and / or battery health state data. The manager device may also download the corresponding location, destination, mode, and / or historical data for each selected CMA; this information may be extracted by the host computer into the CMA database log. As yet another additional option, switching the CMU operation mode may include transmitting a command prompt to the CMU to transition from the wake-up mode prompted by the manager to the continuous wake-up inventory mode.

[0015] The present invention provides the following technical solutions:

[0016] 1. A method of operating a wireless battery management system (WBMS), the WBMS including a plurality of cell module assemblies (CMAs), each cell module assembly having a corresponding battery module and a corresponding cell monitoring unit (CMU), the method comprising:

[0017] Selecting a batch of CMAs to communicate with via a wireless-enabled manager device to thereby retrieve data of their corresponding battery modules;

[0018] Generating a manager access control list (ACL) for the selected batch of CMAs with corresponding media access control (MAC) addresses and identification (ID) data;

[0019] Establishing a wireless connection between the manager device and the corresponding CMUs of the selected CMAs based on the MAC addresses and the ID data in the manager ACL;

[0020] Downloading, via the manager device, device data of each battery module associated with the selected CMAs from the corresponding CMUs of the selected CMAs; and

[0021] Switching the operation mode for each corresponding CMU.

[0022] 2. The method according to technical solution 1, further comprising transmitting the MAC address and the ID data to the WBMS database of the WBMS via the CMA, wherein generating the manager ACL includes retrieving the corresponding MAC address and ID data for each selected CMA from the WBMS database.

[0023] 3. The method according to technical solution 2, wherein generating the manager ACL further includes:

[0024] A remote computing device retrieves the corresponding MAC addresses and ID data, creates a text file with the corresponding MAC addresses of the selected CMAs; and

[0025] uploads the text file from the remote computing device to the manager device.

[0026] 4. The method according to claim 1, wherein selecting the batch of CMAs includes receiving a user input selection via a Wireless Interface Library (WIL) operating on the manager device, the user input selection identifying which of the plurality of CMAs communicates with the manager device.

[0027] 5. The method according to claim 1, further comprising:

[0028] transmitting the generated manager ACL from the manager device to the remote computing device;

[0029] comparing the manager ACL with the primary ACL via the remote computing device to determine whether the MAC addresses in the manager ACL correspond to the associated list of MAC addresses in the primary ACL; and

[0030] in response to the MAC addresses in the manager ACL not corresponding to the associated list of MAC addresses in the primary ACL, selecting a new batch of CMAs via the manager device.

[0031] 6. The method according to claim 1, wherein establishing the wireless connection includes the manager device wirelessly transmitting an electronic acoustic pulse to the corresponding CMU of each CMA in the batch of CMAs.

[0032] 7. The method according to claim 6, wherein the transmitted electronic acoustic pulse causes the CMU to transition from a sleep mode to a wake mode.

[0033] 8. The method according to claim 6, further comprising:

[0034] determining whether the wireless connection with each CMU has been successfully established; and

[0035] transmitting a new electronic acoustic pulse to each CMU for which it is determined that the wireless connection has not been successfully established.

[0036] 9. The method according to claim 1, further comprising, after downloading the device data via the manager device, transmitting a command prompt via the manager device to each CMU in the selected CMAs to clear the device data from the resident memory device of the CMU.

[0037] 10. The method according to claim 1, further comprising transmitting, via the manager device, the device data of the battery modules of the selected CMAs that have been downloaded to the WBMS database of the WBMS.

[0038] 11. The method according to claim 1, wherein switching the operation mode includes transmitting a command prompt to each respective CMU to transition from the wake-up mode prompted by the manager to the continuous wake-up inventory mode.

[0039] 12. The method according to claim 1, further comprising retrieving, via the manager device, the respective location, destination, mode, and / or historical data for each selected CMA.

[0040] 13. The method according to claim 1, wherein the device data includes battery voltage data, battery temperature data, state of charge (SOC) data, and / or state of health (SOH) data of the battery.

[0041] 14. A host system for operating a wireless battery management system (WBMS), the host system comprising:

[0042] A WBMS database; and

[0043] A wireless-enabled manager device communicatively connected to the WBMS database, the manager device being programmed to:

[0044] Select a batch of CMAs from a plurality of battery module assemblies (CMAs), each having a respective battery module and a respective battery monitoring unit (CMU), to communicate with them, thereby retrieving the data of their respective battery modules;

[0045] Invoke a manager access control list (ACL) that has the respective media access control (MAC) addresses and identification (ID) data of the selected CMAs;

[0046] Use the MAC addresses and the ID data in the manager ACL to wirelessly connect to the respective CMU units of the selected CMAs;

[0047] Download the device data of each battery module associated with the selected CMAs from the respective CMUs of the selected CMAs; and

[0048] Command each respective CMU to switch the operation mode.

[0049] 15. The host system according to claim 14, further comprising a main computer device remote from the manager device, the main computer device being configured to:

[0050] Retrieve the corresponding MAC address and ID data of each selected CMA from the WBMS database;

[0051] Create a text file with the corresponding MAC address of the selected CMA; and

[0052] Upload the text file to the manager device.

[0053] 16. The host system according to claim 14, wherein selecting the batch of CMAs includes the manager device receiving a user input selection via a wireless interface library (WIL) operating on the manager device, the user input selection identifying which CMAs are to communicate with the manager device.

[0054] 17. The host system according to claim 14, wherein the manager device is further programmed to:

[0055] Transmit the generated manager ACL to a main computer device remote from the manager device, the main computer device comparing the manager ACL with a main ACL to determine whether the MAC addresses in the manager ACL correspond to a list of associated MAC addresses in the main ACL; and

[0056] In response to the MAC addresses in the manager ACL not corresponding to the list of associated MAC addresses in the main ACL, select a new batch of CMAs.

[0057] 18. The host system according to claim 18, wherein establishing the wireless connection includes the manager device wirelessly transmitting an electroacoustic pulse to the corresponding CMU for each selected CMA, the transmitted electroacoustic pulse causing the CMU to transition from a sleep mode to a wake mode.

[0058] 19. The host system according to claim 18, wherein the manager device is further programmed to:

[0059] Determine whether a wireless connection has been successfully established with each of the CMUs; and

[0060] Send a new electroacoustic pulse to each CMU for which it is determined that a wireless connection has not been successfully established with the CMU.

[0061] 20. The host system according to claim 14, wherein switching the operation mode includes the manager device transmitting a command prompt to each corresponding CMU to transition from the wake mode prompted by the manager to a continuous wake inventory mode.

[0062] The foregoing summary does not represent every embodiment or every aspect of the present disclosure. Instead, when taken in conjunction with the accompanying drawings and the appended claims, the above features and advantages of the present disclosure, as well as other features and attendant advantages, will become apparent from the following detailed description of illustrative examples and modes for carrying out the present disclosure. Additionally, the present disclosure expressly includes any and all combinations and sub - combinations of the elements and features presented above and below. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Figure 1 FIG. 1 is a schematic illustration of a representative electric - drive vehicle having a wireless battery management system in accordance with aspects of the disclosed concepts, the wireless battery management system tracking and managing the operation of battery modules in a traction battery pack of the vehicle.

[0064] Figure 2 FIG. 2 is a schematic illustration of a representative host system for monitoring battery modules via a distributed network of battery monitoring units of a wireless battery management system in accordance with aspects of the present disclosure.

[0065] Figure 3 FIG. 3 is a flow diagram illustrating a representative WBMS inventory monitoring protocol in accordance with aspects of the present disclosure, the protocol being capable of corresponding to memory - stored instructions executed by an on - vehicle or remote controller, control logic circuitry, programmable control unit, or other integrated circuit (IC) device or network of devices.

[0066] Figure 4 FIG. 4 is a flow diagram illustrating a representative WBMS inventory mode protocol in accordance with aspects of the present disclosure, the protocol being capable of corresponding to memory - stored instructions executed by an on - vehicle or remote controller, control logic circuitry, programmable control unit, or other integrated circuit (IC) device or network of devices.

[0067] The representative embodiments are illustrated by way of example in the drawings and will be described in detail below; however, it should be understood that the novel aspects of the present disclosure are not limited to the specific forms shown in the above - listed drawings. Instead, the present disclosure will cover all modifications, equivalents, combinations, sub - combinations, permutations, groupings, and alternatives falling within the scope of the present disclosure as, for example, defined by the appended claims. DETAILED DESCRIPTION

[0068] The present disclosure admits of many different forms of embodiments. Representative examples of the present disclosure are shown in the accompanying drawings and are described in detail herein. It should be understood that these embodiments are provided as examples of the principles disclosed and not as limitations on the broad aspects of the present disclosure. For this reason, elements and limitations described, for example, in the abstract, introduction, summary of the invention, description of the drawings, and detailed description sections but not explicitly set forth in the claims should not be incorporated into the claims singly or jointly by implication, inference, or otherwise. Additionally, the accompanying drawings discussed herein may not be drawn to scale and are provided solely for purposes of guidance. Accordingly, the specific and relative dimensions shown in the drawings should not be construed as limiting.

[0069] For the purposes of this detailed description, unless explicitly disclaimed: the singular includes the plural and vice versa; the words "and" and "or" shall be both conjunctive and disjunctive; the words "any" and "all" shall both mean "any and all"; and the words "including", "containing", "comprising", "having", and their permutations shall each mean "including but not limited to". Additionally, approximating words, such as "about", "almost", "substantially", "generally", "approximately", etc., may be used herein to mean "at, near, or approaching", or "within 0 - 5%", or "within acceptable manufacturing tolerances", or any logical combination thereof. Finally, directional adjectives and adverbs, such as front, rear, inner, outer, starboard, port, vertical, horizontal, up, down, forward, backward, left, right, etc., may refer to a motor vehicle, such as when the vehicle is operably oriented on a horizontal driving surface, the forward driving direction of the motor vehicle.

[0070] Currently, there is no global tracking system to monitor battery cell modules assemblies and traction battery packs before and after assembly line production. Many current technologies require each device to be manually inserted into a master control device and typically collect data only on an "as - needed" basis (e.g., just before group installation). In contrast, the disclosed WBMS monitoring system and method allow for the simultaneous wireless monitoring of multiple WBMS - connected devices during storage, transportation, at an assembly plant, and / or after installation. In addition to improving time efficiency, aspects of the disclosed concepts help provide a safety net for flagging damaged or malfunctioning CMAs, which results in improved system performance, increased battery life, and more comprehensive product information available for optimizing factory, storage, and shipping facility management.

[0071] The new software application for the resident chip of the device with WBMS connection allows the storage of device data and sends it to the WBMS manager device with various settings when desired. The software can include a timer-based measurement mode, in which a configurable timer "wakes up" the device to collect and store WBMS data, which has settings to accommodate excess data. As yet another alternative, the software can include an inventory management mode for continuously or nearly continuously monitoring each device. The WBMS manager device can be enabled to selectively wake up the device, request stored data, read and delete data from the device, and concomitantly update the WBMS database with any retrieved data. The WBMS monitoring system and database can be easily extended and integrated into the CMA / battery pack production, storage, shipping, and service nodes, and any node can be configured to track and store any logically related type of data, including device location, destination, diagnosis, faults, SOH, SOC, operating mode, historical data, etc.

[0072] A variety of options for the WBMS manager device are also available, including antenna-based storage monitoring, storage rack manager, handheld tablet manager, and manager-equipped shipping containers. The antenna-based storage monitoring system allows any one of multiple managers to broadcast and control multiple groups of devices over a large storage area. In contrast, the storage rack manager is equipped and programmed to automatically monitor devices with WBMS connections in a designated rack, rack group, or storage room. On the other hand, the handheld tablet computer manager is designed to directly connect to multiple remotely located WBMS devices in storage, transit, or use. The manager-equipped shipping container is equipped with a discrete WBMS manager device that collects data from the contents of the container.

[0073] According to specific but non-limiting examples, each CMU will be programmed with an inventory mode that allows the device to periodically wake up, collect, and store battery data, and transmit the data to the master device. This allows the WBMS to perform battery measurements daily (e.g., for up to six weeks) or multiple times a day (e.g., for up to two weeks). The inventory mode can be enabled for predefined portions of the CMU / battery pack manufacturing, storage, service, or shipping timeline. For example, a battery module connected to the WBMS can be equipped with a CMU while being transported from one facility to another, and the CMU wakes up periodically to collect battery cell data. When the shipment of battery modules arrives at the destination, a dedicated arrival manager can automatically update the corresponding ACL file and cycle through the list of shipment MAC addresses. When connected to the battery modules included with the shipment, the manager can automatically upload the module data to the storage device while changing the operating mode on the CMU to a predefined mode for the destination facility. The WBMS database is updated with the module ID, MAC address, and health status data for each module, as well as the current location and historical data. The WBMS allows for continuous monitoring of the battery modules and their peripheral electrical hardware, such that faulty or damaged modules are not put into use and are prevented from becoming dangerous while in storage.

[0074] Now referring to the drawings, in which like reference numerals refer to like features throughout several views, shown in Figure 1 is a representative vehicle, generally designated 10, and depicted herein for purposes of discussion as a sedan-type electric drive passenger vehicle. The illustrated vehicle 10—in this document also simply referred to as the “motor vehicle” or simply as the “vehicle”—is merely an exemplary application in which the various aspects of the present disclosure may be practiced. Similarly, the implementation of the concepts for fully electric vehicles should also be understood as a non-limiting application of the novel features disclosed herein. Thus, it will be understood that the aspects and features of the present disclosure may be applied to other electrified powertrain architectures, implemented for any logically related type of vehicle, and used for both automotive and non-automotive applications. Additionally, only selected components of the motor vehicle and the WBMS monitoring system are shown and will be described in further detail herein. However, the vehicles and systems discussed below may include many additional and alternative features, as well as other available peripheral components, for performing the various methods and functions of the present disclosure.

[0075] Figure 1 The representative vehicle 10 is initially equipped with a vehicle telematics and information (“telematics”) unit 14 that communicates wirelessly (e.g., via cell towers, base stations, mobile switching centers, satellite services, etc.) with a remotely located or “off-vehicle” cloud computing host service 24. Figure 1Some other vehicle hardware components 16 generally shown include (as non-limiting examples) an electronic video display device 18, a microphone 28, one or more audio speakers 30, and various input controls 32 (e.g., buttons, knobs, switches, touchpads, keyboards, touchscreens, etc.). Generally, these hardware components 16 function in part as a human / machine interface (HMI) to enable a user to communicate with the telematics unit 14 and other systems and system components within the vehicle 10. The microphone 28 provides a means for vehicle passengers to input verbal or other audible commands; the vehicle 10 may be equipped with an embedded voice processing unit that utilizes audio filtering, editing, and analysis software modules. Conversely, the speaker 30 provides an audible output to vehicle passengers and may be a stand-alone speaker dedicated to use with the telematics unit 14 or may be part of the audio system 22. The audio system 22 is operatively connected to the network connection interface 34 and the audio bus 20 to receive analog information via one or more speaker components and present it as sound.

[0076] Communicatively coupled to the telematics unit 14 is a network connection interface 34, suitable examples of which include twisted pair / fiber optic Ethernet switches, internal / external parallel / serial communication buses, local area network (LAN) interfaces, controller area network (CAN), media-oriented system transport (MOST), local interconnect network (LIN) interfaces, etc. Other suitable communication interfaces may include interfaces that conform to ISO, SAE, and IEEE standards and specifications. The network connection interface 34 enables the vehicle hardware 16 to send and receive signals to and from each other and to various systems and subsystems that are internal or "resident" to the vehicle body 12 as well as external or "remote" from the vehicle body 12. This allows the vehicle 10 to perform various vehicle functions, such as controlling vehicle steering, managing the operation of the vehicle driveline, adjusting powertrain output, engaging / disengaging the braking system, regulating the charging and discharging of the vehicle battery module, and other autonomous driving functions. For example, the telematics unit 14 receives data and / or transmits data to a wireless battery management system (WBMS) module 52, a battery pack control module (BPCM) 54, a powertrain control module (PCM) 56, a sensor system interface module (SSIM) 58, a braking system control module (BSCM) 60, and various other vehicle ECUs (such as a transmission control module (TCM), a climate control module (CCM), etc.).

[0077] Continuing to refer to Figure 1, the telematics unit 14 is an in-vehicle computing device that provides hybrid services both individually and through its communication with other networked devices. The telematics unit 14 typically consists of one or more processors 40, each of which may be embodied as a discrete microprocessor, an application specific integrated circuit (ASIC), or a dedicated control module. The vehicle 10 may provide centralized vehicle control via a central processing unit (CPU) 36, which is operatively coupled to one or more electronic memory devices 38 and a real-time clock (RTC) 42, each of which may take the form of a CD-ROM, a disk, an IC device, a flash memory, a semiconductor memory (e.g., various types of RAM or ROM), etc.

[0078] Remote vehicle communication capabilities with remote, non-vehicle networked devices may be provided via a cellular chipset / component, a navigation and positioning chipset / component (e.g., a global positioning system (GPS) transceiver), or a wireless modem, all of which are collectively represented at 44. Short-range wireless connectivity may be provided via a short-range wireless communication device 46 (e.g., a Bluetooth® unit or a near field communication (NFC) transceiver), a dedicated short-range communication (DSRC) component 48, and / or a dual antenna 50. It should be understood that the vehicle 10 may be implemented without one or more of the components listed above, or optionally, may include additional components and functions desired for a particular end use. The various communication devices described above may be configured to exchange data as part of a periodic broadcast in a vehicle-to-vehicle (V2V) communication system or a vehicle-to-everything (V2X) communication system, e.g., vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), and / or vehicle-to-device (V2D).

[0079] The CPU 36 receives sensor data from one or more sensing devices that perform autonomous driving operations using, for example, photoelectric detection, radar, lidar, ultrasonic, optical, infrared, or other suitable technologies, including short-range communication technologies such as DSRC or ultra-wideband (UWB). According to the illustrated example, the vehicle 10 may be equipped with one or more digital cameras 62, one or more distance sensors 64, one or more vehicle speed sensors 66, one or more vehicle dynamics sensors 68, and any necessary hardware and software for processing the raw sensor data. The type, placement, quantity, and interoperability of the distributed array of in-vehicle sensors may be individually or jointly adapted to a given vehicle platform for achieving a desired level of autonomous vehicle operation.

[0080] To propel the electric drive vehicle 10, the electrified powertrain is operable to generate traction torque and transfer it to one or more vehicle load wheels 26 of the vehicle. The powertrain is at Figure 1The medium is generally represented by a rechargeable energy storage system (RESS), which may have the nature of a traction battery pack 70 mounted on the chassis operatively connected to an electric traction motor 78. The traction battery pack 70 typically consists of one or more battery modules 72, each battery module 72 having a stack of battery pack cells 74, such as lithium-ion, lithium polymer, or pouch or prismatic nickel-metal hydride battery pack cells. One or more electric motors, such as a traction motor / generator (M) unit 78, draw power from the RESS battery pack 70 and, optionally, transfer power thereto. A power inverter module (PIM) 80 electrically connects the battery pack 70 to the motor / generator (M) unit 78 and regulates the current transfer therebetween.

[0081] The battery pack 70 is configured such that module management, cell sensing, and module-to-module or module-to-host communication functions are directly integrated into each battery module 72 and are performed wirelessly via corresponding wireless-enabled battery monitoring units 76. The CMU 76 can be a microcontroller-based printed circuit board (PCB)-mounted sensor array having a GPS transceiver and RF capabilities and is encapsulated on or within the battery module housing. The battery module unit 74, CMU 76, housing, coolant lines, busbars, etc. together define a battery module assembly. The disclosed configuration abandons the use of the type of separate hardwired electronic modules and serial connectors used in the above-described cell sensing board (CSB)-based topology. Additional information regarding CMU architecture and CMA design can be retrieved from U.S. Patent Application Publication No. 2020 / 0076014 A1, commonly owned by Matthew R. Garelli et al., which is incorporated herein by reference in its entirety and for all purposes.

[0082] Figure 2Depicts a distributed feedback control host system 100 for simultaneously monitoring a network of wireless-enabled devices—whether in storage, transit, production, or service—to derive real-time device data updates without the need to manually plug each device into a master control device. According to the illustrated example, user 101 is operating a portable computing (manager) device 110 to wirelessly communicate with the battery monitoring units 76 of multiple battery modules 74 in a wireless battery management system and thereby retrieve device data therefrom. The manager device 110 can be a handheld tablet computer, smartphone, laptop computer, or other similar suitable computing device that is communicatively coupled via a wireless communication network 114 to a remote main computer 112 or a cloud computing host service 124. Wireless data exchange between the manager device 110, CMU 76, main computer 112, host service 124, and database 116 can be effected via short-range wireless communication (e.g., Bluetooth® unit, near field communication (NFC) transceiver, dedicated short-range communication (DSRC) component, etc.) or remote wireless communication (e.g., radio antenna, WiFi network card, cellular network chip, etc.). Although a single user 101 is illustrated as communicating via the host system 100 with four (4) CMUs 72 of a single motor vehicle 10, it is envisioned that many users can communicate with any number and type of wireless-enabled vehicle devices or non-automotive devices of multiple motor vehicles that are suitably equipped for wirelessly exchanging information and data.

[0083] Continuing reference Figure 2 , the main computer 112 can be implemented as a high-speed server-class computing device or a mainframe computer capable of handling batch data processing, resource planning, and database management. For example, the main computer 112 can operate as a host in a client-server interface for any necessary data exchange and communication with one or more "third-party" servers to achieve the desired functionality. On the other hand, the cloud computing host service 124 can operate as middleware for IoT (Internet of Things), WoT (Web of Things), and / or V2V or V2X services, connecting a variety of heterogeneous electronic devices with a service-oriented architecture (SOA) via a data network connection. The network 114 can be any available type of network, including a combination of public distributed computing networks (e.g., the Internet) and secure private networks (e.g., local area networks, wide area networks, virtual private networks). It can also include wireless and wired transmission systems (e.g., satellites, cellular networks, terrestrial networks, etc.).

[0084] As part of this method, each CMU 76 stores, measures, and reports battery data including the condition log 103 (e.g., individual cell voltages and temperatures, module SOH and SOC data, battery capacity and open circuit voltage, and other real-time and historical device data), device-specific data 105 (e.g., MAC address, serial number, brand, model, year, etc.), and location data 107 (e.g., real-time geodetic position, destination, route, etc.). The CMU 76 is individually programmed with a software switch that enables a separate operating mode for the CMU 76; this operating mode will be described in detail below with specific reference to Figure 3 and 4 The CMU operating modes can include, individually or in any combination: (1) a time-regulated "timer mode" with a configurable timer (equivalent to the RTC 42) that wakes up the CMU to collect and store device data according to a current schedule; (2) an "inventory management mode" that enables the CMU to perform continuous or near-continuous monitoring within a preset time window or for the duration that the mode is enabled; (3) a "manager mode" in which a manager device selectively wakes up the CMU, requests stored data, reads and deletes data from the device's resident memory, and then puts the CMU to sleep; (4) an "active mode" that enables real-time monitoring and streaming of battery data of battery modules integrated into an electrified powertrain or other system and commands the battery modules to charge or discharge actively; (5) a "storage mode" that transitions the CMU to a low-power state when the battery modules within the CMA are asleep for a calibrated duration; and (6) a "transition mode" for preparing the CMU to switch from the active mode to the storage mode and vice versa.

[0085] Next, with reference to Figure 3 the flowchart of Figure 1 a method 200 generally described in accordance with aspects of the present disclosure for tracking and managing one or more battery modules (such as Figure 2 the traction battery module 72) using a distributed feedback control system (such as Figure 1 the centralized host system 100) by a wireless-enabled monitoring device (such as Figure 4 the CMU 74). Similarly, Figure 3 illustrates a representative inventory mode selection control strategy or method 300, which can be combined with Figure 3 the method 200 of 4Some or all of the operations illustrated and described in further detail below may represent one or more algorithms, each corresponding to processor-executable instructions that may be stored, for example, in main memory or secondary memory or remote memory and that may be executed, for example, by an electronic controller, a processing unit, control logic circuitry, or other module or device or network of modules / devices to perform any or all of the functions described above and below associated with the disclosed concepts. It should be recognized that the order of execution of the illustrated operation blocks may be changed, additional operation blocks may be added, and some of the described operations may be modified, combined, or eliminated.

[0086] Figure 2 Method 200 begins at terminal block 201, utilizing memory-stored processor-executable instructions for a programmable controller or control module or similar suitable processor to call an initialization routine for a WBMS inventory monitoring protocol. This routine may be executed in real time, continuously, systematically, sporadically, and / or at regular intervals, for example, every 100 milliseconds during normal device operation after being put into service. As yet another option, terminal block 201 may be initialized in response to a user command prompt (e.g., via an input of manager device 110) or a broadcast prompt signal received from a centralized host system (e.g., main computer 112). Method 200 proceeds from terminal block 201 to manufacturing process block 203, where multiple CMAs are produced, for example, at a dedicated battery manufacturing plant. The assembled battery modules may await shipment in a warehouse facility and, optionally, may be temporarily stored on storage racks. A dedicated storage rack manager located at the battery manufacturing plant / warehouse facility may monitor the CMAs prior to shipment.

[0087] After CMA production at manufacturing process block 203, the device-specific data for each CMA is uploaded to the WBMS database, as Figure 3 indicated by database storage block 205. As a non-limiting example, when each battery module assembly leaves the battery production line, a preliminary log file may be generated for it. The battery monitoring unit for each CMA may be programmed to automatically upload the log file or a predefined portion thereof to the WBMS database 116. This preliminary log file may contain different MAC addresses (or Internet Protocol (IP) addresses), serial numbers, Address Resolution Protocol (ARP) information, etc., to facilitate device identification and communication. The log file may also record the initial history of the device, including the preliminary status of the health assessment from the "end-of-line" test, location data, default operation mode settings, and operator notes to be added to the database (e.g., diagnostic reports, repair instructions, creation date, intended destination, starting location, etc.).

[0088] Method 200 proceeds from database storage block 205 to subroutine processing block 207 to invoke an application software program for selecting which CMU or CMUs will be requested for device data. The program can be built within a program-structured and object-oriented programming language (e.g., PYTHON®) and provides a feature suite with scripts for identifying, logging, and parsing CMU data. By way of illustration, Figure 2 Manager device 110 of can be connected to remote host computer 112 and access (e.g., when host 112 acts as a middleware API) or install (e.g., when manager 110 operates as a stand-alone device) a wireless interface library (WIL). The WIL can operate as a user interface through which the user communicates with the manager device and optionally with the host system. It is through this WIL program that user 101 can manually select the CMAs they wish to monitor and manage. User 101 can sort through the available CMAs catalog and select devices individually piecemeal, or alternatively, select all devices within a designated facility, vehicle, shipping container, storage area, etc. Once selected, the user can cycle through the available device data (e.g., MAC address, ID, origin, etc.) for the selected devices. As yet another alternative option, device selection can be achieved by the user providing the MAC address of each desired CMA to the manager device via the WIL. For example, the user can select one or more MAC addresses from a MAC address database; create a corresponding ACL, pass it to the WIL for communication and upload it to the manager, and the WIL invokes the manager ACL and compares it with the previously provided ACL to verify its content.

[0089] From subroutine procedure block 207, Figure 3 method 200 of proceeds to document processing block 209 to create and / or update a manager access control list. In essence, the manager ACL can be built by host computer 112, stored on and accessed through cloud computing host service 124, and updated using the graphical user interface (GUI) features within the WIL on manager device 110. A manager ACL can be created by changing the existing ACL text file with the MAC address and ID data of the CMUs of the selected CMAs and downloading the file to the manager device. Host computer 112 can write a new ACL file for each user input selection of CMUs.

[0090] After the ACL is updated at document processing block 209, method 200 determines at decision block 211 whether the manager ACL was successfully updated. Referring again to Figure 2For the representative host system 100 architecture, the host computer 112 can send a ping to the manager device 110 to transmit an electronic copy of the manager ACL stored in its resident cache. When the host computer 112 receives the copy, it compares the manager ACL with the host ACL created by the host computer 112. This comparison can include the host computer 112 continuously evaluating the MAC addresses and ID data in the manager ACL against the MAC addresses and ID data listed in the host ACL; if they match, the manager ACL has been successfully updated. If the manager ACL is not successfully updated (block 211 = no), the method 200 can loop back to the subroutine process block 207 and select a new batch of CMUs.

[0091] In response to the determination that the manager ACL has been successfully updated (block 211 = yes), the method 200 proceeds to process block 213 and broadcasts an electronic ping to each CMU of the selected CMA to establish a wireless connection between each CMU and the manager device. For at least some system architectures, the electronic ping can include a network data packet that, in addition to other control and payload information, also has a command signal to transition the desired CMU from the sleep mode to the wake mode. Once awakened, a packet-switched wireless connection can be established between the two devices. Thereafter, decision block 215 verifies whether a wireless connection has been successfully established with each CMU. If not (block 215 = no), the method 200 loops back to process block 211 and transmits a new electronic ping to each CMU where the wireless connection has failed.

[0092] Once it is determined that a wireless connection has been successfully established with the CMU (block 215 = yes), the method 200 continues to data block 217 and downloads the CMA device data from the corresponding CMU to the manager device. As indicated above, the device data retrieved by the manager device 110 from the CMU 76 can include any logically related type of data, including device diagnostic data, device fault data, battery voltage and temperature data, SOH data, SOC data, real-time and / or predefined operation mode data, historical device data, etc. Similarly, the host computer 112 (or the manager device 110) can simultaneously obtain the data date / time stamp, real-time device location data, and / or predefined device destination data, such as Figure 3as indicated at data block 219. In a non-limiting example, the manager device may retrieve and upload corresponding battery voltage and temperature data from a selected group of battery modules; the host computer device receives the uploaded data, generates an appropriate timestamp for each file, adds location data, and updates the corresponding CMA file in the database. The operator can then access and edit the CMA files stored in the database, including adding notes such as maintenance notes or changes to the schedule notes. The selected data can then be deleted from the resident memory of the CMU. For database storage block 221, the WBMS database is then updated to include any or all portions of the data retrieved at data blocks 217 and 219.

[0093] Decision block 223 determines whether the WBMS database has been successfully updated with the selected portions of the retrieved data. If not (block 223 = no), method 200 loops back to database storage block 221 and attempts again to store the CMA device data retrieved from the CMU in the WBMS database. On the other hand, when it is determined that the WBMS database has been successfully updated (block 223 = yes), the operating mode of the CMU is switched, for example, from a wake mode to a sleep mode, a default operating mode, or a desired operating mode. For example, the operating mode of the CMU can be switched by transmitting an electronic command prompt to the CMU to transition from a wake mode prompted by the manager to a continuous wake inventory mode. Thereafter, method 200 can confirm at subroutine end block 227 that the manager device is ready for the next device in the manager ACL and concomitantly loop back to process block 213. After the device data for all selected CMAs within the manager ACL has been collected, Figure 3 method 200 can proceed from process block 225 to terminal block 229 and pause temporarily, or can loop back to terminal block 201 and run in a continuous loop.

[0094] Next, referring to Figure 4 , method 300 begins at decision block 301, where the frequency at which CMA device data is needed from the CMU is determined. The device data timing and frequency can be determined by the stage or destination of a given battery module. For example, a traction battery module placed in a storage device of a motor vehicle may need to have its data acquired once a week or less frequently. In contrast, a service location with running and faulty modules on a continuous rotating basis may need it daily if not continuous real-time device data. The data system can be customizable to allow flexibility in determining the criteria for data timing and frequency and the parameters associated therewith.

[0095] When it is determined at decision block 301 that continuous CMA monitoring is desired, method 300 proceeds to process block 303, and the host system sets the CMU to the inventory management mode. Process block 305 provides processor-executable instructions to the manager device to receive a continuous feed of CMA data from each wirelessly-connected CMU. Simultaneously with or after data collection, the manager device systematically pushes the device data to the WBMS database, as indicated by process block 307. Thereafter, Figure 4 the method may proceed to terminal block 309 and terminate, or may loop back to terminal block 301 and run in a continuous loop.

[0096] In response to determining at decision block 301 that time-based rather than continuous CMA monitoring is desired, method 300 proceeds to process block 311 and identifies the scheduling parameters for the timer mode (e.g., wake up the CMU once every 1, 3, or 7 days). The time mode and its associated settings may be predefined by the host system or manually selected by the operator, e.g., based on the desired application or selectively customized. At process block 313, the CMU wakes up at the interval settings and saves the CMA device data. Once saved, the method moves from process block 313 to decision block 315 to determine if there is sufficient storage space remaining in the resident memory for the newly-acquired device data. If not (block 315 = no), then method 300 transfers to process block 317 and identifies the oldest data saved to the resident memory based on the data date / timestamp, overwrites a sufficient amount of this "old" data, and once complete, sets a flag that the data has been deleted.

[0097] In response to determining that there is sufficient storage space remaining in the resident memory for the new device data (block 315 = yes), method 300 transfers to process block 319 and wirelessly connects the manager device to the available CMUs of the selected CMA. Subsequently, at process block 321, the manager downloads the device data from the CMU and optionally purges the downloaded CMA device data while synchronously updating the WBMS database. Thereafter, method 300 proceeds to process block 323 and disconnects the manager device from the CMU. After the manager device is disconnected at process block 323, the method may loop back to process block 311, proceed to terminal block 309 and terminate, or may loop back to terminal block 301 and run in a continuous loop.

[0098] In some embodiments, aspects of the present disclosure may be implemented by a computer-executable instruction program such as program modules, which are typically referred to as software applications or application programs executed by any of the controllers or controller variants described herein. In a non-limiting example, the software may include routines, programs, objects, components, and data structures that perform specific tasks or implement specific data types. The software may form an interface to allow the computer to react based on the input source. The software may also cooperate with other code segments to initiate various tasks in response to data received in conjunction with the received data source. The software may be stored on any of a variety of memory media, such as CD-ROMs, disks, and semiconductor memories (e.g., various types of RAM or ROM).

[0099] In addition, aspects of the present disclosure may be practiced with a variety of computer system and computer network configurations, including multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Additionally, aspects of the present disclosure may be practiced in a distributed computing environment where tasks are performed by resident and remote processing devices linked through a communication network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices. Thus, aspects of the present disclosure may be implemented in conjunction with various hardware, software, or combinations thereof in a computer system or other processing system.

[0100] Any method described herein may include machine-readable instructions executed by (a) a processor, (b) a controller, and / or (c) any other suitable processing device. Any algorithm, software, control logic, protocol, or method disclosed herein may be embodied as software stored on a tangible medium such as, for example, flash memory, solid-state memory, hard disk drive, CD-ROM, digital versatile disk (DVD), or other memory device. The entire algorithm, control logic, protocol, or method and / or portions thereof may alternatively be executed by a device other than a controller and / or embodied in firmware or dedicated hardware in a manner available (e.g., implemented by an application specific integrated circuit (ASIC), programmable logic device (PLD), field programmable logic device (FPLD), discrete logic, etc.). Additionally, although specific algorithms are described with reference to the flowcharts depicted herein, many other methods may alternatively be used to implement the example machine-readable instructions.

[0101] Aspects of the present disclosure have been described in detail with reference to the illustrated embodiments; however, those skilled in the art will recognize that many modifications can be made thereto without departing from the scope of the present disclosure. The present disclosure is not limited to the exact construction and composition disclosed herein; any and all modifications, changes, and variations that are apparent from the foregoing description are within the scope of the present disclosure as defined by the appended claims. Additionally, this concept expressly encompasses any and all combinations and sub-combinations of the foregoing elements and features.

Claims

1. A method of operating a wireless battery management system (WBMS), the WBMS including a plurality of cell module assemblies (CMAs), each cell module assembly having a corresponding battery module and a corresponding cell monitoring unit (CMU), the method comprises: storing in a WBMS database of the WBMS corresponding media access control (MAC) addresses and identification (ID) data for the CMAs; selecting, via a wireless-enabled manager device, a batch of CMAs to communicate with thereto to thereby retrieve data of their corresponding battery modules; generating a manager access control list (ACL) having the corresponding media access control (MAC) addresses and identification (ID) data for the selected batch of CMAs; wherein generating the manager access control list (ACL) includes: retrieving, via a remote computing device, the corresponding MAC addresses and ID data for each selected CMA from the WBMS database; creating, via the remote computing device, a text file with the corresponding MAC addresses of the selected CMAs; and uploading the text file from the remote computing device to the manager device; establishing a wireless connection between the manager device and the corresponding CMUs of the selected CMAs based on the MAC addresses and the ID data in the manager ACL; downloading, via the manager device, device data of each battery module associated with the selected CMAs from the corresponding CMUs of the selected CMAs; and switching an operation mode for each corresponding CMU.

2. The method according to claim 1, further comprising transmitting the MAC addresses and the ID data to the WBMS database of the WBMS via the CMAs.

3. The method according to claim 1, wherein, selecting the batch of CMAs includes receiving a user input selection via a wireless interface library (WIL) operating on the manager device, the user input selection identifying which of the plurality of CMAs communicates with the manager device.

4. The method according to claim 1, further comprises: transmitting the generated manager ACL from the manager device to a remote computing device; comparing, via the remote computing device, the manager ACL with a master ACL to determine whether the MAC addresses in the manager ACL correspond to an associated list of the MAC addresses in the master ACL; and in response to the MAC addresses in the manager ACL not corresponding to the associated list of the MAC addresses in the master ACL, selecting a new batch of CMAs via the manager device.

5. The method according to claim 1, wherein, establishing the wireless connection includes the manager device wirelessly transmitting an electroacoustic pulse to the corresponding CMU of each CMA in the batch of CMAs.

6. The method according to claim 5, wherein, the transmitted electroacoustic pulse causes the CMU to transition from a sleep mode to a wake-up mode.

7. The method according to claim 5, further comprises: determining whether the wireless connection with each CMU is successfully established; and Transmit a new electronic acoustic pulse to each CMU that has not successfully established a wireless connection with the CMU.

8. The method according to claim 1, further comprising, after downloading the device data via the manager device, transmitting a command prompt via the manager device to each CMU of the selected CMA to clear the device data from the resident memory device of the CMU.

9. The method according to claim 1, further comprising transmitting the downloaded device data of the battery modules of the selected CMA to the WBMS database of the WBMS via the manager device.

10. The method according to claim 1, wherein, Switching the operation mode includes transmitting a command prompt to each respective CMU to transition from the wake-up mode prompted by the manager to the continuous wake-up inventory mode.

11. The method according to claim 1, further comprising retrieving corresponding location, destination, mode, and / or historical data for each selected CMA via the manager device.

12. The method according to claim 1, wherein, The device data includes battery voltage data, battery temperature data, state of charge (SOC) data, and / or state of health (SOH) data of the battery.

13. A host system for operating a wireless battery management system (WBMS), the host system comprising: A WBMS database; A wireless-enabled manager device communicatively connected to the WBMS database, the manager device being programmed to: Select a batch of CMAs from a plurality of battery module assemblies (CMAs) each having a respective battery module and a respective battery monitoring unit (CMU) to communicate with them, thereby retrieving data of their respective battery modules; Invoke a manager access control list (ACL) that has the corresponding media access control (MAC) addresses and identification (ID) data of the selected CMAs; Use the MAC addresses and the ID data in the manager ACL to wirelessly connect to the corresponding CMU units of the selected CMAs; Download device data of each battery module associated with the selected CMAs from the corresponding CMUs of the selected CMAs; and Command each corresponding CMU to switch the operation mode; and A main computer device remote from the manager device, the main computer device being configured to: Retrieve the corresponding MAC addresses and ID data of each selected CMA from the WBMS database; Create a text file with the corresponding MAC addresses of the selected CMAs; and Upload the text file to the manager device.

14. The host system according to claim 13, wherein, Selecting the batch of CMAs includes the manager device receiving a user input selection via a wireless interface library (WIL) operating on the manager device, the user input selection identifying which CMAs are to communicate with the manager device.

15. The host system according to claim 13, wherein, The manager device is further programmed to: Transfer the generated manager ACL to a host computer device remote from the manager device, and the host computer device compares the manager ACL with a master ACL to determine whether the MAC addresses in the manager ACL correspond to the associated list of MAC addresses in the master ACL; and in response to the MAC addresses in the manager ACL not corresponding to the associated list of MAC addresses in the master ACL, select a new batch of CMAs.

16. The host system according to claim 13, wherein, establishing the wireless connection includes the manager device wirelessly transmitting an electroacoustic pulse to a corresponding CMU for each selected CMA, and the transmitted electroacoustic pulse causes the CMU to transition from a sleep mode to a wake mode.

17. The host system according to claim 16, wherein, the manager device is further programmed to: determine whether a wireless connection has been successfully established with each of the CMUs; and send a new electroacoustic pulse to each CMU for which it is determined that a wireless connection has not been successfully established.

18. The host system according to claim 13, wherein, switching the operation mode includes the manager device transmitting a command prompt to each corresponding CMU to transition from a wake mode prompted by the manager to a continuous wake inventory mode.

19. A method of operating a wireless battery management system (WBMS) that includes a plurality of cell module assemblies (CMAs), each cell module assembly having a corresponding battery module and a corresponding cell monitoring unit (CMU), the method comprises: selecting, via a wirelessly enabled manager device, a batch of CMAs to communicate with to thereby retrieve data of their corresponding battery modules; generating, for the selected batch of CMAs, a manager access control list (ACL) having the corresponding media access control (MAC) addresses and identification (ID) data; transferring the generated manager ACL from the manager device to a remote computing device; comparing, via the remote computing device, the manager ACL with a master ACL to determine whether the MAC addresses in the manager ACL correspond to the associated list of MAC addresses in the master ACL; in response to the MAC addresses in the manager ACL not corresponding to the associated list of MAC addresses in the master ACL, selecting a new batch of CMAs; establishing a wireless connection between the manager device and the corresponding CMUs of the selected CMAs in the new batch of CMAs based on the corresponding MAC addresses and ID data of the new batch of CMAs; downloading, via the manager device, device data of each battery module associated with the selected CMAs in the new batch of CMAs from the corresponding CMUs of the selected CMAs in the new batch of CMAs; and switching the operation mode for each corresponding CMU in a batch of CMAs.

20. The method according to claim 19, further comprising transmitting the MAC addresses and ID data to a WBMS database of the WBMS via the CMA, wherein, Generating the manager ACL includes retrieving the corresponding MAC address and ID data of each selected CMA from the WBMS database.

21. The method according to claim 20, wherein, generating the manager ACL further includes: creating a text file with the corresponding MAC address of the selected CMA via a remote computing device; and uploading the text file from the remote computing device to the manager device.

22. The method according to claim 19, wherein, selecting the batch of CMAs includes receiving a user input selection via a wireless interface library (WIL) operating on the manager device, the user input selection identifying which of the plurality of CMAs communicates with the manager device.

23. The method according to claim 19, wherein, establishing the wireless connection includes the manager device wirelessly transmitting an electroacoustic pulse to the corresponding CMU of each CMA in the batch of CMAs.

24. The method according to claim 23, wherein, the transmitted electroacoustic pulse causes the CMU to transition from a sleep mode to a wake mode.

25. The method according to claim 19, further comprising, after downloading device data via the manager device, transmitting a command prompt via the manager device to each CMU of the selected CMAs to clear the device data from the resident memory device of the CMU.

26. A method of operating a wireless battery management system (WBMS), the WBMS including a plurality of cell module assemblies (CMAs), each cell module assembly having a corresponding battery module and a corresponding cell monitoring unit (CMU), the method comprises: selecting, via a wireless-enabled manager device, a batch of CMAs to communicate with to thereby retrieve data of their corresponding battery modules; generating a manager access control list (ACL) for the selected batch of CMAs with the corresponding media access control (MAC) address and identification (ID) data; establishing a wireless connection between the manager device and the corresponding CMUs of the selected CMAs based on the MAC address and ID data in the manager ACL, wherein establishing the wireless connection includes: wirelessly transmitting an electroacoustic pulse from the manager device to the corresponding CMU of each CMA in the selected batch of CMAs; determining whether the wireless connection with each CMU has been successfully established; and transmitting a new electroacoustic pulse to each CMU for which it is determined that the wireless connection has not been successfully established; downloading, via the manager device, device data of each battery module associated with the selected CMAs from the corresponding CMUs of the selected CMAs; and switching the operating mode for each corresponding CMU.

Images