CANBUS Protokolü’nün Temeli ve Hızlı Uygulaması

ALPER PEKGÖGÜL

Merhabalar, bu blog yazımda ELFATEK’te hep merak ettiğim CANBUS Protokolünün temel kısmını ve staj esnasında bunu yaptığım projeye dayanarak anlatacağım.

CANBUS özetle anlatılırsa aslında bir hattır. Bu hattın en belirgin özelliği az kablo kullanılarak haberleşme sağlanması ve bu haberleşme esnasında herhangi bir anomali karşısında dirençli olmasıdır. Bu tek hat içinde haberleşmeyi sağlayan CAN-High ve CAN-Low adlı iki tane kablo bulunur ve sistemde bulunan tüm cihazlar bu iki kablo ile sistemin beyni yani ECU (Electronic Control Unit) ile haberleşip bu sistemdeki cihazlar gerekli komutları bu sayede uygulayabilmektedir.

CANBUS Nasıl Var Oldu? 

Aslında CAN hattının ortaya çıkış sebeplerine baktığımızda işin kökeni çok daha eskiye dayanıyor. Evimizde bir ışığı yakmak için düğmeye bastığımızda elektrik basitçe düğmeden geçerek lambaya ulaşıyor. Eskiden otomobillerde de benzer bir mantık vardı: aküden çıkan elektrik, farlara veya diğer sistemlere doğrudan kablolar aracılığıyla ulaşıyordu.

1915 yılında Henry Ford araçlarına far ve elektrikli korna ekleme fikrini ortaya attığında sistem bu şekildeydi. Ancak 1960’lara gelindiğinde artık her otomobilin içinde binlerce ağır kablo bulunuyordu. Bu durum üç temel problem doğurdu:

1. Ağırlık ve uzunluk: Elektronik bileşen sayısı arttıkça kabloların toplam uzunluğu ve ağırlığı da ciddi şekilde yükseldi. Her sensör, her aktüatör ve kontrol ünitesi için ayrı ayrı kablolar çekilmesi gerekiyordu.

2. Tekrarlanan sensörler: Aynı veriyi kullanacak farklı sistemler için çoğu zaman aynı tip sensörlerden birden fazla yerleştirmek zorunda kalınıyordu. Bu da hem maliyet hem karmaşıklık demekti.

3. Zorlaşan arıza tespiti: Araç içindeki kablo şemaları artık onlarca sayfaya sığmıyor, komponent sayısı arttıkça sistemin tanılanması da neredeyse imkânsız hale geliyordu. O dönemlerde kendi kendini teşhis eden bir sistem de henüz yoktu.

İşte tam bu noktada Bosch gibi firmalar, birden fazla ECU’nun ve otomobil sistemlerinin ortak bir iletişim hattı üzerinden konuşabileceği bir haberleşme standardı arayışına girdiler. Piyasada buna uygun bir çözüm bulamayınca Mercedes-Benz, Intel ve bazı Alman üniversiteleriyle birlikte Controller Area Network (CAN) sistemini geliştirmeye başladılar.

DELOCAN: Gerekli CAN-High ve CAN-Low bağlantıları bu cihaz ile sağlanarak bizim bilgisayardan haberleşmeyi sağlarız. Aslında CANBUS için en önemli başlangıcımız bu cihazı elde etmek olur. 

En Önemli Detay 120 ohm Sonlandırıcı Dirençler:
CAN hattının fiziksel katmanında önemli bir unsur da sonlandırıcı dirençlerdir. Bu dirençler, hatta oluşabilecek yansıma sinyallerini (eko) bastırmak için kullanılır. Eğer bu yansımalar engellenmezse veri iletimi bozulur. Özellikle hat uzunluğu arttıkça ve veri iletim hızı yükseldikçe bu olumsuz etki çok daha belirgin hale gelir.

Doğru seçilmiş sonlandırıcı dirençler sayesinde yansıma sinyali dengelenir ve iletişim sağlıklı biçimde devam eder. Genellikle sistemin iki ucuna 120 Ω’luk iki direnç yerleştirilir. Bu iki direnç birbirine paralel olduğundan hat boyunca ölçülen toplam direnç yaklaşık 60 Ω olur. Bazı otomobil üreticileri bu değeri farklı uygulayabilse de CANBUS’un çalışabilmesi için sonlandırma direncinin bulunması kritik bir gerekliliktir.

