I bumped into BDF and BDA by accident but wanted to say thank you for this initiative.
Some background on my history working with battery data in industry:
From 2020-2024 I was responsible for battery data management, analytics, and cell modelling at Lilium Aviation (an eVTOL startup). We performed a huge amount of cell- and pack level tests and had to cope with dozens of different file formats and data schemas from various external test houses, each using a different cycler. This caused a lot of pain.
I pushed for standardizing the data format internally as well as externally with the suppliers, with … let’s say mixed success. So having a universal standard was something I always dreamed of.
Now I’m in acedemia (Prof at Munich University of Applied Sciences) and would be happy to support this effort if I can. Are you looking for community contributions? (I’m a Python developer with plenty of open source experience.)
A probably unrelated question: apart from the output (data), harmoizing the input (cycler protocol) is also something I dreamed of, and something I guess you’re interested in. I’ve seen several forum topics on it, but no mention of Ionworks’ Universal Cycler Protocol ( Universal Cycler Protocol - Ionworks Studio ). If I understand correctly, it’s not an open protocol at present, but is something like that in BDA’s scope?
It’s not currently part of BDA, but I am developing an open source universal cycling protocol package:
It can do Python/JSON protocol to Neware or BioLogic (mps), and it can also create BattINFO ontology jsonld and PyBaMM experiments. It’s just one-way at the moment (unicycler → other format).
@DavidMStraub thanks for sharing that background, your experience at Lilium is pretty much the exact scenario that motivated BDF. And yes, we’re absolutely looking for community contributions, especially from people who’ve dealt with multi-vendor data at scale.
We have a few [open spec questions]( BDF: What's Been Built and What's Next ) right now, EIS data, step indexing, temperature columns, where someone who’s wrestled with dozens of formats from external test houses would be directly useful. The Python package ([batterydf]( batterydf · PyPI )) could also use more eyes, particularly around vendor format coverage. The [open standard thread]( Open standard for cycler output data ) has the full discussion history if you want to see how we got here.
On the protocol side, it’s definitely in BDA’s scope though we prioritized aligning on a common format (a format of last resort at the time). However, we did some early work with [BatteryDataInterface]( GitHub - battery-data-alliance/BatteryDataInterface: Battery data interface specifications · GitHub ) but it’s behind where others are. Ionworks and Empa are both great contributors to open source, and each project looks great. @graham@valentin@DavidMStraub There’s clear demand and a real need for alignment across these efforts. Would be a good topic to discuss here on the forum, pros/cons of the different approaches and where BDA should focus.