Aviyonik Sistemler ve İnsansız Hava Araçları

Aviyonik, bir hava aracının algılama, durum kestirimi, seyrüsefer, haberleşme, uçuş kontrolü, görev yönetimi ve arıza yönetimi işlevlerini ortak bir zaman ve güvenilirlik modeli içinde birleştiren sistemler bütünüdür. İnsansız hava araçlarında bu bütünlük özellikle görünürdür: sensör verisinin anlamı, haberleşme gecikmesi, kontrol çevriminin kararlılığı, yazılımın yürütme zamanı ve operatörün gördüğü durum aynı uçuş emniyeti zincirinin parçalarıdır.

Bu ders notu; sabit kanat uçuş fiziği ve temel kontrol kavramlarından başlayarak IMU/GNSS, koordinat sistemleri, Kalman süzgeci ve sensör füzyonuna; ardından yer kontrolü, telemetri, aviyonik veri yolları, gerçek zamanlılık, hata toleransı, statik analiz, yazılım güvencesi ve sistem entegrasyonuna ilerler. Amaç belirli bir hava aracı ürününü tanıtmak değil, farklı platformlara uygulanabilen aviyonik mühendisliği ilkelerini açıklamaktır.

Aviyonikte ölçüm değeri tek başına yeterli değildir. Bir verinin hangi sensörden geldiği, hangi koordinat sisteminde ifade edildiği, ne zaman üretildiği, hangi hata sınırlarına sahip olduğu ve hangi yazılım sürümünde işlendiği de teknik anlamın parçasıdır. Aynı şekilde “komut gönderildi”, “komut kabul edildi” ve “fiziksel sonuç doğrulandı” durumları birbirinden ayrılmalıdır.

Standartlar ve güvence yaklaşımları bu nedenle yalnız uyumluluk listesi olarak değil, arayüzleri, hata varsayımlarını ve doğrulama kanıtını disipline eden araçlar olarak ele alınır. ARINC 429, ARINC 653, MIL-STD-1553, MISRA C ve DO-178C bağlamı ilgili bölümlerde kendi kapsamları içinde açıklanır; burada herhangi bir belirli platform için kamuya açık kaynakla doğrulanmamış mimari veya sertifikasyon iddiası kurulmaz.

Bu konuların yazarın 2015 yılındaki gömülü ağ, telemetri, statik analiz ve aviyonik hata ayıklama çalışmalarına ilişkin tarihsel uygulama kaydı Baykar stajı sayfasında ayrı tutulur. Ders notundaki genel teknik iddiaların dayanağı ise aşağıdaki akademik ve teknik kaynaklardır.

Ünite 1: Uçuş Fiziği ve Temel Aviyonik Kavramlar

1.1. Aviyonik Sistemlerin Tanımı

Aviyonik sözcüğü aviation ve electronics sözcüklerinin birleşiminden gelir. Uçuşun elektronik, algılama, hesaplama, haberleşme ve kontrol tarafını kapsar.

Bir hava aracının aviyonik sistemi yalnızca kokpit ekranlarından veya bir uçuş bilgisayarından oluşmaz. Modern bir hava aracında aviyonik mimari kabaca şu işlevleri bir araya getirir:

• hava aracının durumunu ölçmek,
• konum ve yönelimini hesaplamak,
• pilot veya operatörden komut almak,
• uçuş yüzeylerini ve diğer eyleyicileri denetlemek,
• görevi ve uçuş planını yönetmek,
• dış dünya sensörlerini işletmek,
• haberleşmeyi sağlamak,
• sistem durumunu izlemek,
• arızaları belirlemek ve mümkünse yalıtmak,
• kritik işlevlerin tek bir hata nedeniyle kaybedilmesini önlemek.

İnsanlı bir uçakta pilot bu yapının merkezindeki karar vericidir. İnsansız hava aracında ise pilotun fiziksel olarak araçta bulunmaması, aviyonik gereksinimleri azaltmaz. Tersine, aracın uçuşunu sürdürebilmesi için durum kestirimi, haberleşme, otomatik uçuş ve arıza yönetimi daha belirleyici hâle gelir.

Bir İHA'nın uçabilmesi için gövde ve motor yeterli değildir. Uçuşun ölçülmesi, yorumlanması ve denetlenmesi gerekir.

1.2. Uçuşun Fiziksel Temeli

Sabit kanatlı bir hava aracını anlamanın en kısa yolu dört temel kuvvetle başlamaktır:

• kaldırma,
• ağırlık,
• itki,
• sürükleme.

Düz ve sabit irtifalı uçuşta idealize edilmiş durumda kaldırma ağırlığı, itki de sürüklemeyi dengeler. Gerçek uçuşta ise hız, irtifa, rüzgâr, manevra ve kumanda girdileri nedeniyle bu denge sürekli değişir.

1.2.1. Dinamik Basınç

Aerodinamik kuvvetlerin önemli bölümü dinamik basınçla ilişkilidir:

q = ½ρV²

Burada:

• q: dinamik basınç,
• ρ: hava yoğunluğu,
• V: havaya göre hız.

Hızın karesiyle değişen bu büyüklük, uçuş kontrolü açısından temel önemdedir. Aynı kumanda yüzeyi sapması düşük ve yüksek hızda aynı etkiyi oluşturmaz. Uçuş kontrol sistemi bu nedenle yalnızca "kumanda açısı" değil, hava aracının hangi uçuş noktasında bulunduğunu da dikkate almak zorundadır.

1.2.2. Kaldırma ve Sürükleme

Kaldırma yaklaşık olarak:

L = ½ρV²SC_L

sürükleme ise:

D = ½ρV²SC_D

ile ifade edilir.

Burada S kanat alanını, C_L kaldırma katsayısını, C_D ise sürükleme katsayısını gösterir.

Bu denklemler önemli bir mühendislik gerçeğini gösterir: uçuş yalnızca mekanik geometriyle açıklanamaz. Hava yoğunluğu, hız, hücum açısı, kanat profili ve uçuş konfigürasyonu birlikte değerlendirilmelidir.

1.2.3. Hücum Açısı

Hücum açısı, kanat profilinin referans doğrusu ile bağıl hava akımı arasındaki açıdır.

Belirli bir aralığa kadar hücum açısı arttıkça kaldırma katsayısı da artar. Ancak akış kanat yüzeyinden ayrılmaya başladığında kaldırma hızla azalır. Bu durum stol olarak adlandırılır.

Stol, yalnızca "uçak çok yavaşladığında" oluşan bir olay değildir. Temel belirleyici hücum açısıdır. Hız, yük faktörü, dönüş ve manevra koşulları kritik hücum açısına ulaşmayı etkiler.

Bir otomatik uçuş sisteminin güvenilirliği bu nedenle yalnızca rota takibinden ibaret değildir. Hava aracını güvenli uçuş zarfı içinde tutmak da kontrol probleminin parçasıdır.

1.3. Hava Aracının Eksenleri ve Hareketi

Bir hava aracı altı serbestlik derecesine sahiptir: üç doğrusal ve üç açısal hareket.

Gövdeye bağlı eksen takımında genellikle:

• ileri eksen x,
• yanal eksen y,
• düşey eksen z

kullanılır.

Bu eksenler çevresindeki açısal hareketler:

• roll: yatış,
• pitch: yunuslama,
• yaw: sapma

olarak adlandırılır.

Açısal hızlar çoğu uçuş kontrol gösteriminde:

• p: yatış açısal hızı (roll rate),
• q: yunuslama açısal hızı (pitch rate),
• r: sapma açısal hızı (yaw rate)

şeklinde gösterilir.

İvmeölçer ve jiroskopların gövdeye sabitlenmiş olması, bu eksen takımını aviyonik açıdan da doğal hâle getirir. Sensörler önce gövde koordinatlarında ölçüm yapar; konum, yönelim ve seyrüsefer için bu bilgiler uygun referans sistemlerine dönüştürülür.

Burada yazılım doğrudan fiziğin içine girer. Bir eksen dönüşümündeki işaret hatası, yanlış bir birim, eksik bir zaman damgası veya hatalı koordinat dönüşümü, ekranda küçük bir yazılım kusuru olmaktan çıkıp hava aracının durum kestirimini bozabilir.

1.4. Kararlılık, Kumanda ve Geri Besleme

Kararlı bir sistem, küçük bir bozucu etki sonrasında denge durumuna dönme eğilimindedir. Kararsız sistemde ise küçük sapmalar zamanla büyüyebilir.

Aerodinamik kararlılık performansla birlikte değerlendirilir. Bazı hava aracı konfigürasyonlarında doğal kararlılığın azaltılması, sürükleme veya manevra performansı açısından avantaj sağlayabilir. Ancak bunun bedeli daha etkin bir otomatik kontrol gereksinimidir.

Uçuş kontrolü bu noktada klasik geri besleme problemine dönüşür:

e(t) = r(t) - y(t)

Burada:

• r(t): istenen durum,
• y(t): ölçülen veya kestirilen durum,
• e(t): kontrol hatasıdır.

Denetleyici bu hatadan hareketle eyleyicilere gönderilecek komutu üretir.

Örneğin istenen yatış açısına ulaşmak için sistem yalnızca kanatçığı belirli bir açıya getirmez. Ölçülen yatış açısını ve açısal hızı izler, hava aracının dinamik cevabını değerlendirir ve kapalı çevrim içinde düzeltme uygular.

Bu nedenle otopilot "önceden yazılmış hareketleri oynatan" bir yazılım değildir. Sensör, durum kestirimi, kontrol kanunu, eyleyici ve geri beslemenin birlikte çalıştığı gerçek zamanlı bir sistemdir.

1.5. Elektronik Uçuş Kumandası (fly-by-wire) ve Dijital Uçuş Kontrolü

Elektronik uçuş kumandası (fly-by-wire) sistemlerinde kumanda işaretleri mekanik bağlantılar yerine elektriksel işaretler ve bilgisayarlar üzerinden işlenir.

Genel akış şöyledir:

Komut → uçuş bilgisayarı → kontrol kanunu → eyleyici → hava aracı → sensör → geri besleme

İHA açısından bu yaklaşım doğal bir mimaridir. Operatör doğrudan fiziksel kumanda bağlantısına sahip değildir. Uçuş bilgisayarı, sensörler ve eyleyiciler aracın uçuşunun asli parçalarıdır.

