Adding Optionality for Custom Measurement Integration

General
1

As mentioned in April’s Monthly sync, I believe it’d be beneficial to have some form of custom measurement integration for BDF. In the consumer electronics industry, we are very concerned about swelling and thickness growth over time. Especially as new chemistries (silicon anode) present new swelling concerns, it would be good to have a way to incorporate this type of data alongside the electrochemical time-series data.

I wouldn’t want to limit this just thickness measurements as each industry and chemistry have their own challenges and metrics that they would like to track.

Initial thoughts on this implementation would likely require the JSON sidecar style metadata for a measurement type. The optional measurement that you would include would be defined in the JSON file to identify the “variableMeasured” with a “name” (that would align with the BDF column header) and “unitText” (which would also align with the BDF column header). Additional options would be to include description of the measurement.

These measurements may not be continuous throughout the testing, so the column would likely have a substantial amount of Null values.

For example, a common test in the consumer electronics industry is 1000 cycles at 100% depth of discharge. Every 100 cycles, the thickness of the pouch cell is measured with a parallel plate height gauge at 100% state of charge. The column in BDF would be “Thickness / mm” and the JSON sidecar for this custom measurement would likely include:

“variableMeasured”:

{

  "@type": "PropertyValue",

  "name": "Thickness",

  "unitText": "mm",

  "description": "parallel plate height gauge at max state of charge",

}

Thoughts? Would love to get outside perspective on this approach.

2

Hi Phil, sorry this sat so long.

I’ve been thinking about this and I think there are two parts to it.

The signal a fixture records during a test, displacement or expansion over time, sits alongside voltage and current the same way our temperature and pressure channels do. I couldn’t find a term for that in the ontology, so it could be a discussion worth having. @DrSimonClark, curious what you think there.

But thickness itself feels more like a cell parameter than a test measurement. The baseline dimension belongs with the cell, not in the time-series table. And that touches a bigger open question, how BDF handles cell and test metadata. A parallel metadata format has been on the roadmap since the beginning, and the early pieces are starting to move (#47 and #48 are the open discussions), so your use case would be good input while it’s still taking shape.

What does your setup export? Column names and units for the in-situ part, and where the baseline dimensions live today. That would help figure out where each piece belongs.