Содержание к диссертации
Введение
Глава 1. Анализ возможностей COM/DCOM 11
1.1. Основные принципы взаимодействия приложений 11
1.2. Нитевые модели 18
1.3. Категории компонентов 23
1.4. Безопасность в COM/DCOM 24
1.5. Сетевой транспорт в COM/DCOM 29
1.6. Задачи автоматизации, решаемые с помощью COM/DCOM 35
Выводы 37
Глава 2. Методика использования COM/DCOM в АСУ 38
2.1. Требования к системе контроля доступа 38
2.2. Описание системы контроля доступа 39
2.3. Устройство ехе-сервера СКД 47
2.4. Устройство dll-сервера СКД 48
2.5. Роль COM/DCOM в СКД 54
2.6. Недостатки СКД 56
2.7. Алгоритмы диагностики и восстановления связи с СОМ-сервером 57
2.8. Методика использования COM/DCOM при создании АСУ 60
Выводы 64
Глава 3. Группа стандартов ОРС 66
3.1. ОРС Common 69
3.2. ОРС Data Access 70
3.3. ОРС Alarms and Events 75
3.4. ОРС Batch 77
3.5. ОРС Security 77
3.6. ОРС Historical Data Access 78
3.7. OPC Data Exchange 79
3.8. ОРС XML-DA 79
3.9. Использование ОРС в АСУ для взаимодействия с устройствами 80
3.10. Быстродействие ОРС 84
3.11. Недостатки ОРС 86
Выводы 89
Глава 4. Опыт использования ОРС в АСУ 90
4.1. Использование ОРС на примере системы контроля и диспетчерского управления 90
4.2. Способы преодоления недостатков ОРС 96
Выводы 108
Глава 5. Распараллеливание работы ОРС-сервера 110
5.1. Актуальность задачи распараллеливания работы ПО
5.2. Классификация протоколов обмена 111
5.3. Распределение задач между нитями сервера 113
5.4. Оптимизация выдачи заданий 119
5.5. Алгоритм работы нити, взаимодействующей с устройствами 125
5.6. Возможные изменения алгоритма распараллеливания задач 129
5.7. Нитевая модель ОРС-сервера 137
Выводы. 139
Глава 6. Использование COM/DCOM и ОРС в интернете 141
6.1. Требования к методу доступа через интернет 141
6.2. Прямой доступ с СОМ-серверам через интернет 141
6.3. Использование браузера для взаимодействия с СОМ-серверами 144
6.4. Недостатки имеющихся методов доступа к ОРС-серверу через браузер 150
6.5. Доступ к ОРС-серверу с помощью ISAPI-библиотеки 151
6.6. Рекомендации по выбору способа доступа к СОМ-серверу через интернет 157
Выводы 158
Заключение 159
Список литературы
- Безопасность в COM/DCOM
- Устройство dll-сервера СКД
- ОРС Historical Data Access
- Способы преодоления недостатков ОРС
Введение к работе
Современные АСУ являются сложными распределёнными системами, управляющими одновременно большим количеством разнородных объектов управления. Такие системы обычно состоят из нескольких уровней. В [1] описаны пять уровней АСУ предприятия: уровень низовой автоматики, контроллерный уровень, уровень человеко-машинного интерфейса (ЧМИ), уровень управления производством и уровень управления ресурсами предприятия. Каждый из этих уровней использует свои аппаратные и программные средства. Между уровнями идёт интенсивный обмен данными. Согласно [2] деление системы на уровни обусловлено не только различными требованиями, предъявляемыми к аппаратной и программной частям, но иерархией бизнес-процессов, связанных с АСУ.
На рис.1 показана типичная многоуровневая АСУ предприятия. На нижнем уровне системы находятся датчики и устройства сопряжения с объектом (УСО), которыми управляет низовая автоматика - простые устройства, обеспечивающие простейшее оперативное управление системой. Этими устройствами, в свою очередь, управляют программируемые логические контроллеры (ПЛК), которые могут быть как относительно простыми и низкопроизводительными, так и многопроцессорными системами, сравнимыми по производительности с мощными серверами. ПЛК управляют устройствами низовой автоматики, собирая с них данные и выставляя параметры процесса регулирования. Обычно контроллер управляет множеством устройств низовой автоматики, управляя через них несколькими ОУ (объектами управления). В некоторых случаях контроллеры могут взаимодействовать непосредственно с датчиками и УСО без помощи низовой автоматики.
ЧМИ (человеко-машинный интерфейс) может быть реализован непосредственно ПЛК, но в большинстве случаев для этого используются отдельные компьютеры, получающие от ПЛК данные. Операторы АРМ посредством ЧМИ осуществляют общее управление частью системы. На этом же уровне осуществляется сбор и архивация данных, поставляемых ПЛК. Уровни системы от датчиков и УСО до уровня ЧМИ принято называть АСУТП.
На уровне управления производством осуществляется общее управление всеми АСУТП предприятия, что обеспечивает их совместную работу. Управление осуществляется, в основном, операторами АРМ, программное обеспечение не рассчитано на автономное принятие решений.
Управление производством
Объекты управления
вині р&а
ifcOfei
Рис. 1. Типичная структура АСУ предприятия
Уровень управления ресурсами предприятия на рис. 1 не показан. Этот уровень долгое время существовал независимо от остальных уровней АСУ, и до сих пор он далеко не везде связан с нижележащими уровнями.
Многие реальные системы, описанные в литературе, в целом соответствуют описанной иерархии, хотя уровни в них могут быть разделены не так чётко. Так, в АСУ Белорусского металлургического завода [3] ПЛК не имеют выхода в Ethernet и связываются с компьютерами уровня ЧМИ посредством технологической сети. Системы, описанные в [4, 5], соответствуют приведённой схеме, за исключением того, что в них отсутствует уровень управления. Практически полностью описанной схеме соответствуют системы, описанные в [6-11]. Интересный пример построения многоуровневой системе описан в [12] - в нём компьютеры уровня управления взаимодействуют непосредственно с контроллерами, а ЧМИ существует параллельно.
Необходимость разбиения системы на уровни хорошо иллюстрирует учебная САУ, разработанная на кафедре автоматики МИФИ [13]: она разбита на два уровня - уровень ПЛК и уровень ЧМИ, хотя используется только для управления одним двигателем и одним датчиком.
На уровнях низовой автоматики и контроллеров применяются технологические сети реального BpeMeHn(Profibus, CAN и т.п.), гарантирующие определённое время доставки пакета . На уровне ЧМИ и выше потребность в сетях реального времени отсутствует, т.к. решение принимает человек, время реакции которого слишком велико для обеспечения реального времени (по тем же причинам на данном уровне не обязательно использовать ОС РВ). Поэтому здесь часто применяется сеть Ethernet, превосходящая технологические сети по универсальности, количеству узлов и длине. Поэтому в большинстве случаев ПЛК имеют выход в Ethernet и передают информацию для уровня ЧМИ именно через эту сеть (хотя возможны также случаи, когда компьютеры уровня ЧМИ подключаются непосредственно к технологической сети). Передача данных между компьютерами уровня ЧМИ в любом случае осуществляется через Ethernet.
Уровень управления также использует сеть Ethernet: либо ту же самую, что и уровень ЧМИ, либо обособленную, но имеющую шлюз в сеть ЧМИ. Уровень управления активно использует данные, поступающие с уровня ЧМИ; в обратном направлении поток данных существенно меньше.
На уровнях ЧМИ и управления не требуется столь же высокая производительность обмена данными, как на нижних уровнях, более значимыми являются требования универсальности, масштабируемости и возможности работать как в режиме непрерывного обмена данными, так и в режиме кратковременных подключений. Кроме того, программное обес-
печение на данных уровнях обычно достаточно сложно, и скорость его разработки становится важным фактором. По последнему критерию технология COM/DCOM, встроенная в Windows, является оптимальной. В данной диссертации будет показано, что по остальным критериям она также подходит для организации обмена данными на уровнях ЧМИ и управления.
Технология COM (Component Object Model), предназначенная для обмена данными между программами, появилась в Windows NT 3.5 в 1993 году [14]. В 1996 году в Windows NT 4.0 появилось расширение этой технологии, получившее название DCOM (Distributed СОМ, [15]). В отличие от COM, DCOM позволяет осуществлять обмен данными между программами, работающими на разных компьютерах, соединённых в сеть. С точки зрения программиста СОМ и DCOM очень мало различаются между собой, поэтому в данной диссертации будет использован термин «технология COM/DCOM» всегда, за исключением тех случаев, когда будет необходимо подчеркнуть различия между СОМ и DCOM.
Технология COM/DCOM всегда была ориентирована прежде всего на офисные приложения и доступ к базам данных или иным ресурсам сервера, совместно используемым пользователями. В COM/DCOM отсутствует понятие гарантированного времени доставки (что не удивительно для технологии, использующей в качестве базовой сети Ethernet). Плохо проработаны вопросы обнаружения разрыва связи и её последующего восстановления. Всё это затрудняет использование COM/DCOM в АСУ. Тем не менее, данная технология очень привлекательна для использования в АСУ из-за простоты разработки и большого количества возможностей.
COM/DCOM следует использовать на тех уровнях АСУ, в которых нет нужды в реальном времени и узлы связаны через Ethernet, т.е. на уровне ЧМИ и выше. В тех случаях, когда ПЛК имеют выход в Ethernet, COM/DCOM может использоваться и для связи между уровнями ПЛК и ЧМИ, хотя такая возможность используется редко.
COM/DCOM является кроссплатформенной технологией. Существуют её реализации для различных операционных систем ([16]). Однако рассмотрение особенностей использования COM/DCOM в операционных системах, отличных от Windows, выходит за рамки диссертации. Кроме того, не рассматривается COM/DCOM в Windows 95/98/МЕ, так как эти операционные системы из-за своей низкой надёжности не могут быть использованы в АСУ.
Цель диссертации - разработка методов и алгоритмов использования COM/DCOM в АСУ. Те аспекты технологии COM/DCOM (например, ActiveX, OLE DB, СОМ-исключения и т.д.), которые не имеют специфики применения в АСУ по сравнению с применением в других областях, рассматриваться не будут. Эти аспекты исчерпывающе описаны в многочисленных руководствах и учебниках по COM/DCOM (например, [17]).
Значительная часть диссертации посвящена семейству стандартов ОРС (OLE for Process Control). Эти стандарты разработаны специально для компонентов АСУ, не требующих реального масштаба времени, и основаны на технологии COM/DCOM. Они получили широкое распространение, значительная доля использования COM/DCOM в АСУ приходится именно на ОРС. Поэтому в диссертации также предлагаются решения, специфичные для этих стандартов.
Все практические разработки в области COM/DCOM и АСУ сделаны автором с использованием языка C++, поэтому примеры кода даны в диссертации именно на этом языке программирования. Однако результаты могут быть легко реализованы на любых других языках программирования, поддерживающих COM/DCOM. Для описания интерфейсов используется IDL (Interface Definition Language, язык определения интерфейсов, [18]), являющийся стандартным средством описания интерфейсов в COM/DCOM.
Безопасность в COM/DCOM
Под безопасностью в этом разделе понимается запрет на неавторизованное подключение, а также меры против вмешательства третьей стороны в процесс обмена или прослушивания третьей стороной линии обмена.
Система безопасности COM/DCOM строится на системе безопасности операционной системы Windows и позволяет гибко настраивать следующие параметры: права сервера по отношению к доступу к системным ресурсам, права клиентов по отношению к доступу к серверам и защищённость протокола обмена данными между клиентом и сервером. Для настройки параметров безопасности (а также ряда других параметров) используется стандартная системная утилита dcomcnfg.
Права сервера определяются тем, в контексте какой учетной записи он запущен (права учётной записи могут быть настроены обычными системными средствами). Настройки касаются сервера в целом: так, если сервер реализует несколько коклассов, все они получат одинаковые права. Возможные варианты по настройке прав сервера показаны в табл. 1.2.
Если серверу необходим вывод на экран, следует запускать его в контексте интерактивного пользователя, так как невозможность вывода на экран может привести к блокировке работы сервера. Рассмотрим ситуацию, когда во время работы сервера произошло некоторое событие, требующее вмешательства пользователя. Сервер открывает диалоговое окно, в котором информирует пользователя о произошедшем и даёт возможность каким-либо образом повлиять на ситуацию. Работа сервера приостанавливается до тех пор, пока пользователь не закроет окно. Если же доступ к экрану у сервера отсутствует, данное окно будет невидимым, и даже если пользователь по каким-то косвенным признакам догадается, что сервер открыл такое окно, он не сможет его закрыть. Работа сервера будет заблокирована, и единственное, что сможет сделать пользователь, - это принудительно заставить систему снять задачу сервера и запустить её снова, а в отдельных случаях для восстановления работоспособности системы в целом необходимо перезагрузить компьютер.
Настройки по умолчанию предполагают работу сервера в контексте учётной записи запускающего пользователя (если сервер не зарегистрирован как служба). Этот вариант, как и внутренние серверы, может приводить к конфликтам при использовании неразделяемых ресурсов (недостатки варианта запускающего пользователя детально рассмотрены в [33]).
Для того, чтобы клиент мог подключиться к серверу, учётная запись, в контексте которой он запущен, должна быть внесена в список тех, кому это подключение разрешено. Для каждого сервера создаётся два списка: список учётных записей, которым разрешено подключение к уже запущенному серверу и список учётных записей, которым разрешён запуск сервера. Выше говорилось, что система при попытке со стороны клиента установки связи с сервером, который ещё не запущен, система его запускает. Это верно только в том случае, если клиент работает в контексте учётной записи, которой разрешён запуск сервера, в противном случае функция CoCreatelnstance(Ex) вернёт значение EACCESSDENIED, сигнализирующее об отсутствии у клиента прав, необходимых для выполнения действия. Если учётная запись внесена в список тех, кому разрешён запуск сервера, она также получает права на подключение к уже работающему серверу.
Чтобы разрешить или запретить подключение, система должна получить информацию о том, какой клиент пытается подключиться к серверу. Системой безопасности COM/DCOM предусмотрено несколько уровней проверки подлинности пользователя, которые показаны в табл. 1.3 (данные взяты из [34]).
Настройка уровня проверки подлинности пользователя обычно осуществляется с помощью утилиты dcomcnfg. Разработчик сервера может перекрыть эти настройки, вызвав в коде сервера системную функцию CoCreateSecurity. Явный вызов этой функции позволяет серверу запретить устанавливать неоправданно низкий уровень проверки.
Клиент также может вызвать функцию CoCreateSecurity. Если сервер и клиент установят разные уровни проверки подлинности пользователя, будет использован более высокий из них. Вопросы согласования уровней проверки подлинности пользователя между клиентом и сервером детально рассмотрены в [35].
Технология COM/DCOM создавалась в первую очередь для того, чтобы оградить разработчика от проблем, связанных с вопросами транспорта данных. Однако в случае удалённой связи через сеть полностью исключить эти проблемы из рассмотрения не удаётся. Кроме того, при пересылке большого объёма данных встаёт вопрос сравнительной производительности COM/DCOM и других протоколов.
Технология COM/DCOM ориентирована, в первую очередь, на тот случай, когда один или несколько мощных серверов вынуждены обрабатывать запросы многочисленных клиентов, причём СОМ-объекты при этом многократно создаются и разрушаются и одновременно на одном компьютере может работать до нескольких сот тысяч экземпляров различных коклассов. Происходит это всё при непосредственном взаимодействии с пользователем, что частично снимает с компьютера от ответственность за принятие решения при внештатных ситуациях: при обнаружении проблемы клиент просто выводит предупреждение пользователю о невозможности выполнения требуемой операции и разрывает связь с сервером. Восстановление связи производится, когда пользователь снова требует выполнить операцию, нуждающуюся в связи с сервером.
Производительность COM/DCOM исследовалась в работе [20]. Для компьютера на базе микропроцессора Pentium с тактовой частотой 120 МГц, ОЗУ 32 Мб и сетевой картой Intel EtherExpress PRO (10 Мбит/с) были получены результаты, представленные в табл. 1.4.
Устройство dll-сервера СКД
Dll-сервер содержит кокласс, экспортирующий два интерфейса: IDevice и IView. IDevice используется модулем ASC.exe, IView - модулем ASCView.exe. Коклассы всех dll серверов реализуют категорию «ASC Device Server», созданную в процессе разработки системы. Это позволяет узнать, какие из dll-серверов зарегистрированы на данном компьютере.
Для реализации пользовательского интерфейса используется библиотека MFC (Microsoft Foundation Classes), входящая в состав Microsoft Visual C++ ([52]). Для реализации окон и различных элементов управления используются объекты соответствующих классов MFC. Через функции интерфейсов IDevice и IView передаются указатели на эти объекты. Таким образом, взаимодействие между dll-сервером и его клиентами не ограничивается взаимодействием через СОМ-интерфейсы. Так как эти указатели не имеют смысла вне процесса, создавшего объекты, данные интерфейсы не могут экспортироваться внешним сервером.
Пользовательский интерфейс для настройки устройства сильно зависит от особенностей самого устройства и поэтому не может быть одинаковым для всех устройств. Можно было бы построить систему по-другому: разработать единый СОМ-интерфейс для ехе-серверов, через функции которого сервер передавал бы клиенту информацию о требуемом количестве окон и об элементах управления, которые должны быть размещены в этих окнах. Клиент, получив эту информацию и построив окна, сообщал бы серверу, какие действия предпринял пользователь, а сервер в ответ указывал бы клиенту, что требуется делать дальше. Такой подход влечёт за собой большие накладные расходы как при разработке клиентов и серверов, так и при их взаимодействии (многократная пересылка информации о действиях пользователя приводит к существенному увеличению нагрузки на сеть).
Вместо этого был выбран другой подход: для каждого устройства разрабатывается не один сервер, а пара серверов: внешний ехе-сервер и внутренний dll-сервер. СОМ-интерфейс каждого ехе-сервера разрабатывается индивидуально, с учётом особенностей устройств, которыми он управляет. Dll-сервер, являющийся клиентом для ехе-сервера, для реализации пользовательского интерфейса создаёт обычные объекты, указатели на которые передаёт клиенту. Эти объекты, с одной стороны, могут быть использованы клиентами dll-сервера так, как будто они ими и созданы, а с другой стороны, инкапсулируют в себе весь код, необходимый для работы с ехе-сервером. Таким образом, во-первых, существенно сокращается срок разработки интерфейса для нового типа устройств, так как данная разработка осуществляется стандартными средствами среды Visual C++, а во-вторых, вызовы ехе-серверу через сеть выполняются только тогда, когда это действительно необходимо.
События, связанные с устройством, dll-сервер передаёт своим клиентам также через указатели на объекты, служащие оболочкой для стандартных системных событий ([28]), поэтому интерфейсы обратного вызова в нём отсутствуют.
Модуль ASC.exe взаимодействует с устройством следующим образом: сначала с помощью функции CoCreatelnstance создаётся экземпляр кокласса, экспортируемого соответствующим dll-сервером. Далее ASC.exe вызывает функции интерфейса IDevice, которые возвращают указатель на объекты, реализующие пользовательский интерфейс. Эти объекты реализуют страницы с элементами управления. Страницы вставляются в главное окно приложения ASC.exe, и пользователь может взаимодействовать с ними. Одна из страниц содержит элементы управления для выбора компьютера, к которому подключено устройство. Как только пользователь указал этот компьютер, dll-сервер вызывает CoCreateln-stanceEx и создаёт на указанном компьютере экземпляр кокласса, экспортируемого парным ему ехе-сервером. Вновь созданный СОМ-объект не подключен к объекту, управляющему устройством, так как не располагает информацией о том, к какому из указанных объектов он должен быть подключен. Как только пользователь задаст параметры устройства, однозначно его идентифицирующие, dll-сервер передаст эти параметры СОМ-объекту, созданному ранее, и он подключится к управляющему объекту, непосредственно связанному с устройством. После этого любые действия пользователя, направленные на изменение параметров устройства, будут транслироваться dll-сервером в вызовы СОМ-объекту ехе-сервера, через который попадут в соответствующий управляющий объект и будут переданы устройству. Связь между модулем ASC.exe и устройством посредством dll-сервера и ехе-сервера иллюстрирует рис. 2.4.
ОРС Historical Data Access
Каждый из стандартов группы ОРС в области своего применения решает широкий спектр задач. Это позволяет гибко приспосабливаться к нуждам каждой конкретной задачи, но делает реализацию стандарта трудоёмкой. В первую очередь это касается реализации сервера. Поэтому есть задачи, для решения которых ОРС не является оптимальным выбором. Это касается, прежде всего, тех случаев, когда и сервер, и клиент создаются одним разработчиком для решения какой-либо частной задачи, и тиражирование клиента и сервера не предусматривается. В этом случае легче будет реализовать оригинальный протокол обмена данными, который содержит только то, что реально требуется в конкретной задаче и избавляет разработчика от реализации ненужных дополнительных возможностей. Но разработчики обычно создают ОРС-серверы с помощью специальных пактов, которые называются ОРС Тооїкії ами ([74]). Эти пакеты расширяют возможности традиционных средств разработки программ, существенно облегчая разработку ОРС-серверов. При использовании ОРС Toolkit oB разработчик сервера должен реализовать только функции обмена данными с устройством и создания адресного пространства сервера, а все требования стандарта реализуются кодом ОРС Toolkit а. Такой подход сокращает область задач, для которых ОРС-сервер неприемлем из-за сложности разработки.
Главным достоинством стандартов ОРС по замыслу ОРС Foundation является их всеобщая поддержка (как будет показано ниже, это верно не для всех стандартов группы ОРС). Вследствие этого они могут обеспечить совместимость приложений различных производителей. Если устройство снабжено ОРС-сервером, то данные из него может получать любая SCADA-система. Если ранее производитель оборудования был вынужден снабжать своё устройство драйверами для как можно большего числа SCADA-систем, то теперь достаточно написать один ОРС-сервер. В этом смысле показательным является пример, приведённый в работе [75]: если для модели контроллера 1998 года разработчики в числе главных достоинств называли наличие драйверов для 11 SCADA-систем, то для контроллера 2001 года выпуска оказалось достаточно только ОРС-сервера. Достоинства ОРС как открытого стандарта при построении автоматизированных систем отмечены также в [48].
Преимущество ОРС-сервера перед обычным драйвером заключается также в том, что драйвер практически всегда представляет собой программный код, работающий в адресном пространстве SCADA-системы, в то время как ОРС-сервер обычно является независимым приложением. Это означает, что в случае использования драйвера SCADA-система должна находиться на том компьютере, к которому физически подключено устройство. Кроме того, две SCADA-системы, скорее всего, не смогут получить доступ к одному устройству, так как два экземпляра драйвера будут конкурировать при использовании ресурсов. А ОРС-сервер выполняет роль не только драйвера для устройства, но и организовывают ветвление потока данных: любое количество клиентов независимо от своего физического местоположения могут одновременно получать данные от одного ОРС-сервера.
Производители SCADA-систем, понимая недостатки обычных драйверов, внедряют в свои продукты протоколы, близкие по возможностям к ОРС. Примером такого протокола может служить SuiteLink, использующийся пакетом FactorySuite компании Wonderware ([76]). Однако даже по сравнению с такими протоколами ОРС имеет важное преимущество, заключающееся в том, что ОРС является общепризнанным стандартом и потому поддерживается большим количеством продуктов. Это достоинство ОРС отмечается в ряде работ (например, [60, 77, 78]). Как показано в [79], использование ОРС при проектировании системы повышает степень взаимозаменяемости компонентов и, следовательно, облегчает расширение и модернизацию системы (этот факт также отмечается в [80]). Авторы [81] отмечают, что использование ОРС при создании АСУТП предприятия помогло объединить ранее разрозненные АСУ, решающие различные задачи, в единую систему. В [82] приводятся примеры использования ОРС, в которых этот стандарт позволил объединить большое число разнородных компонентов.
В работе [83] отмечается ещё одно достоинство ОРС. Все широко распространённые стандарты обмена данными в промышленных системах, существовавшие до ОРС, основывались на полевых шинах или последовательных линиях, что ограничивало максимальное удаление устройства от управляющего компьютера (так, например, интерфейс RS-232 допускает длину линии до 30 метров, RS-485 - до 1200 метров). К немногочисленным исключениям можно отнести протокол ModBus TCP ([84]), который использовался в сети Ethernet. Возможности этого протокола ограничены, поэтому он пригоден далеко не для всех систем. ОРС, основанный на COM/DCOM, осуществляет передачу данных через Ethernet - сеть, свободную от ограничений длины. Как будет показано ниже, COM/DCOM может использоваться не только в локальных, но и в глобальных сетях, что существенно облегчает построение автоматизированных систем, компоненты которых рассредоточены по большой площади.
Автоматизированная система, взаимодействие в которой осуществляется с помощью ОРС, содержит в себе ОРС-серверы различных производителей, управляющие устройствами или являющиеся шлюзами по отношению к другим протоколам. Каждый клиент подключается к тем или иным серверам в зависимости от того, какие данные ему требуются.
Однако следует отметить, что описанные выше достоинства в полной мере присущи только стандарту ОРС Data Access, который действительно получил широкое распространение и стал основным стандартом в своей области. Прочие стандарты группы ОРС не получили столь широкого распространения.
Стандарт ОРС Alarms and Events поддерживается далеко не во всех SCADA-системах. Главное назначение данного стандарта - это передача тревог, связанных с выходом значений параметров за пределы допустимых диапазонов. Однако SCADA-системы, в основном, имеют собственную подсистему генерации тревог такого типа, поэтому их производители не заинтересованы в том, чтобы передавать эти функции сторонним компонентам, так как это приведёт к дополнительным затратам по переработке кода системы, которые не окупятся, так как, лишившись части сложных функций, SCADA-система должна подешеветь. Из известных автору SCADA-систем стандарт ОРС Alarms and Events поддерживает только Genesis32. Коммерческие ОРСА&Е-серверы автору также неизвестны. Это в корне отличается от ситуации со стандартом ОРС Data Access, который поддерживают все без исключения современные SCADA-системы, а рынок OPCDA-серверов очень широк.
То же самое относится и к стандарту ОРС Batch: автору диссертации неизвестны ни SCADA-системы, ни серверы, поддерживающие его. SCADA-системы вообще редко используются для реализации операций дозирования и смешивания, для этого существует другой класс продуктов (в частности, упоминавшийся ранее пакет FactorySuite содержит SCADA-систему InTouch и систему операций дозирования и смешивания InBatch). АСУ, осуществляющие групповые операции, обычно очень сложны, и потому их доля в общем числе АСУ невелика. Из-за этого не существует массового рынка, участники которого были бы заинтересованы в продвижении единого стандарта.
Способы преодоления недостатков ОРС
Описанные в предыдущей главе недостатки ОРС могут быть достаточно эффективно преодолены теми или иными способами. Однако, основным неудобством этих способов является то, что они не закреплены ни в каких стандартах, компоненты, созданные различными разработчиками, не будут полностью взаимозаменяемы. Тем не менее, в рамках конкретной системы эти способы вполне работоспособны.
Ранее обсуждался вопрос о том, что поддержка команд и событий отсутствует в ОРС. С этим недостатком пришлось столкнуться при разработке автоматизированной системы центрального диспетчерского управления для уже упоминавшейся московской монорельсовой транспортной системы. ОРС-сервер используется для передачи данных между системой управления электроподвижным составом (СУ ЭПС) и системой центрального диспетчерского управления (СЦДУ), как это показано на рис. 4.2. Предлагаемые ниже алгоритмы передачи команд и событий опробованы и внедрены в данной системе. Указанные алгоритмы передачи команд и сообщений через ОРС Data Access достаточно универсальны и поэтому предлагаются здесь для создания OPCDA-шлюзов к другим подобным протоколам.
Бортовой контроллер электроподвижного состава связывается с диспетчерской системой с помощью оригинального протокола, основанного на TCP. Данный протокол подра Простые команды, не имеющие параметров, могут быть легко реализованы с помощью элемента данных, имеющего логический тип (сигнальной переменной), следующим обра зом: в обычном состоянии эта переменная имеет значение FALSE. При необходимости отдать команду клиент изменяет это значение на TRUE. Это изменение заставляет сервер послать команду устройству. После того, как команда выполнена (что именно служит подтверждением выполнения команды, зависит от протокола обмена с устройством) сервер возвращает сигнальной переменной значение FALSE. Клиент получает новое значение этой переменной таким же способом, как и значения других элементов данных, и при необходимости может каким-либо образом отреагировать на это обновление.
Описанный алгоритм может быть расширен и на случай команды, имеющей параметры. Для каждого из параметров ОРС-сервер должен завести элемент данных соответствующего типа. Клиент перед отправкой команды помещает в эти элементы данных требуемые значения. Сервер сохраняет изменённые значения во внутреннем буфере, но само по себе обновление этих элементов данных не инициирует отправку команды устройству. Команда будет отправлена только тогда, когда клиент изменит значение сигнальной переменной, связанной с данной командой, на TRUE. После этого сервер отправляет команду, подставляя в качестве параметров сохранённые ранее значения элементов данных. Если в ответ на команду устройство должно прислать какие-то значения, для этих значений также должны быть предусмотрены необходимые элементы данных в адресном пространстве сервера. Эти элементы данных должны быть обновлены до того, как сигнальная переменная получит значение FALSE, чтобы изменение служило для клиента сигналом о полном завершении обработки команды на уровне сервера.
Изложенный здесь алгоритм позволяет посылать устройству команды любой сложности, однако он не закреплена никаким стандартом. Любой разработчик ОРС-сервера вправе реализовать любой другой алгоритм отправки команд, который он сочтёт нужным. Кроме того, сервер не имеет возможности проинформировать клиента о том, что некоторый набор элементов данных служит для передачи устройству команды. Эта информация отображается только в документации сервера. Если разработчик клиента не полностью следует требованиям документации, могут возникнуть ошибки, которые трудно выявить.
Другая проблема, которая может возникнуть при использовании описанного алгоритма, связана с тем, что несколько ОРС-клиентов, использующих один сервер, могут мешать друг другу. Действительно, пусть первый клиент установил параметры в нужные ему значения, но не успел изменить сигнальную переменную до того, как квант времени был передан второму клиенту. Второй клиент также может изменить значения этих элементов данных. В результате, когда первый клиент вновь получит квант времени и изменит сигнальную переменную, устройство получит команду не с теми параметрами, с которыми он ожидал.
Выходом из этой ситуации может стать использование независимых наборов элементов данных, связанных с командой, для разных клиентов. В принципе, стандарт ОРС DA не запрещает создания сервером различных адресных пространств для разных клиентов, поэтому эти элементы данных можно расположить в разных адресных пространствах, и тогда переменные одного клиента будут недоступны остальным клиентам, что полностью исключит возможность взаимного влияния клиентов друг на друга. Однако, как уже упоминалось ранее, ОРС-серверы обычно разрабатываются с помощью Toolkit ов, которые редко предоставляют возможность создания независимых адресных пространств. Поэтому предпочтительнее выглядит компромиссный вариант: для каждого клиента создаётся независимый набор элементов данных для каждой команды, но эти элементы данных располагаются в общем адресном пространстве. На разработчика клиента ложится ответственность за то, чтобы использовать только свои элементы данных.
Простейшим вариантом запроса от устройства является запрос обновлённых значений параметров, причём сам запрос при этом параметров не содержит. В этом случае достаточно ввести в адресное пространство сервера элементы данных, соответствующие параметрам ответа. Задачей клиента в этом случае является своевременное обновление этих элементов данных, а сервер при получении запроса от устройства формирует ответ, руководствуясь текущими значениями параметров. В этом случае сервер может формировать ответ самостоятельно, не извещая клиента о получении запроса.
В более сложном случае запрос устройства содержит параметры, и значения параметров ответа зависят от содержимого запроса. В этом случае сервер не может самостоятельно сформировать ответ, потому что логика обработки запроса обычно реализуется клиентом, а сервер служит только шлюзом между протоколом устройства и ОРС. Для обработки подобных запросов можно ввести в адресное пространство сервера элементы данных, отвечающие параметрам запроса и ответа, а также элемент данных логического типа, который сигнализирует о необходимости ответа на запрос. В обычном состоянии этот элемент данных имеет значение FALSE
