System Engineering etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
System Engineering etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

28 Temmuz 2026 Salı

RS-485/MODBUS ve CAN Bus Karşılaştırması: Hangisi Ne Zaman Tercih Edilmeli?

RS-485/MODBUS ve CAN Bus Karşılaştırması: Hangisi Ne Zaman Tercih Edilmeli?

Endüstriyel bir cihaz, otomasyon kartı, araç elektroniği veya gömülü sistem tasarlarken karşımıza sık sık şu soru çıkar:

“RS-485 ve Modbus mu kullanmalıyım, yoksa CAN Bus mı?”

İlk bakışta bu iki seçenek birbirine oldukça benzer görünür. İkisinde de genellikle iki telli diferansiyel bir haberleşme hattı vardır. İkisi de gürültülü ortamlarda kullanılabilir. İkisiyle de aynı hat üzerinde birden fazla cihaz haberleştirilebilir. Üstelik her ikisi de yıllardır sanayide güvenilir şekilde kullanılmaktadır.

Fakat biraz derine indiğimizde önemli bir fark ortaya çıkar:

RS-485 bir haberleşme protokolü değildir. Kablodaki elektriksel sinyalin nasıl taşınacağını tanımlayan fiziksel bir standarttır. Modbus RTU ise çoğunlukla RS-485 hattı üzerinde çalışan bir haberleşme protokolüdür.

CAN Bus ise yalnızca elektriksel sinyal seviyelerini değil; mesajların nasıl gönderileceğini, aynı anda konuşmak isteyen cihazların nasıl sıralanacağını, hataların nasıl algılanacağını ve hatalı cihazların ağdan nasıl uzaklaştırılacağını da tanımlar.

Dolayısıyla aslında yaptığımız karşılaştırma tam olarak “RS-485 ile CAN” karşılaştırması değildir. Daha doğru ifadeyle şunu karşılaştırıyoruz:

  • RS-485 fiziksel katmanı üzerinde çalışan Modbus RTU sistemi
  • CAN fiziksel katmanı ve CAN veri bağlantı protokolü

Bu yazıda RS-485, Modbus RTU ve CAN Bus yapılarını temel seviyeden başlayarak inceleyecek; hız, mesafe, güvenilirlik, gerçek zamanlılık, maliyet ve yazılım karmaşıklığı açısından karşılaştıracağız. Yazının sonunda hangi uygulamada hangi teknolojinin daha mantıklı olduğunu daha net görebileceksiniz. 😊

RS-485 üzerinde Modbus RTU ile CAN Bus haberleşme yapılarının; kablolama, sorgu-cevap modeli, mesaj arbitrajı, hız, mesafe ve hata yönetimi açısından karşılaştırılması.

Önce Katmanları Doğru Yerleştirelim

Haberleşme sistemlerini bir kargo hizmetine benzetebiliriz.

  • Kullanılan yol ve araçlar, fiziksel haberleşme ortamını temsil eder.
  • Paketin üzerine adresin nasıl yazılacağı, veri formatını temsil eder.
  • Kimin ne zaman paket göndereceği, erişim yöntemini temsil eder.
  • Paket kaybolursa ne yapılacağı ise hata yönetimini temsil eder.

Bu benzetmede RS-485 yalnızca yolun ve taşıma aracının elektriksel özelliklerini tanımlar. Modbus, paketin içine ne yazılacağını ve paketin nasıl yorumlanacağını belirler. CAN ise yol kullanım sırasından paket kontrolüne kadar daha fazla konuyu kendi içerisinde çözer.

Teknoloji Temel görevi Tanımladığı katman
RS-485 Elektriksel sinyalin kablo üzerinde nasıl taşınacağını belirler. Fiziksel katman
Modbus RTU Cihaz adreslerini, komutları, register yapılarını ve veri çerçevesini tanımlar. Uygulama protokolü ve seri hat çerçeveleme kuralları
CAN Bus Mesaj iletimi, hat erişimi, önceliklendirme ve hata yönetimini sağlar. Fiziksel katman ve veri bağlantı katmanı
CANopen / J1939 CAN mesajlarının uygulama seviyesinde nasıl kullanılacağını tanımlar. Üst seviye protokol

Bu ayrım oldukça önemlidir. Çünkü “CAN kullanırsam bütün cihazlar otomatik olarak anlaşır” düşüncesi doğru değildir. CAN, mesajların güvenilir biçimde taşınmasını sağlar; ancak mesajların içerisindeki baytların ne anlama geldiğini sizin tanımlamanız veya CANopen, SAE J1939 gibi bir üst seviye protokol kullanmanız gerekir.

RS-485 Nedir?

RS-485, uzun mesafeli ve gürültüye dayanıklı seri haberleşme için geliştirilmiş diferansiyel bir elektriksel iletişim standardıdır. RS-485 hattında veri genellikle A ve B olarak adlandırılan iki kablo üzerinden taşınır.

Alıcı cihaz yalnızca bir kablonun gerilimine bakmaz. A ve B hatları arasındaki gerilim farkını ölçer. Dış ortamdan gelen elektromanyetik gürültü iki kabloyu benzer şekilde etkilediği için alıcı, ortak gürültünün önemli bir bölümünü bastırabilir.

Tek uçlu haberleşme:

Sinyal ---------------------------->
GND   ----------------------------->

Diferansiyel RS-485 haberleşmesi:

A     ----\____/----\____/--------->
B     ____/----\____/----\________->

Alıcı, A ile B arasındaki farkı değerlendirir.

Bu yapı RS-485’i fabrika ortamları, motor sürücüleri, enerji sayaçları, bina otomasyonu, HVAC sistemleri, güneş enerjisi inverterleri ve saha cihazları için oldukça kullanışlı hâle getirir.

RS-485’in temel özellikleri

  • Diferansiyel sinyal kullandığı için elektriksel gürültüye dayanıklıdır.
  • Düşük haberleşme hızlarında yaklaşık bir kilometre sınıfındaki mesafelere ulaşılabilir.
  • Aynı hat üzerinde birden fazla cihaz bulunabilir.
  • İki telli yarı çift yönlü veya dört telli tam çift yönlü kullanılabilir.
  • UART bulunan hemen her mikrodenetleyiciye bir RS-485 transceiver eklenerek uygulanabilir.
  • Haberleşme protokolünü kendisi belirlemez.

RS-485 neden tek başına yeterli değildir?

RS-485 yalnızca sürücü ve alıcıların elektriksel davranışını tanımlar. Aşağıdaki soruların cevabını vermez:

  • Mesaj hangi baytla başlayacak?
  • Cihazların adresi nasıl belirlenecek?
  • Verinin doğru ulaştığı nasıl kontrol edilecek?
  • İki cihaz aynı anda konuşursa ne olacak?
  • Bir sensör değeri hangi veri formatında gönderilecek?
  • Mesajın sonunda hangi hata kontrol yöntemi kullanılacak?

Bu kuralları sizin tanımlamanız gerekir. Alternatif olarak Modbus RTU gibi hazır ve yaygın bir protokol kullanabilirsiniz.

Modbus RTU Nedir?

Modbus, endüstriyel cihazlar arasında veri alışverişi yapmak için geliştirilmiş açık ve yaygın bir haberleşme protokolüdür. Seri hatta kullanılan sürümü genellikle Modbus RTU olarak adlandırılır.

Modbus RTU çoğunlukla RS-485 üzerinde çalışır. Ancak teorik olarak RS-232 veya başka uygun seri haberleşme ortamlarında da kullanılabilir.

Modbus RTU sisteminde genellikle bir istemci ve birden fazla sunucu cihaz bulunur. Eski dokümanlarda bunlar “master” ve “slave” olarak da adlandırılabilir.

İstemci cihaz soruyu sorar, adreslenen sunucu cevap verir.

İstemci:
"1 numaralı cihaz, 100. register'dan itibaren iki register gönder."

Cihaz 1:
"İstediğin iki register'ın değeri 1250 ve 846."

İstemci:
"2 numaralı cihaz, 20. çıkışı aktif et."

Cihaz 2:
"Komut uygulandı."

Modbus veri modeli

Modbus içerisinde veriler yaygın olarak dört temel grupta ele alınır:

Veri türü Erişim Örnek kullanım
Coil Okuma ve yazma Röle veya dijital çıkış komutu
Discrete Input Yalnızca okuma Buton veya dijital giriş durumu
Input Register Yalnızca okuma Sıcaklık, basınç veya analog ölçüm
Holding Register Okuma ve yazma Ayar, eşik, çalışma modu veya kalibrasyon değeri

Register tabanlı bu yaklaşım özellikle PLC, HMI ve SCADA sistemleri açısından oldukça pratiktir. Bir cihazın dokümanında register tablosu bulunuyorsa, cihazı farklı üreticilerin PLC veya yazılımlarıyla entegre etmek görece kolaydır.

Basit bir Modbus RTU mesajı

Örneğin istemci, 1 adresli cihazdan iki holding register okumak istesin:

01 03 00 64 00 02 CRC_L CRC_H
  • 01: Cihaz adresi
  • 03: Holding register okuma fonksiyon kodu
  • 00 64: Başlangıç register adresi
  • 00 02: Okunacak register sayısı
  • CRC_L CRC_H: Hata kontrol değeri

Buradaki CRC, mesajın hat üzerinde bozulup bozulmadığının anlaşılmasına yardımcı olur. Fakat mesajın yeniden gönderilmesi, zaman aşımı yönetimi ve cihazın cevap vermemesi gibi durumların yönetimi büyük ölçüde uygulama yazılımına bırakılmıştır.

CAN Bus Nedir?

CAN, yani Controller Area Network, başlangıçta araç içerisindeki elektronik kontrol ünitelerinin güvenilir biçimde haberleşebilmesi için geliştirilmiştir. Günümüzde otomotiv dışında iş makineleri, tarım makineleri, medikal cihazlar, robotlar, asansörler, denizcilik sistemleri ve endüstriyel kontrol uygulamalarında da kullanılmaktadır.

CAN hattında da çoğunlukla iki diferansiyel kablo bulunur:

  • CAN_H
  • CAN_L

CAN’in en önemli farkı, hattaki cihazların merkezi bir yöneticiden izin beklemeden mesaj gönderebilmesidir. Bu nedenle CAN, çok yöneticili veya yaygın kullanılan ifadeyle multi-master bir yapıya sahiptir.

CAN cihaz adresi yerine mesaj kimliği kullanır

Modbus sisteminde soru genellikle belirli bir cihaza yöneltilir:

"7 adresli cihaz, sıcaklık değerini gönder."

CAN sisteminde ise cihazlar çoğunlukla belirli bir mesaj kimliğini yayınlar:

CAN ID: 0x181
Data:   23 05 00 00 00 00 00 00

Hattaki bütün CAN düğümleri mesajı fiziksel olarak görür. Ancak yalnızca ilgili CAN ID’sine göre filtre ayarı yapılmış cihazlar mesajı işleme alır.

Bu nedenle CAN haberleşmesi cihaz odaklı değil, mesaj odaklıdır.

CAN Bus arbitrajı nasıl çalışır?

Aynı anda iki CAN düğümünün mesaj göndermeye başladığını düşünelim. Normal bir seri haberleşme sisteminde bu durum çakışmaya ve mesajların bozulmasına yol açabilir.

CAN, bu sorunu bit seviyesinde ve veri kaybı oluşturmadan çözer.

CAN hattında iki temel bit durumu vardır:

  • Dominant bit: Mantıksal 0
  • Recessive bit: Mantıksal 1

Dominant bit, recessive bite üstün gelir. Her düğüm kendi gönderdiği biti aynı anda hattan okur. Bir düğüm recessive bit gönderdiği hâlde hatta dominant bit görürse kendisinden daha yüksek öncelikli bir mesaj bulunduğunu anlar ve iletimi bırakır.

Düğüm A mesaj kimliği: 0x120
Düğüm B mesaj kimliği: 0x080

İki düğüm aynı anda başlar.

