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. 😊

Ö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

• Modbus Organization – Resmî Modbus spesifikasyonları ve uygulama kılavuzları
• Texas Instruments – RS-485’e giriş ve izole RS-485 uygulamaları
• Bosch – CAN protokolü ve CAN Specification 2.0 kaynakları
• CAN in Automation – CAN FD temel çalışma prensibi
• Microchip – CAN arbitrajı, bit timing ve mesaj filtreleme mekanizmaları

CAN Bus Fiziksel Katmanı Nedir?

Otomotiv endüstrisinden endüstriyel otomasyona kadar pek çok alanda yaygın olarak kullanılan CAN Bus (Controller Area Network), güvenilirliği ve dayanıklılığıyla ön plana çıkar. Ancak bu protokolün arkasındaki en temel yapı taşı fiziksel katmanıdır. Bu yazıda, CAN Bus'ın fiziksel katmanını detaylı şekilde ele alacağız. 😊

📚 Fiziksel Katman Neyi İfade Eder?

OSI modelinde "Fiziksel Katman" (Physical Layer), verilerin elektriksel ve fiziksel taşıma biçimidir. CAN Bus özelinde bu, veri hattının nasıl sinyal taşıdığı, hangi kabloların kullanıldığı, napaj (power supply) düzenlemeleri ve elektriksel gürültüye karşı önlemleri içerir.

📏 CAN Bus Fiziksel Katman Bileşenleri

İyi bir CAN haberleşmesi için, aşağıdaki temel bileşenlerin doğru şekilde yapılandırılması gerekir:

• Diferansiyel Hatlar (CAN_H ve CAN_L): İletim sırasında voltaj farkı üzerinden veri taşır. Bu sayede elektromanyetik parazitlere karşı dirençlidir.
• Transceiver (Alıcı-Verici): Mikrodenetleyici ile CAN hattı arasında köprü görevi görür.
• 120 Ohm Sonlandırıcı Dirençler: Veri hattının her iki ucuna bağlanır. Yansıma (refleksiyon) engellenir.
• Bükümlü Çift Kablo (Twisted Pair): Gürültüye karşı koruma sağlar.
• Topraklama (Ground): Gerilim farklarını dengelemek için ortak referans noktasıdır.

🧪 Voltaj Seviyeleri ve Sinyal Yapısı

CAN haberleşmesinde kullanılan iki temel voltaj seviyesi şunlardır:

Durum	CAN_H	CAN_L	Diferansiyel Voltaj (Vdiff)
Recessive (Boşta)	~2.5V	~2.5V	0V
Dominant (Aktif)	~3.5V	~1.5V	~2V

Bu diferansiyel sinyal yapısı sayesinde, CAN Bus oldukça sağlam bir iletişim sunar.

🛡️ Elektromanyetik Uyumluluk ve Koruma

CAN Bus kabloları, dış ortamda oluşabilecek elektromanyetik gürültüye karşı bükümlü çift (twisted pair) olarak döşenir. Gerekirse bu kablolar shielding (ekranlama) ile daha da korunabilir.

🔌 Kablolama Kuralları

Aşağıdaki kurallar CAN hattının sağlıklı çalışması için oldukça kritiktir:

• Kablolama lineer (doğrusal) olmalıdır, dallanmalardan kaçınılmalıdır.
• Hattın iki ucunda 120Ω sonlandırma mutlaka olmalıdır.
• Toplam kablo uzunluğu 500m’yi geçmemelidir (10kbps için).
• Bağlantı noktaları 1m’den uzun olmamalıdır.

⚙️ Hız ve Kablo Uzunluğu İlişkisi

Veri Hızı (kbps)	Maksimum Kablo Uzunluğu
1000 kbps	40 m
500 kbps	100 m
250 kbps	250 m
125 kbps	500 m
50 kbps	1000 m

🔧 CAN Transceiver Seçimi

CAN transceiver’lar, mikrodenetleyiciler ile CAN hattı arasında fiziksel bağ kurar. Aşağıdaki özelliklere dikkat etmek gerekir:

• ISO 11898-2 uyumluluğu
• EMI performansı
• Çalışma sıcaklık aralığı
• Standby ve düşük güç modları

Popüler transceiver örnekleri: TJA1050, SN65HVD230, MCP2551.

❓ CAN Bus Fiziksel Katmanı Sık Sorulan Sorular

• CAN_H ve CAN_L ters bağlanırsa ne olur? Genellikle sistem çalışmaz, ama transceiver zarar görmez.
• Tek direnç yeterli mi? Hayır, her iki uçta 120 ohm olmalı. Aksi halde yansıma oluşur.
• Toprak bağlantısı olmazsa ne olur? Gerilim farkları iletişimi bozabilir. Ortak ground önerilir.

🔖 Terimler Sözlüğü

Terim	Açıklama
CAN_H	Yüksek seviyeli CAN hattı
CAN_L	Düşük seviyeli CAN hattı
Transceiver	Veri alışverişini gerçekleştiren alıcı-verici devre
Diferansiyel Sinyal	İki hat arasındaki voltaj farkına dayalı iletişim
Sonlandırma Direnci	Veri hattı ucuna takılan 120Ω direnç

📌 Ekstra Kaynaklar

• NI – CAN Bus Explained
• Texas Instruments – What is CAN?
• CSS Electronics – Physical Layer Basics

OBD-II ve DTC Kodları Nedir? Arabaların Konuşma Dili!

🚗 OBD-II ve DTC Kodları Nedir? Arabaların Konuşma Dili!

Arabamızda bir şeylerin ters gittiğini gösteren motor arıza ışığı yandığında çoğumuzun kafasında soru işaretleri oluşur. Ne bozuldu? Pahalı bir şey mi? Acaba kullanmaya devam edebilir miyim? İşte bu sorulara cevap veren sistemin adı OBD-II (On-Board Diagnostics - Gömülü Teşhis Sistemi). Ve bu sistemin dili de DTC kodlarıdır. 😊

🔧 OBD-II Nedir?

OBD-II, 1996 yılından itibaren Amerika’da satılan tüm araçlarda zorunlu hale gelen, aracın elektronik sistemlerini denetleyen ve arızaları kayıt altına alan bir teşhis protokolüdür. Avrupa’da ise buna benzer sistemler EOBD olarak adlandırılır.

• Motor, şanzıman, egzoz ve yakıt sistemini denetler
• Arızaları tanımlar ve saklar
• Servis teknisyenlerinin doğru teşhis koymasını sağlar
• Sürücüyü uyararak güvenliği artırır

📟 OBD-II Nasıl Çalışır?

OBD-II sistemi, araç üzerindeki çeşitli sensörlerden veri toplar. Bu veriler kontrol üniteleri (ECU) tarafından analiz edilir. Eğer bir değer olması gereken aralığın dışına çıkarsa, sistem bunu bir DTC (Diagnostic Trouble Code) olarak kaydeder ve genellikle gösterge panelinde “Check Engine” ışığını yakar.

🔢 DTC Kodları Ne Anlatır?

DTC kodları, arızanın tipini ve yerini belirlemek için kullanılır. Her kod 5 karakterden oluşur:

Örnek Kod: P0301

P = Powertrain (Güç Aktarma Organları)
0 = SAE standardı (Üreticiye özgü değil)
3 = Ateşleme Sistemi
01 = 1 numaralı silindirde ateşleme hatası

Yani P0301 kodu, "1 numaralı silindirde ateşleme problemi var" anlamına gelir. Kodun ilk harfi sistem tipini gösterir:

• P – Powertrain (motor ve şanzıman)
• B – Body (karoser, klima vs.)
• C – Chassis (şasi, direksiyon, fren vs.)
• U – Network (CAN-Bus, iletişim sorunları)

🧰 En Sık Görülen DTC Kodları

Kod	Açıklama
P0300	Rastgele/çoklu silindirlerde ateşleme hatası
P0420	Katalitik konvertör verimliliği düşük
P0171	Sistem çok fakir çalışıyor (bank 1)
P0455	Yakıt buhar sisteminde büyük kaçak

