Решение проблемы синхронизации электронных архивов предприятий на базе Lotsia PDM Plus
НПО «Искра» (г.Пермь) является головным разработчиком перспективных газоперекачивающих агрегатов для российской газонефтяной отрасли и основным разработчиком конструкторской документации. Предприятие уже давно и широко использует преимущества CALS-технологий при разработке и выпуске конструкторской документации — с середины 2003 года в промышленной эксплуатации находится электронный архив конструкторской документации на базе Lotsia PDM Plus.
Предприятия, участвующие в кооперации по изготовлению составных частей агрегатов, получают конструкторскую документацию на ранних стадиях отработки новых конструкторских решений. Сжатые сроки, большие объемы выпуска и передачи конструкторской документации, множество последующих уточнений документации, которые оформляются извещениями об изменении или предварительными извещениями согласно ГОСТ 2.503 и пересылаются этим предприятиям в бумажном виде, — все это создаст серьезную проблему по своевременному обеспечению данными производственного процесса для предприятий-соисполнителей.
Поэтому было принято решение передавать конструкторскую документацию предприятиям-соисполнителям в электронном виде. Данное решение распространялось не только на передачу сканированных изображений подлинников (этот процесс уже освоен и успешно функционирует), но и на передачу самих составов изделий и, естественно, изменений, необходимых для изготовления изделий.
Для начала предстояло решить проблему синхронизации электронных архивов НПО «Искра» и его основного предприятия-соисполнителя. Реализация этого была поручена ЗАО «ИВС» (г.Пермь, www.ics.perm.ru)
Все оказалось не так просто
На первый взгляд поставленная задача решалась элементарно — передавать каждый день всю базу или изменения в ней и все дополнения библиотеки сканированных подлинников. Однако не все так просто.
Во-первых, нужно передавать первоначальный состав изделия (здесь необходимо отметить, что лицензия на штатный модуль репликации для системы Lotsia PDM Plus у НПО «Искра» отсутствует). Время от сдачи извещения в службу техдокументации до момента отправки может составлять несколько дней. Действия по извещению (изменения значений атрибутов объектов состава изделия в электронном архиве, внесение изменений в сканированные подлинники в библиотеке документов архива) в течение этого периода проводятся на разных рабочих местах и в различное время. Поэтому передавать состав с незаконченной последовательностью изменений по извещению нельзя, поскольку до тех пор, пока изменение не вступило в силу, изготовление должно проводиться по прежнему составу (рис. 1).
Значит, для передачи состава изделия необходимо дождаться, когда в составе изделия завершатся все начатые изменения, а новые еще не успеют начаться. Для определения периода ожидания этого «окна» была построена предварительная математическая вероятностная модель:
где:
• T — период времени, в течение которого вероятность появления «окна» составит заданную величину J;
• t — длительность прохождения извещения на изменение, дней;
• Q — количество заявок в день. В нашем случае это произведение среднедневного количества извещений на среднее количество единичных изменений, содержащихся в одном извещении, которое, в свою очередь, учитывает как непосредственные изменения, так и вероятность влияния этих изменений на другие составы изделий;
• R — общее количество составов изделий в электронном архиве предприятия-отправителя;
• J = 0,95 — вероятность наличия «окна» для передачи состава.
Анализ модели показал, что продолжительность ожидания «окна» даже в случае трехкратного сокращения существующего периода проведения изменений и количества извещений составляет свыше 11 лет. Допустимые значения Q и t для периодов ожидания в 30, 60 и 90 дней, которые расположены ниже соответствующих кривых на рис. 2, для условий НПО «Искра» являются неприемлемыми.
Во-вторых, нужно постоянно передавать изменения в составе изделия и в документах архива. Простое, на первый взгляд, решение, заключающееся в том, что передавать через определенные промежутки времени изменения в таблицах базы данных электронного архива, здесь невозможно, поскольку нет признаков для определения условия передачи, то есть неизвестно, завершился ли процесс изменений.
В-третьих, электронный архив НПО «Искра» работает с основным составом изделия, то есть с составом, построенным по данным, содержащимся в подлинниках документов. В то же время большая часть изменений оформляется предварительными извещениями и отражается только в копиях документов (рис. 3). Напрямую организовать поэкземплярный учет составов изделий не представляется возможным: если каждый экземпляр изделия будет иметь свой состав в электронном архиве, то изменения по извещениям придется отражать в каждом из них, что многократно увеличит трудоемкость внесения изменений, а размеры базы данных возрастут на порядок.
Рис. 1. Процесс перехода состава изделия из исходного в измененное состояние
Есть и другое решение — отражать изменения по извещениям и предварительным извещениям в том же дереве связей, используя для разграничения изменений типы объектов и значения определенных атрибутов. Но здесь проблема состоит в визуализации результата: такой состав поддается однозначному толкованию компьютерными программами, но для человека становится нечитаемым. К сожалению, существующая в Lotsia PDM Plus функция представления проектов, которая легко справилась бы с задачей отображения составов экземпляров изделий, в настоящий момент не может скрывать отдельные ветви дерева и переносит потомков на уровень объекта, ветвь которого должна быть скрыта.
Казалось, что задача синхронизации данных электронных архивов отправителя и получателя без использования штатного модуля репликации становилась практически неразрешимой. Работа с одним общим электронным архивом также исключалась, поскольку НПО «Искра» выпускает не только газоперекачивающие агрегаты, но также нагнетатели и электростанции и другую продукцию — всего порядка 300 составов изделий.
И тогда специалисты НПО «Искра» и ЗАО «ИВС» пришли к следующему выводу — фиксировать начало процесса изменений в электронном архиве отправителя, а затем, в ходе всего процесса, отслеживать, какие изменения проводятся службой техдокументации с их рабочих мест в базе данных. В этом случае по окончании процесса специальная программа должна была расшифровать изменения, преобразовать их в перечень инструкций, которые отправлялись бы по электронной почте в электронный архив получателя, где по этим инструкциям ответной частью программы автоматически проводились бы предписанные изменения.
Трудность использования решения заключалась в сложности отработки системы отслеживания: в одном электронном архиве изменения проводятся вручную, в другом — автоматически. Не факт, что все многообразие действий пользователя будет правильно фиксироваться и расшифровываться программой сразу же или после трехнедельной отработки ее на полигоне. Тем не менее работы начались.
В процессе разработки технического задания предполагалось изначально синхронизировать электронные архивы предприятий по структуре объектов, атрибутов и связей, детально фиксировать текущие изменения в электронном архиве отправителя, обновлять электронный архив получателя только законченными (проведенными полностью) изменениями по извещениям.
 |
