/// Последняя попытка научится строить систему поддержки эксплуатации и управления ЖЦ ВС по человечески. ///

Имеется ввиду авиапром в целом :(

А кто рулить этой темой на "танке" будет?

Автор этого сообщения.
Если есть вопросы не стесьняйтесь задавать.

Сейчас в опытную эксплуатацию передены следующие модули:

 Eagle - LSAR Def Stan 00-60;
 Aspect - Initial Provisioning ASD 2000M;
 AcquirED - Common Source Database ASD 1000D;
 matriX - IETP Viewer;
 Print Services - Hardcopy manual production;
 EPIC - SGML editror.

Судя по названию модулей это система создания
эксплуатационной документации, Я прав?
Все таки поддержка эксплуатации и тем более управление ЖЦ более глобальные понятия.

2Vb

Ядро системы - модуль Eagle.
Это инструмент для проведения анализа логистической поддержки (АЛП). Работает как по MIL-STD 1388, так и по DEF STAN 00-60.

Он обеспечивает ввод данных и автоматизацию решения логистических задач: анализ уровней ремонта, обслуживание, эксплуатация, надежность, ремонтопригодность, вспомогательное оборудование, снабжение, инфраструктура и т.д.

Интегрируется с со следующими системами?

ASPECT.cs (начальное МТО, каталоги),

AcquirED (подготовка эксплуатационной документация).

PLANET.LCC (Расчет стоимости ЖЦ)

E-Learning (автоматизированные обучающие системы)



Эта интеграция обеспечивает эффективное повторное использование логистических данных и гарантирует единое пространство данных.


E-Learning у них в разработке. В настоящий момент готов инструмент для создания LMS - Learning Menagement System. В апреле появиться возможность генерировать из общей БД сами учебные модули.

На подходе инструмент для стыковки с PDM системами на основе 10303.

Весьма интересна процедура создания тех. карт. Техкарты не создаются не в каком либо из текстовых редакторов, а проектируются пошагово с указанием всех необходимых ресурсров (персонал(кол-во, квалификация, стоимость часа и т.д.) инструмент, приспособления, материалы, место проведения, зоны, места доступа, и т.д.) для каждого шага в Eagle.

И только после этого сливаются либо в виде печатного документа (PDF), либо ИЭТР. И то и другое происходи налету из одной и той же базы данных.

тогда неплохо, особенно
если будет синхронизация
с PDM

По прогнозам интрефейсный модуль для стыковки с PDM системами будет в апреле.

Кроме этого, должен выйти процессный модуль. Для разработки таких процеесов, как, например, "Поиск и устранение неисправностей". Говорят выглядеть будет "а ля Визио".

Стреку, посмотреть бы, хотя бы одним глазом...
Если позволите, небольшое замечание: нет такого понятия как "неисправность" (см. дефект, отказ или повреждение), есть неисправное состояние...

Сильна Наталья ;) ВидноГОСТы читает. Тогда уж и дефект лучше к авиации "не приплетать" (не используем мы на практике это понятие...)

PS На практике - я имею ввиду в эксплуатации и при испытаниях, а на производстве, конечно, есть место и дефекту ;)

2Наталья:

По поводу неисправностей. Абсолютно не имею желания спорить на эту тему.

Мне хоть ГОСТ 18675 и не нравится, но ...

.....
3.1.13.2. Тема 'Отыскание и устранение неисправностей' должна начинаться с перечисления наиболее часто встречающихся неисправностей в порядке вероятности их появления, а также включать работы, которые необходимо выполнить при отклонении от тактико-технических (ТТ) характеристик и других данных, проверяемых по каждому пункту технологических карт.

При наличии нескольких операций, необходимых для отыскания и устранения неисправностей, текстовая часть должна быть дополнена соответствующими схемами, определяющими объем и последовательность этих операций. Операции по отысканию и устранению неисправностей могут излагаться в табличной форме и должны бытьуразделены на три основные группы:

возможные причины - первым пунктом должно быть указание
о том, какая из составных частей системы может быть неисправной, причины перечисляют под описанием каждой неисправности в порядке вероятности их появления, после чего указывают осо бенности изделий, которые могут служить причиной неисправности;

установление неисправного элемента - под этим заголовком перечисляют указания, необходимые для установления неисправности внутри подсистемы или изделия;

устранение неисправностей- под этим заголовком перечислены указания по устранению неисправностей в изделии.

Допускается работы по устранению неисправностей оформлять в виде технологических карт (по форме 7) и помещать в тему 'Технология обслуживания', при этом на стр. 101-200 необходимо делать ссылки на соответствующие технологические карты.

.....

Наталья, я помню наши лингвистические споры, поэтому давайте не будем усугублять.

Что касается посмотреть. С этим проблем нет. В середине апреля можете приехать и посмотреть как это работает. К этому моменту у нас в этом ПО будет готова часть силовой установки Бе-200.

Стреку.
Что касается "приехать в апреле" звучит более, чем заманчиво. К моему большому сожалению, у меня совсем нет времени, но ДЬЯВОЛЬСКИ хочется посмотреть, завидую ... будем думать!
Что касается лингвинистически споров, это Ваши проблемы... не совсем умные люди пишут ГОСТы, которые потом приходится читать... и исполнять.

Наталья, страшно жить!!!
Страшно от того, что столько кругом "не совсем умных людей", начиная от составителей толковых словарей:


Толковый словарь русского языка

НЕИСПРАВНЫЙ, ая, ое; вен, вна.
1. Имеющий повреждения. Н. механизм.
2. Небрежный, неаккуратный, неисполнительный. Н. поставщик.
| сущ. неисправность, и, ж. (к 1 знач.).

--

до ...
Тссс! страшно даже подумать авторов ПРАПИ

-------
ПРАПИ 98

3.4.4. Председатель комиссии но расследованию авиационного инцидента может дать разрешение на замену отказавшего агрегата (детали) п ввод в соответствии с НТЭРАТ ГА воздушного судна в
строп в установленном порядке до прибытия представителен про мышленности, ремонтной организации п владельца воздушного суд на в случае, если в ходе расследования бесспорно установлено, что
причиной авиационного инцидента является отказ (НЕИСПРАВНОСТЬ) авиационной техники, который может быть устранен заменой отказавшего агрегата (детали). .....




А уж НТЭРАТ ГА 93 иначе как диверсией против российского авиапрома и не назовешь!!! Причем в особо циничной и извращенной форме. Аж 110 упоминаний про неисправности!!!

....
- сбор, учет и обработка данных о выявленных
в полете и на земле отказах и неисправностях ави-
ационной техники;
....
- на судне выполнено очередное ТО, предусмо-
тренное регламентом, устранены неисправности
и их последствия;
.....
4.2.2. О неисправностях, выявленных при приемке
ВС, подготовленного к выполнению полета (полет-
ного задания), а также в иных случаях приемки ВС
экипажем, члены экипажа записывают в бортовом.
.....
В случаях задержки рейса по неисправности AT
оформляют документы в установленном авиапред-
приятием порядке.
....
4.2.7. В типовом случае о неисправностях, выявлен-
ных в полете, их характере экипаж (пилот) с бор-
та ВС сообщает диспетчеру службы движения
(ПДСП, ЦДА) аэропорта посадки для срочной пере-
дачи в ИАС, где в данном случае заблаговременно
готовят специалистов для устранения неисправно-
стей, а также запасные части и оборудование.
.....
При этом исправные и неисправные изделия должны храниться раздельно.

И т.д. примерно 100 упоминаний.
---



Но это цветочки, а вот ягодки ...
---
ФЕДЕРАЛЬНАЯ АВИАЦИОННАЯ СЛУЖБА РОССИИ
ПРИКАЗ
26 июня 1997 года № 134
г. Москва

О МЕРАХ ПО СОВЕРШЕНСТВОВАНИЮ СИСТЕМЫ КОНТРОЛЯ ЗА СОХРАНЕНИЕМ ЛЕТНОЙ ГОДНОСТИ ВС НА ОСНОВЕ ДАННЫХ ОБ ОТКАЗАХ, НЕИСПРАВНОСТЯХ АВИАТЕХНИКИ И НАРУШЕНИЯХ ПРАВИЛ ЕЕ ЭКСПЛУАТАЦИИ

