CADmaster

Consistent Software СПб/Бюро ESG имеет большой опыт поставки и внедрения как отдельных подсистем комплексного программно-аппаратного решения, так и всей системы инженерно-конструкторского архива и документооборота.

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

Рис. 1. Общая схема системы инженерно-конструкторского архива и документооборота

Когда формируется система электронного архива предприятия, как правило, предстоит решить две основные задачи:

• создать архив проектных данных, разработанных в «традиционном» виде: на бумажных носителях или на микрофильмах и микрофишах;
• создать архив проектных данных, разрабатываемых в электронном виде.

Для решения первой задачи необходима подсистема сканирования, позволяющая перевести в электронный вид информацию, содержащуюся на «традиционных» носителях. Чтобы оптимизировать этот процесс, как правило, одновременно используют две подсистемы: узкоформатного и широкоформатного сканирования. Так, например, в ЦКБ МТ «Рубин» для узкоформатного сканирования применяются поточные промышленные сканеры Fujitsu, позволяющие сканировать документы со скоростью до 90 листов в минуту (формат — до А3 включительно), а при широкоформатном — сканеры Vidar, Contex и Oce TDS800.

Несмотря на бурное развитие информационных технологий, традиционные чертежи на бумажных носителях весьма востребованы и говорить о полностью «безбумажных» технологиях пока рано. Следовательно, современная система инженерно-конструкторского архива и документооборота обязательно должна комплектоваться подсистемой тиражирования, которая в свою очередь подразделяется на подсистемы тиражирования узкоформатной и широкоформатной документации. ЦКБ МТ «Рубин» использует для этой цели плоттеры Oce TDS800 и Oce 9700, а ПКБ ФГУП «Севмаш» — плоттер Oce TDS800.

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

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

• сравнительно небольшой объем (по сравнению с общим объемом хранения);
• высокая производительность.

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

• инструменты разработки документов и проектных данных в электронном виде;
• средства управления аппаратной частью системы архива и документооборота: устройствами сканирования, хранения и тиражирования;
• программное обеспечение для решения задач системы электронного архива и документооборота, связанных со спецификой предприятия. К примеру, ЦКБ МТ «Рубин» использует программные пакеты серии Raster Arts (разработка компании Consistent Software);
• программные интерфейсы, обеспечивающие взаимодействие средств подсистемы пользовательских приложений;
• программные интерфейсы, обеспечивающие взаимодействие системы архива и документооборота с другими программными комплексами предприятия (ERP-системами, системами календарного планирования, финансовыми, складскими, бухгалтерскими и иными программами).

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

Пути реализации системы управления инженерно-конструкторским архивом и документооборотом

Системы инженерно-конструкторского архива и документооборота можно классифицировать по различным признакам — типу СУБД, языкам написания приложений, архитектуре и т.д. Мы же воспользуемся другим критерием, разделив все системы, предлагаемые сегодня российскому пользователю, на две большие группы: системы «плоского архива» и объектно-ориентированные системы.

«Плоский архив»

Идеология создания этих систем подразумевает работу «в плоскости»: пользователь получает информацию о зарегистрированных объектах в виде плоской таблицы; информация о структуре изделия или не отображается вовсе, или не отображается наглядно. Как правило, для просмотра такой информации требуются дополнительные приложения (редакторы спецификаций и т.д.).

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

И, наконец, еще один важный изъян «плоских» систем: жесткая привязка к конкретному роду деятельности, приемлемая только для узкоспециализированных организаций. Если предприятие осуществляет полный цикл производства (от проектирования до реализации проекта) и работает в нескольких разнородных отраслях, оно просто не сможет обойтись одной лишь «машиностроительной», «строительной», «проектной», «складской» или «административной» системой.

Объектно-ориентированная среда TDMS

Для начала — несколько слов об отличительных особенностях объектно-ориентированных систем:

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

Опыт подсказывает, что наиболее перспективной объектно-ориентированной системой является TDMS, общая структурно-функциональная схема которой показана на рис. 2.

TDMS можно представить в виде трехуровневой модели. На нижнем уровне размещаются картотека хранимых объектов, справочники и классификаторы, на среднем — система архива, а на верхнем — система управления потоками проектных данных. Все три уровня тесно взаимодействуют с имеющимися на предприятии аппаратными средствами хранения, ввода и тиражирования, а также с программными средствами создания проектных данных и документов в электронном виде.

Рис. 2. Общая структурно-функциональная схема системы TDMS

