Работа по созданию нового пассажирского самолета SuperJet 100 (SSJ 100) построена по классическим канонам, в соответствии с которыми разрабатывается и выпускается большинство машиностроительных изделий. Проектирование и изготовление ведутся головной компанией совместно с рядом проектных и производственных организаций. Информационная поддержка сквозного процесса как минимум предполагает проектирование и технологическую подготовку в электронном виде, включая управление данными об изделии, а также автоматизацию планирования и учета на стадии производства. По такой схеме работают многие десятки крупных и средних машиностроительных предприятий в России, выполняя в том числе и зарубежные заказы. Эти же принципы применялись и в проекте SuperJet 100, хотя для него характерен целый ряд особенностей. Об этом мы беседуем с директором по информатизации компании «Гражданские самолеты Сухого» (ГСС) Галиной Львовой.

Intelligent Enterprise: Прежде всего хотелось бы, чтобы вы вкратце рассказали об общей структуре проекта. Какие компании вовлечены в него, какова их роль?

Галина Львова: Наша компания является головным разработчиком проекта SuperJet 100 и по сути изначально была организована с целью создания регионального самолета. Это означает, что мы разрабатываем, поставляем самолет заказчику и по его запросу выполняем послепродажное обслуживание. Вместе с тем, как и в любом крупном машиностроительном проекте, с нами сотрудничает немало соразработчиков и соизготовителей по выпуску тех или иных компонентов самолета. Всего таких компаний, российских и зарубежных, более двадцати. Из зарубежных производителей основных подсистем самолета могу назвать такие компании, как Messier Dowty, поставившую шасси, или Thales, разработавшую авионику. Среди российских есть предприятия, входящие в холдинг «Сухой» и производящие крупные агрегаты, — это самолетострои­тельные заводы из Комсомольска-на-Амуре и Новосибирска. А, например, компания PowerJet специально была создана на базе рыбинского НПО «Сатурн» и французской Sneсma с целью разработки и производства двигателя для SSJ 100. В отличие от простых соразработчиков PowerJet является риск-разделенным партнером, то есть она делит с нами риски проекта. Производителями отдельных агрегатов выступают как российские, так и зарубежные компании.

Кроме того, ЗАО «ГСС» органи­­зо­ва­ны три филиала — в Комсомоль­ске-на-Амуре, Новосибирске и  Воронеже, а также террито­ри­аль­но удаленная площадка в Жу­ков­ском для проведения лётно-испытательных работ. Филиал в Комсо­моль­ске-на-Амуре производит финальную сборку изделия.

Изначально все работы по проектированию и последующему запуску SuperJet 100 в промышленное производство было решено вести с широкомасштабным применением информационных технологий.

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

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

Давайте теперь пойдём по порядку — начиная с проблем, характерных для этапа проектирования.

Структуру информационной поддержки проекта на этом этапе в общем можно считать вполне классической. Совокупность PDM/CAD/CAE-решений, являющихся основой автоматизации проектирования и подготовки производства, дополнена расширенной функциональностью по автоматизации управления самим производственным процессом, включая работу с поставщиками и заказчиками. Естественно, отправной точкой является проектирование изделия при помощи CAD/CAE-систем, с которым процесс разработки, тем не менее, может однозначно ассоциироваться лишь на начальной фазе. Другими словами, ИТ-поддержкой с помощью CAD/CAE-систем без привлечения системы управления данными изделия — PDM — можно ограничиваться толь­­ко на самых первых стадиях большого проекта, когда проработка изделия еще не глубока, а количество данных невелико. Когда же возникает потребность в детальном (рабочем) проектировании, в управлении опциями и вариантами и в применении конкретных компонентов в конкретном экземпляре изделия, изготавливаемого для конкретного заказчика, речь сразу заходит об использовании PDM-системы и о ряде связанных с ней дисциплин. Иными словами, PDM в качестве необходимого компонента проектирования и подготовки производства в нашем случае появляется на ранних стадиях проработки коммерческих заказов.

Специфика практического применения связки CAD/PDM, равно как и самой PDM-системы, в нашем проекте состоит, пожалуй, в том, что кооперация различных фирм здесь все-таки шире, чем это свойственно для проектов, реализуемых российскими предприятиями. По сути требовалось в одном проекте объединить усилия сотрудников нескольких крупных отечественных и зарубежных КБ, имеющих совершенно разные школы проектирования. Помимо различий в решении технических проблем есть существенные различия и в процедурных вопросах, определяющих, в частности, какими документами закрывается тот или иной этап проектирования. Отчасти с зарубежными подрядчиками в этом плане взаимодействовать оказывается как раз легче, особенно с теми из них, кто в силу своей специфики постоянно выступает в роли соисполнителей в крупных международных проектах и просто имеет большой опыт «настройки» собственной деятельности под те или иные особенности работы головной компании. Но одновременно при работе с ними встает проблема создания единого глоссария. Наш проект интернацио­нальный. Родным языком его участ­ников помимо русского является английский, французский, немецкий, итальянский. Естественно, встает проблема перевода, требуется дополнительная работа по согласованию технических терминов на русском и английском языках.

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

