Как объединить АСУП и АСУТП

Надежда Куцевич, ЗАО РТСофт

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

Введение

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

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

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

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

Общие свойства. Рассматриваемые подсистемы являются распределенными. Протоколы локальных сетей и протоколы Internet/Intranet позволяют интегрировать информационные и управляющие потоки в узлах каждой подсистемы. Объединение узлов возможно как в режиме n-tier (равный с равным), так и в режиме клиент-сервер.

Определились категории программных средств, используемых в подсистемах АСУП и АСУТП. Каждая категория в АСУП зависит от степени интеграции систем (см. таблицу 1).

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

визуализация технологического процесса;
сбор данных с различных источников информации по протоколам DDE (Dynamic Data Exchange), OPC (OLE for Process Control) и частнофирменным протоколам;
поддержка языка SQL для создания, удаления, чтения, записи, модификации информации в таблицах баз данных (БД).

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

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

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

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

использование готовых решений для предприятий. В этой связи следует отметить процесс объединения компаний-разработчиков продуктов АСУП и АСУТП (Wonderware и Marcom).

Реляционные БД и БД реального времени

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

производственные процессы генерируют данные очень быстро. Чтобы хранить производственный архив системы, например, с 7500 рабочими переменными, в БД каждую секунду необходимо вставлять 7500 строк. Обычные БД не могут выдержать подобную нагрузку;

объёмы производственной информации настолько велики, что она просто не вмещается в традиционную БД! Например, многомесячный архив завода с 7500 рабочими переменными требует под БД около 1 Терабайта дисковой памяти. Сегодняшние технологии такими объемами манипулировать не могут;

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

Результатом преодоления этих ограничений стало появление класса продуктов, называемых базами данных реального времени (БДРВ). Отмечаются две концепции создания БДРВ: новая независимая разработка БД или разработка БДРВ на основе известных реляционных БД, например, MS SQL Server. Более перспективным представляется второй способ, поскольку, во-первых, он дешевле, а во-вторых, технологичнее (идёт по стопам Microsoft, используя его новые технологии!). В качестве примера реализации БДРВ отметим, например, IndustrialSQL Server (компания Wonderware) и Plant2SQL (Ci Technologies). Основные функции БДРВ, построенные на основе MS SQL Server заключаются в следующем:

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

В настоящее время БДРВ являются продуктами, ориентированными на хранение технологической информации, на обеспечение связи с управленческими данными, на использование уже ставших стандартными в подсистемах АСУП интерфейсов OLE DB, Internet. На рис. 2 показаны информационные потоки. С одной стороны это данные, поступающие из различных технологических источников для сохранения в БД, с другой данные, запрашиваемые потребителями через интерфейс SQL-сервера.

Рис. 2 БДРВ на основе MS SQL Server

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

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

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

использование только РБД, в таблицы которой подсистема АСУТП по SQL-запросам записывает технологические данные; в дальнейшем последние могут быть использованы обеими подсистемами;
использование БДРВ, которые обеспечивают более высокие характеристики регистрации данных и упрощают (без использования SQL) процесс внесения данных в таблицы;
построение комбинированного решения, предполагающего использование БДРВ для технологических первичных данных и таблиц РБД для вторичной информации.

АСУТП и подсистемы АСУП, построенные на технологиях Microsoft

Как уже выше было отмечено, существует устоявшийся набор стандартных протоколов, позволяющий назвать практически любую SCADA-систему открытой. Наибольшее количество SCADA-систем предлагается и развивается их разработчиками на платформе Windows 95/98 или Windows NT. Все они поддерживают технологии Microsoft, в первую очередь, как средство межпрограммного взаимодействия внутри подсистем АСУТП. Не один раз объявлялось, что разработчики SCADA-систем и компания Microsoft имеют одинаковое мировоззрение относительно нового типа производственной среды предприятия будущего и работают вместе над созданием программного обеспечения в масштабе предприятия.

Программное обеспечение подсистем АСУП, разработанное для платформы Windows не могло избежать влияния технологий Microsoft. Именно на их базе построенные каналы связи позволяют обеспечить обмен между рассматриваемыми подсистемами. Стандартные программные протоколы DDE, OLE и OPC могут стать основой интеграции подсистем.

При этом важно отметить, что применение технологий Microsoft не только исключает, а дополняет решения, построенные на основе БД (рис. 3).

О новом классе продуктов

Для организации информационного потока технологических данных в АСУП ряд крупных разработчиков инструментальных систем (прежде всего, систем SCADA) предложили использовать специальный тип программных продуктов, например, VisualFlow компании Envisionlt.

Ключевое назначение пакета VisualFlow объединять разнородные подсистемы (рис.4). Графический объектно-ориентированный инструментарий позволяет через объекты и промежуточные (middleware) мосты организовывать каналы связи с приложениями. Приложения, способные быть источником информации, могут формировать специальные объекты, передаваемые в среду VisualFlow. Там с помощью таблиц и методов на объекте, переданном из источника, выполняются необходимые преобразования. Далее объект передается целевому приложению. Уже сейчас VisualFlow может обеспечить интерфейс для более 120 приложений и баз данных.

Так, для интеграции с системами класса SAP/R3 в пакете VisualFlow определены следующие интерфейсы:

PPPI;
поддержка PI-PCS BAPI;
сертифицированные SAP;
интерфейс общего назначения R3 RFC;
Access 10,000+RFC;
CALL_TRANSACTION RFC;
поддержка IDOC;
поддержка пользовательского ABAP/4;
интерфейс баз данных;
доступ к таблице/полю;
поддержка всех баз данных системы R3.

Но пакет VisualFlow это продукт, способный только интегрировать различные подсистемы. А что интегрировать определяется конкретной задачей обеспечения доступа к технологическим данным как архивным, так и оперативным из приложений АСУП. Разработчик приложения VisualFlow определяет, из каких подсистем принимаются объекты (например, из SCADA-приложений), каким образом полученная через объекты информация преобразуется и передается в целевые подсистемы (например, АСУП). Формирование SCADA-объектов или объектов баз данных реального времени на базе VisualFlow позволяет транспортировать объекты с технологическими данными управленцам.

Выводы

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

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

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

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

21.04.2014