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

Bu ders notunun ilk sürümü Eylül 2015'te, Baykar'daki bilgisayar mühendisliği stajım sırasında üzerinde çalıştığım aviyonik sistemler, gömülü yazılım, MISRA C, statik kod analizi, telemetri ve İHA sistemlerine ilişkin teknik birikim temel alınarak hazırlanmıştır. İçerik, özgün kapsamı korunarak Eylül 2026'da güncel standartlar ve kamuya açık teknik bilgiler doğrultusunda gözden geçirilmiş ve genişletilmiştir.

Aviyonik sistemleri; temel uçuş fiziği, hava aracı dinamiği, seyrüsefer, sensör füzyonu, otomatik uçuş, veri haberleşmesi, yer kontrol istasyonu ve hata toleransı üzerinden ele alan mühendislik notları. İnsansız hava araçlarında bu başlıkların nasıl tek bir bütün hâline geldiği, Bayraktar TB2'nin açık kaynaklarda yayımlanmış özellikleri ve 2015 Baykar staj deneyimimle birlikte değerlendirilmektedir.

Bu konu benim için yalnızca teorik bir havacılık başlığı değildir. 2015'te Baykar'da bilgisayar mühendisliği stajı yaparken İkitelli'de TMS570 ve lwIP ile gömülü ağ çalışmalarıyla başlayıp Keşan'da gerçek İHA sistemleri üzerinde aviyonik hata ayıklama, C/C# statik analiz ve yer kontrol telemetrisiyle çalıştım. Aynı yıl Bayraktar TB2 ikinci seri teslimat, ilk 1000 uçuş saatinin tamamlanması ve ilk mühimmat gösterimi gibi kilometre taşlarına ulaşıyordu. Bugün uçuş kontrolü, telemetri, sensör füzyonu veya hata toleransını ayrı ders başlıkları olarak ele almak kolaydır; sahada ise bunların aynı sistemin birbirine bağlı parçaları olduğu çok daha belirgin görülür.

Stajdaki statik analiz çalışmam, sonradan eklenen bir kalite kontrol adımı olarak başlamadı. Çalışmanın ilk aşamasında ANSI ve ISO çerçevesini inceleyerek özellikle MISRA C kurallarını belgeledim; ardından geliştirdiğim analiz yazılımında bu kuralların otomatik denetlenmesini öncelikli işlevlerden biri olarak gerçekledim. Böylece kodlama standardı, analiz aracı ve proje akışı daha başlangıçta aynı problem olarak ele alınmış oldu. Bu yaklaşımın ayrıntılarını MISRA C ve Statik Kod Analizi notunda ayrıca inceliyorum.

Bu notta yalnızca kamuya açık bilgiler kullanılmıştır. Bayraktar TB2'ye ilişkin güncel teknik özellikler 2015 konfigürasyonuna geriye doğru uygulanmamıştır; platform yıllar içinde geliştiği için farklı tarihli resmî dokümanlarda bazı sayısal değerlerin değişmesi doğaldır.

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

1. Aviyonik sistem nedir?

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.

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.

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.

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.

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.

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.

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.

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ü

6. 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.

7. IMU, jiroskop ve ivmeö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.

8. 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.

9. 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.

9.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.

9.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.

10. 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

11. İ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.

Bu bakış benim 2015'teki staj deneyimim açısından da önemlidir. Keşan'da gördüğüm sistem, yalnızca gökyüzündeki araç değildi. Uçan platform ile yerdeki yazılım arasında sürekli veri akışı, durum izleme, hata ayıklama ve operatör etkileşimi vardı. Bilgisayar mühendisliği açısından İHA'nın önemli bölümü tam olarak burada görünür hâle gelir.

12. Yer kontrol istasyonu

İ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.

13. 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.

14. 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.

TMS570 ve lwIP ile yaptığım gömülü ağ çalışmalarının aviyonik bağlamda anlamı da buydu: ağ yığını yalnızca TCP/IP programlama konusu değildir. İşlemci, gerçek zamanlı davranış, hata yönetimi ve fiziksel sistem arasındaki bağlantının parçasıdır.

14.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 burada anılması, Bayraktar TB2'nin bu veri yollarını kullandığı anlamına gelmez; kamuya açık bir kaynakla doğrulanmayan platform içi arayüzler hakkında böyle bir çıkarım yapılmamalıdı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.

