İki olayda da sistem geç kaldı; ama birinde bedeli bir homurtu, diğerinde bir hayat. Gerçek zamanlı sistemler (real-time systems) kavramı tam da bu farkın üzerine kuruludur. İşin teknik tanımı da bunu söyler: gerçek zamanlılık, bir sistemin her bağımsız işlevi için tanımlanmış zaman sınırına uyma kabiliyetidir. Bir fonksiyonu doğru yerine getirmek kadar, onu istenen zaman çerçevesinde yerine getirmek de gerekir; gerçek zamanlılık bu ikincisini dert edinir. Geç gelen doğru yanıt çoğu zaman yanlış yanıttır.

Gerçek Zamanlı, Hızlı Demek Değil​

Önce en sık yapılan hatayı dağıtalım: gerçek zamanlı sistem; hızlı, çok hızlı, inanılmaz hızlı sistem demek değildir. Saniyede milyarlarca işlem yapan bir sunucu gerçek zamanlı olmayabilir; saniyede yüz işlem yapan ufak bir mikrodenetleyici kusursuz biçimde gerçek zamanlı olabilir.

Fark hızda değil, determinizmde (öngörülebilirlik). Bir durum ve giriş kümesine karşı sistemin doğru yanıtı doğru zaman çerçevesi içinde üretmesi ne kadar öngörülebilirse, sistem o kadar deterministiktir. Buradaki anahtar, ortalama değil en kötü durumdur: bir işlem çoğu zaman 1 ms'de bitip nadiren 100 ms'ye çıkıyorsa, ortalaması ne kadar iyi olursa olsun o sistem güvenilmezdir. Çünkü sizi vuran şey ortalama değil, o ender görülen en kötü andır.

Üç kavram işin sözlüğünü oluşturur:

• Zaman sınırı (deadline): İşin tamamlanmış olması gereken an.
• Gecikme (latency): Bir olay ile sistemin ona verdiği yanıt arasındaki süre.
• Seğirme (jitter): Bu gecikmenin ölçümden ölçüme ne kadar oynadığı. Her döngüde tam 10 ms'de yanıt veren bir sistem iyidir; bazen 8 bazen 14 ms diyen sistem kötüdür. Kontrol döngülerinde seğirme çoğu zaman ham hızdan daha kıymetlidir.

Bir sistem bu öngörülebilirliği ne kadar çok talep ediyorsa, aşağıdaki sınıflandırmada o kadar katı uca düşer.

Sınıflar: Mutlak, Katı, Esnek, Gerçek Zamanlı Olmayan​

Sınıfları birbirinden ayıran soru tektir: bir yanıt tanımlı zamandan sonra gelirse ne olur? Cevap, hem sistemin gerçek zamanlılık sınıfını hem de ondan beklenen determinizm seviyesini belirler.

Soldan sağa zaman sınırının sertliği azalır; ters yönde, sağdan sola talep edilen determinizm seviyesi artar. En yüksek öngörülebilirlik en solda, mutlak uçta gerekir.

Mutlak (Hard) Gerçek Zamanlı​

En tavizsiz uç. Yanıtların hep tanımlı zamandan önce gelmesi gerekir; herhangi bir yanıtın geç gelmesi kabul edilemez ve bütün sistemi başarısız kılar. Burada "geç gelen doğru yanıt" yalnızca yararsız değil, tehlikelidir. En yüksek determinizm bu uçta talep edilir.

Tipik örnekler: otomotiv güvenlik sistemleri (ABS, hava yastığı, ESP), yaşam destek amaçlı tıbbi cihazlar (kalp pili, solunum destek sistemleri) ve insansız hava aracı (İHA) otopilotu. Hava yastığı milisaniyeler içinde açılmazsa hiç açılmamış sayılır.

Katı (Firm) Gerçek Zamanlı​

Bir adım gevşemiştir. Yanıt yalnızca nadiren tanımlı zamandan sonra gelebilir. Geç gelen yanıt artık faydasızdır, atılır; ama bu sistemi yıkmaz, etkisi hizmet kalitesinin düşmesidir. Mutlak uçtan farkı, gecikmiş yanıtın bedelinin sıfır olması, negatif olmamasıdır.

Tipik örnekler: insansız kara aracı otopilotu, insansız seri üretim tezgâhları ve robotik otomasyon. Aynı otopilotun havada mutlak, karada katı olması anlamlıdır: karadaki araç durdurulabilir, geç gelen bir komutun bedeli genellikle ölümcül değildir.

Esnek (Soft) Gerçek Zamanlı​

Burada zaman sınırı keskin bir uçurum değil, yumuşak bir yokuştur. Yanıtların gecikmesi daha sık görülür; geç gelen yanıt hâlâ işe yarar, ama tanımlı zamandan uzaklaştıkça faydası azalır. Etkisi yine hizmet kalitesinin düşmesidir.

Tipik örnekler: sesli/görüntülü bilgi ve eğlence akış sistemleri (TV, radyo, video oyunları), iletişim sistemleri (telefon, telekonferans, görüntülü görüşme) ve konfora dönük ev otomasyonu. Bir görüntülü görüşmede karenin biraz geç gelmesi rahatsız edicidir ama yıkıcı değildir.

Gerçek Zamanlı Olmayan (Non-Real-Time)​

En gevşek uç. Yanıtlar için tanımlı bir zaman yoktur; yanıt ne zaman gelirse gelsin faydalıdır ve sistemin hizmet kalitesi yanıt sürelerinden etkilenmez.

