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

Введение

Работы по созданию единой информационной среды для управления жизненным циклом проектной документации в ОАО «КБСМ» проводятся в соответствии с концепцией создания информационной системы управления ОАО «Концерн ПВО Алмаз — Антей».

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

Специфика работы организации

Основной задачей проводимых работ стало создание единой среды для работы подразделений — от планирования проводимых конструкторских работ до сдачи разработанных документов в электронный архив с учетом промежуточных этапов: выдачи производственных заданий, технического документооборота, проведения изменений конструкторской документации (КД) и прочих процессов основной деятельности организации.

Специфика работы многих отечественных проектных организаций заключается в вынужденном использовании нескольких 2D- и 3D-САПР, и ОАО «КБСМ» здесь не исключение. При этом конечным продуктом является проектная документация, которая должна быть оформлена в соответствии с ЕСКД.

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

Разнородность САПР, имеющихся в организации, обусловлена:

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

Поскольку единого программного продукта и единого регламента работы с САПР не существует, каждое предприятие в освоении электронного документооборота идет своим путем. В рамках совместной работы с организациями-смежниками инженерам-проектировщикам приходится работать с различными программными продуктами. По этой причине получаемые из 3D-моделей двумерные документы обычно «дорабатываются» в AutoCAD или КОМПАС, что вызывает разрыв ассоциативных связей между 2D-объектом и 3D-моделью. Следует отметить, что проведение изменений в КД целесообразно проводить «от модели», но с разорванными связями автоматизация изменений в 2D-документах является проблематичной.

Несмотря на некоторое отставание России в области информационных технологий, связанное с политическими событиями конца прошлого века, страна имеет огромный промышленный и интеллектуальный потенциал, а также отработанные и стандартизированные ГОСТы на способы проектирования и производства сложнейшей продукции. С другой стороны, применение зарубежных САПР и PDM/PLM-систем имеет свои недостатки.

  1. Зарубежные САПР и PDM/PLM-системы не учитывают принятые в России способы производства продукции. Например, в них отсутствуют отечественные механизмы проведения изменений в проектной и технологической документации, алгоритмы технической подготовки производства и многое другое. Решить проблемы автоматизации проектной деятельности организации в существующих российских условиях можно следующими очевидными способами:
    • идти по пути слепого копирования зарубежных стандартов, что неизбежно потребует изменения значительной части устоявшихся в РФ принципов производства продукции и перехода не на один адекватно переведенный стандарт, а на все стандарты, связанные с ним;
    • отказаться от адекватного перевода стандартов, адаптируя их к принятым в РФ принципам производства продукции с возможностью передачи информации о структуре изделия зарубежным заказчикам с учетом их требований.
  2. Зарубежные PDM/PLM-системы являются дорогостоящими, и далеко не все организации могут позволить себе финансировать проекты их внедрения. Как правило, единая среда проектирования должна объединить сотни рабочих мест, при этом многие из них используют лишь небольшой процент всего функционала PDM/PLM-системы (по нашим оценкам — 5−10%). К таким рабочим местам можно смело отнести не только рабочие места для доступа к архиву, службы технологического, метрологического и нормоконтроля, но также и большую часть рабочих мест конструкторов. Поэтому более рациональным является обеспечение сотен рабочих мест более «легкой» системой (в нашем случае была предложена система TDMS), способной выполнять все востребованные на данных местах функции. Такой подход не исключает возможности использования на части рабочих мест, нуждающихся в расширенном функционале, PDM/PLM-системы, родственной западной САПР. При этом должен быть реализован механизм обмена данными между этими двумя системами.
С учетом данной специфики, присущей, на наш взгляд, большинству проектных организаций отечественной промышленности, в ОАО «КБСМ» был реализован проект создания единой информационной среды для управления жизненным циклом проектной документации в конструкторских подразделениях организации.

Автоматизируемые задачи

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

Основные программные модули системы условно можно классифицировать следующим образом:

  • планирование;
  • проектирование;
  • проведение изменений;
  • архив.

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

Планирование

В отличие от проектирования с использованием бумажного документооборота, в электронном проектировании появляются новые виды объектов: 3D-модель, расчетная модель (2D или 3D), объект с видео- и аудиозаписью, комбинированный объект, включающий в себя посредством ссылок в локальной сети или сети Internet другие объекты различных типов.

В связи с этим в реализуемой среде разработки создается не одно дерево объектов, отражающих структуру проекта, а два: дерево 3D-моделей, описывающих геометрию разрабатываемого изделия (в дальнейшем — «дерево 3D-моделей»), и дерево документов, в которое включаются 2D-модели и все остальные типы моделей и объектов проекта (в дальнейшем — «дерево документов»).

