Сбор, обработка, анализ информации о неисправностях и БП?

www.mtain.com

Про FRACAS, и, кстати, про неподвержденные отказы ...

Defect Report and Corrective Action System (DRACAS)

DRACAS- is a formal closed-loop reporting system that requires each reported failure to be analyzed from an maintainability perspective and if necessary, followed up with a corrective action. This system would be used in unison with the FRACAS. However, the objective of this data collection system would be to obtained specific maintainability data.

The collection of data could start early in a design and development phases and continue to be implemented into the operational or fielded phase. The type of data to be collected, with respect to maintainability would ascertain the maintainability characteristics of a system. This data could include actual maintenance elapse times, observation on the BIT performance, discrepancies in technical manuals and documentation, criteria tied to actual repair actions, and any supporting dispositions. For example, where it is observed that for a particular assembly, a large percentage of these assemblies are returned from a supplier as a No-Fault-Found (NFF) or No-Evidence-Of-Failure (NEOF). Upon investigation by the vendor they were unable to locate any faults associated with the assembly in question and after testing, to verify its operational status, returned it to the user as NFF. This type of scenario has an adverse impact upon the operational support cost of a system. The impact upon a system's Life Cycle Cost of those items being found to be NFF is augmented, as there is a cost associated with removing "serviceable" items from a system and entering them into the repair loop. The cause of this maybe as a result of the ineffective diagnostics routine, technical manuals and/ or training of the maintainers

There are many maintainability issues that could have an impact upon the operational Life Cycle Cost for a system. These need to be identified and addressed in a systematic fashion.

Что касается неподвержденных отказов, то в буржуазных GENERAL CONDITIONS OF PURCHASE CUSTOMER SUPPORT между изготовителем ВС и поставщиком ПКИ существует специальный раздельчик:

APPENDIX D NO FAULT FOUND POLICY
Definition of terms


Equipment such as proximity switches, pressure transducers, circuit breakers and hydraulic, mechanical and engine system parts are not included in the NFF policy. Such cases may be reviewed with the aim of improving maintenance practises - including Trouble Shooting Manual (TSM) quality -but the decision to remove a part will remain with the Operator.

It has been found that such cases are impossible to adjudicate as far as assessing the responsibility within the standard maintenance practises.

The NFF Policy is intended for application with avionic components.

Aims and benefits to be achieved from implementing this policy
The policy applies to Line Replaceable Units (LRUs) returned to the Supplier or to a Supplier’s authorized repair station.

o Reduction of No Fault Found costs for the Airline.

o A better understanding of the Centralized Fault Display System (CFDS) and Centralized Maintenance System (CMS). Reduced system interrogation times as experience is gained. This is in conjunction with the revised A320 Trouble Shooting Manual (TSM), which is in the same format as the A330/A340 document.

o A better understanding between all parties and quicker resolutions of NFF issues will ensue. The Supplier's authorized repair station will contact the Operator to ensure that reasons for removal are understood and to obtain historic data on the units. Airbus Industrie may be involved to make sure all causes are documented and to resolve any interface issues with regard to the application of the
NFF policy.

o Reduction of unjustified removals will result in optimum utilization of spares.

o Improvement of the TSM procedures through correlation of common NFF removals.

o Time to identify rogue LRUs will be reduced through analysis of historic records.

o This policy is based on the minimum supporting data required to
substantiate an unscheduled removal. In developing the policy Airbus Industrie has given careful consideration to operational restrictions.

Supplier's responsibility

The Supplier is responsible for keeping historic data by serial number of all units. These files should not only contain data on a LRU warranty aspects but also on the total repair history, reasons for removal, testing, NFF, modification standard and all the work performed on the LRU.

In taking the leadership of the removal analysis, the Supplier or Supplier's authorized repair station will contact the Operator to obtain any information associated with the LRU removal required to complete the LRU history.

Operator’s responsibility

The application of the policy along with an adequate Operator involvement in trouble shooting will significantly lower the number of NFF cases.
The Operator will provide the minimum data for removal substantiation.
The removal data are:

The initiating Pilot Report (PIREP) and/or Maintenance Report (MAREP) and Post Flight Report (PFR) and The BITE/Trouble Shooting Data (TSD) printout as applicable

Or

The failure results of the return to service test procedure (as per CMM) and historic data of all NFF occurrences at Operators facility (for LRU history files) This policy presupposes that the Airbus Industrie operational

