Автоматизация потоков документации — важный шаг к созданию ЕИП СПб ОАО «Красный Октябрь»

Автоматизация процессов разработки и управления обращением программ для станков с ЧПУ

Доселе мы умышленно не употребляли термины «PDM» и «PLM». Это связано отнюдь не с непониманием и непродвинутостью авторов в этих понятиях. Скорее наоборот. Дело в том, что, к сожалению, очень часто мы сталкиваемся с подменой понятий некоторыми поставщиками и производителями решений, когда, например, делаются громкие заявления о внедрении PLM-системы. При детальном изучении такой системы оказывается, что решены лишь задачи на стадии жизненного цикла проектирования, частично производства. При этом, как правило, такая PLM-система функционально ограничена одной САПР, являясь ее «довеском» от производителя. Компания-поставщик быстро напишет любой интерфейс. Часто такая PDM/PLM по своей идеологии далека от принятых у нас принципов разработки КД и ТД. При этом, кроме «конструкторско-технологических», нередко забывают о весьма существенных аспектах управления информацией в процессе жизненного цикла изделия. К таким аспектам относятся, например, логистическая поддержка, эксплуатационная информация и документация, расписания и описания регламентов, электронные руководства и т.д. Описанные причины заставляют нас быть более осмотрительными в своих заявлениях, и вместо употребления терминов «PDM» и «PLM» мы будем говорить лишь о некоторых функциях или элементах PDM и PLM.

Ведя речь о накоплении информации об изделии и реализации ряда PDM- и PLM-функций не на словах, а на деле, обратим внимание читателей, что помимо КД и ТД на стадиях проектирования, производства, модернизации ЖЦ изделия существует еще достаточно специфичный, но присущий высокотехнологичным отраслям пласт информации, связанный с производством. Это программы для станков с ЧПУ.

Кроме организации учета и хранения программ для станков с ЧПУ и автоматизации их «движения» (прохождения контрольных точек в процессе разработки), в системе особое внимание уделено учету обращения программ, внесению изменений, исключению брака. Подробно останавливаться на описании процесса учета изменений, учета версий программ для станков с ЧПУ под управлением системы мы не будем, поскольку бизнес-процессы во многом схожи с процессами учета, хранения, разработки, проведения изменений в КД и ТД. Подробнее рассмотрим следующую ситуацию: программа для станка с ЧПУ в любом случае перед использованием отчуждается от системы. После такого отрыва (записи на внешний носитель) программа загружается в станок. При этом в период между отчуждением и запуском станка по программе возможны следующие варианты:

• несанкционированные и неучтенные изменения с использованием ПК;
• несанкционированные и неучтенные изменения параметров обработки изделия в программе «на станке».

Подобные ситуации ведут к браку, финансовым потерям (порча дорогостоящих заготовок) и прочим негативным последствиям.

С одной стороны, требовать от системы полного контроля над программами для станков с ЧПУ после отчуждения последних — невыполнимая задача. С другой — механизм анализа и контроля безусловно необходим. Несмотря на противоречивость задачи, решение было найдено:

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

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

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

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

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

Взаимодействие административного и технического потоков документов

Говоря о документопотоках предприятия, нельзя забывать об административном документообороте. На рынке программного обеспечения и услуг, связанных с управлением документопотоками в России, наблюдается следующая тенденция:

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

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

Точку зрения классика мы интерпретируем следующим образом:

1. О противоположности:

• на предприятии существуют два разнородных документопотока:

• конструкторско-технологический,
• административный;

• процессы обработки этих потоков — различные;

• алгоритмы автоматизированного управления потоком КД и ТД и потоком приказов/распоряжений, служебных записок, входящей и исходящей корреспонденции совершенно разные.

2. О единстве:

• оба потока в той или иной мере взаимосвязаны. Некоторые примеры:

