Select Sidearea

Populate the sidearea with useful widgets. It’s simple to add images, categories, latest post, social media icon links, tag clouds, and more.

hello@youremail.com
+1234567890

CCP / XCP Protokolü

Vetes Mühendislik > CCP / XCP Protokolü

CCP / XCP Protokolü nedir?

CAN Kalibrasyon Protokolü (CCP), bir Elektronik Kontrol Ünitesine (ECU) okuma/yazma erişimi sağlayan bir arayüzdür. Kalibrasyon, veri ölçümü ve daha fazlasını mümkün kılar. Evrensel Ölçüm ve Kalibrasyon Protokolü (XCP), Ethernet, FlexRay gibi daha fazla veri hattı desteği de dahil olmak üzere çeşitli iyileştirmelerle CCP’nin halefidir. CCP / XCP protokolleri kapsamlı örtüşmelerin yanı sıra önemli farklılıklara da sahiptir. Karışıklığı önlemek için önce CCP protokolünü ele almaya odaklanacağız ve daha sonra önemli farklılıkları açıklığa kavuşturarak CAN üzerinde XCP’yi inceleyeceğiz.

 

CCP/XCP’ nin motivasyonunu anlamak için CAN veri hattına basit bir giriş yapalım. Burada açıklandığı gibi CAN, bir araç/makinedeki farklı ECU’lar arasında veri iletişimini sağlar. Her ECU’nun giriş ve çıkışları CAN veri yolu üzerinde yayınlanır. Ancak, bir ECU’nun iç işleyişi bir kara kutudur. Burada, CCP/XCP bir ECU’nun iç işleyişine doğrudan erişim sağlar. Bu, aksi takdirde yalnızca ECU tarafından bilinebilecek yüksek frekanslı parametre verilerini talep etmenizi sağlar. Ayrıca, ECU algoritmalarını ve değişkenlerini değiştirmenize de olanak tanıyarak ECU’ları test etmeyi ve kalibre etmeyi kolaylaştırır. Daha da önemlisi, CCP/XCP bu arayüzleri ECU üreticileri arasında standartlaştırılmış bir şekilde sağlar.

Usta-Köle (Master-Slave) Mimarisi

CCP/XCP protokolü tek usta (single-master) / çok köle (multi-slave) konseptine dayanır. Harici bir ölçüm ve kalibrasyon aracı (örneğin bir PC/cihaz/veri kaydedici) usta (master) görevi görür ve köle (slave) olarak adlandırılan bir veya daha fazla ECU’dan okuma/yazma yapabilir.


Master ve slave arasındaki arayüz ASAP1 veya ASAM MCD-1 olarak adlandırılır. CCP/XCP standardı ayrıca master ile ECU tanım dosyası arasındaki ASAP2 veya ASAM MCD-2 MC arayüzünü de tanımlar. Uygulamada, bu veri tabanı bir ECU hakkındaki tüm ilgili bilgileri A2L (ECU Açıklama Dosyaları) adı verilen standartlaştırılmış bir dosya formatında tanımlar.

ccp / xcp slave-master ilişkisi

CCP/XCP Kullanım Durumları

CCP/XCP protokolü çoklu kullanım durumlarına olanak sağlar:


• Tak ve çalıştır ECU ölçümü ve kalibrasyonu
• ECU verilerinin mikrosaniye çözünürlükte kaydedilmesi
• ECU’nun dahili verilerine erişim (CAN üzerinde yayınlanmaz)
• Yoklama yoluyla veya olaylara (zaman, tetikleyiciler) dayalı ölçüm
• ECU algoritma değişkenlerinin gerçek zamanlı kalibrasyonu/ayarlanması
• ECU’ların flaş programlanması
• Güvenli erişim için isteğe bağlı kimlik doğrulama
• Esas olarak OEM geliştirme için nadiren üretim sonrası kullanılır

 

XCP ve CCP'deki Önemli Değişiklikler

• XCP, CAN FD, Ethernet, FlexRay, SxL ve daha fazlası için destek ekler
• Daha az yorumlama daha tutarlı uygulamalar
• ECU hesaplamalarını atlamak için yeni ‘stimülasyon’ (STIM) modu
• Verimli iletişim için önceden tanımlanmış/dinamik DAQ listeleri
• Farklı DAQ modlarının senkronize kullanımı için destek
• ECU otomatik algılama (master bilgi için slave’leri sorgulayabilir)
• ECU zaman damgalarını ölçerek daha hassas veri toplama
• Yeni opsiyonel komutlar sayesinde daha fazla veri çıkışı