Dijital uçuş kontrolünün önemli avantajları şunlardır:

• farklı uçuş noktaları için kazanç planlama,
• karmaşık kontrol kanunları,
• çoklu sensör verisinin işlenmesi,
• yedekli kanalların karşılaştırılması,
• arıza belirleme,
• yerleşik test,
• uçuş verisinin kaydı,
• yazılım ile işlev güncelleme.

Buna karşılık yazılım hatası da uçuş emniyeti probleminin parçası hâline gelir. Kritik bir uçuş yazılımında "çalışıyor" ifadesi yeterli değildir. Zamanlama, veri geçerliliği, hata durumları, bellek davranışı, girdi sınırları ve arıza yayılımı da tasarımın konusudur.

Ünite 2: Sensörler, Seyrüsefer ve Uçuş Kontrolü

Bu ünite, uçuş durumunun sensörlerle ölçülmesinden durum kestirimi, güdüm, kontrol ve aktüatör tepkisine kadar kapalı çevrim zincirini birlikte ele alır.

            +-----------------------------+
            |                             |
            v                             |
fiziksel uçuş -> sensörler -> durum kestirimi -> güdüm -> kontrol -> aktüatörler
      ^                                                             |
      +-------------------------------------------------------------+
                         geri besleme

Bir seyrüsefer çözümünde önce konum, hız ve yönelim bilgisinin hangi sensörlerden geleceği belirlenir. Ölçümler farklı frekanslarda üretiliyorsa zaman damgaları ortak zaman tabanına taşınır; koordinat çerçeveleri dönüşümden önce tanımlanır. Filtre güncellemesinde model tahmini ile ölçüm artığı karşılaştırılır. Artığın olağandışı büyümesi, tek başına aracın hareketinden kaynaklanmış sayılmamalı; sensör hatası, gecikme ve model uyumsuzluğu da incelenmelidir.

2.1. Hava Veri Sistemi

Hava aracının yalnızca nerede olduğu değil, atmosfer içinde nasıl hareket ettiği de bilinmelidir.

Hava veri sistemi tipik olarak şu büyüklükleri üretir veya bunların hesaplanmasına katkı sağlar:

• statik basınç,
• toplam basınç,
• basınç irtifası,
• kalibre edilmiş hava hızı,
• gerçek hava hızı,
• Mach sayısı,
• hava sıcaklığı,
• düşey hız,
• hücum açısı.

Basınç irtifası ve hava hızı, uçuş kontrolü için temel durumlardır. Aynı kontrol yüzeyi sapmasının farklı hızlarda farklı aerodinamik moment üretmesi nedeniyle uçuş kontrol kazançları hava verisine göre ayarlanabilir.

İHA'da hava veri bilgisinin önemi üç başlıkta öne çıkar:

1. Uçuş zarfı: stol ve aşırı hız sınırlarının korunması.
2. Otopilot: irtifa, hız ve tırmanma/alçalma modlarının yürütülmesi.
3. Seyrüsefer: hava hızı ve barometrik irtifanın diğer sensörlerle birleştirilmesi.

Sensör ölçümü tek başına gerçek değildir. Kalibrasyon, montaj konumu, basınç hatası, sıcaklık etkisi, örnekleme zamanı ve ölçüm geçerliliği de verinin bir parçasıdır.

2.2. IMU, Jiroskop ve İvmeölçer

Modern aviyonik sistemlerin temel bileşenlerinden biri ataletsel ölçüm birimidir.

Bir IMU tipik olarak üç eksende:

• açısal hızı jiroskoplarla,
• doğrusal özgül kuvveti ivmeölçerlerle

ölçer.

Bu ölçümler strap-down mimaride doğrudan gövdeye bağlı sensörlerden alınır. Yönelim, hız ve konum işlemci üzerinde sayısal olarak hesaplanır.

İdeal durumda ivmenin zamana göre integrali hızı, hızın integrali de konumu verir. Ancak gerçek sensörlerde:

• sabit sapma (bias),
• ölçek katsayısı hatası,
• eksen kaçıklığı,
• sıcaklık etkisi,
• gürültü,
• sürüklenme

bulunur.

Bu hataların integrasyonla büyümesi, ataletsel seyrüseferin temel problemidir.

Buradan önemli bir sonuç çıkar: iyi seyrüsefer yalnızca "iyi GPS" veya "iyi IMU" seçmek değildir. Farklı hata karakteristiğine sahip sensörlerin doğru biçimde birleştirilmesi gerekir.

2.3. Yönelim ve Durum Kestirimi

Uçuş kontrol bilgisayarının temel sorularından biri şudur:

Hava aracı şu anda hangi konumda, hangi yönde ve nasıl hareket ediyor?

Durum vektörü uygulamaya göre değişebilmekle birlikte şu bileşenleri içerebilir:

Durum vektörü örneğin x = [konum, hız, yönelim, açısal hız, sensör sapmaları] biçiminde düşünülebilir.

Yönelim Euler açılarıyla ifade edilebilir; ancak hesaplama sistemlerinde tekillik sorunları nedeniyle kuaterniyon gibi gösterimler de yaygındır.

Durum kestirimi, farklı sensörleri ortak bir fiziksel model içinde birleştirir. Böylece tek bir sensöre körü körüne güvenmek yerine, ölçümlerin tutarlılığı değerlendirilebilir.

İHA sistemlerinin güvenilirliğinde sensör füzyonunun önemi buradan gelir.

2.4. GPS/GNSS, INS ve Sensör Füzyonu

Uydu seyrüseferi uzun süreli konum doğruluğu sağlar. Ataletsel sistem ise yüksek örnekleme hızlı ve kısa süreli düzgün hareket bilgisi üretir.

İki sistemin hata karakteristiği birbirini tamamlar:

• GNSS mutlak konum sağlar ancak ölçüm gecikmesi, kesinti veya bozulma yaşayabilir.
• INS dış kaynağa gereksinim duymadan sürekli çözüm üretir ancak hata zamanla büyür.

Bu nedenle GNSS ve INS'in birlikte kullanılması doğal bir çözümdür.

2.4.1. Kalman Süzgeci

Kalman süzgecinin temel mantığı iki adımdır:

1. sistem modeline göre ileri kestirim,
2. yeni ölçüm geldiğinde kestirimin düzeltilmesi.

Basitleştirilmiş olarak:

İleri kestirim basitleştirilmiş olarak x̂⁻ₖ = F x̂ₖ₋₁ biçiminde yazılabilir.

Ölçüm geldiğinde düzeltme x̂ₖ = x̂⁻ₖ + K(zₖ - Hx̂⁻ₖ) biçiminde gösterilebilir.

Burada yenilik terimi:

Buradaki yenilik terimi zₖ - Hx̂⁻ₖ, ölçüm ile beklenen ölçüm arasındaki farktır.

ölçüm ile beklenen ölçüm arasındaki farktır.

Bu yapı yalnızca konum birleştirmek için kullanılmaz. Jiroskop biası, ivmeölçer biası veya diğer durumlar da kestirilebilir.

İHA açısından sensör füzyonu, uçuş kontrolünün "gözü" gibidir. Kontrol kanunu ne kadar iyi tasarlanırsa tasarlansın, sisteme yanlış durum verisi giriyorsa doğru sonuç beklenemez.

2.4.2. Koordinat Sistemleri ve Zaman Eşleme

Sensör füzyonunda yalnız ölçüm değerlerini bir araya getirmek yeterli değildir. Ölçümlerin aynı fiziksel büyüklüğü aynı koordinat sistemi ve aynı zaman referansında ifade etmesi gerekir. GNSS konumu çoğunlukla jeodezik bir referans çerçevesinde gelir; IMU ise ölçümlerini gövde eksenlerinde üretir. Seyrüsefer çözümü bu verileri uygun dünya, yerel seyrüsefer ve gövde koordinat sistemleri arasında dönüştürür.

WGS 84, küresel konumun ifade edilmesinde yaygın jeodezik başvuru sistemidir. Uçuş kontrolünde ise çoğu zaman kuzey-doğu-aşağı gibi yerel seyrüsefer çerçeveleri ile gövde eksenleri arasında dönüşüm gerekir. Dönüşümün işaret, eksen sırası veya birim hatası doğru sensör verisini yanlış fiziksel anlama çevirebilir.

Zaman eşleme de aynı derecede önemlidir. 100 Hz IMU ölçümü ile daha düşük hızda gelen GNSS ölçümünü yalnız geliş sırasına göre birleştirmek yeterli değildir. Her ölçümün ne zaman alındığı, taşıma ve işleme gecikmesi ve kestirim anına nasıl taşındığı bilinmelidir. Sensör füzyonu bu nedenle yalnız istatistiksel birleştirme değil, aynı zamanda koordinat ve zaman tutarlılığı problemidir.

2.5. Otopilot ve Uçuş Yönetimi

Otopilot ile uçuş yönetimi aynı şey değildir.

Otopilot, belirli kontrol hedeflerini kapalı çevrim olarak gerçekleştirir:

• yatış tutma,
• baş tutma,
• irtifa tutma,
• hız tutma,
• tırmanma veya alçalma,
• rota izleme.

Uçuş yönetimi ise daha üst düzey bir katmandır:

• uçuş planı,
• rota noktası (waypoint) dizisi,
• görev rotası,
• hız ve irtifa profilleri,
• görev evreleri,
• rota değişiklikleri,
• performans tahmini.

İnsansız hava araçlarında bu ayrım özellikle önemlidir.

Yer kontrol istasyonunda operatör "sağa 3 derece aileron" komutu vermek yerine çoğu zaman daha yüksek seviyeli bir amaç tanımlar:

Bu rota noktasına git.

Bunu gerçekleştirmek için sistemin:

1. mevcut konumu belirlemesi,
2. hedef rotayı hesaplaması,
3. gerekli baş ve yatış komutlarını üretmesi,
4. uçuş kontrol döngülerini çalıştırması,
5. rüzgâr ve sapmaları düzeltmesi

gerekir.

Otonomi arttıkça kullanıcı komutunun soyutlama seviyesi yükselir; ancak altta çalışan kontrol döngüleri ortadan kalkmaz.

Ünite 3: İHA Mimarisi, Yer Kontrol, Telemetri ve Gerçek Zamanlı Haberleşme

Bu ünite, hava aracı ile yer kontrol istasyonunu veri bağı üzerinden telemetri, komut, operatör etkileşimi ve kayıt işlevleriyle bağlı tek bir sistem olarak ele alır.