Bitler karşılaştırılır.
İlk farklılıkta 0 gönderen mesaj üstün gelir.

Sonuç:
0x080 mesajı hattı kazanır.
0x120 mesajı bozulmaz; yalnızca daha sonra tekrar gönderilir.

CAN’de sayısal olarak daha düşük mesaj kimliği daha yüksek önceliğe sahiptir. Örneğin 0x050 kimlikli bir acil durdurma mesajı, 0x500 kimlikli periyodik sıcaklık mesajından daha yüksek öncelikli olabilir.

Önemli: CAN arbitrajı öncelik tabanlıdır. Yanlış ID planlaması yapılırsa düşük öncelikli mesajlar yüksek hat yükünde uzun süre bekleyebilir.

CAN hata yönetimi neden güçlüdür?

CAN protokolünde hata algılama yalnızca mesaj sonundaki CRC kontrolünden ibaret değildir. Protokol içerisinde birden fazla kontrol mekanizması bulunur:

  • CRC kontrolü
  • Gönderilen bitin hat üzerinden geri okunması
  • Bit stuffing kontrolü
  • Mesaj çerçevesi format kontrolü
  • Alıcı onay biti, yani ACK
  • Hata çerçevesi gönderimi
  • Gönderme ve alma hata sayaçları
  • Error Active, Error Passive ve Bus-Off durumları

Sürekli hatalı mesaj gönderen bir CAN düğümü hata sayacını artırır. Hatalar devam ederse cihaz önce pasif hâle gelebilir, ardından Bus-Off durumuna geçerek haberleşme hattından mantıksal olarak ayrılabilir.

Bu mekanizma, arızalı tek bir cihazın bütün haberleşme hattını sürekli bozmasını önlemeye yardımcı olur.

RS-485/MODBUS ve CAN Bus Kısa Karşılaştırma Tablosu

Kriter RS-485 + Modbus RTU CAN Bus
Temel yapı İstemci-sunucu, sorgu-cevap Çok yöneticili, mesaj tabanlı yayın
Hat erişimi Genellikle istemci kontrol eder. Bütün düğümler mesaj gönderebilir.
Çakışma yönetimi Protokol ve uygulama yazılımıyla önlenir. Donanımsal, bit seviyesinde arbitraj bulunur.
Önceliklendirme İstemcinin sorgu sırasıyla yapılır. Mesaj kimliği arbitraj önceliğini belirler.
Veri modeli Coil ve register tabanlı hazır model Ham mesaj verisi; uygulama modeli ayrıca tanımlanır.
Klasik veri alanı Tek sorguda çok sayıda register taşınabilir. Klasik CAN’de en fazla 8 bayt
Yeni nesil veri alanı Modbus çerçevesi değişmez. CAN FD’de en fazla 64 bayt
Hata yönetimi CRC, zaman aşımı ve yazılımsal tekrar deneme CRC, ACK, bit kontrolü, hata çerçevesi ve hata sınırlama
Gerçek zamanlılık Planlı sorgulamayla öngörülebilir olabilir. Öncelik tabanlı, olay odaklı iletişim için güçlüdür.
Mesafe Düşük hızlarda çok uzun mesafeler için uygundur. Hız arttıkça ağın fiziksel uzunluğu belirgin biçimde azalır.
Yazılım geliştirme Temel uygulamalarda daha kolaydır. ID planlama, bit timing ve ağ yükü analizi gerektirir.
Yaygın kullanım PLC, sayaç, inverter, HMI ve bina otomasyonu Araç, robot, iş makinesi ve dağıtık kontrol sistemi

1. Haberleşme Modeli: Sorgu-Cevap mı, Olay Odaklı mı?

Modbus RTU’da iletişimi istemci yönetir

Modbus RTU sisteminde sunucu cihazlar genellikle kendi kendine veri göndermez. İstemcinin soru sormasını bekler.

Örneğin bir PLC, sırasıyla şu işlemleri yapabilir:

  1. Birinci cihazın sıcaklığını oku.
  2. İkinci cihazın basıncını oku.
  3. Üçüncü cihazın hata durumunu oku.
  4. Dördüncü cihaza çıkış komutu gönder.
  5. Tekrar başa dön.

Bu yaklaşımın önemli bir avantajı vardır: Hattın kontrolü tek bir merkezde olduğu için iletişim sırası kolayca öngörülebilir.

Ancak bir sensörde aniden kritik bir hata oluşursa sensör çoğu standart Modbus RTU sisteminde kendiliğinden bağırarak haber veremez. İstemcinin sensörü sıradaki sorgusunda yoklamasını bekler.

CAN Bus’ta olay gerçekleştiğinde mesaj yayınlanabilir

CAN ağındaki bir cihaz, hat boş olduğunda mesaj göndermeyi deneyebilir. Kritik bir olay oluştuğunda yüksek öncelikli bir CAN mesajı hemen yayınlanabilir.

Örneğin:

  • Motor sıcaklığı normalde saniyede bir gönderilebilir.
  • Motor aşırı akım hatası oluştuğunda mesaj anında yayınlanabilir.
  • Acil durdurma mesajına çok yüksek öncelik verilebilir.
  • Düşük öncelikli servis bilgileri daha sonra gönderilebilir.

Olay tabanlı, hızlı tepki gerektiren ve birden fazla kontrolcünün aktif olduğu sistemlerde CAN bu nedenle daha doğal bir çözüm olabilir.

2. Gerçek Zamanlılık ve Gecikme

“Gerçek zamanlı” ifadesi yalnızca hızlı olmak anlamına gelmez. Bir mesajın en geç ne zaman ulaşacağının öngörülebilmesi de önemlidir.

Modbus RTU gecikmesi nasıl oluşur?

Modbus RTU’da istemci cihazları sırayla sorgular. Bir cihazın cevap süresi uzarsa veya cihaz hiç cevap vermezse istemci zaman aşımını beklemek zorunda kalabilir.

Örneğin 20 cihazlı bir ağda her sorgu ve cevap toplam 10 milisaniye sürüyorsa, bütün cihazları bir kez taramak yaklaşık 200 milisaniye sürer. Fakat bir cihaz için 100 milisaniyelik zaman aşımı beklenirse toplam tarama süresi belirgin biçimde uzayabilir.

Bu nedenle Modbus performansında şu değerler önemlidir:

  • Baud rate
  • Sorgu uzunluğu
  • Cevap uzunluğu
  • Cihaz sayısı
  • Cihazların cevap hazırlama süresi
  • Zaman aşımı değeri
  • Tekrar deneme sayısı
  • Register’ların blok hâlinde okunup okunmadığı

Doğru tasarlanmış bir sorgulama tablosuyla Modbus RTU oldukça öngörülebilir çalışabilir. Ancak cihaz sayısı büyüdükçe ve zaman aşımı senaryoları arttıkça gecikme de artar.

CAN Bus gecikmesi nasıl oluşur?

CAN’de mesajın gecikmesi, büyük ölçüde mesaj önceliğine ve hat yüküne bağlıdır.

Yüksek öncelikli mesajlar hattı daha kolay kazanırken düşük öncelikli mesajlar bekleyebilir. Ağ yükü aşırı yükselirse düşük öncelikli mesajların gecikmesi önemli hâle gelebilir.

Dolayısıyla CAN sisteminde yalnızca baud rate seçmek yeterli değildir. Aşağıdakiler de planlanmalıdır:

  • Mesaj ID’leri ve öncelikler
  • Mesajların periyodik gönderim süreleri
  • Olay tabanlı mesajların maksimum sıklığı
  • En kötü durumdaki hat yükü
  • Maksimum kabul edilebilir mesaj gecikmesi
  • Düşük öncelikli mesajların aç kalma ihtimali

Doğru tasarlanmış bir CAN ağı, kritik mesajlar için oldukça düşük ve hesaplanabilir gecikmeler sağlayabilir.

3. Hız ve Veri Taşıma Verimliliği

Haberleşme hızını değerlendirirken yalnızca “kaç bit/saniye?” sorusuna bakmak yanıltıcı olabilir. Bir protokolün mesaj başlıkları, hata kontrol alanları ve cevap mekanizması da gerçek veri taşıma kapasitesini etkiler.

RS-485’in hızı protokolden bağımsızdır

RS-485 standardı oldukça yüksek hızlarda çalışabilen fiziksel katman çözümlerine izin verir. Ancak hız arttıkça erişilebilecek kablo mesafesi azalır.

Modbus RTU uygulamalarında sık karşılaşılan hızlar şunlardır:

  • 9.600 bit/s
  • 19.200 bit/s
  • 38.400 bit/s
  • 57.600 bit/s
  • 115.200 bit/s

Bunlar zorunlu değerler değildir. Cihazlar ve hat tasarımı destekliyorsa daha yüksek hızlar da kullanılabilir.

Modbus’un avantajlarından biri, tek sorguda art arda çok sayıda register okuyabilmesidir. Örneğin 30 farklı ölçüm değeri ardışık register’larda tutuluyorsa hepsini tek işlemle okumak mümkündür.

Klasik CAN ve CAN FD

Klasik CAN mesajında veri alanı en fazla 8 bayttır. Bu miktar kontrol komutları, sensör değerleri ve durum bilgileri için çoğu zaman yeterlidir. Ancak uzun veri blokları gönderilecekse mesajın birkaç parçaya bölünmesi gerekir.

CAN FD ile birlikte veri alanı 64 bayta kadar çıkarılmıştır. CAN FD ayrıca arbitraj bölümü tamamlandıktan sonra veri bölümünde daha yüksek bir bit hızına geçilmesine imkân tanır.

Buna rağmen CAN, büyük dosyaların veya sürekli yüksek hacimli verilerin taşınması için geliştirilmiş bir teknoloji değildir. Kamera görüntüsü, ses akışı veya büyük firmware dosyaları için Ethernet gibi daha yüksek bant genişlikli çözümler daha uygun olabilir.

4. Mesafe ve Kablo Yapısı

RS-485 uzun mesafede neden avantajlıdır?

RS-485 düşük hızlarda yaklaşık 1.000 metre sınıfındaki hatlarda kullanılabilir. Gerçek ulaşılabilir mesafe aşağıdaki etkenlere bağlıdır:

  • Haberleşme hızı
  • Kablonun karakteristik empedansı
  • Kablo kesiti ve kalitesi
  • Topoloji
  • Dal bağlantılarının uzunluğu
  • Sonlandırma direnci
  • Toprak potansiyeli farkı
  • Elektromanyetik gürültü
  • Transceiver özellikleri
  • Galvanik izolasyon ve koruma devreleri

Uzun bir üretim hattındaki enerji sayaçlarını veya bina içerisindeki farklı katlara dağılmış cihazları okumak için RS-485 oldukça uygun olabilir.

CAN’de hız-mesafe ilişkisi daha kritiktir

CAN arbitrajı sırasında bütün cihazların gönderilen biti yeterli süre içerisinde görmesi gerekir. Sinyalin hattın bir ucundan diğer ucuna gitme süresi ve geri dönüş gecikmesi, bit timing hesabını doğrudan etkiler.

Bu nedenle CAN hızı yükseldikçe izin verilen toplam hat uzunluğu azalır. Uygulamada 1 Mbit/s gibi yüksek hızlar daha kısa ağlarda; 125 kbit/s gibi daha düşük hızlar ise daha geniş fiziksel ağlarda tercih edilir.

Kesin mesafe yalnızca baud rate tablosundan seçilmemelidir. Kablo gecikmesi, transceiver gecikmesi, düğüm sayısı, konnektörler, stub uzunlukları ve örnekleme noktası birlikte değerlendirilmelidir.

5. Topoloji, Sonlandırma ve Dal Bağlantıları

Hem RS-485 hem de yüksek hızlı CAN için ideal yapı doğrusal bir bus topolojisidir.

Doğruya yakın bus topolojisi:

120 Ω                                            120 Ω
[SON]----+---------+---------+---------+---------[SON]
         |         |         |         |
       Cihaz 1   Cihaz 2   Cihaz 3   Cihaz 4

