Jak aktualizować DPP: zasady aktualizacji

Dlaczego jednorazowe uzupełnienie nie wystarczy

Cyfrowy paszport produktu (DPP) nie jest statycznym plikiem PDF, który tworzy się raz, a następnie archiwizuje. Rozporządzenie bateryjne (UE) 2023/1542 wyraźnie stanowi, że określone punkty danych muszą pozostać możliwe do aktualizacji przez cały cykl życia baterii. Kto uzupełni swój paszport w momencie wprowadzenia do obrotu, a potem przestanie go aktualizować, nie spełnia tych wymagań w pełni — i ryzykuje poważne problemy z zgodnością od 18 lutego 2027 r..

Brzmi to banalnie, ale takie nie jest. Raport z wdrożenia Minespider 2026 wskazuje na dwie strukturalne słabości występujące w całej branży: fragmentację danych w łańcuchu dostaw oraz brak procesów dynamicznej aktualizacji danych. Oba problemy razem utrudniają spójne utrzymywanie DPP w trakcie eksploatacji.

W tym artykule wyjaśniamy, które dane i kiedy muszą się zmieniać, jak wygląda infrastruktura techniczna aktualizacji oraz jakie procesy organizacyjne producenci i operatorzy powinni teraz zbudować.

Co się zmienia — i kiedy

Statyczne i dynamiczne punkty danych

Nie wszystkie pola DPP charakteryzują się taką samą zmiennością. W przybliżeniu można wyróżnić dwie kategorie:

Dane statyczne są ustalane w momencie wprowadzenia do obrotu i z reguły później już się nie zmieniają:

Skład materiałowy i substancje niebezpieczne
Identyfikacja producenta i miejsce produkcji
Certyfikaty z chwili wprowadzenia na rynek

Dane dynamiczne zmieniają się natomiast wraz z cyklem życia produktu:

State of Health (SoH) i State of Charge (SoC) baterii — obie wartości zmieniają się z każdym cyklem ładowania i rozładowania
Historia napraw i konserwacji
Zmiany właściciela i dane lokalizacyjne
Wyniki kontroli regeneracji pod koniec pierwszego cyklu życia

Szczególnie w przypadku baterii, które po zastosowaniu w pojeździe elektrycznym zyskują drugie życie jako stacjonarne magazyny energii, aktualne dane o stanie są nie tylko wymagane regulacyjnie, lecz także istotne z ekonomicznego punktu widzenia: operator magazynu wtórnego musi wiedzieć, jaką rzeczywistą pojemność resztkową kupuje.

Wyzwalacze obowiązkowych aktualizacji

Rozporządzenie nie określa dokładnych częstotliwości aktualizacji, ale definiuje zdarzenia, które ją wywołują:

Zakończenie konserwacji lub naprawy
Przejście do nowej fazy użytkowania (pierwszy cykl życia → drugi cykl życia)
Zmiana właściciela lub operatora
Nowe wartości pomiarowe z systemów BMS (Battery Management System)
Wycofanie produktu lub komunikat dotyczący bezpieczeństwa

Kto nie uwzględnił tych zdarzeń w swoim procesie wewnętrznym, będzie je przeoczać w codziennej działalności.

Architektura techniczna aktualizacji DPP

GS1 Digital Link jako stabilny punkt odniesienia

Powiązanie między fizyczną baterią a cyfrowym paszportem odbywa się za pośrednictwem GS1 Digital Link — standaryzowanego identyfikatora URI, który koduje GTIN i numer seryjny oraz wskazuje powiązany rekord danych. Kluczowe jest to, że odnośnik na produkcie (np. wydrukowany jako kod QR) pozostaje niezmienny. Aktualizacji podlega wyłącznie rekord, na który wskazuje.

Typowy GS1 Digital Link dla baterii wygląda tak:

https://id.example.com/01/04012345678901/21/ABC-0042

01 = GTIN-Qualifier
04012345678901 = GTIN baterii
21 = kwalifikator numeru seryjnego
ABC-0042 = indywidualny numer seryjny

Jest to wyłącznie przykładowy adres URL, który ilustruje schemat URI GS1 Digital Link. Resolver stojący za takim adresem przekierowuje do aktualnego rekordu DPP. Gdy rekord się zmienia, kod QR na produkcie pozostaje identyczny — aktualizacji ulega jedynie miejsce docelowe w backendzie. To właśnie stanowi koncepcyjne sedno dynamicznego utrzymywania danych.

Aktualizacje oparte na API: podstawowa zasada

Nowoczesne platformy DPP udostępniają interfejsy REST API, za pomocą których można celowo aktualizować punkty danych bez ponownego zapisywania całego paszportu. Typowe żądanie PATCH do interfejsu API DPP mogłoby wyglądać tak:

PATCH /dpp/v1/batteries/04012345678901/21/ABC-0042
Content-Type: application/json
Authorization: Bearer <token>

{
  "stateOfHealth": 0.83,
  "lastMeasuredAt": "2026-06-20T14:32:00Z",
  "measuredBy": "operator:fleet-mgmt-system-v2"
}