• входящее письмо от производителя регистрируется и обрабатывается по соответствующим алгоритмам (входящая корреспонденция). Техническое приложение — чертежи и/или изменения от производителя оборудования регистрируются и обрабатываются в соответствии с порядком и правилами работы с КД, то есть в потоке конструкторского документооборота,
• приказ/распоряжение разрабатывается, регистрируется, рассылается и т.д. в соответствии с правилами административного документооборота. При этом КД и ТД, связанная с выполнением этого приказа/распоряжения, разрабатывается в техническом потоке;

• для полной информационной картины не только полезно, но и необходимо:

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

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

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

Компания «СиСофт — Бюро ЕСГ» рассматривает два основных способа решения такой задачи:

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

Как показывает опыт, оба пути имеют право на существование. Та или иная реализация зависит от конкретных условий и детализации задач.

Выбор платформы класса PSIM

Платформа VideoNet – платформа класса PSIM

На ее основе можно создать  решение для безопасности объекта в рамках единой технологической платформы.

VideoNet –  в реальном времени обнаруживает и реагирует на опасные ситуации без прямого участия человека. Мгновенно информирует и оповещает о происшествии. Повышает качество охраны, сокращает время реагирования на тревожные события, помогает быстро принять решение, сократить потери и улучшить дисциплину.

VideoNet является единой средой управления и реагирования

Объединяет в рамках одной платформы систему Видеонаблюдения, СКУД, ОПС, промышленное оборудование, торговые системы и 1С. Совместное использование функционала Видеонаблюдения, СКУД, ОПС и взаимодействие с торговыми системами  –  многократно увеличивает возможности обнаружения различных тревожных событий, дополняет и обогащает процесс охраны информацией и реакциями.

Разграничение прав доступа в системе VideoNet, использование логической инфраструктуры MS Active Directory и системы контроля доступа –  это самый простой пример взаимодействия.  PSIM может выносить решение о доступе по своду правил, используя данные не только одной подсистемы.

Ситуационная осведомленность

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

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

Программное обеспечение класса PSIM должно обладать следующими функциями:

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

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

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

Решение PSIM – не дорогостоящее решение.  Главный фактор при выборе такой системы – это бизнес-потребности заказчика и получение индивидуального решения. Ценность в том, что заказчик получает больше пользы от системы безопасности, это значительное преимущество и при этом сокращение расходов на содержание и обслуживание системы. Принцип модульности – платите только за тот функционал, который необходим. Прозрачность и управляемость — эти два лозунга воплотились в концепции PSIM.

Электронный архив КД и ТД

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

Оцифровка КД и ТД на бумажных носителях

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

Для широких форматов был приобретен сканер Contex, а несколько позже — репрокомплекс Océ. Поставку, инсталляцию, необходимую поддержку, а в дальнейшем и сервисное обслуживание оборудования осуществляет ООО «СиСофт — Бюро ЕСГ».

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

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

Организация процесса хранения

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

При такой организации хранения рано или поздно (по мере накопления информации) наступает день, когда возможности операционных и файловых систем по упорядочению иссякают, а поиск конкретного отсканированного чертежа требует неприемлемого времени. В такой ситуации, как правило, представители ИТ-подразделений рассматривают вопрос об использовании современных СУБД, позволяющих заметно облегчить сложившуюся ситуацию. В настоящее время взоры обращаются к СУБД, которые обычно используются в работе других систем предприятия, например бухгалтерских, складских, ERP-системах и т.д. Как правило, наиболее распространены СУБД Microsoft SQL Server и Oracle. На СПб ОАО «Красный Октябрь» — MS SQL Server.

Разработка системы электронного архива является не только интересной и полезной, но и достаточно трудоемкой задачей. По уже описанным нами причинам были рассмотрены несколько программных продуктов — надстроек над СУБД, которые позволили бы решить стоящие перед предприятием задачи.

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

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

В связи с этим с компанией «СиСофт — Бюро ЕСГ» был заключен договор не только на поставку программного продукта, но и на проведение необходимых работ по его настройке и внедрению.

На этапе создания электронного архива были реализованы:

• централизованный учет и хранение сканированной КД и ТД в единой БД TDMS;
• процессы занесения документации;
• процессы доступа пользователей к разделам информации с учетом прав;
• процессы учета изменений (извещения на изменения, версионность, учет измененных документов).

