Ticari Şarj Operatörleri İçin OCPP 1.6J ve 2.0.1'in Stratejik Karşılaştırması

Küresel Ticari Şarj Operatörleri için OCPP 1.6J ve 2.0.1'in Kesin Stratejik Karşılaştırması: Sürdürülebilir Elektrikli Araç Büyümesi için Ağ Ölçeklenebilirliği, Gelişmiş Siber Güvenlik, ISO 15118 Entegrasyonu ve Uzun Vadeli Altyapı Geleceğe Hazırlığı Konusunda Uzmanlaşma

Yönetici Özeti

Elektrikli araç (EV) şarjı alanında büyük bir değişim yaşanıyor. Küresel benimseme hızlanırken, Elektrikli Araç Besleme Ekipmanları (EVSE) ve Şarj İstasyonu Yönetim Sistemleri (CSMS) arasındaki etkileşimi yöneten temel iletişim protokolleri, Ticari Şarj Operatörleri (CPO) için teknik stratejinin odak noktası haline geldi. Open Charge Alliance (OCA) tarafından sürdürülen Açık Şarj Noktası Protokolü (OCPP), basit bir mesajlaşma çerçevesinden gelişmiş, güvenli ve yüksek ölçeklenebilir bir standarda dönüştü.

Bu kılavuz, OCPP 1.6J'den OCPP 2.0.1'e geçişin kapsamlı bir teknik analizini sunmaktadır. Mimari farklılıkları, güvenlik geliştirmelerini, cihaz yönetimi paradigmalarını ve ISO 15118 entegrasyonunun kritik rolünü inceliyoruz. Alıcılar ve operatörler için bu makale, hızla olgunlaşan bir pazarda bilinçli satın alma ve geçiş kararları almak için kesin bir referans niteliğindedir.

Bölüm 1: Elektrikli Araç Şarj Standartlarının Evrimi: Tarihsel Bir Bağlam

Açık Şarj Noktası Protokolü (OCPP), birlikte çalışabilirlik ihtiyacından doğmuştur. Elektrikli araç şarjının ilk dönemlerinde, donanım üreticileri ve yazılım sağlayıcıları, rekabeti ve yeniliği engelleyen "kapalı sistemler" oluşturan tescilli protokoller kullanmışlardır. OCPP 1.2 ve 1.5'in tanıtımı temeli atmış olsa da, sektörü gerçekten birleştiren OCPP 1.6 olmuştur.

1.1 OCPP'nin Hakimiyeti 1.6J

2015 yılında yayınlanan OCPP 1.6, WebSockets üzerinden JSON (1.6J) uygulamasını tanıttı. SOAP tabanlı mesajlaşmadan bu şekilde uzaklaşmak, ek yükü önemli ölçüde azalttı ve geliştiriciler için uygulamayı basitleştirdi. Akıllı şarj ve ek durum bildirimleri gibi özellikler sunarak neredeyse on yıldır sektör standardı haline geldi.

1.2 OCPP 2.0.1'in Doğuşu

1.6J'nin başarısına rağmen, sektörün büyümesi sınırlılıklarını ortaya çıkardı. Güvenlik sorunları, cihaz yönetimi karmaşıklığı ve gelişmiş şebeke entegrasyonu (V2G) için yerel desteğin olmaması, OCPP 2.0'ın ve ardından geliştirilmiş OCPP 2.0.1'in (2020'de yayınlandı) geliştirilmesine yol açtı. OCPP 2.0.1 sadece bir güncelleme değil; yeni nesil yüksek güçlü, akıllı ve güvenli şarj ağlarını desteklemeyi amaçlayan tamamen yeniden tasarlanmış bir üründür.

Bölüm 2: Temel İletişim Paradigmları: JSON, WebSockets ve Çerçeve Yapıları

Bu protokoller arasındaki farkı anlamak için, düşük seviyeli iletişime bakmak gerekir. Her iki protokol de WebSocket üzerinden JSON kullanır, ancak bu mesajların yapısı ve işlenmesi önemli ölçüde farklılık gösterir.

2.1 WebSocket Katmanı

Her iki sürüm de tam çift yönlü iletişime olanak sağlayan kalıcı WebSocket bağlantıları kullanır. Bu, mobil uygulamadan şarj oturumunu durdurmak veya anlık arıza uyarıları almak gibi gerçek zamanlı işlemler için kritik öneme sahiptir.

2.2 Mesaj Çerçevesi Ayrıştırması

Tipik bir OCPP mesajı, mesaj türü kimliği, benzersiz mesaj kimliği, işlem adı ve veri yükünden oluşur.

OCPP 1.6J Çerçeve Örneği (Önyükleme Bildirimi)

“json [2, "123456", "BootNotification", { "chargePointVendor": "MidaPower", "chargePointModel": "Terra-X", "chargePointSerialNumber": "SN001", "firmwareVersion": "v1.2.3" }]“

OCPP 2.0.1 Çerçeve Örneği (Önyükleme Bildirimi)