🔌 OBD-II Tarayıcılar Nasıl Kullanılır?

Aracınızın direksiyon altı bölgesinde bir 16 pin'lik OBD-II portu bulunur. Buraya bağlanabilen ucuz (genellikle ELM327 tabanlı) veya profesyonel cihazlarla DTC kodlarını okuyabilirsiniz.

• Mobil uygulamalar (Torque, OBDeleven, Car Scanner)
• Bluetooth/Wi-Fi adaptörleri
• Servis cihazları (Launch, Autel, Bosch vs.)

📱 Akıllı Telefonla Teşhis: Uygulamalar

Bluetooth destekli OBD-II cihazınızı telefonla eşleştirdikten sonra, birçok uygulama sayesinde hem DTC kodlarını okuyabilir hem de bazı sensörleri anlık takip edebilirsiniz:

• Torque Pro (Android)
• OBD Fusion (iOS)
• Car Scanner

🧠 DTC Kodunu Okuduk. Sonra Ne Olacak?

Kodun anlamını öğrendikten sonra bu kodu internetten veya araç üreticisinin servis dökümanlarından araştırabilirsiniz. Ama dikkat: bazı arızalar kendiliğinden silinmez! Kodun silinmesi için önce sorunun çözülmesi gerekir. Aksi halde motor ışığı tekrar yanacaktır.

❗ Yaygın Hatalar ve Yanılgılar

• “Kod silinirse sorun çözülür” → Yanlış! Kod, sadece semptomdur. Kök neden çözülmeli.
• “Tüm DTC kodları motorla ilgilidir” → Hayır! Şasi, ağ, gövde sistemleriyle ilgili olanlar da vardır.
• “OBD-II her şeyi gösterir” → Kısmen doğru. Bazı üreticiye özel arızalar sadece orijinal cihazlarla görülebilir.

🔍 OBD-II'nin Geleceği

Günümüzde OBD-II sistemleri, sadece arıza teşhisiyle sınırlı kalmıyor. Artık uzaktan teşhis (remote diagnostics), kablosuz OTA güncellemeleri ve gerçek zamanlı araç izleme gibi fonksiyonlara entegre ediliyor. Özellikle elektrikli ve otonom araçlarla birlikte bu sistemlerin daha da gelişmesi kaçınılmaz.

🎯 Sonuç

OBD-II sistemleri ve DTC kodları, günümüz araçlarının vazgeçilmez teşhis araçlarıdır. Aracınızı daha iyi anlamak, sürüş güvenliğinizi artırmak ve gereksiz masrafların önüne geçmek için bu sistemi tanımak büyük avantaj sağlar.

🔖 Terimler Sözlüğü

Terim	Anlamı
OBD-II	Gömülü Teşhis Sistemi
DTC	Arıza Teşhis Kodu
ECU	Elektronik Kontrol Ünitesi
ELM327	OBD-II okuyucu yongası
Check Engine	Motor arıza uyarı ışığı

📌 Ekstra Kaynaklar

• OBD-II Arıza Kodları Veritabanı
• Wikipedia - On-board Diagnostics
• ScanTool.net DTC Açıklamaları

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 😊

🧭 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

Özellik	Açı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 Katman	Diferansiyel sinyal (RS-422 tabanlı)
Veri Formatı	Her veri 32 bittir
Bağlantı Tipi	Point-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 |

Alan	Bit No	Açıklama
Label	1-8	Hangi verinin gönderildiğini belirten etiket (ör: hız, irtifa)
SDI	9-10	Kanal seçici (opsiyonel)
Data	11-29	Asıl veri kısmı (ör: 300 knots)
SSM	30-31	Verinin durumu (normal, hata, geçersiz vb.)
Parity	32	Veri 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

