Проектирование программного модуля экспорта/импорта в базу данных анализа логистической поддержки в программном продукте LSA Suite

Проектирование программного модуля экспорта/импорта в базу данных анализа логистической поддержки в программном продукте LSA Suite

Лист сокращений

Введение

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

Для авиационной техники, имеющей длительные сроки эксплуатации, затраты на послепродажной стадии, необходимые для поддержания заданных характеристик безопасности, надежности и готовности, могут значительно превышать затраты на ее приобретение. Поэтому основным критерием при решении о покупке самолета является стоимость его жизненного цикла (СЖЦ), включающая затраты на приобретение и эксплуатацию.

ОАО «Авиадвигатель» - известно в мире как ведущее в России конструкторское бюро - разработчик двигателей для военной и гражданской авиации, а также промышленных газотурбинных установок для энергетики, транспортировки газа и нефти, поставщик газотурбинных электростанций. В целях решения задач повышения конкурентоспособности и снижения СЖЦ продукции руководство ОАО «Авиадвигатель» приняло решение о внедрении на предприятии средства интегрированной логистической поддержки - программного продукта LSA Suite.

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

Глава 1. Общая часть

.1 Описание предметной области

Анализ применения информационных технологий (ИТ) в промышленности показывает, что одним из направлений их развития является все более широкое применение этих технологий на всех стадиях жизненного цикла (ЖЦ) сложной наукоемкой продукции, в частности продукции военного назначения (ПВН), в рамках интегрированной информационной среды.

Средством управления СЖЦ является интегрированная логистическая поддержка (ИЛП), представляющая собой комплекс процессов и процедур, направленных на сокращение затрат на постпроизводственных стадиях жизненного цикла, а также обеспечивающих определение параметров поддерживаемости и их анализ. ИЛП относится к числу базовых понятий концепции и стратегии CALS (Continuous acquisition and life cycle support) или ИПИ (информационная поддержка жизненного цикла изделий).

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

.1.1 Система ИЛП

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

До недавнего времени в определениях ИЛП не было однозначности - различные специалисты трактовали это понятие по-своему. Ситуация изменилась с принятием ГОСТ Р 53393-2009, где дается определение ИЛП. У специалистов, которые впервые знакомятся с проблемой ИЛП, нередко возникают вопросы: почему поддержка - логистическая? Под словом «логистика» понимают процессы, связанные с транспортировкой, складированием, таможенным оформлением и другими аналогичными действиями. Этим же словом именуют науку об управлении потоками товарной продукции. В рамках ИЛП эти процессы присутствуют, однако в общем спектре видов деятельности занимают весьма скромное место. В этой связи интересно заметить, что в нормативных документах министерства обороны Великобритании (стандарт 00-600 от 23.04.2010, стандарт JSP 886, том 7, часть 2 от 15.05.2008) даются определения ИЛП, в которых «логистика» вообще не упоминается. Так, в стандарте 00-600 говорится: «ИЛП (ILS - Integrated Logistic Support) это организованный подход, который влияет на конструкцию изделия и развивает решения по поддержке [изделия], оптимизирующие «поддерживаемость» и СЖЦ; формирует «начальный пакет поддержки» и гарантирует непрерывную оптимизацию решений по поддержке в свете модификаций изделия и изменений в его использовании по назначению и в предъявляемых требованиях».

В стандарте JSP 886 дается следующее определение: «Интегрированная логистическая поддержка (ИЛП) предусматривает виды деятельности (в оригинале - disciplines, «дисциплины»), гарантирующие, что на стадии проектирования оборудования идентифицированы и рассмотрены факторы «поддерживаемости» и стоимости, влияющие на конструкцию с целью оптимизации СЖЦ (в оригинале - Whole Life Cost (WLC)). И далее: «ИЛП должна применяться как гарантия того, что оборудование спроектировано «поддерживаемым», что создана необходимая инфраструктура поддержки и что СЖЦ оптимизирована».

Приведенные цитаты подтверждают, что упоминание о логистике в определениях ИЛП отсутствует.

Слово «Интегрированная» в составе термина означает, прежде всего, информационную интеграцию всех относящихся к обсуждаемой проблеме процессов.