Sonlandırma dirençleri hattın iki fiziksel ucuna yerleştirilir. Her cihaza sonlandırma direnci takılması doğru değildir.

Yıldız bağlantı neden problem olabilir?

Önerilmeyen uzun kollu yıldız topoloji:

                 +---- Cihaz 1
                 |
Merkez ----------+---- Cihaz 2
                 |
                 +---- Cihaz 3
                 |
                 +---- Cihaz 4

Sinyal bir bağlantı noktasına ulaştığında farklı kollara ayrılır. Kolların empedansları ve uzunlukları nedeniyle yansımalar oluşabilir. Düşük hızlarda sistem çalışıyor gibi görünse bile hız yükseldiğinde veya kablo uzadığında rastgele haberleşme hataları başlayabilir.

CAN sistemi genellikle stub uzunluğu konusunda daha hassastır. RS-485’te de uzun dallar problem yaratır; ancak düşük hızdaki bazı sistemler daha toleranslı davranabilir.

RS-485 bias dirençleri

İki telli RS-485 hattında hiçbir sürücü aktif değilken hat boşta kalabilir. Alıcının belirsiz değer okumasını önlemek için bazı sistemlerde fail-safe bias dirençleri kullanılır.

Ancak her cihaza ayrı bias direnci koymak hattı gereksiz yere yükleyebilir. Bias ağı çoğunlukla tek bir uygun noktada tasarlanmalıdır. Modern transceiver’ların bir kısmında dahili fail-safe özellikler de bulunur.

CAN’de boşta kalma durumu

CAN transceiver yapısı, hat boşta olduğunda recessive seviyenin oluşmasını sağlayacak şekilde tasarlanır. RS-485’teki klasik harici bias ağı yaklaşımı CAN hattında aynı biçimde uygulanmaz.

6. Cihaz Sayısı ve Adresleme

RS-485 node sayısı

Klasik RS-485 tanımlarında sıkça “en fazla 32 cihaz” ifadesi görülür. Bu sayı, bir sürücünün taşıması gereken klasik unit load yükü üzerinden ortaya çıkmıştır.

Modern 1/2, 1/4 veya 1/8 unit load transceiver’larla fiziksel olarak daha fazla cihaz bağlamak mümkün olabilir. Fakat gerçek sınır yalnızca transceiver yükünden oluşmaz. Kablo uzunluğu, kapasitans, koruma devreleri, konnektörler, topoloji ve protokol adres alanı da dikkate alınmalıdır.

Modbus seri hatta sunucu adresleri genellikle 1 ile 247 arasında kullanılır. Adres 0 ise yayın mesajları için ayrılmıştır. Yayın mesajına cihazların cevap vermemesi gerekir.

CAN’de cihaz adresi kavramı farklıdır

CAN’in temel seviyesinde cihaz adresinden çok mesaj kimliği vardır. Bir düğüm birden fazla CAN ID yayınlayabilir. Aynı mesajı birden fazla cihaz dinleyebilir.

Cihazlara mantıksal node adresi vermek isteniyorsa CANopen veya SAE J1939 gibi bir üst seviye protokol kullanılabilir ya da projeye özel bir adresleme yöntemi tasarlanabilir.

7. Hata Algılama ve Arızaya Tepki

Modbus RTU hata yönetimi

Modbus RTU çerçevelerinde CRC-16 kontrolü bulunur. CRC uyuşmazsa alıcı mesajı geçersiz kabul eder.

Ancak aşağıdaki işlemler genellikle istemci yazılımı tarafından yapılır:

  • Cevap zaman aşımını takip etmek
  • Mesajı yeniden göndermek
  • Tekrar deneme sayısını sınırlamak
  • Cihazı çevrim dışı işaretlemek
  • Haberleşme hatasını operatöre bildirmek
  • Yeniden bağlanma stratejisini yönetmek

Modbus sunucusu geçerli bir sorguyu uygulayamıyorsa bir exception cevabı da gönderebilir. Örneğin desteklenmeyen fonksiyon kodu, geçersiz register adresi veya cihazın işlemi tamamlayamaması bildirilebilir.

CAN hata yönetimi

CAN’de düğümler mesajı gönderirken hattı da izler. Bir düğüm hata algıladığında hata çerçevesi oluşturabilir ve mesajın diğer düğümler tarafından geçerli kabul edilmesini engelleyebilir.

Hatalı mesaj daha sonra otomatik olarak tekrar gönderilebilir. Bunun yanında her CAN kontrolcüsünde iletim ve alım hata sayaçları bulunur.

Bu mekanizma özellikle aşağıdaki sistemlerde önemli bir avantaj sağlar:

  • Bir cihaz arızasının tüm ağı bozmasının kabul edilemediği sistemler
  • Birden fazla kontrol ünitesinin bulunduğu dağıtık mimariler
  • Elektromanyetik gürültünün yüksek olduğu araç ve makine uygulamaları
  • Hata teşhisi ve ağ sağlığının izlenmesi gereken projeler

8. Donanım Maliyeti ve Mikrodenetleyici Seçimi

RS-485 donanımı

RS-485 için temel donanım oldukça basittir:

  • UART çevre birimi bulunan bir mikrodenetleyici
  • RS-485 transceiver
  • Sonlandırma ve gerekirse bias dirençleri
  • ESD, EFT ve surge koruma elemanları
  • Gerekliyse dijital izolasyon ve izole DC/DC dönüştürücü

Yarı çift yönlü RS-485 transceiver’larda sürücü etkinleştirme pini bulunur. Mikrodenetleyici mesaj göndermeden önce sürücüyü aktif eder, son bayt gerçekten hattan çıktıktan sonra tekrar alıcı moduna döner.

Burada sık yapılan bir hata, UART veri register’ı boşalır boşalmaz sürücüyü kapatmaktır. UART register’ı boşalmış olsa bile son bit henüz fiziksel olarak hattan çıkmamış olabilir. Bu nedenle “transmit register empty” yerine çoğunlukla “transmission complete” durumu takip edilmelidir.

CAN donanımı

CAN için genellikle aşağıdaki bileşenler gerekir:

  • CAN kontrolcüsüne sahip bir mikrodenetleyici
  • Harici CAN transceiver
  • İki uçta 120 Ω sonlandırma
  • ESD ve transient koruma devreleri
  • Gerekliyse common-mode choke
  • Gerekliyse galvanik izolasyon

Mikrodenetleyicide dahili CAN kontrolcüsü yoksa MCP2515 gibi SPI üzerinden çalışan harici bir CAN kontrolcüsü kullanılabilir. Ancak yüksek mesaj trafiği, kesin zamanlama veya CAN FD gereken uygulamalarda dahili CAN çevre birimine sahip bir mikrodenetleyici daha uygun olabilir.

Donanım maliyeti açısından iki çözüm arasında her zaman büyük fark bulunmaz. Fark çoğunlukla yazılım geliştirme, test, analiz cihazları ve sistem mühendisliği tarafında ortaya çıkar.

9. Yazılım Karmaşıklığı

Modbus RTU yazılımı neden daha kolay görünebilir?

Basit bir Modbus RTU sunucusunda aşağıdaki yapı yeterli olabilir:

  1. UART’tan çerçeveyi al.
  2. Adresin cihaza ait olup olmadığını kontrol et.
  3. CRC’yi doğrula.
  4. Fonksiyon kodunu işle.
  5. İstenen register’ları oku veya yaz.
  6. Cevabı oluştur ve gönder.

Açık kaynak Modbus kütüphaneleri ve hazır PLC fonksiyon blokları oldukça yaygındır. Register tablosu düzgün hazırlanmışsa üçüncü taraf entegrasyonu da kolaylaşır.

CAN yazılımında neler planlanmalıdır?

CAN sürücüsünün çalıştırılması başlangıçta kolay görünebilir. Fakat iyi bir CAN ağı tasarlamak için aşağıdaki konuların düşünülmesi gerekir:

  • 11 bit veya 29 bit kimlik kullanımı
  • Mesaj ID dağılımı
  • Mesaj öncelikleri
  • Mesaj periyotları
  • Timeout ve alive counter mekanizmaları
  • Sinyal ölçekleri ve offset değerleri
  • Byte order
  • Mesaj bütünlük kontrolleri
  • Bus load hesabı
  • Bus-Off durumundan geri dönüş stratejisi
  • Yazılım güncelleme ve teşhis mesajları
  • Sürüm uyumluluğu

CAN’in donanım seviyesinde güçlü olması, uygulama protokolünün otomatik olarak hazır olduğu anlamına gelmez.

10. Veri Formatı ve Birlikte Çalışabilirlik

Modbus register haritası

Modbus cihazı geliştiren üretici genellikle bir register tablosu yayınlar:

Register Açıklama Veri tipi Ölçek
100 Besleme gerilimi Unsigned 16 bit 0,01 V/bit
101 Kart sıcaklığı Signed 16 bit 0,1 °C/bit
102 Dijital girişler Bit alanı Her bit bir giriş

Ancak bazı ayrıntılar Modbus standardı tarafından kesin biçimde çözülmez. Örneğin 32 bit veri iki register’a yerleştirildiğinde word sıralaması üreticiye göre değişebilir. Bu nedenle register dokümantasyonunda byte ve word sırası açıkça belirtilmelidir.

CAN sinyal tanımı

CAN tarafında benzer bir mesaj tanımı şu şekilde yapılabilir:

Mesaj adı : Device_Status
CAN ID    : 0x181
Periyot   : 100 ms
DLC       : 8

Byte 0-1  : Besleme gerilimi
            Unsigned 16 bit
            Little-endian
            Ölçek: 0,01 V/bit

Byte 2-3  : Kart sıcaklığı
            Signed 16 bit
            Ölçek: 0,1 °C/bit

Byte 4    : Dijital giriş bitleri
Byte 5    : Hata kodu
Byte 6    : Alive counter
Byte 7    : Uygulama CRC değeri

Otomotiv projelerinde bu tanımlar çoğunlukla DBC dosyalarında tutulur. Böylece analiz araçları ham CAN verisini gerilim, sıcaklık veya hız gibi fiziksel değerlere çevirebilir.

11. Galvanik İzolasyon Gerekli mi?

Hem RS-485 hem de CAN hatlarında galvanik izolasyon bazı uygulamalarda son derece önemlidir.

İzolasyon özellikle aşağıdaki durumlarda değerlendirilmelidir:

  • Cihazlar farklı güç kaynaklarından besleniyorsa
  • Toprak potansiyelleri arasında fark oluşabiliyorsa
  • Kablo bina veya makine sınırlarının dışına çıkıyorsa
  • Motor, kontaktör ve inverter bulunan gürültülü ortamdaysa
  • Yüksek gerilimli güç katı ile kontrol katı arasında güvenlik ayrımı gerekiyorsa
  • Uzun kablo nedeniyle yıldırım veya surge riski oluşuyorsa
  • İnsan erişimine açık konnektör bulunuyorsa

İzole bir arayüz genellikle iki parçadan oluşur:

  • Sinyal izolasyonu
  • İzole tarafta transceiver’ı besleyecek izole güç kaynağı

Yalnızca dijital izolatör eklemek yeterli olmayabilir. Bus tarafının enerji beslemesi de izolasyon bariyerinin uygun tarafında oluşturulmalıdır.

12. Siber Güvenlik Açısından Karşılaştırma

Ne standart Modbus RTU ne de klasik CAN temel hâliyle şifreleme ve güçlü kimlik doğrulama sağlar.

Modbus RTU güvenliği

Modbus RTU mesajında cihaz adresi, fonksiyon kodu, veri ve CRC bulunur. Ancak CRC bir güvenlik mekanizması değildir. Yalnızca iletim hatalarının algılanmasına yardımcı olur.

Hatta fiziksel erişimi olan bir saldırgan teorik olarak geçerli CRC’ye sahip sahte bir Modbus komutu oluşturabilir.

CAN güvenliği

CAN mesajlarında da temel seviyede gönderen cihazı kriptografik olarak doğrulayan bir mekanizma yoktur. Hatta erişebilen bir düğüm geçerli biçimde CAN mesajı yayınlayabilir.