Özellik	ARINC 429	CAN Bus	RS-485
Veri Yönü	Tek yönlü	Çift yönlü	Çift yönlü
Kullanım Alanı	Havacılık	Otomotiv, endüstri	Endüstri
Veri Formatı	32-bit sabit	Değişken	Esnek
Hata Tespiti	Parity biti	CRC + ACK	Genelde yok
Kararlılık	Çok yüksek	Orta	Düşü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üğü

Terim	Anlamı
Label	Veriyi tanımlayan numara
SSM	Verinin geçerlilik durumu
Parity	Hata kontrol biti
Transmitter	Veri gönderen cihaz
Receiver	Veriyi alan cihaz

📌 Ekstra Kaynaklar

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

ISO/SAE 21434:2021 Standardı: Otomotiv Siber Güvenliği İçin Yeni Çağı Başlatıyor

Modern araçlar, giderek daha fazla elektronik ve yazılım bileşenlerine bağımlı hale geliyor. Bu durum, araçların performansını ve kullanıcı deneyimini artırsa da aynı zamanda siber güvenlik risklerini de beraberinde getiriyor. Özellikle otonom sürüş, bağlantılı araçlar (connected vehicles) ve elektrikli araçlar gibi yenilikçi teknolojiler, siber tehditlere açık hedefler haline gelmiştir. İşte tam bu noktada ISO/SAE 21434:2021 standardı devreye giriyor. Bu yazıda, ISO/SAE 21434:2021'i inceleyerek otomotiv sektöründeki siber güvenlik süreçlerini nasıl dönüştürdüğünü açıklayacağız.

---

ISO/SAE 21434:2021 Nedir?

ISO/SAE 21434:2021, otomotivdeki siber güvenlik yönetimi için geliştirilmiş bir standarttır. Bu standardın amacı, araç sistemlerinin tasarımından üretimine, hatta son kullanımına kadar tüm yaşam döngüsünde siber güvenlik risklerini minimize etmektir. ISO/SAE 21434, özellikle bağlantılı araçların ve elektronik kontrol ünitelerinin (ECU) siber saldırılarına karşı korunmasını sağlar.

Bu standart, yalnızca teknik önlemleri değil, aynı zamanda organizasyonel süreçleri, personel eğitimi ve risk yönetimini de kapsar. Böylece, araç üreticileri ve tedarikçileri için kapsamlı bir siber güvenlik çerçevesi sunar.

---

ISO/SAE 21434:2021'in Temel Bileşenleri

ISO/SAE 21434:2021, araç sistemlerindeki siber güvenlik süreçlerini aşağıdaki ana başlıklar altında ele alır:

1. Risk Yönetimi

Araç sistemlerindeki potansiyel siber tehditleri tanımlamak ve bu tehditlerin sonuçlarını analiz etmek, ISO/SAE 21434'ün temel adımlarından biridir. Risk yönetimi sürecinde:

• Hangi sistemlerin siber saldırılara açık olduğu belirlenir.
• Tehditlerin olası etkileri değerlendirilir.
• Risk azaltma stratejileri oluşturulur.

Bu süreç, özellikle otonom sürüş sistemleri ve batarya yönetim sistemleri (BMS) gibi kritik bileşenler için hayati öneme sahiptir.

2. Yaşam Döngüsü Yaklaşımı

ISO/SAE 21434, araç sistemlerinin tüm yaşam döngüsünü kapsayan bir yaklaşım benimser. Bu süreç şu aşamaları içerir:

• Tasarım ve Geliştirme: Sistemlerin siber güvenlik gereksinimlerine uygun olarak tasarlanması.
• Üretim ve Dağıtım: Üretim sırasında siber güvenlik protokollerinin uygulanması.
• Kullanım ve Bakım: Araçların kullanım sürecinde düzenli olarak güncellenmesi ve izlenmesi.
• Son Kullanım: Araçların kullanım ömrünün sonunda verilerin güvenli bir şekilde silinmesi.

3. Siber Güvenlik Yönetim Sistemi (CSMS)

ISO/SAE 21434, araç üreticilerinin bir Siber Güvenlik Yönetim Sistemi (Cybersecurity Management System - CSMS) kurmasını zorunlu kılar. CSMS, siber güvenlik süreçlerini organize eden ve sürekli iyileştirilen bir çerçevedir. Bu sistem sayesinde:

• Siber güvenlik politikaları belirlenir.
• Riskler sürekli izlenir ve müdahale edilir.
• Yazılım güncellemeleri ve yamaları düzenli olarak dağıtılır.

4. Veri İzleme ve İletişim Protokolleri

Modern araçlar, sürekli olarak veri toplar ve bu verileri işler. ISO/SAE 21434, bu süreçlerin güvenliğini sağlamak için:

• Veri bütünlüğünü koruyan mekanizmalar önerir.
• İletişim protokollerinin (örneğin CAN, Ethernet) güvenliğini artırır.
• Siber saldırıları gerçek zamanlı olarak tespit eden sistemler geliştirir.

---

ISO/SAE 21434:2021'in Endüstriye Katkıları

ISO/SAE 21434:2021, otomotiv sektörüne birçok açıdan katkı sağlar:

1. Daha Güvenli Araçlar:
   Standardın önerdiği süreçler, araçların siber saldırılara karşı direncini artırır. Bu da hem kullanıcı güvenliğini hem de marka itibarını korur.
2. Global Uyumluluk:
   ISO/SAE 21434, uluslararası bir standart olduğu için, araç üreticilerinin global pazarlarda rekabet avantajı elde etmesini sağlar.
3. Yasal Uyumluluk:
   Özellikle Avrupa Birliği gibi bölgelerde, araçların siber güvenlik standartlarına uygun olması zorunludur. ISO/SAE 21434, bu tür yasal gerekliliklere uyum sağlama konusunda rehberlik eder.
4. Sürekli İyileştirme:
   Standardın yaşam döngüsü yaklaşımı, araç sistemlerinin sürekli olarak güncellenmesini ve iyileştirilmesini teşvik eder.

---

Gelecekteki Gelişmeler

ISO/SAE 21434:2021, otomotivdeki siber güvenlik süreçlerini dönüştürmeye başlamış olsa da, bu alanda sürekli yenilikler bekleniyor. Özellikle şu alanlarda gelişmeler yaşanabilir:

• Yapay Zeka ve Makine Öğrenimi: Siber saldırıları tahmin etmek ve engellemek için daha akıllı algoritmalar.
• Kuantum Bilgi İşlem: Siber güvenlik süreçlerini daha güçlü hale getirmek.
• Kablosuz Güncelleme (OTA): Yazılım güncellemelerinin güvenliğini artırmak.

---

Sonuç

ISO/SAE 21434:2021, otomotivdeki siber güvenlik süreçlerini standardize eden ve bu alanda yeni bir çağ başlatan bir standarttır. Araç üreticileri ve tedarikçileri için kapsamlı bir çerçeve sunarken, aynı zamanda kullanıcıların güvenliğini de en üst düzeyde tutar.

Üniversite öğrencileri ve yeni mezunlar için, otomotiv sektöründe kariyer yapmayı düşünenler, ISO/SAE 21434:2021 gibi standartları anlamak, bu alanda fark yaratmanın ilk adımı olacaktır. Siber güvenlik, modern ulaşımın kalbinde atarken, ISO/SAE 21434:2021 ise bu kalbin düzenli ve güvenli bir şekilde atmasını sağlayan kilit bir unsurdur.

Bu standart, yalnızca bir teknik doküman değil, aynı zamanda otomotivdeki güvenlik ve yenilikçiliğin sembolüdür.

 

ISO/TR 9839:2023 Teknik Raporu: Functional Safety (ISO 26262) Perspektifinden İnceleme

ISO/TR 9839:2023 Teknik Raporu: Functional Safety (ISO 26262) Perspektifinden İnceleme

