TBOS Software Architecture: How the Magic Happens (Part 1 of 2)
Our software-defined battery (SDB) solutions supported by the Tanktwo Battery Operating System (TBOS) offer a range of battery management capabilities that aren’t available through any existing battery solution.
This two-part series delves into the inner workings of TBOS to show how the various functions come together to deliver an innovative battery architecture that can overcome the limits of today’s battery solutions to make electrification sustainable and profitable.
The Four Key Components of TBOS
TBOS is an intricate system connecting software with hardware (i.e., battery cells) and involves four main components:
T-Blocks
A T-Block is a physical unit consisting of cells in a predetermined arrangement — it’s the basic building block of a typical TBOS-driven battery system. It consists of the following:
Electrochemical cells of any age and chemistry mix.
Hardware that controls the cells using predetermined logic.
Hardware for monitoring the cells and collecting telemetry.
Software to control the hardware via a TCP/IP network.
TBOS Control Unit
A computer in the TBOS control unit communicates with other components via a TCP/IP network to monitor and control the battery system. The control unit performs functions including:
Detect T-Blocks in the system.
Provide a control interface for operators to interact with the system.
Collect and analyze telemetry from T-Blocks.
TCP/IP Network
The framework provides communication protocols to transmit data over the internet. In a TBOS-driven battery system, it performs the following functions:
Hosts the DHCP server to assign IP addresses for all devices in the TBOS system.
Provide connectivity between T-Blocks and the control unit.
Connect the battery solution to external networks for system control.
User Devices
A TBOS-driven battery system can connect with any number of user devices (or none at all) so operators can interact with it in real time by:
Connecting to the graphic user interface (UI) in the control unit.
Visualizing telemetry data.
Offering a UI for system control and monitoring.
Software components within the T-Blocks and control unit power TBOS’s innovative capabilities. Here’s a closer look at these two components:
T-Blocks
The software component in a T-Block acts as an intermediary between the cells and the control unit. It allows the system to monitor the state of health (SoH) and assert granular control over each cell to achieve the many features unique to SDB systems.
1. TBOS Management Unit (TMU)
The TMU is the “brain” of each T-Block. It consists of multiple software components, typically implemented on top of Linux OS. Each T-Block comes with two identical TMUs for redundancy and reliability.
2. Main Loop
The main loop is the high-level logic that makes the battery system work — then rinse and repeat.
Main Loop Component 1: TBOS Algorithm
The TBOS algorithm is the control logic that identifies cells and T-Blocks using non-volatile memory (or EEPROMs). It reads cell telemetry, performs cell selection routines, monitors cell safety, and controls cell field effect transistors (FETs), master FETs, and the current limiter. Additionally, it stores the system state with cell telemetry and executes the desired charging and discharging voltages using information from the cache.
The TBOS algorithm has four elements:
TBOS API uses the cache to transmit data between the algorithm and the REST server.
The TBOS cell management feature maintains the logical structure, allowing the software to work with any hardware (i.e., battery packs.)
TBOS drivers function as an abstraction layer for sensors, allowing builders to implement TBOS on any hardware.
TBOS config defines connected peripherals and settings for specific hardware.
The TMU monitors cell and system health in the standby state. Once it receives commands from the system controller, it executes the algorithm and switches to a charging or discharging state.
Charging starts with configuration imports to define the operating conditions for the algorithm. Then, the software performs a verification loop to ensure the measured charging voltage matches the predefined value.
The charging algorithm controls cell selection and monitoring. Cell selection is the outer loop of the algorithm and continues to operate until a stop command is issued or a critical exception occurs. Cell monitoring occurs in the inner loop, and continues until the charging cycle times out or an exception occurs. When the monitoring loop breaks, the algorithm determines whether the software should select new cells or stop charging.
Like the charging algorithm, the discharging algorithm controls cell selection and monitoring. The process starts by ensuring all cells are usable and within the safe operating window. The algorithm then sorts and adds cells to the string. Next, it determines the maximum power that can be transferred to or from each string based on each cell’s internal resistance, string length, and desired voltage.
Main Loop Component 2: Beacon
The beacon runs parallel to the TBOS algorithm and sends universal data protocol (UDP) broadcast packets to the local network to announce the TMU’s ID, IP address, and state. The control unit uses this information to detect usable TMUs in the network.
Main Loop Component 3: TMU Redundancy
The TMU redundancy software runs parallel to the TBOS algorithm. It manages the two parallel and identical TMUs inside each T-Block. It communicates via serial and TCP/IP with the TMUs, determines the controlling unit, monitors the TMU in control, and ensures safe switchover if the controlling unit experiences an issue.
3. Cache
The cache is an information exchange service. It allows software components running in parallel threads to share data. The one in TBOS stores settings and hardware reservations using Redis, an in-memory data store that supports various abstract data structures.
Telemetry data is first stored in the cache and then transferred to the control unit’s database (which could cause the cell measurement displayed through the control unit UI to have a theoretical delay of up to 12 seconds.)
4. REST Server
This HTTP server uses the cache to relay telemetry and commands between T-Blocks and the TMU algorithms.
5. FET control
Our system uses gallium nitride (GaN) metal oxide semiconductor FET, a critical component in the Dynamic Current Routing Matrix (DycromaxTM) architecture that supports TBOS’s unique features like variable output voltage and yellow flagging.
6. Cell Sensors
These measurement instruments collect telemetry from the electrochemical cells, including cell temperature, cell voltage, string current, and string voltage.
7. Current Limiter
This component is essential for constant voltage charging — a unique TBOS capability. The hardware feedback loop measures string current and limits it to the desired level. It also includes over-temperature protection for the current-limiting semiconductors.
The TBOS algorithm controls the digital-to-analog converter (DAC), which includes a proportional integration differential (PID) loop to predict the current limiter’s dissipated power. When the temperature in the semiconductor increases, the software PID loop reduces the dissipated power before the hardware’s one-time programming (OTP) circuit disables the current flow completely to protect the cells from overheating.
8. Block and Cell EEPROM
The EEPROMs in T-Blocks and cells store unique identifiers, which can be read by the TBOS algorithm and included in the collected telemetry to make all measurements traceable.
The memory can also include device-specific settings and usage limits for the TBOS algorithm to enforce specific rules. For example, we can use it as a safety control to ensure that the device’s maximum current limit isn’t surpassed, even if software components receive higher values via external commands or software updates.
TBOS Control Unit
The control unit automatically detects all T-Blocks in the network, collects telemetry, and stores the data in its database. The information contains time series telemetry data and log information for debugging purposes.
The unit has a scanner that listens for broadcast messages from the beacon in all T-Blocks. It controls the T-Blocks, e.g., by defining the voltages and operation mode and issuing commands via the web user interface. The message broker then relays the messages from the web user interface to the command execution task.
Meanwhile, the task queue in the control unit fetches TBOS settings from the TMU and telemetry from the TMU REST server endpoint, executes commands on T-Blocks, and deletes old telemetry no longer required.
To create the redundancy required for maximum reliability, we put multiple instances of the software into each system — all of which have the command line to control the entire system. We also have an arbitrage logic to ensure the integrity of the decision-making process in case there are conflicting commands from different control units.
Our next installment will discuss how these components work together to deliver the unique capabilities offered by our software-defined battery solutions.