В целях повышения уровня контроля за сохранением летной годности воздушных судов (ВС) на основе данных об отказах, НЕИСПРАВНОСТЯХ авиатехники (AT) и нарушениях правил ее эксплуатации в соответствии с п.п. 4, 5, 8 ст. 37 Воздушного кодекса Российской Федерации и во исполнение постановления коллегии ФАС России от 19.11.96 N 2 "О неотложных мерах по повышению безопасности полетов в гражданской авиации" в части централизованного сбора и обобщения записей бортовых регистраторов с информацией об отказах, НЕИСПРАВНОСТЯХ авиационной техники и нарушениях правил ее эксплуатации

---

И в завершение.

---------
ВОЗДУШНЫЙ КОДЕКС

Статья 50. Полеты над населенными пунктами

Полеты воздушных судов над населенными пунктами могут совершаться лишь на высоте, дающей возможность в случае НЕИСПРАВНОСТИ воздушного судна произвести посадку за пределами этих пунктов или на ближайшем аэродроме.



Все, баста карапузики. Доигрались. Занавес.

А насчет посмотреть ПО, думайте. Мы готовы все показать.

2Ученый:
....PS На практике - я имею ввиду в эксплуатации и при испытаниях, а на производстве, конечно, есть место и дефекту ;) ....

А "Дефектная ведомость" ?

Strek
ВБ, "Дефектная ведомость" как и "Поиск и устранение неисправностей" это очевидный привычный жаргон. По сути отказ - это нарушение работоспособности, а дефект - это любое физическое нарушение (отклонение от нормы), которое может привести к отказу, а может и нет. А ГОСТы конечно править надо, только "сил нет"...

/// Дефектная ведомость" как и "Поиск и устранение неисправностей" это очевидный привычный жаргон.

Не согласен. Это не жаргон, а сложившиеся, официальные названия документов и разделов документов. Жаргон это несколько другое.

Насколько корректно используются указанные выше термины? А смотря с чем сравнивать, и от чего плясать.

Кстати, использование жаргона в последнем предложении видно не вооруженным взглядом, чего не скажешь о "неисправности".

Допустим:
(1) "Поиск и устранение неисправных состояний"
(2) "Поиск и устранение отказов"
(3) "Поиск и устранение неисправностей"

Вариант (1) некорректен, поскольку неисправное состояние это "'состояние, статус" изделия, уже имеющее место быть. "Неисправное состояние" характеризуется либо явными, либо косвенными признаками.

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

Так что, вариант (2) имеет такое же право на существование, как вариант (3). Термины "отказ" и "неисправность" являются синонимами. И в данном случае, если нормативно закреплен термин "Неисправность", то его и необходимо использовать. В английском языке есть такое понятие - "consistency". Одно из значений этого слова - "согласованность".

Это означает, однажды "договорившись" о терминах, следует придерживаться того, чтобы всегда и везде придерживаться таких правил, как:

1) Не меняйте принятое значение слова;
2) Не используйте одни и те же слова для выражения различных значений;
3) Слово должно быть употреблено в одном значении на протяжении всей проектной документации;
4) Не применяйте для одного и того же понятия или названия различные технические термины.

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

К вопросу о "неумных людях" пишущих стандарты. Стандарты в советское время, да и сейчас перед официальным вводом в действие неоднократно рассылаются по заинтересованным предприятиям. Так что тезис о "учености" разработчиков прежде нужно адресовать к себе, а затем уж к остальным.

/// А ГОСТы конечно править надо, только "сил нет"...

Не будем о грустном :(

Для развития темы о терминах и стандартах, предлагаю дать определение:

А. Как называется абстрактный "пункт" регламента, имеющий соответствующую ТК?

B. Как назвать "перечень" работ, изложенный в ТК?

2Наталья:
Вот оно! Всякое начинание в России начинается со споров о понятиях и определениях... И этим, как правило, заканчивается. Иначе мы давным давно уже были бы впереди планеты всей. Эх, ну почему буржуины никогда не спорят о понятиях и определениях? Видать у них на первом плане бизнес... Вот гады! :)

Большой респект Strekу и всяческих успехов в этом начинании. Не отвлекайся на эти пустяки! :)

2 Strek:

Скажи лучше, специалист по ИЛС, какое есть определение термина "доработка"? Ряд глупых и неглупых документов (в т.ч. НТЭРАТ, АП-145) даёт разные указания как надо эти самые доработки делать (по бюллетеням и т.п.), но я нигде не нашёл исходного определения. Может я не там искал...

И ещё, в порядке обмена опытом, у вас сколько человек занимается ИЛС? Сколько человек, в частности, занимется конкретно эксплуатационно-ремонтной документацией (мануалы, каталоги и пр.), имею ввиду инженерный народ. И на сколько типов одновременно они работают? И как вы с запорожскими приводите документацию к одному формату - они сразу поставляют в "готовом виде", или вы переписываете в Эпике?

Вы хотели вопросы? :-) Их есть у нас однако.

Стреку.
1. Спорить нет смысла, посмотрите пожалуйста ГОСТ 27.002-89 НАДЕЖНОСТЬ В ТЕХНИКЕ. Основные определения. Термины и определения. Дата введения 01.07.90.
2. Простите за глупый вопрос, "будет готова ПО" на какой двигатель?
3. И все же надеюсь увидеть...

2В.П.Кучеров:

/// Скажи лучше, специалист по ИЛС, : ///

Я так понимаю, что "Специалист по ИЛП" сказано в уничижительном тоне.
Уважаемый В. П. Кучеров, нет в России специалистов по ИЛП. Есть более-менее самообразовывающиеся люди, и есть шарлатаны и проходимцы, ловящие рыбку в мутной воде.

Что касается соревнования в расшифровке терминов. Я задал вопрос про пункты регламента не случайно. Для сравнения:

MIL-HDBK-1908B DEFINITIONS OF HUMAN FACTORS TERMS

TASK ANALYSIS acq. A systematic method used to develop a time-oriented description of personnelequipment/software interactions brought about by an operator, controller or maintainer in
accomplishing a unit of work with a system or item of equipment. It shows the sequential and
simultaneous manual and intellectual activities of personnel operating, maintaining or controlling
equipment, in addition to sequential operation of the equipment. It is a part of system engineering analysis where system engineering is required. The following taxonomy is used to inventory or analyze
tasks, with mission and scenario conditions stated by the procuring activity and the remaining levels
dependent on the current phase of system development and purpose (e.g., gross analysis of tasks,
analysis of critical tasks) for which the analysis is being conducted:

MISSION. What the system is supposed to accomplish, e.g., combat reconnaissance.

SCENARIO/CONDITIONS, Categories of factors or constraints under which the system will be expected
to operate and be maintained, e.g., day/night, all weather, all terrain operation.

FUNCTION. A broad category of activity performed by a system, e.g., transportation.

JOB. The combination of all human performance required for operation and maintenance of one
personnel position in a system, e.g., driver.

DUTY. A set of operationally-related tasks within a given job, e.g., driving, weapon servicing,
communicating, target detection, self protection, operator maintenance.

TASK. A composite of related activities (perceptions, decisions, and responses) performed for an
immediate purpose, written in operator/maintainer language, e.g., change a tire.

SUBTASK. An activity (perceptions, decisions and responses) which fulfills a portion of the
immediate purpose within the task, e.g., remove lug nuts.

TASK ELEMENT. The smallest logically and reasonably definable unit of behavior required in
completing a task or subtask, e.g., apply counterclockwise torque to the lug nuts with a lug wrench."

TASK ELEMENT acq. See "Task analysis."

TASK INVENTORY gen. A comprehensive listing of all tasks performed by system personnel.

TASK STATEMENT gen. A task statement is a description of a task. It is composed of three basic
elements: (1) an action verb which states what is to be accomplished in the task, (2) an object which
identifies what is to be acted upon in the task, and (3) any qualifying phrases needed to distinguish the
task from related or similar activities, limit and define the scope of the task, and clearly communicate
the nature of the task. The third element is often added only when needed for clarification.
---

Кстати, реально "ощутить" приведенные выше термины можно в том ПО, которое мы сейчас тестируем.
В ILog есть такой программный модуль, который так и называется " TASK ANALYSIS " :)

