Digitālā baterijas pase: kā uzturēt savus datus aktuālus

No 2027. gada februāra obligāti: kā ražotāji tiesiski atbilstoši atjaunina dinamiskos datus digitālajā baterijas pasē — no SoH līdz CO₂ pēdas nospiedumam.

autors QR3 Redaktion

Digitālā baterijas pase: kā uzturēt savus datus aktuālus

Kāpēc ar „vienreizēju aizpildīšanu” nepietiek

Digitālā baterijas pase (DBP) nav statiska datu lapa. Bateriju regula (ES) 2023/1542 skaidri nosaka, ka noteiktiem datu punktiem jāpaliek atjaunināmiem visā baterijas dzīves ciklā. Ja pasi aizpilda vienreiz, laižot bateriju tirgū, un pēc tam vairs nemaina, prasības nav pilnībā izpildītas — un no 2027. gada 18. februāra pastāv nopietnu atbilstības problēmu risks.

Tas izklausās pašsaprotami, taču praksē ir būtiska operatīva problēma. Minespider īstenošanas ziņojumā par 2026. gadu identificētas divas strukturālas vājās vietas, kas raksturīgas visai nozarei: datu fragmentācija piegādes ķēdē un procesu trūkums dinamisku datu atjaunināšanai. Abas problēmas ir atrisināmas — taču tikai ar skaidru tehnisko un organizatorisko stratēģiju.


Kas un kad jāmaina: trīs atjaunināšanas kategorijas

Ne uz visiem DBP datu laukiem attiecas vienādi atjaunināšanas pienākumi. Jau no paša sākuma ir vērts nošķirt trīs kategorijas:

1. Statiski pamatdati (vienreiz, laižot tirgū)

Tie ietver ķīmisko sastāvu, elementu tehnoloģiju, ražotāja identifikāciju un sērijas numuru. Šie lauki tiek iestatīti sākotnējās aizpildīšanas laikā un nemainās. Tie veido pases nemainīgo kodolu.

2. Partijai specifiski CO₂ dati (vienreiz, bet detalizēti)

Produktam specifiskā CO₂ pēda (PCF) jāaprēķina saskaņā ar ISO 14067-kompatiblen metodēm un jānorāda partijas līmenī. Eiropas Komisijas JRC projekts skaidri nosaka: agregēšana starp dažādām ražotnēm nav pieļaujama. Katram baterijas modelim katrā ražotnē ir sava PCF vērtība. Tas nozīmē, ka katrai jaunai partijai jāizveido jauns datu ieraksts un tas jāsaista ar attiecīgo pasi — nekādas kopēšanas no iepriekšējā modeļa.

Praksē tas nozīmē: ja jūsu ražošanas sistēma nenodrošina partijai specifiskus CO₂ aprēķinus, augšupējais process jāpielāgo, pirms pasi vispār var aizpildīt.

3. Stāvokļa dati (nepārtraukti, visā dzīves ciklā)

Šī ir sarežģītākā kategorija. State of Health (SoH) un State of Charge (SoC) mainās ar katru uzlādes un izlādes ciklu. Baterijām, kuras tiek izmantotas otrajā dzīves ciklā — piemēram, kā stacionāra krātuve pēc izmantošanas elektromobilī — aktuāli stāvokļa dati ir ne tikai normatīvi noteikti, bet arī ekonomiski nozīmīgi: bez uzticamas SoH informācijas nav iespējams noteikt taisnīgu tirgus vērtību otrreizējās izmantošanas tirgū.


Tehniskā īstenošana: trīs pieeju salīdzinājums

Kā dati nonāk pasē? Un kā tos uzturēt aktuālus? Būtībā pastāv trīs arhitektūras pieejas:

Pieeja Piemērota Priekšrocība Risks
Nosūtīšana, izmantojot REST API Ražotājiem ar savu MES/ERP Pilnībā automatizēta, piemērota reāllaikam Atkarība no iekšējās IT infrastruktūras
Masveida imports (CSV/JSON) Piegādātājiem bez API savienojuma Zems ieviešanas slieksnis Manuālu kļūdu avoti, aizkaves
Sensors–DPP (IoT) Stacionārām krātuvēm, autoparka pārvaldībai Nepārtraukta SoH atjaunināšana Sarežģīts datu konveijers, augstas latentuma prasības

Lielākajai daļai ražotāju lietderīga būs hibrīda pieeja: pamatdati un PCF dati no ERP tiek saņemti, izmantojot masveida importu vai API, savukārt stāvokļa dati tiek papildināti, izmantojot IoT konveijeru.

API atjaunināšana: minimāls piemērs

Ja stāvokļa datu atjaunināšanai izmanto REST API, ieteicams izvēlēties versiju atbalstošu galapunktu struktūru, kas atbalsta arī daļējus atjauninājumus (PATCH):

