СПКД123 / СПДК / Задачи АСУТП / Лекция . Операционные системы реального времени

Лекция 6. Диспетчерские пункты АСУТП. Архитектура программных комплексов

Содержание лекции:

• Что такое диспетчерское управление

• SCADA и MES – инструменты диспетчерского управления

• Направление развития и характеристики типовых ДП АСУТП

• Общие принципы построения программных комплексов ДП 

• Анализ качественных характеристик ДП АСУТП

1. Что такое диспетчерское управление

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

2. ^ SCADA и MES – инструменты диспетчерского управления

Вернемся к разделению функций диспетчерского управления на два класса: управление оборудованием (технологией) и управление поставками, или собственно деятельностью предприятия. С точки зрения автоматизации, выделяются отдельно системы на управление оборудованием, отдельно на управление потоками-поставками. Управление оборудованием относится к задачам систем класса АСУТП, или SCADA-систем (английская аббревиатура – ^ Supervisory Control and Data Acquisition - диспетчерское управление и сбор данных). Это:

• Измерение и контроль значений физических величин и состояния машин и механизмов;

• Выдача команд управления и регулирования непосредственно на машины и механизмы («остановить/запустить», «открыть/закрыть»);

• Задачи выполняются в реальном времени, время отклика (цикл опроса данных, обновления информации и т.п.) – секунды, минуты.

Управление производственной деятельностью предприятия – задачи, относящиеся по современной терминологии к классу MES (от англ.Manufacturing Execution Systems - системы управления производством, производственные исполнительные системы):

• Планирование производственной деятельности в физическом (не денежном) измерении;

• Измерение, сбор, контроль, учет и анализ параметров производственной деятельности;

• Оценка эффективности деятельности предприятия по выбранным критериям;

• Выдача команд нижестоящим подразделениям в виде производственных заданий.

Важной особенностью диспетчерского управления является необходимость интеграции двух представленных классов задач диспетчерского управления – SCADA и АСДУ (MES), а также интеграции с ERP-системами предприятия. ERP-системы традиционно не автоматизируют комплекс диспетчерских задач, прежде всего вследствие его специфичности, наличия компоненты реального времени, большого числа модельных и расчетных процедур и общей доли обработки информации о физических процессах. Данное разделение функций полностью соответствует модели автоматизации по стандарту ISO95.

3. ^ Направление развития и характеристики типовых ДП АСУТП

За 20 лет развития индустрии автоматизации (с середины 70-х до середины 90-х гг.) произошел переход от заказных программно-технических комплексов (с преобладанием технической составляющей, причем ТС также разрабатывались на заказ, в лучшем случае с использованием универсальной элементной базы) – к внедрению настраиваемых на конкретный объект автоматизации тиражируемых, универсальных решений. При этом техническая и программная платформа диспетчерских пунктов независимы (выбирается тип архитектуры вычислительного комплекса (RISC, Intel), одна из операционных систем (версии UNIX, Windows, QNX и др.), тиражируемый программный комплекс АСУТП для выбранной платформы (более 30)). В настоящее время на рынке автоматизированных систем управления технологическими процессами присутствует большое количество тиражируемых систем, решающих все основные задачи, предъявляемые к системам управления «верхнего уровня»: ведение базы данных реального времени и журнала тревог, отображение оперативной технологической информации, графиков (трендов), создание отчетов, взаимодействие с системами линейной телемеханики и цеховой автоматики (в т.ч. выдача команд телеуправления), предоставление стандартных интерфейсов для межпрограммного взаимодействия. Поскольку различные производители программных средств АСУТП ориентируются на использование различных операционных систем (Windows, различные клоны UNIX, QNX) и рекомендуют различные аппаратные платформы, то при разработке АСУТП производственного объекта нужно говорить о выборе не только программных средств АСУТП; требуется анализировать программно-технический комплекс в целом. В данной лекции рассматривается архитектура программных комплексов АСУТП; модульность, межпрограммное взаимодействие, применимость понятия «открытой системы» к АСУТП. В следующих лекциях будут проанализированы: Тип (модель) базы данных АСУТП и ее влияние на производительность, функциональность и эксплуатационные характеристики системы в целом; Средства формирования графиков, отчетов; ведение журнала тревог, выполнение плановых и расчетных задач; Платформа функционирования АСУТП, требования к системному программному обеспечению и техническим средствам. Управление технологическими процессами с использованием SCADA систем стало осуществляться в передовых западных странах в 80-х годах XX в. В России активное использование новой концепции началось несколько позднее. В настоящее время на рынке представлено несколько десятков SCADA-систем. В табл. 6.1 приведен список распространенных тиражируемых программных комплексов АСУТП, с классификацией по типам БД и платформе (операционной системе). Таблица 6.1. Тиражируемые программные комплексы АСУТП.

