Система паспортизации технологических объектов — различия между версиями

Текущая версия на 17:21, 19 марта 2012

Общие информация и принципы построения

Свидетельство регистрации СПТО

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

В то же время, потребность в описании технологического комплекса на уровне блоков, узлов, систем управления, промплощадок и т.д. стоит очень остро. Пытаясь обойтись "малой кровью" такие описания строят на классификационых схемах ERP-систем. В результате выстраивается красивая иерархия с точки зрения формирования структуры МВЗ, но теряются технологические связки. А уж о технологической целостности и непротиворечивости можно даже и не думать - её поддержание будет слишком дорого.

Вот почему лучшие мировые практики идут не по пути построения технологической НСИ как иерархической структуры внутри ERP-системы, а рекомендуют другие подходы. Классическим примером является стандарт ISA-95, который даёт прямые рекомендации по построению модели оборудования, которая по своей идеологии очень далека от обычной иерархии. Схожего подхода придерживались и мы, когда разрабатывали своё решение по построению технологической НСИ.

Структура описания объекта

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

• Не смотря на принадлежность к НСИ, данные в технологической НСИ меняются гораздо чаще, чем в НСИ ERP-системы, например, т.к. оборудование постоянно находится в эксплуатации и его характеристики могут изменяться при ТО или ремонте.
• Структура параметров, описывающих конкретный технологический комплекс не является статичной, она постоянно меняется при возникновении новых задач управления.
• При наличии в системе линейно-протяжённых объектов (дороги, линии электропередач, трубопроводы и т.п.) система должна работать с километровыми разбивками, иногда множествеными.
• Описание объектов должно обеспечить хранение информации о технологических связях: содержит, входит в состав, обслуживает и т.п., причём для привязки к линейным объектам должна быть связь и по пикетному километру.

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

Разработанный ООО "Компания "ТЕРСИС" программный комплекс "Система паспортизации технологических объектов" - СПТО для корректного описания технологических комплексов использует следующие основные понятия:

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

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

Средства обеспечения непротиворечивости информации

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

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

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

В случае, когда этого недостаточно, мы предлагаем так же и решения класса Complecs Event Processing, которое в безинтерфейсном режиме анализирует вводимые данные и сигнализирует об их отклонениях от статистически вероятного интервала.

Программная реализация

Программный комплекс реализован на платформе СУБД Oacle и в качестве платформы использует портальную платформу нашей разработки Веб-портал конструктор. Система 100% веб-ориентирована, может работать по защищённому протоколу SSL.

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

Для работы внешнего прикладного уровня, если это системы нашей разработки, ничего делать не нужно: они по умолчанию используют СПТО для хранения информации. Для внешних систем есть стандартные инструменты формирования источников данных в виде таблиц, снимков (snapshot) или представлений (view) для доступа к данным, а для ввода данных - развёрнутый API на уровне пакетов СУБД Oracle PL/SQL.

Стандартизация средств управления данными

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

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

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

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

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

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

Построение распределённых информационных структур

Использование стандартной структуры таблиц на уровне СУБД позволяет легко строить многоуровневые структуры данных, перенося данные на тот уровень, где они возникают и в основном используются. Особенно актуально это для холдинговых и распределённых структур.

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

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

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

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

Где найти дополнительную информацию

• Производственная автоматизация
• Технологическая НСИ

Если Вас заинтересовало данное решение, пожалуйста, просто свяжитесь с нашими специалистами.

Сергей Зубарев
Главный инженер проектов

e-mail:
моб. тел. +7 495 980-73-57