И с его помощью действительно можно заниматься анализом задач ТО.



/// И ещё, в порядке обмена опытом, у вас сколько человек занимается ИЛС?

Интересный вопрос. Здесь уместно вспомнить фразу: "Это что-то новое, или мы эти уже давно занимаемся?"

Если иметь ввиду, что в ИЛП входят такие дисциплины, как:

- Эксплуатационная и ремонтная технологичность;
- Надежность;
- Контролепригодность;
- Наземное оборудование;
- Эксплуатационная документация;
- Обучение;
- Инфраструктура;
:. И т.д.
Вплоть до утилизации

С учетом вышесказанного можно сказать, что в общей сложности вопросами ИЛП занимаются примерно 70 человек.

////Сколько человек, в частности, занимется конкретно эксплуатационно-ремонтной документацией (мануалы, каталоги и пр.), имею ввиду инженерный народ. И на сколько типов одновременно они работают? И как вы с запорожскими приводите документацию к одному формату - они сразу поставляют в "готовом виде", или вы переписываете в Эпике?
Вы хотели вопросы? :-) Их есть у нас однако:////

Документаций занимаются примерно человек 40 по всем темам.
Периодически случаются к нам экскурсии коллег из остатков авиапрома. В этом направлении есть чем похвастаться, например, как ни странно, РЛЭ Су-30МКИ для индийских ВВС.

Про технологию. Что касается общения с поставщиками комплектующих и двигателистами в частности. Документацию поставщиков готовых изделий мы не переписываем. Вместо этого, более продуктивным является согласованный механизм разработки ЭД в рамках одного проекта. Такую технологию мы пытаемся запустить для некоторых проектов. Мы разработали документ "План управления техническими публикациями". Это примерно 200 страничный документ, в котором изложены абсолютно все аспекты ЖЦ технических публикаций. Такие "Планы" в скором времени будут согласованы в том числе и с поставщиками Д-436ТП и ПС-90А-76.

Самая главная наша проблема, я имею ввиду не ТАНТК, а промышленность в целом заключается в том, что у нас отсутствуют стандарты типа ASD 1000D, ASD 2000M. Отсутствие таких стандартов (а еще лучше не изобретение колеса, а прямое их использование) делает весьма затруднительным интеграцию между участниками проекта.

Про инструмент. Мы не работаем в Эпике. В настоящее время мы для ЭД используем FM. Причины я думаю объяснять не надо. В принципе, выбор инструмента личное дело каждого поставщика. И я не думаю, что мы имеем право в чем-то их ограничивать или диктовать, в чем им работать.

В рамках ПО iLog вообще не имеет значения, какой используется SGML редактор.


2Наталья:

1. Спорить нет смысла, посмотрите пожалуйста ГОСТ 27.002-89 НАДЕЖНОСТЬ В ТЕХНИКЕ. Основные определения. Термины и определения. Дата введения 01.07.90.

Естественно не стоит спорить :) Бесполезно и непродуктивно. Вы даете ссылку на один ГОСТ, я привел десятки противоположных примеров. Это лишний раз доказывает, что "consistency" в советской (российской) нормотворческой традиции не является чем-то обязательным.

А кривость советской системы стандартизации лучше всего ощущается после посещения следующих сайтов:

www.ams.mod.uk
www.dstan.mod.uk
http://assist.daps.dla.mil (на этом сайте тонны американских стандартов, требуется регистрация)

2. ///// Простите за глупый вопрос, "будет готова ПО" на какой двигатель?

Наталья, если уж цитируете, то желательно делать это более корректно:

: К этому моменту у нас в этом ПО будет готова часть силовой установки Бе-200:.

Двигатель соотвественно Д-436ТП.


3. Это зависит только от Вас. :)

Наталья, думаю что приведенная ниже информация, поможет вам решиться на визит к нам :)

Это перечень программных модулей (дисциплин) входящих в EAGLE.

EAGLET Disciplines

EAGLE is organized into task-specific 'disciplines, ' or modules, for optimal information
management. This document outlines the disciplines incorporated in EAGLE, and their
functions. It shows how EAGLE users can meet a broad spectrum of needs through one
integrated, growth-oriented solution.

AdHoc - AdHoc allows users to access the complete EAGLE database to define and
generate unique reports for ad hoc needs. For example, in the military arena, this
discipline could determine the configuration of a fleet of aircraft by serial number.
AdHoc's user-friendly screens enable you to produce such reports quickly and efficiently.
To begin using this discipline, no prior experience with spreadsheets is necessary.

LCN Maintenance - LCN Maintenance is the starting point for establishing a logistics
database. It creates the foundation tables, and key data elements such as end item,
logistics control number (LCN), and CAGE code.

Breakdown Structure - This discipline shows the LCN structure of an end item
hierarchically, in a graphical format. Users see the complete system -- for example, all the
component parts of a vehicle -- broken down by LCN or part application. They can then
move the parts or LCNs around within the structure. Breakdown Structure can be
particularly helpful in documenting an item's structure during its design or modification
phase.

Provisioning - The more data that provisioners have, the more effective they can be, and
EAGLE's Provisioning discipline provides access to vast amounts of information. In addition,
the data can be sorted in numerous ways. For example, users can select a part number and
obtain a summary of all corresponding part information. Users can expand and manipulate
the data, as needed, to allow very specific searches. To navigate this discipline, you simply
select the appropriate tab and click.

ICAPS (Interactive Computer-Aided Provisioning System) - As information is entered into
the database, ICAPS automatically translates the data into the appropriate format. In the
military arena, this means that even users unfamiliar with the required LSAR format can
correctly enter data. Commercial users may also find this format effective.

Support Equipment - This discipline tracks support, test, and training equipment data
and identifies the hardware and software required for off-line tests. In addition, it
automatically generates standard military reports such as LSA-070 and FORMS 9 and 603.

Task Analysis - Designed for managing complex systems, this discipline tracks task
analysis, personnel, and support equipment documentation and provides users with
speedy access to all applicable maintenance data. Skills, tools, facilities, and other
requirements are presented in detail. In addition, logistics tasks can be linked to fullmotion
video to demonstrate the steps involved in a task.

Technical Manual - What would you do if a client requested a customized, 250-page
technical manual and had to have it the same day? Using EAGLE's Technical Manual
discipline, you could accomplish the task at the touch of a button. You specify the manual
required, and Technical Manual uses information stored in the database to automatically
generate a new or previously stored technical manual.

Reliability, Availability, and Maintainability (RAM) Data Finder - This discipline
tracks an item's RAM data. It also describes the function of each component of an end
item, and outlines the maintenance concept to be used for design and support planning.
When potential redesign of an item is analyzed, users can add narrative comments on the
analysis.

Facilities - The Facilities discipline tracks data that describes and justifies proposed
facilities, and modifications to existing facilities. It also produces reports based on this
data.

Operations Maintenance - This discipline tracks data regarding an end item's
anticipated operation, its maintenance environment, and the corresponding maintenance
requirements.

Personnel Skills - The Personnel Skills discipline tracks descriptions and justifications of
new or modified personnel skills required for end item support.

Transportation - This discipline tracks engineering analysis data pertaining to end item
transportation, such as shipping methods and environmental considerations.

Reports - EAGLE offers the 48 military standard reports, and virtually unlimited customreport
capability. Using the Reports discipline, users can easily generate the desired report
from any EAGLE location. Simply select the type of report required, and Reports will guide
you through its creation, enabling you to narrow the scope of the report, as needed.

Depot Management - From tracking a major fleet of vehicles to managing warranty
records for an extensive line of products, this discipline can meet your most demanding
maintenance requirements. In the military arena, Depot Management can track the
maintenance records of every missile and missile part, and every upgrade to each part. For
commercial users, it provides a powerful solution for tracking contracts, inventory, and
related information.

FRACAS (Failure Reporting Analysis and Corrective Action System) - Based on MIL-STD-
2155, FRACAS enables users to track a failure through its life cycle to determine the root
cause. It also links the failure data to EAGLE's LSAR relational database for reporting mean
time between failures. FRACAS uses LSAR as the starting point for failure analysis.

