Model Tabanlı Tasarımda CI/CD Otomasyonu
Model tabanlı tasarımda üretilen şey iki katmanlıdır: bir tarafta Simulink modeli, diğer tarafta o modelden üretilen gömülü kod. İkisi de her değişiklikte otomatik olarak doğrulanmalı, test edilmeli ve standartlara karşı denetlenmelidir. Bu yazımızda versiyon kontrolünden teslime uzanan CI/CD pipeline’ını altı adımda kuracak ve her adımda ilgili MathWorks ürünüyle eşleştireceğiz.
Yazılım ekipleri kodu yıllardır sürüm kontrolü, otomatik test ve sürekli entegrasyonla yönetir. Model tabanlı tasarımın da aynı disipline ihtiyacı vardır.
Bir model değiştiğinde üretilen kodun, testlerin, yapısal kapsamın ve standart uyumunun otomatik olarak yeniden değerlendirilmesi gerekir. Elle yapıldığında bu süreç hem yavaştır hem de atlanır. CI/CD (sürekli entegrasyon ve sürekli teslim) bu yeniden değerlendirmeyi her değişiklikte otomatik yürütür ve hatayı erken aşamada, değişikliğin geldiği yere kadar izlenebilir biçimde yakalar.
MathWorks bu akışı bilinen bir eşlemeyle kurar. Model tabanlı tasarım erken doğrulamayı (early verification) öne alır ve bu, pipeline’da Build aşamasından önce gelen bir Verify aşamasına karşılık gelir. Kod üretimi Build aşamasında yapılır. Simülasyonla dinamik test ve üretilen kodun statik analizi ise Test aşamasında yer alır. Bu yazı pipeline’ı altı adımda kuruyor ve her adımda ilgili MathWorks çözümünü eşliyor. Adımların hepsi tek bir araçla değil, birbirini tamamlayan bir araç ailesiyle yürütülür.
Sürüm Kontrolü ve Yeniden Üretilebilirlik
Pipeline Aşaması
Modellerin, test verisinin, betiklerin ve veri sözlüklerinin sürüm kontrolünde tutulması. Aynı kaynaktan, aynı sürümle, her makinede aynı sonucun üretilmesi.
MATLAB Projects · Git / SVN entegrasyonu · MATLAB Docker imajı
Bir pipeline’ın başlangıç noktası tek bir doğru kaynaktır. MATLAB Projects bu kaynağı yönetir. Proje, yolu (path), bağımlılıkları ve dosya etiketlerini bir arada tutar ve Git ya da Subversion ile sürüm kontrolüne bağlanır. Proje üzerinden yapılan bağımlılık analizi, bir modelin hangi alt modellere, veri sözlüklerine ve betiklere dayandığını çıkarır. Bu analiz ileride yalnızca etkilenen artefaktların yeniden işlenmesini sağlar.
Simulink modeli ikili (binary) bir dosyadır. Metin tabanlı birleştirme onu bozar. Bu nedenle ikili dosya uzantıları (.slx, .mdl, .mat, .mlx) Git’e ikili olarak kaydedilir ve proje açıldığında MATLAB bir .gitattributes dosyasını otomatik oluşturur. Dal birleştirmesi için ise model karşılaştırma ve birleştirme aracı kullanılır. Bu araç hem yerelde hem de CI hattında otomatik birleştirme yapacak biçimde yapılandırılabilir.
Yeniden üretilebilirliğin ikinci ayağı çalışma ortamıdır. Bir testin yerelde geçip CI’da kalması çoğu zaman sürüm ya da bağımlılık farkındandır. MathWorks’ün resmî MATLAB Docker referans mimarisi bu farkı ortadan kaldırır. MATLAB sürümünü ve eklenti ürünlerini sabitleyen bir konteyner imajı tanımlar, böylece her koşum aynı ortamda çalışır.
Dikkat
İkili model dosyalarında dal birleştirmesi çakışma üretir ve bu çakışma metin diff’iyle çözülemez. İki ekip aynı modeli paralel değiştirdiğinde model birleştirme aracı şarttır. İkili dosyaları kaydetmeden çalışmak ise dosya bozulmasına yol açar.
Pipeline’ın Tanımı
Pipeline Aşaması
Hangi görevlerin, hangi sırada, hangi bağımlılıklarla çalışacağının tanımı. Değişmeyeni yeniden işlememek için artımlı (incremental) yürütme. Sunucuya göndermeden önce yerelde ön denetim.
MATLAB Build Tool · CI/CD Automation for Simulink Check (Process Advisor) Bir pipeline, görevlerin ve aralarındaki bağımlılıkların bir tanımıdır. MATLAB Build Tool bu tanımı standart bir arayüzle verir. Görevler bir buildfile.m dosyasında tanımlanır.
Hazır görev sınıfları arasında kod sorunlarını bulan ve hata varsa derlemeyi düşüren görev, testleri koşan görev ve paketleme görevi bulunur. Bağımlılıklar belirtilir, böylece görevler doğru sırada çalışır. Görevin girdi ve çıktıları bildirildiğinde araç değişmeyen görevleri atlar ve yalnızca değişeni yeniden işler.
| function plan = buildfile plan = buildplan(localfunctions); plan(“check”) = matlab.buildtool.tasks.CodeIssuesTask; plan(“test”) = matlab.buildtool.tasks.TestTask; plan.DefaultTasks = [“check” “test”]; end |
Görev planı. CI ajanında “matlab -batch buildtool” komutuyla, terminalden, etkileşimsiz çalışır.
Model tabanlı tasarıma özel pipeline için CI/CD Automation for Simulink Check destek paketi devreye girer. Bu paket Process Advisor uygulamasını sağlar. Bir süreç modeli (process model) tanımlarsınız ve bu model, model tabanlı tasarımın yaygın görevlerini hazır olarak içerir. Modelleme standardı denetimi (Model Advisor ile), test (Simulink Test ile), kod üretimi (Embedded Coder ile) ve kod incelemesi (Simulink Code Inspector ile) bu görevlerdendir. Görevler arasındaki bağımlılıkları araç kendisi yönetir. Örneğin kodlama standardı denetimini çalıştırmak istediğinizde, gerekiyorsa kod üretimi görevi önce otomatik çalışır.
| % Yerelde ön denetim (prequalification): Process Advisor uygulaması % CI ajanında, etkileşimsiz: runprocess fonksiyonu runprocess |
Aynı artımlı yürütme motoru hem yerelde hem CI’da çalışır, böylece sonuçlar tutarlı olur.
Bu paketin iki ayırt edici özelliği vardır. Birincisi yerel ön denetimdir. Process Advisor uygulamasıyla değişikliği masaüstünde önceden niteleyerek (prequalify) CI’daki derleme ve test başarısızlıklarını azaltırsınız. İkincisi artımlı yapı sistemidir. Sistem artefaktlardaki değişimi algılar ve yalnızca etkilenen görevleri yeniden çalıştırır, bu da derleme süresini kısaltır. Paket, GitLab ve GitHub gibi sistemler için pipeline yapılandırma dosyalarını da üretebilir ve paralel pipeline mimarilerini destekler. Kullanımı R2022a ve sonrasını, Simulink Check ürününü ve MATLAB Projects yapısını gerektirir.
Dikkat
Artımlı yapının doğruluğu, görev girdi ve çıktılarının eksiksiz bildirilmesine bağlıdır. Bir bağımlılık bildirilmezse sistem değişeni göremez ve stale bir önbellekle çalışır. Bu sessiz bir hata kaynağıdır. Şüphede kaldığınızda önbelleği temizleyip tam koşum almak güvenli yoldur.
Doğrulama, Test ve Kapsam
Pipeline Aşaması
Verify aşaması: modelleme standardı uyumu ve metrikler. Test aşaması: gereksinim temelli test, yapısal kapsam (karar, koşul, MCDC), formal analiz ve kapsam boşluklarının kapatılması.
Simulink Check · Simulink Test · MATLAB Test · Simulink Coverage · Simulink Design Verifier
Verify: Standart Uyumu
Pipeline’ın ilk denetimi modelin kurallara uygunluğudur. Simulink Check Model Advisor denetimlerini çalıştırır. MathWorks Advisory Board (MAB) stil kılavuzu ve yüksek bütünlüklü standartlar (DO-178C, ISO 26262) bu denetimler arasındadır. Denetimler düzenleme anında (edit-time) çalışabildiği gibi CI’da toplu da çalışır. Boyut ve siklomatik karmaşıklık gibi metrikler raporlanır. Model Testing Dashboard ise bağlı gereksinimleri, test sonuçlarını ve kapsamı tek panoda toplayarak izlenebilirliğin tamlığını gösterir.
Test: Dinamik Doğrulama
Simulink Test gereksinim temelli testleri yönetir ve koşar. Koşum kabini (test harness) test edilen bileşeni yalıtır ve modele müdahale etmez. Testler gereksinim kimliklerine bağlanır. Aynı testler CI ajanında etkileşimsiz çalıştırılır. MATLAB kodu tarafında ise MATLAB Test test yönetimi, kod kapsamı ve artımlı test yürütme sağlar.
| % CI ajanında testleri etkileşimsiz koşma ve artefakt üretme matlab -batch “results = runtests(‘IncludeSubfolders’,true); assertSuccess(results)” |
Test sonuçları JUnit XML, kapsam ise Cobertura XML olarak dışa aktarılıp CI panosuna verilir.
Kapsam ve Formal Analiz
Simulink Coverage testin ne kadarını gerçekten çalıştırdığınızı ölçer. Karar, koşul, değiştirilmiş koşul ve karar (MCDC), ilişkisel sınır ve sinyal aralığı metriklerini uygular. Kapsamı birden çok koşum üzerinden biriktirir ve bağlı gereksinimlere göre kapsayarak istenmeyen kapsamı dışarıda tutar. Eksik kapsam yalnızca test boşluğunu değil, eksik gereksinimi ya da istenmeyen işlevi de açığa çıkarır. Boşluk kaldığında Simulink Design Verifier devreye girer. Formal yöntemlerle (SAT ve SMT) tasarım hatalarını arar, gereksinim özelliklerini ispatlar ya da onları ihlal eden karşı örnek üretir ve kapsam hedeflerini karşılayan testleri otomatik üretir. Üretilen kodla simülasyon arasındaki sayısal eşdeğerlik ise sırt sırta (back-to-back) SIL ve PIL testleriyle doğrulanır.
Dikkat
Design Verifier kapsam boşluğunu otomatik kapatır ama ürettiği testlerin de bir gereksinime bağlanması gerekir. Yapısal kapsam gerekli koşuldur, yeterli koşul değildir. Yüzde yüz MCDC her zaman ulaşılabilir olmayabilir, savunmacı modelleme kalıpları erişilemez dallar üretir. Bunlar kapsam filtresiyle ayrılır ve gerekçesi kayıt altına alınır.
Kod Üretimi ve Statik Analiz
Pipeline aşaması
Build aşaması: modelden üretim kodunun üretilmesi ve izlenebilirliği. Üretilen kodun, model düzeyi denetimlerin ulaşamadığı çalışma zamanı hataları için statik analizi.
Embedded Coder · Polyspace Bug Finder · Polyspace Code Prover
Build aşamasında Embedded Coder modelden okunabilir, derli toplu ve hızlı C ya da C++ üretim kodu üretir. Kod ile model arasındaki izlenebilirlik korunur, böylece bir kod satırından kaynak model ögesine geri gidilebilir. Üretimin başarısı (uyarısız derlenme) bir görev olarak pipeline’da denetlenir. SIL ve PIL kipleri üretilen kodu modelle karşılaştırarak sayısal eşdeğerliği doğrular.
Model düzeyi denetimler her şeyi göremez. Tamsayı taşması, bellek erişim hataları, işaretçi sorunları ve tümleştirme kaynaklı çalışma zamanı hataları kod düzeyinde ortaya çıkar. Polyspace bu boşluğu kapatır. Polyspace Bug Finder kusurları, kodlama kuralı ihlallerini (MISRA C, CERT C) ve metrikleri statik analizle bulur. Polyspace Code Prover ise soyut yorumlamaya (abstract interpretation) dayalı formal yöntemlerle, seçili çalışma zamanı hatalarının tüm yürütme yollarında bulunmadığını ispatlar. Sonuçlar Simulink modeline geri izlenir ve DO-178C ile ISO 26262 için sertifikasyon artefaktı olarak kullanılır.
Dikkat
Bug Finder ile Code Prover farklı işler yapar. Bug Finder hızlıdır ve olası kusurları işaretler. Code Prover her işlemi tüm yollar için inceler ve kanıt üretir, bu yüzden daha yavaştır ve büyük kod tabanında koşum bütçesi planlanmalıdır. İkisi tamamlayıcıdır, birbirinin yerine geçmez.
Paketleme, Teslim ve Raporlama
Pipeline Aşaması
Üretilen kodun, raporların, kapsam ve test sonuçlarının bir araya toplanması. Sonuçların CI panosunun anlayacağı biçimde dışa aktarılması ve aşağı ekiplere teslimi.
JUnit test sonuçları · Cobertura kapsam raporu · Embedded Coder yapı raporu
Bir pipeline yalnızca geçti ya da kaldı bilgisi üretmez. Kanıt üretir. MATLAB ve Simulink testleri, CI platformlarının doğrudan okuduğu artefaktlar olarak dışa aktarılır. Test sonuçları JUnit XML, yapısal kapsam Cobertura XML biçiminde verilir ve CI panosunda eğilim grafiklerine dönüşür. Bunlara üretilen kod, kod üretim raporu, standart denetim raporu ve statik analiz raporu eklenir. Hepsi tek bir paket olarak arşivlenir.
Teslim aşaması kuruluşa göre değişir. Çoğu ekipte paket, sertifikasyon artefaktlarıyla birlikte aşağı ekiplere ya da tümleştirme hattına aktarılır. Buradaki amaç tek bir komutla yeniden üretilebilen, izlenebilir bir teslim setidir.
CI Sunucusuna Bağlama
Pipeline Aşaması
Tanımlanan görevlerin bir CI sunucusunda, her itme (push) ve birleştirme isteğinde otomatik tetiklenmesi. Yerel ajan ya da bulut hizmeti seçimi.
Jenkins eklentisi · GitHub Actions · GitLab CI/CD bileşeni · Azure DevOps
MathWorks yaygın CI platformlarıyla doğrudan tümleşir. CI platformlarında MATLAB belgesi her biri için yöntemi verir. Jenkins’te ajana bir eklenti kurulur ve serbest biçim ya da matris projelerinde MATLAB çalıştırılır. GitHub Actions’ta iş akışı Github/workflows altında tanımlanır. GitLab CI/CD’de bir bileşenle .gitlab-ci.yml yazılır. Azure DevOps’ta bir uzantı kurulur. Her durumda görevler MATLAB build aracını ya da test koşumlarını çağırır ve JUnit ile Cobertura artefaktlarını üretir.
Somut iki örnek vardır. MathWorks teknik makalelerinden biri bir şerit takip sistemini Jenkins ile, diğeri bir hız sabitleme sistemini GitLab ile uçtan uca kurar. Her ikisi de Verify, Build, Test ve Package aşamalarını model tabanlı tasarıma eşler.
Dikkat
Kod üreten ve derleyen ürünler (coder ve compiler) bulut tabanlı CI hizmetlerinde her zaman ücretsiz kullanılamaz ve istemci erişim lisansı (CAL) gerekebilir. Üretim kodu üreten bir hat için çoğu zaman kendi sunucunuzu (self-hosted) çalıştırmak gerekir. Lisans modelini pipeline’ı kurmadan önce netleştirin.
Sınırlar ve Sonraki Adım
Pipeline kağıt üzerinde temizdir. Pratikte üç sürtünme öne çıkar. Birincisi koşum süresidir. Tam bir model derlemesi, Code Prover analizi ve geniş bir Monte Carlo test takımı birlikte pahalıdır. Artımlı yapı ve paralel koşum bunu azaltır ama paralel koşum lisans koltuğu ve hesap kaynağı ister. İkincisi ikili model dosyalarının birleştirme sürtünmesidir. Üçüncüsü lisans modelidir. Üretim kodu üreten araçlar bulut CI’da ek koşullara tabidir.
Nerede durup hangi denetimi her itmeye, hangisini gecelik (nightly) hatta koyacağınıza karar vermek bir araç ayarı değil, mühendislik kararıdır. Hızlı denetimler (standart uyumu, birim test, kapsam) her itmede çalışır. Pahalı denetimler (Code Prover, tam regresyon, donanım döngüde test) gecelik ya da sürüm öncesi hatta bırakılır. Bu hattın son halkası ise gerçek zamanlı hedeftir. Speedgoat üzerinde donanım döngüde test, üretilen kodun gerçek bir saat ve gerçek giriş çıkış altında davranışını sınar. Modelin gerçeğe dokunduğu yer orasıdır.
Sonuç
Bir model değiştiğinde ne olacağını önceden bilmek, testlerin geçip geçmediğini, kapsamın eksiksiz olup olmadığını, üretilen kodun standartları karşılayıp karşılamadığını, artık manuel takibin değil, pipeline’ın işidir. Burada kurulan zincir bunu her tetiklemede otomatik yapar. Burada kurulan zincir bunu her itmede otomatik yapar. Hangi denetimin her itmede, hangisinin gecelik hatta çalışacağı bir araç ayarı değil, mühendislik kararıdır; ama kararı vermek için önce zincirin tamamını görmek gerekir. Bu yazıda da bu bütünsel bakış açısını ortaya koymaya çalıştık.
Bu demoyu kendi projenizde deneyin
Model Tabanlı CI yaklaşımıyla, Simulink Test ve GitHub Actions kullanılarak uçak otomatik pilotu modelinin otomatik doğrulama sürecini keşfedin.