Battery Pass Veri Modeli ve Catena-X

Ek XIII, batarya pasaportunun ne içereceğini söyler; nasıl adlandırılacağını, hangi birimde ölçüleceğini ve hangi veri tipinde taşınacağını söylemez. O boşluğu, tüzük yürürlüğe girmeden önce başlayan üç girişim doldurdu: Almanya'da kamu fonuyla kurulan Battery Pass konsorsiyumu, Catena-X'in batarya pasaportu kullanım senaryosu ve Global Battery Alliance pilotları.

Bir üretici için soru şudur: bunlardan hangisi bağlayıcı, hangisi yol gösterici ve bir Dijital Ürün Pasaportu platformu bu üçünü tek bir kanonik modele nasıl indirger? AAS ve Catena-X ekosistemi yazısı mimariyi anlatıyor; burada veri modelinin kendisine bakıyoruz.

Üç kaynak, üç rol

Kanun ne der, kılavuz ne ekler?

Ek XIII bir özniteliği düz metinle tanımlar: "bataryanın karbon ayak izi", "geri dönüştürülmüş kobalt payı", "anma kapasitesi". Uygulamada bunun yetmediği hemen görülür. Karbon ayak izi toplam mı, kWh başına mı beyan edilir? Geri dönüştürülmüş pay yüzde mi, kütle mi? Anma kapasitesi hangi test koşulunda ölçülür?

Battery Pass içerik kılavuzu tam bu soruları cevaplar: her öznitelik için tanım, birim, veri tipi, kardinalite, erişim katmanı ve dayandığı tüzük maddesi. Teknik kılavuz ve açık veri modeli bunu makine-okunabilir hâle getirir. Ek XIII veri alanları yazısındaki "yaklaşık 90 öznitelik" sayısı da bu haritalamadan gelir.

Sınır net olmalı: kılavuz, kanunun belirsizliğini giderir ama kanunun yerine geçmez. İkincil mevzuat farklı bir birim veya format belirlerse kılavuz ona uyar, tersi olmaz. Karbon alanının neden ayrı bir yazıyı hak ettiğini, metodoloji delegated act'ine bağımlılığıyla birlikte batarya karbon ayak izi beyanı yazısında bulabilirsiniz.

Catena-X aynı alanları nasıl taşır?

Catena-X, Battery Pass sözlüğünü kendi semantik diline çevirir: SAMM ile tanımlı bir batarya pasaportu aspect modeli, her özniteliği tipli ve sürümlü bir yapıya bağlar. Tractus-X referans uygulaması bu modeli okuyan, görüntüleyen ve EDC konektörü üzerinden talep eden açık kaynak bir uygulama sunar. Otomotiv OEM'i tedarikçisinden "pasaport" istediğinde kastettiği çoğunlukla budur; ayrıntı otomotivde DPP ve Catena-X yazısında.

Üretici açısından kritik nokta: aspect modeli, Ek XIII'ün alan adlarını değil, Catena-X'in alan adlarını kullanır. Bakımlı bir eşleme tablosu olmadan iki dünya arasında geçiş yapılamaz.

Ek XIII'ten JSON-LD ve AAS'a

Bir pasaport platformunun yapması gereken, üç modeli yan yana taşımak değil, tek bir kanonik model tutup gerekli serileştirmeyi üretmektir:

1. Her alanı Ek XIII özniteliğine ve erişim katmanına anahtarlayın; konsorsiyum tanımını ve birimini alan tanımına yazın.
2. Kamu ve API yüzeyinde JSON-LD üretin: EN 18223 çekirdek modelini bağlam olarak, batarya alanlarını uzantı olarak. Bkz. EN 18223 çekirdek veri modeli ve JSON-LD ve DPP verisi.
3. Otomotiv müşterisi için aynı kayıttan AAS submodel veya Catena-X aspect çıktısı üretin; eşleme tablosu kodda değil, yapılandırmada dursun.
4. Her pasaport sürümüne kullanılan model sürümünü yazın; model değişince eski sürümler yeniden yorumlanabilir kalır.
5. Birimleri girişte sabitleyin: kWh, kg CO2e/kWh, yüzde. Dönüşümü serileştirme katmanına bırakmayın.

Bu yaklaşımın genel ilkeleri veri modeli rehberinde; Madde 78'in açık standart ve birlikte çalışabilirlik şartlarının bu mimariye nasıl yansıdığı ise batarya pasaportu teknik tasarımı yazısında.

Değişimi yönetmek

Üç kaynak da yaşıyor: konsorsiyum modeli güncelleniyor, Catena-X yeni sürümler çıkarıyor ve Komisyon'un pasaportun teknik özelliklerini belirleyen ikincil mevzuatı bekleniyor. Bu yüzden alan tanımlarını koda gömmek yerine sürümlü bir sözlükte tutmak, 2027'den sonra en az bir kez yapılacak yeniden eşlemenin maliyetini düşürür. Sözlüğün sahibi de belli olmalı: veri modelini kim günceller, kim onaylar, eski sürümler ne kadar süre okunur kalır?

Sık sorulan sorular