Engineering Failure System - The Engineering Failure System tracks and analyzes
engineering failures and defects during the equipment manufacturing process. Users can
also link a failure to the process during which it occurred. With its built-in problem solving
approach, this discipline saves time and money and can stop critical failures from recurring.

Graphics - Graphics stores, maintains, and provides quick access to technical drawings and
artwork. This material can be stored in a variety of formats, and easily retrieved for display
at conferences or meetings. While displaying a design, users can add markups and labels as
an overlay and print the results without changing the original drawing.

Administration - Administration gives you the power and flexibility to customize the
EAGLE disciplines to your specific needs. For example, when you decide which disciplines
you want to use, you can set up your menu accordingly (and even add third-party
software). You can also specify colors and defaults, and opt to import or export LSAR fullfile
or change-only data.

LSA Management - This discipline allows you to track engineering changes and exercise
configuration control within the LSAR database. It stores packaging, item identification,
part application, and reliability information. It also offers additional storage capacity for
data such as validation and product life expectancy information, and customer
requirements, comments, and responses.

Spares Modeling - This discipline is used to add spares modeling information to the
EAGLE database. It identifies the spares and support equipment needed for customer
support, and their potential cost. It also provides a model for calculating resource
requirements recommendations.

Spares Order System - The Spares Order System enables users to create and maintain
contractual, part, and line item information pertaining to spares. It generates the Spares
Release Schedule and Spares Shipping Order.

Бесплатная раздача слонов.

Если кому нужна презентация "Что такое ИЛП" (Power Point, 125 стр., англ. язык) телеграфируйте.

>> Я так понимаю, что "Специалист по ИЛП" сказано в уничижительном тоне.

Неправильно понимаете. Нет, нет и нет. Это без приколов. Есть кто-то кто прошёл дальше других в этом размытом деле ИЛП, и это имхо вы. Если вдруг у нас случится новый прожект, то предстоит учиться. Но это если, не переделывать же, в натуре, старую добрую документацию, хоть она и кривовата, хоть и издана на папирусе. ИЛП как вид деятельности непосредственно Вашим покорным слугой сейчас не востребован.

Я понимаю что в понятие ИЛП входят "ремонтная технологичность", "надёжность" и т.п., но моё консервативное мнение как старого совка, измученного Нарзаном, что эти качества обеспечиваются не специальными людьми по ИЛП, а непосредственно теми конструкторами, которые собственно конструируют изделие. Так же как "качество производства" обеспечивается не отделом качества завода, а теми людьми, которые непосредственно производят продукт. Мой вопрос заключался в том, какое у вас количество выделенных людей, занимающихся ИЛП как основной работой. Есть же "менеджеры по ИЛП"? Или как? Вот в таком смысле. Позволю себе повторить вопрос, т.к. я видимо невнятно его задал. 70 человек - это включая людей, которые вообще-то занимаются другой работой, но ещё и думают об ИЛП, или это специальные люди?

40 человек, делающих документацию. М-м-м-м, немало. Но и не много. Имхо. Не знаю. Это, позвольте уточниться, включает shop manual? Позвольте поделиться мыслью, хотелось бы понять ваше мнение с высоты пройденного пути: я считаю, что базой для всей ИЛП является эксплуатационно-ремонтная техническая документация (или публикации, как ни назови), а всё остальное - планирование запчастей, учёба, наземная база, пр, пр, пр опирается на документацию. Как вы считаете?

О! Т.е. поставщики ПКИ сразу поставляют документацию в готовом виде! Это архиважно имхо. Потому что прежде всего, их (поставщиков) много. Хорошо если вы достигнете этой цели. Простите за серость, что такое стандарты ASD 1000D, ASD 2000M, и где их можно посмотреть? И, э-э-э, 200 страниц - не слишком ли это много чтобы поставщики смогли прочитать и понять столь объёмный том? (Я опять не прикалываюсь, имхо есть такая серьёзная проблема - непонимание документов из-за их громоздкости).

Про инструмент. Согласен, что это вопрос вторичный, но попробовамши потыкать FM и ЕЕ, я бы (лично) предпочёл ЕЕ. Это моё имхо как старого неадекватного совка. Хотя возможно IT люди имеют другое мнение.

/// Но это если, не переделывать же, в натуре, старую добрую документацию, хоть она и кривовата, хоть и издана на папирусе. ИЛП как вид деятельности непосредственно Вашим покорным слугой сейчас не востребован.////

Совершенно верно. Классически смысле ИЛП начинается в начале проекта. Однако, есть такое понятие как "Ограниченный ИЛП". Это означает, что можно решать некоторые задачи ИЛП (по отдельным дисциплинам) в проектах уже находящихся на стадии эксплуаатции.

/////Я понимаю что в понятие ИЛП входят "ремонтная технологичность", "надёжность" и т.п., но моё консервативное мнение как старого совка, измученного Нарзаном, что эти качества обеспечиваются не специальными людьми по ИЛП, а непосредственно теми конструкторами, которые собственно конструируют изделие.////

Естественно, это инженерные задачи для специально обученных людей. Мы вероятно последняя контора, которая обзавелась словом "ИЛП" в официальном названии службы.

Менеджеров по ИЛП, в отличие от других контор у нас нет, пока. Есть начальники отделов, занимающиеся своей непосредственной работой и координирующие свою деятельность со всеми заинтересованными структурами.

Но необходимость в таком менеджере есть. Этот человек должен заниматься координацией работ по всем дисциплинам и увязывать все вопросы ИЛП в рамках конкретного проекта.

Есть несколько ведущих инженеров (3) по ИЛП (официально), которые усиленно раскапывают тему. В принципе мы идем эволюционным путем. Сначала надо разобраться с предметом, а потом проводить структурные преобоазования.

/// 40 человек, делающих документацию. М-м-м-м, немало. Но и не много. Имхо. Не знаю. Это, позвольте уточниться, включает shop manual?////

Да. Включает. Много или мало? Это завист от количества пректов, требований к ЭД в каждом проекте, степени автоматизации. В настоящее время этих людей не хватает.


/////Позвольте поделиться мыслью, хотелось бы понять ваше мнение с высоты пройденного пути: я считаю, что базой для всей ИЛП является эксплуатационно-ремонтная техническая документация (или публикации, как ни назови), а всё остальное - планирование запчастей, учёба, наземная база, пр, пр, пр опирается на документацию. Как вы считаете?////

не буду умничать, процитурую первоисточник:

----
DEF STAN 00-60

PART 0: APPLICATION OF INTEGRATED LOGISTIC SUPPORT(ILS)
SECTION ONE. GENERAL
0 INTRODUCTION

0.1 Стоимость эксплуатации изделий обычно равна или превышает стоимость его приобретения. Эта стоимость является важнейшим фактором при принятии решения о приобретении и, следовательно, имеется необходимость в управлении ею установленными способами. Интегрированная Логистическая Поддержка (ИЛП) - это управление стоимостью, путем учета влияния требований поддерживаемости на процесс проектирования, включая эксплуатационную технологичность и выбор оборудования, а также развертывания и мониторинга необходимой системы поддержки эксплуатации. Ключевыми факторами стоимости поддержки являются надежность и обслуживаемость (эксплуатационная технологичность) изделий и оборудования.
------

В основе ИЛП лежит надежность и эксплуатационная технологичность. Инструкции по поддержанию летной годности (ЭД) и есть ЭД, и ничего более.

Краеугольным камнем ИЛП являтся документ под названием "MaintenancePlan". Вероятно российским аналогом могла бы быть "Программа ТОиР". Но обычно это документ погибает как только появляется ЭД и особенно РО.

Но в случае с прменением "ограниченного ИЛП" документация является той базой, с которой можно начинать процесс. Другого ведь ничего нет.

/// О! Т.е. поставщики ПКИ сразу поставляют документацию в готовом виде!////

Они и поставляют в готовм виде. Вы вероятно имеет ввиду в каком формате?

///Это архиважно имхо. Потому что прежде всего, их (поставщиков) много. Хорошо если вы достигнете этой цели.///

Вот тут и кроется самая большая проблема. Работа с поставщиками и их контроль.

////Простите за серость, что такое стандарты ASD 1000D, ASD 2000M, и где их можно посмотреть?///

Это бывшие стандарты AECMA. 1000D можно скачать с wwww.s1000d.org