// Beispiel: SoH-Update für eine einzelne Batterie-Seriennummer
const response = await fetch(
  'https://api.example.com/v1/batteries/{serialNumber}/state',
  {
    method: 'PATCH',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${apiToken}`,
    },
    body: JSON.stringify({
      stateOfHealth: 0.87,        // 87 % Restkapazität
      stateOfCharge: 0.52,        // 52 % aktueller Ladestand
      measuredAt: '2026-06-25T14:30:00Z',
      measurementMethod: 'IEC_62660-1',
    }),
  }
);

Laikspiedols (measuredAt) nav neobligāts lauks — tas ir būtisks izsekojamībai un tirgus uzraudzības iestāžu pārbaudēm.


Sadarbspēja: standarti, reģistrs un testēšanas vide

Atjaunināšana ir mazvērtīga, ja saņēmēja mezgls datus nesaprot. Tieši šeit nozīme ir standartizācijas darbam. 2026. gada 25. jūnijā CEN un CENELEC rīkoja publisku tīmekļsemināru par jaunieviestajiem DPP standartiem EN 18216–EN 18223. Šie seši standarti, ko izstrādājusi Tehniskā komiteja JTC 24, definē starpproduktu ietvaru sadarbspējai un datu konsekvencei — tieši to slāni, kurā jāstandartizē atjaunināšanas procesi.

Paralēli konsorcijs BatteryPass-Ready 2026. gada 24. jūnijā atklāja publisku digitālās baterijas pases testēšanas vidi. Ražotāji, piegādātāji un programmatūras nodrošinātāji tajā var validēt savas īstenošanas pret normatīvajām prasībām — vēl pirms darbības sākšanas reālajā vidē. Veidojot atjaunināšanas procesus, šī vide jāizmanto savlaicīgi, lai pārbaudītu datu formātus un API saderību.

ES centrālais DPP reģistrs

Eiropas Komisija strādā pie centrālā reģistra, kurā paredzēts reģistrēt un padarīt atrodamus visus DPPs. Orgalim — Eiropas tehnoloģiju nozares apvienība — ir publicējusi skaidrus ieteikumus: reģistram jāatbalsta liela apjoma automatizēti reģistrācijas procesi un jābūt aizsargātam pret darbības pārtraukumiem. Atjaunināšanas procesiem tas nozīmē: jūsu iekšējai arhitektūrai jādarbojas arī tad, ja centrālais reģistrs īslaicīgi nav pieejams — tātad jāparedz lokālā kešatmiņa un atkārtošanas loģika.

Fiziskās baterijas un digitālās pases sasaistīšana praksē notiek, izmantojot GS1 Digital Link — standartizētu URI, kas kodē GTIN un sērijas numuru un norāda uz saistīto datu ierakstu. Šī saite parasti ir iekodēta QR kodā uz baterijas etiķetes.


Organizatoriskie priekšnoteikumi: kas atbild par atjaunināšanu?

Regula galvenokārt attiecas uz ekonomikas dalībnieku, kas laiž bateriju tirgū. Taču stāvokļa dati bieži rodas tālu no ražotāja — pie autoparka operatora, pārstrādes uzņēmuma vai otrreizējās izmantošanas pakalpojumu sniedzēja. Tāpēc jautājums par rakstīšanas tiesībām nav tikai tehnisks: tas jāregulē līgumiski.

Jūsu pārvaldības struktūrā skaidri jādefinē šādas lomas:

  • Datu īpašnieks: kurš drīkst rakstīt un pārrakstīt konkrētus laukus?
  • Auditācijas izsekojamība: katra izmaiņa jāreģistrē ar laikspiedolu un veicēju — ne tikai atbilstības nodrošināšanai, bet arī strīdu gadījumiem otrreizējās izmantošanas tirgū.
  • Ārkārtas process: kas notiek, ja sensors sabojājas vai piegādātājs nesniedz datus?

Tādi risinājumi kā Bureau Veritas un Circulor partnerība parāda, kā pārbaudes organizācijas un datu nodrošinātāji sadarbojas, lai novērstu tieši šīs pārvaldības nepilnības. Līdzīgi sevi pozicionē Securikett ar savu Codikett 2.0 platformu: pret viltojumiem aizsargātas etiķetes, kas fiziski sasaista datu ierakstu ar produktu un apgrūtina nesankcionētu rakstīšanas piekļuvi.


Kontrolsaraksts: gatavība atjaunināšanai līdz 2027. gada februārim

Pirms uzskatīt DBP procesu par „pabeigtu”, jāpārbauda šādi punkti:

  • PCF aprēķins īstenots partijas līmenī (nevis agregēts pēc modeļa)
  • SoH/SoC datu konveijers izveidots un pārbaudīts
  • API galapunkti atbalsta daļējus atjauninājumus (PATCH) ar laikspiedolu
  • Rakstīšanas tiesības līgumiski noregulētas ar visiem attiecīgajiem dalībniekiem
  • Ieviesta atkārtošanas loģika reģistra darbības pārtraukuma gadījumam
  • Īstenošana validēta BatteryPass-Ready testēšanas vidē
  • GS1 Digital Link ir pareizi iekodēts etiķetē un QR kodā

gada februāris tuvojas. Tie, kuri atjaunināšanas procesus sāks veidot tikai tad, kad pienākums stāsies spēkā, secinās, ka īstais darbs nav pases aizpildīšana — bet gan tās pareizas uzturēšanas nodrošināšana daudzu gadu garumā.

Avoti