Gömülü yazılımda HIL testi: hatayı sahada değil masada yakalamak

Hardware-in-the-loop (HIL) testi nedir, küçük bir ekip nereden başlar? Simüle edilmiş sensör ve yüklerle gömülü yazılımı sahaya çıkmadan test etmenin sade yolu.

Giriş

Gömülü bir cihazda yazılım hatası çoğu zaman en pahalı yerde ortaya çıkar: sahada, müşterinin yanında, bir çatıda ya da bir pano içinde. Ofiste "çalışıyor" dediğimiz kod, gerçek sensörün gürültüsüyle, beklenmedik bir voltaj düşüşüyle ya da iletişim hattındaki kısa bir kopmayla karşılaşınca başka davranabiliyor.

Hardware-in-the-loop (HIL) testi bu boşluğu kapatmaya yarar. Fikir basit: gerçek kontrol kartını masada tutup, etrafındaki dünyayı — sensörleri, yükleri, hücreleri, şebekeyi — kontrollü biçimde simüle etmek. Böylece sahada haftalar sonra karşılaşacağınız bir durumu masada dakikalar içinde, istediğiniz kadar tekrar üretebilirsiniz.

Bu yazıda HIL'in ne olduğunu, ne zaman gerçekten gerektiğini ve küçük bir ekibin büyük bir test laboratuvarı kurmadan nereden başlayabileceğini anlatıyoruz.

HIL testi nedir, birim testinden farkı ne?

Gömülü yazılımda test genelde üç katmanda düşünülür:

• Birim testi: Fonksiyonları bilgisayarda, donanım olmadan test edersiniz. Hızlıdır ama donanım zamanlamasını ve çevre birimlerini görmez.
• Software-in-the-loop (SIL): Yazılımın tamamı simüle bir ortamda koşar. Mantık hatalarını yakalar, gerçek mikrodenetleyiciyi değil.
• Hardware-in-the-loop (HIL): Gerçek kart ve gerçek firmware çalışır; kartın girişleri simülatörden gelir, çıkışları ölçülür.

HIL'in değeri, gerçek donanımın zamanlamasını, kesme (interrupt) davranışını, ADC okumalarını ve iletişim yığınını (CAN, RS485, UART vb.) testin içine almasıdır. Birim testinin yerine geçmez; onun üzerine bir katman ekler.

Ne zaman gerçekten gerekir?

Her proje için tam bir HIL düzeneği şart değil. Şu durumlarda yatırımın karşılığı genelde hızlı alınır:

• Hatanın bedeli yüksekse: Batarya yönetimi, motor sürücü, şarj kontrolü gibi güvenlikle ilgili işlevlerde.
• Saha koşulu kolay üretilemiyorsa: Aşırı sıcaklık, hücre dengesizliği, şebeke kesintisi gibi durumları gerçekte beklemek pratik değil.
• Firmware sık güncelleniyorsa: OTA ile düzenli sürüm çıkıyorsanız, her sürümü elle test etmek sürdürülebilir olmaz.
• Birden fazla donanım revizyonu varsa: Aynı yazılımın farklı kart sürümlerinde aynı davrandığını görmek gerekir.

Tek seferlik bir prototip ya da düşük riskli bir veri toplayıcı için iyi birim testleri ve dikkatli bir manuel kontrol listesi çoğu zaman yeterlidir.

Küçük ekip için minimum HIL düzeneği

HIL denince akla pahalı ticari sistemler gelir; ama başlangıç için çok daha sade bir kurulum iş görür:

1. Test edilen kart (DUT): Sahaya giden kartın aynısı, aynı firmware ile.
2. Uyarıcı (stimulus) tarafı: Sensör ve yük davranışını taklit eden programlanabilir bir kaynak. Bu bir DAC çıkışlı geliştirme kartı, programlanabilir güç kaynağı ya da elektronik yük olabilir.
3. Ölçüm tarafı: Kartın çıkışlarını, röle durumlarını ve iletişim mesajlarını okuyan bir arayüz (USB-CAN, USB-RS485, mantık analizörü).
4. Test koşucusu: Senaryoları sırayla çalıştıran ve sonucu kaydeden bir betik. Python ve pytest bu iş için yaygın ve yeterli bir seçimdir.

İlk aşamada hedef "her şeyi simüle etmek" değil; en kritik iki üç senaryoyu tekrarlanabilir hale getirmektir.

İyi bir HIL senaryosu nasıl yazılır?