Tipik örnekler: ödeme sistemleri (POS cihazları), endüstriyel otomasyon izleme sistemleri ve yığın (batch) işlem sistemleri (rapor/veri/kayıt üretimi, çevrim dışı sinyal analizi). Bunların mühendislik anlamında tanımlı bir zaman sınırı yoktur.

Hepsi Bir Arada​

Önemli bir nokta: bu sınıflar koca bir cihazı bütün olarak değil, sistemin her bağımsız işlevini ayrı ayrı etiketler. Aynı İHA'nın içinde uçuş kontrolü mutlak (hard), telemetri akışı esnek (soft), uçuş sonrası kayıt indirme ise gerçek zamanlı olmayan bir işlev olabilir. Doğru soru "bu sistem hangi sınıf?" değil, "bu işlevin zaman sınırı kaçarsa ne olur?"dur.

Garantiyi Nasıl Veriyoruz?​

Madem hız değil, bir işlevi gerçek zamanlı yapan ne? Tek kelimeyle garanti: en kötü senaryoda bile zaman sınırına uyacağını önceden kanıtlayabilmek. Bu birkaç araca dayanır.

WCET (en kötü durum yürütme süresi, worst-case execution time). Mühendis ortalamayla değil bu en kötü değerle çalışır; çünkü garanti ancak en kötü duruma göre verilebilir. Bu yüzden önbellek (cache) ve dallanma tahmini gibi "ortalamayı iyileştiren ama en kötü durumu öngörülemez kılan" mekanizmalar gerçek zamanlı tasarımda göze batar. Performans burada yalnızca fonksiyonel olmayan bir gereksinim (non-functional requirement) değil, doğruluğun ayrılmaz bir parçasıdır.