CAN Verisinin Yapısı (Frame):

CANBUS üzerinde veri alışverişi belirli bir çerçeve (frame) yapısı ile olur. Bu çerçeve, aslında kimin konuştuğunu ve ne söylediğini anlatan bir paket gibi düşünülebilir. Mantığını anlamak için bazı :

1. Arbitration Field (ID Alanı / Node ID) : Bu kısım mesajın kimden geldiğini ve önceliğini belirler. Burada ID değeri ne kadar küçükse önceliği o kadar yüksektir olur. Aslında cihazın ID’si o cihazın adı gibi düşünülebilir ve veri de kime geldiği anlaşılır ve komut gerçekleştirilir.

2. Control Field:  Bu bölüm, mesajın içinde kaç byte veri olduğunu (DLC – Data Length Code) söyler. CAN hattında en fazla 8 byte (klasik CAN için) veri taşınabilir.

3. Data Field (Veri Alanı): Asıl gönderilen bilginin bulunduğu kısım burasıdır. Örneğin, motor devri, sıcaklık ya da sensörden gelen başka bir değer bu byte’lara yazılır ve veri genelde hexadecimal (16’lık sistem) şeklinde ifade edilir.

4. CRC Field (Hata Kontrol Alanı)
Denetçi gibi davranır. Mesajın doğru gidip gitmediğini kontrol eder ve eğer hata varsa alıcı mesajı reddeder.

5. ACK ve End of Frame
Mesajı alan cihaz, mesajı doğru aldığını ACK ile onaylar sonra da çerçeve biter ve hat boşalır.

Üstteki görsel aslında bizim anlattığımız CAN çerçevesinin pratiğe dökülmüş halidir. Burada doldurduğumuz her kutucuk, CAN hattına gönderilecek mesajın bir parçasını oluşturuyor.

ID (hex): Bu kısım cihazın adı gibi düşünebiliriz. Örneğin ekranda görülen 601, o mesajı gönderen cihazın kimliği. Buradaki “1” kısmı cihazın Node ID’si yani kimliği oluyor. Sisteme başka cihazlar bağlandığında her birinin farklı bir ID’si olması gerekiyor ki herkes karışmadan sırayla konuşabilsin. Bunu sınıfta herkesin farklı numarası olması gibi düşünebiliriz ve öğretmen (yani ECU) kime sesleneceğini ID’den anlıyor.

DLC (Data Length Code): Bu kısım mesajın içinde kaç tane veri byte’ı olduğunu söylüyor. Mesela burada 8 seçilmiş, yani bu mesajda 8 byte veri taşınıyor. Eğer DLC 4 olsaydı, sadece 4 byte kullanılacaktı.

DATA (hex): İşin asıl bilgisi burada. Buradaki kutuların her biri 1 byte’ı temsil ediyor (0’dan 7’ye kadar toplam 8 tane). Mesela ekranda 22 60 60 00 FD 00 00 00 yazıyor. Bunlar hexadecimal yani 16’lık sistemde yazılmış sayılar. Bunları başta karmaşık olarak gelse de aslında basit bir mantığı bulunmaktadır ve blogun devamında anlatılacaktır.

Kısaca özetlersek ID kimin konuştuğunu, DLC mesajın kaç kelimeden (byte) oluştuğunu, DATA ise o kelimelerin içindeki bilgiyi gösteriyor.

DATA Nasıl ve Neye Göre Yazılır:

ID ve DLC kutularının kafada karışıklık yaratacağını düşünmüyorum. Zaten cihazın ismi ID’si onun uzunluğu da DLC’si olarak düşünün diye söylemiştim. Şimdi asıl verinin olduğu DATA’yı biraz dikkatli inceleyelim. 

İlk yani sıfırıncı byte bize mesajı gönderirken ne yaptığımızı , alırken de mesajın alındığını veya hata geldiğini anlatır. Bunlara SDO denir:

40 cihazdan bize gelen verileri okuma emri gibi düşünebiliriz. Sensörden gelen veriler olsun, Node ID’sini öğrenmek için gönderilen veri olsun 40 SDO’su ile okuma yapılır. Eğer biz cihaz içinde bazı ayarları değiştirmek istersek 22 SDO’sunu kullanabiliriz. 

