единици
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

Авиониката е "нервната система" на самолета: навигация, комуникации, автоматичен полет, дисплей и системи за данни. Механичната повреда често е видима и осезаема; Грешка в авиониката е скрита в сигнала, кабела, конектора или софтуерната конфигурация. Ето защо изолирането на повреди в авиониката е отделна дисциплина и тук изкуственият интелект (AI) може да бъде както много полезен, така и подвеждащ. В този раздел ще разгледаме как да използваме безопасно AI в BITE, окабеляване и софтуерни слоеве.

Анатомия на повредата на авиониката

Нека разделим една авионика на слоеве: сензор/източник → окабеляване/конектор → изчислителен модул (LRU) → софтуер/конфигурация → дисплей. Тук LRU (Line Replaceable Unit, напълно подвижна кутия в самолета; напр. компютър за данни за въздух) е ключовата концепция. Неизправност може да възникне във всяка връзка от тази верига. Често срещана грешка е директно да се обвинява LRU (най-скъпият и най-видимият пръстен); Повечето неизправности в авиониката обаче са причинени от окабеляване, конектори и заземяване.

BITE (Вградено тестово оборудване — вграден хардуер за самотестване на системата) е първият инструмент в този момент. Системата изпълнява BITE тест и генерира съобщения за грешка. Въпреки това, съобщението BITE също е симптом: Съобщението „Няма X сигнал“ може да бъде причинено от LRU, произвеждащ X, счупен кабел или разхлабен конектор. AI ​​бързо интерпретира съобщението BITE и изброява възможните причини; но WDM (Ръководство за диаграма на окабеляване) и измерването определят кой пръстен е истинският виновник.

Внимание: „Няма открита грешка“ (NFF) е хронична в авиониката. Ако разглобите LRU и го изпратите на тестовия стенд и той каже „няма повреда“, проблемът най-вероятно е в самолета — в кабела, конектора, друго устройство или периодична повреда. AI е склонен да каже „промени LRU“; Не попадайте в този капан.

Окабеляване и конектор: най-пропусканият слой

Златното правило за отстраняване на неизправности в авиониката: проверете пътя, преди да смените частта. LRU не може да бъде обвиняван, без да се провери разположението на щифтовете на съединителя, непрекъснатостта на кабела, съпротивлението на изолацията, заземяването и свързването. Изкуственият интелект ще ви помогне да следите кой щифт къде отива, когато подадете WDM, изброявайки кои проводници/щифтове са подозрителни за повреда - но никога не го молете да "запомни" номерата на щифтовете и схематичните препратки; дайте схемата и тя ще я прочете (RAG логика).

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

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

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

три мини калъфа

Случай 1 — Съединител, запазен LRU. Имаше периодично затъмняване на дисплей. BITE даде съобщение "загуба на данни на дисплея". AI изброи възможните причини; LRU беше първи на опашката, но техникът следваше собствената си поръчка: разглоби и почисти конектора, откри окисляване на единия щифт. След почистване повредата изчезна. Замяната на LRU на стойност приблизително $40 000 и времето за доставка не бяха пропилени ненужно.

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

Случай 3 — Халюцинация: измислена игла. YZ даде справка за повреда като "щифт J2-14 на WDM преминава към маса". Когато техникът включи WDM, той видя, че J2-14 е различен сигнал; AI беше измислил ПИН номера. Когато самият той погледна схемата, правилният щифт беше различен. Ако беше измерен грешният щифт, диагнозата щеше да върви в грешна посока за часове.

Четири копируеми шаблона

Роля: Асистент за тълкуване на съобщения BITE. Задача: Избройте възможните причини за "[съобщение BITE]" за [Тип самолет + система], измервателна верига (конектор-кабел-заземяване) ПРЕДИ, LRU СЛЕД. Правила: - ПИН/схема референтен МОНТАЖ; Кажете „Вижте съответната страница в WDM“. - Посочете, че това е симптом и първопричината ще бъде открита чрез изолиране. Съобщение BITE: [съобщение + контекст]