К великому сожалению, базовый программный продукт TDMS по умолчанию не имеет системы веб-доступа. В связи с этим была поставлена задача организации быстрого доступа к КД и ТД, в том числе из цехов. При этом требования к функционалу рабочих мест, с которых должен осуществляться такой доступ, сводились лишь к возможности быстрого поиска и вывода на экран необходимого чертежа. Результатом выполнения такой задачи стала система веб-доступа к БД TDMS, разработанная компанией «СиСофт — Бюро ЕСГ». При этом на рабочем месте не требуется инсталляция ПО. Работа производится в окне стандартного Internet Explorer.

Разработка и внедрение

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

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

2. Непосредственно реализация системы. Результат: получена система, соответствующая описаниям, приведенным в результатах предыдущего этапа (постановка задачи).

3. Разработка документации (для пользователей и администраторов).

4. Разработка контрольных примеров.

5. Разработка программ и методик обучения.

6. Проведение обучения на контрольных примерах.

7. Сдача в опытную эксплуатацию.

8. Проведение (сопровождение) опытной эксплуатации.

9. Необходимые доработки в рамках ТЗ по результатам опытной эксплуатации.

10. Разработка необходимых нормативных документов (СТП).

11. Приемка в промышленную эксплуатацию.

12. Сопровождение системы.

13. Необходимые модернизации.

Прохождение всех пунктов приведенной последовательности — сложная совместная работа как представителей предприятия, так и компании — поставщика решения. Но есть и исключения. Остановимся на них.

Бытует мнение о том, что сдача-приемка в промышленную эксплуатацию — совместная работа компании — поставщика решения и предприятия. Заметим по этому поводу следующее:

• при прохождении всех пунктов приведенной нами последовательности до пункта «Необходимые доработки в рамках ТЗ по результатам опытной эксплуатации» включительно на предприятии имеется:

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

• при наличии всего перечисленного для регламентации деятельности с использованием системы на предприятии необходимаразработка СТП. Часто на предприятии считают, что разработка СТП должна проводиться силами компании — поставщика решения. Мы против подобного подхода, поскольку компания — поставщик решения выполнит эту работу заведомо хуже представителей предприятия. Участие компании-поставщика может ограничиваться лишь консультациями;

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

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

• технические;
• организационные.

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

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

Управление потоками КД и ТД

Следующей ступенью развития системы была автоматизация управления потоками КД и ТД, в основном в процессе ее разработки. Часто употребляется термин «конструкторский документооборот», что в целом не противоречит понятию «управление потоками КД и ТД», поэтому будем применять оба термина.

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

При автоматизации управления потоками КД и ТД на предприятии особое внимание было уделено процессам разработки в следующих подразделениях:

• АКБ;
• КБ литейного производства;
• конструктора оснастки.

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

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

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

Иными словами, если конструкторы при работе заполняют угловой штамп в 2D-САПР и строят структуру изделия в 3D-САПР, то пусть всё так и остается. При этом информация из САПР передается в систему TDMS (в нашем случае). Если же процессы обмена конструкторской и технологической информацией, управление ее потоками умеет хорошо осуществлять система конструкторского документооборота, реализованная в среде TDMS, то пусть она это и делает с полученной от САПР информацией (файлами, атрибутивными параметрами, структурами, электронными документами и т.д.).

На основании описанного подхода реализовано программное взаимодействие со средствами разработки КД и ТД предприятия — КОМПАС и SOLIDWORKS. Для решения задач интерфейсного взаимодействия системы TDMS с САПР на предприятии используется специальное  приложение «Навигатор СП».

База НТД

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

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

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

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

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

Наличие разнородных САПР в организации обусловлено:

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

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

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

• Зарубежные САПР и PDM/PLM-системы не учитывают принятые в РФ способы производства продукции. Например, в них отсутствуют отечественные механизмы проведения изменений в проектной и технологической документации, алгоритмы технической подготовки производства и многое другое.
  Решить проблемы автоматизации проектной деятельности организации в существующих российских условиях можно следующими очевидными способами:

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