- Flight Crew Operating Manual (FCOM)
including Operation Engineering bulletins (OEBs) - and maintenance recommendations are followed.
The operator is requested to include a technical contact on the paperwork.

NFF charges

Tests resulting in NFF may be charged whenever:
No supporting data is supplied with the unit
The supporting data does not substantiate the removal
Operator chooses not to provide the substantiating data after the request of the Supplier's repair station.

When no LRU defect is found to be the origin of a fault message, the cause will be clarified between the Supplier and Airbus Industrie. The Supplier will open a specific file for these cases.

Airbus Industrie and the Suppliers will not support NFF cases where clear TSM procedures, in relation to a PFR warning message, provide for correct system trouble shooting.

Automatic Test Equipment (ATE) at Operator's facility

The Operator shall not be deemed responsible where it is shown that the LRU test specification is incomplete or incorrect.
The LRU Supplier takes responsibility to verify test specifications.
The ATE manufacturer is responsible for translation of test specifications.
Where the LRU test specification published in the CMM is shown to be correct, the Operator’s selected ATE manufacturer is responsible to clarify NFF resulting from incorrect implementation. If necessary, Airbus Industrie will mediate disputes for such issues.

PROCEDURE ON AIRCRAFT

Action is initiated by a cockpit effect or repetitive CFDS fault. A cockpit effect can be in the form of an ECAM warning or aural call out, or crew observation leading to log book entry.

Log Book entry

All entries are made by the flight crew (PIREP) or maintenance personnel (MAREP) into the aircraft log.

Post Flight Report (PFR)

A summary of ECAM warning messages. These are identified and cross referenced at the time of message occurrence and ATA chapter reference of the equipment involved. A print is made of the PFR.

BITE test

Interrogation of CFDS/CMS to confirm equipment fault in reference to the PFR warning or log book entry.

Fault confirmed by BITE test

When the fault is confirmed by CFDS the unscheduled removal is supported.

A print is made of the BITE test results and returned with the removed LRU.

The LRU is removed in accordance with TSM procedures and dispatched to Supplier's authorized repair station with supporting data.

In this case the supporting data is the PFR and/or the logbook, and the BITE test results (where applicable).

Fault not confirmed by BITE test

In the case of intermittent faults, the decision to remove the LRU may be delayed until time allows deeper trouble shooting. Prior to the LRU removal the Trouble Shooting Data should be retrieved.

Trouble Shooting Data (TSD)

Snapshot of system at time of ECAM warning (creation of PFR message). This allows an analysis of the system and to correctly attribute the failure. A print is made of the TSD and returned with the removed LRU.


The LRU is removed in accordance with the TSM and dispatched to the Supplier’s authorized repair station with the supportive data.

In this case the supporting data is the PFR and TSD.

PROCEDURE IN OPERATOR SHOP

Fail Test at Test Bench
If the LRU fails test then it is sent for repair.
If the LRU passes the test it is returned to service.

Unscheduled removal supported by ATE results The LRU is returned to Supplier repair station together with the ATE failure report. In this case the supporting data is the PFR and the ATE report.

CFDS/CMS print included with LRU

If the PFR plus the BITE Test Results or TSD as applicable or the ATE failure results are included and demonstrate (in conjunction with TSM) that the removal is justified, then no testing charges will apply in case of NFF.

If the above data confirm Aircraft system fault, and if no Airbus Industrie Operational or Maintenance procedure exists to prevent LRU removal, Airbus Industrie will warrant that the Aircraft system responsible party supports test charges.

Removals not supported by CFDS/CMS data

The LRU is considered as an unsupported unscheduled removal.
The Operator is charged for testing in case of NFF.

Ну и т.д. ...

Очень интересная штука.
 
Реклама
2 Strek:
Спасибо за полезную ссылочку на Mtain.
Собственно в моем понимании основными игроками во FRACAS должны быть:
группа надежности АТБ/АК <--> отдел/бригада надежности ОКБ+КБ надежности завода
а сейчас вот так:
ГЦ БПВТ --> отдел/бригада надежности ОКБ
т.е. никаго closed-loop нет и в помине даже на уровне анализа, про корректирующие действия вообще молчу.
ОКБ не имеют прямых источников финансирования на разработку корректирующих действий, тока ежели по коммерческому контракту с АК.
Однако это не совсем красиво выглядит, если налицо КПН.
Еще сложнее если это КПН ПКИ, вендор может вообще отказаться что либо делать, даже за деньги.
Проблема закручена на общих и финансовых взаимоотношениях участников "процесса поддержания летной годности". Как это распутать пока не представляю...
 
