Otomasyon Ölümcül Hale Geldi: MCAS ve Max

Otomatik bir güvenlik özelliğinin bir felaketin parçasına dönüşme süreci

2018–2019 yıllarında iki Boeing 737 MAX uçağı birkaç ay arayla düştüğünde, müfettişler uçakların uçuş kontrol yazılımına uzanan ortak bir payda tespit ettiler. Uçağın farklı şekilli motorlarla başa çıkmasına yardımcı olmak için tasarlanan bir sistem olan Manevra Karakteristikleri Takviye Sistemi (MCAS), geliştirme sürecinin sonlarında, davranışını daha baskın hale getirecek ve kritik olarak tek bir hücum açısı sensörüne güvenecek şekilde yeniden yapılandırıldı. Bu değişiklikler koruma katmanlarını ortadan kaldırdı ve mürettebatı, tanımak veya karşı koymak için eğitilmedikleri hızlı ve kafa karıştırıcı bir arıza moduyla karşı karşıya bıraktı.

MCAS: Ne yapması amaçlanmıştı

MCAS, daha büyük ve daha ileriye monte edilmiş motorların aerodinamiği değiştirmesinin ardından MAX'in önceki 737 modelleri gibi hareket etmesine yardımcı olmak için tanıtıldı. Nominal görevi mütevazıydı: Belirli koşullar burnun çok fazla yukarı kalkabileceğini (pitch up) gösterdiğinde, MCAS pilotlar için kullanım tutarlılığını korumak amacıyla yatay stabilizeyi hafifçe burun aşağı (nose-down) konumuna getiriyordu. Orijinal konseptinde sistemin fark edilmeyecek kadar hafif olması ve nadiren çalışması amaçlanmıştı.

Sistem nasıl değişti — ve bu neden önemliydi

Geliştirme sırasında Boeing, MCAS’in rolünü genişletti. Uygulanan sürüm, önceki taslaklardan daha sık devreye girebiliyor ve daha büyük stabilize komutları uygulayabiliyordu; ayrıca birden fazla kaynağı çapraz kontrol etmek yerine tek bir hücum açısı sensöründen gelen verilere tepki verecek şekilde bağlanmıştı. Hem Lion Air hem de Ethiopian Airlines kazalarında, hatalı hücum açısı verileri, pilotların mücadele ettiği ancak zamanında üstesinden gelemediği tekrarlayan burun aşağı komutlarını tetikledi. Muhafazakar ve yedekli bir tasarımdan daha agresif, tek sensörlü bir uygulamaya geçiş, arızalarda belirleyici bir faktör oldu.

MCAS'i "Y.Z." olarak adlandırmak neden yanıltıcıdır — ve bu etiket neden hala önemlidir

Medya ve kamuoyu tartışmalarında bu kazalar bazen bir "Y.Z." (Yapay Zeka) hatası olarak çerçeveleniyor. Bu kısaltma cazip olsa da kesinlikten uzaktır. MCAS, verilerden kendi kendini eğiten bir makine öğrenimi modeli değildi; deterministik bir uçuş kontrol mantığıydı: belirli sensör girdilerine göre hareket etmek üzere kodlanmış kurallardı. Ancak tehlike, insanların şeffaf olmayan YZ sistemleri hakkında endişelendiği tehlikeyle aynıdır: son kullanıcılardan ve düzenleyicilerden gizlenen, tasarımcılarının tam olarak öngöremediği şekillerde gerçek dünyadaki karmaşık sinyallerle etkileşime giren otomatik davranışlar.

MCAS'i sadece "otomasyon" olarak etiketlemek, tasarım tercihlerinin — özellikle şeffaflık, yedeklilik ve insan-makine etkileşimi konularındakilerin — koruyucu bir özelliği nasıl bir tehlikeye dönüştürdüğünü hafife alabilir. Bu uçuşlar, öğrenmeyen algoritmaların bile sıkı bir güvenlik mühendisliği, yani şu anda diğer alanlardaki YZ sistemlerinden talep ettiğimiz izlenebilir gereksinimler ve bağımsız testlerin aynısını gerektirdiğini ortaya koyuyor.

