Единици
1. Вовед во вештачката интелигенција во одржување на авиони и авионика: улоги, граници, верификација и безбедносно-критички принцип 2. Снимање на одржување и решавање проблеми: PIREP, кодови за грешки и решавање проблеми 3. Бела книга и рачно скенирање: AMM, IPC, SB, AD и верификација 4. Податоци за предвидливо одржување и сензори: Тренд, прогностика и HUMS 5. Авионски системи и изолација на дефекти: BITE, кабли и софтвер 6. Работен ред, планирање и работна сила: од картичка за задачи до CRS 7. Сообразност, сертификација и регулатива: Закон за пловидбеност 8. Делови, инвентар и синџир на снабдување: Следливост и ризик од фалсификувани делови 9. Квалитет, управување со безбедноста и човечки фактори: SMS и Dirty Dozen 10. Визуелна инспекција, NDT и компјутерска визија: споделување на оптоварувањето на очите 11. Случај за одржување од крај до крај: интеграција, граници, приватност и иднината
Единица 5 / 11

Авионски системи и изолација на дефекти: BITE, кабли и софтвер

Добивки:

  • Способност да се оддели неуспехот на авиониката во слоеви (каблирање, конектор, LRU, софтвер) и да се интерпретира пораката BITE како симптом
  • Способност да се имплементира изолациона секвенца што прво го елиминира конекторот/кабелот/земјувањето и софтверот/конфигурацискиот слој наместо да се обвинува LRU прерано
  • Способност да се разбере дека референците за пинови/шеми произведени од вештачката интелигенција мора да бидат потврдени сами по себе во WDM

Авиониката е „нервниот систем“ на авионот: навигација, комуникации, автоматски лет, дисплеј и системи за податоци. Механички дефект е често видлив и опиплив; Во конфигурацијата на сигналот, кабелот, конекторот или софтверот е скриен дефект на авионика. Затоа изолацијата на дефекти во авиониката е посебна дисциплина и овде вештачката интелигенција (ВИ) може да биде и многу корисна и погрешно. Во оваа единица, ќе покриеме како безбедно да се користи вештачката интелигенција во BITE, кабли и софтверски слоеви.

Анатомија на дефект на авиониката

Ајде да го разложиме авионскиот систем на слоеви: сензор/извор → жици/конектор → компјутерска единица (LRU) → софтвер/конфигурација → дисплеј. Овде, LRU (Line Replaceable Unit, комплетно отстранлива кутија на авионот; на пр. компјутер со податоци за воздух) е клучниот концепт. Неисправност може да се случи во која било врска од овој синџир. Честа грешка е директно да се обвинува LRU (најскапиот и највидлив прстен); Сепак, повеќето дефекти во авиониката се предизвикани од жици, конектори и заземјување.

BITE (Вградена опрема за тестирање - вграден хардвер на системот за самотестирање) е првата алатка во овој момент. Системот извршува BITE тест и генерира пораки за грешка. Сепак, пораката BITE е исто така симптом: пораката „Нема X сигнал“ може да биде предизвикана од LRU што произведува X, скршен кабел или лабав конектор. Вештачката интелигенција брзо ја толкува пораката BITE и набројува можни причини; но WDM (Wiring Diagram Manual) и мерењето одредуваат кој прстен е вистинскиот виновник.

Внимание: „Не е пронајдена грешка“ (NFF) е хронична во авиониката. Ако расклопите LRU и го испратите на тест-клупата и вели „нема грешка“, проблемот најверојатно е во авионот - во кабелот, конекторот, друга единица или периодично откажување. ВИ е склона да каже „промени го LRU“; Не паѓајте во оваа замка.

Кабел и конектор: слој кој најмногу се прескокнува

