Защо еднократното попълване не е достатъчно
Цифровият продуктов паспорт (DPP) не е статичен PDF файл, който се създава веднъж и след това се архивира. Регламентът за батериите (ЕС) 2023/1542 изрично предвижда, че определени точки от данни трябва да могат да се актуализират през целия жизнен цикъл на батерията. Който попълни паспорта си при пускането на пазара и след това повече не го актуализира, не изпълнява напълно тези изисквания — и рискува сериозни проблеми със съответствието след 18 февруари 2027 г..
Това звучи тривиално, но не е. Докладът за внедряване на Minespider за 2026 г. идентифицира две структурни слабости, които се срещат в целия сектор: фрагментиране на данните по веригата на доставки и липса на процеси за динамично актуализиране на данните. Комбинацията от двете затруднява поддържането на DPP в съответствие по време на експлоатация.
Тази статия обяснява кои данни и кога трябва да се променят, как изглежда техническата инфраструктура за актуализации и какви организационни процеси трябва да изградят производителите и операторите още сега.
Какво се променя — и кога
Статични и динамични точки от данни
Не всички полета в DPP са еднакво променливи. Най-общо могат да се разграничат две категории:
Статичните данни се определят при пускането на пазара и обикновено не се променят след това:
- Състав на материалите и опасни вещества
- Идентификация на производителя и производствен обект
- Сертификати към момента на пускане на пазара
Динамичните данни, напротив, се променят с жизнения цикъл на продукта:
- State of Health (SoH) и State of Charge (SoC) при батериите — и двете стойности се променят при всеки цикъл на зареждане и разреждане
- История на ремонтите и поддръжката
- Смяна на собственика и данни за местоположението
- Резултати от проверки за повторна подготовка в края на първоначалния жизнен цикъл
Особено при батериите, които преминават към втори живот като стационарни акумулатори след използване в електромобил, актуалните данни за състоянието са не само нормативно изисквани, но и икономически значими: операторът на вторичен акумулатор трябва да знае какъв остатъчен капацитет действително закупува.
Задействащи фактори за задължителни актуализации
Регламентът не посочва точни интервали за актуализация, но определя събития, които я задействат:
- Приключване на поддръжка или ремонт
- Преминаване към нова фаза на използване (първоначален живот → втори живот)
- Смяна на собственика или оператора
- Нови измерени стойности от BMS системи (Battery Management System)
- Изтегляне на продукта или предупреждение за безопасност
Който не е интегрирал тези събития във вътрешния си процес, ще ги пропуска в ежедневната работа.
Техническата архитектура за актуализации на DPP
GS1 Digital Link като стабилна опорна точка
Връзката между физическата батерия и цифровия паспорт се осъществява чрез GS1 Digital Link — стандартизиран URI, който кодира GTIN и серийния номер и сочи към съответния запис с данни. Същественото е, че връзката върху продукта (например отпечатана като QR код) остава непроменена. Актуализира се само записът, към който тя сочи.
Типичен GS1 Digital Link за батерия изглежда така:
https://id.example.com/01/04012345678901/21/ABC-0042
01= GTIN-квалификатор04012345678901= GTIN на батерията21= квалификатор на серийния номерABC-0042= индивидуален сериен номер
Това е чисто илюстративен примерен URL, който показва URI схемата на GS1 Digital Link. Resolver-ът зад подобен URL пренасочва към актуалния запис на DPP. Ако записът се промени, QR кодът върху продукта остава същият — актуализира се само целта в бекенда. Това е концептуалното ядро на динамичното управление на данните.
Актуализации чрез API: основният принцип
Съвременните платформи за DPP предоставят REST API, чрез които точките от данни могат да се актуализират целево, без целият паспорт да се записва наново. Типична PATCH заявка към DPP API може да изглежда така:
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"
}
Предимството пред пълен PUT е, че се предават само променените полета, версионирането остава проследимо, а одитният журнал не се разраства излишно.
Версиониране и одитна следа
Стандартите EN 18216 до 18223, представени от CEN и CENELEC на 25 юни 2026 г. в публичен уебинар, определят изисквания за съгласуваност и оперативна съвместимост на данните. Това имплицитно включва и проследимостта на промените: кой, кога и коя стойност е променил и на какво основание?
Една минимална стратегия за версиониране трябва да съхранява следните полета за всяко събитие по актуализация:
{
"version": "3",
"updatedAt": "2026-06-20T14:32:00Z",
"updatedBy": "system:bms-connector",
"changedFields": ["stateOfHealth", "lastMeasuredAt"],
"previousValues": {
"stateOfHealth": 0.87
}
}
Без тази следа при спор не може да се докаже, че данните са били коректни в съответния момент.
Организационни процеси: какво трябва да изградят компаниите сега
Изясняване на отговорностите за данните
Най-големият практически проблем не е технически. Въпросът е кой в компанията отговаря за отделните точки от данни — и кой при необходимост задейства актуализацията.
Препоръчително е да се създаде проста RACI матрица, която за всяка динамична точка от данни определя:
- Responsible: Кой извършва актуализацията?
- Accountable: Кой носи отговорност пред органа?
- Consulted: Кой предоставя измерените данни?
- Informed: Кой трябва да бъде уведомен за промените?
Включване на веригата на доставки
Много динамични данни възникват не при производителя, а при доставчици, сервизни предприятия или оператори на автопаркове. Производителят обаче остава регулаторно отговорен за коректността на паспорта. Това изисква ясни договорни разпоредби и технически интерфейси, чрез които трети страни да могат да предоставят данни — с определени формати и правила за валидиране.
Консорциумът BatteryPass-Ready, който на 24 юни 2026 г. стартира публична тестова среда, предлага именно такава неутрална платформа за валидиране: компаниите могат да тестват своите решения за DPP спрямо регулаторните изисквания, преди да ги въведат в продуктивна експлоатация.
Наблюдение на централния регистър
Европейската комисия работи по централен регистър, чрез който всички DPPs ще бъдат регистрирани и ще могат да бъдат откривани. Orgalim — европейската индустриална асоциация за технологии — публикува ясни препоръки по темата: регистърът трябва да поддържа автоматизирани регистрационни процеси с голям обем и да бъде защитен от прекъсвания в работата.
За компаниите това означава, че процесите им за актуализация трябва не само да работят със собствената им платформа, но в перспектива да могат да се синхронизират и с централния регистър на ЕС. Който сега заложи на собствени изолирани решения, ще си създаде разходи по миграцията на по-късен етап.
Практически списък за проверка на процеса по актуализация
Преди първият DPP да влезе в продукция, трябва да бъдат изяснени следните точки:
- Класифицирани точки от данни: Кои полета са статични и кои динамични?
- Определени задействащи фактори: Кои събития предизвикват задължителна актуализация?
- Регламентиран достъп до API: Кой може да променя кои полета и чрез кой интерфейс?
- Внедрена одитна следа: Всяка промяна се съхранява с времеви печат, автор и предишна стойност.
- Тествани интерфейси по веригата на доставки: Външните доставчици на данни могат да подават валидни актуализации.
- Проверена съвместимост с регистъра: Собствената система може да комуникира с бъдещия регистър на ЕС.
- Използвана тестова среда: Тестовата платформа BatteryPass-Ready или еквивалентни среди са използвани за тестове за оперативна съвместимост.
Заключение
DPP не е документ, а жив запис с данни. Регулаторните изисквания на Регламента за батериите (ЕС) 2023/1542 са еднозначни в това отношение: динамичните точки от данни трябва да се поддържат актуални през целия жизнен цикъл на продукта. Който не изгради навреме необходимата техническа и организационна инфраструктура, няма да постигне съответствие в срока 18 февруари 2027 г.
Добрата новина е, че необходимите компоненти са налице. GS1 Digital Link решава проблема с идентификацията, REST API позволяват детайлни актуализации, а инициативи като BatteryPass-Ready предлагат тестова инфраструктура. В много компании липсват вътрешните процеси и ясното разпределение на отговорностите за данните — и именно оттам трябва да започне работата.