///И, э-э-э, 200 страниц - не слишком ли это много чтобы поставщики смогли прочитать и понять столь объёмный том? (Я опять не прикалываюсь, имхо есть такая серьёзная проблема - непонимание документов из-за их громоздкости).///

В настоящее время в этот документ включены материалы, которые впоследствии будут размещаться в отдельных документированных процедурах.

///Про инструмент. Согласен, что это вопрос вторичный, но попробовамши потыкать FM и ЕЕ, я бы (лично) предпочёл ЕЕ. Это моё имхо как старого неадекватного совка. Хотя возможно IT люди имеют другое мнение.///

Я думаю, что если мы купим iLog, то мы перейдем на EPIC. Как Вы знаете FM самодостаточен. Для того, что выпускать ЭД в Epic необходимы дополнительные инструменты. В случае же с iLog нам нужен простой SGML редактор, поскольку функции форматиорвания, печати решают модули iLog.

Ну, не соглашусь, не везде есть слово ИЛП в штатном расписании. У нас нет. А вот, ещё интересно, у вас "служба ИЛП" входит в какую епархию - конструкторскую или коммерческую или другую какую?

Я вообще не представляю как могут начальники разных отделов сами координировать между собой работу. Из моей практики, стадо не может само идти в одну сторону - нужен некий пастух, т.е., человек (или отдел), который задаёт идеологию и направление процесса. Тогда все пойдут в одну сторону, в противном случае - в разные.

Я тоже думаю что у нас (ничтожных поставщиков мелких комплектующих в авантюре по имени RRJ) процесс надо будет начинать эволюционно. Конструкция сейчас в основном определена (т.е. рабочая КД выпущена, но, как обычно, она не догма и будет ещё не раз перекраиваться). Я вижу очередную задачу в направлении ИЛП - в разработке публикаций. Но под это решительно не хватает ресурсов, в первую очередь людских.
Для сравнения, у нас старый тип двигателя ведёт отдел (точнее два отдела - эксплуататоры отдельно, ремонтники отдельно) общей численностью человек 20, и они зашиваются. В значительной степени это обусловлено кривизной документации, кривизной нормативной базы и грузом прошлых лет, автоматизация мягко говоря, желает лучшего. Ну, и кадровая проблема в наши дни - это суперпроблема отрасли.

Maintenance plan - это то, с чего мы будем начинать когда сможем выделить отдельного хотя бы одного человека. По старым типам у нас есть практика составления таких планов (в основном относится к shop ремонту) каждый год. Из них реализуется процентов 20-50, в общем, есть прогресс и все более-менее довольны.

По прожекту имени тов.Бухого план скорее всего не будет догмой на века, но по мере реализации будет прорастать вглубь и вширь. Так мне кажется было бы правильно, но не знаю как будет в реале.

Про поставщиков я имею ввиду прежде всего формат, чтобы можно было сделать операцию copy-paste, и раздел в ЭД готов. Вообще, я пока просто не представляю как строить с ними работу, впрочем для нас это не столь актуально. Более актуально shop manual - вот где я усматриваю самый большой объём (учитывая специфику изделия - двигатель).

А вот ещё такой вопрос - как вы по гражданской теме урегулируете отношения с военпредами в обоих их ипостасях - как военных предов и как предов мака? Наш, например, говорит типа мне команды не поступало, ничего не вижу, ничего не слышу. Или уй с ним, с зелёным, не приставать к нему? Он вообще пригодится дальше или нет?

2В.П.Кучеров:

Я понимаю что в понятие ИЛП входят "ремонтная технологичность", "надёжность" и т.п., но моё консервативное мнение как старого совка, измученного Нарзаном, что эти качества обеспечиваются не специальными людьми по ИЛП, а непосредственно теми конструкторами, которые собственно конструируют изделие. Так же как "качество производства"

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

/////Ну, не соглашусь, не везде есть слово ИЛП в штатном расписании. У нас нет. А вот, ещё интересно, у вас "служба ИЛП" входит в какую епархию - конструкторскую или коммерческую или другую какую?////

Ну значит, тогда лавры Вам достанутся :)

Служба эксплуатации и ИЛП эволюционирует по направлению к отдельной "епархии", тесно взаимодействующей с конструкторскими и коммерческими структурами.

////Я тоже думаю что у нас (ничтожных поставщиков мелких комплектующих в авантюре по имени RRJ) процесс надо будет начинать эволюционно.////

Без комментариев : )

В подверждении слов Юры, рекомендую почитать
MIL-HDBK-502 ACQUISITION LOGISTICS

А какой двигатель Вы представляете? :)

///А вот ещё такой вопрос - как вы по гражданской теме урегулируете отношения с военпредами в обоих их ипостасях - как военных предов и как предов мака? Наш, например, говорит типа мне команды не поступало, ничего не вижу, ничего не слышу. Или уй с ним, с зелёным, не приставать к нему?

Нам "независимой инспекций" :) можно сказать повезло. нормальные, понимающие люди. Особых проблем не наблюдается.

....Он вообще пригодится дальше или нет?///

Он, это кто?

Валер, речь идет об военпреде. Зеленом...:) То бишь цвета хаки...

///Про поставщиков я имею ввиду прежде всего формат, чтобы можно было сделать операцию copy-paste, и раздел в ЭД готов. Вообще, я пока просто не представляю как строить с ними работу, впрочем для нас это не столь актуально. Более актуально shop manual - вот где я усматриваю самый большой объём (учитывая специфику изделия - двигатель).///

Соpy-paste - порочный путь. Да и тому же зачем это делать. Это дублирование информации. Каждый делает свою часть. Или я чего-то не понял? Зачем копировать информацию из документов вендора в свою?

/// Валер, речь идет об военпреде. Зеленом...:) То бишь цвета хаки...

Дык я говорю, нет проблем с независимой инспекцией :)

Я непосредственно работаю с семейством Д-30КУ/КП, главным образом - ремонт, поэтому я искушён скорее в копании на свалке среди старого металлолома нежели в современных технологиях.

Поэтому позвольте вопрос (2 Yuha): о цифровых показателях. Я ежегодно подбиваю фактическую цифру по показателям надёжности Д-30КУ - наработку на отказ, на досрочный съём и т.д. (Это в точности как средняя температура по больнице). Иногда я инициирую конструкторские доработки по тем или иным причинам. (хотя не всегда конструктор со мной соглашается, иногда он говорит иди типа, не утомляй меня, тогда я иду т.к. считаю что он умнее меня). Кстати, я ни разу не инициировал доработки именно из-за того, что мне не нравятся показатели надёжности - причины были либо появление нового дефекта, либо необходимость увеличить ресурс детали, либо улучшить ремонтопригодность узла.

Теперь передо мной лежит чертёж на новый двигатель, который не является ни модификацией, ни развитием старого. Какая у него будет наработка на отказ? Откуда я это узнаю? Конструктор говорит что надёжность у этого двигателя будет зашЪбись, и если я его припру к стенке, то даже может быть назовёт цифры, но как я могу ему поверить? Как могу его проверить? Имхо надёжность может показать только жизнь.

Или, допустим, я задал конструктору условие чтобы наработка на выключение в полёте была такая-то, а наработка на shop visit такая-то. Как он это учтёт в чертеже? Я не понимаю.

То же насчёт эксплуатационной технологичности и ремонтопригодности. Какой тут показатель - время на обслуживание двигателя по регламенту? Его можно достигать разными средствами. В одном случае я напишу (например), вынь фильтр, осмотри его, промой и вставь обратно. Если надо сократить время, то я напишу вынь фильтр, выкинь его и вставь новый, но, хе-хе, это же вредительство, правильно? Хотя показатель эксплуатационной технологичности будет лучше. Аналогично я могу отремонтировать турбинную лопатку, а могу заменить новой.

Это я к тому, что цифровые показатели, про которые сейчас трындят на каждом углу - это не от большого ума. Предполагаю что это тупое копирование какого-то модного иноземного стандарта. Ко мне в том году припёрся аудитор и сказал чтобы я измерял свою деятельность в цифровых показателях, и чтобы повесил на стенку план по повышению цифрового показателя. Я ему говорю, в каких амперах будем мерять? А он говорит чтобы я типа сам придумал. Я, конечно, послал его куда надо. Завтра скажут что надо измерять демократию в Бушах-младших (Буш-младший составляет 1/10 от Буша-старшего), и все пойдут измерять.