Роля: Помощник за четене на схеми на свързване (само въз основа на диаграмата, която предоставих). Задача: Избройте щифтовете и сноповете, свързани с [сигнал/функция] в WDM цитата по-долу. Правила: Въз основа само на този цитат; Генериране на ПИН/номер, който не е включен в офертата; В противен случай кажете „не е в кавички“.WDM цитат: [поставете текст/таблица на схема]

Роля: Ръководство за последователност на изолиране на авиониката. Задача: Препоръчайте последователност за отстраняване на следната повреда (BITE → конектор/кабел → софтуер/конфигурация → LRU → тест за връщане). Правила: Посочете какво да измервате на всяка стъпка и в кое ръководство е определен нормалният диапазон; стойност FITTING.Error: [описание]

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

Слаба подкана / Силна подкана

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

Прескача направо към подмяната на LRU, заобикаляйки слоя окабеляване/конектор и софтуера, и носи риск от фалшиви препратки.

Силно: "[Тип равнина]. BITE "загуба на данни на дисплея", периодично, задейства се при разклащане. Избройте възможните причини първо конектор/кабел/заземяване, LRU по-късно; кажете ми какво да измервам на всяка стъпка; препратка към щифт/схема е фиктивна, напомнете ми да погледна WDM; добавете тестване за връщане."

„Прекъсващ“ и „задействан при разклащане“ са силни улики за посоката на конектор/безконтактно и подканата ги използва.

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

слой

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

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

превозно средство

окабеляване/конектор

Прекъснат, треперещ

Непрекъснатост, поставяне на щифта, оксид

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

Заземяване/свързване

шум, смущения

устойчивост на залепване

свързващ метър

LRU

Фиксиран, повторяем

BITE + потвърждение на пейка

BITE, стенд за изпитване

Софтуер/конфиг

Без функция след смяна

Номер на софтуерна част, таблица за съвместимост

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

Често срещани грешки

  • Първо трябва да обвиним LRU. Повечето неизправности на авиониката се причиняват от кабели/конектори.
  • Мисля, че NFF е „разтворен“. Ако няма неизправност в машината, проблемът може да е в самолета.
  • Тестване на периодична повреда, сякаш е отстранена. Повторете състоянието на задействане (вибрация, температура).
  • Забравяне на софтуерния/конфигурационния слой. След промяната е необходимо потвърждение за съвместимост.
  • Приемане на препратката към ПИН/схема от AI. Проверете сами WDM.

В обобщение

Изолирането на неизправности в авиониката е многопластов бизнес: BITE дава симптом, истинската основна причина често е в окабеляването, конектора, заземяването или софтуерния слой. AI ​​е мощен при интерпретирането на съобщението BITE, четенето на WDM (когато го дадете) и напомнянето за реда за елиминиране; но вие балансирате тенденцията да обвинявате LRU рано и риска от фабрикуване на щифт/референтен код. Последователност: BITE → окабеляване → софтуер → LRU → тест за връщане.

Задача за приложение

Изберете съобщение BITE от авиониката. Вземете вероятни причини и ред за елиминиране на изолация от AI с първия и третия шаблон. Проверете сами съответния щифт/кабел от WDM и попитайте "LRU ли дойде първо?" в реда на AI. Проверете го. Напишете своя собствена безопасна последователност и обосновете разликата.

контролен списък

  • [ ] Приех съобщението за УХАПВАНЕ като симптом, а не като диагноза.
  • [ ] Проверих конектора/кабела/масата преди LRU.
  • [ ] Тествах периодичната повреда с условие за задействане.
  • [ ] Потвърдих съвместимостта на софтуера/конфигурацията в официалната таблица.
  • [ ] Проверих сам WDM щифта/референциите; Отказах да го измисля.
  • [ ] Извърших връщания/оперативни тестове след всяка подмяна/ремонт.