Projemde bir sürücünün modunu değiştirirken de 6060h objesini kullandım. Bu objeyi kullanmamın sebebi sürücünün motoru döndürememesinden kaynaklanıyordu ve eğer sürücünün modu değiştirilirse motor dönmeye belki başlayabilirdi. SDO komutu yazıldıktan sonra  60 60 sıraları ters çevrilerek yazılıyor ve gerekli moda 4. byte’ta da mod değeri yazılıyordu. -3 değerinin desimalden hexadecimal değere çevirdiğimizde oluşan değer  gerekli FFFF FFFF FFFF FFFD olur ve en son FD değeri bizim üstte verdiğimiz programın arayüzüne eklenir ve böylece cihazı gerekli moda yazmış oluyoruz. 

LITTLE Endian ve BIG Endian: Üstteki yazımda fark ettiyseniz 60 ve 60 ters çevirilerek yazılmalı olduğunu belirttim. Bu objeleri kutucuklara yazarken uygulanan önemli bir kuraldır. 60 ve 60 aynı sayı olduklarından ve herhangi bir yer değişikliği fark edilmese de aynı örneği 6040h adresinde düşünürsek kutucuklarda sırasıyla önce 40 daha sonra da 60 yazılarak bu adres kullanılmış olur. Burada 60 40h adresi bu cihazın Control Word kısmıdır. Yani motoru çalıştırma/durdurma veya belirli durumlara alma komutları burada yazılır. 

Artık CANBUS protokolünü basitçe kullanabildiğimize göre aşağıdaki diyagramdan ilerleyerek motorun çalışmasını  başlattım.

Donanımda Gözden Kaçanlar:

Genel olarak burada CANBUS protokolü ile hızlıca temel bilgilerle nasıl hızlı bir başlangıç yapabileceğimizi anlattık. Şimdi de projenin donanım kısmına geçelim ve dikkat edilmesi gereken bazı hususlara değinelim. 

Donanım kısmında sadece datasheet’te verilen şemaya göre devre hazırlanır ve çalıştırılır. Dikkat edilmesi gereken hususlardan en çok gözden kaçanlardan birincisi eğer sistemde acil durum stop butonu varsa sistem çalıştırılmadan önce her zaman kısa devre edilmelidir çünkü sürücü her zaman acil durum olduğunu düşünür ve böylece sistem hata verip çalışamaz halde olur. İkinci olarak NTC direncinin bağlanmasıdır. Eğer elinizde NTC olmaz ise onun yerine 10k ohm direnç kullanabilirsiniz. 

Aynı CANBUS uygulamasını farklı ELFATEK cihazlarında kullanabiliriz. Staj esnasında kullanma fırsatı bulduğum eğim sensörü olan “VATOZ” ve hareket için kullanılan “OPERATOR JOYSTİCK” ile bu SDO komutlarını pekiştirdim.  Ne kadar farklı cihazlar gibi gözükse de CANBUS protokolü ile haberleştirirken benzer mantıkta çalıştım. VATOZ ve OPERATOR JOYSTİCK ikisi de daha çok okuma odaklı cihazlar oldukları için ilk byte 40 ile sonra da gerekli adresler ile bazı verileri okudum. Yazma komutlarını kullanırken de OPERATİONAL veya PRE-OPERATİONAL modlar arası geçiş , NODE-ID değişikliği gibi yerlerde kullandım.

Sonuç ve Değerlendirme:

Bu yazı, sizlere CANBUS protokolüne dair ilk adım niteliğinde bir giriş olması amacıyla hazırlanmıştır. Amacım hem teknik terimleri mümkün olduğunca anlaşılır kılmak hem de staj sürecimde karşıma çıkan örneklerle konuyu somutlaştırmaktı.

CANBUS, ilk bakışta karmaşık görünen ama aslında mantığını kavradığınızda oldukça düzenli bir sistem. Araçlarda binlerce kablo karmaşasının önüne geçip, ECU’ların (Elektronik Kontrol Üniteleri) tek bir hat üzerinden haberleşmesini sağlıyor. Bu yazıda anlattıklarım temel seviye taşımaktadır ancak ilerleyen süreçte J1939 gibi üst protokoller gibi konular üzerine belki dalış yapabilirizsiniz.

ALPER PEKGÖGÜL