Otomotiv endüstrisi, elektrikli ve otonom araç teknolojilerinin hızla gelişmesiyle birlikte, araç güvenliği konusuna daha fazla odaklanmaktadır. Bu bağlamda, işlevsel güvenlik (Functional Safety) standartları, özellikle ISO 26262, elektrikli ve elektronik sistemlerin güvenliğini sağlamak için kritik bir rol oynamaktadır. Yeni yayınlanan ISO/TR 9839:2023 teknik raporu, bu standartların uygulanmasında öngörücü bakımın (predictive maintenance) entegrasyonunu ele alarak, araç güvenliği ve performansını artırmayı hedeflemektedir.

ISO 26262 ve İşlevsel Güvenlik

ISO 26262, otomotiv sektöründe elektrikli ve elektronik sistemlerin işlevsel güvenliğini sağlamak için oluşturulmuş uluslararası bir standarttır. Bu standart, araçlardaki güvenlikle ilgili sistemlerin tüm yaşam döngüsünü kapsayarak, potansiyel arızaların önlenmesi ve yönetilmesine yönelik süreçleri tanımlar. ISO 26262, risk tabanlı bir yaklaşım benimseyerek, tehlikeli operasyonel durumların riskini niteliksel olarak değerlendirir ve sistematik hataların önlenmesi ile rastgele donanım hatalarının tespiti veya kontrolü için güvenlik önlemleri tanımlar.

ISO/TR 9839:2023'ün Amacı ve Kapsamı

ISO/TR 9839:2023, ISO 26262-5 standardı ile birlikte donanım bileşenlerine öngörücü bakım uygulamalarını ele alan bir teknik rapordur. Öngörücü bakım, araçlardaki donanım bileşenlerinin durumunu sürekli izleyerek, potansiyel arızaları meydana gelmeden önce tespit etmeyi ve böylece beklenmedik arızaları önlemeyi amaçlar. Bu yaklaşım, araç güvenilirliğini artırırken, bakım maliyetlerini ve araçların beklenmedik duruş sürelerini azaltır.

Öngörücü Bakımın İşlevsel Güvenlik ile Entegrasyonu

Öngörücü bakımın işlevsel güvenlik süreçlerine entegrasyonu, araç güvenliği ve performansını artırmada önemli bir adımdır. ISO/TR 9839:2023, bu entegrasyonun nasıl gerçekleştirileceğine dair rehberlik sağlar. Özellikle, öngörücü bakım verilerinin kullanılmasıyla, potansiyel donanım arızalarının erken tespiti ve yönetimi mümkün hale gelir. Bu da, ISO 26262'nin gerektirdiği güvenlik hedeflerine ulaşılmasını kolaylaştırır.

Pratik Uygulamalar ve Faydaları

ISO/TR 9839:2023'ün uygulanması, otomotiv endüstrisinde çeşitli pratik faydalar sunar:

• Arıza Önleme: Öngörücü bakım, potansiyel arızaları önceden tespit ederek, beklenmedik sistem arızalarının önüne geçer.

• Maliyet Tasarrufu: Planlı bakım ve onarımlar sayesinde, acil durum müdahalelerinin maliyeti azaltılır.

• Güvenlik Artışı: Kritik bileşenlerin sürekli izlenmesi, araç güvenliğini artırır ve yolcu güvenliğini sağlar.

Sonuç

ISO/TR 9839:2023 teknik raporu, öngörücü bakım uygulamalarının ISO 26262 çerçevesinde nasıl entegre edileceğine dair önemli bir rehber sunmaktadır. Bu entegrasyon, otomotiv sektöründe araç güvenliği ve performansının artırılmasına katkı sağlar. Öngörücü bakımın işlevsel güvenlik süreçlerine dahil edilmesi, hem üreticiler hem de kullanıcılar için önemli avantajlar sunar.

Elektrikli Araçlarda BMS'lerin ISO/TR 9968:2023 Perspektifinden İncelenmesi

