Содержание к диссертации
Введение
Глава 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 19
3.9. Использование ОРС в АСУ для взаимодействия с устройствами 80
3.1.0. Быстродействие ОРС 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
Список литературы 163
- Основные принципы взаимодействия приложений
- Требования к системе контроля доступа
- Использование ОРС в АСУ для взаимодействия с устройствами
- Алгоритм работы нити, взаимодействующей с устройствами
Введение к работе
Современные АСУ являются сложными распределёнными системами, управляющими одновременно большим количеством разнородных объектов управления. Такие системы обычно состоят из нескольких уровней. В [1] описаны пять уровней АСУ предприятия: уровень низовой автоматики, контроллерный уровень, уровень человеко-машинного интерфейса (ЧМИ), уровень управления производством и уровень управления ресурсами предприятия. Каждый из этих уровней использует свои аппаратные и программные средства. Между уровнями идёт интенсивный обмен данными. Согласно [2] деление системы на уровни обусловлено не только различными требованиями, предъявляемыми к аппаратной и программной частям, но иерархией бизнес-процессов, связанных с АСУ.
На рис.1 показана типичная многоуровневая АСУ предприятия. На нижнем уровне системы находятся датчики и устройства сопряжения с объектом (УСО), которыми управляет низовая автоматика - простые устройства, обеспечивающие простейшее оперативное управление системой. Этими устройствами, в свою очередь, управляют программируемые логические контроллеры (ПЛК), которые могут быть как относительно простыми и низко-производительными, так и многопроцессорными системами, сравнимыми по производительности с мощными серверами. ПЛК управляют устройствами низовой автоматики, собирая с них данные и выставляя параметры процесса регулирования. Обычно контроллер управляет множеством устройств низовой автоматики, управляя через них несколькими ОУ (объектами управления). В некоторых случаях контроллеры могут взаимодействовать непосредственно с датчиками и УСО без помощи низовой автоматики.
ЧМИ (человеко-машинный интерфейс) может быть реализован непосредственно ПЛК, но в большинстве случаев для этого используются отдельные компьютеры, получающие от ПЛК данные. Операторы АРМ посредством ЧМИ осуществляют общее управление частью системы. На этом же уровне осуществляется сбор и архивация данных, поставляемых ПЛК. Уровни системы отдатчиков и УСО до уровня ЧМИ принято называть АСУТП.
На уровне управления производством осуществляется общее управление всеми АСУТП предприятия, что обеспечивает их совместную работу. Управление осуществляется, в основном, операторами АРМ, программное обеспечение не рассчитано на автономное принятие решений.
Управление производством
ВЕН
-L
Объекты управления
Рис. 1. Типичная структура АСУ предприятия
Уровень управления ресурсами предприятия на рис. 1 не показан. Этот уровень долгое время существовал независимо от остальных уровней АСУ, и до сих пор он далеко не везде связан с нижележащими уровнями.
Многие реальные системы, описанные в литературе, в целом соответствуют описанной иерархии, хотя уровни в них могут быть разделены не так чётко. Так, в АСУ Белорусского металлургического завода [3] ПЛК не имеют выхода в Ethernet и связываются с компьютерами уровня ЧМИ посредством технологической сети. Системы, описанные в [4, 5], соответствуют приведённой схеме, за исключением того, что в них отсутствует уровень управления. Практически полностью описанной схеме соответствуют системы, описанные в [6-11]. Интересный пример построения многоуровневой системе описан в [12] — в нём компьютеры уровня управления взаимодействуют непосредственно с контроллерами, а ЧМИ существует параллельно.
Необходимость разбиения системы на уровни хорошо иллюстрирует учебная САУ, разработанная на кафедре автоматики МИФИ [13]: она разбита на два уровня — уровень ПЛК и уровень ЧМИ, хотя используется только для управления одним двигателем и одним датчиком.
На уровнях низовой автоматики и контроллеров применяются технологические сети реального времени(РгойЬш, 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 может использоваться и для связи между уровнями ПЛК и ЧМИ, хотя такая возможность используется редко.
СОМЮСОМ является кроссплатформенной технологией. Существуют её реализации для различных операционных систем ([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 и ОРС для развития методов создания АСУ на основе этих технологий.
Разработка методики использования COM/DCOM в АСУ для интеграции в системе разнородных устройств.
Разработка типовых алгоритмов, повышающих эффективность взаимодействия СОМ- и ОРС-серверов с устройствами в АСУ за счёт распараллеливания работы.
Развитие методов доступа к СОМ-серверам через интернет для удалённого контроля работы АСУ.
Научная новизна диссертации
На основе анализа возможностей ОРС выявлены недостатки данных стандартов, заключающиеся в неспособности передавать команды от сервера устройству и от устройства к серверу. Предложены алгоритмы, позволяющие осуществить передачу команд и событий с помощью стандарта ОРС Data Access с целью облегчения создания АСУ за счёт использования стандартных возможностей SCADA-систем.
Проведена классификация протоколов обмена с устройствами по пяти признакам и на её основе предложен типовой алгоритм реализации таких протоколов ОРС-серверами и другим ПО, реализующим взаимодействие с устройствами в АСУ.
Разработаны алгоритмы функционирования типовых модулей АСУ - ОРС-серверов. Алгоритмы повышают скорость обмена данными с устройствами (в рассмотренных в диссертации случаях повышение достигало 250%).
Разработан метод доступа к ОРС-ссрвсрам через интернет с помощью стандартного браузера и технологии Internet Server Application Programming Interface (ISAPI), обеспечивающий контроль и управление работой устройств удалённой АСУ.
Практическая значимость диссертации
Разработаны методы организации АСУ, основанные на предложенных рекомендациях по настройке COM/DCOM для АСУ. Данные методы позволяют избежать ненужных запусков нескольких копий сервера и обеспечить контроль работы сервера со стороны пользователя.
Предложена методика создания использования COM/DCOM в АСУ, повышающая эффективность системы за счёт возможности интеграции в неё разнородных устройств.
Предложен алгоритм диагностирования связи с СОМ-сервером, обеспечивающий обнаружение потери связи с устройством в АСУ и её восстановления. Время реакции на потерю связи регулируется и может достигать 1-2 секунд.
Предложено использовать промежуточный ОРС-сервер в тех случаях, когда SCADA-система или иной клиенте использует прямое чтение для взаимодействия с удалённым ОРС-сервером. Использование промежуточного ОРС-сервера снижает нагрузку на сеть не менее чем на 22%.
Разработан метод создания АСУ, использующей интернет для доступа к данным
ОРС-серверов, управляющих устройствами, а также предложен алгоритм работы
соответствующих модулей АСУ.
Основные положения, выносимые на защиту
Повышение эффективности АСУ, использующих COM/DCOM для взаимодействия с устройствами, за счёт настройки COM/DCOM и выбора структуры СОМ-сервера.
Основные принципы взаимодействия приложений
Операционная система Windows позволяет организовывать многозадачность не только на уровне процессов, но и на уровне нескольких потоков исполнения внутри одного процесса. Поток исполнения принято называть нитью (thread). Между нитями могут возникать конфликтные ситуации, когда две или более нитей пытаются работать с одним и тем же ресурсом. Доступ нитей к разделяемым ресурсам должен осуществляться последовательно, т.е. быть синхронизированным. Операционная система самостоятельно не синхронизирует доступ к данным, но предоставляет разработчику программ все необходимые средства для этого. Средства синхронизации подробно описаны, например, в [28].
Если кокласс написан без учёта возможности вызова функций его интерфейсов из разных нитей, то при работе с многонитевым клиентом могут возникнуть проблемы, связанные с несинхропизированным доступом. С другой стороны, если операционная система будет запрещать вызовы функций ко класса из разных нитей, это может существенно уменьшить производительность из-за невозможности распараллеливания процесса. Для решения данной проблемы в COM/DCOM существуют нитевые модели, являющиеся гибким механизмом решения проблем, связанных с распараллеливанием процесса в сервере и в клиенте.
В диссертации излагаются только базовые принципы механизма нитевых моделей. Детальное исследование этого механизма выполнено в [29].
Центральным понятием нитевой безопасности в COM/DCOM является апартамент (подразделение). Апартамент можно представить как виртуальную оболочку, внутрь которой помещаются нити исполнения и созданные ими СОМ-объекты. Существует три вида апартаментов: главный STA (Singlehreaded Apartment), STA и МТА (Multihreaded Apartment). Каждая нить, прежде чем начать работу с COM/DCOM, должна войти в апартамент. Вход осуществляется вызовом функции Colnitialize или CoInitializeEx. Функция Colnitial-ize позволяет нити войти только в STA, CoInitializeEx - в STA или в МТА в зависимости от указанных параметров, Если требуемого апартамента ещё не существует, функция Colniialize(Ex) создаёт его. STA, созданный первым, становится главным STA. Каждый STA может содержать только одну нить, поэтому каждая нить, входящая в STA, порождает новый, свой собственный STA. МТА может содержать неограниченное число нитей, поэтому для каждого процесса операционная система создаёт не более одного МТА, в который помещаются все нити, которые должны быть в МТА.
Кокласс, реализуемый внутренним сервером, при регистрации в системном реестре должен обязательно указать свою нитевую модель. Возможные нитевые модели показаны в табл.1.1.
При вызове клиентом функции CoCreatelnstance(Ex) операционная система проверяет, может ли СОМ-объект быть созданным в том апартаменте, из которого был сделан вызов. Если нет, операционная система пытается найти подходящий апартамент среди уже созданных. Если такого апартамента нет, операционная система создаёт новый апартамент с требуемыми свойствами. Таким образом, процесс выбора апартамента происходит прозрачно как для сервера, так и для клиента.
Если СОМ-объект размещён в том же апартаменте, что и использующая его клиентская нить, то последняя получает указатели непосредственно на интерфейсы данного СОМ-объекта. Если же клиентская нить и СОМ-объект находятся в разных апартаментах, то операционная система создаёт экземпляр объекта-заместителя, с помощью которого производится передача вызовов через границы апартаментов. Такой механизм гарантирует, что сервер, не способный обрабатывать одновременные вызовы из разных нитей, будет получать эти вызовы последовательно.
Для сериализации вызовов операционной системой в STA создаётся невидимое окно. Заместитель из другого апартамента при поступлении ему вызова от его нити помещает в очередь сообщений этого окна соответствующее сообщение. Для обработки этих вызовов нить, расположенная в STA, должна иметь цикл обработки сообщений. При извлечении этого сообщения из очереди невидимое окно вызывает нужную функцию соответствующего СОМ-объекта, и результат вызова возвращается нити, чей заместитель поместил данное сообщение в очередь. Таким образом, СОМ-объект, расположенный в STA, всегда получает вызовы из той нити, которая также расположена в данном STA.
СОМ-объекты, расположенные в МТА, не нуждаются в сериализации вызовов, поэтому невидимое окно в МТА не создаётся.
Нити, расположенные в разных апартаментах, не могут передавать друг другу указатели на интерфейсы напрямую, так как на самом деле это указатели на заместители, а заместитель в каждом апартаменте должен быть свой. Для передачи указателей на интерфейс через границы апартаментов используются системные функции CoMarshallnterThreadlnter-facelnStream и CoGetlnterfaceAndReleaseStream.
Если нить, расположенная в STA, создаёт СОМ-объект, имеющий нитевую модель Free, он помещается в МТА. Требования к СОМ-объекту, помещаемому в МТА, являются подмножеством требований к СОМ-объекту, помещаемому в STA. С учётом того, что вызов функции через границы апартамента выполняется примерно в 1000 раз медленнее, чем напрямую ([20]), это кажется нерациональным. Но, кроме проблемы синхронизации доступа к данным, существует ещё проблема интерфейсов обратного вызова. Много нитевой сервер может делать вызовы функций интерфейсов клиентской стороны из любых своих нитей. Это может привести к краху однонитевого клиента, не синхронизирующего доступ к своим внутренним данным. Поэтому серверы, имеющие модель Free, загружаются всегда в МТА, и, следовательно, вызов функций интерфейсов обратного вызова осуществляется через границу апартамента, т.е. операционная система получает возможность позаботиться о се-риализации этих вызовов. Если же сервер имеет нитевую модель Both, он должен самостоятельно заботиться о том, чтобы вызовы функций интерфейсов обратного вызова осуществлялись только из той нити, в которой было установлено соединение с данным интерфейсом. Подробное обсуждение этого вопроса с примерами кода сделано в [30].
Однако даже если сервер не поддерживает интерфейсы обратного вызова, может возникнуть ситуация, когда модель Free для него будет предпочтительнее, чем Both. Это связано с тем, что кокласс внутри себя может использовать другие коклассы, поддерживающие МТА. Соответственно, для него может оказаться целесообразнее быть помещённым в МТА, чтобы оптимизировать эти вызовы. Этой ситуации посвящена работа [31].
Требования к системе контроля доступа
Как отмечено выше, технология COM/DC ОМ не была изначально рассчитана на применение в автоматизированных системах, поэтому, несмотря на внешнюю привлекательность этой технологии, вопрос её использования в АСУ для взаимодействия с устройствами требует отдельного изучения.
В настоящее время технология COM7DCOM широко применяется в АСУ (в частности, SCADA-системы используют технологии ОРС и ActiveX, основанные на COM/DCOM). Тем не менее, теоретический анализ преимуществ такого использования, насколько известно автору данной диссертации, отсутствует. Целью данной главы является выработка конкретных рекомендаций по использованию COM/DCOM в АСУ. Особое внимание уделено тому, какие задачи могут быть решены с помощью COM/DCOM и границам применимости данной технологии в АСУ.
В качестве примера АСУ, построенной с использованием COM/DCOM, рассматривается система контроля доступа (СКД), созданная при непосредственном участии автора. Эта система получила название ASC (Access Supervisory Control). Краткое описание указанной системы приведено в [49]. При разработке системы учитывались следующие требования: 1. Система должна иметь возможность организовывать взаимодействие устройств различного типа (здесь и далее под устройством подразумевается не только аппаратное устройство, но и любое виртуальное устройство, которое может потребовать управления и взаимодействия). 2. Система не должна ограничиваться каким-либо фиксированным набором типов устройств; должна существовать возможность расширять список допустимых типов устройств без перекомпиляции и перезапуска уже существующей части системы. 3. Если новое устройство уже известного системе типа может быть подключено к компьютеру без его перезапуска, система также должна иметь возможность подключить его без перезапуска. 4. Система должна быть защищенной от несанкционированного вмешательства в её деятельность. 5. При нехватке ресурсов одного компьютера для управления всеми устройствами администратор системы должен иметь возможность распределять задачи между несколькими компьютерами без потери функциональности. 6. Первоначальная установка системы и последующая её настройка, включая распределение задач между компьютерами, подключение новых устройств, регистрацию новых типов устройств, организацию взаимодействия устройств между собой и настройку прав доступа к тем или иным компонентам системы, должна выполняться средствами администрирования, без необходимости вносить какие-либо изменения в код системы.
Эти требования являются типичными для большинства АСУ, взаимодействующих с устройствами. В данной главе будет показано, что COM/DCOM позволяет создавать системы, удовлетворяющие всем вышеперечисленным требованиям, и, как следствие, эта технология может быть использована для построения разнообразных АСУ.
В базовом варианте СКД должна уметь управлять тремя устройствами: считывателем радиокарт, исполнительным устройством и устройством управления базой данных.
Считыватель радиокарт разработан ЗАО «РТСофт» и предназначен для использования совместно с бесконтактными пластиковыми идентификационными картами КИБИ-001 (далее - радиокарты), выпускаемыми ОАО «Ангстрем» (г. Зеленоград). Каждая радиокарта имеет свой уникальный номер, который распознаётся считывателем, когда карта оказывается в зоне действия его антенны (на расстоянии от 60 до 100 мм при поднесении радиокарты параллельно корпусу считывателя). Считыватель радио карт связывается с компьютером посредством интерфейса RS-485 (последовательный порт; возможна передача данных со скоростями 9600, 19200 и 57600 бит/с). Компьютер может опрашивать считыватели для того, чтобы узнать, поднесена ли к какому-либо из них радиокарта, и если да, то каков её номер. На одной линии RS-485 может размещаться до 64 считывателей. Каждый считыватель снабжен светодиодом, который может излучать красный, жёлтый и зелёный свет, и зуммером. Свечением светодиода и звучанием зуммера можно управлять, посылая считывателю соответствующие команды через интерфейс RS-485. Функциональная схема считывателя показана нарис. 2.1. Считыватель имеет двухпроцессорную структуру и включает в себя следующие блоки: 1. Антенна 2. Блок приемопередатчика (RFID-блок) 3. Два микроконтроллера 4. Блок программирования микроконтроллеров (ISP-блок) 5. 1-й интерфейс RS485 (для подключения внешних модулей телеметрии) 6. 2-й интерфейс RS485 (для подключения к HOST-системе) 7. Блок сопряжения с дополнительным устройством контроля 8. Блок сопряжения с исполнительными устройствами 9. Блок индикации и сигнализации 10. Блок питания
Использование ОРС в АСУ для взаимодействия с устройствами
Каждый из стандартов группы ОРС в области своего применения решает широкий спектр задач. Это позволяет гибко приспосабливаться к нуждам каждой конкретной задачи, но делает реализацию стандарта трудоёмкой. В первую очередь это касается реализации сервера. Поэтому есть задачи, для решения которых ОРС не является оптимальным выбором. Это касается, прежде всего, тех случаев, когда и сервер, и клиент создаются одним разработчиком для решения какой-либо частной задачи, и тиражирование клиента и сервера не предусматривается. В этом случае легче будет реализовать оригинальный протокол обмена данными, который содержит только то, что реально требуется в конкретной задаче и избавляет разработчика от реализации ненужных дополнительных возможностей. Но разработчики обычно создают ОРС-серверы с помощью специальных пактов, которые называются ОРС Toolkit ами ([74]). Эти пакеты расширяют возможности традиционных средств разработки программ, существенно облегчая разработку ОРС-серверов. При использовании ОРС Toolkit ов разработчик сервера должен реализовать только функции обмена данными с устройством и создания адресного пространства сервера, а все требования стандарта реализуются кодом ОРС Toolkit a. Такой подход сокращает область задач, для которых ОРС-сервер неприемлем из-за сложности разработки.
Главным достоинством стандартов ОРС по замыслу ОРС 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). АСУ, осуществляющие групповые операции, обычно очень сложны, и потому их доля в общем числе АСУ невелика. Из-за этого не существует массового рынка, участники которого были бы заинтересованы в продвижении единого стандарта.
Алгоритм работы нити, взаимодействующей с устройствами
Как уже было сказано выше, нить, взаимодействующая с устройством, должна реагировать на два внешних события: событие, сигнализирующее о необходимости выполнить задание (отправить запрос устройству), и событие, сигнализирующее нити о необходимости завершиться. Кроме того, так как устройство тоже может присылать запросы, нить должна выходить из состояния ожидания и при получении запроса от устройства. Если сервер дол roe время не посылает устройству никаких запросов, устройство может решить, что связь потеряна, поэтому в некоторых протоколах предусмотрена отправка пустого запроса с определённой периодичностью, если в течение оговоренного времени запросы не посылаются. В этом случае нить может выходить из состояния ожидания по истечении определённого таймаута для того, чтобы отправить пакет, подтверждающий исправность связи. Таким образом, существуют четыре причины, по которым нить может выйти из состояния ожидания: два типа сигналов от других нитей, получение запроса от устройства и истечение таймаута.
Для реализации ожидания удобно использовать не стандартные системные события, а события библиотеки Windows Sockets 2. Эти события подобны обычным системным событиям, но, в отличие от них, могут устанавливаться не только с помощью специальных функций, но и при появлении на сокете активности (например, при приходе информации). Создаются такие события с помощью функции WSACreateEvent, ожидание событий выполняется с помощью функции WSAWaitForMultipleEvents. Данная функция, как и функция WaitForMultipleObjects, позволяет указать таймаут, по истечении которого ожидание прекращается. Таким образом, отслеживание всех четырёх причин, выводящих нить из состояния ожидания, может выполняться одной этой функцией.
На рис. 5.5 изображена блок-схема работы нити, взаимодействующей с устройством, в том случае, когда инициатором установления связи (клиентом с точки зрения сокетов) служит ОРС-сервер. Когда соединение с устройством ещё не установлено, нить всё равно может получать задания, поэтому предусмотрена проверка наличия заданий и до установления связи. При получении задания в данный момент нить просто заполняет область памяти, через которую передаётся результат выполнения задания, информацией о том, что задание выполнить невозможно (в этому случае ОРС-сервер устанавливает соответствующим переменным плохое качество).
Как уже было сказано выше, предполагается, что все запросы (в том числе и пустой запрос, отправляемый для подтверждения наличия связи) требуют ответа. Однако, может возникнуть ситуация, когда сервер и устройство отправляют друг другу запрос практически одновременно, поэтому вместо ответа на свой запрос сервер получит встречный запрос устройства. В этом случае сервер отправляет ответ на запрос устройства и снова пытается получить ответ на свой запрос. Выше оговаривалось, что ни сервер, ни устройство не должны посылать запросы, если сами получили запросы, на которые ещё не ответили, по этому сервер может только один раз получить запрос вместо ответа. Если, ответив на запрос, он снова получает запрос вместо ответа, это говорит о проблемах связи, поэтому при повторном получении запроса сервер должен фиксировать ошибку. Однако для простоты на блок-схеме показана ситуация, когда сервер обрабатывает неограниченное количество запросов вместо ответа.
Следует отметить, что в некоторых транспортных протоколах (например, в UDP) не гарантируется доставка пакетов адресату в той очерёдности, в которой они были отправле ны. Поэтому, если устройство сразу после отправки ответа отправит запрос, этот запрос сервер может получить раньше, чем ответ, несмотря на то, что устройство строго выполняет требования протокола. Поэтому при использовании подобных протоколов допустимо получение не одного, а двух запросов вместо ответа.
Обработка запроса от устройства может понадобиться в одном из трёх мест нити: при выходе из режима ожидания из-за получения запроса от устройства, при получении запроса вместо ответа на запрос и при получении запроса вместо ответа на пустой запрос по таймауту, поэтому обработку запроса целесообразнее вынести в отдельную функцию. Устройство данной функции будет обсуждаться ниже.
На блок-схеме для краткости не показаны действия нити при обнаружении ошибок (которые могут быть связаны как с потерей связи, так и с получением пакета, который в рамках используемого протокола рассматривается как недопустимый). В этом случае нить должна разрывать связь, передавать информацию о невозможности выполнения задания, если в этот момент выполняется задание, и возвращаться к началу, чтобы заново установить связь.
Чтобы не допустить долгое бездействие нити при попытке соединения или чтения пакета в том случае, когда связь отсутствует, сокет предпочтительнее использовать в неблокирующем режиме (стандартный режим работы сокета - блокирующий. В нём нить, вызывающая функции для работы с сокетом, остаётся в приостановленном состоянии до тех пор, пока требуемая функция не будет выполнена. В неблокирующем режиме возможна установка таймаута для операции с сокетом).
Действия по обработке запроса от устройства зависят от того, какой ответ требуется. По этому признаку запросы можно разделить иа три типа: 1. Запрос, не требующий передачи данных устройству в ответ. К запросам такого типа относятся, например, уведомления от устройства об изменении значений параметров. Ответом на такой запрос служит квитанция, не несущая никакой информации, кроме той, что сервер получил запрос и опознал его как допустимый. 2. Запрос, не требующий от ОРС-клиента никаких действий по подготовке ответа. Примером такого запроса может служить запрос устройством последних значений каких-либо параметров. Сервер формирует ответ на основании значений, хранящихся в данный момент в буфере.