№	Производитель	Наименование	Тип БД	Платформа (ОС)
1	AdAstra	TraceMode	тэговая	Windows
2	Iconics	Genesis	тэговая	Windows
3	Intellution	FIX	тэговая	Windows
4	Siemens	SIMATIC WinCC	тэговая	Windows
5	Schneider Electric (ранее ControlMicrosystems)	ClearSCADA	иерархичес-кая	Windows
6	Verano (ранее  Hewlett-Packard)	RTAP/Plus	иерархичес-кая	UNIX (HP-UX, Sun, AIX, OSF/1), Windows

4. ^ Общие принципы построения программных комплексов ДП АСУТП

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

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

• База данных, хранящая оперативную (технологическую) и нормативно-справочную информацию;

• «Скан-задачи» для взаимодействия с телемеханикой, автоматикой и информационных обменов с другими системами управления по различным протоколам передачи данных;

• Подсистема визуализации мнемосхем ТП, вспомогательных окон и проч.;

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

Таблица 6.2. Программные модули типовой ДП АСУТП RTAP/Plus.

№	Программный модуль	Реализуемая функция
Ядро – Диспетчеризация программ
1	RtapScheduler	Планирование запуска, выполнения процессов
2	RtapTimeKeeper	Контроль времени, генератор событий таймера
3	RtapWDServer	Контроль определенных состояний процессов
4	RtapCmdServer	Выполняет внешние команды по расписанию
5	RtapMonitor	Мониторинга текущего состояния проекта ДП
Ядро – Подсистема тревог
6	RtapASServer	Обработка изменений данных, генерация события–тревоги
7	RtapASLogger	Сохраняет сообщения-уведомления о возникновении тревоги
8	RtapASAction	Выполнение команд по условию тревог
Ядро – Коммуникационная подсистема
9	RtapQServer	Ведение (обслуживание) очереди удаленных сообщений
10	RtapDbServer	Обслуживание удаленных подключений к API
11	RtapEnvObjSvr	Обслуживание удаленных подключений к БД
12	RtapASObjSvr	Обслуживание удаленных подключений к системе тревог
База данных
13	RtapMQDBM	Управлнение очередью и выполнение запросов к БД
14	RtapDbCfServer	Обработка запросов по конфигурированию БД
15	RtapDbStartup	Восстанавливает образ БД в оперативной памяти при запуске
16	RtapForceSnap	Сохранение образа БД во вторичной памяти
17	RtapDHMngr	Сохранение ретроспективных данных
18	RtapCheckCfi	Проверка (предупреждение) блокировки БД
База данных – серверы протоколов
19	RtapODBCServer	Обеспечение выполнения SQL-запросов для доступа к БД
20	RtapDDEServer	Обеспечение доступа к БД по протоколу DDE (NetDDE)
21	RtapModbusMaster	Обеспечение доступа к БД по протоколу Modbus
22	RtapOPCServer	Обеспечение доступа к БД через OPC
Подсистема ввода/вывода
23	RtapScanMngr	Управление параметрами опроса устройств СТМ
24	RtapModbusScan и т.п.	Опрос устройств СТМ по определенному протоколу
Подсистема визуализации
25	RtapSchematX	Визуализация мнемосхем
26	RtapPlotDisp	Визуализация графиков
27	RtapRpDisp	Визуализация отчетов
28	RtapASSound	Звуковое оповещение о возникновении тревоги
29	RtapASDisplay	Визуализация журнала тревог
Конфигурирование
30	RtapDbConfig	Конфигурирование БД
31	RtapRpBuilder	Солздание шаблона отчета
32	RtapSchematBuilder	Создание динамических элементов мнемосхем
33	RtapCpBuilder	Создание оконного интерфейса