+-----------------+      veri bağı       +-------------------+
| hava aracı      | <------------------> | yer kontrol       |
|                 |                      | istasyonu         |
| sensör          | -- telemetri ------> | görüntüleme       |
| uçuş bilgisayarı| <--- komut ----------| operatör          |
| aktüatör        |                      | kayıt / analiz    |
+-----------------+                      +-------------------+

İnsansız hava aracı haberleşme hattında önce hangi verinin emniyet açısından kritik, hangisinin tanı amaçlı olduğu sınıflandırılır. İleti sıklığı, paket boyutu, kayıp toleransı ve son kullanım zamanı her veri türü için ayrı belirlenir. Bağlantı gecikmesi arttığında kontrol döngüsünün yer istasyonuna bağımlı kalmaması gibi mimari kararlar emniyet analiziyle gerekçelendirilir. Bağlantı kopması durumunda beklenen geçişler ve araç durumu önceden tanımlanıp deneyle sınanmalıdır.

3.1. İHA Sistem Mimarisi

Bir İHA'yı yalnızca uçan platform olarak düşünmek eksiktir. Operasyonel sistem genel olarak şu bileşenlerden oluşur:

• hava aracı,
• uçuş kontrol sistemi,
• görev bilgisayarı,
• sensörler,
• faydalı yük,
• veri bağı,
• yer kontrol istasyonu,
• operatör arayüzü,
• görev planlama ve kayıt altyapısı,
• bakım ve test bileşenleri.

Bir İHA mimarisi yalnızca hava aracından ibaret değildir. Uçan platform ile yer istasyonu arasında telemetri, komut, kayıt, hata ayıklama ve operatör etkileşimi için sürekli bir bilgi yolu bulunur. Bilgisayar mühendisliği açısından sistem davranışının önemli bölümü bu arayüzlerde gözlenebilir hâle gelir.

3.2. Yer Kontrol İstasyonu

İnsanlı uçakta pilotun kokpitte gördüğü bilgilerin önemli bölümü, İHA'da yer kontrol istasyonuna taşınır.

Tipik bir yer kontrol arayüzünde şu bilgiler bulunabilir:

• konum,
• irtifa,
• hava ve yer hızı,
• baş,
• yunuslama ve yatış,
• rota ve rota noktaları,
• motor ve güç sistemi durumu,
• uçuş modu,
• veri bağı durumu,
• sensör ve faydalı yük durumu,
• video veya elektro-optik görüntü,
• uyarılar ve arızalar.

Burada kullanıcı arayüzü kozmetik bir konu değildir.

Operatörün yanlış uçuş modunu seçmesi, geçersiz telemetriyi geçerli sanması veya kritik bir alarmı fark edememesi sistem problemidir. Bu nedenle HMI tasarımında bilgi yoğunluğu, önceliklendirme ve hata görünürlüğü mühendislik gereksinimi olarak ele alınmalıdır.

3.3. Telemetri: Sayılardan Sistem Durumuna

Telemetriyi yalnızca "araçtan gelen değerleri ekranda göstermek" olarak düşünmek yetersizdir.

Bir telemetri kanalında her veri için en az şu sorular önemlidir:

• Bu değer hangi kaynaktan geldi?
• Hangi zamanda ölçüldü?
• Hangi birimdedir?
• Son güncelleme zamanı nedir?
• Geçerli mi?
• Beklenen aralıkta mı?
• Hangi örnekleme frekansında geliyor?
• Paket kaybı oldu mu?
• Sıra numarası atlandı mı?
• Değer sensör ölçümü mü, kestirim mi, komut mu?
• Eski veri ekranda yeni veri gibi mi görünüyor?

Bir yer kontrol yazılımında altitude = 5000 tek başına yeterli bilgi değildir.

Daha anlamlı veri modeli şuna yakındır:

değer + birim + kaynak + zaman + geçerlilik + kalite + sıra

2015'te yer kontrol telemetrisi üzerinde çalışmak, teorik ağ programlamasının gerçek zamanlı bir sisteme dönüştüğü noktayı görmemi sağladı. Gecikme, bağlantı kopması veya hatalı veri artık laboratuvar örneği değil, sistem durumunun doğru anlaşılmasını doğrudan etkileyen bir problemdi.

3.4. Gömülü Ağ ve Veri Akışı

İHA'da haberleşme iki ayrı ölçekte ele alınabilir:

1. hava aracının kendi içindeki aviyonik haberleşme,
2. hava aracı ile yer sistemi arasındaki veri bağı.

Araç içindeki veri yolu farklı sensör ve bilgisayarların bilgi paylaşmasını sağlar. Yer bağlantısında ise komut, telemetri, görev ve faydalı yük verileri taşınabilir.

Mühendislik açısından önemli olan yalnızca bant genişliği değildir.

Şu özellikler de belirleyicidir:

• gecikme,
• gecikme değişimi,
• paket kaybı,
• sıralama,
• veri bütünlüğü,
• hata belirleme,
• zaman eşleme,
• önceliklendirme,
• bağlantı kaybı davranışı.

Bir video akışının bir paketi kaybetmesi ile uçuş modu komutunun kaybolması aynı sonuç sınıfına ait değildir. Kritik sistem tasarımında veri trafiği semantiğine göre sınıflandırılır.

Gömülü ağ yığını yalnızca TCP/IP programlama konusu değildir. İşlemci zamanlaması, tampon yönetimi, hata davranışı ve fiziksel sistem arasındaki sınırın bir parçasıdır. Paket kaybı, yeniden iletim, gecikme ve bağlantı kopması; üst katmandaki durum kestirimini ve operatör görünümünü doğrudan etkileyebilir.

3.4.1. Aviyonik Veri Yolları: Farklı Gereksinimler, Farklı Tasarımlar

Aviyonik sistemlerde her veri akışı Ethernet veya IP tabanlı olmak zorunda değildir. Tarihsel ve güncel platformlarda farklı güvenilirlik, kablolama, bant genişliği ve determinizm gereksinimlerine göre farklı veri yolu mimarileri kullanılır.

ARINC 429, sivil aviyonikte uzun süredir kullanılan, basit ve öngörülebilir veri aktarım modeline sahip bir standarttır. MIL-STD-1553 ise komut/yanıt temelli, veri yolu denetleyicisinin iletişimi yönettiği farklı bir mimari tanımlar. Bu standartların birlikte incelenmesinin amacı belirli bir platformun iç mimarisi hakkında çıkarım yapmak değil; bant genişliği, determinizm, topoloji, hata yalıtımı ve doğrulanabilirlik arasındaki tasarım tercihlerini karşılaştırmaktır.

Mühendislik açısından çıkarım daha geneldir: veri yolu seçimi yalnız bit hızına göre yapılmaz. Hata modeli, kablolama topolojisi, gecikme üst sınırı, zamanlama öngörülebilirliği, elektromanyetik ortam, bakım ve arayüzlerin yaşam döngüsü birlikte değerlendirilir.

3.5. Gerçek Zamanlılık ve Gecikme

Gerçek zamanlı sistem "çok hızlı çalışan sistem" demek değildir.

Esas ölçüt şudur:

Sonucun doğru zamanda üretilmesi, doğruluğun bir parçasıdır.

Bir kontrol döngüsünde 10 ms içinde gelmesi gereken veri 500 ms sonra geliyorsa değerin sayısal olarak doğru olması yeterli değildir.

Bu nedenle aviyonik yazılımda:

• en kötü durum yürütme süresi (WCET),
• örnekleme periyodu,
• zaman sınırı,
• zamanlama sapması (jitter),
• kuyruk gecikmesi,
• zaman aşımı,
• güncelliğini yitirmiş veri

gibi kavramlar işlevsel doğruluğun parçasıdır.

Yer kontrol sisteminde insan operatörün zaman ölçeği uçuş kontrol döngüsünden daha yavaştır. Buna rağmen telemetri gecikmesi ve veri tazeliği yine görünür olmalıdır. Operatör "şu anki durum" ile "birkaç saniye önceki durum" arasındaki farkı bilmelidir.

3.5.1. Veri Yaşı ve Zaman Senkronizasyonu

Gerçek zamanlı bir sistemde paket alım zamanı ile ölçüm zamanı aynı şey değildir. Bir telemetri paketi yeni gelmiş olabilir, fakat içindeki sensör değeri daha eski bir örnekleme anına ait olabilir. Bu nedenle kritik veri modellerinde yalnız zaman damgası bulunması değil, bu zaman damgasının neyi temsil ettiğinin açık olması gerekir.

Özellikle çoklu sensör sistemlerinde saat kayması, zaman damgası çözünürlüğü, kuyruk beklemesi ve farklı örnekleme hızları durum kestirimini etkileyebilir. Aynı sayısal değer, doğru zaman bağlamı olmadan yanlış bir sistem durumu üretebilir. Bu nedenle veri yaşı ve zaman senkronizasyonu performans metriği değil, işlevsel doğruluğun parçasıdır.

Konum telemetrisinde ölçüm zamanı, paketin gönderilme zamanı ve yer istasyonuna ulaşma zamanı aynı değildir. Son alınan koordinatın ekranda yeni görünmesi, fiziksel konum ölçümünün de yeni olduğu anlamına gelmez. Örneğin konum ölçümü 80 ms işlenip kuyrukta 120 ms bekledikten sonra 50 ms ağ gecikmesiyle ulaşıyorsa karar verildiği anda en az 250 ms yaşındadır. İHA durum ekranı geçerli ölçüm yaşı, saat eşzamanlama güveni ve son veri sınırını açıkça ayırmalıdır; eski ölçümle kontrol kararını tazelemek kontrol döngüsünü güncellemez.

3.6. Haberleşme Kaybı bir İstisna Değil, Tasarım Durumudur

İnsansız sistemde veri bağı her zaman kusursuz kabul edilemez.

Bu nedenle bağlantı kaybı:

unexpected exception

gibi ele alınmamalıdır.

Sistem tasarımının açık bir durumu olmalıdır.

Genel olarak şu sorular önceden cevaplanır:

• bağlantı hangi koşulda kayıp kabul edilir?
• araç mevcut görevine devam eder mi?
• belirlenmiş bir noktaya mı yönelir?
• güvenli bekleme davranışı var mıdır?
• operatör bağlantı durumunu nasıl görür?
• bağlantı geri geldiğinde durum nasıl uzlaştırılır?