Мужики, ещё одна проблема, возможно, только для меня:

если ВС в лизинге, кто контролирует все эти вещи? Кто определяет правильность ТО, кто анализирует информацию по отказам и т.п.?
 
По всем канонам в коммерческой авиации это Operator + State of Registry, а в АОН (бизнес) - Owner + State of Registry
 
А хорошо стали "заглубляться" по NFF!
Может и выработаем в итоге некий подход к нормированию и процедурному обеспечению этой составляющей эксплуатационных свойств... Strek спасибо за инфо, изучаю
 
MsKos сказал(а):
2 Strek:
Собственно в моем понимании основными игроками во FRACAS должны быть:
группа надежности АТБ/АК <--> отдел/бригада надежности ОКБ+КБ надежности завода
а сейчас вот так:
ГЦ БПВТ --> отдел/бригада надежности ОКБ
т.е. никаго closed-loop нет и в помине даже на уровне анализа, про корректирующие действия вообще молчу.
ОКБ не имеют прямых источников финансирования на разработку корректирующих действий, тока ежели по коммерческому контракту с АК.
Однако это не совсем красиво выглядит, если налицо КПН.
Еще сложнее если это КПН ПКИ, вендор может вообще отказаться что либо делать, даже за деньги.
Проблема закручена на общих и финансовых взаимоотношениях участников "процесса поддержания летной годности". Как это распутать пока не представляю...

Мы относительно недавно работаем в гражданском самолетостроении, но я до сих пор не понял пользы от ГЦ БПВТ. Они, собирая у себя информацию по отказам, выпускают лямбда справочники или нет?

Если нет, то какая от них вообще польза?

По поводу источника финансирования ОКБ по вопросу FRACAS. М. С. по сути это авторский надзор в эксплуатации. И судя по тем спорам, которые возникают на конференциях по БП в АР МАК эксплуатант не имеет особого желания финансировать эту деятельность.

При наличии понимания и нормальных взаимоотношений эта проблема может быть решена путем договорных отношений между разработчиком и изготовителем. На данном этапе, по самолетам Бе-103 и Бе-200 мы именно так эту проблему и решили. Наши заводы-изготовители проявили понимание и мы с ними договорились о том, как осуществлять авторский надзор в эксплуатации, по крайней мере, на начальном периоде.

А хорошо стали "заглубляться" по NFF!
Может и выработаем в итоге некий подход к нормированию и процедурному обеспечению этой составляющей эксплуатационных свойств... Strek спасибо за инфо, изучаю

Могу и целиком выслать договорчик. 8-)
 
Strek сказал(а):
:
По поводу источника финансирования ОКБ по вопросу FRACAS. М. С. по сути это авторский надзор в эксплуатации. И судя по тем спорам, которые возникают на конференциях по БП в АР МАК эксплуатант не имеет особого желания финансировать эту деятельность.

Рискну вставить свои 5 копеек... Наверное проблема в том, что несмотря на всякие интеграционные процессы в авиапроме ОКБ продолжают функционировать по старой схеме. За бугром поставщик изделия, как правило, имеет с эксплуатантом Service Level Agreement на весь гарантийный, а во многи случаях и постгарантийный период. Именно там зарыты деньги (регулярно капающие на счвет поставщика), за счет которых он ведет всю работу с FRACAS. А клиент, осознавая за что платит немалые деньги, скурпулезно ведет учет дефектов и принятых корректирующих мер. Ибо отсутствие правильно оформленой и своевременно введенной в систему информации об отказах и дефектах автоматически лищает клиента права не "условно бесплатную" поставку запчастей... "Условно бесплатную" - в том смысле, что эксплуатант в рамках SLA платит за все про все фиксированную цену и заинтересован получить за это максимум услуг...
 