Следующий момент, также характерный для крупных проектов, состоит в необходимости разного представления одних и тех данных, описывающих изделия. Во-первых, не всем нужна детальная геометрия, а многим категориям сотрудников (технологам, нормоконтролерам, специалистам по обслуживанию заказчика) бывает достаточно просмотра упрощенной модели изделия. Во-вторых, на разных стадиях проекта требуется различное «ви’дение» состава изделия: «как спроектировано», «как построено», «как эксплуатируется». Управление составами изделия — это отдельная задача, которая решается с помощью PDM-системы. В связи со всем вышеизложенным приходится еще раз повторить, что создание единого информационного пространства, составной частью которого является среда формирования электронного макета изделия, — ключевой элемент, позволяющий сгладить все шероховатости, присущие проекту с широким сотрудничеством различных соисполнителей. А для любого крупного проекта в сфере машиностроения, я думаю, это характерно просто по определению. Кроме того, сглаживанию способствуют и различного рода регламенты, единые глоссарии и нормативные справочники, которые мы формируем в ходе проекта на базе многосторонних соглашений между его участниками. Хотя, честно говоря, многое из этого хотелось бы иметь на отраслевом уровне. И, наконец, персонал различных организаций должен быть приблизительно одинаково подготовлен в отношении работы с электронными данными об изделии, а сами эти организации — иметь схожий уровень культуры в этой области.

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

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

Подобную задачу мы решаем в проекте SSJ 100 при создании единого электронного макета. Этот макет поэтапно создается в ГСС под управлением PDM-системы TeamCenter Engineering, или TсEng, являющейся ядром информационной системы программы SSJ 100. В качестве CAD-решений ГСС и соразработчики применяют системы компьютерного проектирования CATIA V и Unigraphics NX4. Технически мы обмениваемся данными с компаниями, у которых установлены другие PDM-системы, и даже с теми, у кого таких продуктов вовсе нет, и здесь основным рычагом повышения эффективности использования ИТ-инструментария являются скорее регламенты и разработанные интерфейсы обмена данными.

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

Говоря о масштабном применении конкретного программного обеспечения в контексте крупных проектов, надо также обращать внимание и на следующие нюансы. Пока мы разворачиваем свою деятельность (а это все-таки длительный по времени процесс), даже такие, казалось бы, высокоразвитые системы, как CAD/CAE/PDM, тоже развиваются. Например, функционала некоторых PDM-систем ещё совсем недавно не хватало для работы с различными версиями одного изделия, но некоторым производителям все-таки удалось довести его до приемлемого уровня. Заметные сложности в CAD-системах до сих пор возникают и при работе с композитными материалами. И то и другое для нас чрезвычайно актуально, и в связи с этим нам приходится постоянно следить за развитием предложений в сфере автоматизации.

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

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

Предполагается, что все данные об изделии (в том числе результаты научно-исследовательских работ, расчеты различных характеристик, описания технологических процессов и т. д.) должны быть доступны с помощью PDM-системы. Целью внедрения такой системы является организация управления технической информацией по проекту, для чего решаются вопросы связи геометрических данных по конструкции изделия с негеометрическими данными и с документацией, задачи управления конфигурацией, интеграция TсEng с системами инженерных расчетов и иными приложениями.

Назову основные задачи при внедрении TсEng для проекта SSJ 100. Во-первых, управление электронными техническими документами; во-вторых, создание библиотеки данных по материалам, научно-технической документации, геометрических моделей стандартных и покупных изделий(1); в-третьих, разработка технологии управления конфигурацией изделия при ведении работ в TсEng, взаимоувязанной с директивной документацией; в-четвёртых, расширение функциональности процедур выпуска I-man/workflow и интеграция их в единую систему планирования работ по проекту; и в-пятых, внедрение процедур проведения изменений, увязанных с выпуском директивной документации и процедурами управления конфигурацией, такими как ведение системы управления различными представлениями (отображениями) состава изделия (инженерным, технологическим, эксплуатационным и т. д.), управление составом каждого изготовленного экземпляра изделия (опытного или серийного) и историей его изменения и установление связи состава изделия и его отдельных компонентов с предъявляемыми к нему требованиями, в частности весовыми.

Поскольку TсEng кроме того, что он должен управлять всеми геометрическими и негеометрическими данными проекта, становится интеграционным ядром всех систем, применяемых в проекте (автоматизированных систем проектирования, инженерных расчетов и т. п.), необходимо помимо перечисленных выше решить ряд задач по интеграции различных приложений. Это прежде всего интеграция TсEng с другим специальными САПР, например электротехнической (Electrics), с системой технологической подготовки производства и с блоком программного обеспечения интегрированной логистической поддержки, расширение функ­циональности TсEng средствами модуля Teamcenter Manufacturing (планирование производственных процессов) и т. д.