Elektrikli araçlar (EV), sürdürülebilir ulaşımın geleceğini şekillendiren en önemli teknolojilerden biridir. Ancak bu araçların başarısı, yalnızca güçlü motorlar veya aerodinamik tasarımlara bağlı değildir. Bataryalar, elektrikli araçların kalbinde yer alan kritik bileşenlerdir ve bu bataryaların yönetimi için tasarlanan Batarya Yönetim Sistemleri (BMS) , araç performansı, güvenliği ve ömrü açısından hayati öneme sahiptir. BMS'lerin tasarım, geliştirme ve uygulama süreçlerinde uluslararası standartlar, özellikle de yeni yayınlanan ISO/TR 9968:2023 , rehberlik edici bir rol oynamaktadır.

Bu yazıda, ISO/TR 9968:2023 standardının BMS'ler üzerindeki etkisini ve bu perspektiften nasıl değerlendirildiğini inceleyeceğiz.

---

ISO/TR 9968:2023 Nedir?

ISO/TR 9968:2023, elektrikli araçların şarj sistemleri ve ilgili bileşenleri için bir teknik rapor olarak hazırlanmış bir standarttır. Bu standart, özellikle elektrikli araçların şarj altyapısıyla olan etkileşimlerini ve bu süreçteki güvenlik, uyumluluk ve performans gereksinimlerini ele alır. BMS'ler, bataryaların şarj ve deşarj süreçlerini yönettiği için, ISO/TR 9968:2023 kapsamında da önemli bir yer tutar.

ISO/TR 9968:2023, sadece şarj sistemlerine odaklanmaz; aynı zamanda bataryaların güvenli bir şekilde çalışmasını sağlamak için gerekli olan iletişim protokolleri, veri paylaşımı ve hata yönetimi gibi konuları da kapsar. Bu nedenle, BMS'lerin ISO/TR 9968:2023 ile uyumlu olması, elektrikli araçların genel güvenliğini ve performansını artırmada kritik bir faktördür.

---

BMS'lerin ISO/TR 9968:2023 Çerçevesinde Rolü

ISO/TR 9968:2023, BMS'lerin aşağıdaki ana alanlarda nasıl işlev gördüğüne dikkat çeker:

1. Şarj Yönetimi ve Uyumluluk

Elektrikli araçlar, farklı şarj istasyonlarıyla uyumlu olmalıdır. Ancak her şarj istasyonunun güç çıkışları, gerilim seviyeleri ve iletişim protokolleri farklılık gösterebilir. ISO/TR 9968:2023, BMS'lerin bu farklılıkları algılayıp uygun şekilde yanıt vermesini gerektirir. Örneğin:

• BMS, şarj istasyonundan gelen verileri analiz eder ve bataryanın maksimum kapasitesini aşmadan şarj işlemini optimize eder.
• Şarj sırasında oluşan sıcaklık artışlarını izler ve gerektiğinde şarj hızını düşürür.

Bu süreçler, ISO/TR 9968:2023'e uygun olarak gerçekleştirildiğinde, hem araç hem de şarj istasyonu için daha güvenli bir deneyim sağlar.

2. İletişim Protokolleri ve Veri Paylaşımı

Modern elektrikli araçlar, şarj istasyonlarıyla iletişim kurmak için çeşitli protokoller kullanır (örneğin, ISO 15118 veya CHAdeMO). BMS, bu iletişim protokollerini yöneten merkezi bir bileşendir. ISO/TR 9968:2023, BMS'lerin şarj istasyonlarıyla etkili bir şekilde iletişim kurmasını ve şu bilgileri paylaşmasını gerektirir:

• Bataryanın mevcut şarj durumu (State of Charge - SoC).
• Maksimum şarj hızı ve gerilim sınırları.
• Hata kodları veya uyarılar.

Bu veri paylaşımı, şarj sürecinin verimli ve güvenli bir şekilde gerçekleşmesini sağlar.

3. Güvenlik ve Hata Yönetimi

ISO/TR 9968:2023, BMS'lerin güvenlik odaklı bir yaklaşım benimsemesini zorunlu kılar. Özellikle şarj sırasında ortaya çıkabilecek hatalar, ciddi güvenlik risklerine yol açabilir. Örneğin:

• Aşırı akım veya gerilim, bataryanın hasar görmesine neden olabilir.
• Şarj kablosundaki bir kopma veya kısa devre, yangın riski oluşturabilir.

