Programcıların havacılık alanı hakkında inandığı yanlış kabuller
(flightaware.engineering)- Havacılık verileri karmaşıktır ve standart dışı birçok özellik barındırır
- Geliştiriciler uçuşlar, havalimanları, navigasyon ve transponder bilgileri hakkında sık sık yanlış varsayımlarda bulunur
- Gerçek uçuş takip sistemleri, çeşitli istisna durumlara ve veri anormalliklerine esnek şekilde yanıt verebilmelidir
- Birçok yanlış anlama, yazılımlarda veya müşteri sistemlerinde beklenmedik hatalara yol açar
- Veri tasarlanırken gerçek dünyanın karmaşıklığını dikkatle yansıtan bir bakış açısına ihtiyaç vardır
Genel Bakış
FlightAware, dünya genelindeki havacılık verilerini işleyip dağıtan yazılımlar geliştiren bir şirkettir. Ancak gerçek havacılık verileri, sezgilerin aksine yapısal olarak düzenli değildir; çok sayıda istisna ve anormallik içerir. Pek çok geliştirici veri yapıları, akışlar ve kimliklendirme şemaları hakkında çeşitli önkabuller yapar; fakat bunlar gerçekte sistem hatalarına ve tutarsızlıklara yol açan yanlış varsayımlar hâline gelir. Bu yazı, yanlış kabuller serisinin bir uzantısı olarak, havacılık sektöründeki yazılımlarda sıkça yapılan hatalı kabulleri ve bunların doğurduğu örnekleri derliyor.
Flights (Uçuş bilgileri)
- Uçuşların her zaman kapıdan kalktığı düşünülür; oysa gerçekte bir uçuş birden fazla kez kapı değiştirebilir ya da planlanandan çok daha geç veya erken kalkabilir
- Uçuş programlarının veya kalkış/varış noktalarının net olduğu varsayılır; ancak helikopterler ve askerî uçaklar gibi araçlar, havalimanı dışındaki yerlerden kalkıp inebilir
- Uçuş süresinin veya tarifelerin düzenli olduğu düşünülse de, günler süren uzun uçuşlar ve düzensiz operasyonlar da sık görülür
- Uçuş tanımlayıcı numarasının (ör. UAL1234) tekil olduğu varsayılır; fakat gerçekte tek bir uçağa birden fazla tanımlayıcı ya da numara verilebilir ve aynı numara farklı durumlarda kullanılabilir
- Görünüşte aynı numara olsa bile uçuş tanımlayıcısı, tescil numarası ve diğer işaretler birbirine karışabilir; ayrıca biletleme, hava trafik kontrolü ve pilotların kullandığı kimlik bilgileri birbirinden farklı olabilir
Airports (Havalimanı bilgileri)
- Havalimanı konumu ve kimlik kodlarının sabit olduğu sanılabilir; ancak gerçekte havalimanları kapanabilir, taşınabilir veya birleştirilebilir, bu da konumların ya da kodların değişmesine yol açabilir
- Terminal/kapı numaraları, pistler ve benzeri adlandırma sistemleri de tutarlı değildir ve çok sayıda istisnai kural içerir
- ICAO/IATA kod sistemlerinde de yinelenen kodlar, birden fazla kod atanması ve konum kodlarına dair yanlış anlamalar gibi, gerçek dünyayla uyuşmayan birçok durum vardır
- Belirli bir kimlik bilgisinin (ör. IATA kodu) varlığı, bunun mutlaka gerçek bir havalimanı olduğu anlamına gelmez; bazı tren istasyonları ve otobüs terminallerine de IATA kodu verilmiştir
- Hatta bazı ICAO kodları Dünya dışındaki yerlere bile atanmıştır (ör. bir dış gezegen krateri)
Airlines (Havayolu şirketi bilgileri)
- Ayrı satırlarda somut yanlış kabuller belirtilmediği için atlanmıştır
Navigation (Seyrüsefer ve rota bilgileri)
- Waypoint adlarının tekil olduğu düşünülür; oysa gerçekte tekrar eden adlar vardır
- Havacılıkta kullanılan irtifa tanımı tek bir standarda bağlı değildir; farklı referanslara göre farklı yorumlanır
- Hava trafik kontrol verilerinin tamamen doğru olduğu varsayılabilir; ancak gerçekte hata veya değişiklikler sık yaşanır
- Uçuş planı iptalleri ve plan değişiklikleri gerçek uçuşa yansımayabilir; aynı uçuş birden fazla kez varış noktasını değiştirebilir
- Radar verilerinde, hava trafik kontrol kurumları arasındaki veri tutarsızlıklarında ve eşzamanlı gözlemlerde konum sapmalarında da sorunlar görülebilir
Transponders and ADS-B (Transponder ve ADS-B ile ilgili bilgiler)
- ADS-B sinyallerinin yalnızca uçaklardan gönderildiği varsayılır; oysa havalimanı araçları ve başka cihazlar da bu sinyalleri gönderebilir
- GPS koordinatlarının doğruluğuna ve sinyal güvenilirliğine aşırı güvenmek de bir yanılgıdır
- Transponder kayıt bilgilerindeki (tanımlayıcı numaralar, Mode S adresleri vb.) hatalar, yinelenmeler, bakım eksiklikleri ve format sorunları nedeniyle gerçek zamanlı veri ile gerçek durum arasında sık sık uyuşmazlıklar oluşur
- ADS-B bilgilerinin olduğu gibi alınıp saklandığı düşünülür; ancak iletim hataları, sinyal sahteciliği gibi çeşitli sorunlar yaşanabilir
- Cihaz arızaları, yetersiz yönetim ve dış etkenler (ör. farelerin kablolara zarar vermesi) de gerçek dünyadaki değişkenler arasındadır
Sonuç
Bu liste, FlightAware ve Hyperfeed geliştirme ekiplerinin yıllar içinde çok sayıda gerçek vakadan edindiği deneyim ve içgörülere dayanarak, havacılık verisi güvenilirliğinin ne kadar karmaşık olduğunu gösteriyor. Çeşitli hata ve yanlış anlamaları azaltmak için, veri modelleme ve işletimde gerçek dünyadaki istisnaları titizlikle hesaba katmanın önemini vurguluyor.
4 yorum
Veri standardizasyonu bu yüzden... önemli.. haha
Metin gerçekten çok kısa, ama içindeki duygu;;
Sadece okumak bile tansiyonu yükseltiyor lol
Hacker News yorumu
Uçaklar için zaman içinde değişmeyen tek ve benzersiz bir tanımlayıcının bulunmaması durumu açıklanıyor. Her hava aracına bir seri numarası veriliyor, ancak bunun tek başına benzersizliği garanti etmediğine dair gerçek deneyim paylaşılıyor. "Üretici, model, seri numarası" birleşimi bir hava aracı için yaşamı boyunca en benzersiz tanımlayıcıya en çok yaklaşan şey, fakat gövde yapısal değişiklikle tip değiştirirse bunun bile değişebildiği durumlar var. Havacılık gibi büyük ve karmaşık bir sistemde değişmeyen bir tanımlayıcının olmamasının kişisel olarak şaşırtıcı bulunduğu da ekleniyor. Uçak tescil numarası (kuyruk numarası) araba plakası gibi değişiyor ve ICAO 24 bit tanımlayıcısı ADS-B ekipmanına bağlı olduğu için taşınması/değiştirilmesi de mümkün
"Üretici, model, seri numarası" birleşiminin patent konusu olması karşısında duyulan şaşkınlık ifade ediliyor. Böyle bir şeyin nasıl yeni sayılıp patent alabildiği merak ediliyor
Bu hikâye, 'Theseus'un Gemisi' paradoksuyla ilişkilendirilerek, uçağın kimliği ve tanımlayıcısının değişimi üzerine felsefi bir çağrışım yapılıyor Ship of Theseus Vikipedi bağlantısı
Havacılık endüstrisinin ülkeler bazında silo gibi birbirinden ayrı geliştiği için standardizasyonun geç geldiğine dair tarihsel arka plan paylaşılıyor. Küresel standartların gerçekten yerleşmiş olmasının bile şaşırtıcı bir başarı olduğu görüşü var. Bugün büyük üreticilerin az sayıda şirkette birleşmiş olmasının bunu ancak mümkün kıldığı analizi yapılıyor
Gerçek dünyada "gerçekten" benzersiz bir tanımlayıcının önemli bir sorun olarak sık sık ortaya çıktığına dair saha deneyimi paylaşılıyor. Çözüm neredeyse her zaman “model, üretici, seri numarası” birleşimi oluyor; gerekirse üretim yılı da ekleniyor. Hatta insan verilerinde bile ana dil gibi ölçütlerle de-duplication denenmiş bir örnekten söz ediliyor
Pist numaralarının da zamanla değiştiğine örnek olarak bir Vikipedi maddesi paylaşılıyor Runway Vikipedi bağlantısı
Bu tür listelerin, her maddeye daha ayrıntılı açıklama eklense çok daha faydalı olacağı yorumu yapılıyor. Yine de bağlantı verilen kaynaklarda yararlı çok şey olduğu, örneğin Mars'taki bir kratere ICAO havaalanı kodu verilmesi (JZRO) örneğinin ilginç olduğu belirtiliyor Jezero krateri Vikipedi bağlantısı, kalkışı normal ama inişi 40 saat geciken uçuş örneği
Üretici-model-seri numarası birleşimi bu kadar bariz görünürken bunun nasıl patent alabildiği ve bugün birilerinin bu patentten para kazanıp kazanmadığı sorgulanıyor
Uçuş verisi analizi yazılımı geliştirme deneyiminden, helikopterlerin ve uçakların hastane, çatı, otopark, spor sahası, havaalanı, golf sahası gibi çok çeşitli yerlerden inip kalkması nedeniyle “havacılıkla ilgili türlü türlü yalanlar” arasında yaşamanın gerçek geliştirici sıkıntısı anlatılıyor
"Falsehoods..." yazı dizisi her görüldüğünde, birçok geliştiricinin insan merkezli sistemlerin katı kurallara uyacağını sanmasının ilginç bulunduğu görüşü paylaşılıyor
Geliştiricilerin her şeyi katı bir kural sistemine indirgemeyi sevdiği, ancak gerçek dünyanın böyle olmadığını kabul etmek gerektiği söyleniyor
Programcılık mesleğinin özünde, esnek insan sistemleriyle katı kural tabanlı makineler arasında bir arayüz olma niteliği taşıdığı analizi yapılıyor
Programcıların dünyayı yazılımla modellerken bazı varsayımları doğal kabul ettiği, ama gerçekte bunların hiç de geçerli olmaması nedeniyle yaşanan ikilem ve kafa karışıklığı paylaşılıyor. Örneğin bir uçuşun mutlaka bir kalkış/varış havaalanı olduğu varsayımı veriliyor, ancak gerçek bununla örtüşmüyor
Yazılımın doğası gereği, alan modellemenin mutlaka bir kurallar kümesine dönüştürülmesi gerektiği savunuluyor. Kurallar yoksa hiçbir işlev sunulamayacağı belirtiliyor. Sıradan birine 'artık saniye (leap second)' gibi istisnalar anlatıldığında saçmalık sanılabildiği için, aslında geliştiricilerin dünyanın istisnalarının ve karmaşıklığının çoğu zaman farkında olduğu öne sürülüyor
"Falsehoods Programmers Believe..." dizisindeki her maddenin birer test vakası gibi ele alınması öneriliyor. Programın içine yanlış yerleşmiş varsayımları doğrulayan birim/entegrasyon testlerine dönüştürülebileceği söyleniyor
"Uçuşlar havaalanlarından kalkar ve iner" varsayımının geçmişte Brezilya havacılık sisteminde koşulsuz biçimde yer aldığı ve bunun geçici çözümlerle aşıldığı örneği veriliyor. "Havaalanı/pistlerin konumu ya da yönü değişmez" varsayımının da çok sık yanlış kabul edildiği eleştiriliyor. Hatta "uçaklar yalnızca pistlere veya helikopter pistlerine iner" varsayımının bile ayrıca eklenmesi gerektiği öneriliyor
CGP Grey'nin havaalanı kodlarının ne kadar karmakarışık bir süreçten geçtiğini iyi özetleyen videosu paylaşılıyor YouTube bağlantısı. Sistemin kendine özgü koşulları da anlatılıyor
Aynı konuyu ele alan FlightAware forum tartışması da tanıtılıyor FlightAware forum bağlantısı
Programcı bakış açısından listedeki tüm varsayımların makul göründüğü, sonra da gerçeği acı şekilde fark ederken insanın beyninin patlayacak gibi hissettiği söyleniyor. Bunun harika bir özet olduğu övgüsü yapılıyor