RTOS. Masaüstü Linux ya da Windows verimi ve adilliği önceler; bir görevin tam olarak ne zaman çalışacağını garanti etmez. Bir gerçek zamanlı işletim sistemi (real-time operating system, RTOS) — FreeRTOS, VxWorks, QNX, Zephyr ya da PREEMPT_RT özellikli Linux (uzun yıllar ayrı bir yama setiydi; Linux 6.12'den beri ana akım çekirdeğin bir parçası) — ise öngörülebilirliği öne koyar: en yüksek öncelikli görevin sınırlı ve bilinen bir süre içinde işlemciye kavuşacağını taahhüt eder. RTOS'un emniyet-kritik aviyonik projelerdeki yeri için kitaptaki Gerçek Zamanlı İşletim Sistemleri bölümüne, sertifikasyon gözüyle dikkat edilecek noktalar için de Ek B'deki endişe alanları listesine bakabilirsiniz.

Zamanlama. Görevlere öncelik verilir; öncelikli bir görev hazır olunca, çalışan düşük öncelikli görev anında durdurulur (preemption). Hangi görevin ne zaman çalışacağına karar veren kurala zamanlama algoritması (scheduling algorithm) denir. İki klasiği: RMS (Rate-Monotonic Scheduling), daha sık tekrarlanan görevi daha öncelikli sayar; EDF (Earliest Deadline First), zaman sınırı en yakın olanı önce çalıştırır. Bu algoritmaların matematiksel "zamanlanabilirlik" ispatları başlı başına bir konudur.

Mars'taki Hata: Öncelik Tersinmesi​

Bu mekanizmaların ne kadar ince olduğunu en iyi anlatan hikâye, NASA'nın 1997'de Mars'a indirdiği Pathfinder aracından gelir. Araç yüzeye indikten birkaç gün sonra, meteoroloji verisi toplamaya başlamasının hemen ardından bilgisayarı tekrar tekrar yeniden başlar; milyonlarca kilometre öteden ayıklanması gereken bir kâbus.

Suçlu, gerçek zamanlı sistemlerin meşhur tuzağı öncelik tersinmesidir (priority inversion). Yüksek öncelikli bir görev, düşük öncelikli bir görevin tuttuğu paylaşılan bir kaynağı bekler. Tam o sırada araya giren orta öncelikli ve uzun süren bir görev, düşük öncelikli görevin çalışmasını engeller. Sonuçta yüksek öncelikli görev, kendisinden önemsiz bir göreve dolaylı yoldan takılıp kalır; öncelikler sanki tersine dönmüştür. Çözüm öncelik miras almadır (priority inheritance): paylaşılan kaynağı tutan düşük öncelikli görev, onu bırakana dek geçici olarak yüksek önceliğe terfi ettirilir. Pathfinder ekibi bu özelliği uzaktan etkinleştirip aracı kurtardı.

Pathfinder'ın hatırlattığı şey şu: gerçek zamanlı sistemlerde hatalar çoğu zaman bileşenlerin içinde değil, paylaştıkları kaynaklarda ve aralarındaki etkileşimde saklanır; bağlaşımı (coupling) düşük tutma öğüdünün gerçek zamanlı dünyadaki karşılığı budur.

Tek Eksen Değil​

Mutlak/katı/esnek ayrımı sistemleri tek bir eksende dizer: zaman sınırı kaçarsa ne olur? Oysa gerçek zamanlı sistemler başka eksenlerde de ayrışır. Görevler saatin yönettiği önceden belirlenmiş bir çizelgeye göre mi tetikleniyor (zaman tetiklemeli, time-triggered), yoksa dış olaylar geldikçe mi (olay tetiklemeli, event-triggered)? Emniyet-kritik tasarım, öngörülebilirlik uğruna çoğu zaman ilkini seçer. Garanti tek bir bilgisayarda mı kalıyor, yoksa ağ üzerinden mi taşınıyor? Sıradan Ethernet "elinden geldiğince" (best-effort) çalıştığından, yani her paketi taşıdığı hâlde zamanında teslimi garanti etmediğinden, otomotivde CAN ve FlexRay, aviyonikte AFDX/ARINC 664, yeni sistemlerde TSN gibi gerçek zamanlı ağlar bu yükü üstlenir. Bir de modern eğilim: farklı kritiklikteki işlevleri aynı donanımda koşturmak (mixed-criticality). Aviyonikte bunun çözümü ARINC 653'ün getirdiği zaman ve uzay bölümlemesidir; önemsiz bir işlevdeki hata, hayati komşusuna sıçrayamasın diye. Bu, emniyet-kritik yazılım disiplininin gerçek zamanlılıkla buluştuğu noktadır.

Sonuç​

İyi mühendis bir işlevle karşılaştığında "bunu ne kadar hızlı yaparım?" diye değil, önce şunu sorar: bunun tanımlı bir zaman sınırı var mı, kaçırırsam ne olur? Felaket mi (mutlak/hard), faydasız bir yanıt mı (katı/firm), geciktikçe azalan bir fayda mı (esnek/soft), yoksa hiçbir şey mi (gerçek zamanlı olmayan)? Cevap; işletim sistemini, zamanlamayı, ağı ve gereken titizliği belirler.

Bir uyarı da yerinde olur: günlük dilde "real-time analytics", "canlı pano", "anlık bildirim" diye geçen şeylerin neredeyse tamamı, bu mühendislik anlamıyla en fazla esnek (soft) düzeydedir; birkaç saniyelik gecikme kimseyi incitmez. Gerçek bir mutlak (hard) sistemde ise milisaniyeler sayılır ve zaman sınırını kaçırmanın bedeli ölçülebilir bir felakettir. Sonuçta gerçek zamanlılığı belirleyen şey, sistemin iyi günlerde ne kadar hızlı olduğu değil, en kötü gününde bile sözünü tutacağına dair verebildiği garantidir.

Kaynaklar​

• C. L. Liu, James W. Layland — "Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment," Journal of the ACM, vol. 20, no. 1, 1973. DOI: 10.1145/321738.321743.
• Giorgio C. Buttazzo — Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications (Springer).
• Hermann Kopetz — Real-Time Systems: Design Principles for Distributed Embedded Applications (Springer).
• Mike Jones — "What Really Happened on Mars?" (Mars Pathfinder öncelik tersinmesi olayının, Wind River CTO'su David Wilner'ın bir konuşmasına dayanan anlatımı).
• ARINC 653 — Avionics Application Software Standard Interface (zaman ve uzay bölümlemesi); genel bakış: ARINC 653 (Wikipedia).
• The Linux Foundation — Real-Time Linux (PREEMPT_RT).

Yapısal kapsam analizi (structural coverage analysis) ya da bilindik kisa adiyla SCA'yi incelemeden once yapisal programlamanin ne oldugunu tekrar hatirlayalim.  

Bu yazıyı okurken, Yazılım Doğrulama bölümündeki kapsam yaklaşımı ve Kapsanmayan Kodlar bölümündeki kod türleriyle birlikte düşünmek faydalıdır.

Yapısal Programlama (Structured Programming) nedir?​

Yapısal programlama, 1960'larda, bilgisayar biliminde programların daha anlaşılır, daha etkili ve hata yapma olasılığı daha düşük bir şekilde yazılabilmesi için geliştirilen bir programlama paradigmasıdır. Yapısal programlama, büyük ve karmaşık yazılım sistemlerinin geliştirilmesinde önemli bir dönüm noktası olmuştur. Bu yaklaşımın temelleri, Edsger W. Dijkstra'nın 1968'de yayınladığı "Go To Statement Considered Harmful" (Goto Deyimi Zararlıdır)[1] başlıklı makalesiyle atılmıştır. Dijkstra, bu makalesinde, program akışının kontrolünü sağlamak için "goto" deyiminin kullanımına karşı çıkarak daha düzenli ve modüler programlama tekniklerinin benimsenmesi gerektiğini savunmuştur.

Yapısal programlama, programları anlaşılır bir şekilde modüllere ayırma, tekrar kullanılabilir kod blokları(fonksiyonlar) oluşturma ve program akışını kontrol etmek için sıralı, seçim (if/else) ve yineleme (döngüler) yapılarını kullanma prensiplerine dayanır. Bu yaklaşım, programların daha kolay anlaşılır, test edilir ve bakımı yapılır hale gelmesine yardımcı olmuştur.

Yapısal kapsama analizi (structural coverage analysis) nedir?​

Yapısal kapsama analizi, özellikle havacılık ve uzay mühendisliğinde, bir yazılımın test sürecinde kullanılan bir tekniktir. Bu teknik, yazılımın test edilmesi sırasında kodun hangi bölümlerinin çalıştırıldığını ve hangi bölümlerinin çalıştırılmadığını belirlemek için kullanılır. Yapısal kapsam analizi, yazılımın farklı bölümlerinin yeterince test edilip edilmediğini kontrol etmek amacıyla kullanılan bir dizi metriği içerir. Bu analiz, yazılımın güvenilirliğini ve kalitesini artırmak için önemlidir.

Havacılık ve uzay endüstrisinde, yapısal kapsam analizi özellikle kritik öneme sahiptir çünkü bu alanlarda kullanılan sistemlerin yüksek güvenilirlik ve güvenlik standartlarına uygun olması gerekir. Bu nedenle, yazılımın her bir satırının, şartının veya karar noktasının test edilmesi gerekebilir.

Yapısal kapsam analizinin temel türleri şunlardır:

1. Satır Kapsama (Statement Coverage): Yazılımın her bir satırının en az bir kez çalıştırılıp çalıştırılmadığını kontrol eder. Bu, en temel kapsam analizi türüdür.
2. Karar Kapsama (Decision Coverage): Yazılım içerisindeki her bir karar noktasının (if-else blokları gibi) tüm olası çıktılarının test edilip edilmediğini kontrol eder.
3. Kosul Kapsama (Condition Coverage): Karar noktalarındaki her bir kosulun tüm olası değerlerinin test edilip edilmediğini kontrol eder.
4. Kosul/Karar Kapsama (Condition/Decision Coverage): Hem karar kapsamını hem de kosul kapsamını bir araya getirerek, karar noktalarının ve içerdikleri kosuların tüm olası kombinasyonlarının test edilmesini sağlar.
5. Degistirilmis Kosul/Karar Kapsama (Modified Condition/Decision Coverage, MC/DC): MC/DC, belirli bir kararın sonucu üzerinde her bir koşulun bağımsız etkisini doğrulamayı amaçlar. Bu, hem her giriş ve çıkış noktasının en az bir kez çağrıldığından hem de programdaki bir karardaki her koşulun en az bir kez tüm olası sonuçları aldığından emin olmayı içerir. Daha da önemlisi, her bir koşulun, diğer tüm olası koşullar sabit tutulurken, karar sonucunu bağımsız olarak etkilediği gösterilir. n+1 test senaryosu gerektirir.
6. Coklu kosul kapsama: Olasi butun kosul kombinasyonlarinin test edildigini dogrular. Gerekli senaryo sayisi: 2n

Basit bir örnek​

if ((motor_calisti && yakit_basinci) || yedek_mod) {
  ucusa_devam_et();
} else {
  guvenli_kapat();
}

Bu küçük örnekte:

• Satır kapsama, her iki dalın da en az bir kez çalıştırılmasını ister.
• Karar kapsama, hem true hem false sonucunun görülmesini ister.
• Koşul kapsama, motor_calisti, yakit_basinci ve yedek_mod koşullarının değerlerini tek tek değiştirerek etkisini ölçer.
• MC/DC, her koşulun karar sonucunu bağımsız biçimde etkilediğini gösteren en az sayıda testi arar.

Bu nedenle yapısal kapsam analizi, "kaç satır çalıştı" sorusundan daha fazlasını sorar; mantığın gerçekten kontrol edildiğini kanıtlamaya yaklaşır.

Uzerinde calsitiginiz projenin DAL seviyesine gore DO178C Table A7'den saglamaniz gereken SCA tipini kontrol edebirlisiniz. DAL A seviyesi aviyonik yazilimlar icin her 3 tip kapasama analizi de bagimsiz ekip tarafindan yapilmasi gerekiyor. 

Yapisal kapsama analizinin yazilim dogrulamasina sagladiklari:

1. Tüm kodun en az bir kez çalıştırıldığını garanti eder: Yapısal kapsam, test sırasında kod tabanının her satırının çalıştırılmasını gerektirerek, kodun hiçbir bölümünün test edilmemiş bırakılmadığını sağlar. Bu, her kod satırının sistem operasyonunun güvenliğini etkileyebileceği güvenlik kritik sistemlerde hayati öneme sahiptir.
2. İstenmeyen işlevselliği ve test edilmemiş işlevselliği bulur: Kod tabanının kapsamlı bir şekilde çalıştırılmasıyla, testçiler başlangıçta amaçlanmayan veya yetersiz test nedeniyle önceden tanımlanamayan işlevselliği ortaya çıkarabilir. Bu, farklı operasyonel senaryolar altında sistem davranışı ile ilgili beklenmeyen riskleri azaltmaya yardımcı olur.
3. Ölü kodu veya gereksiz kodu tanımlar: Ölü kod, herhangi bir operasyonel senaryoda çalıştırılmayan kod segmentlerini ifade eder. Bu tür kodu tanımlamak önemlidir çünkü yazılımın verimliliğini düşürebilir, boyutunu gereksiz yere artırabilir ve tespit edilmemiş güvenlik açıklarına yol açabilir.
4. Devre dışı bırakılan kodun gerçekten devre dışı bırakıldığını doğrular: Bazen, çeşitli nedenlerle kod devre dışı bırakılır ancak kaldırılmaz. Yapısal kapsam, bu kodun mevcut yazılım yapılandırmasında çalıştırılamayacağını doğrulayarak, varlığının sistemin operasyonunu etkilemediğinden emin olmamıza yardımcı olur.
5. Test için minimal kombinasyon setini tanımlar (yani, exhaustive test gerektirmez): Yapısal kapsam, tüm kodu kapsayan ancak kaynak ve zaman kısıtlamaları nedeniyle tüm olası girdi kombinasyonlarının tüketici testinin pratik olmadığı karmaşık sistemlerde, yeterli ancak minimal bir test vakası seti belirlemeye yardımcı olur.
6. Yanlış mantığı belirler: Kodun her parçasının çalıştırılmasını sağlayarak, testçiler yazılımın çeşitli koşullar ve girdiler altında beklenen gibi davrandığını doğrulayabilir. Bu, yazılımın mantıksal doğruluğunu kontrol etmeyi içerir.
7. Test çabasının ne kadar tamamlandigi hakkinda ongoru saglar: Yapısal kapsam, yazılımın ne kadar kapsamlı test edildiğinin nicel bir ölçüsünü sağlar. Önemli bir metrik olmasına rağmen, %100 yapısal kapsama ulaşmak hata olmadığını garanti etmez. Ayrıca, yazılımın anormal veya beklenmedik koşullar altındaki davranışını tam olarak ele almaz, bu tipik olarak sağlamlık testi ile değerlendirilir.

Havacılık ve uzay alanında, başarısızlığın maliyeti olağanüstü yüksek olduğunda, yazılım doğrulama ve onaylama sürecinin bir parçası olarak yapısal kapsamın kullanılması vazgeçilmezdir. Uçuş operasyonlarını kontrol eden veya destekleyen yazılımın güvenilir, güvenli olduğunu ve tüm beklenen koşullar altında amaçlandığı gibi performans gösterdiğinden emin olunur.

Kaynakca​

[1]  Edsger Dijkstra (March 1968). "Go To Statement Considered Harmful" (PDF). Communications of the ACM. 11 (3): 147–148. 

[2] A Practical Tutorial on Modified Condition/ Decision Coverage, https://shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm210876-MCDC.pdf  

[3] Comments on Modified Condition/Decision Coverage for Software Testing, https://doi.org/10.1109/aero.2001.931302  [4] John Joseph Chilenski and Steven P. Miller, "Applicability of Modified Condition/Decision Coverage to Software Testing", Software Engineering Journal, September 1994. https://doi.org/10.1049/sej.1994.0025 

[5] A PRACTICAL APPROACH TO MODIFIED CONDITION/DECISION COVERAGE, https://ntrs.nasa.gov/api/citations/20040086014/downloads/20040086014.pdf

Yapısal kapsama analizi(Structural Coverage Analysis - SCA) , yazılım test süreçlerinde hayati role sahip bir yöntemdir. Bu analiz, yazılımın kod kapsamını değerlendirerek hangi kod bölümlerinin testler sırasında çalıştırıldığını veya çalıştırılmadığını belirlemeye yardımcı olur. Ana hedef, yazılımın her bir satırının (statement), dalının (branch) ve koşulunun (condition) uygun şekilde test edilip edilmediğini kontrol etmektir.

Bu konu özellikle Yazılım Doğrulama ve Kapsanmayan Kodlar bölümleriyle birlikte okunursa, hangi kodun neden kapsanmadığı daha net görünür.

Kapsama verisi toplama sürecinde, yapısal kapsama analiz aracı önemli bir rol oynar. İlk olarak, bu araçlar kaynak koda enstrümantasyon adı verilen ek kod parçalarını ekler. Bu ekleme, gereksinim tabanlı testler sırasında hangi kod parçalarının kullanıldığını takip etmek için yapılır. Test sırasında toplanan kapsama verisi, daha sonra yapısal kapsama analiz araçları tarafından incelenir. Bu inceleme sonucunda, testlerde kullanılmayan yani 'kapsanmamış' kod satırları tespit edilir ve bir kapsama analizi raporu oluşturulur.

Bu analiz sonucunda, bazı kodların kapsanmadığı görülebilir. Aşağıdaki yazılimda, bu tür kodlara ait bazı örnekler sunulmuştur. Bu kodlar üç kategoriye ayrılabilir.

Ölü Kod (Dead Code)​

Ölü kod, yazılımın normal akışı içinde hiçbir zaman çalıştırılmayan kod bölümleridir. Genellikle yazılımın eski sürümlerinden kalan, artık kullanılmayan veya yanlış tanimlanmis koşullu blokları içeren kodlardır. Yapısal kapsama analizinde, ölü kod testler sırasında hiç çalıştırılmaz, çünkü bu kodun çalışması için gerekli koşullar asla sağlanamaz. Yapısal kapsama analiziyle bu kodlar kolayca tespit edilir ve kaldırılır. Ayrıca, çeşitli derleyiciler, statik kod analiz araçları [3] ve IDE'ler bu tür kodlama hatalarını belirleyerek uyarıda bulunur.

GNU C Compiler (GCC) için, aşağıda belirtilen derleyici parametrelerini projenize ekleyerek geliştirme aşamasında ölü kodları tespit edebilirsiniz[2]:

 -Wunreachable-code

Gereksiz Kod (Extraneous Code)​

Gereksiz kod, yazılımın işlevselliği için zorunlu olmayan, ancak çalıştırılabilir durumda olan kod parçalarıdır. Bu tür kod, gereksiz hesaplamalar, kullanılmayan değişkenler veya fonksiyonlar gibi unsurları içerebilir. Yapısal kapsama analizinde, gereksiz kod testler sırasında çalıştırılabilir, ancak bu çalıştırmanın programın genel işleyişi veya çıktıları üzerinde bir etkisi olmayabilir.

GNU C Compiler (GCC) için, aşağıdaki derleyici parametrelerini kullanarak bazı gereksiz kodları tespit etmek mümkündür[2]:

-Wunused-variable  -Wunused-value

Devre Dışı Bırakılmış Kod (Deactivated Code)​

Devre dışı bırakılmış kod, yazılım geliştirme sürecinde bilinçli bir şekilde planlanmış ve tasarlanmış koddur. Bu, yazılımın belirli bir konfigürasyonda aktif olmayan ancak başka bir konfigürasyonda kullanılabilecek kod parçalarını ifade eder. Örneğin, hem askeri hem de sivil konfigürasyona sahip bir helikopterin yazılımında, sadece sivil konfigürasyonda gerçekleştirilen testler sırasında askeri konfigürasyona ait kod satırları aktif olmayacaktır. Bu tür kod, yapısal kapsama analizinde genellikle kapsanmayan kod olarak görünebilir. Ancak, extraneous (gereksiz) veya ölü kodun aksine, devre dışı bırakılmış kod tasarım aşamasında öngörülen ve amaçlanan bir özelliktir. Bu kodlar için gereksinimler belirlenmiş, izlenebilirligi saglanmis ve testlerle işlevselliği doğrulanmıştır.

Devre dışı bırakılmış kodun iki temel kategorisi bulunmaktadır:

1. Hiçbir Zaman Aktive Edilmeyecek Kod: Bu kodlar genellikle yazılım geliştirme ve test süreçlerinde kullanılır ancak nihai ürün veya sistemde aktif olmazlar. Örneğin, hata ayıklama (debug) kodları bu kategoriye girer. Bu tür kodlar, yazılımın belirli bir parçasının sadece geliştirme aşamasında kullanılması ama üretim sürümünde devre dışı bırakılması gerektiğinde kullanılır. Bu kodlar genellikle ön işlemci komutları (preprocessor directives) kullanılarak kontrol edilir. Ön işlemci komutları, C veya C++ gibi dillerde yaygın olarak kullanılan #ifdef, #ifndef, #endif gibi direktiflerdir. Bu direktifler, kodun belirli bölümlerinin yalnızca belirli koşullar altında derlenmesini sağlar. Örneğin, #ifdef DEBUG ve #endif arasına yazılan kodlar yalnızca DEBUG makrosu tanımlı olduğunda derlenir ve uygulamaya dahil edilir. Üretim sürümünde bu makro tanımlanmadığında, bu kod bloğu derlenmez ve son üründe yer almaz.
2. Bazı Konfigürasyonlarda Kullanılacak Kod: Belirli konfigürasyonlarda kullanılan, ancak diğerlerinde devre dışı bırakılan kodlar. Cift konfigurasyona sahip helikopter orneginden ilerlersek. Uçuş sırasında, yazılım sivil modda ise, askeri uçuş moduna özgü özellikler devre dışı bırakılır. Bu, yazılımın çalışma zamanında (run-time) dinamik olarak gerçekleşir. Örneğin, bir konfigürasyon dosyası, buton veya input olarak alinan bir ayrik (discrete) pin yazılımın hangi modda çalıştığını belirler ve buna göre askeri özellikleri devre dışı bırakır. Devre dışı bırakma mekanizmasının işlevselliği kanıtlanmalı, gereksinimleri ve testleri olmalıdır. Ayrıca, devre dışı bırakma yaklaşımı, aktif edilen yazılımın seviyesini desteklemelidir.

Devre dışı bırakılmış kodun yönetimi ve kontrolü için Plan Software Aspects of Certification (PSAC), Software Verification Plan (SVP) ve Software Development Plan (SDP) gibi belgelerde özel hususların ele alınması gerekir.

PSAC'te; Devre dışı bırakılmış kodun yazılım içindeki rolü, kullanım amacı ve hangi koşullar altında devre dışı kalacağı açıklanmalıdır. Bu kodun neden gerektiği ve yazılımın genel işlevselliği üzerindeki etkisi detaylandırılmalıdır.

SDP'de; Devre dışı bırakılmış kodun geliştirilmesinde kullanılacak yöntemler ve teknikler detaylandırılmalıdır.

SVP'de; Devre dışı bırakılmış kodun doğru şekilde işlediğinin doğrulanması için uygulanacak test stratejileri ve metodolojileri açıklanmalıdır.

Kaynakça​

1. Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance, Leanna Rierson, Chapter 17 Noncovered Code (Dead, Extraneous, and Deactivated Code)
2. GCC, Options to Request or Suppress Warnings
3. Carnegie Mellon University Software Engineering Institute, MSC12-C. Detect and remove code that has no effect or is never executed

Ileri Okuma​

1. Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance, Leanna Rierson, 
2. Avionics Certification - Complete Guide to DO-178, DO-178C, DO-254; Vance Hilderman ve Tony Baghai

Havacılık endüstrisi, günümüzde giderek artan talepler ve karmaşık sistemlerle karşı karşıyadır. Bu sistemlerin etkin ve güvenilir bir şekilde iletişim kurması, uçuş güvenliği ve operasyonel verimlilik açısından kritik önem taşır. AFDX (Avionics Full-Duplex Switched Ethernet), havacılık endüstrisinde veri iletişimini iyileştirmek ve karmaşık sistemler arasında güvenilir bağlantılar sağlamak için kullanılan bir teknolojidir. Bu yazıda, AFDX'in ne olduğunu, nasıl çalıştığını, havacılık endüstrisindeki kullanım alanlarını, sağladığı avantajları ve teknik özelliklerini detaylı bir şekilde inceleyeceğiz.

AFDX Nedir?

AFDX, uçak içi sistemler arasında güvenilir ve yüksek hızlı veri iletişimi sağlamak için kullanılan bir iletişim protokolüdür. Bu teknoloji, Ethernet tabanlı bir ağ kullanarak verilerin değişimini kolaylaştırır. AFDX, uçuş kontrol sistemleri, yolcu eğlence sistemleri, motor kontrol sistemleri ve daha birçok kritik uçak sistemlerinin entegrasyonunu destekler.

AFDX'in Çalışma Prensibi

AFDX, tam çift yönlü iletişimi destekleyen anahtarlama yapısıyla karakterizedir. Bu yapı, verilerin düşük gecikme ve yüksek bant genişliği ile iletilmesini sağlar. Temel olarak, AFDX birçok uçak sistemini birbirine bağlayan bir ağ topolojisi oluşturur. Bu topoloji, verilerin kesintisiz ve güvenilir bir şekilde iletilmesini garanti eder.

AFDX'in Teknik Özellikleri

Deterministik İletişim: AFDX, belirli bir zaman diliminde veri iletimini garanti eden deterministik bir iletişim sağlar. Bu sayede, kritik verilerin hızlı ve güvenilir bir şekilde iletilmesi mümkün olur.

Redundans ve Güvenilirlik: AFDX, veri yollarında meydana gelebilecek kesintilere karşı yüksek düzeyde dayanıklılık ve güvenilirlik sunar. Çift hat ve çift anahtar yapısıyla ağın kesintisiz çalışması sağlanır.

Geniş Bant Genişliği: AFDX ağı, yüksek bant genişliği sunar. Bu özellik, büyük veri miktarlarının hızlı ve etkili bir şekilde iletilmesini sağlar.

Zaman Bölümlü Protokoller: AFDX, zaman bölümlü protokoller kullanarak veri iletimini düzenler. Bu, veri çarpışmalarını engeller ve veri iletimini daha verimli hale getirir.

Quality of Service (QoS) Desteği: AFDX, farklı veri türlerinin farklı öncelik seviyelerine sahip olabileceği bir Quality of Service (Hizmet Kalitesi) desteği sunar. Bu, kritik verilerin öncelikli olarak iletilmesini sağlar.

Etkin Bant Genişliği Kullanımı: AFDX, veri paketlerini düşük gecikme süreleriyle birleştirerek bant genişliğini daha etkili kullanır.

Airbus A380 ucaginda AFDX topolojisi

Boulanger, Frédéric & Marcadet, Dominique & Rayrole, Martin & Taha, Safouan & Valiron, Benoît. (2018). A time synchronization protocol for A664-P7. 1-9. 10.1109/DASC.2018.8569837. 

Kullanıldığı Uçaklar ve Avantajları

AFDX teknolojisi, özellikle büyük ticari yolcu uçaklarında ve askeri uçaklarda geniş çapta kullanılmaktadır. Airbus A380, Boeing 787 Dreamliner gibi modern yolcu uçaklarında AFDX teknolojisi kullanılarak uçak içi sistemlerin entegrasyonu ve veri iletişimi sağlanmaktadır. AFDX'in sağladığı avantajlar şunlardır:

Güvenilir Veri İletişimi: AFDX, kesintisiz ve güvenilir bir veri iletişimi sağlayarak uçak içi sistemlerin koordinasyonunu ve işbirliğini destekler.

Düşük Gecikme Süresi: Deterministik iletişim yapısı, düşük gecikme süreleriyle kritik verilerin hızlı bir şekilde iletilmesini sağlar.

Kablo ve Ağ Altyapısında Tasarruf: AFDX, tek bir Ethernet ağı üzerinden birden fazla sistem için iletişim sağladığı için kablo ve ağ altyapısı maliyetlerini düşürür.

Kolay Entegrasyon: AFDX, farklı uçak sistemlerinin entegrasyonunu kolaylaştırır, bu da üretim sürecini hızlandırır ve maliyetleri düşürür.

Bakım ve Onarım Kolaylığı: AFDX, hata izleme ve teşhis yetenekleri sayesinde bakım ekiplerinin sorunları tespit etmesini ve çözmesini kolaylaştırır.

Sonuç

AFDX teknolojisi, havacılık endüstrisinde veri iletişimini güvenilir, hızlı ve etkili bir şekilde sağlayarak uçuş güvenliği ve operasyonel verimliliği artırır. Kullanıldığı uçaklarda, uçuş kontrolünden yolcu eğlence sistemlerine kadar geniş bir yelpazede kritik roller üstlenir. Havacılık endüstrisi, AFDX sayesinde daha güvenli ve entegre bir şekilde faaliyet gösterebilirken, yolcular da daha keyifli ve konforlu bir uçuş deneyimi yaşayabilirler. Bu teknolojinin gelecekteki gelişmeleri ve daha fazla uygulama alanıyla havacılık sektöründe daha da büyük bir rol oynaması beklenmektedir.

Havacılık alanında, sorunsuz iletişim uçuşların güvenliği ve verimliliği açısından kritik bir rol oynar. Bu arenadaki önemli protokollerden biri de ARINC 429 protokolüdür. Yıllardır havacılık verilerinin iletişiminde temel bir rol oynamış olan bu protokol, aviyonik sistemler, enstrümanlar ve sensörler arasında hayati bir bağlantı sağlamaktadır. Bu blog yazısında, ARINC 429 dünyasına yüzeysel bir bakış atarak, önemini, çalışma prensiplerini ve modern havacılıktaki kalıcı önemini inceleyeceğiz.

Aeronautical Radio, Inc. (ARINC) tarafından geliştirilen ARINC 429, özellikle aviyonik uygulamalar için tasarlanmış seri veri iletişim protokolüdür. Bu protokol, aviyonik sistemler arasındaki veri iletişiminin fiziksel ve elektriksel özelliklerini tanımlar.

ARINC 429’un Önemi

Havacılığın merkezinde, hassasiyet ve doğruluk son derece önemlidir. ARINC 429, veri doğruluğunu ve bütünlüğünü sağlama konusundaki başarısıyla, aviyonik iletişimde vazgeçilmez bir araçtır. ARINC 429’un neden bu kadar önemli olduğuna bir bakalım:

Güvenlik ve Güvenilirlik: Havacılıkta iletişim hataları felaket sonuçlara yol açabilir. ARINC 429’un sağlam hata kontrol mekanizmaları ve yerleşik yedekliliği, veri iletiminin güvenilir ve bozulmasız olmasını sağlar.

Basitlik ve Evrensellik: ARINC 429’un basitliği, farklı üreticilerden gelen farklı aviyonik sistemler arasında etkileşim sağlamayı kolaylaştırır. Bu evrensellik, havacılık endüstrisinde geniş ölçüde benimsenmesine katkıda bulunmuştur.

Gerçek Zamanlı Performans: ARINC 429, gerçek zamanlı olarak çalışır; bu da kritik uçuş verilerinin sistemler arasında hızlı ve doğru iletilmesini sağlar. Bu, uçuş kontrolü, navigasyon ve izleme gibi faaliyetler için elzemdir.

ARINC 429 Nasıl Çalışır?

ARINC 429, noktadan-noktaya iletişim modelini kullanır, yani bir verici bir veya daha fazla alıcıya veri gönderir. Veri 32 bitlik kelimelere (word) kodlanır; bu kelimeler 5 bölümden oluşur:

Etiket (Label): Gönderilen verinin türünü belirleyen 8 bitlik bir alan. Farklı etiketler, irtifa, hava hızı ve motor parametreleri gibi çeşitli parametrelere karşılık gelir.

Kaynak Hedef Göstergesi (SDI): 2 bitlik bir alandir. Verinin nereden geldiğini ve nereye gittiğini anlamak için kullanılır.

Veri (Data): Gönderilen gerçek veriyi içeren 19 bitlik bir alan; bu veri alani BCD, BNR yada discrete tipinde olabilir.

İşaret/Durum Matrisi (SSM): Verinin önemini belirten 2 bitlik bir alan; işaretini, geçerli veya geçersiz olup olmadığını ve diğer durum bilgilerini içerir.

Parity: Istek uzerine Odd ya da Even tipinde olabilir. Tek bit hatayi tespit edebilir.

Protokol sabit bir bit hızında (12.5 Kbps yada 100 Kbps) çalışır ve bir kelimenin her bir biti sırayla iletilir; en az anlamlı bit (LSB) ilk olarak iletilir. Veri kelimeleri sıralı bir şekilde gönderilir. 2 kelime arasinda en az 4 bit uzunlugunda bosluk olmalidir.

Terimin Kökeni​

Aviyonik terimi, gazeteci Philip J. Klass tarafından ilk kez 1950'lerde kullanılmıştır. Terim, İngilizce "Aviation" (Havacılık) ve "Electronics" (Elektronik) kelimelerinin birleşiminden oluşur, yani AVIation + electrONICS = AVIONICS. Türkçe'de "Aviyonik" olarak bilinir.

Aviyonik, hava taşıtlarında kullanılan elektronik sistemleri genel bir terim olarak ifade eder. Temel olarak uçakların iletişim, navigasyon, gözetleme, ve gösterim işlevlerini yerine getirmek için tasarlanmışlardır. Aviyonik, sadece sivil ve askeri uçakları değil, aynı zamanda helikopterleri, insansız hava araçlarını (İHA), yapay uyduları ve uzay araçlarını da kapsar. Aviyonik sistemler, modern havacılıkta "uçağın beyni" olarak adlandırılır ve genellikle kokpitte bir araya getirilmişlerdir.

Aviyonik Sistemlerinin Bileşenleri​

*İletişim Sistemleri:* Bu sistemler, VHF radyoları, uydu iletişim sistemleri ve transponderlar gibi ekipmanları içerir. Özellikle, uydu iletişimi sayesinde, uçaklar okyanuslar üzerindeyken bile sürekli iletişimde kalabilirler.

*Seyrüsefer (Navigasyon) Sistemleri:* Küresel Konumlama Sistemi (GPS) bu kategorinin en bilinen örneğidir. Ancak, inertial navigasyon sistemleri (INS) ve VOR/DME gibi radyo frekansı tabanlı sistemler de önemlidir. Bu sistemler, uçağın konumunu hassas bir şekilde belirlemesini sağlar.

*Uçuş Kontrol Sistemleri:* Bu kategoride otomatik pilotlar, uçuş yönetim sistemleri (FMS) ve fly-by-wire kontrol sistemleri yer alır. Özellikle fly-by-wire sistemleri, pilot komutlarını elektronik sinyallere dönüştürerek hidrolik sistemler yerine uçağın kontrolünü sağlar.

*Gözetim Sistemleri:* Bu sistemler, uçak çevresindeki nesneleri ve hava şartlarını izlemek için radarlar ve hava durumu gözetleme sistemleri gibi bileşenleri içerir. Ayrıca, Trafik Çarpışma ve İzleme Sistemleri (TCAS), yakındaki diğer hava araçlarını izlemek için kullanılır.

*Gösterim ve Kokpit Göstergeleri:* Elektronik uçuş çantaları (EFB), çok fonksiyonlu göstergeler (MFD) ve baş üstü göstergeler (HUD) bu kategoriyi oluşturur. Örneğin, HUD sistemi, pilotun göz seviyesine bilgileri yansıtarak, dışarıya bakarken bile kritik uçuş verilerini görmesini sağlar.

*Veri Yönetimi ve İşleme:* Farklı sistemler ve sensörlerden gelen verileri birleştiren ve işleyen aviyonik bilgisayarlar, pilotlara ve yer ekiplerine gerektiğinde bilgi sağlar.

*Eğlence Sistemleri:* Bu, genellikle ticari uçaklarda bulunan bir özelliktir. Eğlence sistemleri, film, müzik, internet bağlantısı gibi seçenekler sunar.

Atış/Mühimmat Kontrol Sistemleri:

Askeri uçaklarda, silah sistemlerinin etkin ve doğru bir şekilde kullanılabilmesi için elektronik sistemler kullanılır.

Aviyonik sistemleri, modern havacılığın vazgeçilmez bir parçasıdır. Uçakların güvenli, verimli ve etkili bir şekilde işlemesini sağlayan bu sistemler, giderek daha karmaşık ve ileri teknoloji ürünü hale gelmektedir.