Battery Passport Static vs Dynamic Data: Ownership and Update Interfaces Across ESS Layers

Abstract

The split between “static data” and “dynamic data” in the battery passport data model looks like a classification of data characteristics, but mapped onto ESS system layers it functions as the boundary where data ownership and legal responsibility diverge. Regulation (EU) 2023/1542 places responsibility for the accuracy and up-to-dateness of passport information on the operator placing the battery on the market (usually the pack or system integrator), yet the 16 dynamic attributes (mandatory for the stationary category) are generated after placing on the market in the BMS and EMS run by the asset owner, and the BMS read access right under Article 14 is granted to the purchaser, not the integrator.

In an assumed scenario (200 MWh site, 3,828 packs), raw BMS data amounts to 50.2 TB/year while passport updates on an 86,400 s cycle amount to 5.72 GB/year, a reduction of about 8,775 times, so the bottleneck is not transfer volume but the inter-layer interface contract on who computes this reduction and who signs it.

1. Conclusion First — The Static/Dynamic Boundary Is an Ownership Boundary

Static passport data are fixed upstream (cell maker and integrator) before placing on the market, while dynamic data are generated downstream (asset operator) afterwards. Yet responsibility for the accuracy of both is tied to a single party, so the direction of responsibility runs opposite to the direction of data flow.

Situation (S): From 18 February 2027, industrial batteries above 2 kWh require a passport (Article 77(1)), and the operator placing them on the market must ensure the passport information is accurate, complete and up to date (Article 77(4)). Complication (C): The Battery Pass consortium and DIN DKE SPEC 99100^[1] divide attributes into static and dynamic, but leave the mandatory update interval of dynamic attributes as “subject to further elaboration by the European Commission”.

Question (Q): Among the cell maker’s MES^[2], the pack/system integrator and the BMS/EMS^[3] operator, who owns which data and at what interval must it be updated? Answer (A): Legal responsibility lies with the integrator and the physical source of dynamic data lies with the operator; unless written authorisation and ownership of the aggregation algorithm connecting them are fixed by contract, the passport loses its up-to-dateness from the moment of placing on the market.

This article does not address capture points inside the line. It analyses only data ownership and update interfaces between layers after placing on the market.

2. Mechanism — A Three-Layer Ownership and Update-Interval Matrix

In the Battery Pass data attribute longlist v1.2 (2025-01, aligned with DIN DKE SPEC 99100), the stationary >2 kWh category has 80 mandatory attributes: 64 static and 16 dynamic. All 16 dynamic attributes are classified at “individual battery” granularity, and the 15 other than battery status belong to the performance and durability category (remaining capacity, SoC, throughput, time spent in extreme temperatures, number of deep discharge events, accident information, etc.). Most static attributes are at “battery model” granularity.

Overlaying this classification onto layers yields an ownership map. Static model data (material composition, carbon footprint, recycled content) sit in upstream MES and ERP; static individual data (identifiers, manufacturing date) sit with the integrator; and dynamic data sit in the BMS. The Battery Pass Content Guidance likewise diagrams the flow as “static data within upstream organisations (ERP, MES)” versus “dynamic and static downstream data (e.g. from the BMS)”.

Layer	Main data	Static/dynamic	Legal basis	Physical source	Update trigger and interval
Cell maker MES/ERP	Material composition, upstream carbon footprint contribution, recycled content, cell grading data	Static (model)	Not a passport obligor when the pack is the unit placed on the market — provided via supply contract	Cell maker	On model, supplier or plant change (event)
Pack/system integrator (operator placing on the market)	Passport and battery identifiers, manufacturing date, rated performance, initial values of dynamic attributes	Static (individual and model) + dynamic initial values	Article 77(4) (accuracy responsibility), Article 78(c) (storage party)	Integrator MES and passport backend	At placing on the market + on status change
BMS	Annex VII parameters (remaining capacity, throughput, time in extreme temperatures, etc.)	Dynamic	Article 14(1) (stored in BMS), 14(2) (read-only access for purchaser)	Site BMS	Internal sampling 1 s (assumed); updated “at least daily” (Recital 46)
EMS/asset operator	Operating history, negative events such as accidents, date of putting into service	Dynamic	No explicit passport update obligation (holds access right as purchaser)	Operator EMS/SCADA	Operating-event based

The key to Table 1 is the “legal basis” column in the third and fourth rows. Article 14(2) grants read-only access to BMS data to “the natural or legal person who has legally purchased the battery” and parties acting on their behalf, but specifies no separate access right for the original operator that remains responsible for keeping the passport up to date. The provision in Article 77(4) that the operator “may give written authorisation to any other operator to act on its behalf” is the only textual channel that bridges this gap.

