Battery Markup Language (BatML) Standard
Battery Markup Language and Schema
Overview of Battery ML
The objective of the BatteryML specification is to provide standardized format for definition of all the necessary information for battery performance and safety modeling. The overall design for the BatteryML is given in Fig. 1 below. The BatteryML Schema establishes the main structure for the BatteryML data files and enables data validation and consistency checking. BatteryML files can contain databases and models with default values or with company proprietary information. For e.g., Dow-Kokam or Johnson Controls can provide a database of their cell-sandwich properties that an OEM can directly use in their models. Several examples based on open literature for standard battery materials and components have been developed and made available to the project partners. The GUI under development uses these Schemas and Databases along with any additional user input to create a BatteryML input file. This XML file can either be directly be used by simulation packages or through translators that transform this input into native formats read by the different software components.
Figure 1: Overall Structure of the Battery ML
The top-level structure of the Battery ML Schema (available at the VIBE project website https://vibe.ornl.gov/) is shown in Fig. 2. Here we define a battery component type that contains the base components such as anode, cathode, electrolyte, separator, current collectors. These base components are used to build higher-level components such as cell-sandwich, cell, module, pack, parts (e.g., busbar, cooling fins). Each of these components can contain additional sub-components, as their definition is dependent on the form of model used. For e.g., the cell-sandwich definition will depend on whether it uses DualFoil (pseudo-2D), RC model or NTG model. The Cell can be further specified as Cylindrical cell, Prismatic cell, etc. To enable this flexibility, we picked the relational data model (hierarchical data model will also be implemented in the language). The main considerations for selecting the relational versus hierarchical data model were
· Batteries have very deep hierarchy and the hierarchical data model will lead to considerable duplication of the data
· Relational data model provides the flexibility to quickly modify the hierarchies of the models and add new components
· Relational approach requires that all the references to the data exist and that the model is self-contained. This does not impose a strong limitation because the input files will be primarily manipulated using GUI and not by user editing of the BatteryML XML files.
· Cross referencing in relational data model drastically reduce data duplication and the corresponding risk for errors.
We have also implemented a markup language subset and database (UnitsDB) for the definition of physical units in the model. The underlying unit specification is implemented using Units Markup Language (UnitsML) specifications from National Institute of Standards and Technology. The UnitsDB can be used to define units of relevance to electrochemistry and build on (UnitsML).
Figure 2: Battery ML Schema
Once the DualFoil model has been selected, it can be further subdivided into different components of the cell-sandwich. The Battery ML schema imports the cell-sandwich schema (whose structure is shown in Fig. 3 and can be downloaded from the project’s web site) that further specifies the details of its components.
Figure 3: Cell-Sandwich and Component ML Schema Types
Similar hierarchical expansion can be used to define cell, module, pack, etc. Current implementation contains the above battery hierarchy. Additional data model customizations will be performed in order to support full transformations from one input format to another.
The developed BatteryML Schema(s) can be used for dynamic generation of the GUI interface for the battery model development. An example BatteryML file generated using an XML Schema-based editor XAmple (http://www.felixgolubov.com/XMLEditor/) is shown in Fig. 4.
Figure 4: Structure of the Battery ML file.
The XML files can be queried by simple XQuery commands to extract the necessary properties or they can be transformed and processed using XSLT or scripts (e.g., Perl, Python). We keep the project’s website up to date with the latest version of the schema, corresponding documentation and examples, schema validation tools, etc.