ccp- xcp veri hatları

CCP / XCP vs. UDS

CCP / XCP’yi daha derinlemesine incelemeden önce, bu iletişim protokollerinin biraz benzer bir protokol olan Birleşik Teşhis Hizmetleri (UDS) karşısındaki rolünü anlamak faydalı olabilir. Şekilden de anlaşılacağı üzere, CCP / XCP özellikle OEM’ler tarafından lansman öncesi ölçüm ve kalibrasyon için tasarlanmıştır. Tipik olarak, araçlar satışa hazır olduğunda ECU’lara CCP / XCP erişimi devre dışı bırakılır. Buna karşılık, UDS tipik olarak erken aşama prototip geliştirmede mevcut değildir ve ancak daha sonra eklenir. UDS tanılamaya odaklanırken CCP/XCP’nin tanılama yetenekleri hafiftir. UDS, örneğin saha teknisyenleri tarafından ve OEM’e özgü tarama araçlarında da kullanılabilir. Yine de iki protokol arasında benzerlikler vardır. Örneğin döngüsel veri toplama, ECU flaşlama ve adrese (CCP/XCP) veya kimliğe (UDS) göre okuma/yazma erişimi desteği.

CCP Mesaj Türleri

CCP iletişiminin nasıl çalıştığını anlamak için öncelikle CCP mesaj türlerini gözden geçireceğiz. Genel olarak, CCP iletişimi OBD2, UDS vb. sistemlerde kullanılana benzer bir istek/cevap mantığı üzerinden gerçekleştirilir. Bu iletişim iki tür mesajdan oluşur: Komut Alma Nesnesi (CRO) ve Veri İletim Nesnesi (DTO).

 

CRO – Komut Alma Nesnesi

Komut Alma Nesnesi (CRO), master tarafından bir ECU’ya gönderilen bir CAN çerçevesidir. Veri yükünün 1. baytı komut baytıdır (CMD). Bu, tabloya genel bakışa göre master tarafından ECU’ya hangi komutun verildiğini kontrol eder.


CCP CRO Komut Alma Nesnesi CAN Veri Hattı Çerçevesi

Verilen komutları izlemek için 2. bayt bir sayaçtır (CTR). Master tarafından gönderilen her komut için +1 ile girintilenir ve slave ECU’dan gelen yanıtta yansıtılır. Kalan 6 bayt komuta bağlıdır.

 

CCP CAN Çerçeve Tanımlayıcıları

CCP’de iki CAN tanımlayıcısı kullanılır: Biri master tarafından gönderilen mesajlar için (örn. 0x701) ve diğeri slave tarafından gönderilen mesajlar için (örn. 0x702). Bu tanımlayıcılar A2L’nin (diğer adıyla ECU Tanım Dosyası) bir parçası olarak belirtilir, yani master bağlantıyı başlatmadan önce bu bilgileri edinir. Tipik olarak düşük öncelikli ID’ler, veri yolundaki güvenlik açısından kritik bilgilerin bozulmasını önlemek amacıyla CCP için kullanılır.

Daha da önemlisi bu, master’ın çeşitli CAN ID’leri aracılığıyla belirli ECU’ları hedeflemediği, bunun yerine aşağıda gösterildiği gibi bir bağlantı dizisi aracılığıyla hedeflediği anlamına gelir.

DTO - Veri İletim Nesnesi

Veri İletim Nesnesi (DTO) ECU tarafından master’a gönderilen bir CAN çerçevesidir. Aşağıda belirtildiği gibi üç tip DTO mevcuttur:

 

1. CRM-DTO: Komut Yanıt Mesajı

CRM-DTO, ECU tarafından master’dan gelen bir CRO’ya yanıt olarak gönderilir. Burada CAN ID, ECU tarafından kullanılan CAN ID’yi yansıtır (örn. 0x702). CRM için veri yükü aşağıdaki gibi ayrılabilir:


• Birinci bayt Paket Tanımlayıcısıdır (PID). CRM-DTO için PID her zaman 0xFF’ye eşittir
• İkinci bayt hata kodudur (ERR), örneğin master’ı geçersiz bir talep hakkında bilgilendirmek için kullanılabilir.
• Üçüncü bayt, master’ın CRO’sundan gelen CTR değeriyle eşleşecek olan sayaçtır (CTR).
• Kalan 5 baytın yapısı CRO’da yapılan orijinal talebe bağlıdır.