BMS, bu tür hataları algılayıp anında müdahale edebilmeli ve gerekirse şarj işlemini durdurmalıdır. ISO/TR 9968:2023, bu tür senaryolar için detaylı güvenlik protokolleri tanımlar.

4. Sıcaklık ve Enerji Yönetimi

Şarj sırasında bataryaların sıcaklığı artabilir ve bu durum, bataryanın ömrünü kısaltabilir veya güvenlik riskleri yaratabilir. ISO/TR 9968:2023, BMS'lerin sıcaklık yönetimini optimize etmesini ve şarj hızını buna göre ayarlamasını önerir. Ayrıca, enerji verimliliği açısından da BMS'lerin şarj sırasında kayıpları minimize etmesi beklenir.

---

ISO/TR 9968:2023'e Uyum Sağlamanın Avantajları

ISO/TR 9968:2023'e uyumlu bir BMS tasarlamak, birçok avantaj sağlar:

1. Daha Güvenli Şarj Süreçleri:
   Standarda uygun BMS'ler, şarj sırasında ortaya çıkabilecek riskleri minimize eder ve kullanıcılar için daha güvenli bir deneyim sunar.
2. Geniş Uyumluluk:
   Farklı şarj istasyonlarıyla uyumlu çalışan BMS'ler, kullanıcıların şarj altyapısından bağımsız olarak sorunsuz bir şekilde şarj yapmasını sağlar.
3. Verimli Enerji Kullanımı:
   ISO/TR 9968:2023, BMS'lerin enerji tüketimini optimize etmesini teşvik eder. Bu da bataryanın ömrünü uzatır ve çevresel etkileri azaltır.
4. Global Pazarlara Erişim:
   ISO/TR 9968:2023 gibi uluslararası standartlara uyumlu ürünler, global pazarlarda daha kolay kabul görür ve rekabet avantajı sağlar.

---

Gelecekteki Gelişmeler

ISO/TR 9968:2023, elektrikli araçların şarj sistemleri ve BMS'ler için bir başlangıç noktası olarak görülmelidir. Gelecekte, bu standart daha da genişletilebilir ve yeni teknolojilerle entegre edilebilir. Örneğin:

• Yapay Zeka ve Makine Öğrenimi: BMS'ler, şarj süreçlerini daha iyi tahmin edebilmek ve optimize edebilmek için yapay zeka algoritmaları kullanabilir.
• Kablosuz Şarj Teknolojileri: Kablosuz şarj sistemlerinin yaygınlaşmasıyla birlikte, BMS'lerin bu teknolojilere uyum sağlaması gerekecektir.
• Gerçek Zamanlı İzleme ve Raporlama: ISO/TR 9968:2023, BMS'lerin gerçek zamanlı veri paylaşımını teşvik eder. Bu, sürücülerin ve operatörlerin bataryanın durumunu sürekli takip etmesini sağlar.

---

Sonuç

Elektrikli araçlar, modern ulaşımın geleceği için umut vaat ediyor. Ancak bu araçların güvenli, verimli ve uyumlu bir şekilde çalışması, yalnızca güçlü bataryalara değil, aynı zamanda bu bataryaları yöneten BMS'lere de bağlıdır. ISO/TR 9968:2023, BMS'lerin tasarım, geliştirme ve uygulama süreçlerinde rehberlik edici bir rol oynar. Bu standart, elektrikli araçların şarj süreçlerini optimize ederken, güvenlik, uyumluluk ve performans açısından da yüksek standartlar belirler.

Üniversite öğrencileri ve yeni mezunlar için, otomotiv sektöründe kariyer yapmayı düşünenler, ISO/TR 9968:2023 gibi standartları anlamak, bu alanda fark yaratmanın ilk adımı olacaktır. BMS'ler, elektrikli araçların kalbinde atarken, ISO/TR 9968:2023 ise bu kalbin düzenli ve güvenli bir şekilde atmasını sağlayan kilit bir unsurdur.