CAN CRC’si ve hata kontrol mekanizmaları rastgele iletim hatalarına karşı güçlüdür; ancak kötü niyetli mesaj üretimine karşı kimlik doğrulama sağlamaz.

Güvenlik kritik sistemlerde aşağıdaki önlemler değerlendirilebilir:

  • Fiziksel erişimin sınırlandırılması
  • Ağ segmentasyonu
  • Gateway ve firewall kullanımı
  • Mesaj frekansı ve davranış anomali kontrolü
  • Uygulama katmanında mesaj kimlik doğrulama
  • Rolling counter veya freshness value
  • Güvenli bootloader ve imzalı firmware
  • Servis ve teşhis fonksiyonlarının erişim kontrolü

13. Örnek Proje: Endüstriyel Giriş-Çıkış Modülü

12–24 V ile çalışan, dört analog girişe ve dört adet high-side MOSFET çıkışına sahip bir saha cihazı geliştirdiğimizi düşünelim.

Cihaz aşağıdaki görevleri yapacak:

  • Dört analog sensörü okuyacak.
  • Dört adet 24 V çıkışı kontrol edecek.
  • Besleme ve kart sıcaklığını izleyecek.
  • Bir PLC veya merkezi kontrolcüyle haberleşecek.
  • Yaklaşık 300 metre kablo üzerinden çalışacak.

Bu proje için RS-485 ve Modbus neden mantıklı olabilir?

  • PLC entegrasyonu kolaydır.
  • Analog değerler input register olarak yayınlanabilir.
  • Çıkışlar coil veya holding register ile kontrol edilebilir.
  • 300 metre gibi bir mesafe düşük baud rate’te rahat yönetilebilir.
  • Cihazın acil ve kendiliğinden mesaj göndermesi gerekmeyebilir.
  • Register tablosu üçüncü taraf müşterilere kolayca verilebilir.
  • UART destekli ekonomik bir mikrodenetleyici yeterli olabilir.

Örnek register haritası şöyle olabilir:

30001 : Analog giriş 1
30002 : Analog giriş 2
30003 : Analog giriş 3
30004 : Analog giriş 4

40001 : Çıkış komutları
40002 : Akım limiti
40003 : Haberleşme watchdog süresi

00001 : Çıkış 1
00002 : Çıkış 2
00003 : Çıkış 3
00004 : Çıkış 4

Aynı proje için CAN ne zaman daha mantıklı olur?

  • Birden fazla kontrolcü bulunuyorsa
  • Giriş değişimleri anında yayınlanacaksa
  • Aşırı akım gibi hataların gecikmeden iletilmesi gerekiyorsa
  • Çıkış modülleri birbirinden bağımsız mesaj üretecekse
  • Sistem mobil bir araç veya iş makinesi üzerindeyse
  • Mesaj önceliği ve hata sınırlama önemliyse
  • İleride CANopen veya J1939 entegrasyonu planlanıyorsa

Örneğin aşırı akım mesajına 0x080, periyodik analog ölçümlere 0x300, servis bilgilerine ise 0x600 gibi daha düşük öncelikli ID’ler verilebilir.

14. Hangi Uygulamalarda RS-485/MODBUS Tercih Edilebilir?

Aşağıdaki şartlarda RS-485 üzerinde Modbus RTU genellikle güçlü bir adaydır:

  • PLC, HMI veya SCADA sistemiyle entegrasyon yapılacaksa
  • Cihazlar merkezi olarak sorgulanacaksa
  • Uzun kablo mesafesi gerekiyorsa
  • Veriler register tablosu şeklinde ifade edilebiliyorsa
  • Haberleşme hızı kritik değilse
  • Sistem mimarisi basit ve merkeziyse
  • Düşük maliyetli mikrodenetleyici kullanılacaksa
  • Üçüncü taraf entegrasyonu kolay olmalıysa
  • Saha teknisyenlerinin mevcut Modbus araçlarını kullanması isteniyorsa

Tipik örnekler:

  • Enerji sayaçları
  • Güneş enerjisi inverterleri
  • Motor sürücüleri
  • Uzaktan giriş-çıkış modülleri
  • HVAC kontrol cihazları
  • Bina otomasyonu
  • Endüstriyel sensörler
  • Pompa ve kompresör kontrol panoları

15. Hangi Uygulamalarda CAN Bus Tercih Edilebilir?

Aşağıdaki şartlarda CAN Bus daha uygun olabilir:

  • Birden fazla aktif kontrolcü bulunuyorsa
  • Cihazların olay oluştuğunda kendiliğinden mesaj göndermesi gerekiyorsa
  • Kritik mesajlara öncelik verilmesi gerekiyorsa
  • Güçlü hata algılama ve hata sınırlama isteniyorsa
  • Sistem dağıtık kontrol mimarisine sahipse
  • Kısa ve sık durum mesajları gönderilecekse
  • Araç veya hareketli makine uygulaması geliştiriliyorsa
  • CANopen, J1939 veya başka bir CAN tabanlı standart kullanılacaksa
  • Düğüm arızalarının ağ üzerindeki etkisi sınırlandırılmak isteniyorsa

Tipik örnekler:

  • Otomotiv elektronik kontrol üniteleri
  • Elektrikli araç batarya sistemleri
  • Tarım makineleri
  • İş makineleri
  • Robotik sistemler
  • Asansör kontrol sistemleri
  • Denizcilik elektroniği
  • Dağıtık motor kontrol sistemleri
  • Medikal ve laboratuvar cihazları

16. RS-485/MODBUS ve CAN Aynı Sistemde Kullanılabilir mi?

Evet. Hatta birçok gerçek sistemde iki teknoloji birlikte kullanılır.

Örneğin:

  • Araç içerisindeki düğümler CAN ile haberleşebilir.
  • Merkezi kontrolcü bina otomasyon sistemine Modbus RTU ile bağlanabilir.
  • Bir gateway, CAN mesajlarını Modbus register’larına dönüştürebilir.
  • Yerel hızlı kontrol CAN ile, uzak saha haberleşmesi RS-485 ile yapılabilir.
[CAN Sensörleri]
       |
       | CAN Bus
       |
[CAN / Modbus Gateway]
       |
       | RS-485 Modbus RTU
       |
[PLC veya SCADA]

Gateway tasarlanırken yalnızca veri çevrimi yapılmamalıdır. İki haberleşme sisteminin farklı zamanlama modelleri de düşünülmelidir.

CAN mesajları kendiliğinden ve hızlı biçimde gelebilirken Modbus istemcisi veriyi aralıklı olarak sorgular. Bu nedenle gateway içerisinde son değerlerin tutulduğu bir veri tabanı, timeout bilgisi ve veri güncellik işareti bulunması yararlı olabilir.

17. Sık Yapılan Tasarım Hataları

RS-485 ve Modbus tarafındaki yaygın hatalar

  • RS-485 ile Modbus’un aynı şey olduğunu düşünmek
  • Hattın her cihazına 120 Ω sonlandırma bağlamak
  • Uzun yıldız topoloji kullanmak
  • A ve B isimlendirmesinin her üreticide aynı olduğunu varsaymak
  • Transceiver yön kontrolünü yanlış zamanda değiştirmek
  • Ortak referans hattını ve toprak potansiyeli farkını dikkate almamak
  • Her düğüme ayrı bias dirençleri koymak
  • CRC doğrulaması yapmadan mesajı işlemek
  • Zaman aşımı ve tekrar deneme stratejisi oluşturmamak
  • Register tablosunda veri tipi, ölçek ve byte sırasını belirtmemek

CAN tarafındaki yaygın hatalar

  • Her düğüme sonlandırma direnci takmak
  • Uzun yıldız topoloji kullanmak
  • Bit timing değerlerini rastgele seçmek
  • Bütün mesajlara benzer öncelik vermek
  • Düşük sayısal CAN ID’nin yüksek öncelik olduğunu unutmak
  • Hat yükünü hesaplamamak
  • Bus-Off durumundan geri dönüş stratejisi oluşturmamak
  • Çok sık periyodik mesaj göndererek ağı gereksiz yüklemek
  • CAN’in uygulama protokolünü de otomatik olarak tanımladığını düşünmek
  • Sinyal ölçeklerini ve mesaj sürümlerini dokümante etmemek

18. Hızlı Karar Rehberi

Aşağıdaki sorular seçim sürecini kolaylaştırabilir:

PLC veya SCADA ile kolay entegrasyon mu gerekiyor?

RS-485 ve Modbus RTU genellikle daha uygun olur.

Birden fazla cihaz kendiliğinden mesaj gönderecek mi?

CAN Bus daha doğal bir mimari sunar.

Çok uzun kablo mesafesi mi gerekiyor?

Düşük hızda çalışan RS-485 önemli avantaj sağlayabilir.

Kritik mesajlara donanımsal öncelik mi verilecek?

CAN Bus arbitraj mekanizması sayesinde öne çıkar.

Basit bir sensör veya giriş-çıkış cihazı mı geliştiriliyor?

Merkezi sorgulama yeterliyse Modbus RTU daha kolay olabilir.

Araç, robot veya dağıtık kontrol sistemi mi geliştiriliyor?

CAN Bus çoğunlukla daha uygun olur.

Tek mesajda çok sayıda ölçüm değeri mi okunacak?

Ardışık register okuması sayesinde Modbus RTU oldukça pratik olabilir.

Mesajların olay oluştuğunda hemen yayınlanması mı gerekiyor?

CAN Bus tercih edilebilir.

Sonuç: Hangisi Daha İyi?

RS-485/MODBUS ile CAN Bus arasında herkese uyan tek bir kazanan yoktur. İki teknoloji farklı sistem ihtiyaçlarına cevap verir.

RS-485 üzerinde Modbus RTU; merkezi olarak yönetilen, uzun mesafeli, PLC ve SCADA entegrasyonu gereken, register tabanlı endüstriyel uygulamalarda sade ve ekonomik bir çözümdür.

CAN Bus ise; birden fazla aktif kontrolcünün bulunduğu, mesajların olay tabanlı gönderildiği, kritik mesajlara öncelik verilmesi ve güçlü hata yönetimi gereken dağıtık sistemlerde öne çıkar.

En önemli seçim kriteri yalnızca haberleşme hızı değildir. Aşağıdaki konular birlikte değerlendirilmelidir:

  • Sistem mimarisi
  • Mesafe
  • Düğüm sayısı
  • Mesaj gecikmesi
  • Gerçek zamanlılık
  • Hata yönetimi
  • PLC ve üçüncü taraf uyumluluğu
  • Yazılım geliştirme maliyeti
  • Gelecekteki genişleme ihtiyacı
  • Güvenlik ve izolasyon gereksinimleri

Kısaca özetlersek:

“Bir merkez cihazları sırayla sorgulasın, mesafe uzun olsun ve PLC entegrasyonu kolay olsun” diyorsanız RS-485 + Modbus RTU güçlü bir seçimdir.

“Cihazlar gerektiğinde kendiliğinden konuşsun, kritik mesajlar öncelikli olsun ve haberleşme hataları donanımsal olarak yönetilsin” diyorsanız CAN Bus daha uygun olabilir.

🔖 Terimler Sözlüğü

Terim Kısa açıklama
RS-485 Diferansiyel ve çok düğümlü seri haberleşmenin elektriksel özelliklerini tanımlayan standart.
Modbus RTU Çoğunlukla RS-485 üzerinde kullanılan, sorgu-cevap tabanlı endüstriyel protokol.
CAN Bus Mesaj tabanlı, çok yöneticili, öncelik ve güçlü hata yönetimi sunan haberleşme sistemi.
Transceiver Mikrodenetleyicinin dijital sinyalini fiziksel haberleşme hattına dönüştüren alıcı-verici devre.
CRC İletim sırasında oluşan veri bozulmalarını algılamaya yarayan hata kontrol değeri.
Arbitraj Aynı anda mesaj göndermek isteyen CAN düğümleri arasında öncelik belirleme işlemi.
Dominant bit CAN arbitrajında recessive bite üstün gelen, mantıksal 0 değeri.
CAN ID CAN mesajının türünü ve arbitraj önceliğini belirleyen kimlik alanı.
Sonlandırma Kablo üzerindeki sinyal yansımalarını azaltmak için hattın uçlarına yerleştirilen direnç ağı.
Bus-Off Sürekli hata üreten bir CAN düğümünün kendisini haberleşme hattından ayırdığı durum.
CAN FD 64 bayta kadar veri alanı ve veri bölümünde daha yüksek hız sağlayabilen geliştirilmiş CAN sürümü.

