Содержание к диссертации
Список обозначений и сокращений , 5
Введение 11
8.1. Актуальность темы 11
8.2. Цель работы 19
8.3. Методы исследования и используемые инструментальные средства 20
8.4. Научная новизна 20
8.5. Практическая ценность 21
8.6. Реализация и внедрение результатов 22
8.7. Апробация и публикации 23
8.8. Основные положения, выносимые на защиту 23
8.9. Структура и объем диссертации 24
Глава 1. Анализ компонентов промышленной автоматизации и ОРС серверов доступа к данным реального времени 25
1.1. SCADА-система и ее взаимодействие с устройствами сбора данных и управления 25
1.2. ОРС-серверы доступа к данным реального времени 28
1.2.1. Общие характеристики ОРС-серверов 28
1.2.2. Сущность ОРС и архитектура СОМ-серверов 29
1.2.3. Обобщенная структура ОРС-серверов 33
1.3. Выводы 38
Глава 2. Теоретическое обоснование и разработка структуры сервера
УСОА и его универсальной части 39
2.1. Нотация для описания объектов, компонентов, уровней и взаимодействия между ними 41
2.2. Обобщенная архитектура сервера УСОА. Критерии декомпозиции 42
2.3. Развернутая иерархическая структура сервера УСОА 46
2.4. Модели базовых объектов сервера и модель их взаимодействия 52
2.4.1. Классификация объектов сервера УСОЛ 52
2.4.2. Модель объекта-элемента 54
2.4.3. Модель объекта-диспетчера и алгоритм рабочего потока 57
2.4.4. Модель объекта-интерфейса 62
2.4.5. Модель поведения и взаимодействия объектов в системе 64
2.5. Компоненты сервера УСОА 67
2.5.1. Компонент УСО. 67
2.5.2. Компонент ЦМД 67
2.5.3. Компонент ОРС з
2.6. Модель трехуровневого кэша сервера У СО А и организация обмена данными между ОРС-клиентами и сервером 72
2.6.1. Синхронный обмен данными 75
2.6.2. Асинхронный обмен данными 78
2.6.3. Режим подписки 80
2.6.5. Планирование выполнения задач в иерархических уровнях сервера УСОА 81
2.7. Этапы разработки компонентов сервера УСОА 86
2.8. Выводы. Преимущества сервера УСОА - взгляд изнутри 90
Глава 3. Исследование и разработка специализированной части сервера УСОА. Синтез контура сбора данных и управления 93
3.1. Анализ существующих ОРС-инструментов и требования к разработке компонентов УСО 93
3.2. Характеристика универсальности ОРС-инструмента и синтез структуры компонента УСО 98
3.2.1. Основные понятия и терминология 98
3.2.2. Анализ аспектов универсальности в серверах, разработанных с помощью существующих ОРС-инструментов 99
3.2.3. Синтез структуры компонента УСО с помощью нового ОРС-инструмента 107
3.3. Подготовка к синтезу компонента УСО 112
3.3.1. Декомпозиция компонента УСО 112
3.3.2. Тэг в системе управления: новые типы и модификация существующих типов , 113
3.4. Синтез компонента УСО 124
3.4.1. Анализ и методика разработки реального тэга компонента УСО 124
3.4.2. Анализ и методика разработки реального устройства компонента УСО. Язык общения между ОРС-сервером и компонентом УСО (интерфейсы)... 136
3.5. Организация сбора данных и управления в компонентах УСО 143
3.5.1. Способы организации сбора данных 143
3.5.2. Планирование работы задач сбора данных и управления 146
3.6. Выводы. Преимущества сервера УСОА - взгляд со стороны 151
Глава 4. Практические применения сервера УСОА 154
4.1. Методика подключения УСО к серверу УСОА 154
4.2. Примеры разработки компонентов УСО 162
4.2.1. Разработка компонента УСО для эмулятора сигналов 162
4.2.2. Разработка компонента для нестандартного УСО 164
4.2.3. Разработка компонента УСО для промышленного контроллера и модулей ввода/вывода 165 4.3. Интеграция системы автоматического управления рентгенолюминесцентными сепараторами и SCADA-систем 167
4.4. Интеграция учебных лабораторий АСУ ТП 175
4.4.1. Недостатки ОРС-стандарта и новое интеграционное решение.. 176
4.4.2. Программные средства, используемые для интеграции лабораторий 178
4.4.3. Связывание ЛВС лабораторий 181
4.4.4 Интеграция по управлению и информационное объединение лабораторий 183
4.4.5. Расчет запаздывания передачи данных между серверами УСОА, расположенными в разных ЛВС. 186
4.5. Исследование производительности сервера УСОА 189
4.6. Выводы. Преимущества сервера УСОА - взгляд из практики 191
Заключение 192
Литература 195
Приложения 202
Приложение П.1. Программа эмулятора сигналов и классы компонента УСО эмулятора 202
Приложение П.2. Программа реализации компонента УСО для нестандартного УСО 2
Введение к работе
? Контроллерный уровень, представляющий собой устройства сбора данных и управления (далее устройства связи с объектом - УСО): датчики, механизмы, локальные контроллеры и т.д. Поток информации от контроллерного уровня должен быть предоставлен устройствам вышележащего уровня, пользователям или приложениям, использующим их посредством цифровых коммуникационных протоколов связи. При этом в системе не должно возникать проблем несовместимости.
? Уровень контроллеров верхнего уровня. Информация с локальных контроллеров может направляться в приложения вышележащего уровня непосредственно, а также через контроллеры верхнего уровня. Контроллеры верхнего уровня реализуют различные функции, например, сбор данных с локальных контроллеров, вторичную обработку данных, поддержание единого времени в системе, обмен информацией между локальными контроллерами и приложением следующего уровня и др. При этом в системе также не должно возникать проблем несовместимости.
? Операторский уровень - уровень работы систем типа SCADA (Supervisory Control And Data Acquisition) для сбора данных и диспетчерского управления технологическими процессами (ТП) на производстве. Этот уровень обеспечивает вторичную обработку данных, которые получены с нижнего уровня - визуализацию, интерфейс с оператором, сохранение истории процесса и доступность данных и результатов их обработки приложениям и пользователям верхнего уровня.
? Уровень приложений управления ресурсами предприятия. Информация с уровня SCADA-систем должна быть доступной для этого уровня, т.е. доступ к данной информации из прикладных программ не должен вызывать проблем.
Для обеспечения совместимости между уровнями и создания эффективной интегрированной системы управления (СУ) предприятием системный интегратор или разработчик АСУ ТП должен обеспечить извлечение данных ТП в реальном масштабе времени (РМВ) с самого нижнего уровня и построить "прозрачный" путь получаемым данным к самым верхним уровням. Чтобы получить систему, отвечающую всем потребностям заказчика, системному интегратору или разработчику необходимо использовать инструментальные средства управления различных уровней - SCADA-пакеты, базы данных, электронные таблицы. Ключ к этому - открытая и эффективная коммуникационная архитектура взаимодействия между приложениями, которую предлагает стандарт OLE for Process Control - OPC.
OPC - стандарт [17, 66, 69, 71], основанный на технологии COM/DCOM (Component Object Model/Distributed COM) фирмы Microsoft [18, 19, 32, 60] для СУ в промышленной автоматизации (ПА) и предназначенный для обеспечения универсального механизма обмена данными (ОД) между датчиками, исполнительными механизмами, контроллерами и системами представления технологической информации, оперативного диспетчерского управления, а также СУ базами данных.
ОРС-стандарт создан консорциумом ОРС Foundation [69], в котором участвуют практически все мировые ведущие производители аппаратного оборудования и программного обеспечения (ПО) для ПА. На сегодняшний день ОРС-стандарт в определенной степени реализован и продолжает развиваться. Консорциум ОРС Foundation пытается охватить все аспекты, связанные с взаимодействием между компонентами ПО, между ПО и между системами типа SCADA и технологическим оборудованием. В настоящее время насчитывается порядка десяти ОРС-спецификациЙ — Data Access (доступ к данным реального времени) [67, 68], Alarms & Events (обработка тревог и событий) [65], Historical Data Access (доступ к историческим данным) [71] и т.д. Поэтому ОРС можно определить как стандарт взаимодействия между программными компонентами сбора данных и управления (СДУ). Через ОРС-интерфейсы одни приложения могут читать или записывать данные в другие приложения, обмениваться информацией о событиях, оповещать друг друга о нештатных ситуациях, осуществлять доступ к данным, зарегистрированным в архивах. Указанные приложения могут располагаться как на одном компьютере, так и быть распределенными в сети. При этом независимо от фирмы поставщика, ОРС-стандарт, признанный и поддерживаемый всеми ведущими фирмами-производителями SCADA-систем и оборудования, обеспечит их совместное функционирование [35].
Популярный класс ОРС-приложений представляют собой специализированные ОРС-серверы конкретных аппаратных устройств или ОРС-серверы доступа к данным РВ [53, 63, 67, 68, 73, 74], обеспечивающие предоставление информации о состоянии параметров ТП от УСО ОРС-клиентам на локальном компьютере или в компьютерной сети. Современные SCADA-системы поддерживают ОРС-спецификации доступа к данным РВ, являясь ОРС-клиентами. В этом смысле зачастую специализированные ОРС-серверы разрабатывают фирмы-производители УСО. ОРС-спецификация доступа к данным РВ поддерживается во многих современных SCADA-системах. В настоящее время, консорциум ОРС Foundation набирает силу в разработке открытых промышленных стандартов на основе ОРС-стандарта на базе операционных систем (ОС) фирмы Microsoft. Сейчас в состав консорциума входят более 350 членов [69, 73], среди которых практически все мировые ведущие производители технологического оборудования, систем автоматизированного управления и ПО. Членами консорциума являются, например, фирмы Iconics (США), Wonderware (США), Adastra (Россия), Siemens (Германия), Rockwell Software (США), Intellution (США), Сі Technologies (Австралия), Indusoft Russia (Россия), Fastwel (Россия), ABB Automation (США), Fieldbus Foundation (США), Toshiba (Япония), Hitachi (Япония), National Instruments (США), и др. [9, 36, 37]. Ведущие производители, с учетом своего опыта, стараются предоставить абсолютно всё необходимое тому, кто будет использовать ОРС. Этот факт показывает большой авторитет ОРС-стандарта который является перспективным и для использования в АСУ.
В настоящее время существуют много ОРС-серверов, которые поставляются вместе с продуктами ведущих производителей УСО, разработанных самими производителями [73]. Такими производителями являются, например, Advantech, ABB, Alen-Bradley, С і Technologies, Fisher-Rosemount Systems, Siemens, Omrom, Schneider Electric, ICP-DAS, Fastwel [6, 38, 46, 73] и т.д. Большинство из существующих ОРС-серверов разрабатывается производителями только для модулей или группы модулей ввода/вывода, т.е. только для пассивных устройств. В имеющихся ОРС-серверах поддерживается фиксированное количество тэгов, определяющихся физическими каналами ввода/вывода этих модулей. При этом ОРС-серверы собирают данные в РМВ и предоставляют полученные данные SCADA-системам. В подобных случаях в SCADA-системе работают алгоритмы мониторинга и управления с большой нагрузкой для обработки сырых данных, получаемых от ОРС-серверов и распределенная система управления (РСУ) выглядит не лучше, чем ранняя централизованная СУ [13], т.к. при выключении SCADA-станций система перестает функционировать. Для построения эффективной интегрированной СУ в данном случае требуется в системе предусмотреть дополнительный уровень работы SCADA-системы, называемой мини SCADA-системой. Обе указанные SCADA-системы предоставляются одним поставщиком для обеспечения их совместимости. Это объясняет, почему в СУ 1Ш используются монолитные средства из одной ведущей компании. Конечно, при этом и предприятия-потребители целиком зависят от ведущей компании (финансовые и технические факторы).
На нижнем (контроллерном) уровне АСУ ТП предприятий часто используются УСО разных производителей. Из-за ограниченных аппаратных ресурсов предприятий указанные устройства зачастую соединяются общим интерфейсом (кабелем). Например, устройства соединяются интерфейсом RS-485 и затем с помощью конвертора RS-232/RS-485 устройства могут подключаться к одному СОМ-порту компьютера, на котором работают ОРС-серверы (далее host-компьютер), снабжающие эти устройства. Однако данное решение не приемлемо из-за конфликта между ОРС-серверами при обращении к общему СОМ-порту [16].
Для стандартизации своих продуктов (устройств) производители оборудования автоматизации разрабатывают ОРС-серверы для этих устройств. Многие фирмы-производители УСО в корпоративных целях сознательно разрабатывают ОРС-серверы так, чтобы максимально продвинуть на рынок свою аппаратуру. Например, разрабатываются ОРС-серверы для специализированных контроллеров сбора данных, для плат сбора данных, для контрольно-измерительных приборов и т.д. Однако разработка ОРС-серверов является далеко не тривиальной задачей [25]. Производители оборудования должны получать нужную ОРС-спецификацию доступа к данным РВ и прилагаемые программные компоненты. Затем они должны изучить СОМ-интерфейсы СОМ-объектов, используемых в ОРС-спецификации доступа к данным РВ. И, наконец, они должны привлечь к разработке ОРС-сервера опытного программиста, способного реализовать требуемые интерфейсы, а значит и ОРС-сервер. Уместно еще раз подчеркнуть, что сами ОРС-объекты и их ОРС-интерфейсы достаточно сложны и громоздки [19, 32]. В частности, при разработке ОРС-сервера возникают вопросы ОД, управления памятью, многозадачности, синхронизации и т.п.
Наряду с последними по времени разработки устройствами, снабженными ОРС-серверами, существует значительная часть устройств более ранней разработки, которые не снабжены ОРС-серверами. Такими устройствами могут быть, например, нестандартные платы ввода/вывода, АЦП/ЦАП [39], контрольно-измерительные приборы (насосы-дозаторы, преобразователи частоты, и т.д.), генераторы случайных чисел и т.д. В качестве примера можно назвать российские фирмы L-card [7], РИУС [29], которые занимаются производством нестандартных плат ввода/вывода. До сих пор устройства этих фирм еще не снабжаются ОРС-серверами.
В настоящее время существует часть ПП, в том числе в России, которые еще не применяют SCADA-системы для автоматизации своих СУ. Что же должны сделать предприятия, если они задались целью модернизации своих СУ? Они должны обратиться к крупному ведущему поставщику современных средств ПА и получить от этого поставщика предложение на комплексную модернизацию СУ с заменой как всех аппаратных, так и всех программных компонентов, которые уже много лет активно использовались на предприятиях. Но подобное решение затруднительно или даже неприемлемо по следующим причинам. Во-первых, подобная модернизация невыгодна с финансовой точки зрения. Во-вторых, иногда устройства предприятий затруднительно или вообще нельзя заменить другими из-за проблемы, связанной с уникальностью этих устройств или по соображениям информационной безопасности. Хорошим выходом из подобной ситуации является исследование и разработка универсального ОРС-сервера с открытой архитектурой (далее сервер У СО А), позволяющего интегрировать в СУ любое оборудование при минимальных затратах финансовых и временных ресурсов).