“json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`2.0.1 sürümünde artan ayrıntı düzeyine dikkat edin.`reason` alanı, CSMS'nin önyüklemenin yeniden başlatma, güç açma veya izleme tetikleyicisi nedeniyle olup olmadığını anlamasına olanak tanıyarak daha iyi teşhis mantığı sağlar.

Bölüm 3: Mimari Paradigma Değişimi: Cihaz Modeli

OCPP 2.0.1'deki en önemli teknik değişiklik, aşağıdakilerin getirilmesidir:Cihaz Modeli.

3.1 1.6J Yapılandırma Anahtarlarının Sınırlamaları

OCPP 1.6J'de donanım yapılandırması, "Yapılandırma Anahtarları"ndan oluşan düz bir liste aracılığıyla yönetiliyordu (örneğin,Kalp Atışı Aralığı, Bağlantı Zaman AşımıŞarj cihazları daha karmaşık hale geldikçe (çoklu bağlantı noktaları, entegre güç modülleri, karmaşık soğutma sistemleri), bu düz liste yönetilemez hale geldi. Bir istasyonun fiziksel hiyerarşisini tanımlamanın standart bir yolu yoktu.

3.2 2.0.1 Cihaz Modeli Yaklaşımı

OCPP 2.0.1, aşağıdaki bileşenlerden oluşan hiyerarşik bir model sunmaktadır:BileşenlerVeDeğişkenlerBir bileşen "Denetleyici", "Bağlayıcı" veya "Güç Modülü" olabilir. Her bileşenin durumunu veya yapılandırmasını temsil eden değişkenleri vardır (örneğin,Sıcaklık, Gerilim, Maksimum Akım).

• BileşenŞarj istasyonunun fiziksel veya mantıksal bir parçası.
• Değişken: O bileşenin belirli bir özelliği.
• Özellikler: Değişkeni tanımlayan meta veriler (birim, aralık, erişim türü).

Bu, standartlaştırılmış izleme olanağı sağlar. Operatör artık, satıcıya özgü tescilli anahtarlara güvenmek yerine, standartlaştırılmış bir yol kullanarak belirli bir güç modülünün sıcaklığını sorgulayabilir.

Bölüm 4: Siber Güvenlik: "En İyi Çaba"dan Zorunlu TLS'ye

Elektrikli araç şarjının ilk dönemlerinde güvenlik genellikle sonradan düşünülen bir konuydu. OCPP 1.6J güvenlik profilleri sunuyordu, ancak uygulama farklı üreticilerde tutarsızdı.

4.1 1.6J'deki Güvenlik Profilleri

OCPP 1.6J üç güvenlik profili tanımlamıştır:

1. Güvencesiz: Düz metin HTTP/WebSocket'ler.
2. Temel Kimlik DoğrulamaTLS, kullanıcı adı/şifre ile.
3. Sertifika tabanlıİstemci tarafı sertifikalarıyla TLS.

Sorun şu ki, birçok şarj cihazı Profil 1'de kalmış ve bu da onları ortadaki adam (MITM) saldırılarına ve yetkisiz kontrole karşı savunmasız bırakmıştı.

4.2 2.0.1'in Sert Tutumu

OCPP 2.0.1, güvenli iletişimi zorunlu kılar. Gelişmiş güvenlik özelliklerini yerleşik olarak entegre eder:

• Güvenli Ürün Yazılımı Güncellemeleri: Ürün yazılımı imajlarının zorunlu olarak imzalanması ve doğrulanması.
• Güvenlik GünlüğüGüvenlikle ilgili olaylara ilişkin ayrıntılı kayıtlar (örneğin, başarısız giriş denemeleri, sertifika süresinin dolması).
• Sertifika Yönetimi: Döndürülen ve güncellenen sertifikalar için standartlaştırılmış mesajlar (CSMS tarafından veya İstasyon tarafından yönetilen).
• TLS 1.2/1.3En yeni şifreleme standartlarına destek.

Ticari operatörler için bu, büyük çaplı ağ ihlallerinin riskini azaltır ve IoT cihazları için ortaya çıkan siber güvenlik düzenlemelerine uyumu sağlar.

Bölüm 5: ISO 15118 Entegrasyonu: Tak ve Şarj Et ve V2G

Elektrikli araç şarjının geleceği sadece elektronların hareket ettirilmesiyle ilgili değil; akıllı veri ve enerji alışverişiyle ilgili. ISO 15118, araçtan şebekeye (V2G) iletişim için uluslararası standarttır ve OCPP ile entegrasyonu, 2.0.1 sürümünün belirleyici özelliğidir.

5.1 Tak ve Şarj Etmenin Karmaşıklığı

Tak ve Şarj Et (PnC), sürücünün herhangi bir uygulama veya RFID kartı kullanmadan aracını prize takıp şarj etmeye başlamasına olanak tanır. Bu, araç, şarj cihazı, operatör ve takas merkezini içeren karmaşık bir Açık Anahtar Altyapısı (PKI) gerektirir.

OCPP 1.6J'de, temel protokolde PnC desteği yoktu. Satıcılar özel uzantılar uygulamak zorunda kaldılar, bu da parçalanmaya yol açtı. OCPP 2.0.1, aşağıdaki özellikleri destekleyerek PnC için "altyapıyı" sağlar:

• Sertifika KurulumuCSMS'den EVSE aracılığıyla EV'ye sözleşme sertifikalarının aktarılması.
• YetkilendirmeAraç sertifikasından elde edilen e-Mobilite Kimliği (eMAID) kullanılarak.
• Şifreli İletişimAraç ile şebeke arasında aktarılan hassas faturalama verilerinin korunmasını sağlamak.

5.2 Akıllı Şarj ve Yük Dengeleme

1.6J temel akıllı şarjı desteklerken (gönderme),Şarj Profili Ayarla), 2.0.1 sürümü bunu daha da geliştiriyor. Şunlara olanak tanıyor:

• Harici Sinyal EntegrasyonuŞebeke frekansına veya toptan fiyat sinyallerine gerçek zamanlı yanıt.
• Dinamik Yük Yönetimi: Yüzlerce bağlantı noktasına sahip bir tesiste güç dağıtımının daha ayrıntılı kontrolü.
• Araçtan Şebekeye (V2G)2.0.1 sürümü, çift yönlü enerji akışını desteklemek için gerekli veri alanlarını içerir ve elektrikli araçların şebeke için dağıtılmış enerji kaynakları (DER'ler) olarak işlev görmesine olanak tanır.

5.3 Kullanıcı Arayüzü/Kullanıcı Deneyimi Geliştirmeleri

OCPP 2.0.1, aşağıdaki gibi bilgilerin doğrudan şarj cihazının ekranında veya aracın gösterge panelinde görüntülenmesini destekler:

• Yerel para biriminde gerçek zamanlı fiyatlandırma.
• Pil seviyesinin %80'e ulaşması için tahmini süre (SoC).
• İşlem tamamlandığında detaylı makbuz bilgileri verilecektir.

Bölüm 6: Gelişmiş Cihaz Yönetimi ve İzleme

Sertifikalı ikinci el şarj cihazı (CPO) için, şarj cihazının maliyeti sadece satın alma fiyatı değil; Toplam Sahip Olma Maliyeti (TCO)'dir. Bakım ve arıza süreleri en büyük kar kayıplarıdır. OCPP 2.0.1, üstün izleme yetenekleriyle bu sorunu çözmektedir.

6.1 Olay Odaklı Raporlama

1.6J'de, CSMS genellikle şarj cihazının durumunu sorgulamak veya bir süre beklemek zorundaydı.Durum Bildirimi2.0.1 sürümünde,Olay İzlemeSistem, CSMS'nin eşik değerler belirlemesine olanak tanır. Örneğin: "Yalnızca iç sıcaklık 70°C'yi aşarsa beni bilgilendir" veya "Giriş voltajı 200V'nin altına düşerse rapor ver". Bu, ağ trafiğini azaltır ve proaktif bakıma olanak tanır.

6.2 İşlem Yönetimi: TransactionEvent

OCPP 1.6J'nin en çok eleştirilen yönlerinden biri, işlemlerin ele alınış biçimiydi. Bir oturumda bu konu ele alındı.İşlemi BaşlatVeİşlemi DurdurMesajlar iletilebiliyordu, ancak bir ağ kesintisi meydana gelirse, CSMS genellikle faturalama verilerini uzlaştırmakta zorlanıyordu.

OCPP 2.0.1, bunları tek ve sağlam bir yapıyla değiştiriyor.İşlemOlayıBu mesaj, bir işlemin tüm yaşam döngüsü aşamalarını (Başlatıldı, Güncellendi, Bitti) bildirmek için kullanılır. Benzersiz bir kimlik numarası içerir.işlem kimliğiŞarj cihazı yeniden başlatılsa bile bu durum devam eder ve böylece şarj verilerinin ve dolayısıyla gelirin kaybolmaması sağlanır.

6.3 Geliştirilmiş Tanılama ve Sorun Giderme

OGetLogVeTanı Durumu Bildirimi2.0.1 sürümündeki mesajlar daha yapılandırılmıştır. CPO'lar belirli günlük türlerini (Güvenlik, Tanılama, Kullanıcı) talep edebilir ve zaman aralığını belirtebilir. Bu, uzaktan destek ekiplerinin bir teknisyeni sahaya göndermeden sorunları çözmesine olanak tanıyarak işletme giderlerini önemli ölçüde düşürür.

Bölüm 7: Donanım Yazılımı Güncelleme Mekanizmaları: Güvenilirlik ve Geri Alma İşlemleri

Donanım yazılım güncellemeleri, gelişen donanımların can damarıdır, ancak başarısız bir güncelleme şarj cihazını kullanılamaz hale getirebilir.

7.1 1.6J Güncelleme Süreci

1.6J'de,Firmware GüncellemesiKomut nispeten basitti. Şarj cihazı imaj dosyasını indirir ve yüklemeye çalışırdı. Çok aşamalı güncellemeler veya doğrulanmış geri alma işlemleri için standart bir mekanizma yoktu.

7.2 2.0.1 Çok Adımlı Güncelleme

OCPP 2.0.1, ürün yazılımı güncellemeleri için daha gelişmiş bir yaşam döngüsü sunuyor:

1. İndirmekŞarj cihazı görüntüyü alır ve sağlama toplamını/imzasını doğrular.
2. KurulumGüncelleme ikincil bölüme uygulanıyor.
3. DoğrulamaSistem, yeni bellenim yazılımının doğru şekilde başlatılıp başlatılmadığını kontrol eder.
4. AktivasyonBirincil bölüm değiştirildi.

Herhangi bir adım başarısız olursa, protokol şarj cihazının önceki kararlı sürüme nasıl geri döneceğini ve CSMS'ye belirli hata kodunu nasıl bildireceğini tanımlar. Bu güvenilirlik düzeyi, büyük ölçekli ticari uygulamalar için vazgeçilmezdir.

7.3 İmza Doğrulama

Kötü niyetli kişilerin tehlikeli yazılım yüklemesini önlemek için, 2.0.1 sürümü dijital imzaların kullanılmasını zorunlu kılıyor. Şarj cihazı, üreticinin özel anahtarıyla imzalanmamış hiçbir kodu çalıştırmayı reddedecek ve donanım düzeyindeki saldırılara karşı kritik bir koruma katmanı ekleyecektir.

Bölüm 8: Veri Gizliliği, Mevzuat Uyumluluğu ve GDPR

Elektrikli araç şarjı günlük bir ihtiyaç haline geldikçe, üretilen kişisel veri miktarı da şaşırtıcı boyutlara ulaşıyor. Tek bir şarj seansı, kullanıcının kimliğini, aracının konumunu, seyahat alışkanlıklarını ve finansal bilgilerini birbirine bağlayabiliyor.

8.1 OCPP'de Kişisel Olarak Tanımlanabilir Bilgiler (PII)

Avrupa'daki Genel Veri Koruma Yönetmeliği (GDPR) ve Kaliforniya'daki CCPA gibi benzer yasalar bağlamında, aşağıdaki gibi veri noktaları:idTag(RFID) veyaEVCCID(Araç Tanımlayıcısı) Kişisel Tanımlayıcı Bilgi olarak kabul edilir.

OCPP 2.0.1, veri anonimleştirme için daha iyi kontroller sunmaktadır. Örneğin,Özel VerilerBu alanlar, operatörlerin kişisel tanımlayıcı bilgileri (PII) temel protokol günlüklerine ifşa etmeden meta verileri saklamasına olanak tanır. Ayrıca, geliştirilmiş güvenlik profilleri, bu verilerin hem iletim sırasında hem de depolama sırasında şifrelenmesini sağlar.

8.2 Unutulma Hakkı ve Veri Taşınabilirliği

2.0.1 Cihaz Modelinin yapılandırılmış doğası, CSMS sağlayıcılarının "veri silme" isteklerini uygulamalarını kolaylaştırır. 1.6J sisteminde, farklı yapılandırma anahtarları ve günlükler arasında bir kullanıcının kimliğinin tüm örneklerini bulmak manuel bir kabustu. 2.0.1'de, cihaz durumu ve işlem verileri arasındaki net ayrım, daha temiz bir veritabanı mimarisine olanak tanır.

8.3 Nesnelerin İnterneti Güvenlik Yasalarına Uyumluluk

Birçok bölge artık IoT cihazlarının benzersiz şifrelere ve güvenli güncelleme mekanizmalarına sahip olmasını gerektiren yasalar çıkarıyor. OCPP 2.0.1'in zorunlu TLS ve imzalı bellenimi sadece "isteğe bağlı" özellikler değil; Kaliforniya ve İngiltere gibi pazarlarda donanım satışı için yasal gerekliliklerdir.

Bölüm 9: Alıcının Bakış Açısı: Toplam Sahip Olma Maliyeti (TCO), Yatırım Getirisi (ROI) ve Stratejik Geçiş

Ticari şarj istasyonları işleten bir operatör için, 1.6J sürümünde kalma veya 2.0.1 sürümüne geçme kararı tamamen finansal bir karardır.

9.1 Uygulama Maliyeti

• OCPP 1.6JUygulaması ucuz, düşük maliyetli donanımlar tarafından yaygın olarak destekleniyor, ancak bakım ve güvenlik riskleri açısından yüksek gizli maliyetler taşıyor.
• OCPP 2.0.1CSMS, EVSE'de daha güçlü işlemcilere ve daha fazla belleğe ihtiyaç duyar. Protokolün karmaşıklığı nedeniyle CSMS'nin geliştirme maliyetleri daha yüksektir. Bununla birlikte, uzaktan yönetim ve daha iyi güvenilirlik sayesinde önemli işletme gideri tasarrufu sağlar.

9.2 “Sorunsuz Yükseltme” Efsanesi

Genellikle 1.6J şarj cihazlarının yazılım yoluyla 2.0.1 sürümüne yükseltilebileceği söylenir. Gerçekte bu nadiren doğrudur. 2.0.1 sürümünün bellek ve işlemci gereksinimleri (özellikle TLS sertifikalarının işlenmesi ve Aygıt Modelinin karmaşık JSON ayrıştırması), genellikle eski 1.6J kontrol cihazlarının kapasitesini aşmaktadır.

9.3 Stratejik Göç Yolları

CPO'lar "Hibrit Ağ" yaklaşımını göz önünde bulundurmalıdır:

1. Eski SitelerMevcut düşük güçlü AC şarj cihazları için 1.6J'lik şarj işlemine devam edin.
2. Yeni DC Hızlı Şarj İstasyonları: PnC ve V2G'yi desteklemek için tüm yeni yüksek güçlü kurulumlar için 2.0.1 numaralı zorunluluk.
3. Proxy Çözümleri: CSMS için 1.6J mesajlarını 2.0.1 uyumlu bir biçime çevirebilen bir protokol ağ geçidi kullanın; bu, tek bir birleşik yönetim panosuna olanak tanır.

Bölüm 10: Geleceğe Hazırlık: OCPP 2.1 ve Otonom Şarja Giden Yol

2.0.1 sürümü giderek daha fazla ilgi görürken, Open Charge Alliance şimdiden OCPP 2.1 üzerinde çalışıyor. Bu gelecekteki sürüm, protokolün erişim alanını daha da genişletecek.

10.1 Çift Yönlü Şarj (V2X)

2.0.1 sürümü temel V2G'yi desteklerken, 2.1 sürümü Araçtan Eve (V2H) ve Araçtan Binaya (V2B) iletişimini geliştirerek, elektrikli araçların elektrik kesintileri sırasında evlere enerji sağlamasına veya ticari binalardaki en yüksek talep yükünü azaltmasına olanak tanıyacak.

10.2 Kablosuz Şarj Desteği

Otonom araçlar (AV'ler) ortaya çıktıkça, manuel şarj işlemi geçerliliğini yitirecektir. OCPP 2.1, insan müdahalesi olmadan hizalama ve enerji transferini yöneten, endüktif (kablosuz) şarj için standartlaştırılmış mesajlar içerecektir.

10.3 Akıllı Şehirlerle Entegrasyon

Gelecek sürümlerde trafik yönetim sistemleri ve yenilenebilir enerji tahminleriyle daha derin entegrasyon görülecektir. Şarj istasyonları gerçek zamanlı enerji piyasalarında güç için "teklif verebilecek" ve şarj ağları devasa sanal enerji santrallerine (VPP'ler) dönüşecektir.

Teknik Ek: Mesaj Karşılaştırmalarına Derinlemesine Bakış

En kapsamlı teknik detayı sunmak için, şimdi iki sürüm arasındaki belirli mesaj dizilerini ve çerçeve farklılıklarını analiz edeceğiz.

A.1 Yetkilendirme Akışı

1.6J sürümünde yetkilendirme, "Kabul Edildi" veya "Engellendi" şeklinde ikili bir yanıttı.

1.6J AuthorizeResponse:“json [3, "123456", { "idTagInfo": { "status": "Accepted", "expiryDate": "2026-12-31T23:59:59Z" } }]“

2.0.1 sürümünde, yanıt daha fazla bağlam içermektedir, örneğin:idTokenKullanıcı arayüzü için tür ve ek bilgiler.

2.0.1 AuthorizeResponse:“json [3, "987654", { "idTokenInfo": { "status": "Accepted", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "Tekrar hoş geldin, John! Bakiyen 45,00 $" } } }]“

A.2 Kalp Atışı ve Bağlantı Yönetimi

OCPP 2.0.1, istasyonun "çalışır durumda" olduğunu kanıtlama yöntemini optimize eder. 1.6J sürümünde, eğer birKalp atışıBaşarısız olursa, istasyon genellikle tekrar tekrar denemeye devam ederdi. 2.0.1 sürümünde, istasyon şunu kullanabilir:NotifyEventBirincil sunucuyla bağlantıyı sürdürürken, ikincil sunucuyla olan bağlantısının kesildiğini bildiren mekanizma.

A.3 Detaylı Meta Veri Tablosu

Çözüm

OCPP 1.6J'den 2.0.1'e geçiş, yalnızca bir yazılım güncellemesi değil; elektrikli mobilite ekosisteminin temel bir evrimidir. Ticari operatörler için 1.6J güvenilir geçmişi temsil ederken, 2.0.1 ölçeklenebilir, güvenli ve akıllı bir geleceği temsil etmektedir.

Bugün 2.0.1'i seçmek, uzun ömürlülüğe yapılan bir yatırımdır. Donanımınızın yeni nesil elektrikli araçlarla uyumlu olmasını, sıkılaşan siber güvenlik düzenlemelerine uygun olmasını ve V2G ve akıllı şebeke entegrasyonunun kazançlı fırsatlarına hazır olmasını sağlar. Piyasa konsolide olurken, en sağlam ve esnek protokol yığınlarına sahip operatörler öncü rol üstlenecektir.

Bölüm 11: Derinlemesine İnceleme: Mesaj Akışı Analizi ve Sıralama Diyagramları

Bu bölümde, 1.6J ve 2.0.1 sürümleri arasındaki operasyonel farklılıkları göstermek amacıyla EVSE ve CSMS arasındaki etkileşim dizilerini analiz edeceğiz.

11.1 Önyükleme ve Yapılandırma Sırası

Bir şarj cihazı ağa ilk bağlandığında, kendini tanımlamalı ve yapılandırmasını senkronize etmelidir.

OCPP 1.6J Akışı:

1. WebSocket Bağlantısı: 80 veya 443 numaralı liman üzerinden kurulmuştur.
2. Önyükleme Bildirimiİstasyon, üretici, model ve seri numarasını gönderir.
3. Yapılandırmayı AlCSMS, mevcut durumu kontrol etmek için tüm anahtarları talep eder.
4. Yapılandırmayı DeğiştirCSMS belirli anahtarları günceller (örneğin,Kalp Atışı Aralığı).
5. Durum Bildirimiİstasyon "Mevcut" diye bildiriyor.

OCPP 2.0.1 Akışı:

1. Güvenli TLS El SıkışmasıZorunlu sertifika değişimi.
2. Önyükleme Bildirimiİçerirsebep(örneğin,Güçlendirme).
3. GetBaseReportCSMS, tüm anahtarları istemek yerine, Aygıt Modelinin tam hiyerarşisini sağlayan bir "Temel Rapor" ister.
4. Değişkenleri AyarlaCSMS değişkenleri günceller. 2.0.1 sürümünün atomik güncellemelere izin verdiğini unutmayın; bu, tek bir mesajda birden fazla değişkeni ayarlamayı ve hepsinin başarılı olup olmamasını sağlamayı mümkün kılar.
5. NotifyEventİstasyon, bileşenlerin ilk durumlarını bildiriyor.

11.2 Akıllı Şarj Anlaşması

Akıllı şarj özelliği, özellikle birden fazla şarj profilini yönetirken, 2.0.1 sürümünün gerçek anlamda öne çıktığı noktadır.

1.6J sürümünde CSMS bir mesaj gönderir.Şarj Profili AyarlaBu, bir yığın seviyesini ve bir zamanlama planını tanımlar. Bir istasyonun birden fazla bağlantı noktası varsa, profil işleme genellikle belirsizdir.

2.0.1 sürümünde,Şarj Profili Ayarlaaçıkça bir şeye bağlıdırşarjProfilAmacı.

• ŞarjİstasyonuMaksimumProfil: İstasyonun toplam alım kapasitesini sınırlar.
• TXDefaultProfile: Her yeni işlem için varsayılan değer.
• TXProfil: Devam eden bir işleme özel.

Ayrıca, 2.0.1 sürümü şunları desteklemektedir:Şarj Yığın Seviyesini AlBu mesaj, CSMS'nin hangi profillerin şu anda aktif olduğunu ve EVSE'nin dahili zamanlayıcısı tarafından nasıl önceliklendirildiklerini görmesini sağlar.

11.3 Uzaktan Tetikleme ve Kontrol

Uzaktan komutlar gibiUzaktan Başlatma İşlemi(1.6J) ile değiştirildiİşlemi Başlatma İsteği(2.0.1). Temel fark yüktedir. 2.0.1 sürümünde CSMS şunları içerebilir:şarj profiliBu, aracın ikinci bir mesaj beklemeden, doğru güç seviyesinde hemen şarj olmaya başlayabileceği, gecikmeyi azaltacağı ve şebeke istikrarını artıracağı anlamına gelir.

Bölüm 12: Düşük Seviyeli JSON Şeması ve Alan Karşılaştırmaları

Yazılım geliştiriciler ve sistem entegratörleri için şema değişiklikleri, geçiş sürecinin en emek yoğun kısmıdır.

12.1 Numaralandırılmış Türler (Enum'lar)

OCPP 2.0.1, standartlaştırılmış Enum sayısını önemli ölçüde artırarak, 1.6J uygulamalarında sorun yaratan "özel" durum kodlarına olan ihtiyacı azaltıyor.

• Sebep Numaralandırmaları: Gözlemci, PlanlanmışSıfırlama, UzaktanSıfırla, Güç Kaybı.
• Durum Numaralandırmaları: Dolu, Rezerve, Mevcut değil, Arızalı. 2.0.1 şunları ekler:Mevcut, Dolu, Rezerve, Mevcut değil, ArızalıAncak daha fazla ayrıntı için alt durumlar da mevcuttur.

12.2 Veri Tipleri ve Birimler

OCPP 2.0.1, standart birimlerin (SI) kullanımını resmileştirir. 1.6J'nin bazen ondalık hassasiyeti belirsiz bıraktığı durumlarda, 2.0.1 şunu kullanır:ondalıkFarklı tedarikçilerin donanımlarında tutarlı faturalandırmayı sağlamak için güç ve enerji değerlerine yönelik türler.

Bölüm 13: Vaka Çalışması: Küresel CPO Geçişi (1.6J'den 2.0.1'e)

Şimdi, 10.000 şarj noktasına sahip, sertifikalı ikinci el bir araç olan "MegaCharge"ın varsayımsal bir senaryosuna bakalım.

13.1 Aşama 1: Denetim

MegaCharge, 1.6J şarj cihazlarının %40'ının TLS 1.2'yi desteklemediğini keşfetti. Bu da söz konusu şarj cihazlarının yaklaşan devlet sözleşmeleri için uygun olmadığı anlamına geliyordu.

13.2 Aşama 2: CSMS Yükseltmesi

MegaCharge, yeni bir CSMS oluşturmak yerine "OCPP Çeviri Katmanı"nı uyguladı. Bu katman, eski donanımlar için 1.6J bağlantılarını ve yeni donanımlar için 2.0.1 bağlantılarını yönetirken, mobil uygulamalarına ve faturalama motorlarına birleşik bir API sunuyordu.

13.3 Aşama 3: Donanım Değişimi

Yoğun trafiğe sahip lokasyonlarda MegaCharge, 1.6J şarj cihazlarını 2.0.1 uyumlu DC hızlı şarj cihazlarıyla değiştirdi. Sonuç olarak, daha sağlam şarj altyapısı sayesinde "Başlatılamadı" oturumlarında %15'lik bir azalma sağlandı.İşlemOlayı2.0.1 sürümünde işleme.

13.4 Yatırım Getirisi Analizi

İlk yatırım 2 milyon dolardı. Ancak, (Cihaz Modelinin teşhis özelliği sayesinde) azalan bakım çağrıları yıllık 400 bin dolar tasarruf sağladı. Ek olarak, V2G frekans yanıtı pazarlarına katılabilme yeteneği yıllık 200 bin dolar ek gelir yarattı. Geri ödeme süresi yaklaşık 3,3 yıldı.

Bölüm 14: OCPP 2.0.1 Tedariki İçin Alıcının Nihai Kontrol Listesi

Yeni donanım veya yazılımları değerlendirirken, gerçek uyumluluğu sağlamak için bu kontrol listesini kullanın:

14.1 Donanım (EVSE) Gereksinimleri

• [ ]Güvenlik Profili 3 Desteğiİstemci tarafı sertifika yönetimini destekliyor mu?
• [ ]Çift Çekirdekli İşlemciTLS şifrelemesi ve JSON ayrıştırması için yeterli alan var mı?
• [ ]Güvenli Eleman (SE)Anakartta anahtarları saklamak için donanımsal bir güven kökü (root of trust) bulunuyor mu?
• [ ]ISO 15118-2/20 HazırKontrol ünitesi, PnC için gerekli olan üst düzey iletişimi yönetebiliyor mu?
• [ ]Ekran YeteneğiDonanım, OCPP aracılığıyla fiyat/durum bilgisi göstermeyi destekliyor mu?Veri AktarımıYoksa yerel mesajlar mı?

14.2 Yazılım (CSMS) Gereksinimleri

• [ ]Cihaz Modeli GörselleştirmesiKontrol panelinde şarj cihazlarının hiyerarşik görünümü gösterilebilir mi?
• [ ]Sertifika Yetkilisi (CA) EntegrasyonuCSMS otomatik olarak sertifika düzenleyebilir ve sertifikaları güncelleyebilir mi?
• [ ]İşlem MutabakatıSistem, 1.6J eski şarj cihazlarından kaynaklanan "bekleyen" işlemleri nasıl ele alıyor?
• [ ]Akıllı Şarj Motoru2.0.1 sürümünün gelişmiş yığın seviyesi mantığını destekliyor mu?
• [ ]ÖlçeklenebilirlikWebSocket işleyicisi aynı anda 50.000'den fazla kalıcı TLS bağlantısını yönetebilir mi?

Bölüm 15: Sık Karşılaşılan OCPP Uygulama Sorunlarının Giderilmesi

Standart bir uygulama olsa bile, uygulamalar farklılık gösterir. İşte en sık karşılaşılan sorunlar.

15.1 WebSocket Zaman Aşımı

Birçok ağ güvenlik duvarı, kullanılmayan TCP bağlantılarını kapatır. EğerKalp Atışı AralığıAyar çok yüksekse, şarj cihazı bağlantısı kesilebilir.

• Çözüm: Emin olmakKalp Atışı AralığıBu değer, güvenlik duvarının zaman aşımı süresinden (genellikle 60-120 saniye) daha düşüktür.

15.2 Sertifika Zinciri Sorunları

2.0.1 sürümünde sık karşılaşılan bir hata "Güvenilmeyen Sertifika" hatasıdır. Bu genellikle şarj cihazında CSMS'nin Kök CA'sının kurulu olmaması durumunda ortaya çıkar.

• Çözüm: KullanınSertifika YükleDevreye alma sırasında güven zincirinin tamamlandığından emin olmak için mesaj gönderilir.

15.3 JSON Veri Yükü Boyutu

Bazı 2.0.1 mesajları (örneğin)GetBaseReport(Bu değer çok büyük olabilir. Şarj cihazının tampon belleği çok küçükse, mesaj kaybolacaktır.)

• Çözüm: Kontrol edinMaksimumMesajBoyutuCihaz Modelindeki değişkeni belirleyin ve CSMS'nin bu sınıra uymasını sağlayın.

Bölüm 16: Bölgesel Düzenleyici Ortamlar ve Protokol Zorunlulukları

OCPP 2.0.1'e geçiş sadece teknolojiyle yönlendirilmiyor; giderek artan bir şekilde yasal bir mesele haline geliyor.

16.1 Avrupa Birliği (AFIR)

AB'deki Alternatif Yakıt Altyapısı Yönetmeliği (AFIR), fiyat şeffaflığı ve birlikte çalışabilirliği zorunlu kılmaktadır. OCPP 2.0.1'i açıkça belirtmese de, "gerçek zamanlı veri paylaşımı" ve "akıllı şarj" gerekliliği, 2.0.1'i yeni kamu altyapısı için tek geçerli standart haline getirmektedir.

16.2 Kuzey Amerika (NEVI)

Amerika Birleşik Devletleri'nde, Ulusal Elektrikli Araç Altyapısı (NEVI) formül programı, şarj cihazlarının "birlikte çalışabilir" olmasını gerektiriyor. Kaliforniya gibi eyaletler daha da ileri gidiyor ve Kaliforniya Enerji Komisyonu (CEC), daha önce de bahsettiğimiz gibi, OCPP 2.0.1 aracılığıyla en iyi şekilde uygulanabilen ISO 15118 desteğini savunuyor.

16.3 Çin ve Asya-Pasifik

Çin'in kendi standartları (GB/T) olmasına rağmen, ihracata odaklı üreticiler OCPP 2.0.1'e yoğun yatırım yapıyor. Avustralya ve Singapur gibi pazarlarda, kamu şarj ağları için açılan devlet ihalelerinde artık neredeyse tamamen OCPP 2.0.1 Güvenlik Profili 3 şartı aranıyor.

Bölüm 17: Uygulama Kod Parçaları: "Detaylar"

Geliştiricilere yardımcı olmak amacıyla, karmaşık 2.0.1 görevleri için kavramsal JSON gösterimleri sunuyoruz.

17.1 Sertifika Yenileme Akışı

Bir sertifikanın geçerlilik süresi dolmaya yaklaştığında, CSMS'nin bir yenileme işlemi başlatması gerekir.

1. CSMS gönderirSertifika İmzalandı:“json [2, "CERT-01", "CertificateSigned", { "certificateChain": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----", "certificateType": "V2G" }]“

2. İstasyon yanıt veriyorKabul edildi:“json [3, "CERT-01", { "status": "Accepted" }]“

3. İstasyon gönderiyorGüvenlikOlayBildirimi:“json [2, "EVT-99", "SecurityEventNotification", { "type": "CertificateRotated", "timestamp": "2026-08-09T10:00:00Z" }]“

17.2 Şebekeye Duyarlı Şarj Profilinin Ayarlanması

Şebeke operatörünün şebeke genelindeki gücü kısıtlaması gerektiğini hayal edin.

CSMS gönderirŞarj Profili Ayarla:“json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "Absolute", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]“

Bölüm 18: OCPP 2.0.1 Terimlerinin Kapsamlı Sözlüğü

Tüm paydaşlar için netliği sağlamak amacıyla genişletilmiş bir sözlük sunuyoruz.

• CSMS (Şarj İstasyonu Yönetim Sistemi)Şarj cihazlarını kontrol eden arka uç bulut platformu.
• EVSE (Elektrikli Araç Şarj Ekipmanı): Fiziksel şarj istasyonu.
• OCPP (Açık Şarj Noktası Protokolü)Konuştukları dil.
• OCA (Açık Şarj İttifakı)Dili yazan kuruluş.
• ISO 15118Araç ile şarj cihazı arasındaki protokol.
• PnC (Tak ve Şarj Et)ISO 15118 ve OCPP 2.0.1 tarafından sağlanan kullanıcı deneyimi.
• V2G (Araçtan Şebekeye)Araçtan şebekeye geri güç gönderme.
• V2X (Araçtan Her Şeye)V2G, V2H ve V2B için kullanılan genel terim.
• TLS (Taşıma Katmanı Güvenliği)Verileri güvende tutan şifreleme.
• PKI (Açık Anahtar Altyapısı)Güvenlik amacıyla kullanılan dijital sertifika sistemi.
• JSON (JavaScript Nesne Gösterimi)Mesajların formatı.
• WebSocketMesajların aktığı kalıcı bağlantı "borusu".
• Cihaz Modeli: Donanımı tanımlayan hiyerarşik yöntem 2.0.1.
• Bileşen: Donanımın bir parçası (örneğin, Konnektör).
• Değişken: Bir bileşenin özelliği (örneğin, Durum).
• Bağlanmak: Bir değişkenle ilgili meta veriler (örneğin, Değer, Değiştirilebilirlik).
• İşlemOlayı: 2.0.1 sürümündeki tüm oturum verileri için birleşik mesaj.
• Kalp atışıPeriyodik olarak verilen "Hayattayım" sinyali.
• Önyükleme BildirimiŞarj cihazı çalışmaya başladığında verilen "Merhaba, buradayım" sinyali.
• Veri Aktarımı: Satıcıya özgü uzantılar için "her şeyi kapsayan" bir mesaj (dikkatli kullanın!).

Sonuç: Çok Protokollü Çağda Yolculuk

Alıcı veya işletmeci olarak en önemli çıkarım, yeni bir döneme girdiğimizdir.çoklu protokol çağıÖnümüzdeki 3-5 yıl boyunca 1.6J ve 2.0.1 birlikte var olacak. Ancak denge hızla değişiyor.

Bugün OCPP 2.0.1'i seçerek sadece bir protokol satın almıyorsunuz; bir sigorta satın alıyorsunuz. Ağınızın yeni araçlara, yeni yasalara ve yeni gelir akışlarına uyum sağlayabilmesini güvence altına alıyorsunuz. 2.0.1'in karmaşıklığı, ilerlemenin bedelidir; bu bedel, iyileştirilmiş çalışma süresi, azaltılmış risk ve üstün müşteri deneyimiyle kendini amorti eder.

Ticari şarj istasyonları artık niş bir sektör değil; geleceğin ulaşım sisteminin omurgasını oluşturuyor. Bu omurgayı mümkün olan en sağlam temel üzerine kurun: OCPP 2.0.1.

Bölüm 19: OCPP 2.0.1 için Geliştirme: Yazılım Mühendisleri için En İyi Uygulamalar

1.6J kod tabanından 2.0.1'e geçiş bir yeniden düzenleme değil, yeniden yazma işlemidir. Geliştiricilerin farklı bir zihinsel model benimsemeleri gerekir.

19.1 Asenkronluğu Benimsemek

WebSocket'ler doğası gereği eşzamansız olsa da, 2.0.1'in karmaşıklığı, tek bir isteğin (örneğin)GetBaseReportBu işlem, kaynak kısıtlı bir EVSE'de birkaç saniye sürebilir. CSMS geliştiricilerinin, farklı donanım üreticilerinin değişen işlem hızlarını dikkate alan sağlam bir zaman aşımı ve yeniden deneme mantığı uygulamaları gerekir.

19.2 Etkin JSON Ayrıştırma

JSON ayrıştırması işlemciyi yoğun olarak kullanabilir. EVSE bellenimi için geliştiriciler, tüm veri yükünü RAM'e yüklemek yerine akış tabanlı ayrıştırıcılar kullanmalıdır. Bu, özellikle aşağıdaki durumlar için önemlidir:NotifyEventTek bir karede yüzlerce değişken güncellemesi içerebilen mesajlar.

19.3 Durum Makinesinin İşlenmesi

2.0.1 sürümündeki bir işlemin durum makinesi, 1.6J sürümüne göre daha katıdır. Geliştiricilerin geçiş kurallarına kesinlikle uymaları gerekir.İşlemOlayıÖrneğin, bir e-posta gönderemezsiniz.Sona erdiönceden göndermeden gerçekleşen etkinlikBaşladıo özel etkinlik içinişlem kimliği.

Bölüm 20: Test Etme, Doğrulama ve OCPP Uyumluluk Test Aracı (OCTT)

OCPP'nin vaadi birlikte çalışabilirliktir, ancak bu ancak titiz testler yoluyla gerçekleştirilebilir.

20.1 OCA Sertifikasyonunun Rolü

Open Charge Alliance bir sertifikasyon programı sunmaktadır. Alıcılar "OCPP 2.0.1 Sertifikalı" etiketini aramalıdır. Bu sertifika, uygulamanın tüm zorunlu profilleri kapsayan bir dizi otomatik testten geçtiğini garanti eder.

20.2 OCTT Kullanımı

OCPP Uyumluluk Test Aracı (OCTT), test alanında altın standarttır. Hem bir CSMS'yi hem de bir EVSE'yi simüle eder.

• EVSE Üreticileri İçinİstasyonunuzun "sorunsuz çalışma" senaryolarını ve uç durumları (örneğin, ürün yazılımı güncellemesi sırasında ağ kesintileri gibi) sorunsuz bir şekilde ele aldığını doğrulamak için OCTT'yi kullanın.
• CSMS Sağlayıcıları İçinArka uç sisteminizin çok çeşitli mesajları ve 2.0.1 sürümünün katı güvenlik gereksinimlerini karşılayabildiğinden emin olmak için OCTT kullanın.

20.3 Saha Testleri ve Birlikte Çalışabilirlik Festivalleri

Otomatik testlerin ötesinde, OCA, satıcıların donanım ve yazılımlarını gerçek dünya senaryolarında birbirleriyle test etmek üzere getirdikleri "Plugfest" etkinlikleri düzenliyor. Sertifika uyumsuzluğu veya küçük JSON biçimlendirme farklılıkları gibi en ince hataların tespit edilip çözüldüğü yer burasıdır.

Bölüm 21: Derinlemesine Karşılaştırmalı Tablo: OCPP 2.0.1'in 60'tan Fazla Eylemi

Eksiksiz bir referans sağlamak amacıyla, 2.0.1 sürümünün temel mesajlarını kategorize edip 1.6J sürümündeki karşılıklarıyla karşılaştırıyoruz.

21.1 Sağlama ve Yapılandırma

21.2 İşlem Yönetimi

21.3 Güvenlik ve Donanım Yazılımı Yönetimi

21.4 Tablonun Ağınız İçin Anlamı

Tablo tek bir noktayı açıkça ortaya koyuyor: OCPP 2.0.1, 1.6J'nin kozmetik bir yeniden adlandırması değil. Yeni mesaj aileleri – tipli değişkenler, olay odaklı işlemler ve sertifika yönetimi – Tak ve Şarj Et, akıllı şarj ve düzenleyici raporlama için gerekli altyapıyı oluşturuyor. Sadece 1.6J ile çalışan bir şarj cihazına sonradan bir ağ geçidi eklenebilir, ancak sadece 1.6J ile çalışan bir CSMS, düzenleyicilerin ve otomobil üreticilerinin giderek daha fazla talep ettiği güvenlik modelini sağlayamaz. Donanımı değerlendirirken, "2.0.1'e hazır" ifadesi, ürün yazılımının gelecek yıla değil, bugün piyasaya sürüldüğü anlamına gelmelidir. Ve OCPP 2.0.1, 1.6J'nin SOAP taşıma yöntemi yerine JSON-over-WebSocket üzerinde çalıştığı için, mesaj akışları daha hafiftir ve hata ayıklaması çok daha kolaydır – BT ekibinizin ilk günden itibaren hissedeceği pratik bir avantaj.

Bölüm 22: Sonuç: Yükseltme Kararı Verme

Ticari bir işletmeci için pratik kılavuz açıktır:

• Yeni kurulumlarda varsayılan olarak OCPP 2.0.1 sürümü kullanılmalıdır.Güvenlik modeli, sertifika yönetimi ve ISO 15118 entegrasyonu, 2026 düzenleyici ortamı için ön koşullardır.
• Mevcut 1.6J filoları atıl durumda değil.Yönetilen ağ geçitleri ve çift protokollü CSMS platformları, 2.0.1 yerel donanımına geçiş sürecinde aradaki boşluğu doldurur.
• Güvenmeden önce test edin.OCTT, plugfest'ler ve aşamalı dağıtımlar kullanın; birlikte çalışabilirlik, veri sayfasından varsayılmak yerine sahada kanıtlanır.
• Göç yolunun yazılı olarak talep edilmesini isteyin.Şarj cihazı üreticiniz, belirsiz vaatler yerine, 1.6J'den 2.0.1'e kadar olan ürün yazılımı güncelleme yol haritasını tarihleriyle birlikte yayınlamalıdır.

Harekete Geçme Çağrısı: Protokol Stratejiniz Hakkında MIDA Power ile Görüşün

MIDA Power ships OCPP 1.6J and 2.0.1 on every charger, with field-upgradeable firmware and a cloud platform that manages mixed-protocol fleets in a single dashboard. Contact sales@midapower.com for our protocol migration guide, OCTT test reports, and a free compatibility review of your existing network.