15. 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.

15.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.

16. Haberleşme kaybı bir istisna 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.

16.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

17. 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.

18. 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.

18.1. Yerleşik test ve sistem sağlık izleme

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.

19. Aviyonik yazılımda statik analiz

2015 stajımda C ve C# kodları üzerinde statik analiz çalışmaları yapmamın aviyonik bağlamdaki anlamı sonradan daha belirgin hâle geldi.

Bu çalışma stajın ilerleyen aşamalarında tesadüfen karşıma çıkan bir araç denemesi değildi. Projelendirmeye MISRA C başta olmak üzere programlama standartlarını inceleyip belgeleyerek başladım. Ardından geliştirdiğim analiz yazılımında bu kuralların uygulanabilir bölümünü otomatikleştirmeyi ilk önceliklerden biri yaptım. Önce C ile kaynak kodu durum bilgisiyle tarayan denetimler geliştirdim; daha sonra C# tabanlı masaüstü araçta kendi kontrollerimi Cppcheck ve Splint gibi farklı analiz motorlarının çıktılarıyla aynı sonuç modelinde birleştirdim.

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.

19.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.

2015'te yaptığım çalışma için tarihsel olarak doğru başvuru MISRA C:2012'dir. Güncel sürümün daha sonra değişmiş olması, geçmiş çalışmayı yeni sürümle yapılmış gibi anlatmayı doğru kılmaz. MISRA C:2025 bugün daha yeni başvuru noktasıdır; ancak staj dönemindeki belgelendirme ve analiz çalışmasının bağlamı MISRA C:2012 olarak kalır. Uyum iddiası da yalnız "analiz aracı sıfır uyarı verdi" sonucuna indirgenemez. Sapmaların, uygulanabilir kuralları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.

19.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'nın etkin AC 20-115D genelgesi DO-178C'yi, araç 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 belgelerin burada anlatılması, Bayraktar TB2'nin belirli bir sertifikasyon temelini kullandığı iddiası değildir; kamuya açık kanıt bulunmadan böyle bir sonuç çıkarılamaz.

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.

19.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.

20. Sensör füzyonu ve hata toleransı arasındaki iliş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.

21. 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" kelimesi çok önemlidir.

İ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.

21.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.

22. 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.

Ünite 5: Bayraktar TB2 ve 2015 Baykar Deneyimi

23. Bayraktar TB2'yi sistem olarak okumak

Bayraktar TB2'yi yalnızca gövde, motor ve kamera üzerinden değerlendirmek platformun mühendislik tarafını eksik bırakır.

Baykar'ın güncel kamuya açık ürün bilgilerinde TB2 için şu mimari nitelikler belirtilmektedir:

• tam otomatik uçuş kontrolü,
• üç yedekli otopilot,
• hata toleranslı ve üç yedekli sensör füzyonu,
• tam otomatik taksi, kalkış, seyir ve iniş,
• dahili sensör füzyonuyla GNSS bağımsız seyrüsefer,
• çapraz yedekli yer kontrol istasyonu yapısı,
• yedekli servo eyleyiciler,
• yedekli güç birimleri,
• görüş hattı ve görüş hattı ötesi haberleşme seçenekleri.

Bu maddeler birlikte okunduğunda TB2'nin yalnızca "uzaktan kumandalı uçak" olarak tasarlanmadığı açıktır. Sistem; durum kestirimi, otomatik uçuş, yedeklilik, yer kontrolü ve haberleşmenin birlikte tasarlandığı bütünleşik bir aviyonik mimaridir.

Baykar'ın farklı yıllarda yayımladığı teknik dokümanlarda ağırlık, irtifa ve havada kalış gibi bazı değerlerin farklılaştığı görülür. Bunun nedeni platformun sürümleri ve yayımlanan konfigürasyonların zaman içinde değişebilmesidir. Bu nedenle güncel sayısal verileri 2015'teki hava aracının birebir teknik konfigürasyonu olarak kabul etmek doğru değildir.

24. TB2'nin 2015'te bulunduğu aşama

Baykar'ın kamuya açık tarihçesine göre:

• 2014'te Bayraktar TB2 ilk tam otomatik uçuş testini gerçekleştirdi,
• 2014'te ilk seri teslimat yapıldı,
• 2015'te ikinci seri teslimat yapıldı,
• 2015'te Emniyet Genel Müdürlüğü siparişi alındı,
• 2015'te ilk 1000 uçuş saati kırımsız tamamlandı,
• 2015'te cansız mühimmatla ilk atış gösterimi gerçekleştirildi.

Benim Baykar stajım da bu döneme denk geldi.

Bu zamanlama önemlidir. Bir sistem ilk prototip uçuşunu yapmış, seri teslimata geçmiş ve uçuş saati biriktirmeye başlamışsa yazılım geliştirme problemi de değişir. Laboratuvar doğruluğunun yanında:

• tekrarlanabilirlik,
• bakım yapılabilirlik,
• log kalitesi,
• hata ayıklama,
• saha koşullarında kararlılık,
• operatör deneyimi,
• sürüm kontrolü,
• sistemler arası uyumluluk

daha görünür hâle gelir.

Staj sırasında karşılaştığım gömülü ağ, aviyonik hata ayıklama, statik analiz ve telemetri konuları bu olgunlaşma aşamasının yazılım mühendisliği tarafıyla doğrudan örtüşüyordu.

25. 2015 Baykar deneyimimin teknik karşılığı

İkitelli'deki ilk çalışmalarım TMS570 ve lwIP üzerinde gömülü ağ tarafındaydı. TMS570 ailesi güvenlik odaklı gömülü denetleyici sınıfında yer alır; lwIP ise kaynakları sınırlı sistemlerde TCP/IP haberleşmesi için kullanılan hafif bir ağ yığınıdır.

Bu çalışma bana üç katmanı birlikte düşünmeyi öğretti:

donanım → gömülü yazılım → ağ

Keşan'da ise bu zincirin devamını gerçek İHA sistemi üzerinde görmek mümkündü:

hava aracı → aviyonik veri → haberleşme → yer kontrol yazılımı → operatör

Telemetriyle çalışırken ekranda görülen her değerin arkasında sensör, işlemci, protokol ve zamanlama zinciri bulunuyordu.

Aviyonik hata ayıklamada bir sorunu yalnızca "GUI hatası", "ağ hatası" veya "sensör hatası" diye ayırmak çoğu zaman yeterli değildir. Gerçek neden katmanlar arasında olabilir.

Örneğin ekranda donmuş görünen bir değer:

• sensörün güncelleme yapmamasından,
• gömülü yazılımın paketi üretmemesinden,
• ağ kaybından,
• paket ayrıştırma hatasından,
• zaman aşımı mantığından,
• kullanıcı arayüzü güncelleme probleminden

kaynaklanabilir.

Bu bakış daha sonra gerçek zamanlı, yüksek trafikli ve kritik yazılım sistemlerinde çalışırken de değişmedi: uçtan uca sistem davranışı, tek bir modülün doğruluğundan daha önemlidir.

Aynı dönemde statik analiz projesini MISRA C kurallarını inceleyip belgeleyerek başlatmış olmam da bu uçtan uca düşüncenin başka bir yüzüydü. Kuralı yalnız dokümanda bırakmak yerine uygulanabilir denetimleri yazılımın içine almak, daha kod büyümeden tekrar edilebilir bir kalite mekanizması kurmayı amaçlıyordu. Geliştirdiğim aracın ilk önceliklerinden biri bu analizi gerçeklemekti; daha sonra farklı analiz motorlarının çıktılarının aynı arayüzde birleştirilmesiyle yaklaşım genişledi.

26. Yer kontrol yazılımı neden kritik bir yazılımdır?

Yer kontrol istasyonu hava aracının doğrudan uçuş bilgisayarı değildir; ancak operatör ile araç arasındaki temel insan-makine arayüzüdür.

Bu nedenle şu özellikler kritiktir:

26.1. Durumun tek anlamlı gösterimi

Aynı bilgi birden fazla yerde farklı görünmemelidir.

Uçuş modu, bağlantı durumu veya kritik bir sensörün sağlığı için tek ve tutarlı semantik gerekir.

26.2. Eski veri ile yeni verinin ayrılması

