CC BY
144УДК 62.50:681.51
Управление жизненным циклом сложных технических систем: история развития, современное состояние и внедрение на машиностроительном предприятии
© Е.И. Кузин1, В.Е. Кузин2
1МГТУ им. Н.Э. Баумана, Москва, 105005, Россия 2НПК «Уралвагонзавод», Нижний Тагил, 622007, Россия
Проведен обзор истории развития и современного состояния управления жизненным циклом сложных технических систем. Рассмотрены способ организации процессов и данных на предприятии в рамках концепции поддержки жизненного цикла сложных технических систем и методология описания архитектуры сложных организационных систем. Обобщены и сформулированы принципы, методологии, стандарты и технологии реализации систем поддержки жизненного цикла. Рассмотрен пример внедрения концепции поддержки жизненного цикла на Уралвагон-заводе.
Ключевые слова: сложные технические системы, жизненный цикл изделий, поддержка жизненного цикла, CALS-технологии, архитектура предприятий, управление бизнес-процессами, единое информационное пространство.
Введение. Сложные технические системы (самолеты, вертолеты, танки, атомные реакторы, буровые платформы и пр.) проходят жизненный цикл, занимающий десятки лет. Управление жизненным циклом изделия (ЖЦИ) таких систем является стратегическим направлением науки и технологической политики в промышленности и смежных секторах, позволяющим обеспечить сокращение [1]:
• затрат на разработку и производство наукоемкой продукции на 20.. .30 %;
• затрат, связанных с браком и устранением дефектов продукции, на 15.20 %;
• затрат в период эксплуатации продукции на 20.25 %;
• времени вывода на рынок новых образцов продукции на 60.70 %.
В начале 2000-х годов под поддержкой ЖЦИ понимали в основном проектные и конструкторские работы, поскольку инструментальные средства были сосредоточены на автоматизированном проектировании и управлении данными. До недавнего времени развитие информационных технологий (ИТ) шло в направлении автоматизации процессов определенной специализации, выполняемых на одном рабочем месте: проектирование (CAD/САПР), инженерные расчеты (CAE), проектирование технологических процессов (САПР ТП), операционный учет, управление ресурсами (ERP) и др. [2]. Типичный
ИТ-ландшафт машиностроительного предприятия представлял собой «островки автоматизации», обмен данными между которыми проводился исключительно в бумажной форме. Однако достаточно скоро использование бумаги как средства обмена между автоматизированными рабочими местами стало нивелировать эффект от автоматизации. Возникла потребность в едином интегрированном цифровом представлении изделия для обмена данными между различными рабочими местами в цифровом формате.
С ростом технической сложности изделий большую актуальность приобрело цифровое представление изделия на стадии эксплуатации (при выполнении ремонтов, технического обслуживания, закупки комплектующих). Таким образом, возникла необходимость планирования работ по техническому обслуживанию и ремонту (ТОиР) для обеспечения заданного уровня надежности изделия. Высокая конкуренция на рынке потребовала от предприятий сокращать время проектирования и подготовки производства изделий, а также затраты на эксплуатацию изделий, которые могли значительно превышать стоимость приобретения. Стало очевидно, что разнообразные потребности в данных об изделии в цифровом формате могут быть обеспечены в полной мере только на основе системного подхода к информационной поддержке жизненного цикла изделия (ПЖЦИ).
Жизненный цикл изделия состоит из следующих основных этапов:
• проектирование — формирование принципиального решения, разработка геометрических моделей и чертежей, расчеты, моделирование процессов, оптимизация и т. п. Этап проектирования также включает все необходимые стадии, начиная с внешнего проектирования, выработки концепции (облика) изделия и кончая испытаниями пробного образца или партии изделий;
• подготовка производства — разработка маршрутной и операционной технологии изготовления деталей, реализуемая в программах для станков ЧПУ, технологии сборки и монтажа изделий, технологии контроля и испытаний;
• производство — выполнение календарного и оперативного планирования, приобретение материалов и комплектующих с их входным контролем, выполнение всех требуемых видов обработки, контроля результатов обработки, сборки, испытания и итогового контроля;
• эксплуатация, предполагающая помимо собственно эксплуатации также монтаж изделия у потребителя, обслуживание и ремонт;
• утилизация.
Несмотря на то что о ПЖЦИ в инженерной среде известно давно, до сих пор можно наблюдать несходство толкований и нечеткость определений сути основных компонентов управления ЖЦИ. Это от-
части связано с эволюцией представлений о данных об изделии и бизнес-процессах, составляющих ЖЦИ и осуществляемых без использования бумажных носителей.
В настоящее время можно утверждать, что поддержка (управление) ЖЦИ — это концепция ведения бизнеса на основе системных решений, обеспечивающих коллективную разработку, распространение и использование технических данных об изделии, а также управление ими, начиная с создания концептуального прототипа изделия и заканчивая его утилизацией. Поддержка ЖЦИ обеспечивает интеграцию информации, персонала, бизнес-процессов, проектных, конструкторских, производственных и управленческих систем на всех этапах жизненного цикла и объединяет в комплексную систему передовые подходы и опорные технологии, включая управление данными об изделии (РБМ) [3], коллективные разработки, визуализацию, цифровое производство, выбор стратегических поставщиков, управление соответствиями, их проверку и пр.
Реализация концепции предполагает предварительную разработку и поддержание соответствующей архитектуры сложной организационной системы, которую образуют предприятия, процессы, технологии, ресурсы, информация и пр., объединенные ЖЦИ на всех его этапах [2, 4, 5]. Такая архитектура обеспечивает всестороннее видение сложной организационной системы и позволяет решить две главные проблемы. Первая проблема заключается в постоянном увеличении сложности организационной системы и ИТ-систем, находящихся при этом в постоянном развитии, изменении. Вторая вызвана тем, что со временем получить реальную отдачу от ИТ-систем становится труднее. Очевидно, эти проблемы взаимосвязаны. Чем сложнее организационная система, тем труднее обеспечить согласованное и эффективное взаимодействие разнородных компонентов и получить максимальную отдачу. Чем эффективнее удается справиться со сложностью систем, тем выше вероятность получения реальной выгоды и достижения целей. Для разработки архитектуры используют методологию описания архитектуры ТООЛБ [6] и таксономию Захмана [7], обеспечивающие:
• согласование целей участников ЖЦИ в рамках единого дерева целей, отображенного на организационную структуру;
• эффективное взаимодействие всех участников на всех этапах ЖЦИ за счет систематизированных, адаптированных и оптимизированных бизнес-процессов;
• бесшовный обмен данными между участниками ЖЦИ за счет единого информационного пространства, построенного в соответствии с международными стандартами;
• информационную и функциональную интеграцию программного обеспечения.
Управление данными в едином информационном пространстве на протяжении всех этапов ЖЦИ возлагается на систему PLM (Product Lifecycle Management). В настоящее время приходится констатировать, что реальная функциональность систем класса PLM, позиционируемых как интегрированная совокупность автоматизированных систем, охватывает лишь этап конструкторско-технологи-ческой подготовки производства (КТПП) изделия (да и то не в полной мере). Этап производства изделия, на котором требуется решение задач объемно-календарного и оперативно-календарного планирования, балансировки производственных мощностей, оптимизации поставок материалов и комплектующих, а также складских запасов, поддерживается специализированными информационными системами классов ERP, MES. Этап эксплуатации, на котором важную роль приобретает учет фактических технических характеристик изделия, учет его ТОиР, управление надежностью изделия, также требует применения специализированного программного обеспечения в зависимости от реализуемой методологии эксплуатации и обслуживания изделия. Как инструмент интеграции систем, используемых на этапе производства, современные системы PLM также обладают ограниченной фу нкциональностью.
Таким образом, технически концепция ПЖЦИ должна быть реализована за счет применения разнородных интегрированных между собой программных систем классов PLM (CAE/CAD/CAM/PDM), MDM, ERP, MES, ILS, MRO, FRACAS, которые используют данные единого информационного пространства, включающего электронный макет изделия (ЭМИ), а также процессы, ресурсы и контрагентов (рис. 1).
Эффективное использование разнородного по принципам построения и специализированного по назначению программного обеспечения при реализации концепции ПЖЦИ требует высокого уровня подготовки персонала, работающего с системой, а также высокого уровня культуры работы с данными. В российских условиях это означает смену методологии проектирования изделия, подготовки производства, методологии самого производства и эксплуатации. Так, в ходе подготовки конструкторов, использующих современные САПР, приходится учить не только возможностям программного обеспечения, но и методологии контекстного проектирования изделия «сверху вниз», которая позволяет реализовать параллельное проектирование изделия, что ведет к сокращению времени проектирования в несколько раз. Также необходимо провести обучение в области управления требованиями, изменениями и конфигурацией изделия. При подготовке технологов, применяющих современные САПР ТП, требуется освоение принципов сквозного проектирования технологи-
ческих процессов, в основе которого используется ассоциативная копия ЭМИ, переданная от конструкторов.
Высокий устойчивый спрос
Квалифицированный персонал
Поддержка руководства
Рис. 1. Основа поддержки жизненного цикла изделия — электронный макет: САПР ТП, САПР ИЭТР — системы автоматизированного проектирования технологических процессов и интерактивных электронных технических руководств соответственно; АЛП —
анализ логистической поддержки
Необходимо отметить, что, для того чтобы обеспечить возможность сквозного использования цифрового представления изделия на различных этапах его жизненного цикла, объем вводимых данных приходится увеличивать за счет данных, используемых на смежных этапах. Так, при разработке технологических процессов необходимо
вводить дополнительные данные о параллельности технологического процесса, его применяемости в зависимости от того, в какой сборочный узел входит изделие, и т. п. Это ведет к увеличению трудоемкости проектирования, которое компенсируется, например, возможностью выполнения оперативно-календарного планирования на этапе производства. Таким образом, при внедрении концепции ПЖЦИ неминуемо столкновение с интересами персонала, к которому предъявляются дополнительные требования.
И наконец, последним принципиально важным фактором при реализации концепции ПЖЦИ является высокий спрос на продукцию, делающий невозможным проектирование изделия и управление его производством вручную с использованием бумажных носителей и телефонных коммуникаций. Отсутствие такого спроса неизбежно влечет за собой снижение эффективности системы ПЖЦИ и появление бесчисленных «коротких путей» в виде телефонных звонков, excel- и word-отчетов, которые почти сразу создают «альтернативную» картину происходящего с изделием, что окончательно «убивает» автоматизированную систему ПЖЦИ.
CALS — переход к интегрированным бизнес-процессам и единому информационному ядру в цифровом формате. В основе концепции ПЖЦИ лежит решение министерства обороны США, принятое в 1985 г., о переводе технической и эксплуатационной документации на изделия высокой технической сложности в цифровой (электронный) формат. Необходимость такого решения иллюстрируется широко известным в США и малоизвестным в России историческим анекдотом о возникшей нехватке места на авианосце, который сдавался в эксплуатацию в ВМС США, для размещения всей необходимой технической и эксплуатационной документации на бумажных носителях. Решение было оформлено в виде распоряжения заместителя министра обороны США от 24.09.1985 г. о компьютеризированной логистической поддержке (КЛП, в оригинале CALS — Computer-Aided Logistic Support), которое определяло стратегию повышения точности, полноты, актуальности, подробности логистической технической информации и своевременности доступа к ней, учебные материалы и техническое описание изделия. С течением времени по мере накопления знаний и опыта в области создания и обмена данными в цифровом формате интерпретация аббревиатуры CALS претерпела несколько изменений: Computer-Aided Lifecycle Support (компьютеризированная ПЖЦИ), Continuous Acquistion and Lifecycle Support (бесперебойное снабжение и поддержка ЖЦИ), Commerce At Light Speed (бизнес со скоростью света).
Реализация распоряжения была поручена управляющей группе по вопросам КЛП в промышленности, созданной по инициативе министра обороны США. Главная цель работы группы (которая была
успешно достигнута) заключалась в переходе предприятий оборонно-промышленного комплекса и министерства обороны США от разрозненных и несогласованных бизнес-процессов, ориентированных на работу с информацией на бумажных носителях, к интегрированным в рамках ЖЦИ бизнес-процессам, обеспечивающим создание, преобразование (изменение), хранение, передачу технической информации об изделии и доступ к ней исключительно в цифровом формате. Основным направлением достижения данной цели стала системная разработка стандартов, определяющих структуру данных об изделии и порядок их обмена, а также апробация этих стандартов при производстве, закупке и эксплуатации новых образцов военной техники высокой технической сложности: самолетов A-12, ATF, V-22, LHX и подводной лодки SSN-21.
Роль стандартов и справочников для изделий высокой технической сложности. К моменту выпуска распоряжения о КЛП в США более пяти лет велась разработка стандарта IGES (цифровое представление для обмена данными, описывающими изделие). Стандарт IGES, впервые опубликованный в январе 1980 г. Национальным институтом стандартов и технологии США, позволил передавать в системы автоматизированного проектирования (САПР) каркасы моделей, поверхности любой формы, твердотельные модели и другие геометрические представления.
Помимо стандартов описания данных, формируемых и передаваемых на этапе проектирования, в США разрабатывались стандарты, определяющие данные и процессы этапа эксплуатации изделия (логистической поддержки):
• MIL-STD-1388-2A — анализ логистической поддержки (АЛП);
• MIL-STD-1388-2B — структура базы данных логистической поддержки;
• MIL-STD-1629A — анализ видов, последствий и критичности отказов (АВПКО/FMECA);
• MIL-STD-2361 — требования к интерактивным электронным техническим руководствам (ИЭТР).
Разработка стандартов сопровождалась активным созданием методологической базы, широкой подготовкой персонала, запуском пилотных проектов для отработки и апробации решений в соответствии с выпускаемыми стандартами. Так, для каждого из упомянутых стандартов были созданы руководства (MIL-HDBK-1388, MIL-HDBK-2361 и др.). В октябре 1991 г. с целью организации системной подготовки специалистов по проведению закупок военно-технической продукции и централизации учебных материалов и нормативных документов был учрежден Университет оборонных закупок (Defense Acquisition University).
Отдельно следует упомянуть работы по цифровой каталогизации и унифицированной кодификации предметов оборонных поставок, организованные Оборонным логистическим агентством США (Defense Logistics Agency). Начавшись в национальных масштабах с гармонизации справочников снабжения ВМФ, ВМС и сухопутных войск США, работы были продолжены на международном уровне в рамках программ НАТО по созданию единого справочника материального обеспечения (NMCRL — NATO Master Catalogue of References for Logistics). В настоящее время справочник содержит более 12 млн уникальных инвентарных кодов приблизительно 32 млн комплектующих и материалов. Инвентарный код НАТО (Nato Stock Number) включает в себя четырехзначный классификационный код группы снабжения (NATO Supply Classification Group), двузначный код страны, соответствующий требованиям Национального кодификационного бюро (National Codification Bureau) и семизначный код изделия, также присваиваемый Национальным кодификационным бюро. Необходимо отметить, что система кодификации НАТО полностью повторяет национальную систему кодификации США, которая использовалась до принятия системы НАТО.
В условиях набирающей обороты глобализации экономических связей, активного взаимодействия предприятий и государственных организаций стран — членов НАТО, а также расширения НАТО стало очевидно, что разработка стандартов и их апробация должны иметь международный характер. Так, в 1987 г. в техническом комитете 184 международной организации по стандартизации ISO была создана рабочая группа, задачей которой стала разработка стандарта ISO 10303 описания данных об изделии, получившего впоследствии сокращенное наименование STEP (STandard for Exchange of Product model data — Стандарт обмена данными о моделях изделий) [8].
В 1986 г. был стандартизован разработанный ранее язык обобщенной разметки SGML, позволявший создавать совместно используемые машиночитаемые документы и производить обмен такими документами (в первую очередь в больших правительственных и аэрокосмических проектах). Язык SGML стал основой созданных впоследствии языков HTML и XML. В начале 1990-х годов в Великобритании была начата разработка стандарта по интегрированной логистической поддержке DEF STAN 00-60, ориентированного на получение международного статуса. Приблизительно в это же время Европейская ассоциация предприятий аэрокосмической отрасли (AECMA) инициировала разработку стандарта S1000D, определяющего требования к ИЭТР. Впоследствии под руководством данной ассоциации были разработаны и разрабатываются следующие стандарты (спецификации):
• S2000M — спецификация управления материальными запасами в отношении обработки интегрированных данных;
• S3000L — спецификация анализа логистической поддержки;
• S4000P — спецификация создания и непрерывного совершенствования превентивного технического обслуживания;
• S5000F — спецификация данных операционного учета и учета технического обслуживания и др.
Процессы закупок и поставок комплектующих и материалов для нужд министерств обороны первыми подверглись переводу на технологии обмена данными в цифровом виде. Основным стандартом, определившим требования к обмену данными при подготовке и совершении коммерческих транзакций, стал стандарт UN/EDIFACT, разработанный рабочей группой по упрощению процедур международной торговли (WFI4) Европейской экономической комиссии ООН (UN/ECE) в середине 1980-х годов. В 1987 г. UN/EDIFACT был признан в качестве стандарта ISO 9735. Для содействия успешному внедрению UN/EDIFACT Генеральная Ассамблея EAN в 1987 г. приняла решение о разработке проекта стандарта EDI EANCOM на основе международного стандарта UN/EDIFACT. Стандарт EANCOM — это детализированное руководство по внедрению стандартных сообщений UN/EDIFACT. Сообщения UN/EDIFACT подчас имеют сложную структуру, и пользователи легко могут неправильно понять принципы и истинные намерения создателей таких сообщений. Являясь подмножеством UN/EDIFACT, стандарт EANCOM содержит точные определения и объяснения, которые позволяют торговым партнерам обмениваться коммерческими документами в доступной форме.
Интенсивная разработка стандартов в разных предметных областях потребовала координации усилий. С этой целью в 1995 г. был учрежден Международный совет по вопросам CALS (ICC — International CALS Congress), в который вошли представители почти всех крупнейших промышленных предприятий, выпускающих наукоемкую продукцию высокой технической сложности: British Aerospace, Newport Shipbuilding, Lockheed Martin, McDonnel Douglas, Raytheon, SAAB Aerospace, Marconi, Thomson CSF, Dassault Systems и др. Необходимо отметить, что разработка международных стандартов велась с привлечением широкого списка компаний из соответствующих отраслей. Так, в число разработчиков стандарта ISO 10303-239 (PLCS) вошли сотрудники компаний Boeing, Lockheed Martin, British Aerospace Systems, Baan, PTC, Rolls-Royce, SAAB Technologies, AEROSYSTEMS International, LSC Group, министерств обороны США, Швеции и Финляндии. Кроме того, потребовалось провести согласование (гармонизацию) уже разработанных стандартов. На заседаниях ICC рассматривали различные подходы к гармонизации, в числе которых модуля-
ризация ISO 10303, концептуальное объектно-ориентированное моделирование ЖЦИ и отдельных его этапов [9].
Концепция ПЖЦИ и новые бизнес-модели предприятия.
К середине 1990-х годов стало очевидным, что ПЖЦИ выходит за рамки оборонно-промышленной тематики, имеет огромный потенциал развития в гражданской отрасли и становится одним из конкурентных преимуществ предприятий, работающих на мировом рынке [2-4, 10]. Появился термин «контракт на поддержку жизненного цикла изделия», означавший перевод экономической деятельности предприятий, которые выпускают изделия высокой технической сложности, на сервис-ориентированную бизнес-модель. Предприятия теперь предлагали в качестве альтернативы приобретения изготавливаемой продукции время (часы) ее эксплуатации, включая услуги по ее техническому обслуживанию и ремонту без передачи прав собственности. Это позволяло снизить размер единовременных платежей, заменив их своего рода «абонентской платой» за использование изделия. Ярким примером перехода на сервис-ориентированную бизнес-модель является пример продажи времени эксплуатации авиадвигателей компанией General Electric. Необходимо отметить, что для заключения контракта на приобретение услуги по эксплуатации двигателя компания-покупатель должна отвечать определенному набору требований. Например, на самолетах, на которых будут установлены такие двигатели, должна быть система протоколирования всех событий, произошедших с самолетом в ходе его эксплуатации (включая события технического обслуживания и ремонтов).
Основные принципы ПЖЦИ. В ходе работ по созданию стандартов, каталогов, систем кодирования и реализации проектов по апробации этой нормативной базы был сформулирован ряд принципов, которые считаются неформальными «аксиомами» ПЖЦИ.
1. Поддержку ЖЦИ реализуют путем создания, использования и актуализации цифрового образа (макета) изделия с подробной (пооперационной) историей его проектирования, модификации, изготовления и эксплуатации.
2. Данные об изделии создают единожды, а используют многократно.
3. Создание данных, их обработка и обмен происходят в автоматизированном режиме с минимальным участием человека (так появилась интерпретация аббревиатуры CALS: Commerce At Light Speed — бизнес со скоростью света).
4. Обмен данными осуществляется в соответствии с международными стандартами.
С учетом современного уровня развития ИТ реализация перечисленных принципов кажется естественным и рациональным решением. Однако сделать это на практике особенно в российских условиях
достаточно трудно. Низкий и нерегулярный спрос на российскую наукоемкую продукцию почти полностью нивелирует преимущества, которые дает создание и поддержка единого цифрового представления изделия (сокращение временных затрат на технологическую подготовку производства (ТПП), оптимизация производственных расписаний, балансировка производственных мощностей, оптимизация складских запасов и т. п.). Поэтому в большинстве случаев на российских предприятиях цифровые представления изделия создаются на отдельных этапах жизненного цикла, но не являются совместимыми. Например, на этапе ТПП при разработке управляющих программ 3Б-модели создают с нуля или на основании электронных чертежей, а на этапе производства технологические данные (маршруты, технологические процессы, нормы) вводят вручную и используют лишь для решения задачи объемно-календарного планирования.
В условиях избытка дешевой рабочей силы, отсутствия достаточного количества компетентных специалистов, необходимости быть готовым к срочному выпуску продукции по распоряжению «сверху» ради получения государственных дотаций руководство российских предприятий предпочитает по традиции решать задачи подготовки и планирования производства выделением дополнительных людских ресурсов. Ошибочность такого экстенсивного подхода выявить достаточно трудно в силу ограниченного объема выпуска продукции, не требующего интенсивного обмена данными и их обработки: большинство проблем действительно могут быть решены телефонными звонками или в ходе производственных совещаний. Также необходимо упомянуть крайне низкий уровень культуры российского персонала при работе с данными, что весьма отрицательно отражается на их качестве: данные вводят не полностью, нерегулярно и с большим количеством ошибок. Имея такие исходные данные, мощные информационные системы неизбежно порождают ошибочные отчеты, модели, планы. Необходимость поддержки международных стандартов также не является для подавляющего большинства российских предприятий актуальной в силу отсутствия спроса на их продукцию за рубежом. В тех редких случаях, когда российская продукция пользуется таким спросом, требования к ее эксплуатационному обеспечению минимальны. Это позволяет, например, вместо общепринятых ИЭТР создавать технологические карты обслуживания и ремонта техники в отрыве от ее электронного макета с неизбежными проблемами актуализации такой документации при изменениях конструкторских или технологических данных.
Математические модели изделия и процессов в цифровом формате — ядро ПЖЦИ. Перевод данных об изделии в цифровой формат потребовал смены методологии их создания и обработки на всех этапах ЖЦИ [5, 11-15]. Так, на этапе КТПП вместо подготовки комплекта документов, не содержащих структурированных данных,
стали разрабатывать математическую модель изделия и процессов его изготовления, получившую название ЭМИ — электронного макета изделия. На этапе эксплуатации изделия на смену бумажным руководствам по обслуживанию и ремонту пришли ИЭТР, интегрированные с ЭМИ для упрощения актуализации при внесении изменений. Переход к математическим моделям представления изделия и процессов его изготовления открыл возможности для реализации принципов параллельного проектирования, автоматизации инженерных расчетов и проведения изменений, а также для имитационного моделирования функционирования изделия и процессов его изготовления [5, 12]. Потребность в упорядочении данных об изделии и разграничении доступа к ним на разных стадиях его жизненного цикла, а также потребность в синхронизации действий по созданию, обновлению, передаче и использовании данных привели к созданию нового класса программного обеспечения РБМ (программное обеспечение управления данными об изделии). Интеграция математических моделей изделия и процессов на всех этапах ПЖЦИ — это создание единого информационного пространства, обеспечивающего связность и согласованность всей информации по всем этапам и аспектам ПЖЦИ (рис. 2). Любое изменение в модели изделия или процесса автоматически отображается во всех ассоциированных элементах единого информационного пространства.
Стоимостный анализ
КПП, ТПП, Интерактивные
производства
Электронный макет изделия
Мастер-данные (нормативно-справочная информация)
Инженерный анализ
электронные технические руководства
Анализ логистической поддержки
Фактическая
стоимость эксплуатации, надежность, готовность
Имитационное моделирование функционирования
Имитационное моделирование изготовления
Рис. 2. Структура информационного пространства ПЖЦИ:
КПП — конструкторская подготовка производства; ТПП — технологическая подготовка производства
Новая форма организации процессов и данных на предприятии в рамках концепции ПЖЦИ. Переход предприятий на бизнес-модель, ориентированную на организацию ЖЦИ и его поддержку, был обусловлен целым комплексом факторов:
• расширением требований к изделиям и, как следствие, существенным возрастанием их технической сложности, что в свою очередь повлекло за собой необходимость установления эффективной и экономичной обратной связи между этапом эксплуатации и этапом проектирования;
• экспоненциальным ростом затрат на ТОиР изделий;
• зависимостью 80 % затрат на изготовление и эксплуатацию изделий от решений, принимаемых на этапе их проектирования;
• стремлением заказчиков снизить издержки на закупку и эксплуатацию техники.
Развитие технологии создания данных об изделии и технологии их обмена в цифровом формате, а также автоматизация управления взаимодействием между участниками ЖЦИ привели к возникновению новой организационной формы экономических связей — виртуального предприятия — группы участников жизненного цикла, объединенных в рамках единого информационного пространства, единой системы управления и взаимодействующих в соответствии с функциональной моделью ЖЦИ. Виртуальное предприятие существует, пока имеется потребность в поддержке соответствующего жизненного цикла (или, другими словами, пока действует контракт на поддержку жизненного цикла). Главной особенностью виртуального предприятия является высокая степень информационной и функциональной интеграции его участников в условиях отсутствия единого юридического лица, обеспечивающего вертикальные связи управления и определяющего права собственности на материальное имущество. Основной и единственный актив виртуального предприятия — это данные о ЖЦИ. Виртуальное предприятие обладает рядом п р е и м у щ е с т в, среди которых главными являются следующие:
• высокая динамичность. Предприятие создается с целью реализации жизненного цикла конкретной продукции (определенного номенклатурного ряда). При падении или отсутствии спроса на изделие виртуальное предприятие расформировывают, а его участники продолжают свою экономическую деятельность на других рынках или рыночных сегментах. Данная возможность позволяет предприятиям подстроиться под требования современного рынка, характеризующегося высокой динамикой спроса (длительность жизненного цикла постоянно сокращается) и отсутствием потребности в крупных объемах серийной (одной и той же) продукции;
• одновременное участие в нескольких виртуальных предприятиях в соответствии со своими ключевыми компетенциями и ресурсными возможностями. Таким образом, виртуальное предприятие способствует реализации одной из основополагающих рыночных стратегий — формирование и совершенствование ключевых компетенций.
Для того чтобы установить правила и порядок функционирования виртуального предприятия, необходимо разработать его архитектуру, которая определяет и увязывает в единую модель цели, бизнес-процессы, организационную структуру, единое информационное пространство виртуального предприятия, архитектуру программных приложений, реализующих бизнес-процессы. Базовые требования к архитектуре предприятия и процессам ее разработки сформулированы в стандарте TOGAF [7] (текущая версия 9.1 вышла в декабре 2011 г.), созданном консорциумом Open Group, в состав которого входят представители таких компаний, как Fujitsu, Sun Microsystems, Hitachi, Hewlett-Packard, IBM, NEC и др. В модели TOGAF архитектура предприятия подразделяется на четыре категории:
1) архитектура бизнеса — описывает процессы, используемые для достижения бизнес-целей;
2) архитектура приложений — описывает структуру конкретных приложений и их взаимодействие;
3) архитектура данных — описывает структуру корпоративных хранилищ данных и процедуры доступа к ним;
4) технологическая архитектура — описывает инфраструктуру оборудования и программного обеспечения, в которой запускаются и взаимодействуют приложения.
Однако TOGAF — это не формальная методология, а скорее рецепт по созданию архитектуры. В TOGAF описывается, как создать архитектуру предприятия, но не описывается, как создать хорошую архитектуру. Качество конечного продукта зависит от опыта персонала компании и консультанта по TOGAF.
К настоящему времени разработаны и успешно применяются языки (нотации), позволяющие формализовать такой фундаментальный аспект архитектуры, как процессы. В табл. 1 приведены используемые методы формализации бизнес-архитектуры. Среди приведенных в табл. 1 способов формального описания процессов только ARIS позволяет построить комплексную модель архитектуры, охватывающую все ее аспекты. Однако применение методологии ARIS ограничивается ее двумя главными н е д о с т а т к а м и:
1) ARIS предоставляет возможность формального описания только бизнес-процессов с заранее определенной последовательностью действий. По оценке агентства Gartner, доля таких бизнес-процессов не превышает 20 % общего числа бизнес-процессов на предприятии;
2) ARIS не обеспечивает возможность прямого исполнения моделей в системе управления бизнес-процессами. Модель бизнес-архитектуры, являющаяся результатом проектирования, требует ручной «доводки» программистами. Любое изменение в модели требует ручной «доводки» с нуля.
Таблица 1
Методы формализации бизнес-архитектуры
Нотация (методологии) Формализуемые аспекты бизнес- Результат Возможность построения комплексной модели
архитектуры бизнес-архитектуры
KAOS Цели,требования K AO S -диаграмма Нет
i* Цели, требования ^-описания Нет
Бизнес-процессы Нотация EPC (Event-Process Chain)
Модель данных Нотация ERM (Entity Relationship Model)
ARIS Организационная структура Организационная диаграмма Есть
Аппаратное обес- Принципиальная схе-
печение, сетевая ма
инфраструктура
BPMN, CMMN Бизнес-процессы Нет
Модель данных Диаграмма классов
UML Аппаратное обеспечение, сетевая инфраструктура Диаграмма развертывания Нет
ERD Модель данных Диаграмма «сущность - связь» Нет
RDF, OWL Модель данных Диаграмма «сущность - связь» Нет
ГОЕРО — функцио-
Бизнес-процессы нальные диаграммы; ГОЕР3 — описание процессов (в виде графов состояний) Нет
IDEF ГОЕР1х — диаграмма «сущность - связь»;
Модель данных ГОЕР4 — диаграмма классов объектов; ГОЕР5 — описание семантики (онтологий) Нет
Совместное использование нескольких способов формализации невозможно, поскольку они основаны на разнородных математических аппаратах. Так, нотация БРМК реализует аппарат конечных автоматов, а нотация ЕКЭ — аппарат реляционной алгебры. Поэтому результат одновременного использования нескольких способов описания различных аспектов архитектуры имеет исключительно иллюстративный характер и непригоден для автоматизированной обработки,
например, с целью порождения программного кода, поиска противоречий и др.
Методологической основой технологий создания виртуальных предприятий стали системный анализ и теория сложных систем.
Принципы, методологии, стандарты и технологии ПЖЦИ.
Развитие процессов глобализации привело к существенному возрастанию ценовой конкуренции между промышленными предприятиями. Применение концепции ПЖЦИ позволяет предприятиям избежать ценовой конкуренции, уничтожающей прибыль и возможности развития, за счет смены роли участника отдельного этапа ЖЦИ (например, производства) на роль «интегратора», определяющего структуру самого ЖЦИ, состав его участников, порядок их взаимодействия и т. п.
В новых условиях главной задачей, стоящей перед производителями, вместо организации конкурентоспособного производства стало выстраивание и поддержка цепочки всего жизненного цикла с возможностью управления и оптимизации его стоимости. Таким образом, возникает новая отрасль — организаторов (или интеграторов) цепочек ЖЦИ. Для эффективного и экономически целесообразного решения задачи организации цепочки ЖЦИ создан и непрерывно развивается комплекс принципов, методологий, стандартов и технологий, обеспечивающих реализацию отдельных этапов ЖЦИ и их информационную и функциональную интеграцию (табл. 2).
Таблица 2
Принципы, методологии, стандарты и технологии ПЖЦИ и отдельных этапов жизненного цикла
Этап реализации ПЖЦИ Этапы ЖЦИ
КПП ТПП Производство Поставка Эксплуатация
Принципы Ассоциативное проектирование — — — —
Параметрическое проектирование — — — —
Нисходящее проектирование — — —
Параллельное проектирование — — —
Методологии Методология создания ЭМИ Сквозное проектирование на основе ЭМИ МИР II — —
ВРМ ВРМ, 8СМ —
Управление надежностью
Окончание табл. 2
Этап реализации ПЖЦИ Этапы ЖЦИ
КПП ТПП Производство Поставка Эксплуатация
Методологии ИЛП* — — ИЛП*
Стандарты ISO 10303 (STEP), AECMA S1000D, AECMA 3000L ISO 13339 ISO 15531 (MANDATE), ISO 13584 (PLIB) AECMA S2000M, ISO 13584 (PLIB) AECMA S1000D, AECMA 4000M, ISO 55000
Технологии: САПР САПР ИЭТР САПР ТП CAE NX, Catia, Creo, SolidWorks, Solid-Edge, AutoCAD, T-Flex, «Компас» TG Builder Ansys, MSC, LMS, встроенные модули NX, Catia, Creo Teamcenter Manufacturing, TechCard, Techno-logi CS, «Вертикаль», NX CAM, Power-Mill — — —
Управление производством — — — SAP PP, SAP APO, 1С, OmegaPro-duction — —
Управление активами — — — — SAP, IBM Maxima, RealMaint
АЛП LSA Suite, RAM Commander — — — —
PDM Teamcenter, Enovia, Windchill/Search, «Лоцман», Lotsia PDM, T-FLEX Docs, Ю-PDM
ERP SAP, Infor, Oracle E-Business Suite, MS Dynamics AX, 1C, «Галактика», «Парус»
BPM Pega Systems, Tibco, Oracle BPM, Intalio, Comind, Bizagi
*ИЛП — интегрированная логистическая поддержка.
Пример реализации концепции ПЖЦИ. В качестве примера использования некоторых из перечисленных методологий, стандартов и ИТ при построении интегрированной системы ПЖЦИ можно привести опыт НПК «Уралвагонзавод» (рис. 3). В полном соответ-
Проектирование
Эксплуатационный состав
КПП
NX
LSA Suite
LS dyna Ansys Adams
IE
О
- ЦЗ № 1
I- ЦЗ № 2
s?
Технологический состав
— Операция 2.10
— Операция 2.20
М~220Л)
Сквозной технологический процесс
GOO G17 G40 G49 G80 G90 Т1 Мб
G43 2100. HI S1SD0 МЗ GOl X6.S7S ОТО Х6.5 Y0. Z0. ОТЗ У-0,003 R-6.S FSOO GOl Х6.575 ОТ1 Х8.125 Y-2.321 ОТ2 Х7.702 Y-3.477 R8.45 ОТЗ Х7.633 Y-4.571 R1.S5 G02 Х6.616 Y-17.591 R18.45 ОТЗХ8.866 Y-19.641 RÏ.55 ОТЗ Х15.649 Y-14.816 R21.S5 OT3Xie.024Y-X4.137 R1.55 G01 Х15.976 Y-14.125 ОТЗ Х10.914 Y2.375 R16.5 ОТЗ Х8.433 Y1.063 R1.5 G02 Х7.747 Y-3.497 R8.5 G03 Х7.681 Y-4.556 Rl.5( G02 X6.862 Y-17.612 R18.5
тпп
ТС Manufacturing
Стандартные изделия, покупные изделия
31
Материалы, оборудование,
инструмент, оснастка, профессии, подразделения
31
Ж САМ
Технологический состав
ТТЛ!
Маршруты, операции, переходы
УП
PDM
Сквозное управление бизнес-процессами (ВРМБ)
Рис. 3 (начало). Пример интегрированной системы ПЖЦИ: ЛКН — логистический контрольный номер; ЦЗ — цехозаход; МД — модуль данных; ЛСИ — логистическая структура изделия; ЛСФ — логистическая структура функции; АВПКО — анализ видов последствий критичности отказов; МТО — материально-техническое обеспечение; УП — управляющие программы; НСИ — нормативно-справочная информация
Производство
Себестоимость готовой продукции (план)
Структура затрат
Станок 1 Станок 2 Станок X
32
30
45
22 45 30
22 28 36
Себестоимость узла 1 (план)
Основные материалы (план)
Прямые трудозатраты (план)
Себестоимость узла N (план)
(план)
20
40
60
80 100 Unit
Накладные расходы (план)
Эксплуатация
Узел А
Узел В
леи О
Узел В. 1
МД А (модуль данных)
\
Вертикальное перемещение
Горизонтальное перемещение
\
\
\
W \ \
//
МДВ.1
ЛСФ
Перемещение под углом
S ^ a s
Я" о
% 6 о о
! и äg vo
Управление производством
Управление запасами
Управление надежностью оборудования
Управление затратами
Интегрированная логистическая поддержка
леи
и ЛСФ
АВПКО
Планирование ТОиР
Планирование МТО
Проектирование ИЭТР
IMPA-киоски
Omega Production
MCIS + + RealMaint
БАРЕЮ»
LSA Suite
IE
TG Builder
II
Cortona 3D
H
Технологический состав, маршруты операции
О
и
Производственные заказы
И
Перемещение
изделий и материалов
И
График использования оборудования
Технологический состав,
маршруты, операции, производственные заказы, перемещения изделий и материалов, НСИ
Конструкторский состав изделия, ЛСИ, ЛСФ
МД, ИЭТР, План ТОиР, План МТО
PDM
Сквозное управление бизнес-процессами (ВРМ8)
Рис. 3 (окончание). Пример интегрированной системы ПЖЦИ
ствии с неформальными аксиомами ПЖЦИ главной задачей создаваемой системы были формирование и актуализация единого цифрового представления об изделии и его жизненном цикле, обеспечение доступа к этим сведениям согласно выполняемым на каждом этапе задачам и организация свободного обмена данными между подсистемами. Для создания информационной модели единого цифрового представления необходимо определить процессы, реализуемые на каждом этапе ЖЦИ, в совокупности с исходными и порождаемыми данными. При разработке единой информационной модели на этапе КТПП были успешно решены следующие проблемы:
• переход от единой системы технической документации (ЕСТД) к модели сквозного технологического процесса, которая объединяет понятия технологического маршрута и единичного технологического процесса, включающего в себя пооперационные или попереходные нормы расхода материалов и нормы трудоемкости;
• разработка технологического процесса (в особенности с использованием станков с ЧПУ) на основе ассоциативной копии ЭМИ, полученного от конструкторов;
• согласование ЭМИ с использованием технологии Workflow на платформе Siemens Teamcenter;
• построение и использование централизованного справочника (классификатора) материалов, покупных изделий, деталей, сборочных узлов, оборудования, инструментов, оснастки, профессий, подразделений (нормативно-справочная информация — НСИ).
При построении единой информационной модели этапов технологической подготовки производства и производства изделия была успешно решена задача гармонизации модели технологического процесса для целей оперативно-календарного планирования и модели технологического процесса как результата проектирования. Решение получено за счет:
• построения отображения модели сквозного технологического процесса на модели технологического маршрута, единичного и типового технологических процессов;
• добавления технологическому процессу необходимых свойств (в частности, параллельного выполнения различных технологических процессов по выпуску одной и той же детали или сборки);
• «расшивки» правил входимости и применяемости.
Выводы. Система PDM — основа информационного пространства предприятия (источник данных для всех ИТ-систем).
Единой платформы PLM для построения систем ПЖЦИ пока не создано, поэтому необходимо распределять бизнес-процессы ЖЦИ по специализированным системам (САПР, САПР ТП, ERP, управление производством, управление надежностью, ИЛП).
Необходимы четкая формулировка бизнес-стратегии и описание реализующей ее модели организационной системы.
Требуется комплексное видение управления жизненным циклом продукции компании, соответствующее современным требованиям.
Необходим плотный мониторинг выполнения подрядчиками частных технических заданий на специализированные подсистемы.
ЛИТЕРАТУРА
[1] Яблочников Е.И., Фомина Ю.Н., Саломатина А.А. Компьютерные технологии в жизненном цикле изделия. Санкт-Петербург, СПбГУ ИТМО, 2010, 180 с.
[2] Дмитров В.И. Компьютерная поддержка непрерывных поставок и жизненного цикла продукции — основа обеспечения конкурентоспособности государств в XXI веке. Вестник машиностроения, 1996, № 4, с. 34-37.
[3] Норенков И.П., Кузьмик П.К. Информационная поддержка наукоемких изделий. CALS-технологии. Москва, МГТУ им. Н.Э. Баумана, 2002, 320 с.
[4] Соломенцев Ю.М. Экономика и управление предприятием. Москва, Высшая школа, 2005, 624 с.
[5] Судов Е.В., Левин А.И. Концепция развития CALS-технологий в промышленности России. Москва, НИЦ CALS-технологий «Прикладная логистика», 2002, 130 с.
[6] Стандарты Open Group. URL: www.opengroup.org/togaf (дата обращения 05.i0.20i5).
[7] Захман Дж.А. Структура архитектуры информационных систем. IBM Systems Journal, 1987, т. 26, № 3.
[8] Овсянников М.В., Шильников П. С. Глава семьи информационных CALS-стандартов ISO 10303 STEP. САПР и графика, 1997, № 11, с. 76-82.
[9] Dmitrov V. Conceptual object-oriented modelling of Product Life Cycle stages and its role in harmonising STEP/P Lib/EDIFACT/SGML Standards. Proposal to the International CALS Congress. USA, Orlando, 1997, p. 83-85.
[10] Колчин А.Ф., Овсянников М.В., Стрекалов А.Ф., Сумароков С.В. Управление жизненным циклом продукции. Москва, Анахарсис, 2002, 304 с.
[11] Соломенцев Ю.М. Информационно-вычислительные системы в машиностроении. CALS-технологии. Москва, Наука, 2003, 292 с.
[12] Давыдов А.Н., Барабанов В.В., Судов Е.В. CALS-технологии: основные направления развития. Стандарты и качество, 2008, № 7.
[13] Дмитров В.И. К вопросу о государственной стратегии России в области CALS-технологий. Информационные технологии. Москва, 1996, № 5, с. 25-32.
[14] Норенков И.П. Основы автоматизированного проектирования. 2-е изд. Москва, Изд-во МГТУ им. Н.Э. Баумана, 2002, 336 с.
[15] Судов Е.В., Левин А.И., Петров А.В., Чубарова Е.В. Технологии интегрированной логистической поддержки изделий машиностроения. Москва, Информбюро, 2006, 251 с.
Статья поступила в редакцию 13.11.2015
Ссылку на эту статью просим оформлять следующим образом:
Кузин Е.И., Кузин В.Е. Управление жизненным циклом сложных технических систем: история развития, современное состояние и внедрение на
машиностроительном предприятии. Инженерный журнал: наука и инновации, 2016, вып. 1.
URL: http://engjournal.ru/catalog/me sc/meng/1457.html
Кузин Евгений Иванович родился в 1946 г., окончил МВТУ им. Н.Э. Баумана в 1970 г. Канд. техн. наук, доцент кафедры «Системы автоматического управления» МГТУ им. Н.Э. Баумана. Автор более 10 научных публикаций. Область научных интересов: управление сложными техническими объектами, CALS-технологии. e-mail: evgeny.cuzin@yandex.ru
Кузин Вадим Евгеньевич родился в 1973 г., окончил МГТУ им. Н.Э. Баумана в 1995 г. Начальник отдела комплексной автоматизации НПК «Уралвагонзавод». Автор 5 научных публикаций. Область научных интересов: управление сложными системами, имитационное моделирование, управление бизнес-процессами.
Life cycle management of sophisticated engineering
systems: Development history, state of the art and implementation at the machinery manufacture
© E.I. Kuzin1, V.E. Kuzin 2
1Bauman Moscow State Technical University, Moscow, 105005, Russia 2JSC "Research and production corporation "UralVagonZavod", Nizhniy Tagil, 622007, Russia
The paper reviews the history of development in retrospect and the current state of life cycle management of sophisticated engineering systems. The methods of the processes and data organization across the enterprise within the concept of life cycle support of sophisticated engineering systems are considered along with the methodology describing the architecture of complex organizational systems. We formulate and summarize the principles, methodologies, standards and technologies. We also present an example of the concept implementation at UralVagonZavod.
Keywords: sophisticated engineering systems, management of product life cycle, CALS-technologies, enterprise architecture, business process management, single information space.
REFERENCES
[1] Yablochnikov E.I., Fomina Yu.N., Salomatina A.A. Kompyuternye tekhnologii v zhiznennom tsikle izdeliya [Computer Technologies in the Life Cycle of the Product]. St. Petersburg, St. Ptb. State University ITMO Publ., 2010,180 p.
[2] Dmitrov V.I. Vestnik mashinostroeniya - Journal of Mechanical Engineering,
1996, no. 4, pp. 34-37.
[3] Ovsyannikov M.V., Shilnikov P.S. SAPR i Grafika - CAD and Graphics,
1997, no. 11, pp. 76-82.
[4] Dmitrov V. Conceptual object-oriented modelling of Product Life Cycle stages and its role in harmonising STEP/P Lib/EDIFACT/SGML Standards. Proposal to the International CALS Congress. USA, Orlando, 1997, pp. 83-85.
[5] Dmitrov V.I. Informatsionnye tekhnologii - Information Technology, 1996, no. 5, pp. 25-32.
[6] Standards of Open Management Group. Available at: www.opengroup. org/togaf
[7] Zachman J. IBM Systems Journal, 1987, vol. 26, no. 3.
[8] Kolchin A.F., Ovsyannikov M.V., Strekalov A.F., Sumarokov S.V. Upravlenie zhiznennym tsiklom produktsii [Product Lifecycle Management]. Moscow, Anakharsis Publ., 2002, 304 p.
[9] Norenkov I.P., Kyzmik P.K. Informatsionnaya podderzhka naukoemkikh izdeliy CALS-tekhnologii [Information Support of High Technology Products. CALS-Technologies]. Moscow, BMSTU Publ., 2002, 320 p.
[10] Solomentsov Yu.M. Ekonomika i upravlenie predpriyatiem [Economics and Business Management]. Moscow, Vysshaya shkola Publ., 2005, 624 p.
[11] Solomentsov Yu.M. Informatsionno-vychislitelnye sistemy v mashinostroenii. CALS-tekhnologii [Information and Computer Systems in Mechanical Engineering. CALS-Technologies]. Moscow, Nauka Publ., 2003, 292 p.
[12] Norenkov I.P. Osnovy avtomatizirovannogo proektirovaniya [Basics of Computer-Aided Design]. Moscow, BMSTU Publ., 2002, 336 p.
[13] Sudov E.V., Levin A.I., Petrov A.V., Chubarova E.V. Tekhnologii integrirovannoy logisticheskoy podderzhki izdeliy mashinostroeniya [Technologies of Engineering Product Integrated Logistics Support]. Moscow, Informburo Publ., 2006.
[14] Sudov E.V. et al. Kontseptsiya razvitiya CALS-tekhnologiy v promyshlennosti Rossii [The concept of CALS-technology development in Russian industry]. Moscow SRC CALS-tekhnologiy "Prikladnaya Logistika" Publ., 2002, 129 p.
[15] Davydov A.N., Barabanov V.V., Sudov E.V. Standarty i kachestvo -Standards and Quality, 2008, no. 7.
Kuzin E.I., Cand. Sci. (Eng.), Associate Professor, Department of Automated Control Systems, Bauman Moscow State Technical University. Research interests: control of sophisticated engineering systems, CALS-technologies.
Kuzin V.E., Head of the Department of Complex Automation, JSC "Research and production corporation 'UralVagonZavod' ". Research interests: control of sophisticated engineering systems, simulation, business process management.