Или я чего-то не понимаю в этой жизни.

А вот нецифровые требования я конструктору как раз формулирую. Я требую от него чтобы можно было поменять лопатку не снимая двигатель в shop, подбалансировать ротор, и т.п.

Я и не говорю что ЭД - это есть ИЛП. Я думаю (но не уверен), что ИЛП должна быть построена на базе ЭД. Например, я включаю в ЭД технологию замены лопатки, в этой технологии указан инструмент который необходим для выполнения работы, инструмент надо тоже сделать и опробовать. Тогда ок, я могу включить этот инструмент и расходники в ведомость поставляемого эксплуатанту имущества. Т.е. развиваю ИЛП на базе разработанной ЭД, правильно?

Кстати, опять о птичках (т.е. о цифровых показателях): как мой менеджер по ИЛП спланирует частоту попадания птиц в двигатель? Сколько он должен заложить запасных лопаток в расчёте на 1000 часов наработки? Имхо когда жизнь покажет, тогда и уточнюсь. А для начала возьму с потолка.

А, прорвёмся как-нибудь. Как говорит одна моя подруга, была бы курочка - сготовит и дурочка. Было бы изделие, сделаем ему суперинтегрированную мегалогистическую сверхподдержку. Нету курочки - вот в чём проблема.

>> Зачем копировать информацию из документов вендора в свою?

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

>> нет проблем с независимой инспекцией

Завидую.

В.П.Кучеров:
Действительно, на кой хрен цифирь, ежели в этом нет нужды :) Цифирью начинают интересоваться, когда возникают проблески любви к будущему клиенту и желание завоевать рынок... Цифирь не самоцель, а инструмент совершенствования определенных свойств продукта. Если на клиента - накласть, то не нужна не только цифирь, но и бизнес, как таковой...
Если всетки есть нужда двигаться вперед то лучше, ИМХО, лучше ставить задачу в полном объеме, а не сразу прятаться за оговорками "эволюционно", "поэтапно"... Для того, чтобы желаемая эволюционность и этапность состоялась, нужно четко представлять себе ВЕСЬ ОБЪЕМ предстоящего...
"Если Вы не знаете, куда идете, именно туда Вы и прийдете" (с) Народная мудрость...

С уважением,

Юрий

Стреку, ну не хотите читать ГОСТ 'По Надежности', ради бога, не читайте...

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

Наталья, однажды некие умники "перевели" и "адаптировали" АТА-100, Результат - убожество в виде 18675- . Если не трудно, оставьте при себе лингвистические изыскания. Иногда, проще общаться на ломаном английском с западными специалистами, чем с доморощенными теоретиками.

2В.П.Кучеров:

Я бы не стал противопоставлять "цифра" vs "исскуство". И то и другое является частью одного процесса. В итоге все сводится к двум вещам:

- Готовность
- Стоимость

Вернее к балансу между готовностью и стоимостью.

А как влияет надежность и эксплуатационная (ремонтная) технологичность видно из следующих формул:

Теоретическая готовность - Аi=((MTBF/(MTBF+MTTR))*100%

Оперативная готовность - Ао=МТBM/(MTBM+MTD)

MTBF - средняя наработка на отказ
МТTR - среднее время ремонта
МТBM - среднее время между периодическим ТО
МТD - время простоя

Например, при 100% надежности (МТВF=бесконечность) или при MTTR=0 - готовность = 1. Это теория. А практика - это поиск компромисса между этими двумя крайними точками. Не всегда экономически выгодно добиваться более высоких показателей надежности.

При заданном в ТЗ показателе надежности (а это извините требования Заказчика=святое) уменьшение надежности должно компенсироваться улучшением эксплуатационной (ремонтной) технологичности. И наоборот, чем выше надежность, тем меньше затрат вы несете на обеспечение Э (Р) технологичности.

И именно по этой причине на ТАНТК отдел надежности и безопасности и отдел эксплуатационной технологичности и котролепригодности в ходят в состав одной службы. Службы эксплуатации и ИЛП.

Пример из жизни. Стоимость замены лопатки КНД на одном из российских двигателей, одному инозаказчику обходить более чем в 500 000 у.е.. а подобная процедура у того же заказчика не на российском самолете ~ 30 000 у.е.

Вот вам влияние технологичности на стоимость ремонта.


//// Кстати, опять о птичках (т.е. о цифровых показателях): как мой менеджер по ИЛП спланирует частоту попадания птиц в двигатель? Сколько он должен заложить запасных лопаток в расчёте на 1000 часов наработки? Имхо когда жизнь покажет, тогда и уточнюсь. А для начала возьму с потолка./////

А не надо ему планировать частоту попадания птиц. Это проблема эксплуатирующей организации.


E=FН*n*N*(1/MTBUR)*[(TAT/365)*(1-SR/1000)+SR/1000*((LT+АТ)/365)]

Где

E - расчетная потребность
FH - налет одного самолета в год, часов
n - количество рассматриваемых изделий на самолете
N - количество самолетов в рассматриваемый период
MTBUR - средняя наработка на досрочный съем
ТАТ - время оборота ремонтируемого изделия
SR - коэффициент отбраковки
АТ - административное время (оформление заказа, таможня и т.д.)

Прощу заметить, что в данном случае используется не средняя наработка на отказ (MTBF), а средняя наработка на досрочный съем (MTBUR). Вот тут Ваша псица и сидит.

Другими словами формула для расчета необходимого кол-ва запчастей состоит из трех частей:

1) общее кол-во рассматриваемых запчастей в его флоте
2) вероятность досрочного съема изделия
3) временные параметры, связанные с доставкой изделия

Но это чисто расчетное значение.

Далее нам необходимо определить рекомендованное количество запчастей

m=f(a, E)=a*sqrt(E)+E

где,

m - рекомендованное кол-во запчастей
E - см. выше

Считаем:

Е = 6
PL = 0.9 (90%) (Protection Level)
a = 1.282 (для PL=90%) (распределение Гаусса)

m=1, 282*sqrt(6)+6=9, 14

Рекомендуемое количество m=10

10 железяк Вам надо для определенного парка с определенным налетом. Это касается ремонтируемых изделий. В данном случае 10 двигателей.

Есть еще формулы для расчета расходуемых изделий. Основа везде одна и та же:

Парк, налет, вероятность досрочного съема. Отличия только во временной составляющей.


//// Я ежегодно подбиваю фактическую цифру по показателям надёжности Д-30КУ - наработку на отказ, на досрочный съём и т.д.////

Так что основа у Вас есть. А документация, если к ней подойти с научной точки зрения :) после проведения анализа может сильно поменяться, я имею ввиду технологию обслуживания. Особенно если Вы примените подходы RCM (Reliability Centered Maintenance). Обслуживание, основанное на надежности.

В авиации эта методология называется MSG-3. есть такой продукт МPC-3 (http://www.reliasoft.com/) Стоит 5000 USD. Тестовая версия у нас есть. Шайтан машина.

Кстати, встречный вопрос. Задаю всем. Как вы формируете и обосновываете РО?

Кстати, факт общеизвестный, может даже кто из присутствующих на форуме принимал участие. После проведения анализа ТО на Миг-29 доставшихся ФРГ после объединения с ГДР по MSG-3 стоимость ТО снизилась 30%.

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


В зависости от ваших взаимоотношений с вендором, требований конечного пользователя, в том числе и особенно если требуется ЭД на английском языке по модным стандартам, возможны два варианта:

1) Сознательный вендор.
Разрабатывает ЭД на свои изделия в том, виде, в каком от Вас требует конечный пользователь.
Вариант идеальный, но практически не реализуемый (в россии).
В данном случае Вы, если Ваша продукция двигатель, прикладывает в комплекте с ЭД на двигатель РЭ на готовые изделия и пожимаете друг другу руки с надеждой на дальнейшее плодотворное сотрудничество.


2) Вендор - редиска.
Это вендор говорит, что в гробу видел Вас вместе с вашим конечным пользователем. Т.е. он конечно может все сделать, но его спучиалисты стоят дороже адвокатов с Уолл-стрит.