Burada belirli bir platformun operasyonel davranışını tarif etmekten çok, güvenilir sistem tasarımı ilkesi önemlidir: arıza modu normal durum makinesinin dışında bırakılmaz.

3.6.1. Bağlantı Kaybını Durum Makinesiyle Modellemek

Bağlantı kaybını tek bir if koşuluna indirgemek yerine açık bir durum modeli kurmak daha güvenilirdir. Genel bir tasarımda normal çalışma, bağlantının bozulduğu kısıtlı çalışma, bağlantı kaybı, güvenli davranış, yeniden bağlantı ve durum uzlaştırma gibi durumlar ayrı ayrı tanımlanabilir. Geçişlerin zaman aşımı, veri kalitesi ve görev bağlamı gibi koşulları da açık olmalıdır.

Bu yaklaşım belirli bir İHA'nın gerçek operasyonel durum makinesini açıklamaz. Ama kritik bir haberleşme kanalındaki hata davranışının istisna işleyicisine bırakılmaması gerektiğini gösterir. Durum tabanlı model, test senaryolarının ve hata enjeksiyonunun da daha sistematik kurulmasını sağlar.

Ünite 4: Güvenilirlik, Hata Toleransı, Statik Analiz ve Sistem Entegrasyonu

Bu ünite, sensör ve işlem zincirindeki arızaların algılanması, yalıtılması ve güvenli davranışa dönüştürülmesini sistem bütünlüğü açısından ele alır.

sensör A --+
sensör B --+--> oylayıcı / kestirici --> kontrolcü --> aktüatör
sensör C --+          |
                      +--> kısıtlı çalışma kipi
                      +--> güvenli durum / toparlanma

4.1. Yedeklilik ve Hata Toleransı

Uçuş kritik sistemlerde tek bir bileşenin arızası tüm sistemi kaybettirmemelidir.

Yedeklilik şu seviyelerde uygulanabilir:

• sensör,
• işlemci,
• güç kaynağı,
• veri yolu,
• eyleyici,
• haberleşme,
• yazılım veya algoritma.

Ancak "üç tane sensör koymak" tek başına hata toleransı değildir.

Yedekli sistemde ayrıca şu mekanizmalar gerekir:

• kanallar arası karşılaştırma,
• tutarsız kanalın belirlenmesi,
• oylama,
• arıza yalıtımı,
• yeniden yapılandırma,
• kısıtlı çalışma modu,
• ortak nedenli hata analizi.

Üç kanal aynı hatalı varsayıma dayanıyorsa sayısal yedeklilik ortak nedenli hatayı çözmez.

Bu nedenle kritik aviyonikte mimari yedeklilik kadar tasarım çeşitliliği, bağımsızlık ve arıza yayılımının sınırlandırılması da önemlidir.

4.2. FMEA ve Arıza Düşüncesi

Hata Türleri ve Etkileri Analizi (FMEA), bir bileşenin nasıl arızalanabileceğini ve bu arızanın sistem üzerindeki etkisini sistematik biçimde ele alır.

Temel soru şudur:

Bu bileşen yanlış çalışırsa ne olur?

Ardından daha ayrıntılı sorular gelir:

• arıza algılanabilir mi?
• yanlış veri mi üretir, veri üretmeyi mi bırakır?
• hata başka kanallara yayılır mı?
• sistem çalışmaya devam edebilir mi?
• güvenli moda geçebilir mi?
• operatör durumu anlayabilir mi?

Kritik sistem geliştirmede hata yalnızca catch bloğunda ele alınan yazılım olayı değildir. Sensör, güç, ağ, işlemci, zamanlama ve insan etkileşimi birlikte değerlendirilir.

4.2.1. Yerleşik Test ve Sistem Sağlık İzleme

Hata toleransı yalnız arıza olduktan sonra yedek kanala geçmek değildir. Sistemin kendi bileşenlerinin sağlık durumunu gözleyebilmesi, arızayı mümkün olduğunca erken belirleyebilmesi ve arızalı kaynağı diğerlerinden ayırabilmesi gerekir. Aviyonikte yerleşik test (Built-In Test, BIT) bu düşüncenin uygulama biçimlerinden biridir.

Yerleşik test açılışta, sürekli çalışma sırasında veya bakım amacıyla operatör tarafından başlatılan farklı seviyelerde tasarlanabilir. Amaç yalnız "geçti/kaldı" sonucu üretmek değildir. Hangi bileşenin hangi koşulda güvenilirliğini kaybettiği, sistemin kalan kabiliyeti ve gerekiyorsa hangi kısıtlı çalışma moduna geçileceği de sağlık yönetiminin parçasıdır.

Bu katman FMEA ile doğrudan ilişkilidir. FMEA olası arızaları ve etkilerini düşünür; yerleşik test ve sağlık izleme ise bu arızaların çalışma sırasında nasıl gözlenebileceğine dair mekanizma sağlar.

4.3. Aviyonik Yazılımda Statik Analiz

Aviyonik yazılımda statik analiz, derleyicinin kabul ettiği kod ile mühendislik açısından kabul edilebilir kod arasındaki farkı görünür kılmak için kullanılır. Amaç yalnız sözdizimi hatası bulmak değil; tanımsız davranış, veri akışı kusurları, aritmetik sınırlar, kaynak yönetimi ve proje kurallarından sapmalar gibi hata sınıflarını yürütme öncesinde belirlemektir.

Etkili bir statik analiz süreci araç seçimiyle değil, uygulanacak kural kümesinin ve sapma politikasının tanımlanmasıyla başlar. Proje daha sonra yerel kontrolleri ve farklı analiz motorlarından gelen bulguları ortak bir sonuç modelinde birleştirebilir. Bulguların tekilleştirilmesi, önem derecesi, yanlış pozitif değerlendirmesi ve kaynak kod sürümüyle ilişkilendirilmesi; ham uyarı sayısından daha değerlidir.

Bu deneyimin kalıcı tarafı belirli bir aracın kendisi değildi. Kuralın belge olarak tanımlanması, mümkün olan bölümünün otomatik denetlenmesi, bulgunun kaynak dosya ve satırla izlenebilmesi ve farklı araçların aynı kod için farklı güvence düzeyleri sunduğunun görülmesi daha önemliydi.

Statik analiz şu tür problemlerin erken yakalanmasına yardımcı olabilir:

• erişilemeyen kod,
• boş gösterici (null) veya işaretçi (pointer) hataları,
• tanımsız davranış,
• sınır aşımı,
• yanlış tür dönüşümleri,
• kaynak sızıntısı,
• kullanılmayan durumlar,
• karmaşık kontrol akışları,
• bazı eşzamanlılık problemleri.

Ancak statik analiz testin veya sistem doğrulamasının yerine geçmez.

Kritik yazılımda daha doğru denklem şöyledir:

doğru mimari + açık gereksinim + statik analiz + test + entegrasyon doğrulaması + saha gözlemi

Bir araç tek başına güvenilirlik üretmez. Farklı hata sınıflarını yakalayan yöntemlerin birlikte kullanılması gerekir.

4.3.1. MISRA C: Kural Kümesi ile Analiz Aracını Ayırmak

MISRA C bir statik analiz motoru değildir. Kritik sistemlerde C dilinin daha öngörülebilir ve denetlenebilir kullanılmasını hedefleyen bir yönerge ailesidir. Bir analiz aracı bu yönergelerin bir bölümünü otomatik olarak denetleyebilir; başka yönergeler kod incelemesi, tasarım kanıtı veya kontrollü sapma süreci gerektirebilir.

Programlama standardının sürümü konfigürasyon kontrollü bir proje girdisi olmalıdır. Yeni bir MISRA sürümünün yayımlanması, daha eski bir yazılım tabanının kendiliğinden yeni sürüme göre geliştirilmiş olduğu anlamına gelmez. Uyum da yalnızca “analiz aracı sıfır uyarı verdi” sonucuna indirgenemez; uygulanabilir kuralların, gerekçeli sapmaların ve doğrulama kanıtının proje düzeyinde izlenmesi gerekir.

Bu ayrımın daha ayrıntılı teknik tarafı MISRA C ve Statik Kod Analizi notunda ele alınmıştır.

4.3.2. Uçuşa Elverişlilik ve Yazılım Güvencesi

Uçuşa elverişlilik yalnız yazılımın hatasız derlenmesi veya testlerin geçmesi anlamına gelmez. Hava aracının ve ilgili sistemlerin amaçlanan kullanım bağlamında güvenli biçimde çalışabileceğine ilişkin sistem, donanım, yazılım, bakım ve işletme kanıtları birlikte değerlendirilir.

Sivil havacılıkta RTCA DO-178C, hava aracı sistem ve ekipmanlarındaki yazılım için geliştirme ve doğrulama güvencesi yaklaşımının temel başvuru dokümanlarından biridir. FAA AC 20-115D; DO-178C'yi, yazılım aracı yeterliliği için DO-330'u, model tabanlı geliştirme için DO-331'i, nesne yönelimli teknoloji için DO-332'yi ve biçimsel yöntemler için DO-333'ü tanır. Bu belgeler burada belirli bir platforma sertifikasyon atfetmek için değil, gereksinimden kanıta uzanan güvence zincirinin nasıl kurulduğunu açıklamak için ele alınır.

Mühendislik açısından önemli olan, kritik yazılımda gereksinim, tasarım, kod, doğrulama sonucu, yapılandırma ve problem kayıtları arasında izlenebilir bir kanıt zinciri kurulmasıdır. Bu bakış Yazılım Mühendisliği ve Yazılım Test Mühendisliği derslerindeki izlenebilirlik ve doğrulama kavramlarının aviyonik bağlamdaki karşılığıdır.

4.3.3. Gereksinim Tabanlı Doğrulama ve Yapısal Kapsam

Yapısal kapsam, testlerin kodun hangi bölümlerini yürüttüğünü gösteren bir kanıt türüdür; gereksinimlerin doğru ve eksiksiz doğrulandığını tek başına kanıtlamaz. Kritik sistemlerde ifade kapsamı, karar kapsamı ve değiştirilmiş koşul/karar kapsamı (MC/DC) gibi ölçütler risk ve güvence düzeyine göre anlam kazanır.

