CAN ağ iletişimine değinmeden önce genel anlamıyla ağ iletişiminden bahsetmek isterim. Günümüz otomobillerinde elektronik haberleşme öylesine büyük bir önem kazanmıştır ki araç içerisindeki sistemlerin yüzde 70’ini elektronik oluşturur. Yalnızca yüzde 30’u mekanik birleşenlerdir. 150‘ye yakın EKÜ’yle sürdügümüz aracımız, bizim yerimize sadece birkaç milisaniyede biz farkına dahi varmadan binlerce, onbinlerce sinyali farklı algılayıcılardan toplayıp binlerce, onbinlerce karar vermiştir bile!
Trafiğe kapalı bir alanda çok eski bir otomobille (Hadi 80 model diyelim) günümüzde üretilmiş 2019 model bir aracı sürmeyi deneyip, iki deneyimi karşılaştırdigınızda, eskiden insanlarin bu “kazma” otomobilleri nasıl sürebildiklerine şaşırır, günümüzde artık aracı “sürmek” için çok az efor sarfettiğimizi hemen farkederiz. (Ki çok yakın bir gelecekte (en gec 2025 senesinde) 100% kendi kendine giden otomobilleri sokakta gördükten sonra, yıllar önce aldığınız ehliyetin de bir anlam ifade etmediğini gördügünüzde ne hissedeceksinizdir kim bilir? 🙂 )
Özellikle tavsiyem kukaları belirli aralıklarla düz bir hatta yerleştirip, her iki araçla farklı hızlarda kukaların arasında slalom yapmayı denemek olacaktır. 🙂 “Alet işler, el övünür” sözünü yüzümüze çarpacaktır. Ben şahsen Bosch’un Boxberg’teki test pistinde buna acı bir şekilde şahit oldum!
Şunu da açıkça söylemek gerekir ki, şu an var olan yarı otonom sürüş özelliklerine sahip bir araba sürerken kaza yapmak için özel bir çaba göstermek gerekir: Şerit takibi, çarpışma engelleyici, sürücü yerine araç hızını öndeki aracın hızına göre ayarlayan adaptiv seyahat kontrol sistemi(kendi kendine ivmelenme ve fren yapma), otomatik park sistemi(kendi kendine park etme) , 360°’lik kamera, baş üstü ekranı, hız limit desteği, aktif viraj farları, esp, eps, abs…
Üzerinde 4 yıl boyunca çalıstığım dinamik sürüş sisteminin sürüşü nasıl etkilediğini asağıdaki örnekte görmek mümkün.
Tüm bu muazzam bilgi alışverişi ve karar alma sürecinin altında ağ iletişimi yatıyor. Birbirinden farklı sistemler, farklı karmaşıklığa ve güvenlik önceliğine sahip (ASIL) ve dolayısıyla farklı gereksinimleri de birlikte getiriyor.
Örnek: Sürüş halindeyken araç kliması bozulsa mı sürüşünüz daha çok etkilenir, yoksa direksiyonunuz mu? Ya da hangi sistemin sinyalinin daha kısa sürede işlenmesini isterdiniz ABS mi yoksa araç içi aydınlatma mı?
Bu yüzdendir ki araç ağı iletişimi her sistemin araç içerisindeki önemine, bulundugu yere (kablo uzunluğu değişecektir) ve maliyete göre CAN, Flexray ve LIN gibi farklı farklı haberleşme protokollerinin doğmasına sebep olmuştur.
Araç ağı, birden fazla karar verici, akıllı ürünün (ABS*, ESP*, EPS*, vb) ve bu ürünlerin EKÜ’lerinin bir araya gelip, bir grup oluşturup kendi aralarında bilgi alışverişinde bulunduğu bir sistem olarak düşünebiliriz. Sürekli bilgi akışının olduğu bir sistem. Araç ağında ise bu sistemi oluşturan her bir elemanı bir dügüm noktası olarak gösteriyoruz. İletişim ilişkisini ise bir çizgiyle belirtiyoruz.
Araç ağında her EKÜ’nün ihtiyacına göre farklı ağ iletişim protokolü tercih edilir. Bunu iki insanın baştan belirlenmis kurallarla birbirleriyle konuşmaları şeklinde düşünebilirsiniz. LIN ögretmenin ögrencilerine söz hakkı vermesi gibi çalışırken, CAN ise bir partide birbirini tanıyan insanların birbiriyle herhangi bir çakışmaya sebep olmaksızın gelişigüzel konuşmasına ya da Flexray’i bir grup konuşmacının ne zaman, hangi sırayla konuşacağı dakikası dakikasına önceden belirlenmiş bir konferansa benzetebiliriz.
Bu yazı serisinde otomotiv alanında en yaygın kullanılan araç ağı; CAN hakkında bahsedeceğim.
Öncelikle şunu belirtmekte fayda var. İsminiz Can ise ve yurtdışında yaşıyor, otomotiv sektöründe çalışıyorsanız, geçmiş olsun… İsminizle yapılabilecek korkunç kötü şakaların sınırı yok. Özellikle espiri anlayışlarıyla (!) meşhur olmuş Almanların… 🙂
CAN, otomotiv sektöründe seri üretime girmiş ilk araç iletişim ağıdır. Günümüzde artık standartlaşmış, hatta otomasyon teknolojilerinden biyomedikal ürünlere kadar çok farklı alanlarda kullanılır hale gelmiştir. Bunun sebebi hem düşük maliyetli hem de güvenilir olması.
Motor yönetiminden klimaya hibrit araçlardaki şarj sistemlerinden hidrolik direksiyona kadar CAN oldukça farklı alanlarda kullanılır. Tabi her alanın gerektirdiği veri hızı farklıdır. Mesela motordaki iletişim, konfordaki iletişime göre daha hızlı olmayı gerektirir. Bundan dolayı da her sistem icin CAN ağ iletişimi farklı veri aktarım hızıyla entegre edilir.
Veri aktarım hızına göre 2 tip CAN iletişim ağından bahsetmek mümkündür:
Genel özelliklerini özetlemek gerekirse:
İlk bayt her zaman için takip eden verinin büyüklüğünü tanımlar (0x02 = 2 Bayt, 0x07 = 7 Bayt gibi), geri kalan baytlar ise gönderilen ya da alınan veri için ayrılmıştır. CAN mesajı eğer ki tek bir mesajdan oluşuyorsa, toplam mesaj uzunluğu 8 bayta eşit veya küçükse “Tekil Mesaj”dır.
Örnek: 03 2E 06 00 (Bir UDS mesaji — Write Coding Value)
Alınan CAN mesajımız 8 bayttan daha uzun olduğunda ise “İlk mesaj + Ardisik Mesaj”lar halinde alınır. Bu mesaj formatının ilk kısmı ilk mesajdan oluşur. İlk baytta “0x1” “İlk Mesaj”ı temsil eder, bayt 0 ve bayt 1’de geriye kalan bitler ise mesaj uzunluğuna ayrılmıştır. İlk mesajda veri için 6 baytlık bir yer kalır. Kalan veri ise ardışık mesajlar halinde okunur.
İlk mesajdan ve akış denetleme mesajından sonra ardışık alınan mesaj(lar)a denir.
İlk mesajda olduğu gibi, burda da ilk baytta ardışık mesajı temsil eden “0x2” görüyoruz. “n” ise bu sefer veri uzunluğunu degil, Ardışık mesajların sırasını belirtir; dizin görevi görür. (0x21, 0x22, 0x23,… gibi)
Tekil, ilk ve ardışık mesaja örnek:
03 22 06 00 (Alınan Mesaj — Tekil)
10 0A 62 06 00 00 30 22 (Gönderilen Cevap Mesajı — İlk Mesaj, verinin uzunluğu 10 Bayta (Hex 0x0A) eşit olduğunu mesajda görebilirsiniz)
30 00 00 (Akış Denetleme Mesajı)
21 7E FF 02 00: Mesaj tek bir mesaja sığmadığı için, Ardışık mesaj ilk mesajın hemen ardından gönderilmeye başlanmıştır. Geriye kalan yalnızca 4 bayt olduğu icin 1 tek ardışık mesaj yeterlidir bu durumda.
Ardışık mesajların akışını denetleyen mesajdır; ardışık mesaj adedini ve sıklığını belirler.
Protokol denetim bilgisi (PCI) 3 bayttan oluşur:
Bayt#0: Üst yarım baytta (HB: High byte) akış denetimi mesajını temsil eden “0x3” görüyoruz. Bunun yanında alt baytta (LB: Low byte) ise “S” ardışık mesajların akış durumunu belirtir. 3 Farklı değer alabilir:
0 = ClearToSend (Gönder gelsin)
1 = Wait (Bekle paşam)
2 = Overflow (Taşma)
Bayt#1: İzin verilen ardışık mesaj adedini belirleyen blok büyüklüğü için ayrılmıştır. (BS: Block Size)
BS = 0 ise, sınırlama olmaksızın ardışık mesaj gönderilir.
Bayt#2: İki ardışık CAN mesajı arasındaki en az bekleme süresidir. (STMin: Minimum Separation Time)
Örnek: S = 0, BS = 5, STMin = 20 ms
0x30 05 14
Bir UDS servisi olan, hata hafızasını oku mesajı ve cevabıyla sizi başbaşa bırakıyorum:
Kısacası 03 19 02 0C mesajı EKÜ’müze ulaşıyor ve cevap olarak da EKÜ’müz 59(Pozitif cevap) 02 + veri ile karşılık veriyor:
03 19 02 0C (EKÜ’ye gelen mesaj)
10 4B 59 02 FF E1 14 20 (EKÜ’nün verdiği cevap başlıyor: İlk Mesaj)
30 00 00 (Akış Denetimi Mesajı: S= 0, BS = 0, STMin = 0)
21 2F 55 60 70 2F 50 00 (Ardışık Mesaj 1)
22 03 1F 20 30 21 2F 50 (Ardışık Mesaj 2)
23 00 02 5A 39 34 22 2F (Ardışık Mesaj 3)
24 13 43 00 13 14 00 0E (Ardışık Mesaj 4)
25 7E A9 40 09 31 D2 20 (Ardışık Mesaj 5)
26 7F 12 23 A3 12 24 AA(Ardışık Mesaj 6)
27 20 07 28 A0 01 01 14(Ardışık Mesaj 7)
28 11 24 AA 22 E0 24 9C (Ardışık Mesaj 8)
29 28 99 01 00 11 1F 1F (Ardışık Mesaj 9)
2A 00 2F DD 25 00 2F (Ardışık Mesaj 10)
M.Eng.Can Acar
Mechatnom CEO