Согласно ГОСТ Р 53394 - 2009 «Интегрированная логистическая поддержка промышленных изделий - совокупность видов инженерной деятельности, реализуемых посредством управленческих, инженерных и информационных технологий, ориентированных на обеспечение высокого уровня готовности изделий (в том числе показателей, определяющих готовность - безотказности, долговечности, ремонтопригодности, эксплуатационной и ремонтной технологичности и др.,) при одновременном снижении затрат, связанных с их эксплуатацией и обслуживанием».

ИЛП такого сложного наукоемкого изделия, как самолет, состоит из следующих основных элементов:

анализа логистической поддержки (АЛП) cамолета, проводимого на всех стадиях ЖЦИ;

планирования и управления ТОиР, проводимых на стадии проектирования и уточняемых в процессе производства и эксплуатации самолета;

управления процессами МТО эксплуатации, разрабатываемого на стадии проектирования и уточняемого в процессе производства и эксплуатации самолета;

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

обучения персонала, эксплуатирующего самолет;

планирование и организацию процессов упаковывания, погрузки/разгрузки, хранения, транспортирования изделия;

разработку инфраструктуры СТЭ;

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

мониторинг технического состояния изделия и процессов эксплуатации и технического обслуживания;

Приведенное выше определение и схема на рисунке 1 отражают точку зрения специалистов - разработчиков стандарта, сложившуюся к 2006-2007 гг. в процессе создания стандарта. За истекшие с этого времени 4-5 лет накоплены новые знания и представления о проблеме, в связи с чем и определение, и иллюстрирующая его схема нуждаются в некоторых уточнениях. При неизменности провозглашаемых указанным определением общих целей ИЛП следует уточнить содержание объединяемых этим понятием видов деятельности.

Рисунок 1.1 - Логическая схема взаимосвязи основных процессов ИЛП

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

Соответственно, виды деятельности ИЛП группируются по следующим основным направлениям:

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

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

совершенствование (развитие) СТЭ в ходе ЖЦ ФИ; это направление деятельности предполагает внесение в полученные при создании и сопровождении

Виды деятельности ИЛП, объединенные в описанные выше направления и реализуемые на разных стадиях ЖЦ изделия, логически и информационно интегрированы в единый комплекс процессов, в который вовлечены как разработчик (поставщик), так и заказчик (эксплуатант). Информационная интеграция процессов обеспечивает обратную связь между процессами: сведения, полученные в ходе эксплуатации, используются для совершенствования конструкции изделия и организации СТЭ.

Согласно схеме на рисунке 1 в ходе ИЛП выполняются следующие основные действия:

формирование концепции СТЭ/поддержки ФИ с учетом ожидаемых условий и сценариев эксплуатации; в ходе разработки изделия и СТЭ, а также при сопровождении и развитии СТЭ эта концепция может меняться;

систематизация сведений о конструкции изделия, необходимых для создания СТЭ, включая данные о надежности;

анализ логистической поддержки с формированием БД АЛП и получением необходимых данных и документов в форме отчетов из БД АЛП;

проверка фактических показателей поддерживаемости (ЭТХ) изделия, обеспечиваемых его конструкцией и созданной СТЭ;

оценки СЖЦ (в том числе прямых затрат на ТО и издержек, обусловленных простоями ФИ). [4]

Сравнение системы ИЛП и традиционной системы поддержки продукции показано на рисунке 1.2. [1]

Рисунок 1.2 - Отличия системы ИЛП от традиционной системы поддержки

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

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

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

.1.2 АЛП как часть ИЛП

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

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

Будучи многопрофильной инженерной дисциплиной, АЛП охватывает следующие основные направления:

анализ условий и возможных сценариев эксплуатации ФИ;

анализ существующей СТЭ;

анализ вариантов конструкции ФИ и СТЭ и выбор их наилучшего сочетания (рисунок 3);

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

анализ изменений в существующей СТЭ, связанных с вводом в эксплуатацию нового ФИ;

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

определение содержания послепроизводственного обеспечения - деятельности поставщика после прекращения производства ФИ;

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

оценка эффективности разработанной СТЭ в части ЭТХ ФИ, в том числе приращений коэффициентов готовности ФИ, снижения СЖЦ (в том числе затрат на ТО и издержек, связанных с простоями ФИ) и, при необходимости, планирование мероприятий по развитию СТЭ.

Рисунок 1.3 - Логическая схема анализа вариантов конструкции изделия и СТЭ и выбора их наилучшего сочетания