В качестве системы планирования на предприятии предложено использовать систему MS Project и программный интерфейс ее взаимодействия с системой TDMS.

Кратко опишем организацию программного взаимодействия систем TDMS и MS Project.

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

Руководитель проекта разрабатывает схему деления изделия на составные части и на ее основании создает в среде MS Project укрупненный план-график разработки проекта с указанием сроков, ресурсов (разработчиков) и взаимосвязей между задачами. При этом ресурсы, назначаемые каждой задаче плана-графика, «поступают» в среду MS Project из упомянутого выше ресурсного листа, созданного по данному проекту в среде TDMS. Автоматизированное взаимодействие TDMS и MS Project в области передачи ресурсов осуществляет реализованный модуль программного взаимодействия.

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

По завершении корректировок, согласований и утверждения плана-графика руководитель проекта получает возможность путем выбора соответствующей функции (специально разработанный программный интерфейс) в среде MS Project запустить процедуру автоматического формирования в среде TDMS древовидной структуры — дерева документов. Подчеркнем, что каждый узел сформированной иерархии является «заготовкой» документа (объекта) и/или группы документов (например, альбома) в составе которой производится регистрация в БД и разработка под управлением TDMS моделей, объектов и документов.

При ведении такой разработки под управлением среды TDMS, более подробно описанной в разделе «Проектирование», каждая 3D-сборка, объект или документ имеет свой статус, отражающий стадию разработки. В свою очередь, каждой стадии разработки соответствует определенный процент выполнения работ над документом. В зависимости от статуса этот процент «переносится» посредством программного интерфейса из среды TDMS в систему планирования MS Project. По окончании разработки КД в среде TDMS в среду MS Project через интерфейс поступает команда на отображение отметки о выполнении работ по соответствующей строке плана-графика.

Кроме вышеперечисленных функций в настоящее время теоретически проработано и реализовано решение для следующей ситуации: по различным причинам структура изделия, КД по нему и, соответственно, структура плана-графика в MS Project могут меняться (в структуру изделия добавляются новые ветви и узлы, некоторые ветви и узлы могут удаляться или, наоборот, раскрываться). В связи с этим структура изделия в TDMS синхронизируется со структурой плана-графика. Кроме того, проработана и реализована на практике «обратная связь»: при изменении структуры изделия в TDMS план-график в MS Project синхронно изменяется.

Это позволяет:

  • автоматизировать процесс согласования плана-графика посредством системы электронного документооборота;
  • синхронизировать структуру изделия в среде управления разработкой (TDMS) с календарным планом-графиком разработки КД;
  • синхронизировать ресурсы системы планирования с реальными ресурсами, задействованными в разработке КД;
  • автоматически устанавливать в среде TDMS сроки разработки КД в соответствии с планом-графиком;
  • автоматически получать информацию о реальном выполнении каждой задачи плана-графика (процент выполнения по каждой строке и факт окончания работ).

Проектирование