Под управлением PDM фактически работают CAD-системы. Конкретно в нашем случае в качестве последних выступают CATIA V разработки Dassault Systemеs и UG NX4 компании Siemens — Unigraphics Solutions. Под управлением PDM ведётся выпуск конструкторской документации, формирование директивных документов, определяющих применимость тех или иных компонентов для конкретного изделия, технологическая подготовка производства; эта система управляет также информацией о геометрии изделия, оснастки и инструмента. Далее на основе этих данных формируются так называемые директивные (укрупненные) технологические процессы, а затем и рабочие техпроцессы. Первые разрабатываются в головном офисе ГСС и представляют собой технологический документ, устанавливающий правильный технологический маршрут и предписывающий использование в рабочем техпроцессе обязательных методов и средств технологического оснащения. Вторые проектируются в филиалах ГСС и на заводах-изготовителях в соответствии с выпущенной конструкторской документацией и директивными процессами. Исходными данными в этом случае являются электронные макеты изделия и технологического оснащения. Выбор состава электронного макета и его выгрузка в файлы промежуточного формата осуществляется при помощи PDM-системы ТсЕng. Результатом работы является сформированный комплект технологической документации на процессы изготовления и сборки.

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

Вы упомянули о необходимости интеграции PDM с системами инженерных расчетов. Подобные системы класса САЕ, являясь действительно важным и известным классом ИТ-поддержки на этапе проектирования изделия, все же стоят особняком и вроде бы не должны быть тесно интегрированы в сквозной процесс информационной поддержки…

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

На сей счет существует два взгляда. Либо мы работаем в той же произрастающей из конструкторских задач системе управления данными об изделии, структуризация в которой по большому счету не совпадает с потребностями расчетчиков, либо наряду с PDM строим самостоятельную систему управления инженерной информацией, поддерживающую другую структуру данных. И таким образом мы имеем два пула данных, которые по ряду упомянутых выше причин тесно связаны между собой. Сейчас мы поняли, что управлять расчетными данными на основе файловой системы становится все сложнее. Большая часть прочностных и некоторых других расчетов у нас проводится с использованием семейства продуктов MSC.Software, и сейчас мы рассматриваем возможность внедрения разработки этой компании под названием SimManager, которая как раз и позволит отстроить такую систему.

А каковы принципы информационной поддержки изделия уже на стадии производства SuperJet 100, а также на стадии его эксплуатации?

Система управления на этих стадиях жизненного цикла, наверное, в принципе мало чем отличается от систем управления большинства отраслей промышленности, даже не обязательно машиностроительных. Мы должны управлять собственным производством, взаимодействовать с соисполнителями и заказчиками, и соответственно нам необходимы функции автоматизации, с которыми, как известно, ассоциируются ERP-, SCM- и CRM-системы. Что касается ERP, в качестве которой мы внедряем Oracle E-Business Suite, то она, естественно, должна полностью поддерживать процессы дискретного производства. С точки зрения конкретных функций нас прежде всего интересует управление производством, закупками, запасами и транспортировкой. Немаловажно для нас и управление проектами, персоналом, финансами, а также бюджетирование. Машиностроительная специфика в первую очередь проявляется в необходимости тесной связи с PDM-системой. Когда начинается стадия производства, эти две системы как минимум должны ответить на вопрос, что у нас заказано и как исходя из спроектированной модели подготовить производство и выполнить данный заказ. Более заметный отраслевой оттенок имеет функционал системы поддержки заказчика. Безусловно, это не анализ предпочтений потребителей, как бывает во множестве других отраслей. В нашем случае мы должны рассказать потребителю о продукте, о его конкурентных преимуществах и технических характеристиках, о том, в какой комплектации (с какими опциями) он может быть поставлен. Если, скажем, авиакомпания разместила заказ, то она должна знать, в каком он состоянии, а эта информация черпается уже непосредственно из ERP-системы. Кроме того, заказчику необходимо представить информацию о сервисе, связанном с эксплуатацией, а также каталоги запасных частей. Если он приобрел самолет, то эксплуатационную документацию в электронном виде (кстати, поставляемую нами для каждого отдельного борта и разрабатываемую на стадии проектирования) он тоже сможет получать через единую точку входа в режиме on-line. Понятно, что большая часть данной информации рождается и первоначально структурируется на стадии конструкторской разработки в PDM-системе, и это лишний раз подчеркивает ее ключевую роль.

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

Как мы видим, сквозная информационная поддержка в нашем случае осуществляется посредством достаточно знакомых в корпоративной среде функциональных категорий, но при этом вопрос, какие классы продуктов следует выбрать в качестве ключевых, отнюдь не является риторическим. С учётом масштабов нашей деятельности мы можем полноценно работать, только опираясь на «тяжелую» ERP-систему, а в такие решения уже давно «втянуты» многие SCM- и CRM-функции. Если же посмотреть на описание передовых PDM-систем, одну из которых мы используем, то можно убедиться, что они также включают в себя массу функций, характерных для популярных бизнес-приложений. В итоге мы пришли к своего рода двуполярной системе ИТ-поддержки, в которой центральное место занимают PDM- и ERP-системы.

(1)- Решение этой задачи осуществляется при участии ОАО «ОКБ Сухого» и серийных заводов.