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

Рис. 1. Основные подсистемы автоматизации на предприятии

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

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

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

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

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

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

Сходство и различие систем

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

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

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

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

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

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

Базы данных

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

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

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

1. Сохранение некритичной ко времени информации в Microsoft SQL Server. В то время как вся технологическая информация сохраняется в специальном формате.

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

3. Поддержка целостности данных для обеспечения записи больших объемов информации без потерь.

4. Добавление в Microsoft SQL Server свойств сервера реального времени.

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

Рис. 2. База данных реального времени на основе Microsoft SQL Server

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

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

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

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

Специальные технологии

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

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

Рис. 3. Обобщенная схема взаимодействия двух типов служб

Новый класс продуктов

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

Рис. 4. Возможности интеграции VisualFlow

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

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

  • интерфейс PPPI (PI-PCS BAPI);
  • интерфейсы, сертифицированные компанией SAP (R/3 RFC, Access 10,000+RFC, CALL_TRANSACTION RFC, IDOC, ABAP/4);
  • интерфейс баз данных (доступ к таблице/полю и поддержка всех баз данных R/3).

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

Выводы

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

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

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

Об авторе

Надежда Куцевич — менеджер компании RTSoft по SCADA-системам. С ней можно связаться по электронной почте по адресу: nak@rtsoft.msk.ru


Управление производством

Цель: Обеспечить выполнение производственного плана в соответствии с запланированным объемом производства, затратами и качеством продукции.

Типичные вопросы:

- Соответствует ли выпуск плановым показателям? Где возникают узкие места?

- Что является причиной задержек?

- Соответствует ли реальная себестоимость расчетной?

- Каковы отклонения производственных показателей?

Службы контроля

Цель: Оптимизация процесса, соблюдение правил техники безопасности.

Типичные вопросы:

- Стабилен ли данный контур управления?

- Почему сработал данный предохранительный механизм?

- Каким образом вчерашние изменения повлияли на сегодняшнюю производительность?

- Почему стан № 5 не запускается в автоматическом режиме?

Технологические службы

Цели: Повышение эффективности процесса, поддержание работоспособности оборудования.

Типичные вопросы:

- Почему перегревается данный насос?

- Что явилось причиной подъем температуры в регуляторе давления?

- Каковы параметры процесса при высоком или низком выходе продукции?

- Какова связь между производственными характеристиками оборудования и стабильностью?

Плановые службы

Цели: Разработка графиков выпуска продукции.

Типичные вопросы:

- Как соотносится текущий коэффициент загрузки оборудования со средним?

- Соблюдается ли график производства?

- Каковы минимальные и максимальные показатели выпуска продукции в час?

- Каков, по сравнению с расчетным, фактический объем сегодняшнего выпуска?

Бухгалтерия

Цели: Контроль и минимизация затрат производства.

Типичные вопросы:

- Есть ли доход от выпуска данного вида продукции?

- Каков текущий уровень потребления сырья и материалов по сравнению с предыдущим месяцем?

- Какова структура себестоимости продукции в этом месяце?