RefBESS-250MW: A Synthetic Reference Battery Storage Architecture

J. McKenney

This document sits in Eigenia working group WG-05-CAD, Unified Asset Graph, and is the synthetic reference asset of the three-schema programme rather than one of its arguments. P1 defines the three-identity join between DEXPI 2.0, CycloneDX 1.6 and IEC 61970 CIM, P2 defines the CIM profile that join uses, and P3 gives the conformance suite and test vectors. The applied papers compute against the site specified here, and two of them carry the join into harder domains: a pharmaceutical plant whose electrical leg is thin by construction, and a rail depot where the process and electrical domains split apart. This document states no requirements and owns no rule numbers.

Licence: CC BY 4.0. 17 August 2026.

Executive Abstract#

Every paper in this programme computes against something. If each invents its own example, no two results compare and no reader can check the arithmetic. This document fixes one target: a grid-scale battery storage site of 250 megawatts and 500 megawatt hours, lithium iron phosphate, connected at 220 kilovolts, with a central liquid cooling plant, a layered control stack and a site substation.

A battery site was chosen because the programme claims three standards join on one object, and most assets are lopsided: a distribution network is rich electrically and thin on process, a software platform lives in the component standard alone. A grid-scale battery site is a process plant and a substation at once, its pumps, firmware and switchgear each answering to a different standard; a join shown on an asset with one thin leg proves nothing. Every number says where it came from, sourced or modeled: of thirty-two site parameters, thirteen are sourced and nineteen modeled; of seventeen thermal parameters, one is sourced.

Two features are deliberate awkwardness. One dosing pump carries a process and an electrical identity but no software identity, having no firmware; and the three legs are dated differently on purpose, so the join treats divergent dating as legitimate. Omissions are by decision: no electrical quantities, no measurement objects, no dynamics, no network past the connection point. No such site exists, the thermal chain is unverified, the electrical leg reaches L4 by construction, and the reference data classes are named in words rather than resolved to identifiers.

Abstract#

RefBESS-250MW is a synthetic transmission-connected lithium iron phosphate storage site of 250 MW and 500 MWh, a fixed computation target for the applied papers of the three-schema programme. It is not a design, a validation, or a reuse of the distribution-network asset, whose process leg is thin by construction. It assigns identities, not semantics; relations and conformance stay in P1 and the CIM profile in P2. The site carries a DEXPI 2.0 process leg of one hundred tagged objects across a two-loop thermal plant sized to an 8.0 MW rejection duty, a CycloneDX 1.6 component leg of six per-unit documents with no merged bill of materials, and a CPAI-profiled IEC 61970-301 electrical leg carrying shape without quantity. Ten objects carry all three identities; one carries two legs, and the three as-built bases carry three dates, on purpose. Nothing has been tested against a real export; the thermal parameters are unverified; the electrical leg reaches L4 by construction; and the ISO 15926-4 classes are named in words rather than resolved to identifiers, a defect it records against itself.

1. Scope, and what RefBESS-250MW supplies#

RefBESS-250MW is a synthetic grid-scale battery energy storage site, specified once so the applied papers of this programme compute against a fixed target. It is a 250 MW, 500 MWh lithium iron phosphate installation connected at 220 kV, with a centralized liquid cooling plant, a layered control stack and a site substation.

It exists because the three-identity join needs an object all three standards can name. A distribution network satisfies the electrical leg richly and the process leg barely, because a network is not a P&ID. A software platform satisfies the component leg and neither of the others. A grid-scale battery site is a plant and a substation at once: pumps, heat exchangers, valves and instrumentation that DEXPI 2.0 [5] describes; battery management firmware, converter control software and an energy management platform that CycloneDX 1.6 [6] describes; transformers, switchgear and a coupling point that the IEC 61970 Common Information Model [7] describes. A join demonstrated on an asset with a thin leg proves nothing, so this site is specified where all three speak about one object.

1.1 What RefBESS-250MW is, and how to read its numbers#

RefBESS-250MW is a fixed synthetic target that the applied papers of this programme compute against. What a reader takes from it is a site whose three legs are all specified to the same depth, so that a join result is a statement about the join rather than about an accident of one leg's richness. Four statements fix that reading.

It is a modeled site with a modeled operator. Every parameter here is specified by this document rather than measured on an installation, every vendor named in section 4 is a synthetic name, and every package URL and master resource identifier here is minted for this document. The Basis column on every table says whether a number is Sourced or modeled.

