CAN Bus:
Temel ilkeler
ve uygulama
Otomotiv haberleşmesinin temelleri ve etkileşimli test örnekleri.
KeşfetOtomotiv ağlarında test ve validasyon nasıl yapılır?
Anıl Mirap · 29 Ekim 2026CAN Bus, araçtaki elektronik kontrol birimlerinin ortak bir iletişim hattı üzerinden veri alışverişi yapmasını sağlayan bir haberleşme sistemidir. Bu yazı; ağın temel yapısını, mesajların yorumlanmasını ve iletişim hatalarının sistem davranışına etkisini bir hız sinyali örneği üzerinden açıklamaktadır. Etkileşimli uygulamalar kavramları somutlaştırırken, bölüm sonlarındaki teknik notlar test ve validasyon yöntemlerini ayrıntılandırmaktadır.
Temel kavramlardan test yöntemlerine uzanan dört bölüm ve tamamlayıcı teknik notlar.Araç içi
haberleşme yapısı.
Bir araçta motor, fren ve gösterge gibi sistemlerin kendi elektronik kontrol birimleri bulunur. Elektronik kontrol birimi (ECU) olarak adlandırılan bu gömülü sistemler, işlevlerini yerine getirmek için gerekli verileri ağ üzerinden paylaşır.
Hız bilgisi göstergeye nasıl ulaşır?
CAN, Controller Area Network (kontrol birimleri ağı) adının kısaltmasıdır. Ortak bir iletişim hattı kullanır: ağa bağlı bir birim hız bilgisini mesaj olarak yayınlar; gösterge gibi bu bilgiye ihtiyaç duyan birimler mesajı alıp kullanır. Böylece her bilgi için ayrı bir uçtan uca bağlantı kurma ihtiyacı azalır.
Aşağıdaki şema, iki kontrol birimini ve aralarındaki CAN_H / CAN_L iletkenlerini göstermektedir. Mesaj gönderimi canlandırılarak veri aktarımı gözlenebilir. Taşıma, yorumlama ve fonksiyon sekmeleri, iletişim sürecinin üç aşamasını ayrı ayrı açıklamaktadır.
Taşıma: Mesaj ortak hat üzerinden yayınlanır. ACK adlı alım onayı, en az bir birimin mesajı doğru aldığını gösterir.
Teknik derinlik: gerekçeler ve uygulama notları
Mesajı görmek ile fonksiyonu doğrulamak arasındaki fark
Bir analiz ekranında sürekli akan çerçeveler görmek rahatlatıcıdır. Fakat bu görüntü, alıcı uygulamanın doğru veriyi kullandığını göstermez. CAN seviyesindeki ACK, en az bir düğümün çerçeveyi doğru aldığını ifade eder; hedef uygulamanın veriyi kabul ettiğini veya beklenen eylemi yaptığını kanıtlamaz. [1]
Örneğin araç hızının bir göstergeye iletildiğini düşünelim. Çerçeve hatta bulunabilir; buna rağmen yanlış ölçek, eski bir sinyal tanımı, donmuş veri veya gecikmiş uygulama görevi yüzünden gösterge yanlış davranabilir. Bu nedenle incelemeyi üç ayrı soruyla yürütürüm: Veri taşındı mı? Doğru yorumlandı mı? Fonksiyon, doğru zamanda doğru tepkiyi verdi mi?
Yazıdaki hız sinyali ve test vakası, yöntemi somutlaştırmak için hazırlanmış kurgusal bir örnektir. Sayısal kabul kriterleri bir üretici şartnamesinden alınmamıştır; gerçek projede onaylı gereksinimler belirleyicidir.
Test için ölçülebilir bir gereksinim oluşturmak
‘Hız mesajı çalışmalı’ test edilebilir bir gereksinim değildir. Kaynak ECU, alıcı, ağ segmenti, mesaj ve sinyal tanımı, geçerli aralık, güncellenme biçimi, gecikme sınırı ve hata tepkisi belirtilmelidir. DBC sürümü ile donanım, yazılım ve kalibrasyon sürümleri de başlangıç kaydına girer. Aksi hâlde aynı isimle farklı sistemler test edilmiş olabilir.
Kurgusal örneğimizde 0x180 kimlikli, 8 baytlık bir Classical CAN mesajı her 20 ms’de bir araç hızı taşır. İlk iki baytta unsigned little-endian hız alanı, 0,01 km/h ölçeği ve sıfır ofset vardır. Başka bir alanda veri geçerlilik bilgisi bulunur. Bu tanımlar gerçek bir aracın mesaj haritası değildir.
Örnek kabul şartımız şöyle olsun: Alıcı son geçerli mesajdan itibaren 100 ms boyunca yeni geçerli veri alamazsa, bunu izleyen en fazla 10 ms içinde hızı ‘kullanılamıyor’ olarak işaretlemeli. Kurtarma için art arda üç geçerli mesaj beklemeli. Burada 100 ms’nin hangi olaydan ölçüldüğü, eşik anındaki eşitliğin nasıl ele alındığı ve 10 ms’lik tepkinin gözlem noktası açıkça tanımlanmalıdır.
Mesaj yapısı ve
verinin yorumlanması.
Mesaj, kimlik ve veri alanı gibi parçalardan oluşur. Kimlik, alıcının hangi mesajı okuduğunu ayırt etmesini sağlar. Veri alanındaki baytlar ise sayıları taşır. Bir bayt 8 bittir; bit, 0 veya 1 değerini alan en küçük bilgi birimidir. Classical CAN bir mesajda en fazla 8 veri baytı taşır.
Deney: CAN mesajını çöz
İki baytın değeri ve bayt sırası değiştirilerek ham verinin fiziksel değere dönüşümü incelenebilir.
(B₀ + B₁ × 256) × 0.01
Unsigned · 16 bit · ofset 0DBC dosyası, mesaj içindeki sinyallerin tanımlarını içerir. Hız bilgisinin hangi baytlarda bulunduğunu ve ham sayısal değerin km/h birimine nasıl dönüştürüleceğini belirtir. Deneyde 10 ve 27 onaltılık (hex) sayılardır. Doğru sırada 10000 ham değerini verir; 0,01 ile çarpınca 100 km/h elde edilir. Bayt sırası değiştirilerek yorumlama kuralının sonuç üzerindeki etkisi incelenebilir.
Kablonun uçlarında neden direnç var?
Sonlandırma dirençleri, sinyalin kablo uçlarından yansımasını azaltmaya yardımcı olur. Bu modelde iki uçta 120 Ω bulunur; paralel bağlandıklarında toplam 60 Ω ölçülür. Direnç sayısı değiştirilerek paralel eşdeğerin nasıl oluştuğu incelenebilir.
Enerjisi kesilmiş, iki uçta sonlandırılan geleneksel high-speed CAN modeli. 60 Ω, sinyal bütünlüğünü tek başına kanıtlamaz.
Teknik derinlik: gerekçeler ve uygulama notları
Fiziksel katman: Sonlandırma direncini yorumlamak
İlk kontrol; doğru segment, kablolama, besleme, konnektörler ve topolojidir. İki uçta 120 Ω sonlandırma bulunan, enerjisi kesilmiş geleneksel bir high-speed CAN segmentinde CAN_H ile CAN_L arasında yaklaşık 60 Ω beklenir. Bu kuralı low-speed veya farklı sonlandırma mimarilerine doğrudan uygulamak doğru değildir. Direnç ölçümü enerjisiz ve üreticinin servis yöntemine uygun yapılır. [2]
Yaklaşık 120 Ω eksik bir sonlandırmayla, yaklaşık 40 Ω ise ilave paralel sonlandırmayla tutarlı olabilir. Ancak tek ölçümle kesin kök neden ilan edilmez: ölçüm noktası, ayrılan düğümler ve segment yapısı sonucu değiştirebilir. 60 Ω görmek de kablonun yük altında kusursuz sinyal taşıdığını kanıtlamaz.
Sonraki adımda osiloskopla diferansiyel dalga şekli, yansıma, kenar bozulması ve hata anıyla ilişkili değişimler incelenir. Dalga şekli tek bir ‘güzel görünüm’ üzerinden değerlendirilmez; ilgili transceiver, bit hızı ve fiziksel katman şartları esas alınır. Bir konnektörün hareketiyle hata artıyorsa, bunu zaman damgalı trafik ve hata kayıtlarıyla ilişkilendirmek gerekir.
DBC ile baytları fiziksel değerlere çevirmek
DBC; sinyalin bit konumunu, uzunluğunu, byte order bilgisini, işaretli veya işaretsiz oluşunu, ölçeğini ve ofsetini tanımlar. Temel dönüşüm fiziksel değer = ham değer × ölçek + ofset şeklindedir. Dolayısıyla ‘mesaj kimliği doğru’ demek, sinyalin doğru çözüldüğü anlamına gelmez. [3]
Örneğimizde ilk iki bayt 0x10 ve 0x27 olduğunda little-endian ham değer 0x2710, yani 10000 olur. 0,01 ölçeğiyle sonuç 100 km/h’dir. Bayt sırasının yanlış yorumlanmasıyla ham değer 0x1027, yani 4135 ve gösterilen hız 41,35 km/h olur. Trafik tamamen düzenli görünürken uygulama düzeyinde ciddi bir hata oluşabilir.
Bu nedenle sıfır, alt ve üst geçerli sınır, temsil edilebilir komşu değerler ve tanımlı geçersiz kodlar ayrı ayrı denenir. Reserved değerler gerçek hız gibi kullanılmamalıdır. Alıcı filtresi, mesaj uzunluğu ve gerekiyorsa multiplexor seçimi de kontrol edilir. Test verisini çözen araçla ECU aynı yanlış tanımı kullanıyorsa iki tarafın anlaşması bağımsız doğrulama sayılmaz; en az bir bilinen bayt örneği elle kontrol edilmelidir.
İletişim kesintisi ve
sistem tepkisi.
Alıcı son gördüğü değere ne kadar süre güvenmeli? Bu soru, bir haberleşme testini sistem davranışı testine dönüştürür.
Zaman kontrolü kullanılarak mesaj kaybı, geçersiz veri ve üç geçerli mesaj sonrasında kurtarma senaryoları karşılaştırılabilir.
Deney: Zaman aşımını test et
Son geçerli alım t = 0. Zamanı kaydırarak alıcının kararını incele.
Son geçerli veri yaşı: 120 ms.
Mesajlar t = 0’dan sonra kesilir. Alıcı 100 ms’de kullanılamıyor durumuna geçer.
Örnek gönderim periyodu
Son geçerli veriden timeout
Kurtarma için art arda geçerli alım
Veri kesildiğinde göstergeye nasıl bilgi verilir?
Bir haberleşme testi, normal bilgi akışını ve kesinti durumunu kontrollü biçimde inceler. Örneğimizde her 20 ms’de, yani saniyede 50 kez mesaj beklenir. Son geçerli bilgiden sonra 100 ms geçerse alıcı veriyi kullanılamıyor olarak işaretler. Bu bekleme sınırına timeout denir. İletişim geri geldiğinde üç geçerli mesaj beklemek, örnekteki kurtarma kuralıdır; gerçek araçta süreler ve tepkiler gereksinime göre belirlenir.
Teknik derinlik: gerekçeler ve uygulama notları
Zamanlama: Ortalama periyot, en kötü gecikmeyi gizleyebilir
Periyot ardışık gönderimler arasındaki süreyi, jitter bu sürenin değişimini, uçtan uca gecikme ise kaynak olayından alıcının sonucu kullanmasına kadar geçen zamanı anlatır. Bunları aynı metrik gibi raporlamak hatalıdır. Gönderici görevi, kuyruk, arbitration, gateway ve alıcı görevi farklı katkılar yapabilir.
20 ms’lik mesajın uzun dönem ortalaması 20 ms olabilir; yine de kısa bir trafik patlamasında kritik bir mesaj gecikebilir. Testte ortalama yanında maksimum aralık, dağılım, ardışık kaçırılan güncellemeler ve işlevsel tepki ölçülmelidir. Yüzdelik değerler faydalıdır, fakat sert bir deadline gereksiniminde tek bir ihlali ortalama içine gömmek kabul edilemez.
Farklı cihazların zaman damgaları karşılaştırılıyorsa saat senkronizasyonu ve ölçüm belirsizliği belirtilmelidir. Sadece CAN izinden alıcının uygulama tepkisi ölçülemez; uygun gözlem sinyali, ECU ölçümü veya harici çıkış kaydı gerekir. Örnek testte yük yüzdesi kadar mesajların öncelik ve burst yapısı da değiştirilir. Evrensel bir ‘şu yüzde altında ağ güvenlidir’ sınırı kabul edilmez.
Hata enjeksiyonu: Sistemin bozulmasını değil, tepkisini test etmek
Hata enjeksiyonunun amacı rastgele trafik üretmek değil, belirli bir gereksinimi sınamaktır. Hedef mesajı susturmak, araya gecikme koymak, tanımlı geçersiz değer göndermek veya veriyi dondurmak farklı hata sınıflarıdır. Her senaryoda ön koşul, uygulanacak hata, gözlenen tepki ve temizleme adımı bulunmalıdır.
‘Geçersiz veri’ ile ‘veri yok’ aynı senaryo değildir. Alıcıya her 20 ms’de bir geçersiz mesaj gönderilirse, yalnızca paket gelişini izleyen bir timeout yanlışlıkla sürekli sıfırlanabilir. Kabul şartı son mesajdan mı, son geçerli mesajdan mı hesaplama istiyor? Bu fark, test tasarımının merkezindedir.
Payload’a yanlış bir uygulama CRC’si koymakla CAN hattında protokol CRC hatası yaratmak da farklıdır. Normal CAN arayüzü, gönderdiği çerçevenin protokol alanlarını çoğunlukla kendisi üretir. Bit seviyesinde bozma veya elektriksel kısa devre simülasyonu için uygun hata enjeksiyon donanımı gerekir. Bu uygulamalar hareket hâlindeki araçta değil, yetkilendirilmiş ve korumalı test düzeneğinde yapılır.
Error passive, bus-off ve kurtarmanın ayrı doğrulanması
CAN denetleyicileri hata sayaçlarıyla hata yayılımını sınırlar. Error passive ve bus-off aynı durum değildir; bus-off durumundaki düğüm normal iletişime katılmaz. Bir log dosyasında yalnızca mesajın kaybolduğunu görmek, düğümün bus-off olduğunu kanıtlamaz. Denetleyici durumu ve erişilebilen hata sayaçları ayrıca kaydedilmelidir. [4]
Test; hata başlangıcını, iletişimin kesilmesini, uygulamanın veri kaybına tepkisini, hata kaldırıldıktan sonraki yeniden katılımı ve fonksiyonun geri dönüşünü ayrı olaylar olarak izlemelidir. Düğümün hatta yeniden görünmesi, uygulamanın güvenle normale döndüğünü tek başına göstermez.
Kurtarma stratejisi proje gereksinimine bağlıdır. Sürekli reset atan bir ECU geçici olarak iletişime dönüp tekrar düşebilir; kısa test bunu başarı sanabilir. Bu yüzden tekrarlı hata-kurtarma çevrimleri, güç çevrimi sonrası durum, tanı kaydı ve normale dönüşte sıçrama ya da eski veri kullanımı da değerlendirilir.
E2E koruma: Veri tazeliği ve tutarlılığını değerlendirmek
Uygulama düzeyinde kullanılan E2E yaklaşımı; profile bağlı olarak sayaç, Data ID ve CRC gibi mekanizmaları birleştirir. Tekrar, sıra bozukluğu ve veri bozulması gibi durumları ele almak için CAN’ın çerçeve kontrolünün ötesinde değerlendirme gerekir. Timeout davranışı profil ve çağırma mimarisiyle birlikte incelenmelidir. Buradaki AUTOSAR 4.3.1 belgesi kavramsal kaynaktır; proje için geçerli sürümün yerine kullanılmaz. [5]
Sayacın donması ile fiziksel sinyalin sabit kalması farklıdır. Duran bir aracın hızı meşru biçimde sıfır kalabilir; salt değer değişmedi diye sensör arızası denemez. Test; yeni örnek geldi mi, koruma durumu geçerli mi ve uygulama bu durumu nasıl kullanıyor sorularını ayrı tutmalıdır. Ayrıca CRC, gönderenin kimliğini kriptografik olarak doğrulayan bir güvenlik mekanizması değildir.
Örnek vaka: Hız verisi kaybolduğunda gösterge ne yapmalı?
Düzeneği iki düğüm ve bir analiz arayüzüyle kurarız: göndericiyi simüle eden kaynak, test edilen gösterge ECU’su ve gözlem sistemi. Önce 100 km/h değerini 20 ms periyotla göndeririz. Alıcının geçerli duruma geçtiğini ve doğru değeri kullandığını doğrularız. Hata enjeksiyonundan önce bu başlangıç şartı sağlanmazsa test devam etmez.
Son geçerli alım anını t0 olarak işaretleyip sadece 0x180 mesajını durdururuz; diğer trafik devam eder. Örnek şartımıza göre kullanılamıyor durumuna geçiş t0 + 100 ms’den önce olmamalı, t0 + 110 ms’den sonra da kalmamalıdır. Bu pencere evrensel bir otomotiv sınırı değil, yukarıda tanımladığımız varsayımsal gereksinimin sonucudur. Ölçüm çözünürlüğü ve saat hizalama hatası karara dâhil edilir.
Ardından yalnızca bir geçerli mesaj gönderip tekrar sustururuz: art arda üç geçerli mesaj şartı henüz karşılanmadığı için normal gösterime dönmemelidir. Sonra düzenli üç geçerli mesajla kurtarmayı sınarız. Geçersiz bir mesajın bu diziyi kesip kesmeyeceği ayrıca şartnamede tanımlanmalıdır. Aynı test timeout eşiğinin hemen çevresinde, başlangıçta veri hiç gelmediğinde ve farklı trafik koşullarında tekrarlanır.
Test tasarımı
ve doğrulama.
Test etmek, beklediğimiz davranış ile gözlediğimiz sonucu karşılaştırmaktır. Verification, tanımlı gereksinimin karşılandığını; validasyon ise ortaya çıkan davranışın amaçlanan kullanıma uygunluğunu inceler. Bir hız göstergesi örneğinde doğru değer, zamanında güncelleme ve kesintide anlaşılır tepki birlikte değerlendirilir.
- 01
Gereksinim
Hangi davranış, hangi koşulda, hangi sürede bekleniyor?
- 02
Kontrollü test
Aynı sürüm, başlangıç durumu ve girdiyle karşılaştırılabilir koşullar kurulur.
- 03
Gözlem
Trafik ile uygulama tepkisini aynı zaman ekseninde ilişkilendir.
- 04
Sonuç ve kayıt
Beklenen ve gözlenen sonuç, ilgili kayıtlarla birlikte değerlendirilir.
CAN haberleşmesi; mesajın yayınlanması, alıcı tarafından çözümlenmesi ve uygulama tarafından kullanılması aşamalarından oluşur. Test tasarımı, bu aşamalardaki beklenen davranışları gözlenebilir kabul ölçütleriyle ilişkilendirir.
Teknik derinlik: gerekçeler ve uygulama notları
MIL, SIL, HIL ve araç testinin tamamlayıcı rolleri
Model-in-the-loop, davranış mantığını erken sınamak için; software-in-the-loop, yazılım davranışını simüle edilmiş çevrede incelemek için kullanılabilir. Hardware-in-the-loop ise gerçek ECU’yu kontrollü çevre girdileriyle çalıştırarak donanım ve yazılım etkileşimini görünür kılar. Her düzeneğin model doğruluğu, zamanlama ve erişebildiği arıza türleri bakımından sınırları vardır.
Gerçek transceiver ve kablo olmadan yapılan bir test, fiziksel hat yansımasını doğrulayamaz. Gerçek ECU içermeyen bir simülasyon, hedef işlemcideki görev zamanlamasını tam olarak kanıtlayamaz. HIL’de geçmek de aracın bütün kullanım koşullarında doğrulandığı anlamına gelmez. Test planı, her iddia için uygun ortamı ve açıkta kalan riski belirtmelidir.
CANoe gibi platformlar iletişim analizi, simülasyon ve otomatik test imkânı sunar. [7] Ancak araç seçimi, test kapsamının yerine geçmez. Basit bir tezgâh testi için daha küçük bir arayüz ve betik yeterli olabilir; çoklu ECU, tanı ve hassas zamanlama gereksinimi arttığında farklı altyapılar gerekebilir. Ölçüt, aracın adı değil, ihtiyacın tekrar üretilebilir şekilde gözlenebilmesidir.
CAN FD’de test planına ne eklenir?
Classical CAN’da veri alanı en fazla 8 bayttır; CAN FD’de 64 bayta kadar çıkabilir. CAN FD, arbitration ve veri fazı için farklı bit zamanlamalarını destekler. Kullanılan yapılandırmada nominal bit hızı, veri bit hızı ve bit-rate switching birlikte kaydedilmelidir. Yalnızca nominal bit hızını bilmek yeterli değildir. [6]
Test planına 8 bayt ötesindeki sinyaller, uzunluk kodlaması, padding, seçili DLC değerleri ve alıcı tampon davranışı eklenir. En büyük payload ile kısa mesajların birlikte bulunduğu trafik örüntüleri de denenir. Daha yüksek veri hızı bütün fonksiyonların gecikmesinin otomatik olarak azalacağı anlamına gelmez; payload dağılımı ve zamanlama yeniden ölçülür.
Karma ağlarda her denetleyicinin ve aracın ilgili çerçeve türünü desteklediği doğrulanmalıdır. ‘CAN FD uyumlu’ etiketi tek başına tüm fiziksel topolojilerde seçilen hızın çalışacağını garanti etmez. Gateway üzerinden dönüşüm varsa veri uzunluğu, tazelik ve hata durumunun diğer ağ tarafına nasıl taşındığı da kapsam içindedir.
Otomasyonla test koşullarını tekrar üretmek
İyi bir otomatik test başlangıç durumunu kurar, beklenen ön koşulu doğrular, uyarımı uygular, zaman damgalı gözlem toplar, açık bir kuralla karar verir ve düzeneği temizler. Bir önceki testten kalan hata kaydı ya da aktif simülatör, sonraki testin sonucunu etkilememelidir. Rastgele trafik kullanılıyorsa üretim tohumu ve konfigürasyon kaydedilir.
Sabit bir süre bekleyip ekrandaki değeri okumak yerine mümkünse ilgili olayı tetikleyici olarak kullanırım. Test düzeneği mesaj gönderememişse bunu ECU başarısızlığı gibi raporlamak yerine ‘test altyapısı hatası’ olarak ayırırım. Başarısız, engellenmiş ve geçersiz yürütmelerin hepsini tek bir kırmızı kutuya toplamak, düzeltme kararını zorlaştırır.
Regresyon seti her değişiklikte aynı büyüklükte olmak zorunda değildir. Değişen sinyal, alıcılar ve ortak ağ etkileri üzerinden hedefli bir küme seçilebilir; ancak kritik hata tepkileri için kararlaştırılmış temel set korunur. Test sayısı tek başına başarı metriği değildir: hangi gereksinimin hangi koşulda kanıtlandığı gösterilmelidir.
Validasyon çıktısı: ‘Çalışıyor’ yerine incelenebilir kanıt
Kapanış kaydı en az gereksinim kimliğini, test kimliğini, donanım-yazılım-kalibrasyon ve ağ veritabanı sürümlerini, bağlantı düzenini, araç ayarlarını, ölçüm koşullarını, beklenen ve gözlenen sonucu içermelidir. Ham trafik, gerekiyorsa osiloskop kaydı, uygulama durumu ve hata kaydı aynı olayla ilişkilendirilir. Kişisel ya da gizli araç verileri paylaşılacak örneklerden çıkarılır.
Doğrulama, tanımlanan gereksinimlerin karşılandığını sınar. Validasyon ise bu gereksinimlerin ve ortaya çıkan davranışın amaçlanan kullanım için yeterli olup olmadığını değerlendirir. Şartnameye uyan bir gösterge, sürücüye yanıltıcı eski hız göstermeye devam ediyorsa sorun yalnızca test sonucunda değil, gereksinimin kendisinde de olabilir.
Sonuç raporu geçilen testlerin yanında kapsam dışı koşulları, açık hataları, sapmaları ve kalan riskleri de belirtmelidir. Bir CAN testinin başarılı olması tek başına fonksiyonel güvenlik uygunluğu veya bütün aracın validasyonu anlamına gelmez. Mühendislik açısından savunulabilir sonuç, iddianın sınırı ile onu destekleyen kanıtın birbirine uymasıdır.
Örnek test matrisini incele
| Senaryo | Uyarım | İzlenen nokta | Beklenen sonuç | Yakalanan risk |
|---|---|---|---|---|
| Normal iletişim | 100 km/h, 20 ms | Çözülen hız ve geçerlilik | Doğru değer ve geçerli durum | Yanlış ölçek / byte order |
| Hedef mesaj kaybı | Sadece 0x180 susturulur | Son geçerli alımdan itibaren süre | Örnekte 100–110 ms’de kullanılamıyor | Eski veriyi geçerli sayma |
| Geçersiz veri akışı | Her 20 ms’de geçersiz sinyal | Geçerli veri zamanlayıcısı | Geçersiz paket tazelik sağlamaz | Timeout’un yanlış sıfırlanması |
| Kısmi kurtarma | Bir geçerli mesaj, sonra sessizlik | Normal duruma geçiş | Üç mesaj şartı sağlanana kadar bekler | Erken normale dönme |
| Trafik patlaması | Kontrollü öncelik ve yük örüntüsü | En büyük gecikme ve deadline | Onaylı zamanlama şartları korunur | Ortalamada gizlenen ihlal |
Kaynaklar ve ileri okuma.
Buradaki deneyler, kurgusal bir hız mesajı için deterministik eğitim modelleridir. Gerçek araç verisi veya ECU ölçümü içermez. Projede onaylı gereksinimler ve geçerli standart sürümleri esas alınır.
- [1] KvaserCAN Frame Types — acknowledgement and frame semantics
- [2] KvaserHow to test if your CAN termination works correctly
- [3] CSS ElectronicsCAN DBC File Explained — signal decoding
- [4] KvaserCAN Error Handling — detection and error confinement
- [5] AUTOSARE2E Communication Protection Library — CP 4.3.1 (conceptual reference)
- [6] Linux Kernel DocumentationSocketCAN — CAN FD driver support and bit timing
- [7] VectorCANoe — communication analysis, simulation and automated testing
CAN ile bilgi paylaşımını anlamak, mesajın yolculuğunu izlemekle başlar. Mesajın taşınması, yorumlanması ve uygulamada kullanılması birlikte incelendiğinde, otomotiv ağlarında test ve validasyonun amacı daha anlaşılır hâle gelir.
Diğer yazılara dön