В ходе АЛП выполняют анализ структуры и функциональный анализ изделия, а также анализ видов последействий отказов (АВПО) и критичности отказов (АВПКО), при котором выявляют виды возможных отказов и определяют состав и приоритеты компенсирующих или корректирующих действий (работ по обслуживанию).

Конкретный набор задач АЛП определяется особенностями проекта и стадией разработки. Часть задач выполняется итеративно.

Для проектов, связанных с разработкой нового авиадвигателя, АЛП носит наиболее полный характер и охватывает все направления, перечисленные выше.

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

Исходные данные и результаты АЛП хранятся в специализированной базе данных - БД АЛП. Функции по созданию и ведению БД АЛП обычно выполняет разработчик.

1.1.3 База данных АЛП

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

Каждая задача АЛП представляет собой достаточно трудоемкое исследование процессов, документов, внешних условий, организационных структур, совокупность которых и образует систему ИЛП авиадвигателя. Каждое такое исследование требует участия многих специалистов различной, как правило, весьма высокой квалификации: конструкторов, расчетчиков, специалистов по надежности, организации эксплуатации и обслуживания, организации и проведению испытаний, охране окружающей среды, экономистов и так далее. Поскольку в ходе АЛП собираются и помещаются в БД АЛП огромные объемы разнообразной информации (числовой, текстовой, графической, мультимедийной и другой), непосредственными участниками, а подчас и организаторами АЛП должны быть специалисты в области информационных технологий.

.1.4 АЛП как часть процесса разработки авиадвигателя

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

Большинство задач АЛП носит качественный характер, в том числе анализ обслуживания по методике АТА MSG-3, направленный на обеспечение надежности. Лишь для некоторых процедур допускается количественное решение. К их числу относятся анализ видов, последствий и критичности отказов (АВПКО), анализ обслуживания, обеспечивающего надежность (АООН), частично анализ уровней ТОиР (АУР), расчет СЖЦ, расчет параметров МТО.

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

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

В целом система задач АЛП и последовательность их выполнения построены так, чтобы снизить вероятность неудачных проектных решений, влияющих на эффективность эксплуатации авиадвигателя. По аналогии со стандартами серии ISO 9000, направленными на построение системы, обеспечивающей заданный уровень качества и возможность адекватно демонстрировать потребителю способность управлять качеством, технологии и стандарты АЛП направлены на то, чтобы доказать потребителю (заказчику), что все меры, обеспечивающие сокращение СЖЦ изделия и увеличение уровня поддерживаемости, поставщиком (подрядчиком) приняты.

.1.5 Структурная схема процесса поддержки продукции и место подготовки к АЛП в данном процессе

В процессе изучения системы поддержки наукоемкой продукции были составлены контекстные диаграммы «TO BE» данного бизнес-процесса (ИЛП) в нотации IDEF0. Контекстная диаграмма процесса поддержки продукции (СТЭ) представлена на рисунке 1.4. Место подготовки к АЛП в данном процессе представлено на рисунке 1.5.

Рисунок 1.4 - Диаграмма «TO BE» процесса создания СТЭ

Рисунок 1.5 - Диаграмма «TO BE» процесса подготовки БД АЛП

Рисунок 1.6 - Диаграмма «TO BE» процесса анализа сценариев применения изделий

На диаграмме (рисунок 6) можно выделить область применимости данной работы. ЛСИ, ЛСФ, АВПКО и АВПО, а также информация для классификаторов, которые являются входными данными для разрабатываемого программного комплекса, их положение в структуре процесса АЛП показаны на данной схеме.

1.1.6 Структурно-функциональная схема предприятия и место структурного подразделения, для которого осуществляется разработка

Рисунок 1.7 - Структурно-функциональная схема подразделения

1.1.7 Обоснование выбора программного комплекса

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

Группой экспертов на предприятии были рассмотрены программные комплексы следующих фирм:Project

НИЦ CALS- DM - информационная система подготовки эксплуатационных данных, предназначенная для автоматизации деятельности проектно-конструкторских бюро, машиностроительных предприятий и предприятий других отраслей, разрабатывающих и выпускающих сложную наукоемкую продукцию. Используется преимущественно в кораблестроении, судостроении. В авиации использовалась в проекте Power Jet. Продукт нуждается в доработках. Поэтому, программный продукт SeaScape - DM в данной работе рассматриваться не будет. Следовательно, основными конкурентами в расчете АЛП являются программные модули LSA Suite (НИЦ CALS) и Favoweb LSA (ALD). В представленных программных продуктах реализованы все основные задачи АПП, выполняемые на этапах разработки и эксплуатации. Экспертами на предприятии были выделены основные требования к системе:

возможность создания логистической и функциональной структур изделия, их анализ и установление связей.

возможность импорта анализов АВПКО, АВПО (анализ видов и последствий отказов), а также возможность импорт ранее выполненных анализов АВПКО, АВПО из ALD RAM Commander.

возможность анализа MSG-3, оформления отчетов по анализу MSG-3 с перечнем элементов-кандидатов планового ТО для включения в сертификационный базис в соответствие с требованиями АР МАК и EASA.

возможность расчета периодичности работ по плановому ТО.

возможность разработки макетов технологических карт ТО.

возможность импорта макетов технологических карт ТО в издательскую систему TG Builder (или другую) для разработки и издания ЭЭД «Иллюстрированный каталог 34», «Каталог и руководство СНО».

возможность интеграции с БД Siemens PLM Software Teamcenter.

Для осуществления выбора поставщика была составлена сравнительная таблица систем:

Таблица 1.1 - Сравнительная таблица систем

Исходя из анализа получившейся таблицы, основываясь на данных о планируемых разработках, количества необходимых лицензий и других, экспертами на предприятии был сделан выбор в пользу программного продукта LSA Suite компании АНО «НИЦ CALS-технологий» г. Москва.

1.2 Проблема

С общетехнических позиций проблема регламентирования и учета, связанных с поддержанием авиадвигателя в работоспособном состоянии, сводится к:

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

обеспечению ремонтопригодности и эксплуатационной технологичности авиадвигателя;

рациональной организации снабжения эксплуатанта запасными частями, расходными материалами и принадлежностями, то есть материально-техническому обеспечению (МТО) эксплуатации авиадвигателя, профилактических и ремонтно-восстановительных работ, позволяющему избегать как дефицита, так и избытка материальных ресурсов;

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

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

организации своевременной подготовки и переподготовки персонала для эффективной эксплуатации и ТОиР нового авиадвигателя; [3]

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

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

Для решения данных проблем необходимо внедрение промышленных информационных технологий - CALS-технологий, в частности системы ИЛП, а так же автоматизировать процесс ИЛП и АЛП.

Но, в процессе внедрения системы АЛП, в частности программного комплекса LSA Suite, возникает проблема настройка данной системы под конкретные требования предприятия, на котором производится внедрение. Для решения данной проблемы и предназначен разрабатываемый в данной работе комплекс экспорта/импорта данных.

.3 Постановка задачи

Спроектировать модуль экспорта/импорта данных, необходимых для АЛП, из организационно-технических систем, существующий на предприятии (в частности: Siemens PLM Software Teamcenter 2007, ALD RAM Commander) в программный комплекс LSA Suite.

1.3.1 Описание разработки

Разработать шаблон импорта конструкторских данных из PDM-системы Siemens PLM Software Teamcenter 2007.

Разработать шаблон импорта ЛСИ из системы ALD RAM Commander и загрузить ЛСИ в программный комплекс LSA Suite.

1.4 Архитектура разрабатываемого программного комплекса

Были созданы диаграммы «TO BE» в нотации IDEF0. Контекстная диаграмма представлена на рисунке 1.8 и рисунке 1.9.

Рисунок 1.8 - Диаграмма «TO BE» программного комплекса. Уровень 1

Рисунок 1.9 - Диаграмма «TO BE» программного комплекса. Уровень 2

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

В общей части проанализированы:

Описание предметной области

Проблематика автоматизации внедрения АЛП

Место комплекса импорта в данной схеме

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

Глава 2. Специальная часть

.1 Описание модели данных

Информация о ЛСИ финального изделия, его АВПКО, а также данные для справочника «Компоненты и запчасти» логически разделены. Исходя из требований к параметрам импорта в программном продукте LSA Suite, был сделан вывод о том, что необходимо будет реализовать сложные выборки данных из баз данных. Данные находятся в базах данных двух организационно-технических систем: Siemens PLM Software Teamcenter 2007 и ALD RAM Commander.

Так, было принято решение создать шаблоны для формализации данных. Количество шаблонов решено было сделать равным трем: первый шаблон - для импорта из базы данных программного продукта Siemens PLM Software Teamcenter 2007 данных о компонентах и запчастях, из которых состоит финальное изделие; второй - для импорта ЛСИ из базы данных программного продукта ALD RAM Commander; третий - для импорта АВПКО из базы данных программного продукта ALD RAM Commander.

