Model Tabanlı Tasarımda Sistematik Doğrulama: Gereksinim Tabanlı Test

Bir modelin simülasyonda beklenen cevabı üretmesi ile gereksinimlerini karşılaması aynı şey değildir. Bu iki kavramı birbirine bağlayan doğrulama disiplini, Gereksinim Tabanlı Test (Requirements-Based Testing, RBT) olarak adlandırılır. Bu yazıda, MATLAB ve Simulink ekosisteminde RBT iş akışını; hangi araçlarla, hangi sırada ve hangi çıktılarla yürüttüğümüzü adım adım inceliyoruz.

Giriş

Gömülü sistem geliştirmede doğrulama, uzun yıllar boyunca kod yazıldıktan sonra başlayan bir aşama olarak algılandı. Simülasyonlarda modelin “düzgün çalıştığının” gözlemlenmesi, teslimat için çoğu zaman yeterli kabul ediliyordu. Ancak sistem karmaşıklığı arttıkça bu yaklaşımın sınırları netleşti: bir kontrolcünün beklenen basamak tepkisini üretmesi, aynı kontrolcünün farklı çalışma koşullarında belirlenen sınırlar içinde kalmasını garanti etmiyor; bir durum makinesinin birkaç geçişini doğru işletmesi, geri kalan geçişlerin de güvenli olduğu anlamına gelmiyor.

Gereksinim Tabanlı Testin kabul gerekçesi tek cümleyle özetlenebilir: her test senaryosu, doğrulamaya çalıştığı gereksinime kadar geri izlenebilir olmalı; her gereksinim de kendisini doğrulayan en az bir test ile eşleşmelidir. Bu prensibi otomotivde ISO 26262, havacılıkta DO-178C gibi standartlar zorunlu kılıyor; ancak bu standartlara tabi olmayan projelerde bile RBT, geç aşamada yakalanan bozukluklar yerine sorunları tasarım aşamasında ortaya çıkaran en etkili disiplinlerden biridir.

Aşağıda MATLAB ve Simulink ekosisteminde RBT uygulamasını, araç zinciriyle birlikte ele alıyoruz.

V-Modelinde RBT’nin Konumu

Model tabanlı tasarımda V-modeli, gereksinim seviyesinden başlayıp birim testi, entegrasyon testi ve sistem kabul testine uzanır. Sol kolda gereksinim ve tasarım aşamaları, sağ kolda ise doğrulama ve validasyon aktiviteleri yer alır. RBT’nin görevi bu iki kolu yatay bağlantılarla birbirine tutturmaktır: sağ kolda koşulan her bir test, sol koldaki bir gereksinimin karşılığı olarak var olur.

Şekil 1 — V-modelinin iki kolu, gereksinim izlenebilirlik bağlantılarıyla tutturulur.

V-modelinin sol kolunda ortaya çıkan bir eksiklik — örneğin anlamı bulanık yazılmış bir gereksinim — sağ kolda entegrasyon testi sırasında yakalandığında, tasarımın revize edilmesi ve tüm bağımlı bileşenlerin yeniden doğrulanması gerekir. Hata düzeltme maliyeti V’nin sağına doğru hızla artar. RBT, bu maliyeti düşürmek için gereksinimlerin kalitesini henüz sol kolda denetlenebilir hâle getirir ve sağ koldaki aktiviteleri bu gereksinimlere kilitler.

Şekil 2 — Hata düzeltme maliyeti ve süresi, V-modelinin sağ koluna doğru katlanarak artar.

Gereksinim Kalitesi: Doğrulanabilir Değilse, Test Edilemez

RBT iş akışında test tasarımından önce gelen adım, gereksinimlerin yazımıdır. Bir gereksinim doğrulanabilir değilse, ne kadar çok test yazılırsa yazılsın o gereksinim “doğrulandı” sayılamaz. “Sistem hızlı cevap verecektir” ifadesi, “Sistem girişten 50 ms içinde cevap üretecektir” ifadesine dönüştürülmediği sürece test edilebilir değildir.