Златното правило за смена на проблеми со авиониката: проверете ја патеката пред да го замените делот. LRU не може да се обвини без да се провери поставеноста на игличките на конекторот, континуитетот на кабелот, отпорот на изолацијата, заземјувањето и врзувањето. Вештачката интелигенција ќе ви помогне да следите каде оди иглата кога давате WDM, наведувајќи кои жици/пинови се сомнителни за дефект - но никогаш не барајте од него да ги „запомни“ броевите на пиновите и шематските референци; дајте ја шемата и таа ќе ја прочита (RAG логика).

Софтвер и конфигурациски слој

Во модерната авионика, некои од дефектите не се во хардверот, туку во софтверскиот број на дел или конфигурациската некомпатибилност. LRU може да е точен, но со инсталиран погрешен софтверски стандард; или поставката за програмирање/опција на пиновите е неточна. SB може да бара одредена верзија на софтверот. Вештачката интелигенција прашува „дали оваа грешка е поврзана со одреден софтверски стандард? ве потсетува да ги погледнете соодветните SB во прашањето; но вие ја потврдувате компатибилноста во официјалната табела за компатибилност на производителот.

Совет: Во случај на дефект на авиониката, вашата нарачка треба да биде: (1) читање и снимање на BITE, (2) потврдете го конекторот/кабелот/земјувањето, (3) потврдите стандард за софтвер/конфигурација, (4) размислете за замена на LRU само тогаш, (5) враќање/оперативен тест по секоја замена. ВИ може да се потсети на оваа низа; Ваша одговорност е да не го прескокнете.

три мини футроли

Случај 1 - Конектор зачуван LRU. Имаше периодично затемнување на единицата за прикажување. BITE даде порака „загуба на податоци при прикажување“. ВИ ги наведе можните причини; LRU беше прв во редот, но техничарот ја следеше својата наредба: го расклопи и исчисти конекторот, најде оксидација на една игла. По чистењето, дефектот исчезна. Замена на LRU од приближно 40.000 долари и времето за испорака не беше непотребно потрошено.

Случај 2 - Некомпатибилност на софтверски стандард. Функцијата не работеше по замена на единицата за навигација. YZ рече дека „новиот LRU веројатно бара различен софтверски стандард, проверете го соодветниот SB“. Инженерот погледна во табелата за компатибилност на производителот: тој навистина требаше да инсталира одреден софтвер. Вклучена е функцијата по инсталацијата; се избегнува непотребната втора замена на LRU.

Случај 3 - Халуцинација: нашминкана игла. YZ даде референца за дефект бидејќи „пинот J2-14 на WDM оди на земја“. Кога техничарот го вклучи WDM, виде дека J2-14 е различен сигнал; Вештачката интелигенција го сочинуваше бројот на пинот. Кога самиот ја погледна шемата, точната игла беше различна. Ако беше измерена погрешна игла, дијагнозата ќе одеше во погрешна насока со часови.

Четири шаблони за копирање

Улога: асистент за толкување пораки BITE. Задача: Наведете ги можните причини за „[BITE message]“ за [Тип на авион + систем], мерниот синџир (приклучок-кабел-земјување) ПРЕД, LRU ПОСЛЕ. Правила:- Референца за игличка/шема ПОСТАВУВАЊЕ; Кажете „Погледнете ја соодветната страница во WDM“. - Наведете дека ова е симптом и дека основната причина ќе се најде со изолација. Порака BITE: [порака + контекст]

Улога: Помошник за читање дијаграм за поврзување (само врз основа на дијаграмот што го дадов). Задача: Наведете ги игличките и прицврстувачите поврзани со [сигнал/функција] во цитатот на WDM подолу. Правила: Само врз основа на овој цитат; Генерирање пин/број што не е вклучен во понудата; Во спротивно, кажете „не е во наводник“.

Улога: Водич за секвенца за изолација на авионика. Задача: Препорачај секвенца за отстранување за следната грешка (BITE → конектор/кабел→ софтвер/конфигурација → LRU → тест за враќање). Правила: Наведете што да се мери на секој чекор и во кој прирачник е дефиниран нормалниот опсег; вредност FITTING.Грешка: [опис]

