Diagnostics fields in a BESS passport record state what a battery energy storage system recorded about its own condition, which part of the system issued the record, and which evidence file supports each entry, for a stationary battery system within the passport scope of Regulation (EU) 2023/1542. The record applies to the system as installed and as identified in the passport, and the governing condition is the current Regulation text together with any applicable delegated or implementing act in force at the date of the entry. A diagnostics entry is a dated statement of a recorded event, not a judgement about the cause of the event and not a replacement for a linked diagnostic log held outside the passport.
Diagnostics data means the fault codes, alarm entries, sensor readings, and diagnostic evidence that a battery management system or a connected monitoring system generated during operation, together with the identifiers, dates, methods, and sources needed to trace each entry back to its source file. The scope of this guide is the record of those fields: what belongs in the passport record, what belongs in a linked file, and what evidence supports each field. This guide does not cover diagnostic procedures, fault finding, repair methods, or any decision about whether a particular battery is safe to operate, and it does not explain how to diagnose a fault.
What counts as a diagnostics field in a passport record?
A diagnostics field counts as a passport record field when a later reader needs it to understand what was recorded, when it was recorded, and where the supporting evidence sits. A field with no date, no source, and no link to a system identifier does not meet that test. The passport record therefore holds summary fields and trace fields, while the full diagnostic log stays in a linked file under version control. Each summary field names its source, its date, and its owner, so a maintenance entry, a performance entry, and a diagnostics entry refer to the same system and the same period.
| Diagnostics field | Entry content | Evidence check |
|---|---|---|
| Event identifier | Unique identifier as issued by the source system | Matches the linked log entry |
| Event date and time | Date and time as recorded, with the time basis stated | Timestamp matches the linked log entry |
| Source location | Rack, string, module, or sensor position as stated | Location matches the system layout on file |
| Fault or alarm code | Code exactly as issued, with a definition reference | Code definition file is named and dated |
| Recorded severity | Severity or class exactly as recorded by the source system | Class matches the source system definition |
| Affected function | Function named in the source record | Function name matches the source record |
| Sensor channel | Channel or signal name as stated in the source record | Channel name matches the linked log |
| Threshold stated | Threshold or limit stated in the source documentation | Threshold document is named and dated |
| Recorded reading | Reading as recorded, with unit, method, and date stated | Reading matches the linked log entry |
| Linked evidence | File reference, version, and date for the linked log | Reference resolves to a dated file |
| Entry status | Status as recorded, such as open, cleared, or unresolved | Status change carries a date and a named role |
| Gap note | Note where a field is missing, with an owner and a review date | Gap note is dated and assigned |
How does a diagnostics field differ from a performance field or a maintenance entry?
A diagnostics field differs from a performance field by its object. A performance field states capacity, power, efficiency, or durability under stated conditions over a stated period. A diagnostics field states an event: a code issued, an alarm raised, or a threshold crossed, at a stated date and time. A diagnostics field also differs from a maintenance entry by its author: a maintenance entry records an action taken by a named role on a stated date, while a diagnostics entry records what the system itself generated, before any action. The link between the two entries is a shared identifier and a shared date sequence.
Which diagnostics fields belong in the passport record itself and which belong in a linked file?
The passport record itself holds the summary that a later reader needs without opening a full log: the event identifier, the event date and time, the source location, the fault or alarm code with its definition reference, the recorded severity, the affected function, the linked evidence reference, the entry status, and any gap note. The linked file holds the detail: the full log extract, the surrounding sensor readings with units, methods, and dates, the code definition document, and the threshold document. The linked file is named by reference, version, and date, and the reference must resolve to a dated file. The Regulation text as checked for this guide gives no standalone list of diagnostics fields for a BESS passport record, so the check method is the trace test: every field must name a source, a date, and a linked evidence reference, and every field that cannot meet that test must appear as a dated gap.
How is a diagnostic event entry written so a later reader can trace it?
A diagnostic event entry is written as a single dated record with one identifier, one source location, one code, and one linked evidence reference, and the entry keeps its original date even when its status later changes. A status change is a new dated line under the same identifier, naming the role that recorded the change and the date of the change, so the history of the event stays visible. An entry edited in place, with the original code or date overwritten and no version note, breaks the trace. A worked record below shows the form of one entry. All values in the worked record are illustrative placeholders, not measurements from a real battery, and the worked record uses no real fault code, no real reading, and no real system identifier.
| Worked record field | Illustrative entry |
|---|---|
| Event identifier | ILLUSTRATIVE-EVENT-IDENTIFIER |
| Event date and time | Illustrative date and time as recorded, with the time basis stated |
| Source location | Illustrative rack and string position as stated in the source record |
| Fault or alarm code | ILLUSTRATIVE-CODE, with the definition file named and dated |
| Recorded severity | Illustrative severity class exactly as recorded by the source system |
| Affected function | Illustrative monitoring function named in the source record |
| Sensor channel | Illustrative channel name as stated in the source record |
| Threshold stated | Illustrative threshold as stated in the source documentation |
| Recorded reading | Illustrative reading, with unit, method, and date stated |
| Linked evidence | Illustrative file reference, version, and date |
| Entry status | Illustrative status as recorded, with later changes as new dated lines |
| Gap note | Illustrative gap note where a field is missing, with an owner and a review date |
What evidence supports each diagnostics field?
Evidence for a diagnostics field is a dated file that a later reader can open and compare with the passport entry. A code needs a code definition document, because a code without a definition cannot be interpreted. A threshold needs a threshold document, because a reading outside a limit means nothing without the limit, the method, and the date of the document that states the limit. A reading needs a log extract, because a summary value without a log extract cannot be checked against the source system. A status change needs a dated line naming the role that recorded the change. A diagnostic report that accompanies an event is filed as linked evidence, not as a replacement for the fields above.
| Field group | Evidence on file | Check |
|---|---|---|
| Identity and timing | Linked log extract, with identifier and timestamp | Identifier and timestamp match the passport entry |
| Code and severity | Code definition document, dated | Definition matches the code exactly as issued |
| Location and function | System layout on file | Location and function match the source record |
| Reading and threshold | Log extract with unit and method, plus threshold document | Reading, unit, method, and threshold match the entry |
| Source and trace | Source system name, file reference, version, and date | Reference resolves to a dated file on record |
| Status history | Dated status lines, each naming the recording role | Sequence matches the event history |
How are repeated, cleared, and unresolved diagnostic entries handled?
Repeated entries are handled as separate events under separate identifiers when the source system issues them separately, with each entry carrying its own date and time, even when the code and the source location repeat. A repeated code is not merged into a single entry, because merging hides the frequency of the events and breaks the date sequence. A cleared entry keeps its original identifier, code, and date, and the clearance appears as a new dated line naming the role that recorded the clearance. Clearance is a record status, not a finding about the underlying system. An unresolved entry stays open with its original date, its latest status line, and a review date, and the record never closes an unresolved entry by silence or by omission. A superseded entry follows the same method: the original entry stays on file, and a dated note links the two identifiers.
What gaps and limits must the record show?
A diagnostics record must show its gaps as plainly as its entries, because a gap that is hidden reads as completeness to a later reader. Common gaps include a log extract that covers only part of the operating period, a code issued without a definition document on file, a threshold stated without a dated source document, a reading recorded without a unit or without a method, a linked file reference that no longer resolves, and a status line recorded without a named role or without a date. Each gap gets a dated note, an owner, and a review date, and the gap note states what is missing and which file should supply it, rather than offering a substitute value. The summary covers only the period for which linked evidence is on file, and the record states that period plainly, with start and end dates as recorded.
How does diagnostics evidence relate to state of health, performance, safety, and maintenance records?
Diagnostics evidence relates to state of health records by timing and by source location, not by substitution. A state of health entry states capacity or condition at a stated date under a stated method, while a diagnostics entry states an event at a stated date and time from a stated source location, and a later reader may compare the two sequences by date and by location. Diagnostics evidence relates to performance records in the same way: a performance trend shows change under a consistent method over a stated period, and a diagnostics sequence shows events within that period. Diagnostics evidence relates to safety and fire information by the affected function named in the entry, while the safety record states the safety tests, instructions, and handover that apply. Diagnostics evidence relates to maintenance records by the shared identifier and date sequence described earlier in this guide.
General educational information only is the limit of this guide, and this guide is not individual legal advice for any specific battery, system, or decision. Before acting on a specific battery or decision, check the current Regulation text and any applicable delegated or implementing act, confirm the passport scope for the system category, and confirm each diagnostics field against its linked evidence file, its code definition, and its threshold document as dated on file.
Sources & further reading
Source links point to primary materials and further reading, including commercial implementation resources where cited. This introductory guide does not replace the legislation.