Model Tabanlı Tasarım yaklaşımının temel kazanımlarından biri, V-modelinin tüm aşamalarını tek bir bütün hâlinde yönetebilmektir. Gereksinim, model, otomatik üretilen kod ve test sonuçları aynı araç zinciri içinde tutulduğunda, proje boyunca süreklilik arz eden bir dijital thread oluşur. Bu süreklilik, gereksinimdeki bir değişikliğin tasarım ve test artefaktlarına otomatik olarak yansımasını sağlar; aynı zamanda sertifikasyon için istenen delil zincirinin temelini kurar.

Şekil 3 — Model Tabanlı Tasarım’da model geliştirme sürecinin merkezindedir ve gereksinimden sistem testine uzanan dijital thread’i oluşturur.

Requirements Toolbox, gereksinimleri Word veya Excel’de tutmak yerine doğrudan MATLAB ortamında yönetme imkânı sağlar. Requirements Editor (slreq.editor) üzerinden şunlar mümkündür:

• Gereksinimleri hiyerarşik yapıda oluşturmak ve alt gereksinim ilişkileri kurmak.
• Custom attribute eklemek (priority, safety level, rationale, verification method).
• Keyword’ler ile gereksinimleri kategorilere ayırmak (functional, safety, performance gibi) ve raporlama sırasında bu kategorilere göre filtreleme yapmak.
• DOORS, Polarion, Jama gibi harici sistemlerle ReqIF standardı üzerinden çift yönlü senkronizasyon kurmak.

Pratikte gereksinimleri yönetmenin iki yolu vardır: birincisi gereksinimleri doğrudan Requirements Toolbox içinde oluşturmak (authored requirements), ikincisi ise harici bir sistemden içe aktarmak (external requirements). İkinci yaklaşımda DOORS, Jama veya Polarion gibi kurumsal bir gereksinim yönetim sisteminde tutulan veriler ReqIF formatıyla MATLAB ortamına getirilir; üzerinde yapılan model ve test eşleştirmelerinden sonra gerekirse aynı formatla kaynağa geri yazılabilir. Bu roundtrip yaklaşımı, gereksinim sahibi ekip ile geliştirme ekibinin farklı araçlar kullanmaya devam etmesine rağmen, tek bir doğruluk kaynağı (single source of truth) üzerinde çalışmasını mümkün kılar.

Şekil 4 — Requirements Toolbox; harici gereksinim yönetim sistemleriyle ReqIF formatı üzerinden çift yönlü senkronizasyon kurar.

R2022a ile gelen Requirements Table block, formal gereksinim analizi için belirgin bir katkı sunar. Bu blok gereksinimi “eğer/değilse” mantığıyla tablo formatında ifade etmeye olanak tanır ve Simulink Design Verifier ile birlikte tutarlılık (consistency) ve tamamlılık (completeness) analizi yapılabilir. İki gereksinim aynı durumda çelişkili davranışlar talep ediyorsa, kod üretilmeden, hatta çoğu zaman modele bloklar eklenmeden, tespit edilir.

Pratikte Sık Karşılaşılan Durum

Ekiplerin çoğu, RBT sürecine başladıklarında ilk engele gereksinim yazımında takılır. “Motor sıcaklığı yüksekse alarm verilir” gibi bir gereksinim atomik değildir: sıcaklık eşiği belirsiz, “alarm” ifadesi tanımsız, “yüksek”in histerezis içerip içermediği yoruma açıktır. İyi yapılmış bir gereksinim gözden geçirme oturumu, sonraki tüm test aşamalarını anlamsız hâle getirebilecek bu belirsizlikleri en başta temizler.

İzlenebilirlik: Tek Hat, İki Yön