|
Решение найдено!
На этапе технического проекта удалось во многом упростить процедуру фиксации процесса изменений, просто отказавшись от отслеживания действий пользователя. Ключевым понятием будущей системы станет «длинная транзакция» (Saga) — сформированная разработчиком извещения последовательность изменений из перечня жестко заданных действий (сокращенно — build ).
Рис. 2. Время ожидания «окна» для передачи
Процесс будет выглядеть следующим образом (рис. 4): разработчик извещения об изменении вместе с оформлением извещения формирует последовательность (1), затем служба технической документации проводит изменения в документах архива и в момент вступления извещения в силу запускает эту последовательность в рабочей базе данных, то есть происходит актуализация изменений (2). Далее информация об изменениях фильтруется и выделяется часть информации, предназначенная для пересылки получателю. Передача данных об изменениях в архив получателя может осуществляться любым удобным способом (e-mail, носители информации, FTP/HTTP) (3). В результате снимается проблема отработки: и список действий жестко задан, и build выполняется в электронном архиве отправителя и только затем, после успешного выполнения, — в электронном архиве получателя (4).
Рис. 3 Отображение изменений по предварительным извещениям
Рис. 4. Схема работы
Еще один плюс от подобного способа работы — длительность процесса проведения изменений сокращается на порядки, время ожидания «окна» становится реальным, но для нас это уже не имеет особого значения.
|
|
Реализация решения
Располагая передовым программным обеспечением управления информацией об изделии Lotsia PDM Plus и опытом внедрения сложных, неординарных решений, ЗАО «ИВС» вместе с НПО «Искра» в настоящий момент вплотную приблизились к практической реализации идеи синхронизации посредством передачи «длинных транзакций». Разработка программы в полном разгаре, и согласно плану уже летом этого года выйдет действующая бета-версия программы (рис. 5).
Рис. 5. Вид окна программы
Разработчики программы синхронизации и участники будущего процесса с нетерпением ждут доработки функциональности представления проектов Lotsia PDM Plus, что позволит организовать передачу изменений и по предварительным извещениям.
|
|
Выводы
Описанное решение проблемы синхронизации электронных архивов даст возможность существенно уменьшить сроки выхода новых изделий на рынок за счет сокращения или исключения отдельных стадий жизненного цикла изделия на этапе разработки конструкторской документации и технологической подготовки производства. При передаче конструкторской документации в производство предприятия-соисполнители смогут отказаться от таких трудоемких и срочных работ, как чтение конструкторских спецификаций предприятия-разработчика, их интерпретация и ручной ввод в свою базу данных; соответственно исчезнут и связанные с этим ошибки.
При передаче изменений тоже ожидается также значительное сокращение задержек на стадиях изготовления и монтажа, которые зависят не только от своевременности получения и учета изменений, но и от их правильной интерпретации.
Стратегическим же преимуществом передачи «длинных транзакций» является потенциальная возможность синхронизации электронных архивов не только с архивами на платформе Lotsia PDM Plus, но и с архивами на других платформах, даже без использования штатного модуля репликации для Lotsia PDM Plus.
|
|
«САПР и графика» 5'2005