В таком случае Вы растворяете его докуменатацию в своей самостоятельно.

На практике обычно у головного изготовителя применяются оба варианта.


Пример, ЭД самолета Бе-200 (РО, РЭ (ТК), РЛЭ, РЗЦ) стоят ~ 25 000 р.

А производители некторых комплектующих просят с нас, например, за ЭД на 3 радиостанции - 80 000 р.

2 Юрий

Вот именно в том-то и дело, что куда точно идти я как раз и не знаю. Вам это кажется странным? Для меня цель находится пока за горизонтом.

2 Наталья
>> Надеюсь, бить не будете?

Отчего же, больно и с удовольствием (шутка). Всё это хорошо и красиво, учебник умный, не спорю. Но. Москва не сразу строилась. Не могу и я построить ИЛП сразу. Утешает что я понимаю что я это понимаю.

2 Strek

Вот! Я хотел получить подтверждение предположению, и в значительной мере получил его - правильная система техобслуживания одними цифрами не просчитывается. Здесь есть вполне весомый элемент искусства и практических наработок.

Это предположение вытекает из моего опыта далёкой молодости, когда я работал не в промышленности, а в эксплуатации. Дело было давно, но отчётливо помню текущую работу - устранение дефектов в промежутках между рейсами. Т.е. время вылета написано в расписании, и будь добр к этому времени дефект устрани. В этой ситуации (нормальной жизненной по-моему) формула

Аi=((MTBF/(MTBF+MTTR))*100%

не катит. Потому что дополнительное время на устранение дефекта не расходуется, хотя гимор для авиатехника имеет место быть.

Далее, шопный ремонт двигателя может выполниться двумя способами. Немного утрирую, но принцип следующий:
1. Двигатель завозится в shop, разбирается, дефектируется, детали требующие ремонта ремонтируются, двигатель собирается и испытывается. Такой ремонт занимает 60-80 дней.
2. Двигатель завозится в shop, разбирается, дефектируется, взамен деталей требующих ремонта ставятся другие б/у детали из обменного фонда, двигатель собирается и испытывается. Такой ремонт занимает 30-40 дней.

Оба варианта - в соответствии с шоп-мануалом, но сделать можно по-разному. Это к вопросу о ремонтной технологичности.

В общем, товарищи, НЕ всё просчитывается. Но это меня пока не огорчает, если често. Была бы курочка.

>> Пример из жизни. Стоимость замены лопатки КНД на одном из российских двигателей, одному инозаказчику обходить более чем в 500 000 у.е.. а подобная процедура у того же заказчика не на российском самолете ~ 30 000 у.е.

Очень типичная жизненная ситуация. Здесь работает фактор жадности, который не учтён в формулах. Замена такой же лопатки на таком же российском двигателе, но не для инозаказчика, а для внутреннего заказчика будет стоить 10 000 у.е. Я угадал? Это не говорит о том, что замена лопатки не технологична - это говорит о том, что изготовитель двигателя жадный.

То же фактор относится к стоимости ТО на МИГ-29 - ранее объём регламентных работ был искусственно раздут, а периодичность сокращена. Я ничего удивительного в этом не вижу - работал либо фактор жадности, либо фактор зелёного человечка, имеющего свои чудачества (хоть он и заказчик).

Слово MSG-3-анализ я уже слышал, но пока не разобрался что это такое. Я так понимаю, что мне предстоит определяться с периодичностью регламента, но у меня пока нет соображений как это делать применительно к бумажному изделию. Почему регламент на Д-30КУ такой а не иной я не задумываюсь потому что так сложилось исторически, умные люди до меня сделали именно так, спасибо им за это. Я не знаю почему они назначали регламент именно так, а спросить - не спросишь т.к. иных уж нет, .

>> на ТАНТК отдел надежности и безопасности и отдел эксплуатационной технологичности и котролепригодности в ходят в состав одной службы. Службы эксплуатации и ИЛП

Во как! У нас надёжность относится к конструктору, технологичность как таковая отсутствует, как и ИЛП. Поддержка эксплуатации относится к коммерсантам. В общем, разрознено, и это плохо.

О вендорах: мне, к сожалению, пока попадались только второго типа. Это элемент культуры, как не бросать окурки на пол. У меня есть стойкое подозрение, что сознательных вендоров в бывш.СССР просто нет как класса. Ой, нет, знаю одного, который правильно работает - Самарский завод подшипников, но по подшипникам ЭД не бывает. Агрегатчики все поголовно на любые претензии говорят или "вина эксплуатации", или "дай бабла много и сразу", или просто "иди на.". Это серьёзная проблема. Не знаю пока что будем делать с вендорами.

PS: когда я слышу слово 18675, мне хочется схватиться за пистолет (с)

Сразу не читая всего остального о наболевшем. :))

... PS: когда я слышу слово 18675, мне хочется схватиться за пистолет (с) ....


AECMA 1000D издана в качестве Авиацонного справочника в НИИСУ. Правда ее малость испохабили, не так конечно как в случае с 18675, но тем не менее. Поэтому смело можете выпускать ЭД в соотвествии с 1000D. :)))

---
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ УНИТАРНОЕ ПРЕДПРИЯТИЕ
'НАУЧНО-ИССЛЕДОВАТЕЛЬСКИЙ ИНСТИТУТ СТАНДАРТИЗАЦИИ И УНИФИКАЦИИ' ФГУП 'НИИСУ')

АВИАЦИОННЫЙ СПРАВОЧНИК


МЕЖДУНАРОДНАЯ СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ К ТЕХНИЧЕСКИМ РУКОВОДСТВАМ, ВЫПОЛНЯЕМЫМ С ИСПОЛЬЗОВАНИЕМ ОБЩЕЙ БАЗЫ ИСХОДНЫХ ДАННЫХ.
AC 1.1.1000D-2002

Предисловие

1 ДОКУМЕНТ Международная спецификация требований к техническим руководствам, выполняемым с использованием общей базы исходных данных. Интерактивные электронные технические руководства (AECMA 1000D)
2 ПЕРЕВОД ВЫПОЛНЕН Научно-исследовательским центром CALS-технологий 'Прикладная логистика'
3 ЭКСПЕРТИЗА НА АУТЕНТИЧНОСТЬ ПЕРЕВОДА ПРОВЕДЕНА ФГУП 'НИИСУ'
4 АС ПОДПИСАН И ВВЕДЕН В ДЕЙСТВИЕ решением ТК 323
5 ВВЕДЕН ВПЕРВЫЕ
6 Настоящий АС разработан методом прямого использования аутентичного текста зарубежного документа AECMA 1000D
7 ИЗДАН В ТИПОГРАФИИ ФГУП 'НИИСУ'




Можете попросить головного заказчика чтобы он вас "заставил" использовать 1000D. Вообщем варианты есть. :)))

///
Очень типичная жизненная ситуация. Здесь работает фактор жадности, который не учтён в формулах. Замена такой же лопатки на таком же российском двигателе, но не для инозаказчика, а для внутреннего заказчика будет стоить 10 000 у.е. Я угадал? Это не говорит о том, что замена лопатки не технологична - это говорит о том, что изготовитель двигателя жадный.////

Не знаю, сколько она будет стоить для российского заказчика, просто на этом двигателе на корпусе КНД нет горизонтального разъема.

//// Я ничего удивительного в этом не вижу - работал либо фактор жадности, либо фактор зелёного человечка, имеющего свои чудачества (хоть он и заказчик).////

В подобных ситуациях процентов на 99 перестраховка конструктора. Зеленый он особо не шарит, разве что с аналогами сравнить.

///Слово MSG-3-анализ я уже слышал, но пока не разобрался что это такое. Я так понимаю, что мне предстоит определяться с периодичностью регламента, но у меня пока нет соображений как это делать применительно к бумажному изделию.////

Давайте мыло сброшу MSG-3 на русском языке.


>> на ТАНТК отдел надежности и безопасности и отдел эксплуатационной технологичности и котролепригодности в ходят в состав одной службы. Службы эксплуатации и ИЛП

///Во как! У нас надёжность относится к конструктору, технологичность как таковая отсутствует, как и ИЛП. Поддержка эксплуатации относится к коммерсантам. В общем, разрознено, и это плохо.////