Doğru sıra, yalnız kapsam yüzdesini yükseltmek değildir. Önce gereksinimlerden doğrulama senaryoları türetilir; sonra yapısal kapsam analizi testlerin ulaşmadığı kodu, gereksinimle ilişkisi belirsiz davranışı veya ek test ihtiyacını görünür kılar. Böylece kapsam bir hedef sayı değil, doğrulama boşluklarını bulma aracına dönüşür.

4.4. Sensör Füzyonu ve Hata Toleransı Arasındaki İlişki

Sensör füzyonu genellikle doğruluk problemi olarak anlatılır. Aslında güvenilirlik problemi de olabilir.

Örneğin üç yönelim kaynağı düşünelim.

Yalnızca ortalama almak yeterli değildir. Kaynaklardan biri bozulduğunda:

• hangi sensörün ayrıştığı,
• ayrışmanın ne kadar sürdüğü,
• sensörün geçici mi kalıcı mı hatalı olduğu,
• sisteme ne kadar güvenileceği

belirlenmelidir.

Bu nedenle sensör füzyonu, durum kestirimi ile sağlık yönetiminin kesiştiği noktadır.

Bir İHA'nın kendi durumunu bilmesi kadar, bu bilgiye ne kadar güvenebileceğini bilmesi de önemlidir.

4.5. Sistem Entegrasyonu

Aviyonik mimari, tek tek iyi bileşenlerin toplamı değildir.

Mimari şu kararların tamamını kapsar:

• işlevlerin hangi bilgisayarda çalışacağı,
• sensörlerin nereye bağlanacağı,
• verinin hangi yoldan taşınacağı,
• gecikme bütçesi,
• güç dağıtımı,
• yedeklilik,
• yazılım bölümlendirmesi,
• bakım ve yerleşik test,
• hata durumunda yeniden yapılandırma.

Bu nedenle sistem entegrasyonunda "arayüz" terimi burada işlevsel bir ayrımı ifade eder.

İki alt sistem kendi başına doğru çalışıp birlikte yanlış davranabilir.

Örneğin:

• farklı koordinat sistemi,
• farklı endian,
• farklı zaman referansı,
• farklı birim,
• farklı işaret konvansiyonu,
• farklı güncelleme hızı

entegrasyon hatası üretmek için yeterlidir.

Aviyonik hata ayıklama bu yüzden yalnızca kaynak kod içinde yapılmaz. Kablodan protokole, sensörden ekrana kadar uçtan uca veri yolu izlenir.

4.5.1. Bölümlendirme ve ARINC 653

Bütünleşik modüler aviyonik yaklaşımında farklı işlevlerin ortak işlem kaynaklarını kullanması, arızaların ve zamanlama etkilerinin birbirine yayılmaması gereksinimini doğurur. ARINC 653 bu bağlamda uygulama yazılımı ile aviyonik işletim sistemi arasındaki APEX arayüzünü ve bölümlendirme modelini tanımlar.

Mekânsal bölümlendirme bir bölümün bellek veya kaynak hatasının diğer bölüme taşmasını sınırlamayı, zamansal bölümlendirme ise işlemci zamanının belirlenmiş pencereler içinde öngörülebilir dağıtılmasını hedefler. Bu konu burada mimari bağlamla sınırlıdır; ayrıntılı çalışma için ARINC 653 ile Zamansal ve Mekânsal Bölümlendirme notuna bakılabilir.

ARINC 653'ün güncel sürümlerinden Part 1 Supplement 6, 2024 sonunda yayımlanmıştır. Standart sürümünün güncel tutulması önemlidir; eski bir ders notundaki Supplement numarasını bugün de geçerli kabul etmek doğru değildir.

4.5.2. Sistem Düzeyi Tehlike Analizi: FMEA'nın Tamamlayıcısı Olarak STPA

FMEA bir bileşenin belirli bir arıza kipine girmesi halinde sistem üzerindeki etkileri düşünmek için güçlü bir yöntemdir. Ancak karmaşık aviyonik sistemlerde bütün bileşenler kendi yerel tanımlarına göre çalışırken etkileşim, zamanlama veya yanlış sistem durumu bilgisi nedeniyle de tehlike oluşabilir.

Bu nedenle bileşen arızası ile sistem düzeyi tehlike aynı kavram değildir:

bileşen arızası
-> etkisini analiz et

ama ayrıca

bileşenler çalışıyor
+ yanlış etkileşim / yanlış zaman / yanlış durum modeli
-> tehlikeli sistem davranışı

Nancy G. Leveson'ın STAMP yaklaşımı güvenliği yalnız arıza olasılıklarının toplamı olarak değil, sistem davranışının uygun kısıtlarla kontrol edilmesi problemi olarak ele alır. STPA ise bu düşünceyi tasarım ve tehlike analizinde kullanılabilecek sistematik sorulara dönüştürür.

İHA bağlamında önce kabul edilemez sonuç ile tehlikeli sistem durumu ayrılabilir. Ardından bu durumu önlemesi gereken sistem kısıtı tanımlanır:

kayıp / kabul edilemez sonuç
↓
tehlikeli sistem durumu
↓
güvenlik kısıtı
↓
kontrol yapısı
↓
kontrol eylemi + geri bildirim
↓
nedensel senaryo

Buradaki controller yalnız uçuş kontrol bilgisayarı anlamına gelmez. Otopilot, yer kontrol yazılımı, insan operatör, görev yönetimi veya başka bir üst seviye işlev aynı fiziksel sürecin davranışını etkileyebilir.

Bir kontrol eylemi en az dört açıdan sorgulanabilir:

1. Gerekli eylem verilmediğinde tehlike oluşuyor mu?
2. Eylem belirli bir sistem durumunda verilmemesi gerekirken veriliyor mu?
3. Doğru eylem yanlış zamanda veya yanlış sırada mı veriliyor?
4. Eylem gerekenden uzun/kısa sürüyor ya da yanlış zamanda mı sonlandırılıyor?

Örneğin soyut bir uçuş modu geçişinde problem yalnız MODE_CHANGE komutunun bit değerleri değildir. Güvenli davranış şu bağlamlara bağlı olabilir:

mevcut uçuş modu
konum / irtifa / hız durumu
sensör verisinin yaşı
otopilotun iç durum modeli
operatörün gördüğü durum
komutun sırası
komutun alındığına ilişkin geri bildirim

Bu değişkenlerden biri fiziksel gerçekle uyuşmuyorsa yazılım sentaktik olarak geçerli bir komut üretirken sistem düzeyinde yanlış davranabilir.

4.5.2.1. Process Model Uyuşmazlığı

Denetleyici kararını fiziksel dünyanın kendisinden değil, sensörler ve önceki durumlar üzerinden oluşturduğu bir iç modelden verir. Bu model gerçeğin gerisinde kaldığında doğru algoritma + yanlış durum bilgisi birleşimi tehlikeli olabilir.

Yer kontrol yazılımında bu fikir özellikle önemlidir:

fiziksel uçuş durumu
↓
sensör / aviyonik veri
↓
telemetri ve haberleşme
↓
yer kontrol yazılımının durum modeli
↓
operatörün algıladığı durum
↓
komut

Bu zincirin herhangi bir yerindeki gecikme, stale data, eksik geri bildirim veya mod uyuşmazlığı komutun bağlamını değiştirir. Bu nedenle 26. bölümdeki veri yaşı, alarm önceliği, komut doğrulama ve kayıt ilkeleri yalnız UI/UX tercihi değil, güvenlik kontrol yapısının parçalarıdır.

4.5.2.2. FMEA ile STPA'yı Rakip Yöntemler Olarak Görmemek

FMEA özellikle fiziksel/elektronik bileşen arızalarının etkisini sistematik biçimde görünür kılar. STPA ise yazılım yoğun, insan dahil ve çok sayıda denetleyicinin etkileştiği yapılarda arıza olmadan da ortaya çıkabilen yetersiz kontrol senaryolarını araştırmak için farklı bir mercek sağlar.

Pratikte:

FMEA -> hangi bileşen nasıl arızalanabilir ve etkisi nedir?
STPA -> hangi sistem etkileşimi veya kontrol eylemi tehlikeli durumu mümkün kılabilir?

soruları birbirini tamamlayabilir.

STPA/STAMP, FMEA'nın yerine geçen bir teknik değildir; tehlikeleri bileşen arızalarının ötesinde kontrol yapısı, yanlış kontrol eylemi ve yetersiz geri besleme açısından inceleyen tamamlayıcı bir sistem güvenliği yaklaşımıdır. Aviyonikte özellikle insan, yazılım, sensör, ağ ve eyleyici etkileşiminin birlikte değerlendirilmesine yardımcı olur.

4.6. COTS Bileşenleri ve Kritik Sistem Ayrımı

Ticari hazır bileşenler maliyet ve geliştirme süresi açısından önemli avantaj sağlar. Özellikle yer sistemlerinde standart bilgisayar donanımı ve yazılım bileşenlerinden yararlanmak doğaldır.

Ancak uçuş kritik işlevlerde aynı rahatlıkla kullanılamaz.

Değerlendirilmesi gereken başlıklar şunlardır:

• yaşam döngüsü,
• dokümantasyon,
• geriye dönük uyumluluk,
• deterministik davranış,
• çevresel dayanım,
• doğrulanabilirlik,
• tedarik sürekliliği,
• yazılım bütünlüğü.

Kritik sistemde "piyasada yaygın kullanılıyor" güvenlik kanıtı değildir.

COTS değerlendirmesinde bileşenin yalnız işlev listesine bakmak da yeterli değildir. Kullanılan tam sürümün, derleyici veya araç zincirinin, yapılandırmanın, bilinen kusurların, güncelleme politikasının ve tedarikçinin yaşam döngüsü davranışının izlenebilir olması gerekir. Aynı ürün adını taşıyan iki sürüm farklı hata profiline sahip olabilir. Kritik sistem açısından yeniden üretilebilir yapı ve bileşen kökeninin bilinmesi, teknik yetenek kadar önemlidir.

4.7. Aviyonikte Uçtan Uca Zaman Bütçesi ve Hata Sınırlama