Также в состав тиражируемых программных комплексов АСУТП входят средства настройки АСУТП на конкретный объект автоматизации: программы создания базы данных, оконного интерфейса и мнемосхем ТП на базе поставляемых шаблонов, средства тестирования и т.п. Одна из тенденций развития современных АСУТП – это перенос процедур первичной обработки данных «вниз», с более высокого уровня управления (диспетчерский пункт АСУТП) на более низкий уровень программируемых логических контроллеров. Соответственно, основными для ДП АСУТП становятся функции сохранения данных, их отображения и передачи в АСУПХД, системы учета расхода и т.п.

5. ^ Анализ качественных характеристик ДП АСУТП

В число современных требований к любой информационной системе входит «соответствие стандартам открытых систем». На практике это означает требование поддержки распространенных интерфейсов межпрограммного взаимодействия и обмена данными, возможности функционирования в сетевой среде и т.п.  Анализ показывает, что степень «открытости» системы определяется двумя факторами: либо использованием в качестве базовых компонентов АСУТП программного обеспечения от крупных фирм-разработчиков (например, база данных пакета Wonderware IndustrialSQL Server является «надстройкой» над Microsoft SQL Server), либо изначальной ориентированностью при разработке системы на ее функционирование в многоплатформенной среде. В настоящее время в связи с подавляющим превалированием по числу инсталляций ОС Windows производители, ориентировавшиеся на UNIX, выпускают по крайней мере клиентские автоматизированные рабочие места для Windows. Взаимодействие UNIX-Windows реализуется либо универсальным механизмом объектного взаимодействия CORBA, либо специальным ПО. В любом случае используется сеть TCP/IP. В подавляющем большинстве СУБД АСУТП реализован доступ к хранимым данным через ODBC и NetDDE – широко распространенные стандарты информационного обмена между приложениями. Любая АСУТП должна получать данные технологического процесса из внешней среды, которую, собственно, она и контролирует. Выделяются различные способы получения данных от оборудования (интеллектуальных датчиков, ПЛК и цеховых САУ) – периодический опрос всех значений, получение измененных значений, получение аварий. В первых двух случаях данные передаются по запросу АСУТП, передача тревог обычно инициируется самим оборудованием. В ряде систем выделяется отдельный процесс («скан-менеджер»), осуществляющий управление опросом ПЛК, сохранение полученных данных (в выделенной области памяти или непосредственно в БД), управление процессами, реализующими информационный обмен по универсальным и специальным протоколам. На платформе Windows широко распространено использование OPC (OLE for Process Control, объектное взаимодействие в системах управления ТП). Универсальный OPC-клиент используется со стороны АСУТП, каждый производитель ПЛК поставляет свой OPC-сервер. В настоящее время существует более 200 OPC-серверов, и как следствие не требуется реализовывать ПО стыка каждой конкретной АСУТП со всеми моделями ПЛК. Универсальные «скан-задачи» для АСУТП на базе UNIX-платформы не получили широкого распространения, а аналогичные OPC механизмы объектного взаимодействия (CORBA) являются слишком «тяжелыми» для интенсивного обмена технологическими данными между ПЛК и системами реального времени. Несмотря на все многообразие стандартно реализуемых тиражируемым программным обеспечением функций, часто возникают задачи, наиболее эффективный способ решения которых – написание отдельной программы, оперирующей технологическими данными, хранящимися в БД АСУТП. Такими задачами могут являться:

• моделирование системы трубопроводов;

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

• экспертные системы и др.

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

1   2   3   4   5   6   7   8   9   ...   14