Ну что бы совсем Вас расстроить. Кроме указанных отделов в упомянутую службу входят еще: отдел технических публикаций (все виды ЭД) и отдел технического сопровождения эксплуатации (авторский надзор эксплуатации и ремонта, техническая помощь, ЗИП, СБ и т.д.)

Хм. Не знаю ни одного советского, а также и ни одного импортного самолётного двигателя с горизонтальным разъёмом корпуса КНД. Везде корпуса КНД собираются кольцами. Вот КВД - да, с горизонтальными разъёмами.

Вообще, по скромности запросов ощущается рука Мотор Сыча - это имхо самая жадная моторная фирма. Если речь о двигателе Д-436, то я самолично когда-то менял вентиляторную лопатку на Д-36. Работа заняла пол-дня (один человек) плюс гонка двигателя ещё два часа. Или речь идёт о лопатке подпорной ступени?

>> Можете попросить головного заказчика чтобы он вас "заставил" использовать 1000D. Вообщем варианты есть

Ес-но, по 18675 мы ничего нового делать не будем. Эта ботва портит немало крови по старым типам, где ничего кардинально уже не переделать, приходится насиловать себя и людей. Дык, головного заказчика нету однако. Никакого нету. Вы-то сами как, по спецификации 1000D работаете?

///Далее, шопный ремонт двигателя может выполниться двумя способами. Немного утрирую, но принцип следующий:
1. Двигатель завозится в shop, разбирается, дефектируется, детали требующие ремонта ремонтируются, двигатель собирается и испытывается. Такой ремонт занимает 60-80 дней.
2. Двигатель завозится в shop, разбирается, дефектируется, взамен деталей требующих ремонта ставятся другие б/у детали из обменного фонда, двигатель собирается и испытывается. Такой ремонт занимает 30-40 дней.

Оба варианта - в соответствии с шоп-мануалом, но сделать можно по-разному. Это к вопросу о ремонтной технологичности.///

Позволю себе не согласиться. Это не эксплуатационная технологичность изделия, а схема организации ремонта. Причем, связанная исключительно с возможностью содержать или обращаться в обменный фонд. Что собственно говоря все равно имеет исключительно финансовое выражение.

... Вот КВД - да, с горизонтальными разъёмами...

Очипятался. Двигатель, тот который в Индии собираются по лицензии выпускать.

///Вы-то сами как, по спецификации 1000D работаете?

Максимально приближенно, насколько это возможно.

Доброго времени суток.
Мой респект Стреку за создание топика.

К моему стыду, у меня пока появилось время и желание пока только покритиковать (только 00-60):

1. Если смотреть на историю развития 00-60 и 1388 можно заметить, что развитие этой темы шло исключительно со сотороны т.н. военных администраций "приобретения" NATO , UK MOD и др.. Эти стандарты - нужны данным администрациям для приведения к единообразию тендорных предложений на разработку и поставку ВОЕННОЙ техники.

1.1 Полноценное использование 00-60, удовлетворяющее контрактные (тендорные) требования военных администраций всегда влечет за собой серьезное удорожание проекта и разумно только в случае огромных объемов серийного производства и эксплуатации, а также высокого уровня идентичности парка "оборудования" т.е. ограниченного количества конфигураций экземпляров (например либо не применяется, либо применяется ограниченно на уровне субконтрактов на проектах постройки крупных, единичных судов). Боингистов из RM&T работающих сегодня в подразделениях коммерческих самолетов, а вчера в военных, просто трясет при упоминании ILS:).

2. Коммерческие эксплуатанты в отличие от военных знать не знают что такое ILS. Уж поверьте мне, я довольно часто пытаюсь поднять этот вопрос в разговорах с инозаказчиками, но каждый раз встречаю у них непонивание в глазах.

3. В комерческой авиации ILS как таковой не используется, хотя лично мне эта теория оч нравиться за свою стройность, системность и "широту". Уверен, что в военных проектах работать на позиции ILS manager супер интересно.

4. Кстати, в западном подходе, ILS manager - это позиция в т.н. acqusition team со стороны Покупателя, а не Разрабтчика. Причем покапателя в самом широком смысле (Заказчика, Головного Разработчика и т.д.)

Чуть позже, если позволите, я еще поворчу...

2В.П.Кучеров:

Вот именно в том-то и дело, что куда точно идти я как раз и не знаю. Вам это кажется странным? Для меня цель находится пока за горизонтом.
Москва не сразу строилась. Не могу и я построить ИЛП сразу.

1. Куда идти? Есть классика ИЛП, описанная в буржуйских стандартах. Сие есть объем и границы желаемого (если конечно оно действительно желаемо). Остается попристальней к этому присмотреться, изучить в деталях. И тогда прийдет понимание, куда гребсти... поэтапно :)
2. Знание объема и границ бедствия позволяет выстроить этапность внедрения, ставя первоочередными те части ИЛП, к которым Вы больше всего готовы и которые могут быть реализованы "автономно". При отсутствии вообче какого-либо основания для стрительства этой беды, начинать с нуля. В любом случае перед глазами должен быть Roadmap, из которого будет ясно, с чего когда начать и чем кончить...:) Ну не получится никакая этапность при отсутствии понимания целого...

>> Двигатель, тот который в Индии собираются по лицензии выпускать.

Ну, всё равно. Имхо цена явно завышена, даже капиталка движка дешевле стоит. Ну, фиг с ними, это их проблема.

>> Позволю себе не согласиться. Это не эксплуатационная технологичность изделия, а схема организации ремонта.

Ну, пожалуй да, не эксплуатационная технологичность, но всё равно это входит в комплексное понятие ИЛП, не так ли? И тема не столь простая, не всегда просто выражается деньгами (хотя в конечном итоге всё равно деньгами) - например, если искомой детали в обменном фонде нет, но такая подходящая есть на двигателе другого заказчика, который будет ремонтироваться позже. В таком случае возникает вариант попросить заказчика №2 отдать свою деталь для заказчика №1, а заказчику №2 будет отдана деталь заказчика №1, но только после ремонта, который по срокам подойдет под ремонт двигателя. Не знаю, внятно ли я выражаюсь. Короче, опять хочу сказать что всё не так просто, а жизнь подкидывает разные случаи.

>> Давайте мыло сброшу MSG-3 на русском языке.

Буду признателен. Мой мыл: dmafa собачья_морда list точка ru

2 goodways:

Ворчите, ворчите, от чего же не. Лично мне идея ИЛП нравится, несмотря на то, что я обрушиваю на неё ушата грязи. Я совершенно чётко НЕ представляю себе сопровождение эксплуатации новых типов без ИЛС-менеджера у разработчика. Старые как-то катятся по накатанной, но они катятся к концу ЖЦ. А новые надо как-то стартовать, для этого эксплуатанту просто необходимо приставить няньку. Хм. Какие могут быть сомнения, не понимаю.

Позволю себе, еще несколько замечаний.

Во-1х, не все сводится к двум вещам: готовности и стоимости, ЛА создается, чтобы использоваться по назначению, т.е. летать, а не только быть готовым летать.
Во-2х, MTTR - среднее время ремонта, какого (?), скорее всего здесь среднее время восстановления (устранения отказа).
В-3х, MTD - время простоя, опять какого (?), причины простоев бывают разные, наверно, здесь простой на переиодическом ТО.
В-4х, Формула рассчета Е теряет смысл, если средняя наработка на досрочный съем соизмерима с налетом парка за рассматриваемый период (в нашем случае - год), что будете закладывать "0 или 1, 5"?
При больших налетах и дорогих запасных частях вступает в силу уже управление запасами (дешевле произвести и доставить, чем закладывать и хранить). Кстати, кроме досрочного съема есть еще и замена по ресурсу или по техническому состоянию.
В-5х, анализ ЕРТО с точки зрения стоимости ТО военных ЛА у нас никогда не проводился, поэтому ничего удивительного в 30% нет. Наши технари уже давно "подсчитали в уме" и половину РТО выполняли "ручкой".

ИЛП и я не могу даже начать строить, чтобы строить - нужен фундамент (научно-теоретическая база, четкое понимание физических явлений и процессов, происходящих в конструкции и системе сопровождения эксплуатации), силы и средства.
С уважением.