Еще до недавнего времени две подсистемы автоматизации промышленных предприятий: АСУП (системы автоматизации управленческой и финансово-хозяйственной деятельностью, планирования ресурсов предприятия) и АСУТП (системы автоматизации технологических и производственных процессов) развивались обособленно и независимо друг от друга (рис. 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 не запускается в автоматическом режиме?
Технологические службы
Цели: Повышение эффективности процесса, поддержание работоспособности оборудования.
Типичные вопросы:
- Почему перегревается данный насос?
- Что явилось причиной подъем температуры в регуляторе давления?
- Каковы параметры процесса при высоком или низком выходе продукции?
- Какова связь между производственными характеристиками оборудования и стабильностью?
Плановые службы
Цели: Разработка графиков выпуска продукции.
Типичные вопросы:
- Как соотносится текущий коэффициент загрузки оборудования со средним?
- Соблюдается ли график производства?
- Каковы минимальные и максимальные показатели выпуска продукции в час?
- Каков, по сравнению с расчетным, фактический объем сегодняшнего выпуска?
Бухгалтерия
Цели: Контроль и минимизация затрат производства.
Типичные вопросы:
- Есть ли доход от выпуска данного вида продукции?
- Каков текущий уровень потребления сырья и материалов по сравнению с предыдущим месяцем?
- Какова структура себестоимости продукции в этом месяце?