W porównaniu z pełnym żądaniem PUT zaletą jest to, że przesyłane są tylko zmienione pola, wersjonowanie pozostaje przejrzyste, a dziennik audytowy nie rośnie niepotrzebnie.

Wersjonowanie i ścieżka audytu

Normy EN 18216–18223, które CEN i CENELEC przedstawiły 25 czerwca 2026 r. podczas publicznego webinarium, określają wymagania dotyczące spójności danych i interoperacyjności. Obejmuje to pośrednio także możliwość prześledzenia zmian: kto, kiedy, jaką wartość zmienił i na jakiej podstawie?

Minimalna strategia wersjonowania powinna zapisywać przy każdym zdarzeniu aktualizacji następujące pola:

{
  "version": "3",
  "updatedAt": "2026-06-20T14:32:00Z",
  "updatedBy": "system:bms-connector",
  "changedFields": ["stateOfHealth", "lastMeasuredAt"],
  "previousValues": {
    "stateOfHealth": 0.87
  }
}

Bez takiej ścieżki w razie sporu nie można wykazać, że dane były prawidłowe w danym momencie.

Procesy organizacyjne: co firmy muszą teraz zbudować

Ustalenie odpowiedzialności za dane

Największy praktyczny problem nie ma natury technicznej. Chodzi o to, kto w firmie odpowiada za poszczególne punkty danych — i kto w razie wątpliwości inicjuje aktualizację.

Warto przygotować prostą macierz RACI, która dla każdego dynamicznego punktu danych określa:

Responsible: Kto wykonuje aktualizację?
Accountable: Kto odpowiada przed organem?
Consulted: Kto dostarcza dane pomiarowe?
Informed: Kogo należy powiadomić o zmianach?

Włączenie łańcucha dostaw

Wiele dynamicznych danych powstaje nie u producenta, lecz u dostawców, firm serwisowych lub menedżerów flot. Producent pozostaje jednak regulacyjnie odpowiedzialny za poprawność paszportu. Wymaga to jasnych ustaleń umownych i interfejsów technicznych, za pomocą których podmioty zewnętrzne mogą dostarczać dane — w określonych formatach i zgodnie z regułami walidacji.

Konsorcjum BatteryPass-Ready, które 24 czerwca 2026 r. uruchomiło publiczne środowisko testowe, oferuje właśnie taką neutralną platformę walidacyjną: firmy mogą testować swoje rozwiązania DPP pod kątem wymagań regulacyjnych, zanim rozpoczną eksploatację produkcyjną.

Uwzględnienie centralnego rejestru

Komisja Europejska pracuje nad centralnym rejestrem, w którym wszystkie DPPs mają być rejestrowane i możliwe do znalezienia. Orgalim — europejskie stowarzyszenie przemysłu technologicznego — opublikowało w tej sprawie jasne zalecenia: rejestr musi obsługiwać wysokowolumenowe, zautomatyzowane procesy rejestracji i być zabezpieczony przed awariami operacyjnymi.

Dla firm oznacza to, że ich procesy aktualizacji muszą działać nie tylko z własną platformą, lecz w przyszłości także umożliwiać synchronizację z centralnym rejestrem UE. Kto teraz postawi na zastrzeżone rozwiązania wyspowe, ten narazi się później na koszty migracji.

Praktyczna lista kontrolna procesu aktualizacji

Zanim pierwszy DPP trafi do środowiska produkcyjnego, należy wyjaśnić następujące kwestie:

Punkty danych sklasyfikowane: Które pola są statyczne, a które dynamiczne?
Wyzwalacze zdefiniowane: Jakie zdarzenia uruchamiają obowiązkową aktualizację?
Dostępy do API uregulowane: Kto może zmieniać jakie pola i za pośrednictwem którego interfejsu?
Ścieżka audytu wdrożona: Każda zmiana jest zapisywana wraz ze znacznikiem czasu, autorem i poprzednią wartością.
Interfejsy łańcucha dostaw przetestowane: Zewnętrzni dostawcy danych mogą wprowadzać prawidłowe aktualizacje.
Zgodność z rejestrem sprawdzona: Własny system może komunikować się z przyszłym rejestrem UE.
Środowisko testowe wykorzystane: Platforma testowa BatteryPass-Ready lub równoważne środowiska zostały wykorzystane do testów interoperacyjności.

Podsumowanie

DPP nie jest dokumentem, lecz żywym rekordem danych. Wymogi regulacyjne rozporządzenia bateryjnego (UE) 2023/1542 są pod tym względem jednoznaczne: dynamiczne punkty danych muszą być aktualne przez cały cykl życia produktu. Kto nie zbuduje odpowiedniej infrastruktury technicznej i organizacyjnej na czas, nie zapewni zgodności przed terminem 18 lutego 2027 r.

Dobra wiadomość jest taka, że niezbędne elementy już istnieją. GS1 Digital Link rozwiązuje problem identyfikacji, interfejsy REST API umożliwiają granularne aktualizacje, a inicjatywy takie jak BatteryPass-Ready oferują infrastrukturę testową. W wielu firmach brakuje jednak wewnętrznych procesów i jasnego przypisania odpowiedzialności za dane — i właśnie od tego należy zacząć pracę.