RBT’nin omurgasını izlenebilirlik oluşturur. Klasik iş akışında gereksinim Word dosyasında, model Simulink’te, test senaryoları Excel’de, sonuçlar ise bir başka rapor dosyasında tutuluyorsa, bir gereksinim değiştiğinde hangi testin güncelleneceği ve hangi modül kodunun yeniden gözden geçirileceği manuel çıkarsamaya kalır. Büyüyen projelerde bu yaklaşım sürdürülebilir değildir.

Requirements Toolbox’taki izlenebilirlik matrisi, bu ilişkiyi otomatik kurar ve aşağıdaki soruları tek ekranda cevaplanabilir kılar:

• Hangi gereksinim, hangi Simulink bloğunda veya hangi MATLAB kod satırında uygulanıyor?
• Hangi gereksinim hâlâ hiç test edilmemiş durumda?
• Hangi test, hiçbir gereksinimle eşleşmiyor (orphan test)?
• Bir gereksinim değiştiğinde, bu değişimden etkilenen tüm alt artefaktlar hangileridir?

Şekil 5 — Requirements Toolbox Traceability Matrix arayüzü, gereksinim ile model bloklarını aynı görünümde ilişkilendirir.

Son soru, pratikte en kritik olanıdır. Simulink Test’te bir test senaryosu passed bile olsa, üst gereksinimi değişmişse Requirements Toolbox testin durumunu change pending olarak işaretler. Bu mekanizma, özellikle uzun soluklu projelerde “hangi test hâlâ geçerli?” sorusunun manuel takibini ortadan kaldırır.

Çift yönlü izlenebilirlik (bidirectional traceability), DO-178C ve ISO 26262 ASIL-C/D seviyelerindeki projelerde sertifikasyon delilinin temel bileşenidir: gereksinimden teste doğru kadar, testten gereksinime geri de izlenebilmek zorundadır. Requirements Toolbox’un ürettiği raporlar, sertifikasyon kuruluşuna sunulan dosya setinin doğrudan bir parçası olarak kullanılabilir.

Şekil 6 — Her gereksinimin uygulama (implemented) ve doğrulama (verified) durumları Requirements Editor üzerinden tek bakışta takip edilir.

Test Yazımı: Simulink Test ve Test Harness

RBT iş akışında test senaryoları, modelin iç mantığına göre (white-box) değil, gereksinimin giriş–çıkış davranışına göre (black-box) yazılır. Bu ayrım önemlidir; zira test senaryoları, implementasyonun bir türev ürünü değil, gereksinimin bağımsız yorumu olmalıdır. İmplementasyonu esas alarak yazılan test, tasarımdaki bir mantık hatasını da birlikte meşrulaştırır.

Simulink Test Harness, doğrulanacak bileşeni ana modelden izole bir test ortamına taşır. Bu ortamda:

• Ana model tasarımı hiçbir şekilde değiştirilmez; harness ayrı bir MLDATX dosyasında saklanır.
• Bileşenin giriş ve çıkışlarına özelleştirilmiş kaynak/sink blokları bağlanır.
• Farklı simülasyon modları (normal, SIL, PIL) aynı harness üzerinde koşturulabilir.
• Test verileri MATLAB tablolarından, Excel dosyalarından veya gerçek sistem kayıtlarından beslenebilir.

Şekil 7 — DUT (Design Under Test) ana modelden kopyalanır, gereksinim giriş–çıkış davranışı üzerinden değerlendirilir.

Gereksinimdeki zaman bağımlı ifadelerin formalizasyonu için Test Assessment blokları ve verify ifadeleri kullanılır. Örneğin “Aracın hızı 3 saniye boyunca 100 km/h üzerinde kalırsa uyarı lambası 500 ms içinde aktifleşmelidir” gereksinimi, neredeyse birebir bir sözdizimiyle yazılabilir:

Şekil 8 — Simulink Test’te test harness’e girişler MAT/Excel dosyalarından, Signal Editor’dan veya Test Sequence bloğundan beslenir; çıkışlar baseline verileri veya MATLAB Unit Test ifadeleri ile değerlendirilir.