ccp-xcp protokolü komut yanıt mesajı

2. EV-DTO: Olay Mesajı

EV-DTO, ECU’da bir durum değişikliğine neden olan dahili bir olaya yanıt olarak ECU tarafından gönderilir. Bu, son CRO’dan bu yana meydana gelen hataları master’a bildirmek için kullanılabilir. EV-DTO’nun yapısı daha önceki CRM-DTO ile aynıdır ve EV PID’si her zaman 0xFE’ye eşittir. TO’nun EV-DTO’lar için bir önemi olmadığını unutmayın.

ccp-xcp olay mesajı

3. DAQ-DTO: Veri Toplama Mesajı

DAQ-DTO, ECU tarafından belirli bir olaya (örneğin bir döngüsel sayaç, bir düğme veya benzeri) yanıt olarak master’a otomatik olarak veri göndermek için kullanılır. DAQ iletişiminde master, ECU’yu belirli bir ölçüm dizisi için ‘yapılandırarak’ başlar. ECU bir kez başlatıldığında, master’dan başka CRO’lar olmadan DAQ-DTO’ları çıkaracaktır. DAQ-DTO’da PID, bir ‘Nesne Tanımlayıcı Tablosu’na (ODT) referanstır ve 7 bayta kadar ODT ile ilgili veri taşır.

ccp-xcp veri toplama mesajı

CCP DAQ Aracılığıyla Veri Toplama

CCP, DAQ (Senkron Veri Toplama) adı verilen alternatif bir veri ölçüm tekniği sunar. DAQ’nun başlatılması biraz daha karmaşıktır, ancak yoklamanın her iki dezavantajını da çözer. Basit bir ifadeyle, DAQ aşağıdaki gibi çalışır:


• Master slave’den hangi ölçümlerin kaydedileceğini ve hangi olayın veri iletişimini tetikleyeceğini belirler. Örneğin, master A ve B sinyallerinin her 10 ms’de bir, C sinyalinin ise her 100 ms’de bir yayınlanmasını talep edebilir. Master, slave’leri düğmeye basma veya açı değişimi gibi olaylara göre sinyal yayınlayacak şekilde bile yapılandırabilir.
• DAQ yapılandırması tamamlandığında, master diziyi ‘başlatır’ ve slave artık DAQ-DTO mesajlarını kullanarak istenen sinyalleri otonom olarak yayınlar.
• Bu, master’dan gelen talep mesajlarını ortadan kaldırır. Ayrıca sinyal verileri, CRM-DTO’lara kıyasla DAQ-DTO’larda daha verimli bir şekilde paketlenerek veri yolu yükü azaltılır.
• Ayrıca, DAQ ile ilgili sinyalleri aynı DAQ-DTO çerçevelerinde paketlemek mümkündür. İstenen sinyallerin zaman senkronize bir şekilde ölçülmesini sağlar. Analiz için verilerin kalitesini artırır.

A2L - ECU Açıklama Dosyaları

Önceki bölümlerde zaman zaman “ECU tanım dosyalarından” bahsettik. Bir ECU açıklama dosyası, bir ana aracın bir ECU ile iletişim kurmak için bilmesi gereken her şeyi içerir. Veri ölçümü perspektifinden bakıldığında bu, CAN tanımlayıcıları, mevcut sinyaller, sinyal kod çözme kuralları, DAQ/ODT bilgileri vb. hakkındaki bilgileri içerir. Uygulamada, bu bilgileri yapılandırmak için ASAP2 tanımlama formatı (*.A2L) kullanılır. ASAP2 veri tanımı ASAM tarafından ASAM MCD-2 MC’de standartlaştırılmıştır ve ilk versiyon 1.3.1 15 Haziran 1999’da, yani CCP 2.1 standardının yayınlandığı yıl yayınlanmıştır. Standardın en son versiyonu olan 1.7.0 2015 yılında yayınlanmıştır.


Pratikte, A2L dosyası ECU ile iletişimi mümkün kılarak master cihazı “yapılandırmak” için kullanılır. Örneğin, önceki örneklerimizde master ve ECU arasındaki CRO/DTO iletişimi için 0x701 ve 0x702 CAN ID’lerini kullandık. Bu ID’ler A2L dosyasında belirtilecektir. A2L dosyası ayrıca sinyallerin ECU’da nasıl depolandığını ve bunların kodunun nasıl çözüleceğini de açıklar.

