Всем привет! Тут уважаемые коллеги уже много раз писали о различных инструментах и технологиях платформы ZIIoT для работы с промышленными данными и создания приложений. Но как-то руки пока не доходили до одного из самых важных ее компонентов — единой объектной модели (ЕОМ). В этой статье я исправлю это недоразумение и расскажу, как реализована концепция ЕОМ у нас и как работает наш инструмент для графического конфигурирования моделей — Zyfra Graphic Object Designer. Меня, кстати, зовут Александр Пучков, я ведущий владелец продуктов в компании «Цифровая индустриальная платформа», которая занимается развитием отдельной модификации ZIIoT для нефтегазовой и нефтехимической отраслей – ZIIoT Oil&Gas – и приложений на ее основе.

Что в имени твоем, ЕОМ?

Прежде чем начать разговор про ЕОМ, имеет смысл представить, хотя бы коротко, саму платформу ZIIoT Oil&Gas. Прежде всего, это набор сервисов для сбора, обработки, систематизации и хранения промышленных данных. Заодно это и среда для разработки производственных и бизнес-приложений, которые этими данными впоследствии «кормятся». Миссия же платформы, как бы пафосно это ни звучало, — облегчить промышленникам процесс цифровизации, сделав разработку и внедрение прикладных решений проще, дешевле и быстрее.

В абсолютном большинстве случаев в промышленности (нефтегаз не исключение), приходится иметь дело с приложениями, которым необходимы данные сразу из нескольких источников. Эти данные зачастую распределены по разным БД, большинство из которых — реляционные. Дружба приложений с такими базами данных строится сложно и обходится предприятиям очень дорого. Думаю, что проблемы всем знакомы: это дублирование данных, многочисленные интеграции, необходимость в прокачанных спецах для поддержки разрозненных моделей данных в ИТ-системах, невозможность персонализированного контроля работы с данными и прочее. Все это выливается в увеличение количества часов оплачиваемого рабочего времени разработчиков. На организацию доступа приложений к реляционным БД может уходить до трети времени разработки. Причем мир движется к тому, что приложений в проме будет становиться только больше, а следом будет становиться больше возни с интеграциями, а также будет больше затрат. Не очень соответствует миссии платформы и желаниям бизнеса, да? По этой причине мы предпочли реляционному моделированию объектное и реализовали в ZIIoT Oil&Gas концепцию единой объектной модели.

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

Рисунок 1. Роль ЕОМ в платформе ZIIoT Oil&Gas
Рисунок 1. Роль ЕОМ в платформе ZIIoT Oil&Gas

Что мы получили от реализации концепции ЕОМ:

  • единый подход к проектированию интеграций в платформе;

  • единство справочников и поддержку процессов в единой модели данных для приложений;

  • унификацию взаимодействия различных ИТ-систем.

Еще более приятной жизнь промышленных разработчиков делает встроенный в платформу графический конфигуратор ЕОМ – Zyfra Graphic Object Designer (сокращенно Z-GraphOD), более известный в нашей команде под кодовым названием «ЗИГОД» от аббревиации официального именования системы (созвучие кодового названия со словом «зигота» не случайность).

ЗИГОД против таблиц

По сути, Zyfra Graphic Object Designer – это инструмент построения мнемосхем типа PI ProcessBook, однако одновременно с отрисовкой мнемосхем он еще и автоматически конфигурирует единую объектную модель. За счет простоты в использовании — построение идет по типу P&ID-диаграмм — любой специалист (даже без столетнего опыта работы) может быстро освоить его функционал и штамповать мнемосхемы и конфигурировать ЕОМ в разы быстрее, чем при табличном моделировании. Для бизнеса это тоже хорошо: ускоряется разработка, повышается качество приложений, сокращается время на обучение сотрудников и затраты на поддержку единой объектной модели.

Процесс конфигурирования ЕОМ через Zyfra Graphic Object Designer состоит из трех этапов.

Первый этап: формирование классификатора

На этом этапе мы проводим анализ предметной области предприятия и создаем необходимые библиотеки классов (материалов, оборудования, процессов и пр.). Они позволят нам в дальнейшем ускорить тиражирование объектов внутри моделей, которые мы потом будем конфигурировать. Так как платформа ZIIoT Oil&Gas имеет четкий нефтегазовый профиль и уже используется, для предприятий нефтепереработки и у нас есть готовые библиотеки — «из коробки».

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

Второй этап: конфигурирование моделей

Формирование моделей, как я сказал раньше, идет по типу P&ID-диаграмм (piping and instrumentation diagram), то есть диаграмм, показывающих связь технологического оборудования и приборов, а также последовательность операций для реализации того или иного процесса. Проще некуда: цепляем мышкой нужные классы из библиотеки, переносим их на проектную область, располагаем в правильной последовательности, связываем между собой и таким образом обеспечиваем единство внутри модели данных. Как это выглядит, показал на картинке ниже.

Рисунок 2. Конфигурирование моделей по типу P&ID-диаграмм в Z-GraphOD
Рисунок 2. Конфигурирование моделей по типу P&ID-диаграмм в Z-GraphOD

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

Третий этап: обеспечение трансфера данных из ЕОМ в приложения

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

Бизнес-эффекты

Что важно для любой коммерческой разработки? Правильно: сроки, стоимость разработки, издержки на поддержку. В общем-то, наша концепция ЕОМ влияет на все эти показатели:

  • оптимизирует сроки создания продуктов на платформе ZIIoT Oil&Gas за счет сокращения интеграций и использования данных;

  • снижает стоимость разработки и поддержки ЕОМ — не нужно нанимать дополнительно специалистов, с задачей без труда справляются аналитики;

  • сокращает затраты на создание витрин данных за счет единства модели данных и справочников НСИ;

  • гарантирует прозрачность процесса разработки и аудит ответственности — ничего задним числом в ЕОМ сделать невозможно, все действия контролируются.

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

На этом у меня пока все. На ваши вопросы с радостью отвечу в комментариях.

Комментарии (0)