From 18 February 2027, any battery in electric vehicles, light means of transportation, and industrial applications above 2 kWh placed on the EU market will require a digital product passport (DPP). The EU Battery Regulation defines the specific data to be included for batteries, and the CEN/CENELEC Joint Technical Committee 24 (JTC-24) standards specify the technical framework covering all aspects of the DPP ecosystem. They address:
- data exchange protocols,
- unique identifiers and their formats,
- data carriers (like QR codes),
- data storage and archiving,
- application programming interfaces (APIs),
- system interoperability,
- access rights management and security,
- data authentication and integrity.
Together, these provide essential guidance for building compliant DPP-systems.
To illustrate what the standards define, consider application programming interfaces. An API is an interface that enables communication and data exchange between different software systems – for instance, between economic operators’ systems and service providers’ systems. APIs can also define access points for third parties’, such as a market surveillance authority, to retrieve digital product passport information. The JTC-24 standards specify the operations these APIs must support, such as creating, reading, updating and deleting digital product passports. By standardizing these interfaces, it is ensured that all actors in the ecosystem can exchange data reliably, regardless of the specific software implementation each organization uses.
While the standards define these interfaces and their core requirements, they naturally focus on what DPP-systems must achieve rather than prescribing how every implementation detail should be handled. This allows flexibility for different technical approaches in areas like error handling, response time management, concurrent data access, and backup processes, while ensuring consistent interoperability and compliance. Within that framework, developers need to make informed choices about DPP-system behavior in various real-world scenarios.
This is where the BatteryPass-Ready project provides the necessary support. We are developing a testing environment that shifts the focus from abstract compliance to practical robustness. Through systematic testing of success and failure scenarios within the DPP ecosystem, economic operators can understand how their systems respond to various situations, calibrate their implementations accordingly, and gain confidence that their systems are ready for production.
From Technical Requirements to Testable Scenarios
To bridge the gap between standards and implementation, we’ve developed a systematic methodology that translates normative requirements into testable scenarios. The core of this approach are user stories describing realistic business processes, while incorporating the technical and implementation requirements. „Placing the battery on the market“, for example, covers the registration process and making the DPP available for other actors of the DPP ecosystem. Other examples for user stories are „Updating Battery Passport data“ or “Reading access-restricted and public Battery Passport data“.
Certain aspects of system behavior are not fully specified by standards and regulations and may therefore be open to interpretation. To operationalize these requirements, assumptions are defined for each user story, which will be disclosed together with their origin. These assumptions form the foundation of our test scenarios and are continuously refined through feedback from economic operators and other stakeholders, or revisited as new standards are released or existing ones are revised. This iterative approach ensures that our testing methodology remains aligned with evolving regulatory requirements.
Each user story represents a process that must work reliably when DPPs become mandatory in February 2027. A systematic step-by-step analysis identifies all interaction points, dependencies, and decision nodes, that define expected system behavior. This creates a comprehensive map of what needs to be tested.
Our approach defines user stories from a technical and implementation point of view, informed by both regulatory requirements and practical input from supporting partners. The question we pose is: Which scenarios must be tested and validated to ensure that economic operators are adequately prepared for the mandatory battery passport implementation?
To answer this question, our methodology follows five steps:
- Extract regulatory requirements from standards and regulations
- Map actor roles to functional responsibilities to form user stories
- Define testable scenarios for each user story
- Develop realistic end-to-end failure scenarios
- Generate executable test procedures for both success and failure scenarios
To support this methodology, particularly the definition of testable scenarios, user stories are structured around recurring functional building blocks, hereafter referred to as modules. At present, seven modules have been defined: registration, authentication, authorization, read, update, delete, and backup. These modules represent distinct functional areas and enable the systematic structuring of user stories and the organization of testable scenarios accordingly.
As this modular approach is applied during the definition of testable end-to-end scenarios, practical implementation considerations arise, and assumptions must be defined within each functional area, e.g. the expected system behavior when handling malformed requests, the correct handling and classification of data access that exceeds a user’s authorization, or the appropriate handling of data submitted in an incorrect or incomplete format. Explicitly addressing these aspects is essential to achieving a robust and reliable implementation.
Example User Story: Updating Battery Data during Its Use Phase
Battery passports aren’t static documents – they need to be updated throughout the battery’s lifecycle as new information becomes available. An actor will need to record changes in battery health and might need to update data after maintenance or repair. Let’s follow a simple update process step by step to see where unclarities remain.
Authentication and Authorization: An actor requests access to update passport data. The system verifies identity and checks permissions before granting access. In the ideal case, this happens seamlessly within seconds.
Update: The system applies the changes and records the new version. In the ideal case, the update completes smoothly and all parties are notified. But what if an actor tries to modify fields they only have read-only access to? The system needs mechanisms to handle incomplete updates, detect permission violations, and maintain data integrity.
Backup: After a successful update, the system creates a backup copy for regulatory compliance. Ideally, backups complete quickly and confirmations are received. But what if the wrong version is backed up, or the backup data isn’t actually stored? The system must monitor backup processes and handle failures to ensure no data is lost.
The Reality: Prioritization Is Essential
In a single user story we can identify hundreds potential failure modes. Across all operations and actor interactions this results in numerous potential test scenarios. With limited resources, exhaustive testing is impossible.
This is where prioritization based on different criteria becomes essential – regulatory impact, frequency of occurrence, cascading effects, and recovery complexity. These prioritized scenarios form the foundation of our testing environment, allowing companies to focus on the failures that matter most.
What’s Next
Especially small and medium enterprises need practical approaches to demonstrate compliance without getting lost in technical details. In our next post, we’ll show you how we’re putting this methodology into practice with a testing environment that helps companies validate their implementations before going live. Building the battery passport system is about processes that work in the real world, under pressure, when things go wrong. And in a system processing millions of transactions per year across dozens of organizations and multiple countries, things will go wrong. The only question is whether your system is ready for it.
Elena Andrushchenko, Dogan Efe
TU Berlin