📌 Ekstra Kaynaklar

28 Kasım 2025 Cuma

CAN Bus'ın Avantajları ve Dezavantajları: Modern Araçların Gizli Kahramanı

CAN Bus'ın Avantajları ve Dezavantajları: Modern Araçların Görünmeyen Kahramanı

Merhaba! Bu yazıda otomotiv dünyasının perde arkasında çalışan ama çoğu zaman adı bile geçmeyen bir teknolojiye odaklanacağız: CAN Bus. Bugün piyasadaki neredeyse tüm modern araçlarda, ECU’lar (Electronic Control Unit), sensörler ve aktüatörler arasındaki iletişimin büyük kısmı bu yapı üzerinden gerçekleşiyor.

Eğer araç elektroniklerine meraklıysan, gömülü yazılım geliştiriyorsan ya da sadece “Bu kadar sistem birbirini nasıl anlıyor?” diye düşünüyorsan, doğru yerdesin. Bu yazıda CAN Bus’ın avantajlarını, dezavantajlarını, pratik kullanım alanlarını ve gelecekte yerini nelerin alabileceğini konuşacağız. Hem yeni başlayanlar hem de sektörde çalışanlar için anlaşılır bir dil kullanmaya çalışacağım. 🚗💡

Bir otomobildeki ECU’ların aynı CAN Bus hattı üzerinde birbirine bağlandığını gösteren şematik ağ diyagramı



CAN Bus Kısaca Nedir?

CAN (Controller Area Network), temel olarak araç içindeki elektronik kontrol birimleri arasında iletişim kurulmasını sağlayan bir haberleşme protokolüdür. 1980’lerin ortasında Bosch tarafından geliştirilmiş ve daha sonra ISO 11898 standardı hâline gelmiştir.

Bu ağda her ECU, birer “node” (düğüm) gibi düşünülür ve hepsi ortak bir veri yolu (bus) üzerinde konuşur. CAN Bus; motor kontrol ünitesi, ABS, airbag, direksiyon sistemi, gövde kontrol modülü, multimedya sistemi gibi birbirinden çok farklı modüller arasında veri taşır.

CAN Bus’ın Temel Özellikleri

  • İki telli diferansiyel hat kullanır (CAN_H ve CAN_L).
  • Genellikle 500 kbps veya 1 Mbps hızlarda çalışır (klasik CAN).
  • Broadcast (yayın) mantığı ile mesajlar hattaki tüm ECU’lara iletilir.
  • Her mesajın kendine ait bir ID (Identifier) değeri vardır ve bu ID aynı zamanda önceliği belirler.

Kısaca: İki kablo üzerinden, aynı hat üzerinde bir sürü modülün konuştuğu, hataya dayanıklı, oldukça pratik bir iletişim sistemi diyebiliriz.


CAN Bus’ın Avantajları

1. Yüksek Güvenilirlik ve Hata Toleransı

CAN, otomotiv gibi güvenliğin kritik olduğu alanlarda kullanılmak üzere tasarlanmıştır. Hata algılama ve yönetimi konusunda oldukça gelişmiş mekanizmalara sahiptir:

  • Bit hata algılama (bit monitoring)
  • CRC (Cyclic Redundancy Check) ile veri bütünlüğü kontrolü
  • Acknowledge (ACK) mekanizması
  • Error frame göndererek hatalı düğümün kendini sınırlaması

Bir ECU sürekli hatalı mesaj gönderiyorsa, CAN protokolü bu ECU’yu “bus-off” hâline getirip hatta zarar vermesini engeller. Bu sayede kritik fonksiyonların sürekliliği desteklenir.

2. Diferansiyel Sinyalleme Sayesinde Gürültü Bağışıklığı

Otomotiv ortamı, özellikle de motor bölgesi; yüksek akımların, enjektörlerin, ateşleme bobinlerinin ve çeşitli elektromanyetik kaynakların olduğu oldukça gürültülü bir ortamdır. CAN, bu zorlu şartlara dayanmak için diferansiyel sinyal kullanır:

  • CAN_H ve CAN_L hatlarında zıt fazda sinyal taşınır.
  • Ortamdan gelen gürültü her iki hatta da aynı yönde biner (common-mode noise).
  • Alıcı, bu iki hattın farkını okuduğu için gürültünün etkisi büyük oranda bastırılır.

Sonuç: Uzun kablo mesafelerinde ve zorlu ortamlarda bile güvenilir iletişim. 🚙

3. Kablo Maliyeti ve Ağırlığında Azalma

CAN’dan önce araç içinde pek çok fonksiyon için nokta-nokta kablolama kullanılıyordu. Örneğin bir buton ile bir modül arasında özel kablo çekiliyor, sensörler doğrudan tek bir ECU’ya bağlanıyordu. Bu yaklaşım:

  • Daha fazla kablo → daha yüksek maliyet
  • Daha fazla kablo → daha yüksek araç ağırlığı
  • Montaj ve bakım zorluğu

CAN ile birlikte bu yapı büyük ölçüde sadeleşti:

  • Birçok sensör ve ECU aynı ortak veri yolunu kullanmaya başladı.
  • Kablolama, “power + CAN bus” hattı şeklinde basitleşti.

Özellikle büyük araçlarda (otobüs, kamyon, iş makinesi vb.) kablo metrajındaki azalma ciddi maliyet avantajı sağlar.

4. Kolay Genişletilebilir ve Esnek Mimari

CAN hattına yeni bir ECU eklemek için genellikle yapılması gereken tek şey, o ECU’yu aynı CAN_H ve CAN_L hattına bağlamaktır. Doğru terminasyon, hız ve ID planlaması yapıldıktan sonra sistem oldukça esnek bir şekilde ölçeklenebilir.

Bu da OEM’lere (araç üreticilerine) şu imkânları verir:

  • Farklı donanım paketlerinde opsiyonel modüller ekleyebilme (ör. park asistanı, kör nokta uyarı sistemi)
  • Aynı platformu kullanıp farklı model araçlar türetebilme

5. Gerçek Zamanlı (Real-Time) İletişime Uygun Yapı

CAN, özellikle kontrol döngülerinin hızlı ve deterministik olması gereken sistemlerde kullanılır. Örneğin:

  • Tekerlek hızı verilerinin ABS/ESP modülüne aktarılması
  • Motor devir, tork ve yük bilgilerinin ECU’lar arasında paylaşılması
  • Direksiyon açı sensörü verisinin sürüş destek sistemleriyle paylaşılması

CAN, doğru tasarlanmış bir ağ mimarisi ve doğru ID önceliklendirmesi ile oldukça tutarlı zamanlama performansı sunar.

6. Öncelik Tabanlı Mesajlaşma (Arbitration)

CAN Bus’ın en önemli avantajlarından biri de önceliklendirme mekanizmasıdır. CAN hattında aynı anda birden fazla ECU mesaj göndermek isterse, devreye arbitration (hakemlik) süreci girer:

  • Mesaj önceliği, ID değeri ile belirlenir.
  • Numerik olarak küçük ID = daha yüksek öncelik
  • Yüksek öncelikli mesajlar, düşük öncelikli mesajları “ezer” ve önce hattı kullanır.
Örnek:
ID 0x010  → Yüksek öncelik (ör. fren komutu)
ID 0x100  → Orta öncelik (ör. motor verisi)
ID 0x600  → Düşük öncelik (ör. konfor özellikleri)

Bu sayede fren gibi kritik bir mesaj, yoğun ağ trafiğinde bile gecikmeden iletilebilir.

7. Uygun Maliyetli ve Yaygın Ekosistem

CAN transceiver entegreleri ve CAN destekli mikrodenetleyiciler (STM32, NXP, Microchip vb.) piyasada fazlasıyla yaygın ve görece ucuzdur. Bu, CAN’i sadece otomotivde değil:

  • Endüstriyel otomasyon
  • Tıbbi cihazlar
  • Drone ve robotik uygulamalar
  • Tarım makineleri
  • Denizcilik (NMEA 2000)

gibi birçok alanda da standart hâline getirmiştir.


CAN Bus’ın Dezavantajları

Her teknolojide olduğu gibi CAN’in de bazı sınırları ve dezavantajları var. Özellikle modern araçlardaki veri miktarı arttıkça, bu dezavantajlar daha belirgin hâle geliyor.

1. Sınırlı Bant Genişliği (Veri Hızı)

Klasik CAN (Classical CAN) için tipik maksimum hız 1 Mbps’tir. Bu hız; sensör verileri, komut mesajları ve basit durum bilgileri için fazlasıyla yeterli olsa da, günümüz araçlarında kullanılan:

  • Kamera görüntüleri
  • Radar/LiDAR verileri
  • Yüksek çözünürlüklü ekran veri akışları

gibi uygulamalar için oldukça yetersiz kalır.

Bu nedenle OEM’ler, özellikle otonom sürüş ve gelişmiş sürüş destek sistemlerinde Automotive Ethernet gibi daha yüksek bant genişlikli çözümlere yöneliyor.

2. Mesaj Boyutu Sınırlaması

Klasik CAN çerçevesinde en fazla 8 byte veri taşınabilir. Büyük boyutlu veriler (örneğin uzun bir durum paketi, kalibrasyon verisi veya log bilgisi) bu sınır nedeniyle parçalara bölünmek zorundadır.

Bu sorunu azaltmak için geliştirilen CAN FD (Flexible Data Rate) standardı, veri alanını 64 byte’a kadar genişletir ve daha yüksek veri hızları sağlar. Yine de, bu hâliyle bile CAN FD; görsel veri gibi çok büyük akışlar için yeterli değildir.

3. Yerleşik Güvenlik (Security) Mekanizması Bulunmaması

CAN’in tasarlandığı dönemlerde araçlar dış dünyaya bu kadar bağlı değildi ve siber saldırı tehdidi bugünkü kadar gündemde değildi. Bu nedenle CAN protokolü:

  • Kimlik doğrulama (authentication)
  • Şifreleme (encryption)
  • Erişim kontrolü (access control)

gibi güvenlik mekanizmalarını yerleşik olarak içermez.

Bu da şu riskleri doğurur:

  • Yetkisiz erişimle mesaj dinleme (sniffing)
  • Sahte mesaj gönderme (spoofing)
  • Kritik sistemlere müdahale etme

Bu yüzden günümüzde ISO/SAE 21434 ve UNECE R155 gibi siber güvenlik standartları, CAN tabanlı ağlar üzerinde ek güvenlik katmanları ve IDS (Intrusion Detection System) gibi çözümlerin kullanılmasını şart koşuyor.

4. Broadcast Yapının Gizlilik ve Güvenlik Açısından Riskleri

CAN Bus, doğası gereği bir broadcast (yayın) protokoldür; yani hat üzerindeki tüm mesajlar, hatta bağlı olan tüm ECU’lar tarafından dinlenebilir. Bu durum:

  • Her ECU’nun, doğru filtreleme yapılmazsa gereğinden fazla mesaj görmesine
  • Saldırganın tek bir noktadan bağlanarak tüm trafiği izlemesine

imkân tanır. Dolayısıyla, CAN yapısı güvenlik açısından ekstra tasarım önlemleri gerektirir.

5. Uzun Hatlarda ve Yanlış Topolojilerde Sinyal Bütünlüğü Problemleri