It is specified afresh, and it shares a 50 Hz system context with RefDNSP-1.2M [8]. That asset is a 1.2 million customer distribution network whose process leg is thin by construction, which is right for what it supports and wrong for what the three-schema papers need. The shared system context is the whole of what the two have in common, and it is enough for a later paper to connect one to the other. Every other parameter here is this document's own.

It is a specification of an instance, written to be computed against. A design carries vendor selections, calculation sheets and a hazard study, and it is a project's work. Every figure here is a modeled figure, and running it against a real DEXPI file, CycloneDX document or CIM export is the step that would make it a measured one. Section 3 gives a thermal plant to compute against, and plant that gets built is built from a design.

The join semantics are P1's and P2's, and this document assigns identities under them. Relations, attribute names, traversal rules and conformance sit in P1 [2] and the CIM profile in P2 [3]. This document assigns identities under those rules and takes their definitions from P1 and P2 as they stand.

2. Site parameters#

Every row states whether its value was taken from a published source or chosen. A value chosen inside a published range is modeled, and the range is named so a reader sees how much freedom the choice had.

Thirteen of the thirty-two rows are sourced and nineteen are modeled, the honest ratio for a synthetic asset. The three as-built dates differ because P1 R-8 treats a divergent basis set as legitimate and conformant rather than an error to be tidied away [2].

3. The process leg: thermal management#

A 250 MW battery site rejects heat continuously while it works and the cells tolerate only a narrow band [12]. Thermal management is therefore a process plant with a coolant inventory, rotating equipment, heat transfer surface, valves and instrumentation. It is the part of a battery site a P&ID describes, and it is why RefBESS-250MW can carry a DEXPI leg at all.

The architecture is two loops. A primary chilled water loop runs between water-cooled chiller packages and their heat rejection. A secondary glycol and water loop feeds the ten blocks, separated by plate heat exchangers so a field leak does not contaminate the chiller circuit. Each block takes flow through a modulating three-way valve controlled on its return temperature.

3.1 Thermal design parameters#

Sixteen of the seventeen rows are modeled and one is sourced. Every derived row recomputes from the rows above it. That is why the assumed specific heat and efficiencies are printed rather than only the answers: a reader who disagrees with 96 percent can rerun the arithmetic instead of arguing with a number that arrived from nowhere.

3.2 Tagged objects#

One hundred objects carry a TagName in the DEXPI leg. The tag block is modeled site convention: 11xx circulation, 12xx heat transfer, 13xx refrigeration and heat rejection, 14xx coolant inventory, 15xx block distribution.

P1 R-18 requires the ISO 15926-4 class to travel with the tag, because a tag alone is scoped to one plant and one discipline [2], [16]. The Class column is descriptive rather than a resolved reference data library identifier, a defect section 8 records against this document rather than the approach.

3.3 Why the control valves matter more than the pumps#

The instrument set is where P1's relation vocabulary earns its keep. TT-1541 observes the return temperature of block 1 and commands nothing, so it carries monitors. TCV-1501 moves metal in response and carries controls. Both sit on the same field network and in the same bill of materials, and only the declared relation separates a falsified reading from a coolant flow an attacker can close. P1 R-13 forbids traversing one as the other [2].

4. The component leg: the control stack#

The site carries six CycloneDX 1.6 documents, one per deliverable unit, each produced by the build system that assembles it. There is no merged site bill of materials, for the reason P1 gives for having no central join registry: a merge reintroduces a single authority and hides which build system vouched for which claim.

Vendor identifiers below are synthetic: namespaces prefixed example-, registry hosts under example.org, reserved for documentation and unregistrable [20]. No package URL here resolves.

Two properties of this leg drive what the applied papers can do with it.

It is the volatile leg. A firmware upgrade mints a new package URL, correctly, because it is a different artifact. P1 R-12 and R-15 exist for this [2]. The site is specified with versions rather than ranges, and an applied paper modeling an upgrade must mint new identities and say so.

Not every component has a package URL. The network switch is hardware and carries a CPE instead [21]. That is not an edge case here; the switchgear, transformers and enclosures all sit in this category. A bill of materials reporting only what has a package coordinate reports the software and calls it the asset.

4.1 Where the component leg attaches#

Firmware is a constituent, not the asset. Every component above carries partOf toward the object it runs inside, with two exceptions. The site controller carries controls toward the ten block asset references because it dispatches them, and the thermal plant controller carries controls toward the ten control valves and monitors toward the block instruments. Those assignments decide whether a site controller compromise reaches the blocks in the graph or silently does not.

5. The electrical leg: connection and protection#

The electrical leg is a CPAI document, the cyber-physical profile of IEC 61970-301 defined in P2 [3]. CPAI admits shape and refuses quantity, so nothing below carries an impedance, a rating, a tap position or a solved voltage.

