Что такое документоцентричный подход

Клиентоцентричность государственного управления обсудят на ПМЭФ-2021

Наши проекты

Контакты

Рассылки «Ведомостей» — получайте главные деловые новости на почту

Ведомости в Facebook

Ведомости в Twitter

Ведомости в Telegram

Ведомости в Instagram

Ведомости в Flipboard

Решение Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор) от 27 ноября 2020 г. ЭЛ № ФС 77-79546

Учредитель: АО «Бизнес Ньюс Медиа»

И.о. главного редактора: Казьмина Ирина Сергеевна

Рекламно-информационное приложение к газете «Ведомости». Зарегистрировано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор) за номером ПИ № ФС 77 – 77720 от 17 января 2020 г.

Любое использование материалов допускается только при соблюдении правил перепечатки и при наличии гиперссылки на vedomosti.ru

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

Сайт использует IP адреса, cookie и данные геолокации Пользователей сайта, условия использования содержатся в Политике по защите персональных данных

Все права защищены © АО Бизнес Ньюс Медиа, 1999—2021

Любое использование материалов допускается только при соблюдении правил перепечатки и при наличии гиперссылки на vedomosti.ru

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

Все права защищены © АО Бизнес Ньюс Медиа, 1999—2021

Решение Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор) от 27 ноября 2020 г. ЭЛ № ФС 77-79546

Учредитель: АО «Бизнес Ньюс Медиа»

И.о. главного редактора: Казьмина Ирина Сергеевна

Рекламно-информационное приложение к газете «Ведомости». Зарегистрировано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор) за номером ПИ № ФС 77 – 77720 от 17 января 2020 г.

Сайт использует IP адреса, cookie и данные геолокации Пользователей сайта, условия использования содержатся в Политике по защите персональных данных

Источник

Три шага к дата-центричной архитектуре

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

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

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

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

Принципиально новая архитектура, свободная от данных проблем, должна быть построена на следующих принципах [1]:

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

Путь к дата-центричной архитектуре

На практике переход к архитектуре, ориентированной на данные, предполагает выполнение ряда шагов.

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

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

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

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

Платформа «АрхиГраф»

Платформа «АрхиГраф» предназначена для создания логической витрины данных и построения кластера физического хранения информации под управлением онтологической модели. Главная идея платформы состоит в объединении всей корпоративной информации в рамках одной или нескольких онтологических моделей. Основным хранилищем подобных моделей являются графовые базы данных класса RDF triple store, обеспечивающие богатые возможности поиска по графам и управления ими при помощи языка SPARQL. Однако такие СУБД довольно медленны и не предназначены для хранения больших объемов данных. С другой стороны, традиционные средства, такие как реляционные и документоориентированные СУБД, обеспечивают быструю обработку больших объемов информации за счет развитых инструментов оптимизации, включая индексацию и сегментацию таблиц и коллекций объектов. Требуется промежуточный слой физического хранения данных в реляционных базах данных и NoSQL-базах, которые с точки зрения приложений выглядели бы как графовые СУБД. Это позволит совместно использовать преимущества способов управления данными, целостности структуры и состава данных, характерные для онтологий и графовых СУБД, с совершенными механизмами оптимизации производительности традиционных хранилищ.

Рис. 1. Структура платформы «АрхиГраф»

В платформе «АрхиГраф» имеется промежуточный слой (рис. 1), позволяющий распределить данные между множеством кластеров реляционных и NoSQL СУБД, а также хранилищ Hadoop, управлять их распределением и применять различные способы оптимизации скорости доступа к данным. Доступ к данным со стороны приложений осуществляется через программные интерфейсы REST, SPARQL, GraphQL, очереди обмена сообщениями RabbitMQ, Kafka, с помощью протокола Websocket.

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

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

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

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

Рис. 2. Кластеризация платформы «АрхиГраф» и хранилищ данных

Сервисы «АрхиГраф» выполняются в контейнерах под управлением Kubernetes, что обеспечивает практически неограниченное масштабирование при росте нагрузки (рис. 2). Хранилища данных могут также кластеризоваться с помощью своих собственных средств, таких как pgpool или Stolon для СУБД Postgres, причем к платформе «АрхиГраф» можно подключить любое количество подобных кластеров.

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

Сценарии использования

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

Рис. 3. Процесс сбора и анализа информации в логической витрине данных

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

Рис. 4. Конвейер обработки событийных данных, поступающих в систему

В качестве примера другого сценария можно привести конвейер по связыванию разнородной событийной информации, поступающей из разных источников (рис. 4), — такие задачи возникают в системах информационного обмена или сбора отчетности, а также в ситуационных центрах. Для обработки разнообразных потоков данных создаются компоненты, в реальном времени собирающие данные от источников и преобразующие их в соответствии с информационной моделью при помощи специальной метамодели, которая описывает соответствие элементов разных информационных структур. Такая метамодель позволяет определить широкий спектр преобразований — от разбора JSON-коллекций и XML-файлов до импорта таблицы Excel. После получения графа с набором информационных объектов и их свойств, поступивших в составе обрабатываемого сообщения, к нему применяются правила валидации, записываемые в синтаксисе SHACL (Shapes Constraint Language). После этого нужно применить следующий набор правил, которые обновят общесистемное хранилище данных в соответствии с поступившей информацией, — здесь также используется SHACL. Использование логически корректных правил позволяет гарантировать логическую целостность и корректность информации в общесистемном графе.

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