• идти по пути слепого копирования зарубежных стандартов, что неизбежно потребует изменения значительной части устоявшихся в РФ принципов производства продукции и перехода не на один адекватно переведенный стандарт, а на все стандарты, связанные с ним;
• отказаться от адекватного перевода стандартов, адаптируя их к принятым в РФ принципам производства продукции с возможностью передачи информации о структуре изделия зарубежным заказчикам с учетом их требований.
• Зарубежные 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-моделей) и двумерных (дерево документов) структур изделия. Такая интеграция предусматривает наличие горизонтальных перекрестных связей для ускорения навигации между деревьями, скажем, при переходе от трехмерной детали к ее проекции. По этим перекрестным связям также автоматически отслеживаются изменения трехмерной модели или плоского чертежа, и в случае изменения объекта с одной стороны связи автоматически формируется соответствующее уведомление конструктору о несоответствии оригинала порожденному им чертежу с требованием исправления возникшей ситуации. Рассмотрим поэтапно методологию работы конструкторов предприятия после завершения описанных выше процессов планирования.

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

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

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

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

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

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

• Инициатор создает в TDMS извещение на изменения (ИИ), заполняет все необходимые поля карточки.
• ИИ встроенными средствами маршрутизации системы TDMS отправляется для получения регистрационного номера в отделе.
• Сотрудникам отдела СИТД приходит письмо с просьбой выдать регистрационный номер.
• После выдачи регистрационного номера ИИ отправляется обратно инициатору.
• Инициатор создает в системе TDMS электронное административное поручение, при помощи которого извещение отправляется по маршруту согласования.
• После согласования всеми указанными в маршруте лицами инициатору приходит соответствующее письмо, позволяющее приступать к внесению изменений.
• Инициатор создает производственные поручения со ссылкой на извещение и конструкторский документ, в который необходимо внести изменения, и рассылает их отделам-разработчикам для внесения изменений.
• Каждому отделу-разработчику приходит письмо и производственное поручение, в котором указан конструкторский документ, требующий внесения изменений.
• В системе TDMS в соответствии с требованиями приложения А ГОСТ 2.051-2006 генерируются новые версии электронных документов, в которые и вносятся изменения. Все версии документов сохраняются в БД TDMS.
• В карточке учета указываются вносимые в конструкторский документ изменения, а в карточке версионности – новая версия и основание изменений.
• После прохождения маршрута рецензирования процесс внесения изменений в данный конструкторский документ считается завершенным.
• По окончании отработки всех производственных поручений и внесения необходимых изменений работа с извещением завершается, и оно переводится в статус архива.

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

Недавно был сделан очередной шаг к усовершенствованию системы – появился NormaCS PRO. Являясь фактически самостоятельным продуктом, включающим в себя NormaCS, он позволяет создавать и редактировать собственную базу данных в формате NormaCS, а также формировать базы стандартов предприятия, редких документов и прочих внутренних и внешних данных. Эти базы могут быть подключены к сетевой или локальной версии NormaCS. Кроме того, NormaCS PRO обеспечивает возможность создания иерархических комплексов нормативных документов (например, Отраслевые стандарты – Стандарты предприятия – Нормативы филиала – Документы отдела) со ссылками на документы вышележащих уровней и сквозным поиском.

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

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

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

Средства видеоаналитики и настраиваемая логика системы

Интеллектуальные детекторы в автоматическом режиме выявляют и реагируют на подозрительные и опасные события. В VideoNet  для каждой камеры создаются различные комбинации детекторов и зон детектирования с индивидуальными параметрами.

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

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

Технология PSIM дает выбор

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

Система класса PSIM в отличие от системы видеонаблюдения дает полную картину происходящих на объекте событий и предоставляет всю совокупность данных для принятия решения.

Представьте, вам доступна только часть информации для принятия решения, какая вероятность быстро принять верное решение?  Решение PSIM дает ситуационную осведомленность.  Общая картина складывается из множества данных: видео, аудио, СКУД, ОПС, данные от датчиков, оборудования и т.д.