Gerçek zamanlı mühendislikte ortalama performans yerine uçtan uca gecikme bütçesi, en kötü veya yüksek yüzdelikli gecikme, jitter, kaynak doygunluğu ve hata sonrası toparlanma birlikte ele alınır. Aviyonik işlem hattında sensör edinimi, bus aktarımı, filtreleme, karar ve actuator komutu ayrı servis ve kuyruk süreleri ekler; tek bir algoritmanın mikrobenchmark'ta hızlı olması, worst-case end-to-end deadline'ın veya jitter sınırının karşılandığını göstermez. Sınırlar, overload davranışı ve degradasyon biçimi açık tanımlanmalıdır.

• Sensör-okuma-kontrol-aktüatör zincirinde her aşamanın latency bütçesini ayrı tanımlamak.
• Jitter ve deadline miss olaylarını ortalama çevrim süresinden ayrı izlemek.
• Fault containment region ve recovery davranışını iletişim mimarisiyle birlikte tasarlamak.

Üçlü yedekliliğin güvenilirliğini varsayımlarıyla hesaplamak. Üç bağımsız algılayıcının her birinin belirli görev aralığında yanlış sonuç verme olasılığı p = 0,01 ve çoğunluk oylamasının hata yapması için en az ikisinin yanlış olması gerektiği varsayılsın. İkili hata olayları ile üçlü hata birlikte sayıldığında çoğunluğun yanlış olma olasılığı P_fail = 3p²(1−p) + p³ = 0,000298, yani yaklaşık %0,0298 olur. Tek algılayıcının %1 hata olasılığına göre önemli bir iyileşme görünür. Ancak bu hesap bağımsızlık ve aynı hata tanımına dayanır. Üç algılayıcının ortak enerji kaynağı, aynı bozuk kalibrasyon veya aynı çevresel etki nedeniyle birlikte yanlış ölçmesi halinde formül iyimser kalır. Oylamanın gecikmesi, aykırı ölçüm tespiti ve geçersiz veride güvenli moda geçişi ayrıca tasarlanmalıdır.

4.8. Yedek Sensörlerde Ortak Nedenli Hata

Aynı fiziksel büyüklüğü ölçen iki sensörün bulunması, iki bağımsız hata kaynağı bulunduğu anlamına gelmez. Aynı güç hattı, ortak saat, aynı yazılım dönüşümü veya ortak montaj geometrisi, her iki kanalda benzer hatalar doğurabilir. Basit çoğunluk oylaması, yalnız aynı nedenden etkilenmeyen ölçümler için bağımsızlık varsayımı makul olduğunda güçlüdür. İki kanalın aynı değeri vermesi, ortak referans hatasını dışlamaz.

Sensör uyuşmazlığı, yalnız \(\lvert y_1-y_2\rvert\) farkına göre değil, zaman eşitlemesi, ölçüm belirsizliği ve dinamik rejimle birlikte değerlendirilir. Örneğin farklı filtre gecikmeleri, hızlı manevrada fiziksel bir arıza olmadan da ölçümler arasında büyük geçici fark oluşturabilir. İzleme modeli; normal geçişleri, sensörün donmuş çıkışını, veri yaşını ve fiziksel olarak mümkün olmayan değişim hızlarını ayırt etmelidir.

Bir sensör dışlandığında hangi kontrol moduna geçileceği, hangi performans sınırlarının daralacağı ve operatöre nasıl bilgi verileceği önceden tanımlanır. Yedeklilik tasarımının doğrulanması, tek kanalın kopması kadar ortak güç kaybı, hatalı zaman tabanı ve birbirini doğrulayan fakat aynı biçimde yanılan kanalları da kapsar. Böylece 'yedek kanal var' ifadesi, ölçülmüş hata toleransı iddiasıyla karıştırılmaz.

4.9. ARINC 653 Bölümlendirme ve Zamanlama Sözleşmesi

ARINC 653 yaklaşımında zaman ve bellek bölümlendirmesi, uygulamaların birbirinin kaynaklarını keyfî biçimde tüketmesini sınırlandıran mimari araçlardır. Bölümlere ayrılan işlem zamanı, major time frame içinde belirlenmiş pencerelerle yönetilebilir; ancak bölüm içi görevlerin deadline'ları, bölümler arası iletişim gecikmesi ve hata geçişleri ayrıca analiz edilir. Bölüm izolasyonu tek başına tüm sistemin işlevsel güvenliğinin kanıtı değildir.

Doğrulama, zaman penceresi taşması, bölümler arası iletişim tamponları, görev öncelikleri, kritik kesitler, watchdog davranışı ve en kötü durum yürütme süresi varsayımlarını kapsar. Statik analiz ve kodlama kuralları çalışma zamanı zamanlamasının ölçülmesiyle tamamlanır. Planlama sonuçları hedef RTOS sürümü ve gerçek donanım özellikleri belirtilmeden farklı platformlara genellenmez.

4.10. Manevra ile Sensör Arızasının İnovasyon Temelli Ayrımı

Sabit hız varsayımıyla çalışan bir kestiricide ani ve gerçek manevra büyük ölçüm artığı üretir. Bu artık tek başına GNSS veya ataletsel sensör arızasını göstermez. Uçuş dinamiğine uygun alternatif modeller, zaman damgası eşleşmesi, bağımsız ölçüm kanalları ve ortak nedenli arıza olasılığı birlikte sınanır. Ölçüm reddi sistemi yanlış bir konum kestirimine kilitlememelidir. NIS, çok modelli Kalman ve dayanıklı ölçüm süzme yöntemlerinin kuramsal temeli Anomali Algılama dersinde açıklanır.

Ünite 5: Görev Yönetimi, Komut Güvenliği ve Operatör Arayüzü

5.1. Görev ve Mod Yönetimi

Bir İHA'da görev yönetimi yalnız rota noktalarının sıralanması değildir. Uçuş modu, navigasyon kaynağı, haberleşme durumu, enerji seviyesi, görev fazı ve arıza durumu birlikte değerlendirilir. Aynı coğrafi hedef, farklı sistem durumlarında farklı biçimde yürütülebilir.

Mod geçişleri açık bir durum makinesiyle modellenmelidir. Örneğin:

MANUAL
  ↓
ASSISTED
  ↓
AUTO_MISSION
  ↓
RETURN / HOLD / LAND

Bu akış yalnız normal geçişleri gösterir. Gerçek sistemde geçişlerin hangi koşullarda reddedileceği, hangi hata durumunun hangi güvenli moda yol açacağı ve operatör müdahalesinin ne zaman kabul edileceği de tanımlanmalıdır.

Bir modun ekranda seçilmiş görünmesi, platformun o moda gerçekten geçtiği anlamına gelmez. Arayüz, istek ile doğrulanmış sistem durumunu ayırmalıdır.

5.2. Komut Yaşam Döngüsü

Yer kontrolünden gönderilen komutlar için en az şu durumların ayrılması yararlıdır:

oluşturuldu
→ iletildi
→ alındı
→ doğrulandı
→ yürütülüyor
→ tamamlandı / reddedildi / zaman aşımı

Komutun iletilmiş olması fiziksel sonucun gerçekleştiğini kanıtlamaz. Özellikle kritik komutlarda işlem kimliği, tekrar önleme, zaman aşımı, açık onay ve gerektiğinde son durum doğrulaması gerekir.

Bağlantı kesilirse istemcinin komutun karşı tarafta uygulanıp uygulanmadığını bilemediği durumlar oluşabilir. Bu belirsizlik, kör yeniden deneme ile giderilmemelidir. İdempotent komutlar, benzersiz işlem kimlikleri ve açık durum sorgulama mekanizmaları bu nedenle önemlidir.

Komut güvenliği yalnız yetkilendirme problemi de değildir. Geçerli bir kullanıcı, yanlış uçuş fazında teknik olarak geçerli fakat operasyonel olarak tehlikeli bir komut üretebilir. Sistem, kullanıcı yetkisi ile durum geçerliliğini ayrı denetlemelidir.

5.3. Alarm, Öncelik ve Durumsal Farkındalık

Operatör arayüzü mümkün olan en fazla veriyi göstermek yerine karar için gerekli durumu görünür kılmalıdır. Çok sayıda eşit öncelikli uyarı, kritik olayın fark edilmesini güçleştirebilir.

Bir alarm modeli en az şu bilgileri ayırabilir:

• önem derecesi,
• kaynak alt sistem,
• oluşma zamanı,
• aktif/pasif durumu,
• onaylanıp onaylanmadığı,
• tekrar sayısı,
• ilişkili uçuş modu,
• önerilen veya otomatikleşmiş tepki.

Alarmın nedeni ortadan kalktığında kaydın silinmesi yerine yaşam döngüsünün korunması, uçuş sonrası inceleme açısından daha değerlidir.

Durumsal farkındalık yalnız ekrandaki sayısal değerlerden oluşmaz. Operatörün platformun hangi modda olduğunu, otomasyonun hangi görevi yürüttüğünü ve bir sonraki beklenen davranışın ne olduğunu anlayabilmesi gerekir. Mod belirsizliği veya otomasyon sürprizi, arayüzün teknik olarak doğru veri göstermesine rağmen operasyonel riski artırabilir.

5.4. Kayıt, İzlenebilirlik ve Uçuş Sonrası Analiz

Gerçek zamanlı gösterim ile olay sonrası açıklanabilirlik farklı gereksinimlerdir. Arayüz anlık durumu özetleyebilir; ancak olay analizi için ham veya yeterince ayrıntılı kayıt gerekir.

5.4.1. Durumun Tek Anlamlı Gösterimi

Aynı değişken farklı ekranlarda farklı birim, yuvarlama veya durum koduyla gösterilmemelidir. Gösterim dönüşümü tek bir tanımlı kaynağa dayanmalıdır.

5.4.2. Eski Veri ile Yeni Verinin Ayrılması

Bir değerin son alınan değeri olması, hâlâ geçerli olduğu anlamına gelmez. Ekranda veri yaşı, timeout veya geçerlilik durumu gerektiğinde görünür olmalıdır.

5.4.3. Alarm Önceliği

Kritik alarm, bilgi mesajı ve bakım uyarısı aynı görsel ağırlıkta ele alınmamalıdır. Önceliklendirme, arayüz tasarımının yanında sistem güvenilirliği konusudur.

5.4.4. Komut Doğrulama

Kritik komutlarda gönderildi durumu ile uygulandı durumu ayrılmalıdır. Yalnız aktarım katmanı ACK'i fiziksel eylemin kanıtı değildir.

5.4.5. Kayıt ve İzlenebilirlik