Основным средством разработки трехмерных моделей на предприятии является система трехмерного твердотельного проектирования Pro/ENGINEER от компании PTC. Следует отметить, что окончательное формирование двумерных чертежей на предприятии осуществляется как в данной системе, так и в системах плоскостного проектирования, созданных сторонними разработчиками. При этом ассоциативная связь между трехмерной моделью и порожденными ею двумерными чертежами может оказаться разорванной. Для предотвращения подобной ситуации в системе TDMS была разработана структура хранения данных, обеспечивающая сохранность ассоциативной связи. Ее идеологическим отличием является интеграция двух древовидных структур объектов TDMS, предназначенных соответственно для хранения трехмерных (дерево 3D-моделей) и двумерных (дерево документов) структур изделия. Такая интеграция предусматривает наличие горизонтальных перекрестных связей для ускорения навигации между деревьями, скажем, при переходе от трехмерной детали к ее проекции. По этим перекрестным связям также автоматически отслеживаются изменения трехмерной модели или плоского чертежа, и в случае изменения объекта с одной стороны связи автоматически формируется соответствующее уведомление конструктору о несоответствии оригинала порожденному им чертежу с требованием исправления возникшей ситуации. Рассмотрим поэтапно методологию работы конструкторов предприятия после завершения описанных выше процессов планирования.
  1. Создание и регистрация сборки верхнего уровня будущего изделия. На предприятии внедряется методология нисходящего проектирования и управления большими сборками в Pro/ENGINEER, предусматривающая создание на начальном этапе пустой древовидной структуры проектируемой сборки с ее последующим наполнением. Для создания концептуальной схемы будущего изделия руководитель проекта формирует сборку верхнего уровня, которая имеет прямую наследственную связь со срезом схемы изделия, полученным на этапах планирования. Таким образом, после окончания планирования руководитель проекта формирует в Pro/ENGINEER трехмерное дерево будущего изделия и при наличии соответствующих прав переносит его в TDMS. При этом в соответствии с принятым на предприятии соглашением об обозначениях объектов TDMS автоматически формируются перекрестные связи между древовидными структурами объектов среза схемы деления и регистрируемых 3D-объектов сборки верхнего уровня и, следовательно, — горизонтальные связи между деревом 3D-моделей и деревом документов.
  2. Выгрузка трехмерных данных из TDMS. При наличии соответствующих прав командой TDMS инициализируется выгрузка файлового состава из объектов в папку на локальной машине, местоположение которой задается конструктором. Этот процесс необходим для повышения отказоустойчивости системы в целом, поскольку работа конструктора становится автономной и на данном этапе разработки не зависит от состояния серверных и сетевых составляющих компонент. В процессе выгрузки данных в дереве 3D-моделей TDMS создается объект, файловый состав которого включает в себя все выгружаемые файлы, а также XML-файл, содержащий всю атрибутивную и иерархическую структуру выгружаемых объектов. Такой объект, создаваемый при каждой выгрузке, необходим для последующего восстановления выгруженных данных в случае их потери или для восстановления предшествующего состояния выгруженных объектов, являясь, таким образом, версией выгружаемых данных.
  3. Загрузка трехмерных данных в TDMS. Загрузка результата работы проектировщика из Pro/ENGINEER также инициализируется соответствующей командой TDMS. При этом во временную папку на локальной машине конструктора из Pro/ENGINEER выгружаются файлы последней версии модели, переносящиеся затем на сервер в дерево 3D-моделей TDMS. Данный процесс аналогичен процессу переноса объектов сборки верхнего уровня, однако здесь при включении файлов в состав объектов первоначального дерева 3D-моделей возможны три варианта поведения TDMS:
    • перенос измененного объекта — в данном случае в TDMS загружается измененный в процессе работы конструктора объект, ранее присутствовавший в модели, которая выгружается из дерева 3D-моделей. При этом происходит замена файлового состава и атрибутивной части в существующих объектах дерева 3D-моделей;
    • перенос добавленного объекта — в процессе переноса ранее не существовавшего в TDMS объекта в соответствующем месте дерева 3D-моделей формируется структура переносимого нового узла либо поддерева. При этом осуществляется проверка наличия объектов в дереве документов в соответствии с принятым на предприятии соглашением об обозначениях. При их наличии устанавливается перекрестная взаимосвязь между созданными объектами дерева 3D-моделей и найденными объектами дерева документов. Объекты, отсутствующие в дереве документов, создаются, как и в случае с деревом 3D-моделей, при этом перекрестные связи также устанавливаются автоматически.
    • перенос удаленного объекта — если удаленный объект имел в дереве документов объекты с существующим файловым составом, то он не удаляется из дерева 3D-моделей, а приобретает статус «аннулированного». В противном случае объект удаляется из дерева документов.

Проведение изменений

Механизм внесения изменений в конструкторские документы в системе TDMS был разработан на основании типовой схемы процесса внесения изменений в КД, принятой в ОАО «КБСМ». При этом во время проведения регламентных работ предусматривается возможность вносить в КД данные о замене устаревших элементов на новые, соответствующие достигнутому технологическому уровню. Таким образом, производится модернизация технических систем. Внесение изменений в электронном виде осуществляется в соответствии не только с положениями ГОСТ 2.503−90, регламентирующими проведение изменений в конструкторской документации, но с и требованиями к проведению изменений в электронных конструкторских документах, изложенными в приложении, А ГОСТ 2.051−2006 «Электронные документы».

