Uydu Sistemlerinde Model Tabanlı Tasarım: Gereksinimden ECSS-E-ST-40 C Doğrulamasına | MATLAB ile Uçtan Uca Rehber
Bir uydunun yönelim kontrolü sistemini tasarlamak, birbirinden bağımsız görünen onlarca mühendislik kararını tek bir tutarlı zincire dönüştürmek demektir: gereksinim mi tutarsız? Mimari mi eksik? Model mi yanlış? Doğrulama mı yetersiz? Bu yazımıda, Requirements Toolbox ile başlayıp Simulink Design Verifier’da biten uçtan uca bir model tabanlı tasarım sürecini somut bir uydu örneği üzerinden anlatıyoruz.
Giriş
Bir uydu görevinin başarısı, gereksinimden doğrulamaya uzanan zincirin doğru modellenmesine bağlıdır. Uydunun yönelim dinamiği (attitude dynamics), yörünge hareketi ve çevresel bozucu torklar (disturbance torques) birbirine bağlı sistemlerdir. Bu sistemleri ayrı ayrı çözmek kolaydır. Asıl güçlük, hepsini tek bir tutarlı model üzerinde birleştirmek ve bu modeli denetlenebilir bir doğrulama planına bağlamaktır. Model tabanlı tasarım (Model-Based Design) tam bu noktada devreye girer.
Uydunun açısal hareketi, Euler hareket denklemleri ve kuaterniyon kinematiği temel alınarak modellenir. Euler açıları yerine kuaterniyon kullanmanın nedeni, gimbal kilidi (gimbal lock) sorununu taşımamasıdır. Yörünge hareketi ise iki cisim (Kepler) denklemleriyle ya da J2 ve daha yüksek zonal harmonikleri içeren sayısal yayılımla çözülür. Bu denklemler MATLAB ve Simulink ortamında blok diyagramlarla kurulur. Aerospace Blockset, yörünge ve dönme dinamiğini, çevresel modelleri ve işaretleme profillerini hazır bloklarla sağlar. Yönelim belirleme tarafında jiroskop, manyetometre, güneş algılayıcısı ve yıldız izleyici ölçümleri bir Kalman filtresinde (örneğin MEKF) birleştirilir. Kontrol tarafında B-dot detumble ve kuaterniyon geri beslemeli kontrolcü bu döngüyü kapatır.
Bir uydu için bu zincir tek bir araçla değil, bir araç ailesiyle yürütülür. Gereksinimler Requirements Toolbox ile yazılır ve izlenir. Mimari System Composer ile bileşenlere, portlara ve arayüzlere ayrılır. Fonksiyonel model Simulink, Simscape ve Stateflow ile kurulur. Hata senaryoları Simulink Fault Analyzer ile modele dışarıdan eklenir. Doğrulama ise Simulink Test, Simulink Coverage, Simulink Design Verifier ve Simulink Check ile yapılır. Bu yazı, aynı omurgayı MathWorks’ün CubeSat MBSE örneğiyle aynı sırada izler ve her adımda teoriyi ilgili MathWorks çözümüne eşler.
Bir noktayı baştan belirtmek gerekir. Bir gereksinimi mimaride bir bileşene bağlamak, o gereksinimin karşılandığı anlamına gelmez. Bu bağ yalnızca tasarımda bir karşılık olduğunu gösterir. Gereksinimin karşılandığının kanıtı simülasyon, yapısal kapsam ve formal analizdir. Bu ayrım, yazının dördüncü adımının çekirdeğini oluşturur.
Gereksinimler
| TEORİ | Hangi toolboxları kullanabilirsiniz? |
| Misyon hedefinin alt gereksinimlere ayrışması. Yörünge seçimi (irtifa, eğim, yerel güneş saati, güneş eşzamanlılık). Fırlatma aracı zarfı (kütle, hacim, ayrılma açısal hızı, mekanik arayüz). Faydalı yük çözünürlüğü ve tekrar geçiş. İşaretleme doğruluğu ve kararlılığı. Güç ve haberleşme bütçesi. | Requirements Toolbox Requirements Editor, ReqIF içe ve dışa aktarma, izlenebilirlik matrisi, bileşene tahsis, değişim etki analizi. |
Bir uydu projesi tek bir cümleyle başlar. Örnekteki en üst gereksinim şudur. Sistem, yer hedefinin görüntüsünü günde bir kez 10 metre çözünürlükte sağlar ve saklar. Geri kalan her gereksinim bu hedeften türer. Çözünürlük yörünge irtifasını sınırlar. Tekrar geçiş süresi yörünge eğimini ve düğümün yerel güneş saatini (LTAN) sınırlar. İşaretleme doğruluğu ise ADCS hata bütçesini doğrudan belirler ve aşağı doğru reaksiyon tekeri torkuna, algılayıcı gürültüsüne ve kestirim kovaryansına yansır.
Fırlatma aracı ve yörünge seçimi de birer gereksinimdir, bir varsayım değil. Fırlatma aracı kütle ve hacim zarfını, ayrılma anındaki açısal hız koşulunu ve mekanik arayüzü dayatır. Bunları metin gereksinimi olarak yazarsınız ve mimaride bileşenlere stereotip özelliği olarak (kütle, güç, nominal gerilim) bağlarsınız. Requirements Toolbox bu hiyerarşiyi Requirements Editor içinde kurar ya da ReqIF üzerinden DOORS gibi bir araçtan içe aktarır. Her gereksinim bir kimlik alır. O kimlik mimariye, davranış modeline ve test senaryosuna kadar çift yönlü izlenir. İzlenebilirlik bir biçimsellik değil. Bir gereksinim değiştiğinde hangi bileşenin ve hangi testin etkilendiğini tek bakışta gösterir.
💡 Dikkat.
Güneş eşzamanlı yörünge tam da J2 kaynaklı düğüm gerilemesine dayanır. Yani yörünge gereksinimini fiziksel olarak doğrulamadan sabitlerseniz, üçüncü adımda kullandığınız yörünge yayıcının bu etkiyi içerip içermediğini de denetlemeniz gerekir. Aksi halde kağıt üzerinde doğru, simülasyonda tutmayan bir yörüngeyle çalışırsınız.
Mimari
| TEORİ | Hangi toolboxları kullanabilirsiniz? |
| Sistemin ayrışması. Uzay segmenti, yer segmenti, fırlatma. Alt sistemler: faydalı yük, ADCS/GNC, güç (EPS), uçuş bilgisayarı, haberleşme, yapı, itki. Aynı işlevin farklı tasarım alternatifleri ve ticari analiz. | System Composer Bileşen, port, bağlayıcı, arayüz, stereotip, görünüm. Variant Component Tahsis için Requirements Toolbox. |
Gereksinimler ne istediğinizi söyler. Mimari sistemi parçalara böler ve her parçaya bir işlev atar. System Composer bunu bileşenler, portlar, bağlayıcılar ve arayüzlerle yapar. Bir port bileşenin çevresiyle etkileşim noktasıdır. Bir arayüz o porttan akan verinin türüdür. Simulink kullanıcıları için doğrudan bir köprü vardır. System Composer arayüzleri Simulink veri yolu (bus) tanımlarıyla aynıdır. Bir veri sözlüğündeki ACSOutBus gibi bir yapı arayüz olarak portlara atanır.
MathWorks örneği mimariyi INCOSE Uzay Sistemleri Çalışma Grubunun CubeSat Referans Modeline (CRM) dayandırır. Bu, sıfırdan başlamak yerine kabul görmüş bir ayrıştırmadan başlamanın örneğidir. Stereotipler her bileşene alana özgü veri ekler. Kütle, güç, maliyet, nominal gerilim. Stereotip paketleri profillerde tutulur ve bir temel stereotipten miras alır. Gereksinim tahsisi bu adımın çekirdeğidir. Requirements Manager içinde bir gereksinimi sürükleyip bileşene bırakırsınız. Implemented sütunu bağlantının kurulduğunu gösterir. Mantıksal ve fiziksel mimariler arasında ise model to model tahsis kurarsınız.
Variant: aynı işlev, farklı tasarım
Bir uydu tasarımı tek bir çözüm değildir. ADCS için üç eksen reaksiyon tekeri mi yoksa yalnızca manyetik tork çubuğu mu? Farklı yörünge ya da fırlatma yapılandırmaları? Variant Component tam bunun içindir. Bir bileşene birden çok tasarım alternatifi koyar ve aktif seçimi etiket ya da ifade kipiyle belirlersiniz. İfade kipinde bir kontrol değişkeni alternatifleri çalışma anında açıp kapatır ve etkinleştirme zamanını seçersiniz. Böylece ticari analizleri modeli yeniden kurmadan yaparsınız. Variant bileşenleri, ayrı gereksinim kümelerini karşılayan tasarım alternatiflerini tek mimaride taşır.
💡 Dikkat
Implemented sütunu yeşil göründü diye gereksinim karşılandı sanmak yaygın bir hatadır. O sütun yalnızca bir bağlantının varlığını söyler. Tasarımın gereksinimi sağladığını üçüncü adımdaki simülasyon ve dördüncü adımdaki test ve formal analiz gösterir.
Fonksiyonel Model
| TEORİ | Hangi toolboxları kullanabilirsiniz? |
| Katı cisim açısal dinamiği ve kuaterniyon kinematiği, yörünge yayılımı, çevresel bozucu torklar, eyleyici ve algılayıcı modelleri, kestirim filtresi, kontrolcü, mod mantığı, hata modeli. | Simulink · Aerospace Blockset · Simscape · Stateflow · Simulink Fault Analyzer |
Mimari iskelettir. Bu adımda iskelete davranış girer. System Composer Simulink üzerine kurulu olduğu için bir referans bileşeni doğrudan bir Simulink modeline bağlanır. Örnekte GNC alt sistemi üç model referansı içerir ve mimarideki arayüzler model içinde veri yolu sinyallerine eşlenir. İkinci adımda çizdiğiniz mimari burada çalışan modele dönüşür.
Uydu Dinamiği
Katı cismin açısal hareketi gövde çerçevesinde Euler denklemiyle yazılır. Yönelim ise kuaterniyon kinematiğiyle yayılır. Kuaterniyon, Euler açılarındaki tekillik sorununu (gimbal lock) taşımadığı için uçuş yazılımının standardıdır.
💡
I·ω̇ + ω × (I·ω) = T_kontrol + T_bozucu q̇ = ½ · q ⊗ [0, ω] I atalet tensörü, ω gövde açısal hızı, q gövdeden ataleğe kuaterniyon, T torklar.
Yörünge tarafında iki seçim vardır. Hızlı ve yaklaşık için iki cisim (Kepler) yayılımı, gerçekçi için zonal harmonikleri (J2, J3, J4) içeren sayısal yayılım. Aerospace Blockset bunu doğrudan verir. Spacecraft Dynamics bloğu hem yörüngeyi hem de dönme durumlarını birlikte yayar ve yönelim gösterimini seçmenize izin verir. Yalnızca yörünge için Orbit Propagator (Kepler) bloğu vardır. İşaretleme profili için Attitude Profile (Nadir Pointing) gibi hazır bloklar bulunur.
💡 Dikkat
Güneş eşzamanlı yörünge J2 kaynaklı düğüm gerilemesine dayanır. Pertürbasyonsuz Kepler yayıcı bu etkiyi yok sayar. SSO tasarımını doğrularken pertürbasyonsuz bloğu kullanmak, yörüngeyi güneş eşzamanlı yapan etkiyi gizler. Bu adımda doğru blok zonal harmonikli sayısal yayıcıdır.
Çevresel Model
Bozucu torklar dört ana kaynaktan gelir. Yerçekimi gradyanı atalet asimetrisinden doğar. Atmosferik sürükleme alçak yörüngede baskındır ve irtifa düştükçe büyür. Güneş radyasyon basıncı yüzey alanına ve basınç merkezi ile kütle merkezi arasındaki kaymaya bağlıdır. Artık manyetik dipol Dünya alanıyla etkileşir.
💡
T_gg = (3μ / R³) · (R̂ × I·R̂) T_m = m × B μ yerçekimi sabiti, R yörünge yarıçapı, R̂ nadir birim vektörü, m artık dipol, B manyetik alan vektörü.
Bu modeller için Aerospace Blockset yerçekimi, manyetik alan (IGRF ve WMM) ve atmosfer yoğunluğu bloklarını sağlar. Manyetik alan vektörü B yalnızca bir bozucu kaynağı değildir. Hem manyetometre ölçümünün hem de tork çubuğu kontrolünün temelidir.
Eyleyici Modeli
Reaksiyon tekeri açısal momentum depolar ve tork üretir. Gerçek tekerde tork sınırı, momentum doyması, kalkış sürtünmesi (stiction) ve nicemleme vardır. Tekerler doyduğunda momentumu boşaltmak gerekir ve bu boşaltma manyetik tork çubuğu ya da iticiyle yapılır. Tork çubuğu yalnızca B vektörüne dik yönde tork üretir, B boyunca tork üretemez. İtici kesiklidir ve bir en küçük itki darbesi (minimum impulse bit) vardır. Kontrol düzeyinde bu modeller Simulink içinde kurulur. Elektriksel ve mekanik sadakat gerektiğinde, örneğin motor sargısı, baranın gerilimi ve EPS’e binen güç çekişi modellenecekse, Simscape devreye girer. Simscape fiziksel ağ yaklaşımıyla çalışır ve denklemleri sizin yerinize kurar.
💡 Dikkat
Tekeri ideal bir tork kaynağı olarak modellemek doymayı ve sürtünmeyi gizler. Oysa işaretlemeyi bozan iki şey tam da bunlardır. Erken aşamada ideal model hız kazandırır. İşaretleme bütçesini doğrularken tork sınırı ve momentum boşaltma döngüsü modelde olmalıdır.
Dört tipik algılayıcının zayıf noktası farklıdır. Yıldız izleyici en doğru ölçümü verir ama yavaştır ve Güneş ya da Dünya albedosu körleştirebilir. Güneş algılayıcısı kaba ölçüm verir ve gölgede çalışmaz. Manyetometre ucuzdur ama gürültülüdür ve tork çubuğu çalışırken kirlenir. Jiroskop yüksek hızda ölçer ama kayma (bias) ve açısal yürüme biriktirir. Modelde gürültü, bias, açısal yürüme, hizalama hatası, nicemleme, gecikme ve güncelleme hızı bulunmalıdır.
Algılayıcı Modeli
💡 Dikkat
Tork çubuğu çalışırken alınan manyetometre ölçümü kirlidir. Algılama ve eyleme aynı anda yapılırsa kestirim bozulur. Bunu mod mantığında zamanlamayla çözersiniz. Önce ölç, sonra tork uygula.
Filtre Modeli (kestirim)
Yönelim belirleme iki aileye ayrılır. Belirleyici yöntemler (TRIAD, QUEST) iki ya da daha çok vektör gözleminden anlık yönelim çıkarır. Özyineli yöntemler jiroskopla durumu yayar ve vektör algılayıcılarla düzeltir. Tipik bir çarpımsal genişletilmiş Kalman filtresi (MEKF) çarpımsal hata kuaterniyonunu ve jiroskop bias’ını birlikte kestirir.
💡
x = [ δθ , b_g ]ᵀ δθ küçük açı hata vektörü, b_g jiroskop bias. Süreç gürültüsü açısal yürüme σ_v ve bias yürümesi σ_u ile ayarlanır. Düzeltme adımından sonra kovaryans sıfırlanır (reset).
Yakınsama keyfi değildir. İyi bir başlangıç yönelimi, ayarlanmış Q ve R kovaryansları ve gözlenebilirlik gerektirir. Gözlenebilirlik için eşdoğrusal olmayan en az iki vektör gözlemi gerekir. UKF, kuvvetli doğrusal olmayan rejimlerde alternatiftir.
💡 Dikkat
Gölge döneminde güneş algılayıcısı düşer ve geriye tek vektör (manyetometre) kalır. Tek vektör tam yönelimi gözleyemez. EKF bu pencerede sapabilir. Senaryolarınızda gölge geçişini mutlaka koşturun.
Kontrolcü
İki temel mod vardır. Ayrılma sonrası yüksek açısal hızı söndürmek için B-dot detumble kullanılır ve yalnızca manyetometre ile tork çubuğu ister. İşaretleme moduna geçince kuaterniyon geri beslemeli PD kontrolcü hedef yönelimi tutar. Bir momentum saturasyon döngüsü ise tekerdeki momentumu çapraz çarpım yasasıyla tork çubuğuna aktarır.
💡
m = −k · ḃ T = −K_p · sgn(q₀)·q_v − K_d · ω m_saturasyon = (1/‖B‖²) · (B × T_istenen) ḃ gövde çerçevesindeki manyetik alanın türevi, q_v hata kuaterniyonunun vektör kısmı, sgn(q₀) en kısa dönüşü seçer.
Mod Mantığı (Stateflow)
Yukarıdaki blokları kim yönetir? Bir denetleyici durum makinesi. Stateflow sonlu durum makineleriyle bu denetimi kurar. Tipik akış şudur. Detumble, ardından Güvenli ve Güneşe işaretleme, ardından İnce işaretleme ve Görüntüleme, ardından Momentum boşaltma. Geçişler koşullara bağlıdır. Açısal hız eşiği, gölge bayrağı, hedef görünürlüğü, teker momentum eşiği ve hata bayrakları. Stateflow burada hem zamanlayıcı hem de arıza tespit ve kurtarma (FDIR) mantığının yaşadığı yerdir.
Hata Modeli (Simulink Fault Analyzer)
Simulink Fault Analyzer hataları tasarımı değiştirmeden enjekte eder. Algılayıcı takılması (stuck at), bias kayması, eklenen gürültü, sinyal gecikmesi, veri kaybı ya da teker arızası gibi davranışları modele dışarıdan ekler. Tetikleme zamanlı, koşullu ya da elle olur. Hataları Simulink, Simscape ve System Composer genelinde yönetir. Etkileri Simulation Data Inspector ile incelersiniz. Multiple Simulations paneliyle hata duyarlılığı analizi yaparsınız. Safety Analysis Manager ile FMEA ve FHA gibi güvenlik analizlerini yürütür, hataları tehlikelere, tespit ve azaltma mantığına ve gereksinimlere bağlarsınız. Ürün R2023b ile geldi. Bu, döngüyü kapatan adımdır. Burada enjekte ettiğiniz bir hata, bir sonraki adımda FDIR mantığınızın o hatayı yakaladığını kanıtlayan bir test senaryosuna dönüşür.
Doğrulama ve V&V
| TEORİ | Hangi toolboxları kullanabilirsiniz? |
| Gereksinim temelli test. Birim, regresyon, sırt sırta (back to back) test. Yapısal kapsam (karar, koşul, MCDC, ilişkisel sınır). Formal analiz: tasarım hatası tespiti ve özellik ispatı. Modelleme standardı uyumu ve metrikler. Misyon düzeyinde geçerleme. | Simulink Test · Simulink Coverage · Simulink Design Verifier · Simulink Check |
Modeli kurdunuz. Şimdi gereksinimleri karşıladığını göstermeniz gerekir. Simulink Test bunu sistematik ve tekrarlanabilir biçimde yapar. Test Manager testleri yönetir ve koşar. Test Sequence bloğu karmaşık senaryolar ve değerlendirme ölçütleri kurar. Koşum kabini (test harness) test edilen bileşeni yalıtır ve modele müdahale etmez. Değerlendirmeleri metin tabanlı bir dille yazar, beklenen çıktıları ve toleransları belirlersiniz. Testleri birinci adımdaki gereksinim kimliklerine bağlarsınız. Sağlamlık için parsim ile yüzlerce koşumu paralel çalıştırır, başlangıç hızı, atalet belirsizliği ve algılayıcı gürültü tohumları üzerinde Monte Carlo dağılım taraması yaparsınız. Aynı testler SIL, PIL ve donanım döngüde (HIL) kiplerde de koşar. Modelinizi Speedgoat gibi gerçek zamanlı bir hedefe taşıdığınızda test takımınız sizinle gelir.
Yapısal Kapsam (Simulink Coverage)
Test geçti demek yeterli test yaptınız demek değildir. Simulink Coverage testin ne kadarını gerçekten çalıştırdığınızı ölçer. Endüstri standardı metrikleri uygular. Karar, koşul, değiştirilmiş koşul ve karar (MCDC), ilişkisel sınır, sinyal aralığı ve arama tablosu kapsamı. Birden çok koşumun kapsamını biriktirir (cumulative coverage) ve birim testlerden gelen kapsamı sistem testi düzeyinde toplar. Kapsamı bağlı gereksinimlere göre kapsayarak istenmeyen kapsamı dışarıda tutarsınız. Eksik kapsam yalnızca test boşluğunu değil, eksik gereksinimi ya da istenmeyen işlevi de açığa çıkarır. Embedded Coder ile üretilen kod için SIL ve PIL kipinde kod kapsamı da ölçülür. MCDC, DO-178C ve DO-331 tanımına göre raporlanır.
💡 Dikkat
. 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 ayırır ve gerekçesini kayıt altına alırsınız.
Formal Analiz (Simulink Design Verifier)
Simulink Design Verifier formal yöntemler (SAT ve SMT çözücüleri) kullanır ve simülasyonun gözden kaçırdığı hataları açığa çıkarır. Üç işi vardır. Birincisi tasarım hatası tespiti. Tamsayı taşması, sıfıra bölme, ölü mantık (dead logic) ve dizi sınırı ihlali gibi hataları modelde arar. İkincisi özellik ispatı. Bir güvenlik ya da gereksinim özelliğini biçimsel olarak ispatlar ya da onu ihlal eden bir karşı örnek üretir. Üçüncüsü otomatik test üretimi. Karar, koşul, MCDC ve özel hedefleri karşılayan test senaryolarını otomatik üretir. Böylece elle yazılmış testlerin kapatamadığı kapsam boşluklarını kapatır. Her ihlal ve her hedef için hata ayıklamaya yarayan bir simülasyon test senaryosu üretir. Falsifikasyon ile ispat arasındaki fark önemlidir. Bir test bir hatayı gösterebilir. Formal ispat ise bir özelliğin tüm girdi uzayında tuttuğunu söyler.
Standart Uyumu ve Metrikler (Simulink Check)
Simulink Check modeli, gereksinimleri ve testleri standartlara karşı denetler. MathWorks Advisory Board (MAB) stil kılavuzunu ve yüksek bütünlüklü yazılım standartlarını (DO-178C, DO-254, ISO 26262, IEC 61508) uygular. Denetimler düzenleme anında (edit time) çalışır, böylece ihlali tasarım sırasında yakalarsınız. Boyut ve karmaşıklık gibi metrikleri (siklomatik karmaşıklık) raporlar. Model Testing Dashboard ise gereksinim temelli test durumunu tek panoda toplar. Bağlı gereksinimler, test sonuçları ve kapsam birlikte görünür. İzlenebilirliğin tamlığını ve doğrulama kanıtını burada izlersiniz. Kendi kurum standartlarınız için özel denetimler de yazarsınız.
Dört araç birlikte bir döngü kurar. Check modelleme sırasında standardı dayatır. Test gereksinim temelli senaryoları koşar. Coverage tamlığı ölçer. Design Verifier özellikleri ispatlar ve boşluklar için test üretir. Model Testing Dashboard kanıtı toplar. Sertifikasyon kapsamında bu araçları kullandığınızda DO Qualification Kit ile araç niteliğini (tool qualification, TQL) sağlarsınız. Üçüncü adımda enjekte ettiğiniz hata senaryoları ise burada FDIR doğrulama testlerine dönüşür.
💡 Dikkat
Misyon testinin geçmesi tek başına geçerleme değildir. MathWorks örneği bunu açıkça söyler. Bu test erken aşamada yörünge seçiminin makul olduğunu teyit eder, kapsamlı bir doğrulama değildir. Geçen bir test yalnızca o senaryonun o simülasyon penceresinde tuttuğunu gösterir.
Sınırlar ve Sonraki Adım
Buraya kadar kurulan zincir kâğıt üzerinde tutarlıdır. Pratikteki asıl gerilim, sadakat ile koşum süresi arasındaki dengede (fidelity-runtime tradeoff) ortaya çıkar. Motor elektriksel dinamiğini, bara gerilimini ve sürtünmeyi içeren tam bir Simscape eyleyici modeli, çözücüye katılık (stiffness) getirir ve değişken adımlı çözücünün adım maliyetini artırır. Buna pertürbasyonlu çevre (J2 ve daha yüksek zonal harmonikler, yoğunluk modeline bağlı sürükleme, güneş radyasyon basıncı) ile atalet belirsizliği, algılayıcı gürültü tohumları ve başlangıç açısal hızı üzerinde binlerce Monte Carlo koşumu eklendiğinde, hesap yükü tek bir masaüstü oturumunda taşınamaz hâle gelir. Bu yükü paralel koşum (parsim) ve hızlandırılmış kip (accelerator) bir ölçüde azaltır.
Bazı etkiler bu döngünün doğal olarak dışında kalır. Esnek gövde modları (flexible body modes), güneş paneli ve antenler gibi eklentilerin yapısal titreşimini kontrolcü bant genişliğiyle kuplajlar ve katı cisim varsayımını geçersiz kılar. Termal kuplaj (thermal coupling), yapısal eğilme ve algılayıcı hizası üzerinde yavaş ama ölçülebilir bir kayma yaratır. Yıldız izleyicinin ayrıntılı optik ve radyometrik modeli (saçılan ışık, gürültü eşdeğeri açı) ise ayrı bir simülasyon alanıdır. Bu etkiler tek bir Simulink modeline sığmaz ve ortak simülasyon (co-simulation) ya da donanım döngüde test (hardware-in-the-loop, HIL) gerektirir.
Nerede durup sadakat eklemeyi kesmek gerektiği bir araç ayarı değil, doğrulanan gereksinime bağlı bir mühendislik kararıdır. İşaretleme doğruluğu bütçesini doğrulamak için eyleyici doyması ve algılayıcı gürültüsü modelde bulunmalıdır. Termal sürüklenmeyi doğrulamak için ise ayrı bir analiz alanı gerekir.
Model gerçek donanıma HIL aşamasında bağlanır. Speedgoat gerçek zamanlı hedef üzerinde uçuş yazılımı döngüde koşar, gerçek giriş çıkış (RS-485, algılayıcı öykünmesi) bağlanır ve model sabit bir örnekleme periyoduna (sample time) zorlanır. Masaüstünde gizli kalan zamanlama varsayımları burada açığa çıkar. Gerçek zamanlı aşım (real-time overrun), giriş çıkış gecikmesi ve çözücü bütçesi ancak gerçek bir saat altında ölçülür. Sonraki adım budur ve varsayımların gerçek zamana karşı sınandığı yer de orasıdır.
Sonuç
Gereksinimden doğrulamaya uzanan bu zincir, bir uydu sisteminin mühendislik karmaşıklığını tek bir model çatısı altında yönetmenin mümkün olduğunu gösteriyor. Requirements Toolbox’tan Simulink Design Verifier’a kadar kullandığımız her araç, bir önceki adımın çıktısını girdi olarak alıyor, bu da hata yayılımını minimuma indiriyor ve ECSS-E-ST-40 Cgibi standartların gerektirdiği iz sürülebilirliği otomatik olarak sağlıyor. Esnek gövde modları, termal kuplaj ve gerçek zamanlı HIL doğrulaması bu makalenin kapsamı dışında kaldı; bunları ilerleyen yazılarda ele alacağız. Bu aşamada anlatılan zinciri kendi projenize uyarlamak veya araçlar hakkında teknik destek almak istiyorsanız bizimle iletişime geçin.