Bağlantı kesildiğinde son değer ekranda kalabilir. Bu değer görsel olarak hâlâ "canlı" görünüyorsa operatör yanlış karar verebilir.

26.3. Alarm önceliği

Her uyarı kırmızı yapılırsa hiçbir uyarı gerçekten kırmızı değildir.

Bilgi, ikaz ve kritik alarm ayrımı gerekir.

26.4. Komut doğrulama

Operatör eyleminin:

• alındığı,
• doğrulandığı,
• uygulandığı

aynı şey değildir.

Komut arayüzü bu ayrımı mümkün olduğunca görünür kılmalıdır.

26.5. Kayıt ve izlenebilirlik

Kritik olaylarda sonradan şu sorular cevaplanabilmelidir:

• hangi veri ne zaman geldi?
• hangi komut ne zaman gönderildi?
• sistem hangi moddaydı?
• hangi uyarı üretildi?
• bağlantı durumu nasıldı?

Telemetri kaydı yalnızca analiz kolaylığı değil, sistem mühendisliği için geri bildirim mekanizmasıdır.

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

27. İHA'da insan 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.

28. 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

Bayraktar TB2'nin kamuya açık tanımlarında tam otomatik taksi, kalkış, seyir, rota takibi ve iniş gibi kabiliyetlerin vurgulanması bu ayrımı açık biçimde gösterir.

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

Daha doğru ifade şudur:

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

29. İHA yazılımını farklı yapan nedir?

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

Fiziksel dünya ile doğrudan bağlıdır

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

Zaman önemlidir

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

Donanım kusursuz değildir

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

Hata durumları normaldir

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

Gözlemlenebilirlik gerekir

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

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.

30. Güvenilirlik için temel yazılım ilkeleri

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

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.

Gizli başarısızlıktan kaçınmak

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

Deterministik davranış

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

Hata yayılımını sınırlamak

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

Kaynak kullanımını sınırlandırmak

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

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.

31. 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ğ çok güçlü tutulmalıdır.

32. 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.

33. Bayraktar TB2 üzerinden mimari okuma

TB2'nin kamuya açık özellikleri ders notundaki kavramlarla eşleştirildiğinde yapı daha anlaşılır hâle gelir.

Üç yedekli otopilot

Bu ifade tek bir uçuş bilgisayarına bağımlı kalmama hedefini gösterir. Mühendislik problemi yalnızca üç kanalı çalıştırmak değil; kanalların tutarlılığını değerlendirmek ve arıza durumunda güvenli karar verebilmektir.

Üç yedekli sensör füzyonu

Sensör verisinin tek kaynaktan alınmadığını, durum kestiriminin hata toleransı ile birlikte ele alındığını gösterir.

Otonom kalkış ve iniş

Uçuşun en dinamik evrelerinden ikisinde:

• durum kestirimi,
• rota/hat takibi,
• hız ve irtifa kontrolü,
• eyleyici denetimi

birlikte çalışır.

GNSS bağımsız seyrüsefer

Uydu seyrüseferinin tek hata noktası olarak kabul edilmediğini gösteren önemli bir mimari niteliktir. Kamuya açık ifade sensör füzyonunu vurgular; ayrıntılı uygulama mimarisi kamuya açık olmayan alanlara girmeden de bu tasarım ilkesinin önemi anlaşılabilir.

Çapraz yedekli yer kontrol yapısı

İHA sistemi yalnızca araç üzerinde yedeklenmez. Yer tarafındaki görev sürekliliği de bütünsel mimarinin parçasıdır.

Yedekli servo ve güç birimleri

Kontrol bilgisayarının doğru komut üretmesi tek başına yeterli değildir. Komutun fiziksel yüzeye aktarılması ve sistemin enerjiyle beslenmesi de güvenilirlik zincirinin parçasıdır.

Ünite 7: Saha Deneyimi ve Mühendislik Çıkarımları

34. Teori ile saha arasındaki fark

Ders kitabında sistemler başlıklara ayrılır:

• aerodinamik,
• kontrol,
• seyrüsefer,
• haberleşme,
• yazılım,
• insan-makine etkileşimi.

Gerçek sistemde ise bir problem bu sınırları tanımaz.

Örneğin rota takibindeki sapma:

• rüzgâr modelinden,
• GNSS hatasından,
• IMU biasından,
• zaman senkronizasyonundan,
• kontrol kazancından,
• servo cevabından,
• telemetri gösteriminden

kaynaklanabilir.

2015'te Baykar'daki stajın benim açımdan asıl değeri de buydu. Üniversitede ayrı ayrı öğrendiğim gömülü sistem, ağ, C/C#, kontrol, sensör ve arayüz kavramlarının gerçek bir hava aracında aynı uçtan uca sistemin parçaları olduğunu görmüş oldum.

35. Mühendislik açısından çıkarımlar

Aviyonik ve İHA sistemlerinden çıkarılabilecek bazı genel dersler vardır.

Birinci ders: Fizik yazılımın dışı değildir

Yazılım fiziksel sistemi kontrol ediyorsa fizik, yazılım gereksiniminin parçasıdır.

İkinci ders: Ölçüm ile gerçek aynı şey değildir

Her sensör ölçümü hata modeliyle birlikte düşünülmelidir.

Üçüncü ders: Ağ hataları iş mantığıdır

Bağlantı kaybı veya gecikme yalnızca iletişim katmanının sorunu değildir; sistem davranışını değiştirir.

Dördüncü ders: Yedeklilik mimari problemdir

Aynı bileşenden birkaç tane koymak tek başına hata toleransı sağlamaz.

Beşinci ders: Arayüz kritik bileşendir

İnsan yanlış durumu görüyorsa alttaki sistem doğru çalışsa bile görev başarısız olabilir.

Altıncı ders: Kayıt ve telemetri sonradan eklenen özellik değildir

Sistemin sahada anlaşılabilir ve hata ayıklanabilir olması tasarım gereksinimidir.

Yedinci ders: Otonomi daha fazla yazılım değil, daha fazla sistem sorumluluğudur

İnsan döngüden uzaklaştıkça durum kestirimi, hata yönetimi ve güvenilir kontrol daha kritik hâle gelir.

36. Sonuç

Bir İHA'nın uçması aerodinamikle başlar; fakat güvenilir biçimde görev yapması aviyonik sistemlerin birlikte çalışmasına bağlıdır.

Kanat kaldırma üretir.

Sensörler aracın durumunu ölçer.

Durum kestirimi bu ölçümleri anlamlı bir modele dönüştürür.

Seyrüsefer nereye gidildiğini belirler.

Otopilot istenen uçuş durumunu kapalı çevrim denetler.

Eyleyiciler sayısal komutu fiziksel harekete çevirir.

Veri bağı hava ile yer arasındaki bilgi akışını taşır.

Yer kontrol istasyonu operatöre sistemin durumunu görünür kılar.

Yedeklilik ve hata yönetimi ise bu zincirde tek bir kusurun tüm görevi kaybettirmesini önlemeye çalışır.

Bayraktar TB2 bu başlıkların Türkiye'de somutlaştığı en önemli sistemlerden biridir. Benim için konuya ayrıca kişisel bir bağ ekleyen nokta, 2015'te projenin seri teslimat ve operasyonel olgunlaşma döneminde Baykar'da staj yapmış olmamdır. TMS570/lwIP gömülü ağ çalışmalarından Keşan'daki aviyonik hata ayıklamaya, C/C# statik analizden yer kontrol telemetrisine uzanan işler, daha sonra gerçek zamanlı ve kritik sistemlere bakışımı belirleyen erken deneyimlerden biri oldu.

O dönem öğrendiğim temel düşünce bugün de geçerlidir:

Bir kritik sistem, tek tek doğru çalışan parçaların toplamı değildir.

Asıl mühendislik, bu parçaların aynı fiziksel gerçeklik, aynı zaman çizgisi ve aynı hata modeli içinde güvenilir biçimde birlikte çalışmasını sağlamaktır.

Kaynaklar

R. P. G. Collinson, Introduction to Avionics Systems, Third Edition, Springer, 2011.

Baykar, Bayraktar TB2 ürün sayfası

Baykar, tarihçe

Baykar, kamuya açık ürün ve teknik dokümanları

FAA AC 20-115D, Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( )

SAE, ARINC 653 Part 1 Supplement 6

SAE, ARINC 429 Part 1 Supplement 19

U.S. DoD ASSIST, MIL-STD-1553

MISRA C:2025 Addendum 6