Instance counts are modeled and follow from section 2: one 220 kV line bay, two 220 kV transformer bays, ten 33 kV block feeder bays, two auxiliary transformer bays and eleven 415 V auxiliary bays, each with a breaker and a protection device. Transformers are two main, ten block and two auxiliary units.

5.1 Completeness level reached#

CPAI degrades by completeness level and requires the producer to declare it rather than let a consumer guess [3]. This site reaches L4, the highest level P2 section 7 defines.

L4 is what makes this architecture worth specifying rather than assuming. It is the level at which a cyber event traces to a physical action, because the profile can answer what removes supply from an asset and whether that device appears in a bill of materials. Here it does: PROT-415-A01 is a CIM ProtectionEquipment instance and pkg:generic/example-protection/feeder-relay@1.9.2 is a CycloneDX component, and they are one device.

5.2 Two places where CPAI does not fit a battery site#

A reference architecture that hides where its profile strains is not doing its job.

CPAI admits no class for a grid-forming converter. P2 excludes the direct current and converter classes of the wires package, on the ground that no join question yet distinguishes an AC from a DC supply path, and its own limitations record that grid-scale storage weakens that exclusion every year [3]. This site hits the gap directly. The fifty converters are its defining electrical devices, they carry firmware, and CPAI has nowhere to put them except ConductingEquipment, which loses the fact that they are converters. They are carried there and the loss is flagged. P2's next revision should admit the converter classes.

CPAI defers Feeder. P2 could not confirm the class name against the published UML and refused to admit a class it cannot name [3]. The ten block circuits are what an operator would call feeders. They are carried as Bay inside VL-33, which is traversable and is not what the objects are called on site.

6. Identity assignment across the three legs#

A three-way join that cannot be demonstrated on one physical object is a diagram, not a mechanism. This section is why the document exists.

6.1 How many objects carry all three identities#

Ten objects carry a TagName, a package URL for the software inside them, and an mRID for their electrical position: four circulation pumps, three chiller packages, three air cooled condensers. Each is a P&ID object, runs firmware, and is an electrical load with its own bay, breaker and protection device.

The glycol dosing pump P-1403 is the deliberate counter-example. It is a tagged process object and an electrical load, started direct on line with no firmware, so it carries a DEXPI leg and a CIM leg and no CycloneDX leg. P1 R-12 and P2 C-9 both bear on it: a consumer must accept the two-leg join and must not synthesize the third [2], [3]. A reference architecture where every object carries three legs would let an implementation pass without exercising that rule.

6.2 The object carrying all three identities#

Pump P-1101A, one of the four secondary coolant circulation pumps. Its asset reference 09a66af0-8c96-4ed1-b2f2-fb9f0e5c8524 is minted once by the plant model authority and appears unchanged in all three files.

DEXPI leg, on the equipment object that carries the tag, per P1 R-17:

<Equipment ID="EQ-P-1101A">
  <TagName>P-1101A</TagName>
  <GenericAttributes Set="AssetJoin">
    <GenericAttribute Name="AssetReference"
                      Value="09a66af0-8c96-4ed1-b2f2-fb9f0e5c8524"/>
    <GenericAttribute Name="AssetReferenceRelation" Value="identity"/>
    <GenericAttribute Name="AssetReferenceAuthority"
                      Value="https://example.org/authority/refbess-plant"/>
    <GenericAttribute Name="AssetReferenceBasis"
                      Value="PID-RB-COOL-101 rev C 2026-08-14"/>
  </GenericAttributes>
</Equipment>

CycloneDX 1.6 leg, on the variable speed drive firmware inside the pump's drive, in BOM-RB-THM:

{
  "type": "firmware",
  "bom-ref": "pkg:generic/example-automation/vsd-firmware@7.2.1",
  "name": "vsd-firmware",
  "version": "7.2.1",
  "purl": "pkg:generic/example-automation/vsd-firmware@7.2.1",
  "properties": [
    { "name": "assetjoin:ref",
      "value": "09a66af0-8c96-4ed1-b2f2-fb9f0e5c8524" },
    { "name": "assetjoin:relation", "value": "partOf" },
    { "name": "assetjoin:authority",
      "value": "https://example.org/authority/refbess-build" },
    { "name": "assetjoin:basis", "value": "BUILD-RB-2026-0831 2026-08-31" }
  ]
}

CPAI leg, on the EnergyConsumer that represents the pump motor as a load, per P2 C-2 and C-3:

cim:EnergyConsumer
  cim:IdentifiedObject.mRID      "0dae4314-dc30-454e-8dd1-5849dee9dcc1"
  cim:IdentifiedObject.name      "EC-AUX-P1101A"
  join:assetReference            "09a66af0-8c96-4ed1-b2f2-fb9f0e5c8524"
  join:relation                  "identity"
  join:authority                 "https://example.org/authority/refbess-network"
  join:basis                     "NM-RB-EXPORT-2026-Q3 2026-08-20"
  join:modelAuthoritySet         "https://example.org/mas/refbess-network"

Three files, one asset reference. A TagName a plant engineer wrote, a package URL a build system minted, an mRID a network model tool assigned. None touched, none promoted over the others.

6.3 The L4 chain that hangs off it#

L4's value is what the CIM leg makes traversable from that one binding, using only associations CPAI admits and the document declares, as P2 C-8 requires:

PROT-415-A01 runs firmware and appears in BOM-RB-PRO, so the traversal closes. A disclosure against that relay firmware reaches, in declared hops and no inference, the breaker that feeds the pump that circulates the coolant that holds the cells inside the band of section 3. That is the chain the programme exists to make computable, and RefBESS-250MW is the smallest asset on which every hop is real.

6.4 Relation assignment across the site#

Nine assignments drawn from the five relations P1 permits, none invented. The vocabulary held on this site, one small piece of evidence that five is enough. P1 records the opposite risk and this document does not settle it.

7. What this reference architecture deliberately omits#

Each omission is a decision. This document is a target for analysis, not an analysis.

No quantities on the electrical leg. No impedance, admittance, rating, tap position, injection or solved voltage. CPAI excludes them, and a producer required to supply them supplies no CIM leg at all [3].

No measurement objects. The monitors relation sits in the monitoring device's own leg, with its firmware. Admitting CIM measurement classes would model one relationship twice with no rule for reconciling the two [3].

No IEC 61850 substation configuration file, and no geography. A battery site has an SCL file and it is a plausible fourth leg; P2 draws that boundary and this document does not cross it. Substation localizes every asset well enough for the questions the join asks.

No commercial model, cell data sheet or fire safety design. Cost, dispatch strategy, cycle life, C-rate limits and warranty terms change no identity, and inventing them would produce numbers that look measured. NFPA 855 is named as applicable [14] and deflagration venting, suppression and detection are out of scope; section 3 gives one modeled separation distance, not a code minimum.

No dynamics, and no network beyond the coupling point. Inertia emulation, droop settings and fault ride-through belong to a stability study on a timescale the join does not reach. The site stops at the 220 kV connection; attaching it to a wider network is a later paper's decision, and RefDNSP-1.2M is the obvious candidate [8].

8. Limitations#

RefBESS-250MW is a modeled reference site, and every figure here is computed over that model. Every modeled parameter was chosen by the author, and the sourced rows point at published standards and literature, not a survey of built plant. Section 2 represents nothing except itself.

The thermal parameters are internally consistent and unverified against a vendor design. The 8.0 MW duty follows from two assumed efficiencies, the flows from the duty and an assumed specific heat, the pump power from the flow and an assumed hydraulic efficiency. Change any assumption and the chain moves together, which makes it useful for a worked example and useless for procurement. No vendor has been asked whether 4.0 MW chiller packages exist in the configuration section 3 assumes.

The CIM leg reaches L4 by construction, not because a real export was inspected. The instance counts in section 5 were derived from the arrangement in section 2, not read out of a CIM RDF XML file. P2 states that nothing in CPAI has been tested against a real export [3]. This document supplies a target for that test, not the test.

A synthetic asset cannot show the join survives a real operator's naming discipline. Every tag follows one convention, every package URL is well formed, every mRID is a canonical UUID [22]. Real sites carry tags that changed when a contractor changed, components with no version string, and network models whose mRID values differ between exports of one circuit. The join's hard cases are in that gap and none appear here.

The ISO 15926-4 classes are described, not resolved. Section 3.2 names classes in words. P1 R-18 requires the reference data library class to travel with the tag [2], which needs a resolved identifier from ISO 15926-4 [16], and the authors do not hold the library. A defect in this document, correctable by substitution.

No package URL here resolves and none can be tested. Synthetic namespaces are right for a document that must not be mistaken for a real vendor's product [20], and the cost is that no tool can run against them. Jurisdiction is the same kind of limit: the 50 Hz rows are sourced to one frequency operating standard [9], and the claim that a 60 Hz site moves the electrical leg's parameters and none of its identities is made here and not tested.

