Содержание к диссертации
Введение
ГЛАВА 1. Задачи интегрированной логистической поддержки 9
1.1 Состояние вопроса 9
1.2 Общие сведения об ИЛП Л
1.3 Анализ логистической поддержки . 13
1.4 Управление ТОиР 22
1.5 Управление МТО 25
1.6 Разработка и ведение эксплуатационной документации 28
1.7 Другие элементы ИЛП 31
1.8 Выводы по главе 1 , 33
ГЛАВА 2. Разработка интегрированной информационной модели (АЛП И ЭЭД) 35
2.1 Информационные модели, регламентированные нормативными документами в области ИЛП 35
2.2 Интегрированная информационная модель (АЛП и ЭЭД) .. 40
2.3 Выводы по главе 2 53
CLASS ГЛАВА 3. Методики решения задач АЛП 5 CLASS 5
3.1 Создание логистических структур, функциональный анализ 55
3.2 Методика анализа видов, последствий и критичности отказов 61
3.3 Методика расчета периодичности планово-профилактических работ... 67
3.4 Методика расчета параметров материально-технического обеспечения 77
3.5 Совместное выполнение расчетов периодичности планово-профилактических работ и параметров МТО 83
3.6 Разработка регламентов и технологий ТОиР по результатам АЛП 87
3.7 Отчеты из базы данных АЛП 91
3.8 Выводы по главе 3 , 93
ГЛАВА 4. Автоматизированная система алп: программная реализация и апробация 95
4.1 Создание проекта АЛП и настройка системы 95
4.2 Построение логистических структур и расчет показателей надежности 98
4.3 Анализ видов, последствий и критичности отказов (АВПКО)... 103
4.4 Расчет рекомендуемой периодичности планово-профилактического обслуживания элементов ЛСИ 108
4.5 Формирование перечня поставляемых запчастей и расчет параметров материально-технического обеспечения (МТО) 111
4.6 Разработка технологических процессов обслуживания 113
4.7 Формирование перечня начальной поставки (ПНП) и иллюстрированного каталога деталей и сборочных единиц (ИКДС) 119
4.8 Формирование структуры ЭТД на изделие, создание DMRL. 123
4.9 Апробация системы LSS в ОКБ нм. Яковлева 124
Выводы и результаты диссертационной работы 129
Библиографический список
- Разработка и ведение эксплуатационной документации
- Информационные модели, регламентированные нормативными документами в области ИЛП
- Создание логистических структур, функциональный анализ
- Создание проекта АЛП и настройка системы
Введение к работе
В последние годы словосочетание «Интегрированная логистическая поддержка»1 (сокращенно - ИЛП) стало популярным как в общетехническом обиходе, так и в научно-технических документах различного уровня и статуса: в концепциях, положениях и т.д. Такая популярность связана с выходом отечественной машиностроительной продукции на внешние рынки, где потребители этой продукции предъявляют к ней требования, основанные на международных и национальных стандартах, принятых в промышленно развитых странах.
Современные наукоемкие изделия (например, прокатный стан, станок с ЧПУ, самолет, корабль и т.п.) имеют длительный жизненный цикл (ЖЦ). Для таких изделий величина затрат в ходе ЖЦ - один из важных потребительских параметров. Эти затраты складываются из затрат на разработку, производство, ввод изделия в действие, эксплуатацию, поддержание его в работоспособном состоянии и утилизацию по истечении срока службы. Для систем, имеющих срок использования 10-20 и более лет, затраты на постпроизводственных стадиях ЖЦ, связанные с поддержанием изделия в работоспособном состоянии (состоянии готовности к использованию), могут быть равны или даже превышать затраты на приобретение. При этом, в силу общеизвестных экономических причин (инфляция, обесценение денег), первые со временем возрастают, а вторые убывают.
Понятие ИЛП охватывает комплекс управленческих и информационных процессов и процедур, выполняемых в ходе всего ЖЦ изделия, направленных, преимущественно, на сокращение затрат на послепродажное сопровождение2 при непременном обеспечении заданного уровня технической готовности.
1 В англоязычной литературе: Integrated Logistic Support (ILS)
2 Эти затраты иногда именуются «затратами на владение».
5 Это понятие относится к числу базовых инвариантных понятий концепции и стратегии CALS (Continuous Acquisition and Life Cycle Support) или ИЛИ (Информационная Поддержка жизненного цикла Изделий) [1-4].
С общетехнических позиций проблема снижения затрат, связанных с поддержанием изделия в работоспособном состоянии, сводится к следующим аспектам:
обеспечение конструкторскими, технологическими и производственными мерами высокой надежности (безотказности и долговечности);
обеспечение ремонтопригодности и эксплуатационной технологичности;
рациональная организация снабжения потребителей запасными частями, расходными материалами и принадлежностями, т.е. материально-техническое обеспечение (МТО) эксплуатации, профилактических и ре-монтно-восстановительных работ, позволяющее избегать как дефицитов, так и избытков материальных ресурсов;
рациональная организация процессов технического обслуживания и ремонта (ТОиР), позволяющая сокращать затраты на их проведение;
обеспечение эксплуатационного, обслуживающего и ремонтного персонала актуальной, достоверной и удобной для практического использования технической документацией;
организация подготовки и переподготовки персонала для эффективной эксплуатации и ТОиР новых изделий;
сбор, обработка и анализ данных о фактических показателях надежности, ремонтопригодности и эксплуатационной технологичности, на основе которых разработчики могут совершенствовать конструкцию, а также процессы эксплуатации и ТОиР.
Все эти аспекты традиционно находятся в центре внимания разработчиков и производителей техники. Им посвящены многочисленные научно-исследовательские и опытно-конструкторские работы, а также государственные и отраслевые стандарты.
По мере развития промышленных информационных технологий (ИТ) многие процессы проектирования, производства, эксплуатации и обслуживания техники приобретают новое качество, обусловленное возможностями интенсивного обмена техническими данными как внутри процессов, так и между ними.
Благодаря ИТ появилась возможность планирования, документирования и отчетности, относящихся ко всем действиям, процедурам и процессам ЖЦ изделия на формальной основе, обеспечиваемой упомянутым обменом данными, что способствует улучшению качества и организации послепродажного сопровождения наукоемкой продукции,
В этой связи ИЛП должна рассматриваться как совокупность базовых управленческих технологий в рамках ИЛИ, опирающаяся на возможности современных ИТ и обладающая следующими ключевыми особенностями:
системность, состоящая в охвате всех стадий ЖЦ и в наличии информационных обратных связей от процессов эксплуатации и технического обслуживания к процессам разработки и производства, что способствует совершенствованию конструкции изделия и системы его технической эксплуатации (СТЭ);
опора на формализованные информационные модели, обеспечивающие обмен данными и совместное использование этих данных всеми участниками ЖЦ изделия в рамках интегрированной информационной среды (ИИС);
использование в качестве целевых функций управления показателей конкурентоспособности и поддерживаемости (см. ниже), как интегральных оценок качества изделия и СТЭ.
Одна из важнейших составляющих ИЛП - анализ логистической поддержки (АЛП). АЛП представляет собой формализованную технологию всестороннего исследования машиностроительного изделия и вариантов системы его эксплуатации. Это комплексная инженерная дисциплина, находящаяся «на
7 стыке» процессов разработки изделия и СТЭ. АЛЛ направлен на сокращение затрат на ЖЦ изделия при заданных показателях надежности и эффективности. Результаты АЛЛ представляются в специальной базе данных - БД АЛЛ. В ходе АЛЛ решаются следующие основные задачи:
формирование требований к проекту и к системе поддержки изделия на основе сравнения с существующими аналогами; корректировка проектных решений, направленная на обеспечение эффективной эксплуатации;
разработка предложений по реализации системы поддержки эксплуатации, обеспечивающей наилучшее соотношение затрат и уровня технической готовности (коэффициента готовности) изделия, определяемое термином «пригодность к поддержке» или «поддерживаемость» (Supportability) [5];
определение потребностей в ресурсах логистической поддержки;
разработка планов послепроизводственной поддержки;
расчеты стоимости ЖЦ;
оценка достигнутых показателей эффективности эксплуатации.
К сожалению, до недавнего времени в России проблеме ИЛП в целом и АЛЛ в частности не уделялось должного внимания, что привело к существенному отставанию отечественной промышленности в этом направлении.
Главное отличие процессов и процедур послепродажного сопровождения, принятых в России и описываемых в отечественных нормативных документах, от аналогичных процессов и процедур, регламентированных зарубежными стандартами, состоит в том, что отечественные документы не предусматривают систематического применения ИТ для поддержки этих процессов в рамках
иис.
Как уже отмечалось, проблема ИЛП приобрела особую актуальность в связи с выходом отечественных предприятий - производителей наукоемкой продукции на международные рынки. Иностранные заказчики предъявляют к средствам и системам послепродажного сопровождения российских изделий те же требования, что и к аналогичным изделиям зарубежных фирм. В частности, они
требуют от российских производителей предоставления данных АЛЛ в форме отчетов или баз данных [5]. В этой связи проблема организации ИЛП и АЛЛ для изделий российских предприятий переходит в разряд первоочередных, поскольку от ее решения в значительной мере зависит конкурентоспособность отечественной машиностроительной продукции на мировых рынках.
Все вышеизложенное предопределяет актуальность темы диссертации. Поскольку АЛП требует обработки больших объемов разнообразной информации, его выполнение возможно только в автоматизированном режиме, т.е., по сути, речь идет об автоматизации достаточно своеобразного технологического процесса инженерной деятельности.
Цель работы: повышение конкурентоспособности продукции отечественного машиностроения на мировых рынках посредством создания и внедрения методических и программных средств автоматизации процессов АЛЛ в проект-но-конструкторских организациях.
Для достижения этой цели потребовалось решить следующие задачи:
Описать состав задач АЛП, содержание БД АЛП и выбрать задачи для первоочередной реализации в составе специализированного программного обеспечения (ПО).
Проанализировать информационные модели АЛП, содержащиеся в зарубежных нормативных документах, и на основе результатов анализа разработать интегрированную объектно-ориентированную информационную модель.
Разработать методики автоматизированного решения отдельных задач АЛП.
На основе интегрированной информационной модели и методик разработать ПО автоматизированной системы АЛП.
Провести апробацию ПО АЛП в конкретных проектах.
Теоретическое и экспериментальное решение перечисленных задач и составляет основное содержание диссертации.
Разработка и ведение эксплуатационной документации
Известно, что по мере усложнения изделий происходит резкий рост объемов технической документации, в том числе ЭД. При таких объемах бумажной документации возникают значительные трудности при поиске сведений, касающихся эксплуатации, обслуживания, устранения неисправностей и т.д., а также при сопровождении такой документации. В результате резко снижается эффективность эксплуатации сложных наукоемких изделий. Выходом из положения является представление ЭД в электронном виде (ЭЭД). Сегодня наличие ЭЭД на изделие является очевидным конкурентным преимуществом, а ее отсутствие может послужить непреодолимым препятствием к заключению контракта.
Необходимость перехода к ЭЭД, помимо роста объемов документации, обусловлена следующими тенденциями: ? Быстрые изменения, модификация техники приводят к тому, что многочисленные технические руководства становятся неактуальными и не отражают действительного состояния изделия. В результате бумажная документация обесценивается, а ресурсы на создание, хранение и сопровождение оказываются затраченными впустую. ? Увеличение номенклатуры и уменьшение сроков освоения новых изделий требует повышения квалификации и быстрого переучивания персонала, для чего необходимы учебно-методические материалы, которые целесообразно выпускать в электронном виде. ? Развитие автоматизированных систем диагностики и контроля, как встроенных в изделия, так и используемых в сервисных службах, требует специфических программных средств обработки информации; такие средства во взаимодействии с ЭЭД повышают надежность изделия в эксплуатации. ? Применение ЭЭД качественно улучшает дисциплину эксплуатации и обслуживания изделий и оборудования, обеспечивая выполнение всех требований технологии эксплуатации, разработанной производителем, и повышение показателя подцерживаемости изделия.
Правила создания, ведения и применения ЭЭД, модели данных и т.д. регламентированы международными стандартами [20,25,26].
Эксплуатационная документация (не обязательно электронная) представляет собой комплект документов, связанных в некоторую структуру. Стандарты [20,26] вводят базовые понятия, относящиеся к электронной документации.
Основное из этих понятий - электронная техническая публикация (ЭТП), которая является аналогом книги в бумажном комплекте документации. В различных отраслях промышленности существуют стандарты, регламентирующие перечень публикаций, поставляемых с изделиями.
ЭТП состоит из модулей данных. Модули данных составляются по жестко определенным правилам и имеют содержательную и стандартизованную идентификационно-статусную (атрибутивную) часть.
Неотъемлемая часть ЭТП - перечень действующих модулей данных -своеобразное оглавление, содержащее список модулей данных, составляющих публикацию.
Систему хранения и управления модулями данных принято называть общей базой данных эксплуатационной документации (ОБДЭД)10. Такая система, установленная у разработчика, позволяет при необходимости получить комплект технических публикаций на изделие и/или его разновидности в электронной или бумажной форме.
Общая структура ЭЭД схематично показана на рис. 1,7.
Модуль данных (МД) - совокупность взаимосвязанных технических сведений, относящихся к определенной тематике, не подлежащая делению на составные части. В [26] выделены шесть основных типов МД: 4. Информация о возможных отказах я методах их устранениях перечни возмож РисЛ 7 Ot i CSTA» 5 a tpoHKOMэксплуа тационной документации пых отказов с указанием их симптомов и, при необходимости, ссылок на процедурно-технологические МД описывающие процедуры поиска и/или устранения отказа. 5. Каталоги деталей и сборочных единиц: иллюстрированные перечни деталей и сборочных единиц, входящих в изделие, его системы или агрегаты. 6. Инструкции для оператора (экипажа): сведения и инструкции, необходимые для использования изделия по назначению.
Идентификационно-статусная часть МД содержит фиксированный набор полей, описывающих свойства МД: номер версии, дата издания (выпуска), причина издания (выпуска), язык содержательной части, уровень секретности сведений в МД и лр,
При иомощк щюнтификационно етатуенъгх частей МД система управления ОВДЭД обеспечивает: 1 формирование публикаций для различных конфигураций изделия; управление изменениями и версиями документации; » подготовку документации на нескольких языках; в контроль качества документации; формирование отчетной информации.
Эксплуатационную документацию на изделие, представленную в электронном виде, принято называть интерактивным электронным техническим руководством (ИЭТР). ИЭТР представляет собой комплекс взаимосвязанных технических данных, содержащихся в единой или распределенной системе хранения, и предназначено для отображения на электронном дисплее.
Данные в ИЭТР логически взаимосвязаны так, что пользователь может быстро получить доступ к нужной информации. ИЭТР в интерактивном режиме предоставляет справочную и описательную информацию о проведении эксплуатационных, сервисных и ремонтных процедур. Многие данные, включаемые в ИЭТР для решения многочисленных прикладных задач, получают в процессе проведения АЛЛ.
Информационные модели, регламентированные нормативными документами в области ИЛП
Стандарт DEF STAN 00-60 является нормативным документом, наиболее полно регламентирующим процессы и процедуры ИЛП. Объем стандарта, превышает 3000 страниц. В стандарте DEF-STAN 00-60 принята реляционная модель данных АЛП, состоящая из 108 реляционных таблиц, разбитых на 11 групп: Группа X: Структура изделия. Группа А: Требования к функционированию и обслуживанию. Группа В: Результаты анализа надёжности, готовности, ремонтопригодности; АВПКО. Группа С: Задачи обслуживания, анализ задач, необходимые ресурсы. Группа Е: Вспомогательное оборудование и материалы для обучения. Группа U: Описание и требования к испытываемым изделиям. Группа F: Данные об инфраструктуре для поддержки технической эксплуатации. Группа G: Требования к квалификации персонала. Группа Н: Данные для МТО и упаковки. Группа J: Анализ транспортабельности. Группа Z: Требования к упаковке, обработке, хранению и транспортированию боеприпасов.
В каждой группе содержится от двух (группа Z) до 19 (группа Н) реляционных таблиц. Все данные, документируемые в БД АЛЛ, представлены в виде элементов данных (ЭЛД). В [20] приводится словарь ЭЛД с описаниями, списками возможных значений, допустимым форматом данных и инструкциями по заполнению или расчету значений.
Принятая в стандарте [20] реляционная модель данных на момент создания первых его редакций (конец 80-ых - начало 90-ых г.г. XX века) была наиболее прогрессивной в отношении способов хранения и управления данными. В последние годы появилась альтернатива этой модели - объектно-ориентированные модели данных и соответствующие БД (ООБД). Несмотря на то, что технологии ООБД еще находятся в стадии становления, следует отметить ряд их принципиальных преимуществ перед реляционными БД (РБД) [36, 37].
Дело в том, что в РБД объекты реального мира представляются как структуры, состоящие из наборов элементарных типов данных (в нашем случае -элементы данных). Такое представление имеет понятную интерпретацию -строка в плоской таблице. Если специфика предметной области позволяет работать с такого рода представлением реальных объектов, то РБД отлично справляются со своей задачей. Однако, описание в виде набора плоских таблиц во многих случаях не отражает внутренней структуры предметной области, является искусственным и становится совершенно непонятным при увеличении количества таблиц. Именно такая ситуация имеет место с реляционной моделью данных, принятой в [20]. Иными словами, основной недостаток реляционной модели заключается в слишком сильной абстракции реального объекта, что ведет к потере семантики. Кроме того, имеет место и такой «технический» аспект: программное обеспечение РБД оказывается жестко завязанным на струк туру реляционных таблиц. Если в дальнейшем потребуется изменить эту структуру, то все программное обеспечение придется переделывать.
ООБД, в отличие от РБД, имеют простую и естественную связь с предметной областью, наглядно представляя ее структуру и состав. Применительно к такой сложной неоднородной предметной области, как ИЛП в целом и АЛЛ в частности, использование ООБД должно упростить процессы создания БД, внесения изменений в структуру и состав данных без переделки программного обеспечения и положительно сказаться на понимании пользователями принципов функционирования программ, работающих с данными.
Соображения, подобные сформулированным выше, привели к тому, что в более поздних по сравнению с [20] нормативных документах приняты объектно-ориентированные модели данных, описанные ниже.
Спецификация АЕСМА 1000D [27] регламентирует структуру общей базы данных (CSDB - Common Source Data Base), используемой для подготовки эксплуатационной документации (ОБДЭД). Как уже отмечалось в главе 1, основной информационной единицей - информационным объектом ОБДЭД (и формируемой на ее основе документации) является МД. Совокупность определенным образом отобранных и структурированных МД образует электронную публикацию. Спецификация предполагает использование шести основных типов МД (см. раздел 1.6). Для каждого из них определена собственная модель данных.
Технология представления данных, используемая в спецификации [27], базируется на стандарте [38], согласно которому разметка текста осуществляется путем вставки в него специальных ключевых слов - тегов (tags). Помощи тегов в тексте выделяются информационные объекты, и размеченный текст интерпретируется как совокупность таких объектов. Набор объектов, используемых в SGML-документе, должен быть предварительно декларирован в схеме данных, которая в [27] именуется Document Type Definition (DTD). DTD представляет собой обычный текстовый документ, содержащий описание объектов, их взаимосвязей и атрибутов.
Международная спецификация АЕСМА 2000М [26] описывает процессы и процедуры МТО в рамках поддержки ЖЦ изделий авиационной промышленности. Спецификация охватывает аспекты, аналогичные описанным в [20]: начальное МТО; кодификация предметов МТО; планирование текущего МТО; управление заказами; управление счетами; управление ремонтом.
Спецификация подробно описывает перечисленные процессы и процедуры, но не содержит информационной модели, а регламентирует лишь номенклатуру и формат обмена данными в электронном виде с помощью транзакций, оставляя выбор способа формирования и хранения информации на усмотрение пользователя.
К формированию информационной модели ИЛП имеет отношение первый раздел [26] - «Начальное МТО», который описывает порядок сбора, представления и обмена данными о начальном МТО. В результате создается перечень начальной поставки1 (ПНП) - официальный документ (в электронной или бумажной форме), содержащий сведения обо всех элементах, входящих в структуру поставляемого конечного изделия, а также о необходимых для эксплуатации предметах поддержки (вспомогательное оборудование, инструменты, расходные материалы и т.д.).
Создание логистических структур, функциональный анализ
Как следует из описания, приведенного в главе 1, АЛП начинают с формирования рабочих групп поставщика, заказчика и совместной рабочей группы. Силами этих групп разрабатывают стратегию и план АЛП, определяют организационные формы контроля за ходом АЛП, а также критерии оценки его результатов. Вся эта деятельность составляет предмет задач АЛП, относящихся к группе 100 (см. Приложение 2).
Далее необходимо изучить условия эксплуатации изделия у будущего (реального или предполагаемого) заказчика (задача 201). В процессе изучения разрабатывают сценарий использования изделия по назначению и описывают его миссии , а также собирают информацию о системе эксплуатации и ТОиР, имеющейся у заказчика. При этом определяют следующие параметры: ? количество КИ, эксплуатируемых по одному сценарию; ? средняя наработка одного КИ в год; ? среднее количество миссий одного КИ в год; ? средняя продолжительность одной миссии; ? продолжительность начального МТО; ? стоимость помещений для обслуживания КИ, хранения запчастей и др. По получении этих данных и занесении их в БД АЛЛ проекта приступают к решению одной из основных задач АЛЛ - функциональному анализу.
Функциональным анализом (задача 301) называется процесс выявления и описания всех функций КИ или входящей в него системы2. В процессе анализа формируется логистическая структура функций (ЛСФ), состоящая из элементов, соответствующих функциям изделия, и связей между ними. В соответствии с требованиями [20] каждому элементу ЛСФ присваивают уникальный код - логистический контрольный номер (ЛКН).
ЛСФ разрабатывают и анализируют с целью: создания описаний выполняемых функций; ? выявления полноты и непротиворечивости функций (в первую очередь- функциональных требований к изделию); ? выявления возможных видов функциональных отказов, а также анализа их последствий на всех уровнях вплоть до КИ (см. раздел 3.2).
Для вновь создаваемых изделий, не имеющих прототипов («пионерских» изобретений), по общей логике технического творчества создание ЛСФ - необходимый этап. Для изделий, имеющих прототипы и, тем более, относящихся к определенной отрасли (т.е. к сложившемуся классу), ЛСФ, как правило, соответствует дереву систем, подсистем, агрегатов и т.д., функции которых, в основном, известны apriori. Для изделий, находящихся на этапе производства или эксплуатации, необходимость создания ЛСФ определяется после оценки и сопоставления затрат и выгод, которые могут быть получены от этой работы.
ЛСФ формируется на основе данных, содержащихся в техническом задании, контракте, информации об аналогах, предварительных проработок (блок-схемы и подобные документы), описания сценария использования по назначению и миссий изделия.
В процессе создания ЛФ анадизируется миссия н определяются все функции изделия, необходимые для ее выполнения. Кроме основных функций, обусловленных назначением, рассматриваются вспомогательные функции, например, обеспечение экипажа информацией о состоянии изделия и передача этой информации в системы мониторинга.
Процесс создания ЛСФ состоит из ряда шагов. На нервом шаге функции КИ описываются укрупнено, без лишних подробностей и уточнений. Например, для самолета перечень укрупненных функций будет, как правило, соответствовать перечню основных систем [27], На последующих шагах выполняется разукрупнение каждой функции на один уровень вниз (выделение подфункций). В качестве примера на рис. 3 Л показано разукрупнение функции «Обеспечение жизнедеятельности экипажа и охлаждение оборудования», соответствующей системе кондиционирования, воздуха (СКВ) самолета. Необходимое количество уровней разукрупнения выбирается для каждой функции индивидуально с учетом ее сложности, удобства разработки конструкции (установления связей между функциональными к конструктивными элементами), удобства описания функциональных отказов изделия в процессе АВПКО.
Фрагмент ЛСФ самолета Вместе с создттм ЛСФ в процессе функционального анализа составляют описание каждой функции, присутствующей в структуре. При этом определяется и документируется, как минимум, следующая информация: предполагаемое время выполнения каждой функции в процентах от времени миссии; ? набор выходных параметров, характеризующих выполнение функции; ? значения этих параметров, считающиеся нормой, и допуски на них.
Информация обо всех видах возможных нарушений функций (полное невыполнение, выход значений одного или нескольких параметров за рамки допустимых значений) и последствиях этих нарушений собирается и анализируется в процессе АВПКО, который, помимо прочего, позволяет выявить критичные функции, требующие особого внимания при разработке конструкции изделия. На основании результатов анализа возможно изменение ЛСФ. Если изделие находится на этапе разработки, то ЛСФ может быть изменена с целью снижения критичности функций или введения дополнительных функций контроля за состоянием изделия. Если же конструкция изделия уже разработана и изменяться не может, то в ЛСФ можно вносить изменения, связанные с более удобным структурированием функций для целей АВПКО. Внесение изменений в ЛСФ и уточнение результатов АВПКО производится до тех пор, пока ЛСФ не станет пригодной для разработки на ее базе конструкции изделия или установления связей с элементами уже разработанной конструкции.
Конструирование изделия ведется с учетом созданной ЛСФ. В ходе этого процесса элементам ЛСФ (функциям) ставятся в соответствие: ? известные технические решения (изделия, для которых имеется комплект технической документации) без доработки; ? известные технические решения с доработкой, обусловленной новыми функциональными требованиями; ? новые технические решения с характеристиками (свойствами), обусловленными требованиями (в первую очередь - функциональными), не имеющими аналогов.
Создание проекта АЛП и настройка системы
В системе LSS используется множество справочников и классификаторов, которые требуется заполнить перед началом работы. С системой поставляются . Л файлы в формате .csv, содержащие типовые справочники, которые могут оыть загружены автоматически.
Чтобы загрузить в проект справочник из файла, поставляемого с системой, в главном меню выбирают «Лжжройт С&р№очн1жи Защ та иредакти-рввание» , затем - нужный справочник, и нажимают кнопку «Догрузить т фатая. Чтобы автоматически загрузить н проект все справочники, подавляемые с системой (рекомендуется), необходимо в главном меню выбрать «На стройт- првеочпиш{- 3агрузить есе т файлов т умолчанию»
Чтобы добавлять/редактировать значения в справочниках, необходимо в главном меню выбрать іІіастройка- Сярточпикіі- Загрута и редактирование». Затем в диалоговом окне из выпадающего списка «Справочник или каво еифитпюр» выбрать нужный справочник, после ч&го добавлять, удалять и редактировать значения с помощью кнопок «Добавить», «Удалить» и «Свойства)},
Справочники «Зоны изделия», «Справочник организаций и «Справочник шде/шиъ реализованы на отдельных вкладках системы. Данный о зональной структуре КИ, организациях-изготовителях и поставщиках комплектующих, а также о характеристиках существующих реализаций изделия могут быть внесены в справочники на этапе формирования логистической структуры изделия, либо по мере поступления данных на более поздних этапах АЛЛ. Для нового проекта АЛП обязательно требуется указать; ? КАФИ (код-акроним финального изделия); ? единицу измерения наработки; ? валюту проекта; ? параметры кодирования логистических элементов (ЛКН). Для корректной работы системы LSS рекомендуется заполнить также и остальные параметры проекта.
Перед началом работы рекомендуется установить для проекта значения параметров по умолчанию (после заполнения справочников системы), а затем отредактировать необходимые параметры. Для этого на вкладке «Данные о проекте» нужно нажать кнопку «Установить значения по умолчанию».
Создание сценария использования конечного изделия
Параметры сценария использования КИ заполняются на вкладке «Сценарий использования». Для нового проекта АЛП обязательно требуется указать; ? количество КИ, эксплуатируемых по сценарию; ? среднюю наработку КИ в год; ? количество миссий в год; ? среднюю продолжительность миссии.
Если в проекте предполагается учитывать различные фазы миссии, то следует создать перечень фаз миссии. В противном случае рекомендуется создать одну фазу миссии с наименованием «Все фазы» и указать для нее долю времени 100%. 4.2 Ностроекме логистических структур ЇЇ расчет показателей надежности Функции к структура изделия в системе LSS представляются в виде взаимосвязанных иерархических деревьев ЛСФ и ЛСИ (Рис. 4.2). 4,2.1 Построение логистической структуры функций ЛСФ включает в себя элементы, описывающие функции КИ к связи между ними, Для каждого элемента нужно указать: ЛКН (логистический контрольный номер) по [20]; ? наименование и описание функции; ? фазы миссии, в которых выполняется функция; показатели надежности каждой функции (интенсивность отказов). Структура ЛСФ редактируется на вкладке щруктура функций». Подчи ненная (дочерняя) функций создается через контекстное меню, связанное с ро дительской функцией. Описание и параметры каждой функции задаются в дна логовом окне ее свойств (контекстное меню на соответствующей функции " Сеойства или двойной щелчок мыта на соответствующей функции) (Рис, 4.3).