Organizasyonel ve düzenleyici başarısızlıklar teknik kusurları şiddetlendirdi

Teknik seçimler bir boşlukta gerçekleşmedi. Birden fazla inceleme ve duruşma; denetim, iletişim ve kurumsal kültürdeki sorunların riski artırdığını ortaya koydu. Düzenleyici kurumlara MCAS evrildikçe her zaman tüm ayrıntılar sunulmadı; pilot el kitaplarında başlangıçta bu özelliğe yer verilmedi ve MCAS'in nadiren devreye gireceği yönündeki varsayımlar, pilotların bu durum gerçekleştiğinde nasıl tepki verecekleri konusundaki eğitimlerini azalttı. Bu kurumsal aksaklıklar, bir mühendislik hatasını bir kamu güvenliği krizine dönüştürdü.

Boeing ve düzenleyicilerin uyguladığı düzeltmeler

MAX filosunun yere indirilmesinin ardından, Boeing ve havacılık otoriteleri yazılım ve operasyonel değişiklikler talep etti. Revize edilen tasarım MCAS'i sınırlıyor; böylece sistem yalnızca her iki hücum açısı sensörü de mutabık kaldığında hareket ediyor, olay başına tek bir aktivasyonla kısıtlanıyor ve trim komutlarının büyüklüğünü dengeliyor. Düzenleyiciler ayrıca uçağın hizmete dönmesine izin verilmeden önce dokümantasyon, pilot eğitimi ve bağımsız doğrulama gereksinimlerini sıkılaştırdı. Bu değişiklikler doğrudan arıza modlarını ele aldı ancak krizin ortaya çıkardığı daha geniş yönetişim sorularını ortadan kaldırmadı.

Daha geniş YZ ve otomasyon tartışmaları için dersler

MAX hikayesi, geniş ölçekte otomasyon uygulayan herkes için uyarıcı bir kılavuz niteliğindedir. Dört ders öne çıkıyor:

Bunlar YZ etiği ve güvenliği çevrelerinde tanıdık söylemlerdir, ancak 737 MAX bunların soyut olmadığını gösteriyor. Güvenlik açısından kritik sistemlerde, bunları yanlış yapmanın bedeli anında ve geri dönülemezdir.

Tartışmanın bundan sonraki yönü

Teknik düzeltmeler MAX'i daha sıkı koşullar altında hizmete döndürdü, ancak bu olay düzenlenen endüstrilerde otomasyonun nasıl yönetilmemesi gerektiği konusunda bir mihenk taşı olmaya devam ediyor. Politika yapıcılar ve mühendisler için zorunluluk, dersleri uygulanabilir standartlara dönüştürmektir: otomatik karar sistemleri için daha net sertifikasyon süreçleri, önemli tasarım değişikliklerinin zorunlu raporlanması ve üreticiler ile sertifika verenler arasındaki çıkar çatışmalarını azaltan kurumsal yapılar.

Gazeteciler ve kamuoyu için bu aynı zamanda terimler konusunda kesin olma gerekliliğini hatırlatıyor. "YZ" manşetleri süslüyor, ancak MAX vakasındaki temel sorun makine öğrenimi anlamında yapay zeka değildi; bu, agresif otomasyon, zayıf şeffaflık ve zayıflamış güvenlik uygulamalarının bir kombinasyonuydu. Bu kombinasyonu bir mühendislik ve yönetişim zorluğu olarak ele almak, tekrarları önlemek için bize daha üretken bir yol sunar.

Sonuç

737 MAX felaketleri kaçınılmaz değildi. Bunlar belirli tasarım kararlarının, denetlenmeyen varsayımların ve kurumsal başarısızlıkların sonucuydu. Otomasyon ve YZ daha fazla alana yayıldıkça, MAX vakası çarpıcı bir örnek olarak durmalıdır: Daha güvenli sistemler bir kod parçasına duyulan güvenden değil; muhafazakar tasarımdan, kullanıcılarla net iletişimden, bağımsız incelemeden ve sağlam düzenleyici denetimden doğar. Bunlar teknik teferruatlar değil, kamu güvenliğinin önkoşullarıdır.