Temporal operatörlerin (duration, within, delayed, until) varlığı, bu tür ifadelerin MATLAB scriptleriyle manuel kurgulanmasını değil, gereksinim metniyle neredeyse birebir örtüşen bir sözdizimiyle yazılabilmesini sağlar. Test Manager arayüzü, bu assessment’ları klasik input/output karşılaştırmalarıyla aynı iş akışında yönetir.

Kapsam Analizi: “Yeteri Kadar” Test Ettik mi?

Gereksinim tabanlı tüm testler “passed” sonucuna ulaştığında bile iş tamamlanmış olmaz. Akla gelmesi gereken ilk soru şudur: mevcut testler, modelin ne kadarını gerçekten çalıştırıyor?

Simulink Coverage bu soruyu nicel olarak cevaplar. Simulink Test üzerinden koşulan senaryolar Coverage ile birlikte çalıştırıldığında şu metrikler elde edilir:

• Decision Coverage: Her karar (if/switch/if-else) için hem true hem false yollarının en az bir kez çalıştırılıp çalıştırılmadığı.
• Condition Coverage: Bir koşuldaki her boolean operand’ın hem 0 hem 1 değerleriyle değerlendirilip değerlendirilmediği.
• MC/DC (Modified Condition/Decision Coverage): Her koşulun, diğerlerini sabit tutarak kararın sonucunu bağımsız biçimde etkilediğinin gösterilmesi.

Şekil 9 — Kapsam analizi, test edilmeyen dalları ve eksik koşul kombinasyonlarını görünür kılar.

MC/DC, DO-178C Level A yazılımlarında zorunlu metriktir. Çok koşullu mantıklarda MC/DC’nin manuel test yazımıyla sağlanması oldukça zahmetlidir; bu noktada Simulink Design Verifier‘in formal metotlarla otomatik test üretimi devreye girer ve eksik kapsamı tamamlayacak senaryoları önerir.

Şekil 10 — Simulink Design Verifier, kapsam boşluklarını kapatacak yeni test senaryolarını formal analizle otomatik üretir.

Kapsam analizi sonuçlarında iki durum özellikle dikkat çekicidir:

• Gereksinim tarafından kapsanmayan model mantığı. Modelde çalışan ama hiçbir gereksinim tarafından talep edilmeyen bir fonksiyonellik — unintended function — tespit edilmiş demektir. Güvenlik kritik uygulamalarda bu, ya gereksinim dokümanında bir eksik olduğunu ya da modelde fazla mantık bulunduğunu gösterir.
• Gereksinimi olan ama çalıştırılamayan kod. Kodun erişilemez (dead) parçasıdır ve genellikle koşul mantığında bir hataya işaret eder.

Her iki durum da kapsam raporu olmadan fark edilmeden kalma eğilimindedir.

Model seviyesindeki kapsam metriklerine ek olarak, Embedded Coder tarafından üretilen C/C++ kodu üzerinde de kapsam ölçümü yapılabilmektedir. Simulink Coverage ile SIL/PIL testleri birlikte koşturulduğunda, modelde hesaplanan kapsam bilgisi otomatik üretilen kodun satır, karar ve MC/DC kapsamıyla eşleştirilir. Bu; model-kod eşdeğerliğini kanıtlamak için DO-178C ve ISO 26262 süreçlerinde talep edilen önemli bir delil kaynağıdır.

MIL, SIL ve PIL: Eşdeğerlik Testleri

Model Tabanlı Tasarım’da aynı gereksinim seti, geliştirme sürecinin farklı aşamalarında üç farklı koşum ortamında doğrulanır: MIL (Model-in-the-Loop) — modelin bilgisayar üzerinde simülasyonu; SIL (Software-in-the-Loop) — Embedded Coder tarafından üretilen kodun host bilgisayarda koşturulması; PIL (Processor-in-the-Loop) — üretilen kodun hedef mikroişlemci üzerinde koşturulması.