Two CPAI classes carry objects they do not describe. Section 5.2 sets this out: converters as ConductingEquipment, block circuits as Bay. Both are findings against P2 rather than defects hidden in a table.

The three as-built dates demonstrate a problem, they do not resolve it. P1 R-8 makes basis divergence visible rather than removing it [2]. An applied paper computing against RefBESS-250MW inherits an inconsistent set and must say what it did about it.

9. References#

1. Creative Commons. Attribution 4.0 International (CC BY 4.0) Legal Code. Creative Commons Corporation, 2013.
2. McKenney, J. The Three-Identity Join: DEXPI 2.0, CycloneDX 1.6 and IEC 61970 CIM. P1 of the three-schema programme, Eigenia WG-05-CAD, 2026.
3. McKenney, J. CIM Profile for Cyber-Physical Asset Identity (CPAI). P2 of the three-schema programme, defining the profile and its completeness levels L0 to L4, Eigenia WG-05-CAD, 2026.
4. McKenney, J. Conformance Suite and Reference Implementation. P3 of the three-schema programme, Eigenia WG-05-CAD, 2026.
5. DEXPI e.V. DEXPI 2.0 Specification. Released 10 October 2025, published on GitLab under the Creative Commons Attribution 4.0 International licence.
6. OWASP Foundation and Ecma International. CycloneDX Bill of Materials Specification. ECMA-424, 1st edition, June 2024, defining CycloneDX 1.6. Ecma International Technical Committee 54.
7. International Electrotechnical Commission. IEC 61970-301: Energy management system application program interface (EMS-API), Part 301: Common information model (CIM) base.
8. McKenney, J. Cascading Failure Hypothesis. Eigenia WG-04-CF, 2026. Specifies RefDNSP-1.2M.
9. Australian Energy Market Commission, Reliability Panel. Frequency Operating Standard. In effect 9 October 2023. Sets nominal system frequency 50 Hz and a normal operating band of 49.85 Hz to 50.15 Hz.
10. International Energy Agency. Battery storage is scaling up and taking on a larger system role. IEA commentary, Paris. Reports utility-scale durations clustering in the one to four hour band, the commissioned average rising from about two hours in 2023 to about three in 2025.
11. International Organization for Standardization. ISO 668: Series 1 freight containers, Classification, dimensions and ratings.
12. Ma, S., Jiang, M., Tao, P., Song, C., Wu, J., Wang, J., Deng, T., and Shang, W. Temperature effect and thermal impact in lithium-ion batteries: A review. Progress in Natural Science: Materials International, vol. 28, no. 6, pp. 653 to 666, December 2018. Gives 15 °C to 35 °C as the band where cell performance is high and degradation moderate.
13. International Electrotechnical Commission. IEC 62933-5-2: Electrical energy storage (EES) systems, Part 5-2: Safety requirements for grid-integrated EES systems, Electrochemical-based systems. 2025 edition.
14. National Fire Protection Association. NFPA 855: Standard for the Installation of Stationary Energy Storage Systems. Cited for applicability only; no clause-level requirement here was verified against the standard text.
15. International Electrotechnical Commission. IEC 62443-3-3:2013: Industrial communication networks, Network and system security, Part 3-3: System security requirements and security levels. First edition, August 2013.
16. International Organization for Standardization. ISO/TS 15926-4: Integration of life-cycle data for process plants including oil and gas production facilities, Part 4: Core reference data. Technical Specification.
17. Ecma International. Package URL (purl) Specification. ECMA-427, 1st edition, December 2025. Ecma International Technical Committee 54.
18. International Electrotechnical Commission. IEC 61970-600-1:2021: Common Grid Model Exchange Standard (CGMES), Structure and rules. International Standard, edition 1.0, 4 June 2021, cancelling and replacing the 2017 Technical Specification of the same number.
19. International Electrotechnical Commission. IEC 61970-600-2:2021: Common Grid Model Exchange Standard (CGMES), Exchange profiles specification. International Standard, edition 1.0, 4 June 2021, cancelling and replacing the 2017 Technical Specification of the same number.
20. Eastlake, D. and Panitz, A. Reserved Top Level DNS Names. RFC 2606, BCP 32, Internet Engineering Task Force, June 1999. Reserves example.org for documentation use.
21. Cheikes, B. A., Waltermire, D., and Scarfone, K. Common Platform Enumeration: Naming Specification Version 2.3. NISTIR 7695, NIST, August 2011.
22. Davis, K., Peabody, B., and Leach, P. Universally Unique IDentifiers (UUIDs). RFC 9562, Internet Engineering Task Force, May 2024.