2. Dave McComb. The Data-Centric Revolution: Restoring Sanity to Enterprise Information Systems. O’Reilly, 2019.

Источник

Дата-центричное и интегрированное решение EPLAN для полного жизненного цикла АСУ ТП

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

Кирченов Алексей Юрьевич, директор EPLAN Россия

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

Еще одно существенное отличие тематики АСУ ТП заключается в том, что для создания полезной информационной модели (такой модели, от использования которой владелец\оператор объекта получит существенные выгоды) требуется работа в единой модели нескольких игроков — генподрядчика, субподрядчиков, монтажных и пусконаладочных организаций. В самом деле, большая часть оборудования АСУ ТП устанавливается в шкафах. Именно подрядчики, собирающие шкафы, выбирают как конкретные устройства (с заказным номером и техническими характеристиками), так и их «экземпляры» — в терминологии EPLAN это конкретное изделие с серийным номером, датой следующего обслуживания\поверки.

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

У компании Intergraph есть такое решение — это SmartPlant Foundation. Благодаря своей дата-центричности среда EPLAN может быть без проблем интегрирована SPF. Для быстрой и беспроблемной интеграции необходим партнер, обладающий компетенциями как в EPLAN, так и в Intergraph. Такой партнер есть — это компания Ulysta. Решение uConnect этой компании готово к интеграции с EPLAN. Сроки и стоимость такой интеграции определяются в зависимости от объема данных, которые необходимо публиковать в SPF. Если центральной базы данных нет, это не проблема. Среда EPLAN обладает мощными инструментами интеграции, начиная от стандартных инструментов импорта-экспорта данных в форматах TXT, CSV, XML, XLS и интеграции с базами данных (Access, SQL) и заканчивая мощным API, дающим внешним приложениям доступ к любым инженерным данным, содержащимся в проекте EPLAN.Среда EPLAN «умеет» автоматически создавать ссылки на свои объекты для быстрого открытия этих объектов из внешних приложений, а так же может хранить ссылки на внешние объекты для их быстрого открытия в сторонних приложениях.

EPLAN — глобальная компания с собственными офисами в 51-й стране мира.

Еще более чем в 20 странах мы представлены нашими партнерами. EPLAN работает в объектно-ориентированной парадигме с момента своего основания — уже более 32 лет, и за эти годы превратился в лучшее в своем классе решение, доминирующее в целом ряде отраслей. Последние несколько лет фокусами развития среды EPLAN являются дата-центричный подход и междисциплинарная интеграция — то что в ряде отраслей именуют мехатроникой — единым процессом, объединяющим электрику, механику и программное обеспечение. В среде EPLAN проект представляет из себя базу данных в особом проприетарном формате. Любые данные, вносимые в систему, индексируются в базе данных проекта и увязываются между собой в контексте этого проекта. Данные могут вноситься как из отдельных файлов (таблиц excel, csv, xml, txt), так и баз данных (Access, SQL, Oracle). При этом существуют механизмы проверки данных — при повторном внесении данных они сравниваются с уже внесенными и контролируется изменение данных. Как только необходимый объем данных внесен в базу данных проекта, среда EPLAN автоматически сгенерирует требуемую документацию. При создании документов пользователем в среде EPLAN данные из документов автоматически индексируются в базе данных проектов и остаются связанными между собой. Внешние документы (руководства по эксплуатации, паспорта приборов) индексируются в системе и становятся доступны пользователю. Пара кликов позволяет перейти с генплана на монтажную документацию по конкретному датчику, посмотреть его manual, перейти на P&ID, затем на схему внешних проводок (чтобы увидеть, как подключен датчик), затем, например, на кабельный журнал (непосредственно на кабель, которым подключен этот датчик). При изменении схем информация автоматически обновляется в базе данных проекта. Таким образом содержимое документов доступно для обработки и автоматического изменения в контексте проекта.

Наиболее эффективным инструментом построения единой информационной модели АСУ ТП является работа в едином формате EPLAN.

При работе с подрядчиками\субподрядчиками в формате EPLAN им направляется техническое задание и шаблон проекта (либо частичный проект EPLAN). ZW1 — это резервная копия проекта, единый файл архива, содержащий все необходимые настройки (например, кодирования оборудования, нумерации проводов, кабелей и устройств), рамки, структуру и формы отчетов. Как правило, проверка входящих проектов может быть автоматизирована, а детальный отчет по требуемым доработкам создан автоматически. После приемки проект, как правило, индексируется в системе управления инженерными данными, а частичные проекты объединяются в единый проект. Тематика АСУ ТП кардинально отличается от, например, строительства тем, что решения на 100% составляются из покупных изделий. Их не надо конструировать, надо просто взять и соединить между собой. Поэтому наличие надежного источника актуальной информации об изделиях является обязательным условием производительной работы в дата-центричной среде. В EPLAN Data Portal пользователи могут скачать или сконфигурировать свое изделие, получая как его схему подключения, техническую информацию (руководства по эксплуатации, паспорта приборов). В будущем все важнее будет становиться наличие в цифровой форме информации по надежности (MTBU) и эксплуатации (сроки поверок\замен) изделий. EPLAN Data Portal готов к предоставлению такой информации. EPLAN — важная часть Индустрии 4.0.Формат проектов EPLAN используется в лидирующих проектах по созданию производства будущего, таких как SmartFactory KL.

Источник: ©EPLAN Software & Service

Источник