3. Calculation — Who Performs the Reduction Between 1 s and 86,400 s

The assumed scenario is a 200 MWh ESS site with 52.25 kWh packs (52 series cells of 314 Ah, 3.2 V), giving 3,828 packs and 199,056 cells. The BMS is assumed to record two channels per cell (voltage and temperature) on a 1 s cycle at 4 bytes per channel, and each of the 16 dynamic passport attributes is set at 256 bytes per data point (including value, unit, timestamp, originator and measurement-uncertainty metadata; assumed). DIN DKE SPEC 99100 recommends that performance and durability attributes be accompanied by metadata on date, originator, measurement uncertainty and test method.

Scenario	Update interval	Annual data points	Annual data volume	Remarks
A Raw BMS (baseline)	1 s	—	50.2 TB	Not passport data; 2 channels per cell
B Periodic passport update	86,400 s	22,355,520	5,723 MB	Applying the Recital 46 BMS up-to-dateness benchmark to the passport
C Low-frequency passport update	2,592,000 s (assumed)	734,976	188 MB	Based on slowly changing attributes such as remaining capacity
D Event-based update	At placing on the market and status change	122,496	31.4 MB	Assumes one placing + one status change

Compared with baseline A (50.2 TB), B is about 1/8,775; in other words, the passport is the product of reducing raw BMS data by a factor of 8,775. B’s site-wide write rate is only 3,828 × 16 ÷ 86,400 = 0.709 records/s, so communication bandwidth is not a constraint. The implication is clear: the quality of dynamic passport values is determined not by transmission but by the reduction algorithm (SoH^[4] estimation logic), and the layer that owns that algorithm effectively becomes the party that writes the passport.

This is where the ownership problem becomes concrete. The algorithm is usually held by the BMS supplier or the integrator, the input data sit at the operator’s site, and legal responsibility rests with the integrator. If the contractual role of any one of these three parties is left empty, the origin of passport values cannot be demonstrated under any of scenarios B, C or D.

4. Positions of the Data Models and Limits of Application

The three initiatives treat dynamic data at different depths. What they share is that none has fixed a mandatory update interval.

• DIN DKE SPEC 99100 (2025-02): Quotes the static/dynamic definitions from Delegated Regulation (EU) 2022/670 and notes for each dynamic attribute, such as remaining capacity, SoC and throughput, that “the mandatory required update interval is subject to further elaboration by the European Commission”. It also states that, per standardisation request M/579, dynamic data of batteries with a BMS must be determinable without external equipment.
• Battery Pass Content Guidance v1.1: Considers a blanket daily update to add no value for most attributes while increasing data and energy burdens, and recommends update rules per attribute based on use cases. For remaining power capability it recommends evaluation before a status change instead of continuous updating.
• GBA Battery Passport: Presented as a proof of concept in Davos on 18 January 2023, it centres on upstream static data such as benchmarks on 18 ESG issues and a greenhouse gas rulebook. Seventeen consortia are participating in the 2026 Operational Trials, and full launch is targeted for 2027.

There are limits of application as well. As of September 2026 the Article 77(9) implementing act (access scope for persons with a legitimate interest) has not been adopted, so the access scope of operators and re-use businesses is not fixed (verification required). The figures in Table 2 rest on the simplification of two channels per cell at 4 bytes, so baseline A can vary greatly depending on the compression and event-logging schemes of actual BMSs.

That BMS, PCS and EMS operate at different control speeds was covered in the speed differences across the BMS, PCS and EMS layers. This article takes a different angle. Rather than control-loop speed, it analyses the legal and contractual interface of who owns the data and who signs it, combined with update intervals.

5. Conclusion and Implications

The static/dynamic split does not end as an IT design term. Static data must be pulled from upstream by supply contract before placing on the market, and dynamic data must be pulled from downstream by authorisation contract afterwards. What the integrator needs to prepare is not bandwidth but two contractual interfaces (cell maker ← static, operator → dynamic) and one clause on algorithm ownership.

The structural conclusion of this analysis (responsibility and data flow run in opposite directions) is derived directly from the regulation text and is independent of the scenario assumptions. However, reduction ratios such as 8,775 times are outputs of an assumed scenario, and pilot-site results cannot be transferred 1:1 to large sites, so further verification is required.

FAQ

Q. Wouldn’t the problem be solved if the operator uploaded data directly from the EMS to the passport backend?
A. Not under the text as it stands. Article 78(c) requires passport data to be stored by the responsible operator or operators authorised to act on its behalf, and Article 78(f) restricts rights to introduce and modify information according to access rights. For the operator to write directly, written authorisation under Article 77(4) must come first, and that authorisation should specify the update interval and the calculation method.