Функции архива и документооборота

Электронный архив TDMS обеспечивает выполнение следующих функций:

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

Система управления потоками проектных данных TDMS позволяет осуществить:

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

Особенности TDMS. Примеры реализации

Чтобы избежать излишнего «теоретизирования», рассмотрим особенности TDMS на конкретных примерах.

Объектный метод

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

• атрибуты (поля карточек объектов);
• формы ввода (карточки объектов);
• типы файлов объектов;
• возможные связи одних объектов с другими (например, для наглядного древовидного отображения структуры проекта указывается, что в состав объекта «Проект» могут входить объекты «Изделие», в объект «Изделие» — объекты «Детали», в объект «Деталь» — объекты «Чертеж», «Спецификация» и т.д.);
• статусы объекта, то есть перечень его возможных состояний в процессе разработки («В разработке», «Разработан», «На проверке», «На доработке», «На согласовании», «На утверждении», «В архиве» и т.д.);
• команды, доступные для выполнения тем или иным пользователем в зависимости от его роли и текущего статуса объекта в процессе разработки. Например, пользователь, которому присвоена роль «Разработчик» в группе «Конструкторы», имеет право выполнить четко определенный набор команд (редактировать объект и присвоить ему статус «Разработан» с автоматической маршрутизацией объекта со всем его составом — входящими объектами, файлами и т.д.).

Многоуровневая иерархическая модель

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

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

Классификаторы

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

Рис. 3. Фрагмент классификатора документации по помещениям

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

Возможности настройки

Система TDMS с успехом работает в самых различных отраслях: судостроении, машиностроении, строительстве, в лесопромышленных комплексах. Встроенный механизм импорта и экспорта настроек системы позволяет решить проблему создания единой инженерно-конструкторской системы архива и документооборота на предприятиях, подразделения которых заняты весьма разнородной деятельностью (машиностроение, строительство, склад, административный документооборот и т.д.).

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

Внешние и внутренние обработчики объектов

Одним из важных преимуществ, получаемых пользователем TDMS, является возможность определять наборы команд для каждого типа объектов. Набор команд, которым может оперировать пользователь, определяется предоставленными ему правами доступа. Возможность применить к объекту ту или иную команду зависит также от статуса объекта: его реального состояния, стадии разработки.

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

• встроенные языки программирования (JS и VBS);
• открытый API;
• встроенный в среду TDMS редактор программного кода обработчиков (создание любых обработчиков без редактирования программного кода TDMS);
• встроенные в среду TDMS элементы объектно-ориентированной среды программирования (формы, кнопки, поля, конструктор выражений, автоматическая проверка синтаксиса и т.д.);
• возможность подключения любых внешних модулей (библиотек *.dll), осуществляемая без редактирования программного кода TDMS из соответствующего окна настроек. Окно настроек доступно администратору;
• подключаемая к внешним средам программирования (VB и C++) библиотека API TDMS, позволяющая реализовывать любые внешние приложения, взаимодействующие с TDMS, и интерфейсы с любыми программными средствами — для создания единого информационного пространства предприятия;
• поставляемое в комплекте с системой руководство разработчика с описанием коллекций, объектов, свойств, методов и функций. Примеры на VBS (для создания обработчиков встроенным редактором), а также на VB и C++ (для создания внешних приложений, взаимодействующих с TDMS через API).

Приведем логику работы некоторых команд-обработчиков, реализованных в среде TDMS в ПКБ ФГУП «Севмаш» (по проекту «Приразломная»).

Команда формирования комплекта документов по запросу смежных организаций:

• заполнение бланка заявки на комплект документов от ЦКБ МТ «Рубин» (составляется в MS Excel);
• передача бланка заявки на ФГУП «ПО Севмаш»;
• автоматизированное формирование комплекта документов заявки в среде TDMS (по полям бланка заявки);
• автоматическая выгрузка из среды TDMS комплекта документов по заявке;
• передача комплекта документов в ЦКБ МТ «Рубин».

Команда формирования задания в Центр печати:

• формирование в среде TDMS объекта «Задание на печать»;
• «присоединение» вложенных объектов-документов (результат запроса по базе TDMS);
• автоматическая маршрутизация задания на печать;
• вывод объектов «Документ», вложенных в объект «Задание на печать» (осуществляется сотрудником Центра печати — пользователем TDMS).