CAN hattı, teoride çok esnek görünse de fiziksel tasarım tarafında dikkat edilmesi gereken noktalar vardır:

  • Hattın iki ucuna mutlaka 120 Ω terminasyon direnci konmalıdır.
  • “Yıldız topoloji” gibi yanlış kablolama yöntemleri yansımalara (reflections) neden olabilir.
  • Çok uzun kablolarda ve yüksek hızlarda sinyal zayıflaması görülebilir.

Bu sorunlar, özellikle saha uygulamalarında “Arada sırada çalışan, sonra bozulan” gizemli hatalara sebep olabilir. Bu yüzden hem elektriksel tasarım hem de PCB layout tarafında dikkatli olmak gerekir.


Gerçek Hayattan CAN Bus Örnekleri

Motor Kontrolü (Powertrain)

Motor ECU’su; sensörlerden gelen:

  • Devir (RPM)
  • Gaz pedalı konumu
  • Emme manifoldu basıncı
  • Sıcaklık sensörleri

gibi verileri CAN üzerinden alır ve diğer modüllerle paylaşır. Örneğin:

  • Motor tork bilgisi şanzıman ECU’suna iletilir.
  • Yakıt tüketim bilgisi gösterge paneline gönderilir.

Şasi ve Güvenlik Sistemleri

ABS, ESP, hava yastığı modülleri gibi güvenlik kritik sistemler, CAN üzerinden sürekli veri alışverişi yapar. Örneğin:

  • Tekerlek hız sensörleri → ABS/ESP modülü
  • Yanal ivme ve dönüş hızı → ESP/ADAS modülü
  • Çarpışma sensörleri → Airbag kontrol ünitesi

Bu verilerin doğru zamanda ve doğru şekilde iletilmesi, doğrudan yolcu güvenliğini etkiler.

Konfor ve Multimedya

Cam kaldırma modülleri, koltuk kontrol üniteleri, klima, far kontrolü ve multimedya sistemleri de CAN üzerinden haberleşir. Örneğin:

  • “Kapı açıldı” bilgisi hem gövde kontrol modülüne hem iç aydınlatma sistemine iletilir.
  • Direksiyondaki multimedya tuşları, ses sistemiyle CAN üzerinden konuşur.

Bu sayede araç içindeki tüm konfor özellikleri birbirine entegre, senkronize ve yönetilebilir hâle gelir.


CAN FD ve Automotive Ethernet ile Kıyaslama

Modern araçlarda veri miktarı arttıkça, klasik CAN’in limitleri daha fazla hissedilir hâle geldi. Bunun üzerine iki önemli teknoloji öne çıktı:

CAN FD (Flexible Data Rate)

  • Veri alanını 8 byte → 64 byte’a çıkarır.
  • Belli kısımlarda daha yüksek baudrate kullanarak toplam veri hızını artırır.
  • Klasik CAN ile geriye dönük uyumluluk sunar (donanım/altyapı avantajı).

CAN FD, özellikle daha yoğun veri alışverişi gerektiren kontrol modüllerinde (örneğin modern güç aktarım sistemleri, batarya yönetim sistemleri) giderek daha fazla kullanılmaktadır.

Automotive Ethernet

  • 10 Mbps, 100 Mbps hatta 1 Gbps seviyelerinde veri taşıyabilir.
  • Kamera, radar, multimedya gibi yüksek bant genişliği isteyen uygulamalar için uygundur.
  • Switch tabanlı yapısı ile segmentasyon ve daha iyi güvenlik imkânı sunar.

Yine de, maliyet, karmaşıklık ve gerçek zamanlı kontrol açısından değerlendirdiğimizde; CAN Bus hâlâ kritik kontrol yollarında vazgeçilmez konumunu koruyor.


CAN Bus Avantaj & Dezavantaj Karşılaştırma Tablosu

Başlık Avantaj Dezavantaj
Bant Genişliği Kontrol verileri için yeterli Görüntü, radar vb. için yetersiz
Güvenilirlik Gelişmiş hata algılama ve bus-off mekanizması Yerleşik siber güvenlik özellikleri yok
Kablolama İki telli yapı, düşük maliyet ve ağırlık Yanlış topoloji ve terminasyon sorun yaratabilir
Esneklik Ağa yeni ECU eklemek kolay Toplam trafik iyi planlanmazsa tıkanma riski
Mesaj Yapısı Basit ve deterministik Klasik CAN’de 8 byte sınırı

Sonuç: CAN Bus Neden Hâlâ Oyunun İçinde?

Özetle; CAN Bus, düşük maliyet, yüksek güvenilirlik, gerçek zamanlı performans ve yaygın ekosistem gibi güçlü avantajlara sahip. Evet, bant genişliği sınırlı ve yerleşik güvenlik mekanizmaları yok; ancak doğru mimari, uygun güvenlik katmanları ve iyi bir ID/mesaj tasarımıyla hâlâ son derece güçlü bir çözüm sunuyor.

Günümüzde otonom sürüş, bağlı araçlar (connected cars) ve OTA (Over-the-Air) güncellemeler gibi yeni kavramlarla birlikte Ethernet ve CAN FD gibi teknolojiler öne çıksa da, klasik CAN Bus’ın uzun yıllar daha araçların kalbinde yaşamaya devam edeceğini söylemek yanlış olmaz. 🚗✨


🔖 Terimler Sözlüğü

Terim Açıklama
CAN Controller Area Network – Araç içi iletişim protokolü
ECU Electronic Control Unit – Elektronik kontrol ünitesi/modülü
Diferansiyel Sinyal İki hat arasındaki gerilim farkı üzerinden veri iletimi tekniği
Arbitration CAN hattında mesajların ID’ye göre önceliklendirilmesi ve çakışma çözümü
CRC Cyclic Redundancy Check – Veri bütünlüğünü kontrol etmek için kullanılan algoritma
CAN FD Flexible Data Rate – Daha yüksek veri hızı ve daha büyük veri alanı sunan CAN genişlemesi
Automotive Ethernet Yüksek bant genişlikli, Ethernet tabanlı araç içi haberleşme teknolojisi
Bus-off Sürekli hata üreten ECU’nun CAN hattından otomatik olarak izole edilmesi durumu

📌 Ekstra Kaynaklar

27 Haziran 2025 Cuma

Otomotiv Ethernet vs CAN FD: Hangisi Otomotivin Geleceği?

🚗 Otomotiv Ethernet vs CAN FD: Hangisi Otomotivin Geleceği?

Günümüzde otomotiv elektroniği baş döndürücü bir hızla gelişiyor. Otonom sürüş sistemleri, gelişmiş sürücü destek sistemleri (ADAS), yüksek çözünürlüklü kameralar, radarlar ve daha fazlası... Bu sistemlerin tümü, araç içindeki elektronik kontrol üniteleri (ECU’lar) arasında hızlı ve güvenilir veri iletişimi gerektiriyor. Peki bu veri iletişimi nasıl sağlanıyor? Karşınızda iki güçlü aday: CAN FD ve Otomotiv Ethernet.

Bu yazımızda, her iki teknolojiyi detaylıca karşılaştırıyor, avantajlarını ve zorluklarını inceliyor ve “Geleceğin iletişim protokolü hangisi olacak?” sorusuna birlikte cevap arıyoruz. 😊

Visual comparison of CAN FD bus and Automotive Ethernet data flow in a modern car network

📚 Önce Temel Kavramlar

  • CAN FD (Flexible Data-rate): Klasik CAN protokolünün geliştirilmiş versiyonudur. Daha yüksek veri hızları ve daha büyük veri yükleri taşır.
  • Otomotiv Ethernet: Bilgisayar ağlarındaki Ethernet’in otomotiv uyarlamasıdır. Özellikle yüksek bant genişliği gerektiren uygulamalar için geliştirilmiştir.

⚙️ Teknik Özellik Karşılaştırması

Özellik CAN FD Otomotiv Ethernet
Maksimum Veri Hızı 8 Mbps 100 Mbps – 1 Gbps+
Veri Çerçeve Boyutu 64 byte 1500 byte (MTU)
Topoloji Bus (dallanmış yapı) Point-to-Point veya Star
Gerçek Zamanlılık Yüksek TSN (Time Sensitive Networking) ile mümkün
Maliyet Düşük Orta-Yüksek
EMI/EMC Dayanıklılığı Yüksek Orta (ek önlemler gerekebilir)

🔌 Kullanım Senaryoları

CAN FD Ne Zaman Tercih Edilir?

  • Gövde elektroniği (body control modules)
  • Kapı kontrol sistemleri
  • Geliştirilmiş motor kontrol üniteleri
  • Gerçek zamanlılık gerektiren düşük-bant sistemler

Otomotiv Ethernet Ne Zaman Öne Çıkar?

  • ADAS (İleri Sürücü Destek Sistemleri)
  • Yüksek çözünürlüklü kamera sistemleri
  • Radar, LiDAR ve sensor fusion uygulamaları
  • Otonom sürüş kontrol üniteleri

🔍 Gerçek Hayattan Bir Örnek

Yeni nesil bir araçta kamera verileri Ethernet üzerinden taşınırken; aynı araçtaki kapı kilidi sinyalleri CAN FD üzerinden gönderilir. Çünkü birisi yüksek bant genişliği ister, diğeri ise düşük gecikmeli, güvenilir iletişim.

🏁 Gelecek Kimin?

Gelecekte bu iki teknolojinin birlikte var olması oldukça olası. CAN FD, maliyet ve dayanıklılık açısından hala birçok yerde tercih edilecek. Ancak otonom araçlar ve yüksek bant genişliği gerektiren sistemlerde Ethernet’in yeri giderek büyüyor.

💡 Hibrit Yapılar

Birçok OEM üreticisi, hibrit iletişim mimarilerine yöneliyor. Örneğin:

  • Motor kontrolü için CAN FD
  • Görüntü işleme için Ethernet
  • Gateway ECU üzerinden farklı protokoller arası geçiş

🛠️ Zorluklar

  • Ethernet için elektromanyetik uyumluluk (EMC) sorunları
  • CAN FD ile veri miktarının sınırlı olması
  • Her iki protokol için zaman senkronizasyonu gereksinimi

🧠 Sonuç

CAN FD, otomotiv dünyasında köklü bir sistem olarak kullanılmaya devam edecek. Ancak Ethernet, özellikle otomasyon, otonomi ve bağlantılı araçlarda kaçınılmaz bir gereklilik haline geliyor. Hangi protokolün kullanılacağı, uygulamanın ihtiyaçlarına göre değişiyor.

🔖 Terimler Sözlüğü

Terim Açıklama
CAN FD Flexible Data-rate: Geliştirilmiş CAN protokolü
Otomotiv Ethernet Otomotiv uyumlu Ethernet protokolü
ECU Electronic Control Unit: Elektronik kontrol ünitesi
TSN Time Sensitive Networking: Gerçek zamanlı veri aktarım tekniği

📌 Ekstra Kaynaklar

22 Haziran 2025 Pazar

Steer-by-Wire Nedir? 🚗 Elektronik Direksiyonun Geleceği

Steer-by-Wire Nedir? 🚗 Elektronik Direksiyonun Geleceği

Otomotiv teknolojisi her geçen gün daha dijital ve daha akıllı hale geliyor. Bu dönüşümün en dikkat çekici parçalarından biri ise “Steer-by-Wire” yani elektronik kontrollü direksiyon sistemleri. Peki bu sistemler nasıl çalışır? Neden giderek daha fazla araçta tercih ediliyor? Güvenli mi, pratik mi, pahalı mı? Tüm detaylara bu yazımızda değiniyoruz.

Illustration of a modern steer-by-wire system with electronic steering wheel and actuator-based wheel control.

🧩 Steer-by-Wire Ne Demek?

Steer-by-Wire, geleneksel mekanik direksiyon sistemlerinde bulunan direksiyon mili, dişli kutusu ve bağlantı çubukları gibi mekanik bağlantıların yerini elektronik bileşenlerin aldığı bir sistemdir. Yani direksiyon simidi ile tekerlekler arasında artık fiziksel bir bağlantı bulunmaz.