Q. Recital 46 calls for updating “at least daily”, so why not simply set the passport to an 86,400 s cycle?
A. The Recital 46 benchmark concerns data held in the BMS under Article 14, and the definition of “up to date” for the passport has not yet been specified by a delegated act. Applying it as in scenario B of Table 2 keeps the data volume (5,723 MB/year) manageable, but the Battery Pass guidance does not recommend a blanket daily update, so per-attribute interval design comes first.

Field Application Notes

The items below can be executed on Monday morning.

Check	How to execute	Remarks
☐ Tag the source layer of the 16 dynamic attributes	For each dynamic row in longlist v1.2, add three columns: source (BMS/EMS/manual), owner of the calculation algorithm, and signing party	Every blank cell is a contract gap
☐ Review data clauses in supply contracts	Check whether cell maker contracts specify the delivery format for material composition, carbon footprint and recycled content, and triggers for change notification	Include whether notification is required on model or plant changes
☐ Draft a written authorisation with the operator	On the basis of Article 77(4), specify the update interval (s), calculation method and metadata requirements (time, originator, uncertainty)	Revisit access scope after the Article 77(9) implementing act is adopted
☐ Measure BMS logging interval and format	Measure the number of cell channels, logging interval (s) and byte size of the site BMS and recalculate baseline A in Table 2	Check compression and event-logging schemes
☐ Define the transfer procedure for re-use and repurposing	Document how the existing passport is linked and how dynamic history is handed over when responsibility transfers under Article 77(7)	Issuer of the new passport and history retention scope require verification

---

Footnotes
[1] DIN DKE SPEC 99100: Specification “Requirements for data attributes of the battery passport” published by Germany’s DIN and DKE in February 2025. It defines static data as data that do not change often or on a regular basis, and dynamic data as data that do (quoting Delegated Regulation (EU) 2022/670).
[2] MES (Manufacturing Execution System): The manufacturing execution system that manages process execution, history and quality data.
[3] BMS/EMS (Battery Management System/Energy Management System): Respectively, the battery state monitoring and protection layer and the site-level charge/discharge operation layer.
[4] SoH (State of Health): The current performance state of a battery relative to its initial state. For stationary ESS it is judged from the Annex VII Part A parameters: remaining capacity, remaining power capability, remaining round trip efficiency, evolution of self-discharging rates and ohmic resistance.

Sources: Regulation (EU) 2023/1542 (Articles 14, 77, 78; Recital 46; Annexes VII, XIII), EUR-Lex, 2023-07-28, https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng / DIN Media, “DIN DKE SPEC 99100:2025-02 Requirements for data attributes of the battery passport”, https://www.dinmedia.de/en/technical-rule/din-dke-spec-99100/385692321 / VDE, “Path Cleared for the Battery Passport”, 2025-01-15, https://www.vde.com/en/press/press-releases/din-dke-spec-99100-battery-pass / Battery Pass consortium, “Battery Passport Content Guidance v1.1”, 2023, https://thebatterypass.eu/assets/images/content-guidance/pdf/2023_Battery_Passport_Content_Guidance.pdf / Battery Pass consortium, “Battery Passport Data Attribute Longlist v1.2” and BatteryPassDataModel, 2025-01, https://github.com/batterypass/BatteryPassDataModel / Global Battery Alliance, “Global Battery Alliance Launches World’s First Battery Passport Proof of Concept”, 2023-01-18, https://www.globalbattery.org/press-releases/global-battery-alliance-launches-world%E2%80%99s-first-battery-passport-proof-of-concept/ / Global Battery Alliance, “Battery Passport”, accessed 2026, https://www.globalbattery.org/battery-passport/ / EU Digital Product Passport (secondary reporting), “Battery passport access rights: the Article 77(9) implementing act missed its 18 August 2026 deadline”, 2026-09-08, https://eudigitalproductpassport.org/updates/battery-passport-access-rights-implementing-act-delay

Measurement & Calculation Conditions: Site size 200 MWh, 52.25 kWh packs (52 series cells of 314 Ah, 3.2 V), 3,828 packs and 199,056 cells, BMS logging of 2 channels per cell at 1 s and 4 bytes per channel, 256 bytes per passport data point, low-frequency update interval of 2,592,000 s and two event-based updates are all assumed values. Conversions use 31,536,000 s per year, 1 MB = 10⁶ bytes and 1 TB = 10¹² bytes. The 16 dynamic attributes are based on the mandatory “Stationary >2kWh” column of the Battery Pass longlist v1.2 and may change with delegated and implementing acts. Field verification under actual site conditions is required.