How Does Software Handle State of Health Data?

Software for state of health is the system that collects battery management data, calculates or records state of health and related performance and durability information, and carries the resulting fields into the passport record where Annex XIII requires them. State of health is information resulting from use, and it changes through the life of the battery, so the software must handle updates, versioning and access control for a field that is never finally settled while the battery remains in use. A static state of health value, recorded once at manufacture and never updated, will misstate the battery condition at every later life stage.

State of health work sits at the boundary between passport data and diagnostic data. The passport carries the summary and status fields that later actors need, while detailed diagnostic readings remain in workshop and fleet systems. Software must therefore decide, field by field, what belongs in the passport and what remains in the diagnostic system, and must implement the update route for the passport fields without copying the full diagnostic log into the passport. The boundary decision should be recorded in the data model, not left to individual operators.

What state of health fields does the passport carry?

State of health fields in the passport are the fields that Annex XIII and any applicable implementing or delegated act assign to the passport, concerning performance, durability and remaining capability as resulting from use. The fields are model and category specific, and they differ between electric vehicle, LMT and industrial batteries in presentation and in the access tier that applies. Software should implement the field set from the Annex XIII catalogue for the category, with the tier, the update rule and the source for each field, rather than implementing a generic health score that has no Annex XIII basis.

A field catalogue check should compare the software fields against the Annex XIII catalogue for the category, with each field marked as implemented, pending act detail or not applicable. A catalogue that implements a health score without an Annex XIII source creates a passport field that an authority cannot verify against the Regulation. A catalogue that omits a required field creates a gap that will be found at authority review. The catalogue should be version controlled and dated.

How is state of health measured and calculated?

State of health measurement uses battery management system data, test results and, where applicable, the performance and durability parameters set in the Regulation for the battery category. The measurement method, the test conditions and the calculation basis must be recorded with the value, because a state of health value without a method is not comparable across batteries or across time. A value calculated from a full discharge test, a value estimated from management system data and a value derived from a partial test are different evidence types, and the passport field should allow the method to be distinguished.

Worked check: two packs show the same state of health percentage. The first value comes from a full test under defined conditions, the second from a management system estimate with an unstated algorithm. A reader who treats the two values as equivalent will judge the packs as equal, when the evidence quality differs. The passport record should preserve the method distinction, so that the reader can judge the values on their evidence, not on the percentage alone.

How are state of health updates managed?

State of health updates are managed as versioned changes to the passport field, with the old value preserved in the audit trail, the new value recorded with its method and date, and the actor who introduced the update identified. Updates should occur at defined events, such as repair, inspection, life stage change or periodic assessment where the rules require it, rather than continuously on every charge or discharge. Continuous updating would create a record that changes faster than it can be verified, and would expose diagnostic detail that the passport is not designed to carry.

Update events should be defined in the software workflow, with a trigger list, a responsible role and a verification step for each event. A trigger list that is too broad will flood the passport with updates. A trigger list that is too narrow will leave the passport stale at a life stage change. The trigger list should be reviewed after the first months of operation, with the review recorded, so that the update pattern matches the actual life stage events for the battery category.

How is state of health data accessed by later actors?

State of health data are accessed by later actors under the Annex XIII tiers, with repairers, recyclers, repurposers and authorities receiving the fields assigned to their tier. A buyer of a used battery, a repairer assessing a pack and a recycler routing a pack each need the state of health field, but they need it with different accompanying detail and under different access rights. Software must generate the tier appropriate view for each actor from the same source record, without creating separate copies of the health data that can diverge.

Access testing should be carried out for each actor type on the same battery, with the returned fields compared against the tier map. A test that checks only one actor type misses a tier error for another type. A test that checks the source record only, without checking the generated views, misses a view generation error. The combined test, source plus views, is the access evidence for state of health data.

What limits apply to state of health claims?

State of health claims in the passport are limited to the fields and methods defined in Annex XIII and the applicable acts. A state of health value does not certify remaining life in a particular pattern of use, range in a particular vehicle, or fitness for a particular second life application, unless the method and the application threshold are stated. A claim that presents a health percentage as a guarantee of remaining life, without method and threshold, overstates what the field proves. Marketing and sales material must not present the passport health field as a guarantee that the passport does not provide.

Claim control should separate the passport field, the professional assessment and the sales description into three documents with separate review. A sales description that copies the passport percentage without the method, or a professional assessment that is presented as a passport field, merges documents that should remain separate. The separation should be checked before sale, with the three documents compared for consistency and for the limits stated in each.

How is state of health history preserved?

State of health history is preserved through the audit trail, which records each update with its method, date and actor, and through the linkage to the original passport where a life stage change creates a new record. History must remain available to authorities and to legitimate interest actors under the tier rules, even after the battery changes life stage or the responsible operator changes. As checked on 28 October 2026, the detailed updating rules depend in part on acts under Article 77, so the history design should carry a review date. This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting.

This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting. State of health is a versioned field with a method, and the history should remain available through life stage changes.