При создании объекта «Задание на печать» использовались руководящие документы, регламентирующие порядок и форму подачи заявки в Центр печати ПКБ ФГУП «Севмаш». Карточка (форма ввода) объекта «Задание на печать» повторяет в электронном виде бланк ранее принятой «бумажной» заявки на печать и имеет те же поля.

Открытый API

Интеграция со средствами разработки

Приведем несколько примеров интеграции TDMS со средствами разработки проектных данных. Суть работы интерфейса с AutoCAD — автоматическая передача полей карточки объекта TDMS (проектного документа, чертежа и т.д.) в поля углового штампа файла AutoCAD (*.dwg). Сравнительно недавно реализован интерфейс с системами трехмерного моделирования Solid Edge, SOLIDWORKS, Unigraphics, Autodesk Inventor: в дерево объектов TDMS передаются деревья сборок перечисленных систем. Переданные сборки можно открывать для просмотра и редактирования.

Интеграция с системами планирования Primavera и MS Project

Любая система управления потоками проектных данных должна обеспечивать возможность календарного планирования ресурсов и процессов. С другой стороны, система календарного планирования представляет собой достаточно сложное программное средство. Поскольку в мире существует практически общепризнанный стандарт в области реализации систем планирования — Primavera и MS Project, — созданы интерфейсы взаимодействия TDMS с этими системами. Суть интеграции сводится к синхронизации состояния (статуса) объектов электронного архива и состояния задач по разработке этих объектов, описанных в системе календарного планирования. Момент утверждения соответствующего объекта (документа) является временем окончания запланированного этапа работ.

Взаимодействие с аппаратными средствами

Взаимодействие с подсистемой сканирования

Взаимодействие TDMS с аппаратными устройствами подсистемы сканирования осуществляется с использованием программы RasterID (разработчик — компания Consistent Software), выполняющей следующие группы функций:

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

Схема работы интерфейса, осуществляющего взаимодействие между TDMS и аппаратными средствами подсистемы сканирования, приведена на рис. 4.

Рис. 4. Схема работы интерфейса между RasterID и TDMS

Логика работы интерфейса сводится к следующему:

• RasterID осуществляет управление сканирующими устройствами подсистемы сканирования;
• после улучшения качества изображений (если в таком улучшении есть необходимость) осуществляется процесс распознавания полей углового штампа;
• поля углового штампа импортируются TDMS (в карточку соответствующего объекта, который может быть автоматически создан в указанном месте дерева объектов);
• файл растрового изображения «присоединяется» к объекту (записывается в базу).

Взаимодействие с подсистемой тиражирования

Наиболее простой (но не всегда приемлемый на крупных предприятиях) способ взаимодействия с аппаратными средствами подсистемы тиражирования и TDMS реализуется по следующей логике:

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

Взаимодействие с подсистемой хранения. Управление хранилищами данных

При создании рассматриваемых систем серьезное внимание нужно уделить тому, как будет организовано хранение информации. Средствами СУБД MS SQL Server и Oracle файлы объектов TDMS могут записываться в ячейки таблиц в бинарном виде. Такой способ размещения тел документов в TDMS поддерживается и может быть применен при сравнительно небольших объемах хранимой информации или на начальных этапах формирования архива. Работа с большим массивом данных будет сопряжена с немалыми сложностями: база MS SQL Server (схема Oracle) значительно увеличивается в объеме, требуется задействовать всё больше ресурсов сервера, производительность системы падает, возрастает вероятность сбоев.

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

При настройке службы файловых серверов TDMS можно указать любое число хранилищ, их быстродействие, максимальный объем и т.д. Через интерфейс менеджера файловых серверов доступны все функции тестирования и управления службой. На рис. 5 показаны схема организации хранения, реализованная в ПКБ ФГУП «Севмаш» по проекту «Приразломная», и интерфейс менеджера управления файловыми серверами при использовании функции переноса файлов между хранилищами с учетом алгоритма автоматической оптимизации по частоте обращения. При инициализации этой функции все файлы, обращения к которым происходят нечасто, переносятся в область долгосрочного архивного хранения (роботизированную DVD-RAM библиотеку Plasmon D480). Файлы, интенсивность доступа к которым выше, автоматически распределяются по оперативным хранилищам.

Рис. 5. Схема организации хранения, реализованная в ПКБ ФГУП «Севмаш»

Другие функции

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

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

Основные этапы и логика успешного внедрения

При всем многообразии областей, где может применяться TDMS, на сегодня уже сформировалась универсальная логика успешного внедрения:

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

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

Скачать статью в формате PDF — 195.1 Кбайт