TBOS: Sandboxing for secure battery development and operations (BatSec Series 4/6)
[ Missed the previous posts? Read part 1, part 2, and part 3. ]
Battery security lives at the intersection of data science, cryptography, material science, and economics and is the foundation on which we build software-defined batteries (SDBs), the battery topology of the future. It’s the cornerstone of the Tanktwo Battery Operating System (TBOS) and is interwoven with all its capabilities.
Our battery security architecture allows organizations, systems, or teams with specific competence to work in their areas of expertise (i.e., sandboxes) while interacting with adjacent ones to ensure seamless integration of different functionalities without the ability to alter things they don’t know enough about.
The sandboxing arrangement facilitates collaboration among experts in various disciplines to optimize each application. For example, an owner will likely want to maximize the lifespan of the asset (i.e., battery pack) but don’t have the knowledge to know how far to turn the dial before safety or accelerated wear becomes an issue.
With advanced access control mechanisms, our technology sandboxes different functional areas. For instance, the owner can interact with battery chemistry experts to optimize asset lifespan, safety, and operational simplicity to maximize lifetime value without impacting safety. Non-specialists can operate the system independently without jeopardizing its integrity.
Sandboxing requires an airtight cryptography-based ecosystem, and we have integrated it into TBOS's battery security architecture. We build the security part of this foundation on operational principles to support the universal long-tail implementation of electrified products and equipment.
Battery security use cases: Enabling the right people to access the right capabilities
With our battery security architecture, different players in the battery ecosystem can perform their duties or optimize business outcomes without blowing things up or exposing the architecture to external threats.
Business decision-makers can develop products and pricing structures to support business models without straining a battery’s capacity.
Battery chemistry experts can change limits for cell temperature, voltages, currents, waveforms, duty cycles, etc., to support business requirements.
Fleet managers can re-allocate battery packs across vehicles and drivers to access extra power (i.e., “turbo boost”) when required.
Utility companies can use battery packs for buffer capacity when the grid is strained (at a predetermined cost.)
Power-as-a-Service providers can limit the performance or shut down the power supply when a customer skips payment.
Insurance providers can limit how and where a battery pack is used (e.g., with geo-fencing.)
Battery security also prevents:
Battery packs from self-discharging and becoming unusable.
Black market economies from re-purposing batteries.
Drivers from using “turbo boost” too often, compromising the battery packs’ longevity.
Lessees from using batteries in geographic areas outside their service agreements (e.g., places that are too hot or cold, which may affect battery health and safety.)
Owners from getting back battery packs with worse state-of-health than anticipated at the end of a lease agreement.
Up next: The nuts and bolts of Tanktwo battery security technology
So how do we make our SDBs do all of these neat tricks and more? We support our forward-thinking vision with cutting-edge software engineering. The next installment of this series will discuss the core component of this technology: key management.