Что дает интеграция СКУД и ОПС в VideoNet

Рассмотрим пример, когда на программном обеспечении VideoNet  уже построена система видеонаблюдения. Что даст интеграция в эту систему СКУД, ОПС  и как улучшится процесс охраны за счет совместного взаимодействия.

VideoNet  – Единая среда управления и реагирования:

• Управляет настройками и обработкой типовых операций (постановка/снятие  с  охраны, обрабатывает тревожные сообщения, запускает реакции)
• Расширяет количество реакций за счет использования программируемой логики.  Это дает большое количество все возможных реакций для любых подключенных  к VideoNet устройств или подсистем.
• Дает решение там, где его не было.
• Например, сработал датчик пожарной сигнализации, помимо стандартной реакции включить сирену, можно настроить трансляцию по камере, отправку сообщения, звукового сигнала  и многое другое.
• Повышает информативность. Проблема ложных срабатываний существует всегда. Тревожным событием станет комплексное событие от различных источников, с настроенными параметрами срабатывания и видеоверификацией  для оператора или охранника.
• Снижает влияние человеческого фактора на процесс охраны.

Решает распространенные задачи:

• Постановка/снятие с охраны
• Поставили объект под охрану или нет – «Я ставил, а оно не сработало»
• Видеозапись, событие в журнале,  отправка сообщения,  время постановки и т.д.
• Принятие решения  – это комплексное событие от разных источников
• Что является реальным тревожным событием?  Решает задачу ложных срабатываний.
• Как и что включается по тревоге.  Программируются реакции и уведомления на тревогу.
• Контроль оператора

VideoNet  позволяет создавать общие правила доступа для разных контроллеров, разных производителей.

• Графики/режимы работы
• Создание групп пользователей
• Создание групп устройств

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

Реализация правил: кого и в какие помещения  впускать, блокировать,  определять в каком помещении находится человек,  контролировать перемещение  сотрудников,  делать различные отчеты –  решает задачи: прошел не по своей карте, прошел «паровозиком», прошел в незакрытую дверь, прошел не в свое время,  взлом и т.д. Использование системы видеонаблюдения совместно со СКУД – повышает информативность и создает доказательную базу.

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

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

• Автоматическому отслеживанию потенциально опасных ситуаций и реагированию на них;
• Отображению происходящих событий в видеоокнах и на графическом плане объекта, в журнале и панели событий;
• Управлению исполнительными устройствами, подключенными к системе: в ручном и автоматическом режиме.

Возможности системы можно расширить двусторонней звуковой связью, используя встроенные микрофоны в видеокамерах или  дополнительные микрофоны и громкоговорители.

Принятие решения и расследование инцидентов

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

Оператор может задать размеры, пропорции искомых объектов, их цвет, скорость, направления движения. В качестве дополнительных  критериев поиска можно выбрать события от  детекторов, искать по типам событий, комбинировать с фильтрами аудиоданных, сообщениями от  различных подсистем, например, СКУД или ОПС.

Среда аналитики – инструмент пост-анализа информации

• Поиск информации в базах данных по запрашиваемым параметрам;
• Одновременный анализ событий по нескольким источникам;
• Отображение результатов запроса в настраиваемых формах представления;
• Генерация отчетов различных видов и форм: расчет рабочего времени, фиксация нарушений графика работы и т. д.

• По видеоданным
• По аудиоданным
• По графическим материалам
• По  текстовым записям
• По  источникам данных:

• От системы видеонаблюдения (СВН)
• От охранно-пожарной системы (ОПС)
• От системы контроля и управления  доступом (СКУД)

Эффективность работы системы видеонаблюдения и  безопасности напрямую  зависит от автоматизации  процессов  с  огромным  потоком  однородной информации.  Платформа VideoNet дает централизованное управление,  большую функциональность, сочетание свойств подсистем, сокращение общих затрат на обслуживание, масштабируемость, независимость от поставщика оборудования. Кроме того, опыт показывает, что система класса  PSIM может уменьшить время отклика на тревожное событие до  75%, для контроля не нужно  привлекать дополнительных сотрудников.