При проведении изменений в электронных конструкторских документах реализован следующий алгоритм.

  1. Инициатор создает в TDMS извещение на изменения (ИИ), заполняет все необходимые поля карточки.
  2. ИИ встроенными средствами маршрутизации системы TDMS отправляется для получения регистрационного номера в отделе.
  3. Сотрудникам отдела СИТД приходит письмо с просьбой выдать регистрационный номер.
  4. После выдачи регистрационного номера ИИ отправляется обратно инициатору.
  5. Инициатор создает в системе TDMS электронное административное поручение, при помощи которого извещение отправляется по маршруту согласования.
  6. После согласования всеми указанными в маршруте лицами инициатору приходит соответствующее письмо, позволяющее приступать к внесению изменений.
  7. Инициатор создает производственные поручения со ссылкой на извещение и конструкторский документ, в который необходимо внести изменения, и рассылает их отделам-разработчикам для внесения изменений.
  8. Каждому отделу-разработчику приходит письмо и производственное поручение, в котором указан конструкторский документ, требующий внесения изменений.
  9. В системе TDMS в соответствии с требованиями приложения, А ГОСТ 2.051−2006 генерируются новые версии электронных документов, в которые и вносятся изменения. Все версии документов сохраняются в БД TDMS.
  10. В карточке учета указываются вносимые в конструкторский документ изменения, а в карточке версионности — новая версия и основание изменений.
  11. После прохождения маршрута рецензирования процесс внесения изменений в данный конструкторский документ считается завершенным.
  12. По окончании отработки всех производственных поручений и внесения необходимых изменений работа с извещением завершается и оно переводится в статус архива.
Через определенные периоды времени эксплуатации инициатор проводит проектно-конструкторские работы по модернизации технических систем и вносит изменения, направленные на улучшение характеристик технических систем. Это влечет за собой замену определенного числа элементов, что вызывает необходимость внесения изменений в документацию по описанному выше алгоритму.

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

Архив

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

Заключение

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

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

Литература

  1. Воробьев А.М., Щеглов Д.К. Создание единого информационного пространства организации // Сб. материалов семинара «Развитие информационной структуры Концерна». — М.: ОАО «Концерн ПВО Алмаз — Антей», 2007.
  2. Погорелов В.И., Щеглов Д.К., Рындин А.А. Методы обмена данными между системами поддержки жизненного цикла изделий на основе языка XML // Сб. материалов общероссийской НТК «Третьи Уткинские чтения». — СПб.: БГТУ «Военмех», 2007.
  3. Свинцов Е.Н., Щеглов Д.К., Крылов А.Н. Опыт использования системы 3D-моделирования Pro/Engineer для разработки средств ЗРК // Сб. материалов отраслевой НПК «CALS-технологии в образовании, науке и производстве». — СПб.: БГТУ «Военмех», 2007.
  4. Алимов М.В., Рындин А.А., Тучков А.А., Фертман И.Б. Ступени внедрения ИПИ-технологий. Опыт реализации электронного документооборота // REM № 2, 2006.
  5. Давыденко С.В., Павлович М.М. Реализация системы конструкторского документооборота и решение проблемы тиражирования документации в ЦКБ МТ «Рубин» // CADmaster № 5, 2000.
  6. Ведерникова Т.В., Смирнов C.В. Использование современных достижений информационных технологий в ЗАО «ЦНИИ судового машиностроения» // CADmaster № 5, 2005.
  7. Рындин А.А., Фертман И.Б., Тучков А.А. Ступени внедрения ИПИ-технологий. Опыт реализации электронного документооборота // Материалы конференции «Моринтех-практик — информационные технологии в судостроении». — СПб., 2006.
  8. Рындин А.А., Рябенький Л.М., Тучков А.А., Фертман И.Б. Ступени внедрения ИПИ-технологий // CADmaster № 1, 2006.
  9. Рындин А.А., Рябенький Л.М., Тучков А.А., Фертман И.Б. Описание электронной информационной модели изделия судостроения на различных стадиях жизненного цикла с элементами интегрированной логистической поддержки // Сб. материалов конференции «Применение ИПИ-технологий для повышения качества и конкурентоспособности наукоемкой продукции (ИПИ-2004)», 7−8 декабря, 2004 г., Москва.
  10. Давидович А.Н. «Обоснование необходимости использования гетерогенных САПР при проектировании сложных наукоемких изделий машиностроения «// REM № 4, 2007.
ОАО «КБСМ»:
Алексей Воробьев, член-корр. РА РАН, д.т.н., проф., зам. генерального конструктора по науке — главный конструктор — начальник РИО
Владимир Пивоваров, зам. главного конструктора — начальника КК-ПВО
Дмитрий Щеглов, руководитель лаборатории ИТ

CSoft-Бюро ESG:
Михаил Алимов, инженер-программист
Татьяна Ведерникова, ведущий инженер-программист
Лариса Данилова, к.ф.-м.н., бизнес-аналитик
Алексей Рындин, начальник отдела
Александр Тучков, к.т.н., директор Бюро ESG
Игорь Фертман, директор CSoft-Бюро ESG

Тел.: (812) 496−6929
E-mail: sales@csoft.spb.ru