Olay kaydı; zaman, kaynak, uçuş modu, yazılım sürümü ve ilgili durum değişkenlerini ilişkilendirebildiğinde anlamlıdır. Uçuş sonrası yeniden yürütme veya zaman çizgisi analizi, yalnız hata ayıklama değil doğrulama ve bakım için de kullanılabilir.

Bu ünitenin temel ilkesi şudur: operatör arayüzü, komut kanalı ve kayıt sistemi aynı gerçek durum modelinin farklı görünümleri olmalıdır.

Ünite 6: İnsan Faktörü, Otonomi, Güvenilir Yazılım ve Uçtan Uca Mimari

6.1. İHA'da İnsan Faktörü

İHA'da pilot araçta değildir; insan faktörü ortadan kalkmaz.

Operatörün:

• gecikmeli video ile çalışması,
• çok sayıda durumu aynı anda izlemesi,
• otomatik uçuş modlarını anlaması,
• bağlantı kesintisini yönetmesi,
• sistemin ne yaptığını ve neden yaptığını takip etmesi

gerekir.

Otomasyon arttıkça yeni bir problem ortaya çıkar: otomasyon sürprizi.

Sistem teknik olarak doğru bir moda geçmiş olabilir; fakat operatör bunun nedenini anlamıyorsa durum farkındalığı zayıflar.

İyi bir arayüz yalnızca mevcut durumu göstermemeli, sistem davranışını anlaşılır kılmalıdır.

6.2. Otonomi ile Uzaktan Kontrol Arasındaki Fark

Uzaktan kontrol edilen araçta insan sürekli kumanda üretir.

Otonom sistemde ise insan daha yüksek seviyeli hedef verir; araç alt düzey kontrol kararlarını kendi üretir.

Bu fark şu şekilde özetlenebilir:

Uzaktan kontrol: insan → kumanda yüzeyi

Otonom uçuş: insan → görev hedefi → uçuş yönetimi → otopilot → kontrol yüzeyi

Otonom taksi, kalkış, rota takibi ve iniş gibi işlevler; düşük seviyeli sürekli manuel kumanda ile yüksek seviyeli gözetimli görev yönetimi arasındaki ayrımı göstermek için kullanılabilecek genel örneklerdir. Burada temel mühendislik sorusu, hangi kararların araç üzerinde üretildiği ve insanın hangi durumlarda hangi yetkiyle devreye girdiğidir.

Otonomi "insanın olmadığı sistem" değildir.

Daha doğru ifade şudur:

İnsan ile kontrol döngüsü arasındaki soyutlama seviyesinin yükselmesidir.

6.3. İnsansız Hava Aracı Yazılımlarının Ayırt Edici Özellikleri

İHA yazılımı klasik masaüstü veya web uygulamasından birkaç temel nedenle ayrılır.

6.3.1. Fiziksel Dünya ile Doğrudan Bağlıdır

Yanlış çıktı yalnızca ekranda yanlış bilgi anlamına gelmeyebilir; fiziksel sistemi etkileyebilir.

6.3.2. Zaman Önemlidir

Doğru cevap geç geldiğinde yanlış cevap olabilir.

6.3.3. Donanım Kusursuz Değildir

Sensör gürültüsü, ağ kaybı ve güç dalgalanması gerçek sistemin parçasıdır.

6.3.4. Hata Durumları Normaldir

Bağlantı kaybı, sensör ayrışması veya yedek kanala geçiş önceden modellenmelidir.

6.3.5. Gözlemlenebilirlik Gerekir

Kayıt, telemetri ve durum kaydı olmadan saha problemlerini tekrar üretmek zorlaşır.

6.3.6. Sistem Sınırları Geniştir

Bir hata gömülü işlemciden yer kontrol ekranına kadar herhangi bir katmanda olabilir.

Bu özellikler, aviyonik yazılımı sistem mühendisliği disipliniyle birlikte düşünmeyi zorunlu kılar.

Bu dersin kontrol tarafı Otomatik Kontrol, ölçüm ve örnekleme tarafı Sinyaller ve Sistemler, işlemci ve kesme davranışı Mikroişlemciler, zamanlama ve süreç yönetimi İşletim Sistemleri, veri aktarımı ise Bilgisayar Ağları dersleriyle doğrudan kesişir. Yer kontrol istasyonundaki insan-makine etkileşimi için UI/UX Mühendisliği, doğrulama zinciri için Yazılım Test Mühendisliği tamamlayıcı bağlam sağlar.

6.4. Güvenilirlik için Temel Yazılım İlkeleri

Aviyonik veya benzeri kritik gerçek zamanlı sistemlerde bazı ilkeler geneldir.

6.4.1. Belirsiz Durum Bırakmamak

Bir veri geçersizse "son bilinen değer" ile "geçerli güncel değer" aynı biçimde sunulmamalıdır.

6.4.2. Gizli Başarısızlıktan Kaçınmak

Sessizce yanlış sonuç üretmek, açıkça hata vermekten daha tehlikeli olabilir.

6.4.3. Deterministik Davranış

Aynı koşullarda öngörülebilir zamanlama ve durum geçişleri tercih edilir.

6.4.4. Hata Yayılımını Sınırlamak

Bir alt sistemin bozulması diğer bağımsız işlevleri gereksiz yere etkilememelidir.

6.4.5. Kaynak Kullanımını Sınırlandırmak

Bellek, CPU ve kuyruk büyümesi kontrol altında tutulmalıdır.

6.4.6. Gözlemlenebilirlik

Sistem, kendi durumunu açıklayabilecek kadar kayıt üretmelidir.

Bu ilkeler yalnızca havacılığa özgü değildir. Finans, kamu güvenliği, telekomünikasyon ve endüstriyel kontrol gibi kritik sistemlerde de aynı düşünce biçimi geçerlidir.

6.5. Uçuş Fiziği ile Yazılım Arasındaki Bağ

Aviyonik mühendisliğin en öğretici taraflarından biri, yazılım ile fizik arasındaki sınırın kaybolmasıdır.

Bir yazılım değişkeni:

airspeed

yalnızca kayan noktalı sayı değildir.

Arkasında:

• pitot/statik ölçüm,
• kalibrasyon,
• atmosfer modeli,
• filtreleme,
• örnekleme zamanı,
• veri yolu,
• uçuş kontrol kazancı,
• operatör göstergesi

bulunabilir.

Benzer şekilde:

roll

yalnızca ekrandaki bir açı değildir.

IMU ölçümleri, koordinat dönüşümü, durum kestirimi ve kontrol döngüsünün ortak sonucudur.

Bu nedenle aviyonik yazılımda değişken adı ile fiziksel anlam arasındaki bağ açık biçimde korunmalıdır.

6.6. Sensörden Ekrana Uçtan Uca Veri Zinciri

Bir telemetri değerini örnek alalım:

irtifa

Bu değer aşağıdaki zincirlerden biriyle oluşabilir:

basınç sensörü → ADC → hava veri hesabı → uçuş bilgisayarı → paketleme → veri bağı → yer istasyonu → ayrıştırma → UI

veya:

GNSS → seyrüsefer çözümü → uçuş bilgisayarı → veri bağı → yer istasyonu

veya:

INS + barometrik veri → füzyon → kestirilmiş irtifa → telemetri

Dolayısıyla "irtifa yanlış görünüyor" problemi tek bir kaynağa indirgenemez.

İyi hata ayıklama yaklaşımı veriyi uçtan uca izler:

1. kaynak ölçüm doğru mu?
2. dönüşüm doğru mu?
3. paket doğru mu?
4. zaman damgası doğru mu?
5. veri hedefe ulaştı mı?
6. ayrıştırma doğru mu?
7. UI doğru birim ve ölçekle gösteriyor mu?

Bu yöntem 2015'te aviyonik hata ayıklama sırasında öğrendiğim ve daha sonra farklı kritik sistemlerde sürekli kullandığım en kalıcı mühendislik yaklaşımlarından biridir.

6.7. Yedeklilik Desenleri Üzerinden Mimari Okuma

Kamuya açık bir aviyonik mimariyi incelerken ürün adından çok güvenilirlik desenlerine bakmak daha genellenebilir sonuç verir. Yedekli uçuş bilgisayarları, birden fazla sensör kanalı, çapraz haberleşme, ayrık güç yolları ve bağımsız eyleyici kanalları aynı amaca hizmet etse de aynı hata modelini çözmez.

6.7.1. Hesaplama Yedekliliği

Birden fazla işlem kanalı, tek işlemci arızasına karşı tolerans sağlayabilir. Ancak bütün kanallar aynı yazılım kusurunu, aynı yanlış gereksinimi veya aynı güç kaynağını paylaşıyorsa ortak nedenli hata riski devam eder.

6.7.2. Sensör Yedekliliği

Birden fazla IMU veya hava verisi kaynağı yalnız çoğunluk oylaması için kullanılmaz. Tutarsızlık belirleme, bias izleme, arızalı kanalın dışlanması ve belirsizlik yönetimi de tasarımın parçasıdır.

6.7.3. Haberleşme Yedekliliği

İki fiziksel bağlantı bulunması yeterli değildir. Yönlendirme, hata belirleme ve geçiş davranışı da bağımsızlık modeline uygun olmalıdır. Aynı yazılım durumu her iki bağlantıyı da yanlış yönetiyorsa fiziksel yedeklilik beklenen güvenilirliği üretmez.

6.7.4. Güç ve Eyleyici Yedekliliği

Güç dağıtımı, servo sürücüleri ve eyleyiciler için yedeklilik; ortak kablo, ortak regülatör, ortak mekanik bağlantı veya tek hata noktasının nerede kaldığıyla birlikte değerlendirilmelidir.

6.7.5. Otonom Kalkış, İniş ve Seyrüsefer

Otomasyonun kapsamı arttıkça durum kestirimi, mod yönetimi, arıza yönetimi ve insan-makine arayüzü arasındaki sözleşmeler daha kritik hâle gelir. Otonomi, ayrı bir “zeka modülü” eklemekten çok bütün sistemin karar ve geri kazanım zincirini genişletir.

Mimari okumanın amacı özellik listesi çıkarmak değil, hangi hata varsayımının hangi mimari mekanizmayla sınırlandığını anlamaktır.

6.8. İnsan-Makine Ekibinde Durumsal Farkındalık ve Dayanıklılık

