IVI 2.0 XML, bir aracın elektronik uygunluk belgesi verisini standart ve makine tarafından okunabilir biçimde ifade eden veri yapısıdır. Dosyanın teknik olarak açılması veya XSD kontrolünden geçmesi, içindeki bilgilerin homologasyon açısından doğru olduğu anlamına gelmez. Sağlam bir eCoC süreci üç kontrol katmanını birlikte yürütür: şema uygunluğu, alanlar arası iş kuralları ve onay kaynağına uygunluk.
eCoC geçişinin kapsamını ve 29 Kasım 2026 hazırlık planını önce görmek isterseniz üretici hazırlık rehberinden başlayabilirsiniz. Bu yazı, verinin nasıl üretileceğine ve neden yalnızca “XML oluşturmanın” yeterli olmadığına odaklanır.
IVI 2.0 neyi standartlaştırır?
Initial Vehicle Information (IVI) veri modeli; araç kimliği, üretici, tip onayı, tip–varyant–versiyon, teknik özellikler, kütleler, güç aktarma sistemi, çevresel veriler ve ilgili uygunluk bilgilerinin tanımlı bir hiyerarşide aktarılmasını sağlar. Alanların zorunluluğu araç kategorisine, yakıt ve güç aktarma tipine, onay şemasına, üretim aşamasına ve hedef sisteme göre değişebilir.
Birleşik Krallık VCA, UK IVI dosyasının AB IVI 2.0 yapısını temel aldığını ancak GB ve UKNI onay bilgileri için ek değerler içerdiğini açıklıyor. Bu örnek önemli bir ilkeyi gösterir: aynı temel model kullanılsa bile hedef otoritenin güncel XSD'si, versiyon notları ve tamamlayıcı talimatları esas alınmalıdır.
IVI dosyasındaki veri nereden gelmeli?
Tek bir sistem nadiren tüm alanların tek ve doğru kaynağıdır. VIN ve üretim tarihi üretim/ERP sisteminden; tip–varyant–versiyon ve onay kapsamı homologasyon kayıtlarından; opsiyon ve konfigürasyon verileri ürün ağacından; emisyon ve tüketim değerleri ilgili teknik kaynaklardan gelebilir. Bu nedenle her alan için “kaynak, dönüşüm kuralı, sorumlu, güncellik ve kanıt” tanımlanmalıdır.
| Veri grubu | Muhtemel ana kaynak | Kritik kontrol |
|---|---|---|
| VIN ve üretim bilgisi | ERP / üretim yürütme sistemi | 17 karakter, benzersizlik, WMI ve tarih tutarlılığı |
| Tip–varyant–versiyon | Tip onayı / homologasyon veri tabanı | VIN konfigürasyonunun onay kapsamında bulunması |
| Kütle ve boyutlar | Onay dokümanı / ürün konfigürasyonu | Kategori ve aks değerleriyle aritmetik tutarlılık |
| Motor, güç ve enerji | Teknik dosya / güç aktarma sistemi kaydı | Birim, yakıt türü ve güç aktarma tipine bağlı alanlar |
| Emisyon / CO₂ / tüketim | Onay, test ve gerektiğinde VECTO kaynakları | Uygulanabilir mevzuat, değer kümesi ve kapsam |
| İmza ve sürüm | eCoC operasyon sistemi | Yetkili imza, bütünlük ve sürüm zinciri |
Üç katmanlı doğrulama modeli
1. XML ve XSD doğrulaması
İlk katman dosyanın güncel şemaya uyup uymadığını kontrol eder: eleman sırası, veri tipi, zorunlu alan, izin verilen değer ve biçim. Hedef pazarın XSD sürümü sabitlenmeli; şema değişiklikleri kontrollü yayın olarak yönetilmelidir.
2. İş kuralı ve çapraz alan doğrulaması
Şema tarafından zorunlu tutulmayan ilişkiler burada kontrol edilir. Araç kategorisi ile gövde tipi, yakıt türü ile emisyon alanları, aks sayısı ile aks değerleri, kütlelerin kendi aralarındaki sınırlar ve üretim aşamasına göre uygulanabilir alanlar örnektir. Bu kontroller, yetkili sisteme gitmeden önce yakalanan hataların önemli bölümünü oluşturur.
3. Homologasyon kaynağına uygunluk
En kritik katmandır. XML'deki değerlerin geçerli tip onayı, uzatmaları ve araç konfigürasyonuyla eşleşmesi gerekir. XSD'nin “geçerli” dediği bir serbest metin ya da sayısal değer, onay belgesinde farklıysa eCoC yine yanlıştır. Bu nedenle Anemon Mühendislik yaklaşımı, platform doğrulamasını teknik dosya ve onay kapsamı incelemesiyle birleştirir.
Kısa cevap: Geçerli XML, doğru eCoC için gerekli koşuldur; fakat yeterli koşul değildir.
Tip–varyant–versiyon ve VIN eşleşmesi neden merkezde?
Bir VIN'in hangi onaylı konfigürasyonu temsil ettiği belirlenmeden teknik değerler güvenle üretilemez. Opsiyon kodlarının varyant/versiyona etkisi, üretim tarihi itibarıyla geçerli uzatma, güç aktarma sistemi ve gövde kombinasyonu birlikte değerlendirilmelidir. Manuel listelerde yaygın görülen kopyala–yapıştır hataları, farklı bir versiyona ait değerin doğru görünümlü XML içinde taşınmasına neden olabilir.
Manuel giriş, dosya aktarımı veya API?
| Yöntem | Uygun olduğu durum | Temel risk |
|---|---|---|
| Kontrollü manuel giriş | Düşük hacim, az sayıda araç yapısı | Tekrarlı veri girişi ve insan hatası |
| Şablon / tablo aktarımı | Orta hacim, düzenli veri kaynağı | Sürüm ve kolon eşleşmesinin bozulması |
| ERP / API entegrasyonu | Yüksek hacim, otomatik üretim | Yanlış ana verinin seri biçimde çoğalması |
| Hibrit model | Birden çok marka, aşama veya veri olgunluğu | Rol ve onay akışının net tanımlanmaması |
En otomatik yöntem her zaman en güvenli başlangıç değildir. Önce temsili araçlarla veri modeli doğrulanmalı, sonra hacme göre otomasyon artırılmalıdır. Electronic COC Platformu kontrollü manuel akıştan dosya ve API entegrasyonuna kadar kademeli bir yapı kurmayı amaçlar.
Hata, düzeltme ve sürüm yönetimi
eCoC operasyonunda dosyanın ilk gönderimi kadar sonradan yapılan düzeltmenin izlenmesi de önemlidir. Hangi alanın neden değiştiği, kim tarafından onaylandığı, hangi IVI sürümünün imzalanıp gönderildiği ve hedef sistemin hangi cevabı verdiği kayıt altına alınmalıdır. Aynı VIN için yeni bir sürüm gönderildiğinde önceki kayıt kaybolmamalı; denetim izi korunmalıdır.
Temsilî dosyanızı pilot olarak doğrulayalım. Bir araç ailesi ve anonimleştirilmiş alan listesi üzerinden veri haritası, kural kapsamı ve entegrasyon yöntemini belirlemek için Anemon eCoC ekibiyle iletişime geçin.
Yayına geçmeden önce kontrol listesi
- Hedef sistemin güncel XSD ve versiyon notları arşivlendi mi?
- Her alanın ana kaynağı ve sahibi tanımlı mı?
- Tip–varyant–versiyon ile VIN eşleştirme kuralı onaylandı mı?
- Birim dönüşümleri ve ondalık hassasiyet tek merkezde mi yönetiliyor?
- Kategori, yakıt, gövde ve üretim aşamasına bağlı koşullar test edildi mi?
- İmza öncesi ve sonrası dosya bütünlüğü kontrol ediliyor mu?
- Hata mesajları sorumlu ekibe ve anlaşılır iş kuralına çevriliyor mu?
- Düzeltme ve yeniden gönderim sürüm geçmişini koruyor mu?
Örnek: bir VIN kaydı nasıl güvenilir eCoC verisine dönüşür?
Üretim sistemi VIN'i ve fiilî konfigürasyonu oluşturduğunda platform önce bu kaydı onaylı tip–varyant–versiyonla eşleştirir. Eşleşme bulunamazsa varsayılan bir versiyon seçmek yerine kayıt istisna kuyruğuna alınmalıdır. Doğru kapsam bulunduğunda teknik alanlar kendi ana kaynaklarından çekilir; birimler ve kod listeleri hedef IVI sürümüne dönüştürülür.
Ardından şema doğrulaması, çapraz alan kuralları ve homologasyon kontrolü çalışır. Örneğin aks sayısı ile aks kütleleri, yakıt türü ile uygulanabilir emisyon alanları ve araç statüsü ile üretim aşaması birbirini doğrulamalıdır. Kontroller tamamlanmadan imza oluşturulmamalıdır. Son çıktı yalnızca XML değil; kullanılan kaynak sürümlerini, uygulanan kuralları, onaylayan kişiyi ve dosya özetini de içeren denetim paketidir.
İyi bir pilot çalışmanın teslimatları
- Temsilî araç ailelerini ve istisnaları gösteren kapsam matrisi,
- her IVI alanı için kaynak, dönüşüm, sorumlu ve kanıt bilgisi,
- hedef XSD sürümü ile uygulanabilir kural kataloğu,
- pozitif, negatif ve sınır değer test senaryoları,
- örnek imzalı dosya ve doğrulama raporu,
- ret mesajından kök nedene kadar izlenebilir hata sınıflandırması,
- ERP/API entegrasyonu için alan sözleşmesi ve değişiklik yönetimi planı.
Bu çıktılar olmadan tamamlanan bir “XML üretici”, seri kullanımda aynı hatayı yüzlerce araca taşıyabilir. Pilotun başarısı dosya sayısıyla değil, veri kaynağı ve onay kapsamının kanıtlanmasıyla ölçülmelidir.
IVI 2.0 XML ve eCoC veri doğrulama — IVI verisi, doğrulama kuralları ve entegrasyon seçenekleri için Electronic COC platformunu inceleyin.
Sık sorulan sorular
IVI 2.0 bir PDF formatı mı?
Hayır. XML tabanlı yapılandırılmış veri modelidir. İnsan için oluşturulan görünüm ayrı bir sunum katmanı olabilir.
Excel'den eCoC üretilebilir mi?
Kontrollü şablon ve doğrulama katmanı varsa düşük veya orta hacimde kaynak olarak kullanılabilir. Ham bir tablonun doğrudan XML'e çevrilmesi homologasyon doğruluğunu garanti etmez.
Her ülke aynı IVI dosyasını mı kabul eder?
Temel model ortak olabilir; ancak hedef otoritenin XSD sürümü, ek alanları, imza ve gönderim kuralları kontrol edilmelidir.
Resmî teknik bilgiler nerede bulunur?
EUCARIS IVI uygulama bilgileri, ilgili AB mevzuatı, VCA'nın UK IVI dokümanları ve seçilen NAP/onay kuruluşunun güncel kılavuzları birlikte kullanılmalıdır.
Özet
IVI 2.0, araç uygunluk verisini elektronik ortamda taşımak için kullanılan yapılandırılmış veri modelidir. Güvenilir bir eCoC süreci yalnızca XSD'ye uyan XML üretmez; alanların doğru kaynaktan gelmesini, birbiriyle tutarlı olmasını, geçerli tip onayıyla eşleşmesini ve her değişikliğin sürüm olarak izlenmesini sağlar.