Bu sistemde sürücünün direksiyonu çevirme hareketi sensörlerle algılanır, kontrol ünitesi (ECU) bu veriyi işler ve tekerleklere gerekli dönüş komutu, elektrik motorları aracılığıyla iletilir.

⚙️ Steer-by-Wire Nasıl Çalışır?

Steer-by-Wire sistemi genel olarak şu bileşenlerden oluşur:

  • Direksiyon Açısı Sensörü: Sürücünün çevirdiği direksiyon açısını ölçer.
  • ECU (Elektronik Kontrol Ünitesi): Alınan veriyi işler, gerekli komutları üretir.
  • Aktüatörler: Tekerleklerin açısını değiştiren elektrik motorlarıdır.
  • Geri Bildirim Mekanizması: Direksiyon simidine yapay kuvvet hissi verir (örneğin yol direncini hissettirme).

🛡️ Güvenlik Ne Durumda?

Direksiyon gibi kritik bir sistemin elektronikleştirilmesi doğal olarak bazı güvenlik endişelerini de beraberinde getiriyor. Ancak otomotiv sektörü, bu tür sistemlerin ISO 26262 gibi fonksiyonel güvenlik standartlarına uygun olarak tasarlanmasını zorunlu kılıyor.

Steer-by-Wire sistemlerinde yaygın olarak aşağıdaki güvenlik önlemleri alınır:

  • Çift yedekli sensörler
  • Çift işlemcili ECU’lar
  • Acil durumlarda kontrolü sürücüye veren fail-operational yapılar
  • Batarya veya enerji kesintisinde geçici mekanik kontrol opsiyonu (hibrit sistemler)

🚀 Avantajları Neler?

Steer-by-Wire sisteminin sunduğu avantajlar oldukça dikkat çekicidir:

  • Ağırlık Azalması: Fiziksel bağlantılar ortadan kalktığı için sistem hafifler.
  • Daha Az Yer Kaplama: Direksiyon miline ihtiyaç kalmadığı için tasarım esnekliği artar.
  • Kişiselleştirilebilir Sürüş: Direksiyon sertliği, dönüş açısı gibi parametreler yazılımla ayarlanabilir.
  • Otonom Sürüş Uyumlu: Elektronik sistem, otonom sürüş algoritmalarına kolayca entegre edilebilir.

🔧 Dezavantajları da Var mı?

Elbette. Her teknolojide olduğu gibi Steer-by-Wire sistemlerinin de bazı dezavantajları mevcut:

  • Maliyet: Gelişmiş elektronik bileşenler nedeniyle ilk yatırım maliyeti yüksektir.
  • Algısal Güven: Sürücüler fiziksel bağlantı olmayışını ilk etapta garipseyebilir.
  • Enerji Bağımlılığı: Sistemin düzgün çalışması için sürekli elektrik beslemesi gerekir.

🔄 Geleneksel Direksiyon ile Farkları

Özellik Geleneksel Direksiyon Steer-by-Wire
Fiziksel Bağlantı Var Yok
Geri Bildirim Doğal, mekanik Yapay (force feedback)
Yedeklilik Genelde yok Elektronik yedeklilik
Tasarım Özgürlüğü Kısıtlı Yüksek

📈 Gelecekte Nerelerde Kullanılacak?

Şu anda Steer-by-Wire sistemleri çoğunlukla premium segmentte veya elektrikli araçlarda karşımıza çıkıyor. Ancak teknolojinin yaygınlaşmasıyla birlikte aşağıdaki alanlarda daha fazla görmemiz bekleniyor:

  • Otonom Araçlar
  • Ağır vasıtalar (otobüs, kamyon)
  • Tarım ve inşaat araçları

🛠️ Hangi Markalar Kullanıyor?

Steer-by-Wire sistemlerini uygulayan bazı öncü üreticiler:

  • Infiniti: Q50 modelinde Direct Adaptive Steering teknolojisi
  • Tesla: Cybertruck için yoke-style steer-by-wire planı
  • Nissan: Otonom test araçlarında yaygın kullanım

🧠 Yazılım ve Kalibrasyonun Rolü

Steer-by-Wire sistemlerinde yazılım; sürücü geri bildirimi, dönüş sertliği, direksiyon davranışı gibi pek çok unsuru belirler. Bu nedenle yazılım kalibrasyonu hem güvenlik hem sürüş keyfi açısından kritik rol oynar.

Yapay zeka destekli sistemlerde, sürücünün sürüş stiline göre adaptif davranışlar bile mümkün hale gelmektedir.

🔮 Sonuç: Direksiyonun Geleceği Burada mı?

Steer-by-Wire sistemleri otomotiv endüstrisinin dijitalleşmesinin önemli bir parçası. Hem otonom sürüşe hazırlık, hem de kullanıcı deneyimini artırmak açısından ciddi potansiyel taşıyor.

Ancak yaygınlaşması için hem maliyetlerin düşmesi hem de kullanıcı güveninin artması gerekiyor. Önümüzdeki yıllarda bu sistemin daha fazla modelde karşımıza çıkması oldukça muhtemel. 🚘

🔖 Terimler Sözlüğü

Terim Açıklama
ECU Electronic Control Unit, kontrol birimi
Aktüatör Elektriksel komutla mekanik hareket üreten bileşen
Force Feedback Geri bildirim için uygulanan yapay direnç hissi
ISO 26262 Otomotiv için fonksiyonel güvenlik standardı

📌 Ekstra Kaynaklar

21 Haziran 2025 Cumartesi

Gökyüzünde Konuşan Sistemler: ARINC 429 Protokolü Nedir? (Temel Anlatım ve Örneklerle)

✈️ Gökyüzünde Konuşan Sistemler: ARINC 429 Protokolü Nedir?

Havacılık sektörü, veri güvenliği ve tutarlılığı açısından en hassas endüstrilerden biridir. Uçakta yüzlerce sistem aynı anda çalışır; pilotun önündeki ekranlardan uçuş kontrol yüzeylerine kadar her şey, dakik hesaplamalar ve kesin bilgi akışıyla işler.

Peki, bu sistemler birbiriyle nasıl haberleşiyor?
Cevap: ARINC 429 protokolü!

Bu yazıda, ARINC 429’un ne olduğunu, nasıl çalıştığını, nerelerde kullanıldığını ve örnek veri formatlarını sade bir dille anlatacağız. Havacılığa meraklı biri ya da bu alana giriş yapmak isteyen biri için temel bir ARINC 429 rehberi olacak 😊

Cockpit view showing ARINC 429 data flow from aircraft sensors to cockpit instruments and flight recorder

🧭 ARINC 429 Nedir?

ARINC (Aeronautical Radio, Incorporated) 429, uçak içindeki elektronik sistemlerin birbiriyle veri alışverişi yapmasını sağlayan, bir yönlü (unidirectional), seri haberleşme protokolüdür.

“O zaman USB kablosu gibi bir şey mi?”
Aslında benziyor ama çok daha güvenli, sağlam ve havacılık şartlarına özel tasarlanmış bir sistemdir.

🧩 Temel Özellikleri

ÖzellikAçıklama
Veri YönüTek yönlü (1 gönderici ➝ 1 veya daha fazla alıcı)
Veri Hızı12.5 kbps veya 100 kbps (yaygın olan 100 kbps)
Fiziksel KatmanDiferansiyel sinyal (RS-422 tabanlı)
Veri FormatıHer veri 32 bittir
Bağlantı TipiPoint-to-point veya Multi-drop

🧠 Nasıl Çalışır?

ARINC 429'da her veri iletimi 32 bitlik kelimeler (word) halinde yapılır. Her bir kelime belirli alanlara ayrılmıştır.

📦 ARINC 429 Veri Yapısı

| 31   | 30-29 | 28-27 | 26-11              | 10-9 | 8-1    | 0     |
| Parity | SSM | SDI | Veri (Data) | RT | Label | Parity |
AlanBit NoAçıklama
Label1-8Hangi verinin gönderildiğini belirten etiket (ör: hız, irtifa)
SDI9-10Kanal seçici (opsiyonel)
Data11-29Asıl veri kısmı (ör: 300 knots)
SSM30-31Verinin durumu (normal, hata, geçersiz vb.)
Parity32Veri doğrulama biti (tek sayıda 1 için)

Örnek:

  • Label: 203 → Hava Hızı
  • Data: 300 knots
  • SSM: 00 → Normal veri
  • Parity: 1 → Hataları tespit etmek için

✈️ Nerelerde Kullanılır?

ARINC 429, özellikle sabit kanatlı uçaklarda (örneğin Airbus, Boeing) kullanılır. Aşağıdaki sistemlerde yaygın olarak görülür:

  • Uçuş yönetim sistemleri (FMS)
  • Otomatik pilot
  • Navigasyon cihazları (IRS, GPS)
  • Hız sensörleri (Pitot tüpleri)
  • Işık sistemleri
  • Uçuş veri kaydedicileri (black box)

🔄 Neden Tek Yönlü?

ARINC 429’un tek yönlü olması, karmaşayı azaltır ve güvenliği artırır.

Sistem şöyle işler:

  • Veriyi sadece bir cihaz gönderir.
  • Birden fazla cihaz aynı veriyi dinleyebilir.

Örnek: “Hava hızı 300 knots” bilgisi bir sensörden çıkar, aynı anda otopilot, ekranlar ve black box bu veriyi alır.

🧪 Senaryo ile Açıklama

Hayal edin:

  • Uçakta bir hava hızı sensörü var.
  • Bu sensör, ARINC 429 üzerinden veri gönderiyor.
  • 3 sistem bu veriyi dinliyor: Otomatik pilot, ekranlar, kara kutu

Gönderilen veri:

  • Label: 203
  • Data: 300 knots
  • SSM: 00
  • Parity: 1

Hiçbir sistem cevap vermez, sadece veri alır.

⚙️ Diğer Protokollerle Karşılaştırma

ÖzellikARINC 429CAN BusRS-485
Veri YönüTek yönlüÇift yönlüÇift yönlü
Kullanım AlanıHavacılıkOtomotiv, endüstriEndüstri
Veri Formatı32-bit sabitDeğişkenEsnek
Hata TespitiParity bitiCRC + ACKGenelde yok
KararlılıkÇok yüksekOrtaDüşük-Orta

🔒 Neden Hâlâ Kullanılıyor?

  • Stabil ve test edilmiş sistem
  • Deterministik yapı (önceden öngörülebilirlik)
  • Basit mimari
  • Geriye dönük uyumluluk

Yeni nesil uçaklarda ARINC 664 (AFDX) gibi sistemler gelse de ARINC 429 hâlâ güvenilir bir standardır.

🧰 Donanım Tarafı

  • Diferansiyel sinyal (RS-422 uyumlu)
  • 2 kablo yeterlidir
  • Örnek entegre: Holt HI-3593

🧪 Simülasyon ve Hobi Seviyesi Uygulamalar

  • ARINC 429 USB dongle
  • Arduino ile temel sinyal üretimi
  • Simulink ile blok bazlı modelleme

🎯 Sonuç

ARINC 429 öğrenmeye değer mi? Kesinlikle evet!

Özellikle havacılıkta çalışmak isteyen mühendisler için vazgeçilmez bir altyapıdır. Sadeliği sayesinde öğrenmesi kolay, uygulaması güçlüdür.

🔖 Terimler Sözlüğü

TerimAnlamı
LabelVeriyi tanımlayan numara
SSMVerinin geçerlilik durumu
ParityHata kontrol biti
TransmitterVeri gönderen cihaz
ReceiverVeriyi alan cihaz

📌 Ekstra Kaynaklar

  • Holt Integrated Circuits
  • ARINC 429 PDF dokümanı (Google üzerinden erişebilirsiniz)
  • GitHub’da ARINC 429 simülasyon projeleri

1 Mart 2025 Cumartesi

STM32 HAL Kullanırken Performans Optimizasyonu: Kesme ve DMA İpuçları

STM32 HAL Kullanırken Performans Optimizasyonu: Kesme ve DMA İpuçları