ИМХО помимо отсутствия культуры/практики заключения долговременных соглашений с эксплуатантом о сервисном обслуживании есть еще одно препятствие в налаживании хорошей обратной связи между разработчиком и эксплуатантом - опять тот же человеческий фактор. Заполнение всяческих учетно-регистрационных форм - всегда дополнительная работа. А человек по своей природе ленив и склонен рассуждать просто: я выполняю основную работу (ТО или ремонт) и зачем мне вся эта формалистика? Т.е. важная для разработчика/поставщика в лучшем случае делается по остаточному принципу - в последний момент, когда наступает время отчетности. О достоверности придуманной с потолка информации говорить не приходится. Сам когда-то (во времена службы в ВВС) лихорадочно заполнял КУНы в конце года, придумывая отказы и дефекты практически "от фонаря"...
Мне кажется повысит дисциплину учета и отчетности по отказам/дефектам в эксплуатации можно, "встроив" соответствующие операции в сам регламент ТОиР, одновременно избавив персонал от необходимости двойного ввода данных (в бумажных и электронных формах). Например путем придания электронных системам и электронному делопроизводству законный статус. А вместе с самолетом поставлять эксплуатанту соответствующий инструментарий...
 
Мне кажется повысит дисциплину учета и отчетности по отказам/дефектам в эксплуатации можно, "встроив" соответствующие операции в сам регламент ТОиР, одновременно избавив персонал от необходимости двойного ввода данных (в бумажных и электронных формах). Например путем придания электронных системам и электронному делопроизводству законный статус. А вместе с самолетом поставлять эксплуатанту соответствующий инструментарий...

Юра, так и я про то же. Я считаю, что если мы хотим получать данные об эксплуатации, то получить эти данные мы должны не из дополнительных примочек, которые кое-кто лоббирует, а из тех систем, которые обеспечивают работу оперетора, АТБ и т.д.

Т.е. Выдача нам данных не должна иметь сколь нибудь значительной трудоемкости для эксплуатанта, а проистекать из его повседневной деятельности.

Об этом я и говорил в МАКе. Но есть же масса голодных разработчиков софта ...
 
Всё равно достоверность первичной информации - большая проблема, но одна из основных. Что обрабатывать, если отказ определён неправильно?
 
Реклама
Plivet,
А что значит отказ определен неправильно? Эксплуатант это делает до уровня конструктивно-сменной в условиях эксплуатации единицы. Если у него есть диагностические средства - то он кронечно может копнуть глубже, но окончательные выводы - за ремонтной организацией. Но даже если учет отказов и статистику вести только на уровне КСЕ - уже будет большая польза. ИМХО...
 
Yuha,

это только теоретически. Практически снимается куча блоков по одному отказу. На них на всех заполняется одна КУН. Если есть возможность и персонал, тогда определяется, а если нет, то всё, действительно, отправляется в ремонт. Что делает ремонт? Неужели напишет, что всё исправно и откажется от бабок?
Я уже приводил пример того, что блок по одному и тому же отказу снимался и отправалялся в ремонт 6 раз. Всё время оплачивался капремонт.

Мною отказ был выявлен и устранён только применением нетривиальной технологии, которая не была предусмотрена РТО, но дала результат.

Жизнь, к счастью, многообразней регламентов...
 
2 Strek:

1) По поводу пользы ГЦ БПВТ:
Они выпускают и приторговывают "желтыми" книжечками, т.н. отчетами, в основном по инцидентам. Инциденты мы и сами рассматривать можем.
Прислали как-то раз данные по наработке на отказ для компонентов восьмерок. Так ухитрились посчитать, что на вертолете оказалась 1 лопасть несущего винта вместо 5, т.е. не учли поправку на количество однотипных компонентов, поэтому их цифирки оказались в 2-3-5 раз хуже чем есть, даже по их данным по количеству отказов.
Кроме этого, присылают они не весь набор информации, которую получают от эксплуатанта, а в урезанном варианте, сам проверял (подробности могу отмылить). Нет у меня к ним доверия...
2) По поводу авторского надзора в эксплуатации:
Главная причина его "смерти" действительно в нежелании эксплуатанта платить непонятно за что. Опять все тоже отутствие closed-loop или "пряника".
На мой взгляд ценность старого авт.надзора была в том, что проблемы получали из первых рук, и в результате личного общения с людьми многое становилось понятнее, и тогда по возращении готовились толстые годовые бюллетени по уточению ЭД. Как-то возродить надзор в гарантийный период наверное возможно, а в послегарантийный - большая пронблема, по крайней мере сейчас.

2 Yuha:

По поводу заполнения КУН:
В бумажные РО и РЭ можно и вставить, что собственно и делаем, но надежды на то, что заработает, все равно мало (нет если по-честному). Даже можно и в электронные РО и РЭ вставить, с тем же эффектом. Инструментарий тоже вроде как имеется и Эрлане и в Руслане, да и свой смогем, если надо. Все равно инфу надо вбивать ручками, неважно за клавой ты сидишь или за бумажным бланком.
Истина возможно лежит где-то в другой плоскости. Чтобы ввод и передача инфы стала для эксплуатанта нормальной повседневной работой должна быть полная интеграция этого процесса с процессами диагностирования отказов, заявок на склад, оформления передачи компонентов в ремонт, заказов на поставку запчастей. Возможно это уже зашито где-то в АТА 2000 или АЕСМА 2000М? У меня все никак не получается разобраться с этими зарубежными "механизьмами".
 
///По поводу заполнения КУН:

А нужен ли вообще, наш, российский КУН в ТАКОМ виде?

Мы, например, от МЧС так и не добились его заполнения и высылки.
Разработали более упрощенную форму, которую опять же заполняет не эксплуатант, а наш представитель у эксплуатанта.
 
MsKos,

мужики, я не о том. Кто определит отказ комплектующего изделия? Посадить писать можно и девочку после школы. Кто сделает анализ блока? Его дефектацию? Даже экипаж записывает проявление отказа во время полёта "как Бог на душу положит". Иногда т.н. "неподтверждающийся" отказ несколько экипажей записывают одинаково, переписывая предыдущую запись из Б/Ж, а после разговора с командиром выясняешь совершенно иные признаки.

Например: запись в б/ж типа "раскачка по продольному каналу". Естественно смотришь канал тангажа САУ, выводишь в ноль закон управления. Оказывается, что происходят колебания указателя АУАСПа, а сам самолёт не качает. Совершенно другой отказ и в другом месте.

Так что я о достоверности первичной информации. КУН или подобный документ - это уже не первичная информация, это продукт анализа с субьективной оценкой.
 
Plivet,
Что-то я совсем не въезжаю... :( Не знаю, как теперь в ГА, но 20 лет назад в ВТА, обслуживая то же САУ :D я искал отказы/дефектовал блоки "классическим" способом последовательной замены "подозрительных блоков. Получал от экипажа замечание в виде упомянутой тобой записи в б/ж и начинал ковыряться. Иногда командир ленился записывать претензию и я это делал сам. Это важный момент! Ибо запись не считается закрытой до тех пор, пока не отписан способ устранения дефекта и не полученно подтверждение, что дефект фактически устранен. И это был мой свинячий бизнес - устранить дефект. Дальше все зависило от квалификции. Один предпочитал, не приходя в сознание, перебрать с десяток блоков кряду, а другой сначала думал, а потом действовал... Заключительная стадия жизненного цикла записи в б/ж - подтверждение устранения. Если устранение дефекта подтверждено - значит блок, который поменяли - действиительно дефектный и его можно отправлять в ремонт...
Или ты хочешь сказать, что ввиду дефицита времени на разбирательство - с борта снимают весь комплект САУ и меняют его на новый? :eek: Не быстрее будет подумать и сделав пару перекрестных замен (левый на правый и т.п.) вычислить "скурвившийся" агрегат?
 
Рассуждаем дальше... Зачем нужны КУН? Ведь они по сути - результат перелопачивания, в лучшем случае, фактических данных из журналов учета отказов/дефектов. Разрыв во времени между регистрацией дефекта в журнале и оформлением КУН - хороший повод для искажения фактической информации. Так зачем разделять эти вещи? Инфу нужно вводить один раз в одном месте. Это постулат информационных технологий...
 
Strek,
ИМХО более упрощенные формы КУН не меняют сути дела, если система остается та же, т.е. одну и ту же инфу нужно записывать два и более раз в разных формах. Система регистрации и учета отказов/дефектов ДОЛЖНА БУТЬ ОДНА. Использование этой ЕДИНОЙ системы по назначению должно иметь два аспекта:
- Оперативное: регистрация и отслеживание устранения каждого отказа/дефекта (то что нужно эксплуатанту сейчас и сегодня)
- Неоперативное: накопление и систематизация данных по зарегистрированным дефектам/отказам (то что нужно разработчику/производителю интегрально за какой-то промежуток времени)
 
Реклама
Юра, все это в системах "ИЛП" Эксплуатанта уже реализовано.
Например, в том же Эрлане. Вопрос только в одном, как эти данные получить от эксплуатанта? 8-)
 
Назад