Şekil 11 — Simulink Test’in Equivalence Test şablonu; aynı test senaryosunu MIL ve SIL/PIL ortamlarında koşturup çıktıları karşılaştırır.

Simulink Test’in eşdeğerlik (equivalence) test şablonu, aynı gereksinim tabanlı senaryonun MIL ve SIL çıktılarını otomatik olarak karşılaştırır. Farklar tolerans bandının dışına çıkarsa test fail olur. Bu; kod üretim sürecinde kayan nokta–tam sayı dönüşümlerinden veya hedef donanımın matematiksel davranışından kaynaklanan farkların saptanmasını kolaylaştırır.

Sertifikasyon Araç Zinciri

ISO 26262, DO-178C, IEC 61508 veya EN 50128 gibi standartlara tabi projelerde RBT bir tercih değil, zorunluluktur. Bu standartlar aşağıdaki unsurları arar:

• Gereksinimden teste ve koddan gereksinime doğru çift yönlü izlenebilirlik.
• Her gereksinimin en az bir test ile eşleştirilmesi ve sonuçlarının kayıt altına alınması.
• Otomatik üretilen kodun, üretildiği modelin gereksinimlerine izlenebilir olması.
• Kullanılan doğrulama araçlarının tool qualification sürecinden geçirilmiş olması.

IEC Certification Kit (ISO 26262, IEC 61508, IEC 62304, EN 50128) ve DO Qualification Kit (DO-178C, DO-254), MathWorks’ün MATLAB/Simulink/Embedded Coder/Polyspace araç zinciri için önceden hazırlanmış sertifikasyon paketleridir. Bu paketler; tool qualification dosyalarını, referans iş akışlarını ve denetim şablonlarını içerir. Sertifikasyon sürecinde sunulacak belgelerin önemli bir kısmı, Requirements Toolbox ve Simulink Test’in otomatik ürettiği raporlar olacak şekilde yapılandırılabilir.

Şekil 12 — Simulink Coverage ve Requirements Toolbox tarafından otomatik üretilen bir doğrulama raporu örneği; gereksinim, test ve kapsam metrikleri tek bir denetim dosyasında birleşir.

Sektörden Örnekler

Gereksinim tabanlı test ve Model Tabanlı Tasarım, havacılık ve otomotiv başta olmak üzere güvenlik kritik yazılım geliştiren şirketlerde kurumsal bir yetkinlik olarak yerleşmiş durumda. Aşağıda, MathWorks kullanıcı hikayelerinden öne çıkan üç örneği kısaca paylaşıyoruz.

Kaynak: MathWorks yayınlanmış kullanıcı hikayeleri (mathworks.com/company/user_stories).

Sonuç

Gereksinim Tabanlı Test, Model Tabanlı Tasarım’ın bir eklentisi değil; yazılım geliştirmenin doğrulama aşamasını disipline eden bir çalışma metodudur. Gereksinimi doğrulanabilir şekilde yazmak, onu model ve teste izlenebilir biçimde bağlamak, test koşumunu otomatik hâle getirmek ve kapsamı ölçmek, bu zincirin her halkası, ürün sahaya çıktığında sorulacak “yazılım, kendisinden istenen işi yapıyor mu?” sorusuna tekrarlanabilir ve objektif bir cevap verebilmek içindir.

MATLAB ve Simulink ekosisteminde Requirements Toolbox, Simulink Test, Simulink Coverage ve Simulink Design Verifier bu metodolojiyi destekleyen araçlardır. Araçların tek tek kullanımı kadar, aralarındaki entegrasyon ve CI/CD hatlarına yerleştirilmeleri, RBT yatırımının gerçek karşılığının alındığı noktadır. Gereksinimi bir metin dosyası olmaktan çıkarıp model, test ve rapor ile sürekli eşlenen yaşayan bir artefakta dönüştürmek , gömülü yazılım geliştirmede uzun vadeli kalitenin en somut göstergelerinden biridir.