STM32 mikrodenetleyicileri, özellikle gömülü sistemler ve zaman kritikli uygulamalar için oldukça popülerdir. Ancak, yazılım tarafında performans optimizasyonu yapmak, donanımın tüm potansiyelini verimli bir şekilde kullanabilmek için kritik önem taşır. Bu yazıda, STM32 HAL (Hardware Abstraction Layer) kütüphanesini kullanarak performansı artırmanıza yardımcı olacak iki önemli konuyu ele alacağız: Kesme ve DMA (Direct Memory Access).

1. Kesme (Interrupt) ile Hızlı Tepki

Kesme, STM32 gibi mikrodenetleyicilerde, belirli bir olay gerçekleştiğinde programın normal akışından çıkıp, hemen o olaya tepki vermesini sağlar. Bu özellik, özellikle zaman kritik uygulamalarda oldukça faydalıdır. Örneğin, bir sensörden gelen veriyi hızlıca okumak veya dış bir butona basıldığında kullanıcıya tepki vermek için kesme kullanabilirsiniz.

Kesme Kullanmanın Avantajları:

  • Hızlı Tepki: Kesme kullanarak, sürekli olarak bir işlem yapmayı beklemek yerine, bir olay gerçekleştiğinde hemen müdahale edebilirsiniz. Bu, zaman kazandırır.
  • Verimli Zaman Kullanımı: Mikrodenetleyici başka işlemlerle meşgulken, kesmeler sayesinde sadece gerekli olduğunda işlem yapılır. Bu, CPU’nun verimli kullanılmasını sağlar.

Kesme Performansı İçin İpuçları:

  • Kesme Önceliği Ayarı: STM32, çoklu kesme kaynakları destekler ve her bir kesmeye bir öncelik verebilirsiniz. Kesme önceliği ayarlayarak, en önemli olayların ön planda işlenmesini sağlayabilirsiniz. Bu, kritik uygulamalarda kesme sırasının doğru yönetilmesini sağlar.

  • Kesme Fonksiyonlarını Kısa Tutun: Kesme fonksiyonları kısa olmalıdır. Kesme fonksiyonları sırasında, mikrodenetleyici başka kesmeleri almaz ve bu da sistemin yanıt süresini olumsuz etkiler. Yalnızca gerekli işlemleri yapın ve büyük hesaplamaları ana program akışına bırakın.

2. DMA (Direct Memory Access) ile Verimli Veri Transferi

DMA, mikrodenetleyicinin CPU’sunu devre dışı bırakarak, verileri bir bellek biriminden diğerine hızlı bir şekilde aktarır. Bu özellik, özellikle yüksek hızda veri transferi yapmanız gerektiğinde faydalıdır. Örneğin, ADC (Analog to Digital Converter) ile veri okuma veya UART üzerinden gelen veriyi hafızaya kaydetme gibi işlemler için DMA kullanmak verimliliği artırır.

DMA Kullanmanın Avantajları:

  • CPU Yükünü Azaltır: CPU, veri transferini kontrol etmez, bu da diğer işlemler için daha fazla işlem gücü bırakır.
  • Hızlı Veri Transferi: CPU’dan bağımsız olarak, veri transferi çok daha hızlı yapılır. Bu, özellikle büyük veri setleriyle çalışırken oldukça önemlidir.

DMA Performansı İçin İpuçları:

  • DMA ile Kesme Kullanımı: DMA ile veri transferi sırasında kesme kullanarak, transfer tamamlandığında işlem yapabilirsiniz. Bu, veri transferi bitmeden önce başka bir işlem başlatmanın önüne geçer.

  • Veri Boyutunu Yönetme: DMA işlemleri genellikle büyük veri blokları üzerinde daha etkilidir. Küçük veri transferleri için DMA yerine doğrudan işlemler yapmak daha verimli olabilir. Gereksiz veri transferlerini önlemek için veri boyutlarını optimize edin.

  • DMA Kanal Yapılandırması: STM32, birden fazla DMA kanalını aynı anda kullanabilir. Bu kanalların doğru yapılandırılması, veri transferinin en verimli şekilde yapılmasını sağlar. DMA kanalındaki kaynak ve hedef adreslerini doğru belirlemek çok önemlidir.

3. Kesme ve DMA Birlikte Kullanımı

Kesme ve DMA birlikte kullanıldığında, çok daha verimli ve hızlı sistemler oluşturabilirsiniz. Örneğin, ADC ile sürekli veri okurken, DMA ile verileri hafızaya aktarabilir ve her yeni veri bloğu geldiğinde bir kesme ile işlem yapabilirsiniz. Bu sayede, hem hızlı veri transferi hem de hızlı işlem yapma imkanı elde edersiniz.

Kesme ve DMA’yı Birlikte Kullanırken Dikkat Edilmesi Gerekenler:

  • Kesme ve DMA Zamanlamasını Yönetme: Kesme ve DMA arasında zamanlama çatışmaları olabilir. DMA ile veri aktarımı bittiğinde bir kesme gerçekleşeceği için, kesme sırasında DMA işlemlerini engellemeyen bir yapı kurmak önemlidir.
  • Kesme İzinlerini Yönetme: DMA kesme işlemi sırasında, başka bir kesmenin engellenmemesi için doğru kesme izinlerini yönetmek gerekir. Örneğin, DMA kesmesinin aktif olduğu zamanlarda, düşük öncelikli kesmeleri geçici olarak devre dışı bırakmak verimliliği artırır.

Sonuç

Kesme ve DMA, STM32 mikrodenetleyicilerinin performansını önemli ölçüde artıran iki güçlü özelliktir. Doğru kullanıldığında, bu iki özellik, zaman ve kaynak verimliliğini optimize eder, CPU yükünü azaltır ve tepki sürelerini hızlandırır. STM32 HAL kütüphanesi, bu özellikleri kullanmayı kolaylaştırır, ancak yine de performans için dikkatli bir yapılandırma gereklidir. Bu yazıda verdiğimiz ipuçları, projelerinizde daha verimli ve hızlı sistemler kurmanıza yardımcı olacaktır.

Unutmayın, her zaman yazılımın yanı sıra donanımı da doğru şekilde yapılandırmak gerekir. Performans optimizasyonu, sistemin tüm bileşenlerinin uyumlu bir şekilde çalışmasıyla mümkündür.

28 Şubat 2025 Cuma

UN R156 Regülasyonu: Araç Yazılım Güncellemeleri için Güvenlik ve Süreç Yönetimi

Otomotiv endüstrisi, dijitalleşmenin hız kazanmasıyla birlikte giderek daha fazla siber güvenlik tehdidine maruz kalıyor. Günümüzde modern araçlar, internet bağlantıları, kablosuz güncellemeler (OTA - Over-the-Air) ve akıllı sistemler sayesinde daha fazla yazılım bileşeni içeriyor. Ancak bu gelişmeler, araçların siber saldırılara karşı korunmasını zorunlu hale getiriyor. İşte tam da bu noktada, Birleşmiş Milletler Avrupa Ekonomik Komisyonu (UNECE) tarafından yayınlanan UN R156 regülasyonu devreye giriyor.

Bu yazıda, UN R156’nın ne anlama geldiğini, hangi konuları kapsadığını ve otomotiv sektöründeki önemini temel seviyede ele alacağız.

UN R156 Nedir?

UN R156 (Regulation No. 156), araçların yazılım güncellemeleriyle ilgili güvenlik ve yönetim gereksinimlerini belirleyen bir düzenlemedir. Bu regülasyon, özellikle araçların uzaktan güncellenmesi (OTA) süreçlerinin güvenli ve izlenebilir olmasını sağlamayı amaçlar. UNECE tarafından geliştirilen bu regülasyon, Software Update Management System (SUMS) yani Yazılım Güncelleme Yönetim Sistemi kavramını ortaya koyarak, otomobil üreticilerinin yazılım güncellemelerini sistematik bir şekilde yönetmelerini zorunlu kılar.

Regülasyonun ana hedefi, kötü amaçlı yazılım yüklenmesini önlemek, güvenli güncelleme süreçleri sağlamak ve araç içindeki yazılım değişikliklerinin kayıt altına alınmasını garanti etmektir.

UN R156 Hangi Konuları Kapsar?

Bu regülasyon, otomotiv sektöründe yazılım güncellemelerinin düzenlenmesi için dört ana gereksinim belirler:

  1. Yazılım Güncelleme Yönetim Sistemi (SUMS) Kurulumu:

    • Araç üreticileri, tüm yazılım güncellemelerini yönetebilecek bir sistem kurmalı ve bu sistemi resmi olarak belgelendirmelidir.
    • Bu sistem, güncelleme süreçlerini şeffaf ve izlenebilir hale getirmelidir.
  2. Güncelleme Süreçlerinin Güvenliği:

    • Tüm yazılım güncellemelerinin kimlik doğrulaması yapılmalı ve yetkisiz erişimlere karşı korunmalıdır.
    • Yazılımın güncelleme sırasında bozulmaması için güvenlik mekanizmaları (örn. şifreleme, imza doğrulama) uygulanmalıdır.
  3. Güncellemelerin Takibi ve Belgelendirilmesi:

    • Yapılan tüm yazılım değişiklikleri kayıt altına alınmalı ve gerektiğinde denetim için hazır tutulmalıdır.
    • Üreticiler, bir aracın hangi yazılım sürümüne sahip olduğunu gösterebilmelidir.
  4. Araç Sahibi ve Yetkililer için Bilgilendirme:

    • Yazılım güncellemeleri sırasında kullanıcılar bilgilendirilmeli, güncelleme süreci hakkında şeffaf bir iletişim sağlanmalıdır.
    • Güncellemelerin araç fonksiyonlarına etkisi açıkça belirtilmelidir.

UN R156 Neden Önemlidir?

Eskiden, araç yazılımlarının güncellenmesi yalnızca servislerde yapılan fiziksel işlemlerle gerçekleşiyordu. Ancak modern araçlarda kablosuz (OTA) güncellemeler yaygınlaştıkça, güvenli yazılım yönetimi kritik bir hale geldi.

Bu regülasyonun otomotiv sektörü açısından en önemli faydaları şunlardır:
Siber Güvenliği Artırır: Yetkisiz yazılım yüklemelerinin önüne geçerek araçların siber saldırılara karşı korunmasını sağlar.
Hukuki ve Ticari Riskleri Azaltır: Üreticilerin, yazılım kaynaklı hatalara karşı daha hızlı müdahale edebilmesine yardımcı olur.
Regülasyon Uyumluluğu Sağlar: UN R156, Avrupa Birliği başta olmak üzere birçok ülkede yasal bir zorunluluk haline gelmiştir. Uyumsuzluk durumunda üreticilere ciddi yaptırımlar uygulanabilir.
Araç Yaşam Döngüsünü Uzatır: Güvenli yazılım güncellemeleri sayesinde araçlar daha uzun süre güncel ve işlevsel kalır.

Sonuç

UN R156, otomotiv sektöründe yazılım yönetiminin güvenli ve sistematik bir şekilde yapılmasını zorunlu kılan bir regülasyondur. Siber güvenlik tehditlerinin arttığı bir dönemde, araç yazılım güncellemelerinin güvenliğini sağlamak, sadece üreticiler için değil, kullanıcılar için de büyük önem taşımaktadır.

Özellikle otonom sürüş teknolojilerinin yaygınlaşmasıyla birlikte, yazılım güncellemelerinin güvenli olması hayati bir konu haline gelmiştir. Bu nedenle, UN R156 regülasyonu, gelecekte daha da önem kazanacak ve tüm otomotiv üreticileri için standart bir gereklilik haline gelecektir.

RS-485/MODBUS ve CAN Bus Karşılaştırması: Hangisi Ne Zaman Tercih Edilmeli?

RS-485/MODBUS ve CAN Bus Karşılaştırması: Hangisi Ne Zaman Tercih Edilmeli? Endüstriyel bir cihaz, otomasyon kartı, araç elektroniği vey...