Улога: Потсетник за компатибилност на софтвер/конфигурација. Задача: Наведете како да ја потврдите компатибилноста на софтверскиот стандард/конфигурација за следната замена на LRU. Правила: Наведете дека мора да ја потврдам компатибилноста во официјалната табела на производителот; бројот на верзијата е FITTING. Размена: [LRU + тип + бизнис контекст]

Слаб промпт / Силен промпт

Слабо: "Има порака за загуба на податоци на екранот, кое поле да го сменам?"

Скока директно до замена на LRU, заобиколувајќи го слојот за кабли/конектор и софтверот и носи ризик од лажни референци.

Силно: „[Тип на авион]. ГРИЗ „Губење на податоци при прикажување“, наизменично, предизвикувачи при тресење. Наведете ги можните причини прво конектор/кабел/земјување, подоцна LRU; кажи ми што да мерам на секој чекор; референцата за игла/шема е фиктивна, потсетете ме да погледнам во WDM; додајте тестирање за враќање“.

„Интермитентно“ и „активирано при тресење“ се силни индиции за насоката на конекторот/неконтактниот и промптот ги користи.

Табела: Слоеви на дефекти на авионика и почетна проверка

слој

типичен симптом

прва проверка

возилото

жици/конектор

Наизменично, тресење

Континуитет, седење игла, оксид

Мултиметар, WDM

Заземјување/сврзување

бучава, пречки

отпорност на врзување

мерач за врзување

LRU

Фиксна, повторлива

ГРИЗ + потврда за клупа

ГРИЗ, тест клупа

Софтвер/конфигурација

Нема функција по замена

Софтверски дел бр, табела за компатибилност

Табела на производителот

Вообичаени грешки

  • Прво да се обвини ЛРУ. Повеќето дефекти на авиониката се предизвикани од кабли/конектори.
  • Мислејќи дека NFF е „распуштен“. Ако нема дефект во машината, проблемот може да е во авионот.
  • Тестирање на интермитентна грешка како да е поправена. Повторете ја состојбата на активирањето (вибрации, температура).
  • Заборавајќи го слојот за софтвер/конфигурација. По промената е потребна потврда за компатибилност.
  • Прифаќање на референцата за игла/шема од вештачката интелигенција. Проверете го WDM сами.

Сумирано

Изолацијата на дефекти на Авионика е повеќеслојна работа: BITE дава симптом, вистинската основна причина често е во жици, конектор, заземјување или софтверски слој. Вештачката интелигенција е моќна во толкувањето на BITE пораката, читањето на WDM (кога ќе го дадете) и потсетувањето на наредбата за елиминација; но ја балансирате тенденцијата рано да се обвинува LRU и ризикот од изработка на пинови/референци. Секвенца: BITE → кабли → софтвер → LRU → повратен тест.

Задача за апликација

Изберете порака BITE за авиони. Добијте веројатни причини и редослед на елиминација на изолација од вештачката интелигенција со првиот и третиот шаблон. Потврдете ја релевантната игла/опрема од WDM и прашајте „Дали LRU дојде прв?“ по наредба на вештачката интелигенција. Проверете го. Напишете ја вашата сопствена безбедна секвенца и оправдајте ја разликата.

листа за проверка

  • [ ] Пораката BITE ја третирав како симптом, а не како дијагноза.
  • [ ] Го проверив конекторот/кабелот/земјата пред LRU.
  • [ ] Го тестирав наизменичниот дефект со состојба на активирањето.
  • [ ] Ја потврдив компатибилноста на софтверот/конфигурацијата во официјалната табела.
  • [ ] Сам го потврдив пинот/референците на WDM; Одбив да измислам.
  • [ ] Извршив враќање/оперативни тестови по секоја замена/поправка.