a2l dosyası

CAN Üzerinde XCP Temel Bilgiler

Şimdi CCP’nin temellerini gözden geçirdik. Daha sonra, çerçeve yapılarına odaklanarak CAN üzerinde XCP’yi ele alacağız. CAN üzerindeki XCP ile CCP’deki yapısal değişiklikleri anlamak için CCP CRO/DTO ile XCP CTO/DTO’nun aşağıdaki karşılaştırmasını göz önünde bulundurun.

ccp-xcp yapı karşılaştırma

Görüldüğü gibi, XCP paketleri XCP CTO (CCP CRO ve CRM-DTO ile benzer bir role sahip) ve XCP DTO (CCP DAQ-DTO ile benzer bir rol oynayan XCP DAQ-DTO ile) içerir.

 

XCP CTO – Komut Aktarım Nesnesi

CAN üzerindeki XCP’de CTO, komutlar (CMD), komut yanıtları (RES), hatalar (ERR), olaylar (EV) ve servis istekleri (SERV) dahil olmak üzere kontrol komutlarının aktarılması için bir CAN çerçevesidir. CCP’deki CRO’nun aksine, CTO hem master hem de ECU tarafından kullanılır. Ayrıca master’dan gelen bir CMD paketine ECU’dan bir RES veya ERR paketi ile cevap verilmesi gerektiğini, diğer paket türlerinin ise asenkron olarak gönderildiğini unutmayın. CTO yüküne bakarsak, 1. bayt bir Paket Tanımlayıcısını (PID) yansıtır. Bir XCP on CAN CTO yükünde geri kalan 7 bayt, CTO paketinin türüne özgü verilerden oluşur. Bu yapıyı CCP’nin CRO’su ile karşılaştırırsak, XCP’deki komut sayacı baytının hariç tutulması dışında benzerdir.


XCP iletişimi en az iki CAN veri yolu tanımlayıcısı gerektirir: Biri master için (örn. 0x551) ve diğeri ECU için (örn. 0x552). Master’ın XCP üzerinden birden fazla ECU ile iletişim kurması gerekiyorsa, ek bir tanımlayıcı seti gerekecektir.

 

XCP DTO: Veri Aktarım Nesnesi

XCP DTO, senkronize veri göndermek için kullanılır. DTO özellikle DAQ ölçümünde kullanılır (DAQ-DTO’nun CCP’deki rolüne benzer şekilde).

can üstünden xcp

XCP DTO Zaman Damgası

Bununla birlikte, XCP DAQ ölçümü hakkında dikkat edilmesi gereken önemli bir husus, ECU’nun XCP DTO paketlerine ölçüm zamanını yazmasını sağlamasıdır. Bunun anlamı, master’ın kendi dahili zaman damgası yerine ECU ölçüm zaman damgasını kullanarak birden fazla çerçeveye bölünmüş ECU verilerini doğru bir şekilde senkronize edebilmesidir. XCP DTO zaman damgası isteğe bağlıdır ve A2L dosyasında belirtilen artırma mantığı ile artan bir sayaç olarak uygulanır. Belirli bir DAQ listesi için bir zaman damgası eklenecekse, 1. ODT listesine yazılacaktır (ancak aynı DAQ listesinde daha fazla ODT listesi varsa sonrakilere yazılmayacaktır).

 

DAQ DTO’larında DAQ liste # ve ODT liste # bilgilerini paketlemek için birden fazla yöntemin mevcut olduğunu da belirtmek gerekir. En basit durum, ODT liste numarasının tüm DAQ listelerinde benzersiz olduğu ‘mutlak ODT numaraları’dır. Burada, PID (yani ODT #) bir ODT listesini global olarak tanımlamak için yeterlidir. Bununla birlikte, DAQ listeleri arasında göreceli ODT liste numaralarının kullanıldığı başka bir yöntem de mevcuttur. Böylece, örneğin PID = 0x00 olan iki ODT listesine sahip olabilirsiniz, yani CAN ID iki DTO’da aynı olduğu için benzersiz bir şekilde tanımlanamazlar. Burada, CAN çerçeve yükünün 2. ila 3. baytlarına 1 veya 2 baytlık bir DAQ listesi tanımlayıcısı eklenebilir. Bununla, belirli bir ODT listesi yine benzersiz bir şekilde tanımlanabilir.

 

Konuyla ilgili üretici firmamız Kvaser’in sayfasını incelemek için tıklayınız.