IVI Nedir? İlk Araç Bilgisi ve IVI 2.0 XML

IVI, elektronik Uygunluk Belgesi sürecinde Initial Vehicle Information, yani ilk araç bilgisi anlamına gelir. Üretim sonrasında araç için oluşturulan başlangıç veri kümesini ifade eder. Buradaki IVI, araç içi bilgi-eğlence sistemi değildir. Üretici için önemli olan, onaylı araç bilgisini alıcı hizmetin istediği yapılandırılmış kayda doğru biçimde dönüştürmektir.

IVI ile eCoC arasındaki ilişki nedir?

eCoC, uygunluk bilgisinin elektronik ve yapılandırılmış biçimde sunulmasıdır. IVI şartnamesi bu bilgiyi taşıyan mesajı tanımlar. EUCARIS’in resmî terminoloji açıklaması, başlangıç verisini sonraki değişiklikleri içerebilen Actual Vehicle Information, yani AVI veri kümelerinden ayırır. Sonradan yapılan araç değişiklikleri, başlangıç kaydının iz bırakmadan değiştirilmesiyle karıştırılmamalıdır.

Uygulamada üç soru birlikte cevaplanır: araca ait onaylı bilgiler hangileri, bu bilgiler gerekli mesaj alanlarına nasıl aktarılıyor ve gönderim sonrasında alıcı sistem ne yanıt veriyor? Teknik verinin sahibi ile gönderimi yapan kişi farklı olabilir. Buna rağmen ikisi de aynı aracı ve aynı dosya sürümünü inceleyebilmelidir. Aksi halde hata araştırması yanlış kayıt üzerinden ilerleyebilir.

Hazırlık kaydında hangi bilgiler bulunmalı?

VIN, tip onayı referansları ve ilgili teknik özellikler başlangıç noktasıdır. Hangi alanların zorunlu olduğu, izin verilen değerler ve koşullar seçilen şartnameye ve araç kapsamına bağlıdır. Bu nedenle XSD dosyası mesaj açıklamalarıyla birlikte kullanılmalıdır. İnternetten alınmış tek bir örnek XML, her araç kategorisinin bütün gereksinimlerini açıklayan bir şablon olarak görülmemelidir.

Alan eşleştirme çalışmasında her değerin kaynağı, XML’deki karşılığı, varsa birim dönüşümü ve belirsizlik halinde başvurulacak sorumlu belirtilmelidir. Eksik bir değer tahminle doldurulmaz; inceleme için işaretlenir. Dosya bütün alanları dolu olduğu halde yanlış varyanttan alınmış kütle veya tip onayı bilgisi taşıyabilir. Doluluk kontrolü ile doğruluk kontrolü bu nedenle ayrı yürütülür.

IVI 2.0 geçişinde ne değişir?

EUCARIS, IVI 2.0’ın 1.x serisinden yapısal olarak farklı olduğunu açıklar. Geçiş, yalnızca dosyadaki sürüm etiketinin değiştirilmesi değildir. Hedef hizmetin kabul ettiği şartname seçilmeli, mevcut eşleştirmeler incelenmeli ve temsilî araçlar için yeni çıktılar üretilmelidir. EReg Topic Group XII resmî IVI dokümanlarına ulaşmak için başlangıç kaynağıdır.

Eski dosyada ad alanını veya sürüm numarasını değiştirmek yeterli kabul edilmemelidir. Üretilen yapının ve alanlara yerleştirilen bilgilerin anlamı kontrol edilir. Kullanılan eşleştirme sürümü doğrulama sonucuyla birlikte saklanır. Böylece daha sonra bir hata incelendiğinde dosyanın hangi kurallarla üretildiği anlaşılır. IVI 2.0 XML doğrulama sayfası gönderim öncesindeki kontrol adımlarını açıklar.

XSD kontrolünden geçmek neden yeterli değildir?

Şema doğrulaması, XML’in seçilen XSD’de ifade edilen yapısal koşullara uyup uymadığını kontrol eder. Ancak fiziksel aracın bütün özelliklerini veya seçilen tip onayı kaydının doğru araca ait olduğunu tek başına kanıtlayamaz. Çıktı, kaynak bilgilerle karşılaştırılmalıdır. Değerler arasındaki ilişkiler de incelenmeli; alıcı hizmetin ek kuralları kendi dokümantasyonu üzerinden değerlendirilmelidir.

İzin verilen aralıkta olmasına rağmen yanlış varyanttan alınmış bir sayısal değer düşünün. Yapısal kontrol bu değeri reddetmeyebilir, ancak dosya hedef araç için doğru değildir. Düzeltme kaynak seçiminde veya alan eşleştirmesinde yapılmalıdır. Sadece son XML’i elle değiştirmek, bir sonraki dosya üretiminde aynı hatanın tekrar ortaya çıkmasına yol açabilir.

Doğrulanmış XML’den gönderim sonucuna

Kayıt gönderime hazır olduğunda hedefin istediği imza veya mühür uygulanır ve gönderilen dosyanın tam kopyası saklanır. Alıcı hizmetin hesap ve ortam koşulları kontrol edilir. İmzalama adımı için eCoC XML imzalama, teslim ve yanıt takibi için eCoC NAP gönderimi rehberleri kullanılabilir. Bu aşamalar aynı sürecin parçalarıdır, ancak her birinin sonucu ayrı görünmelidir.

Araç kaydı tamamlandı olarak işaretlenmeden önce dönen yanıt incelenir. Bağlantı hatası, dosya doğrulama reddi ve başarılı alıcı yanıtı birbirinden ayrılır. Sonuç belirsizse dosyayı tekrar göndermeden önce durum araştırılır. Operatör; hangi dosyanın gönderildiğini, denemenin referansını, gelen yanıtı ve sıradaki işlemin kimin sorumluluğunda olduğunu görebilmelidir.

Pilot çalışmada hangi araçlar seçilmeli?

Pilot örnekleri üretim verisindeki gerçek farklılıkları temsil etmelidir. İlgili konfigürasyonlar ve gerekiyorsa farklı imalat aşamaları ayrı değerlendirilir. Bilerek hatalı hazırlanmış bir örnek de kullanmak faydalıdır. Amaç yalnızca başarılı bir dosya üretmek değil; hatanın operatör tarafından anlaşılıp anlaşılamadığını, doğru kaynağa kadar izlenip izlenemediğini ve düzeltmenin kontrollü yapılıp yapılmadığını görmektir.

Çalışma sonunda her örnek için kaynak kayıt, oluşturulan dosya ve doğrulama raporu birlikte gözden geçirilir. Üreticinin test hesabında gönderim yapıldıysa alıcı yanıtı da bu kayda eklenir. Hangi aşamanın tamamlandığı açıkça yazılır. Yerelde başarılı sonuç alınması ile hedef hizmetin kaydı kabul etmesi aynı kanıt değildir; günlük iş akışı bu farkı koruyacak şekilde kurulmalıdır.