Aviyonikte otomasyon, sensör füzyonu ve uçuş yönetimi yalnız teknik doğruluk problemi değildir. Pilot, operatör veya yer kontrol ekibi; sistemin ne bildiğini, hangi otomasyon kipinde olduğunu, hangi verinin güvenilir olmadığını ve mevcut eğilimin uçuş hedefleri açısından ne anlama geldiğini anlayabilmelidir. Bu konu Bilişsel Sistemler Mühendisliği ile doğrudan kesişir.

6.9. Kip Farkındalığı ve Otomasyon Sürprizi

Otomasyonun hangi kipte olduğu görünür değilse veya kip geçişi kullanıcının beklentisinden farklı gerçekleşirse, teknik sistem doğru çalışsa bile insan-makine ortak sistemi yanlış davranabilir. Bu nedenle kritik otomasyonlarda şu bilgiler tasarım nesnesidir:

• etkin kip,
• kipi değiştiren olay,
• otomasyonun şu anda kontrol ettiği değişkenler,
• insanın devralabileceği eylemler,
• sensör veya model güvenilirliğini azaltan koşullar,
• devralma sonrası beklenen geçici davranış.

6.10. Durumsal Farkındalık

Durumsal farkındalık yalnız uçuş parametrelerini görmek değildir. İlgili öğelerin algılanması, uçuş bağlamındaki anlamlarının kavranması ve eğilimlerin yakın gelecek için öngörülmesini içerir. Bu nedenle iyi bir uçuş veya yer kontrol ekranı ham değerleri çoğaltmak yerine enerji, marj, rota, tehdit, bağlantı ve sistem sağlığı arasındaki operasyonel ilişkileri anlaşılır kılmalıdır.

6.11. Dayanıklılık ve Bozulmuş Kip

Aviyonik sistemlerin önemli bir tasarım problemi, kısmi arızada hangi yeteneklerin korunacağıdır. Sensör kaybı, haberleşme zayıflaması veya yardımcı işlev arızası bütün sistemin aynı biçimde davranmasını gerektirmez. Güvenli çekirdek fonksiyonların korunması ve insanın yeni sınırları anlayabilmesi, kademeli hizmet kaybının iki tamamlayıcı yönüdür.

Bu nedenle degraded mode testi yalnız yazılım çıktısının doğru olup olmadığını değil, insanın hangi bilgiyle devralacağını ve yeni operasyonel marjları doğru anlayıp anlamadığını da kapsamalıdır.

Ünite 7: Doğrulama, Degradasyon ve Mühendislik İlkeleri

7.1. Laboratuvar Doğruluğu ile Uçuş Güvenilirliği Arasındaki Fark

Bir aviyonik işlev laboratuvarda doğru sonuç üretse bile uçuş ortamında aynı güvenceyi otomatik olarak taşımaz. Zamanlama değişkenliği, sensör gürültüsü, kablo ve güç sorunları, sıcaklık, titreşim, haberleşme kaybı, yeniden başlatma ve beklenmeyen mod geçişleri sistem davranışını değiştirebilir.

Bu nedenle doğrulama tek bir test seviyesine bırakılmaz. Model-in-the-loop, software-in-the-loop, processor-in-the-loop, hardware-in-the-loop ve kontrollü uçuş testleri farklı hata sınıflarını görünür kılar. Her test katmanının kapsamadığı varsayımlar ayrıca yazılmalıdır.

7.2. Tasarım Kararını Gereksinim ve Kanıta Bağlamak

Güvenilir aviyonik geliştirmede önemli soru “bu yöntem çalışıyor mu?” değil, “hangi gereksinimi, hangi varsayımlar altında, hangi kanıtla karşılıyor?” sorusudur.

Bir gereksinim zinciri şu biçimde izlenebilir:

sistem tehlikesi
→ güvenlik gereksinimi
→ alt sistem gereksinimi
→ yazılım/donanım tasarımı
→ doğrulama senaryosu
→ test sonucu / analiz kanıtı

Bu zincirin kopması, test sayısı yüksek olsa bile güvenceyi zayıflatır.

7.2.1. Fizik, Yazılım Gereksiniminin Parçasıdır

Yazılımın denetlediği hava aracı dinamiği, sensör sınırı ve eyleyici doygunluğu “harici detay” değildir. Kontrol ve emniyet gereksinimleri fiziksel sınırlarla birlikte yazılmalıdır.

7.2.2. Ölçüm ile Gerçek Aynı Şey Değildir

Her ölçüm hata, gecikme ve geçerlilik bilgisi taşır. Bir değeri kesin gerçek gibi kullanmak, durum kestirimi ve arıza yönetimini kırılgan hâle getirir.

7.2.3. Ağ Hataları Uygulama Mantığının Parçasıdır

Paket kaybı, yeniden sıralama, tekrar, gecikme ve bağlantı kopması yalnız ağ katmanı problemi değildir. Görev ve kontrol mantığının bu durumlar altında nasıl davranacağı tanımlanmalıdır.

7.2.4. Yedeklilik Mimari Problemdir

Aynı hata kaynağını paylaşan iki kanal, iki bağımsız güvenilirlik kanalı değildir. Ortak nedenli hata analizi yedeklilik tasarımının parçasıdır.

7.2.5. Arayüz Kritik Bileşendir

Operatör yanlış veya eski durum görüyorsa alt katmanların doğru hesap yapması yeterli olmayabilir. İnsan-makine arayüzü güvenilirlik zincirine dahildir.

7.2.6. Kayıt ve Telemetri Sonradan Eklenen Özellik Değildir

Olay sonrası açıklanabilirlik, bakım ve doğrulama için yeterli veri baştan tasarlanmalıdır. Yalnız debug logu, sistematik olay kaydının yerini tutmaz.

7.2.7. Otonomi Daha Fazla Sistem Sorumluluğu Getirir

Otonom işlev arttıkça karar yetkisinin sınırı, fallback davranışı, operatör müdahalesi ve güvenli durum tanımı daha açık olmalıdır.

7.3. Hata Muhafazası ve Deterministik Degradasyon

Bir alt sistem arızalandığında platformun hangi yetenekleri koruyacağı ve hangilerini bırakacağı önceden tanımlanmalıdır. Tam görev yeteneğinden sınırlı moda, hold durumuna, return davranışına veya kontrollü inişe geçiş rastlantısal exception zinciri olmamalıdır.

Fault-containment region yaklaşımı, bir hatanın hangi sınır içinde tutulacağını açıklaştırır. Watchdog, bus guardian, süreç izolasyonu ve güç anahtarlama gibi mekanizmalar ancak tanımlı hata modeliyle birlikte anlam kazanır.

7.4. Aviyonik Kararı Gereksinim ve Kanıta Bağlamak

Zamanlama ve arayüz sözleşmeleri ölçülebilir olmalıdır. Mesaj periyodu, maksimum gecikme, timeout, veri birimi, koordinat sistemi ve geçerlilik süresi açık değilse iki ayrı alt sistem kendi başına doğru çalışırken birlikte yanlış davranabilir.

Aynı ilke değişiklik yönetimi için de geçerlidir. Yazılım sürümü, parametre seti, kalibrasyon ve donanım revizyonu birlikte izlenmezse test edilen konfigürasyon ile uçan konfigürasyon arasında fark oluşabilir.

7.5. Otonomi ve Yapay Zekânın Aviyonikteki Yeri

Makine öğrenmesi; algılama, sınıflandırma, kestirim, anomali belirleme veya karar desteği gibi işlevlerde kullanılabilir. Bununla birlikte öğrenilmiş model çıktısı, güvenilirlik zincirindeki tek kanıt hâline getirilmemelidir.

Model tabanlı bileşenlerde en az şu sorular yanıtlanmalıdır:

• eğitim ve doğrulama verisi operasyon alanını ne ölçüde temsil ediyor?
• dağılım dışı durumda çıktı nasıl sınırlandırılıyor?
• güven skoru hangi karar katmanında kullanılacak?
• model başarısız olduğunda güvenli fallback nedir?
• veri ve model sürümü nasıl izleniyor?
• gecikme ve kaynak kullanımı worst-case bütçeye uyuyor mu?

Kritik bir mimaride yapay zekâ katmanı, sistemin geri kalanındaki durum makinesi, zaman bütçesi ve hata yönetiminden bağımsız tasarlanamaz.

7.6. Sonuç

Aviyonik mühendisliğinin temel problemi elektronik bileşenleri veya yazılım modüllerini tek tek çalıştırmak değildir. Ölçüm, zaman, hesaplama, iletişim, kontrol, operatör ve hata yönetimini aynı güvenilirlik modeli içinde tutmaktır.

Uçuş fiziği kontrol sınırlarını belirler. Sensörler fiziksel dünyayı eksik ve gürültülü ölçer. Durum kestirimi bu ölçümü modele dönüştürür. Kontrol yasaları eyleyicilere komut üretir. Haberleşme ve yer kontrolü durumu operatöre taşır. Kayıt ve doğrulama mekanizmaları sistemin neden öyle davrandığını sonradan açıklanabilir kılar.

Bu zincirin herhangi bir yerinde zaman, geçerlilik veya durum anlamı kaybolursa alt bileşenlerin tek tek doğru olması sistem düzeyinde yeterli değildir.

Kaynakça

• Brendan Gregg. Systems Performance: Enterprise and the Cloud. Pearson Education, 2014.
• European Union Aviation Safety Agency. Artificial Intelligence Concept Paper Issue 2: Guidance for Level 1 & 2 Machine-Learning Applications. EASA, 2024.
• FAA AC 20-115D, Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( )
• MISRA C:2025 Addendum 6
• Heather Adkins; Betsy Beyer; Paul Blankinship; Piotr Lewandowski; Ana Oprea; Adam Stubblefield. Building Secure & Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems. O’Reilly Media, 2020.
• Mor Harchol-Balter. Performance Modeling and Design of Computer Systems: Queueing Theory in Action. Cambridge University Press, 2013.
• Nancy G. Leveson. Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press, 2011.
• R. P. G. Collinson. Introduction to Avionics Systems, 3rd ed. Springer, 2011.
• SAE, ARINC 429 Part 1 Supplement 19
• SAE, ARINC 653 Part 1 Supplement 6
• U.S. DoD ASSIST, MIL-STD-1553
• Simo Särkkä; Lennart Svensson. Bayesian Filtering and Smoothing, 2nd ed.. Cambridge University Press, 2023. https://doi.org/10.1017/9781108917407