.1.1 Входные данные

Входными данными для справочника «Компоненты и запчасти» являются данные из базы данных программного продукта Siemens PLM Software Teamcenter 2007. Описание входных данных (шаблон) приведено в таблице 2.1.

Таблица 2.1 - Входные данные для шаблона загрузки данных в справочник «Компоненты и запчасти»

Входными данными для загрузки ЛСИ являются данные из базы данных программного продукта ALD RAM Commander. Описание входных данных (шаблон) приведено в таблице 2.2.

Таблица 2.2 - Входные данные для шаблона загрузки ЛСИ

Входными данными для загрузки АВПКО являются данные из базы данных программного продукта ALD RAM Commander. АВПКО состоит из 6 таблиц. Описание входных данных (шаблон) приведено в таблицах 2.3 - 2.8.

Таблица 2.3 - Входные данные для шаблона загрузки АВПКО. FMECA

Таблица 2.4 - Входные данные для шаблона загрузки АВПКО. TAM

Таблица 2.5 - Входные данные для шаблона загрузки АВПКО. FB

Таблица 2.6 - Входные данные для шаблона загрузки АВПКО. FM

Таблица 2.7 - Входные данные для шаблона загрузки АВПКО. EE

Таблица 2.8 - Входные данные для шаблона загрузки АВПКО. TESTS

2.1.2 Данные в системе

Данными в системе является информация, находящаяся в справочнике «Компоненты и запчасти» (рисунок 10), ЛСИ (рисунок 11), АВПКО (рисунок 2.1).

Рисунок 2.1 - Справочник «Компоненты и запчасти»

Рисунок 2.2 - ЛСИ изделия

Рисунок 2.3 - АВПКО изделия

2.2 Алгоритм программы

.2.1 Блок-схема алгоритма

Обобщенно алгоритм модуля импорта данных для справочника «Компоненты и запчасти» из системы Siemens PLM Software Teamcenter 2007 (рисунок 2.4).

Рисунок 2.4 - Блок-схема алгоритма

логистический поддержка интегрированный программа

2.2.2 Описание алгоритма программы

Название блок схемы алгоритма и соответствующее ему описание представлено в таблице 2.9.

Таблица 2.9 - Описание блоков

В ходе разработки были решены следующие задачи:

Разработан шаблон импорта конструкторских данных из PDM-системы Siemens PLM Software Teamcenter 2007

Разработан шаблон импорта ЛСИ из системы ALD RAM Commander и загрузить ЛСИ в программный комплекс LSA Suite

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

Заключение

Данная работа посвящена экспорту/импорту в программный комплекс LSA Suite.

В работе рассмотрены следующие объекты:

постановка задачи, технические требования;

описание модели данных;

описание структуры и алгоритма программного модуля;

Внедрение спроектированного модуля автоматизирует процесс экспорта/импорта данных в программный комплекс LSA Suite для проведения АЛП, ускорит процесс расчета стоимости ЖЦИ.

Список литературы

1.   Долженков Н.Н., Рипс П.А., Тараканов В.В. Создание современной системы логистической поддержки отечественных самолетов - насущное требование времени // Полет. - 2007 - №5 - с. 3-9.

2.      LSA Suite [Электронный ресурс]. URL: <http://www.cals.ru/products/LSA/>

.        ГОСТ Р 53392 - 2009 - Интегрированная логистическая поддержка. Анализ логистической поддержки. Основные положения; Введен 01.07.2010. - М. Стандартинформ, 2010 - 15 с. - (Автоматизированные системы управления <http://www.gostedu.ru/002/013/008/007/>).

.        ---Судов Е.В., Левин А.И., Петров А.В., Елизаров П.М., Бриндиков А.Н., Незаленов Н.И., Карташев А.В. Повышение конкурентоспособности отечественной продукции военного назначения за счет применения технологий интегрированной логистической поддержки и каталогизации // Альманах «Россия: союз технологий», Специальный выпуск «Каталогизация продукции  новый этап развития».  М.: НО «Ассоциация «Лига содействия оборонным предприятиям», 2012.  С.10-19 <http://www.cals.ru/information/biblio/art/kat_sudov_levin.pdf>.