Bir senaryo; başlangıç durumunu, uygulanan uyarıyı ve beklenen tepkiyi açıkça tanımlamalıdır. Örneğin bir batarya yönetim sisteminde:

Senaryo	Uyarı	Beklenen tepki
Aşırı gerilim	Bir hücre gerilimi eşik üstüne çıkarılır	Şarj rölesi belirlenen süre içinde açılır, hata kodu yayınlanır
Haberleşme kopması	CAN hattı 2 saniye kesilir	Cihaz güvenli moda geçer, hat gelince toparlanır
Sıcaklık sensörü arızası	NTC girişi açık devre yapılır	Sensör hatası raporlanır, sistem yanlış değerle çalışmaz

Önemli olan, "çalışıyor mu" yerine "doğru sürede, doğru şekilde tepki veriyor mu" sorusunu sormaktır. Zamanlama gereksinimi yazılı değilse, test önce bunu netleştirmeye zorlar; bu da başlı başına faydalıdır.

HIL'i CI hattına bağlamak

Düzenek bir kez kurulduğunda, asıl kazanç onu otomatik çalıştırmaktan gelir. Pratik bir yol:

• Masadaki düzeneğe bağlı bir bilgisayarı CI için self-hosted runner olarak tanımlamak.
• Her birleştirmede (merge) firmware'i derleyip karta yüklemek ve kısa bir HIL senaryo setini koşturmak.
• Uzun senaryoları (saatlerce süren döngüler gibi) gece çalışacak ayrı bir işe ayırmak.
• Test sonuçlarını ve ölçüm kayıtlarını sürümle birlikte saklamak.

Böylece OTA ile sahaya gidecek her sürüm, en azından kritik senaryolardan geçmiş olur. Bu, sahadaki cihazı uzaktan güncellerken duyulan kaygıyı ciddi ölçüde azaltır.

Sık yapılan hatalar

• Düzeneği tek kişiye bağımlı bırakmak: Kablolama ve kurulum belgelenmezse düzenek o kişi olmadan çalışmaz.
• Sadece mutlu yolu test etmek: HIL'in asıl değeri arıza ve uç durum senaryolarındadır.
• Simülatöre körü körüne güvenmek: Simüle edilen model gerçeği tam yansıtmaz; saha verisiyle ara ara karşılaştırmak gerekir.
• Gerçek yüksek güçle masada denemek: Yüksek akım ve gerilim gereken testlerde güvenlik önlemleri ve uygun ekipman şarttır; bunlar ayrı planlanmalıdır.

SSS

HIL testi için ticari bir sistem almak zorunda mıyım? Hayır. Başlangıçta geliştirme kartları, programlanabilir güç kaynağı ve Python tabanlı bir test koşucusu çoğu senaryo için yeterlidir. Ticari sistemler, senaryo sayısı ve hassasiyet ihtiyacı arttığında anlam kazanır.

HIL, birim testinin yerine geçer mi? Geçmez. Birim testleri hızlı ve ucuzdur, mantık hatalarını erken yakalar. HIL ise donanım zamanlaması ve çevre birimleriyle ilgili hataları görür. İkisi birlikte kullanılmalıdır.

HIL testlerini her commit'te çalıştırmak gerekir mi? Kısa ve kritik senaryo seti için evet, mümkünse her birleştirmede. Uzun süren senaryolar gece veya sürüm öncesi çalıştırılabilir.

Hangi projelerde öncelik verilmeli? Hatanın güvenlik ya da maliyet riski taşıdığı, saha koşulunun kolay üretilemediği ve firmware'in sık güncellendiği projelerde.

Sonuç

HIL testi büyük bir laboratuvar işi olmak zorunda değil. Gerçek kart, programlanabilir bir uyarı kaynağı, basit bir ölçüm arayüzü ve birkaç iyi yazılmış senaryo ile başlayıp zamanla genişletmek mümkün. Kazanç, hataları sahada değil masada; müşteri yerine ekip olarak yakalamak.

TW Bilişim olarak gömülü yazılım, elektronik ve bunları besleyen DevOps altyapısı üzerinde çalışıyoruz; batarya ve enerji tarafındaki işlerimizde de test düzeneklerini bu sade yaklaşımla kurmaya özen gösteriyoruz.

Gömülü bir ürün için test altyapısı ya da firmware ile CI hattını birbirine bağlamak üzerine düşünüyorsanız, kısa bir görüşmeyle mevcut durumunuza bakabiliriz: iletişim veya [email protected].