Kazanimlar:
- Belirsiz pilot raporunu (PIREP) yapay zeka ile doğru ATA bölümüne oturtulmuş yapılandırılmış arıza tarifine çevirebilme
- Hata kodunun kök neden değil semptom olduğunu kavrayıp elemeli troubleshooting'de konnektör/kablolama kontrolünü parça değişiminden önce uygulayabilme
- Yapay zekanın ürettiği FIM/task referanslarının ve olası neden listelerinin doğrulanması gereken hipotezler olduğunu kavrayabilme
Her bakım işi bir kayıtla başlar ve bir kayıtla biter. Uçak bakımının kalbi, arızanın nasıl tarif edildiği, nasıl kaydedildiği ve nasıl izole edildiğidir. Bu ünitede yapay zekayı (YZ) tam da bu üç halkada — pilot raporunu anlamada, hata kodlarını yorumlamada ve arıza izolasyonunda (troubleshooting) — nasıl bir hızlandırıcı olarak kullanacağınızı, ama teşhis kararını neden asla ona bırakamayacağınızı işleyeceğiz.
Önce terimleri netleştirelim. PIREP (Pilot Report — pilotun uçuş sırasında veya sonrasında fark ettiği anormalliği kendi cümleleriyle yazdığı arıza kaydı) çoğu zaman kısa, teknik olmayan ve belirsizdir: "İniş takımı inerken alışılmadık bir ses geldi." MAREP (Maintenance Report — bakım personelinin gözlemini kaydettiği not) daha teknik olabilir. Tech Log (Technical Logbook — uçağın teknik seyir defteri, arızaların ve yapılan işlemlerin resmi kaydı) ise tüm bunların yasal olarak toplandığı defterdir. Modern uçaklarda bir de CMS/CMC (Central Maintenance System/Computer — Merkezi Bakım Bilgisayarı) vardır; sistemler kendi ürettikleri fault code (arıza kodu) ve maintenance message (bakım mesajı) kayıtlarını buraya düşürür.
Belirsiz insan tarifini yapılandırmak
Bir pilotun "garip bir titreşim" ifadesi ile bir arıza kodu arasında büyük bir mesafe vardır. YZ bu mesafeyi kapatmakta çok işe yarar: serbest metni alır, yapılandırılmış bir arıza tarifine çevirir — hangi uçuş fazında (kalkış, tırmanma, seyir, iniş) olduğu, hangi sistemi (ATA bölümü) ilgilendirebileceği, tekrarlayıp tekrarlamadığı. Bu, teşhis değil, veriyi düzenlemedir. Kritik nokta: YZ'nin ürettiği yapılandırma bir hipotez setidir; hangisinin doğru olduğunu manuel ve fiziksel muayene belirler.
ATA bölümü kavramını hatırlayalım: ATA 100 standardı, uçağı sistemlere göre numaralandırır (21 klima, 27 uçuş kumandaları, 28 yakıt, 29 hidrolik, 32 iniş takımı, 34 seyrüsefer, 49 APU, 72 motor). Bir arızayı doğru ATA bölümüne oturtmak, doğru manuele ve doğru uzmana ulaşmanın ilk adımıdır. YZ, belirsiz bir tarifi olası ATA bölümlerine eşlemede hızlıdır — ama "olası", "kesin" demek değildir.
İpucu: PIREP'i YZ'ye verirken pilotun tam cümlesini değiştirmeden aktarın. "Titreşim" yerine kendi yorumunuzu ("muhtemelen fan dengesizliği") yazarsanız, YZ'yi baştan yanlış yöne saparsınız. Ham veriyi ham bırakın; yorumu doğrulamadan sonraya saklayın.
Hata kodları: sözlük, teşhis değil
Modern aviyonik ve motor sistemleri, arıza durumunda numaralı kodlar üretir. Bu kodların anlamı FIM (Fault Isolation Manual — Arıza İzolasyon El Kitabı) ya da üreticinin arıza kodu sözlüğünde tanımlıdır. YZ bir kodu insan diline çevirmede ve olası nedenleri sıralamada yardımcı olur; ancak burada iki büyük tuzak vardır.
Birincisi: aynı kod farklı uçak tiplerinde, hatta farklı yazılım standartlarında (software part number) farklı anlama gelebilir. YZ tipi karıştırabilir. İkincisi: bir kod çoğu zaman kök nedeni değil, semptomu işaret eder. Örneğin bir "hava verisi tutarsızlığı" kodu, arızalı bir sensörden de, tıkalı bir pitot borusundan da, bir kablo bağlantısından da kaynaklanabilir. YZ olasılıkları listeler; hangisinin gerçek olduğunu FIM'i adım adım izleyerek ve ölçerek siz bulursunuz.
Troubleshooting'te YZ: hipotez üreteci
İyi bir arıza izolasyonu, "shotgun troubleshooting" (rastgele parça değiştirme) değildir; yapılandırılmış, elemeli bir süreçtir. YZ burada bir hipotez üreteci ve kontrol listesi hatırlatıcısı olarak parlar:
- Semptomu netleştir: faz, koşul, tekrar sıklığı, eşlik eden diğer belirtiler.
- Olası nedenleri listele: YZ'den olasılık sırasıyla iste; her biri için hangi FIM adımını çağır.
- Ucuz ve hızlı testten başla: bağlantı/konnektör kontrolü, BITE testi, görsel muayene.
- Elemeli ilerle: her testin sonucunu kaydet; hipotezleri ele.
- Doğrula ve kapat: onarım sonrası operational test / return-to-service test yap.
YZ bu adımlarda sırayı hatırlatır ve gözden kaçan bir olasılığı öne çıkarır. Ama "şu parçayı değiştir" kararını, FIM ve fiziksel bulgu verir.
Dikkat: No Fault Found (NFF — arıza bulunamadı) tuzağına dikkat. Bir bileşeni sökmeden önce, arızanın gerçekten o bileşende mi yoksa kablolama/konnektör/yazılımda mı olduğunu izole edin. YZ "bileşeni değiştir" demeye meyillidir; oysa aviyonik arızaların önemli bölümü kablolama ve bağlantı kaynaklıdır (bunu 5. ünitede derinleştireceğiz).
Üç mini vaka
Vaka 1 — Tarifi yapılandırmak. Bir teknisyen, "inişte solda tıkırtı" şeklindeki bir PIREP'i YZ'ye verdi. YZ bunu faz (iniş), olası ATA bölümleri (32 iniş takımı, ikincil olarak 52 kapılar) ve "tekrar var mı?" sorusuyla yapılandırdı. Teknisyen son 10 uçuşun tech log'una baktı, arızanın 3 uçuşta tekrarladığını gördü ve muayeneyi iniş takımı kapak menteşesine odakladı; sorun gevşeyen bir bağlantı elemanıydı. Kör aramaya kıyasla yaklaşık 25 dakika kazanç.
Vaka 2 — Kod sözlüğü hızlandırdı, teşhis insandan geldi. Bir "hava verisi tutarsızlığı" kodu için YZ üç olası neden sıraladı: pitot/statik tıkanıklık, ADC (Air Data Computer — hava verisi bilgisayarı) arızası, kablolama. Teknisyen en ucuz testten başladı: pitot ısıtma ve drenajı kontrol etti, bir statik portun kısmen tıkalı olduğunu buldu. Parça değiştirilmeden sorun çözüldü; gereksiz bir ADC değişimi (yüksek maliyet + gereksiz risk) önlendi.
Vaka 3 — Halüsinasyon yakalandı. YZ, bir motor kodu için "FIM task 73-21-00-810-801" diye bir referans verdi. Teknisyen FIM'de baktığında bu numara o kodun bölümünde yoktu; YZ numarayı uydurmuştu. Doğru adım manuelde farklı bir görevdi. Kaynağa bağlama refleksi, yanlış prosedürle ilerlemeyi engelledi.
Dört kopyalanabilir şablon
Rol: Arıza tarifi yapılandırma asistanı.Görev: Aşağıdaki pilot raporunu yapılandırılmış arıza kaydına çevir.Çıktı alanları: Uçuş fazı | Olası ATA bölüm(ler)i | Tekrar durumu (bilinmiyorsa"kontrol edilecek") | Eşlik eden belirtiler | Netleştirici sorular.Kurallar: Teşhis KOYMA; sadece düzenle. Emin olmadığın alanı "belirsiz" yaz.PIREP: [pilot cümlesini aynen yapıştır]
Rol: Hata kodu açıklama asistanı.Görev: [Uçak tipi + yazılım std] için "[kod]" mesajının olası anlamını veolası nedenlerini olasılık sırasıyla listele.Kurallar:- Her neden için hangi FIM görevini kontrol etmem gerektiğini belirt ama task numarasını UYDURMA; "FIM'de [kod] bölümüne bak" de.- Kodun tipe göre değişebileceğini hatırlat.Kod ve bağlam: [kod + tip + faz]
Rol: Troubleshooting adım rehberi.Görev: Aşağıdaki arıza için elemeli bir kontrol sırası öner (ucuz/hızlı testtenpahalı/parça değişimine).Kurallar:- Her adımda ne ölçeceğimi ve beklenen normal aralığın nerede tanımlı olduğunu (AMM/FIM) belirt; değeri UYDURMA.- Konnektör/kablolama kontrolünü parça değişiminden ÖNCE koy.Arıza: [yapılandırılmış tarif]
Rol: Kapanış testi hatırlatıcısı.Görev: Aşağıdaki onarım için hangi operasyonel/iade testlerinin ve kayıtlarıngerektiğini kontrol listesi olarak çıkar.Kurallar: Testin resmi adımının AMM'de doğrulanması gerektiğini belirt.Onarım: [yapılan iş özeti]
Zayıf prompt / Güçlü prompt
Zayıf: "34-11 kodu ne demek, hangi parçayı değiştireyim?"
Bu soru tipi ve yazılım standardını içermez, doğrudan parça değişimine atlar ve YZ'yi uydurma bir referans üretmeye teşvik eder.
Güçlü: "[Uçak tipi, yazılım std]. CMC'de '34-11 hava verisi tutarsızlığı' mesajı, seyirde tekrarlıyor. Olası nedenleri olasılık sırasıyla ver; her biri için FIM'de bakılacak bölümü işaret et ama task no uydurma; en ucuz/hızlı testten başlayan elemeli sıra öner; konnektör/pitot kontrolünü parça değişiminden önce koy."
Bu prompt tipi, bağlamı, elemeli mantığı ve halüsinasyon frenini içerir.
Tablo: Arıza tespitinde rol dağılımı
Adım
YZ'nin işi
İnsanın işi
PIREP'i yapılandırma
Serbest metni alanlara ayırır
Ham tarifi bozmadan verir, doğrular
Kod yorumlama
Sözlük + olası neden listesi
Tipe uygunluğu FIM'de teyit eder
Hipotez üretme
Olasılıkları sıralar
Fiziksel testle eler
Test sırası
Elemeli sıra önerir
Ölçer, kaydeder, karar verir
Kapanış
Test/kayıt hatırlatır
Testi yapar, imzalar (CRS)
Sık yapılan hatalar
- Semptomu kök neden sanmak. Kod semptomdur; FIM ile kök nedene inin.
- Konnektör/kablolamayı atlayıp parça değiştirmek. NFF ve tekrar arıza üretir; maliyet ve risk artar.
- Pilot tarifini kendi yorumunuzla değiştirmek. YZ'yi baştan saptırır.
- Task numarasına güvenmek. YZ referans uydurabilir; FIM'de kendiniz görün.
- Kapanış testini atlamak. Onarım, iade testi ve kayıt olmadan tamamlanmış sayılmaz.
Özetle
Arıza tespiti bir kayıt-yapılandırma-izolasyon zinciridir. YZ belirsiz pilot tarifini yapılandırmada, hata kodunu insan diline çevirmede ve elemeli troubleshooting sırasını hatırlatmada güçlü bir asistandır. Ama kod semptomdur, teşhis değildir; olası neden listesi hipotezdir, karar değildir. Konnektör/kablolama kontrolünü parça değişiminden önce yapın, her referansı FIM'de doğrulayın ve onarımı iade testiyle kapatın.
Uygulama görevi
Elinizdeki (hassas olmayan) bir arıza kaydını alın. Birinci şablonla YZ'den yapılandırma isteyin, sonra üçüncü şablonla elemeli test sırası çıkarın. Gerçek FIM/AMM'den her adımın karşılığını bulun ve YZ'nin önerdiği sıralamayı kendi mesleki yargınızla düzeltin. Farkları bir tabloya yazın: YZ ne dedi, manuel ne diyor, siz ne karar verdiniz.
Kontrol listesi
- [ ] PIREP'i ham haliyle, yorum katmadan verdim.
- [ ] Arızayı doğru ATA bölümüne oturttum.
- [ ] Kodu tipe ve yazılım standardına göre FIM'de teyit ettim.
- [ ] Konnektör/kablolama kontrolünü parça değişiminden önce yaptım.
- [ ] Her FIM/AMM referansını orijinalinde gördüm; uydurmayı reddettim.
- [ ] Onarımı operasyonel/iade testiyle ve kayıtla kapattım.