автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.06, диссертация на тему:Методы и алгоритмы использования технологии COM/DCOM и стандарта OPC для взаимодействия с устройствами в автоматизированных системах управления

На правах рукописи

Григорьев Антон Борисович

Методы и алгоритмы использования технологии СОМЛ>СОМ и стандарта ОРС для взаимодействия с устройствами в автоматизированных системах управления

Специальность : 05.13.06 - Автоматизация и управление технологическими процессами и производствами (по отраслям) 05.13.11 - Математическое и программное обеспечение вычислительных машин, комплексов и локальных сетей

Автореферат

диссертации на соискание учёной степени кандидата технических наук

Автор:

Москва-2005 г.

Диссертация выполнена в Московском инженерно-физическом институте (государственном университете).

Научный руководитель

доктор технических наук, профессор

Шагурин И.И.

Официальные оппоненты:

доктор технических наук, профессор

Жданов В.С.

кандидат технических наук, доцент

Леонов Д.Г.

Ведущая организация:

ДОАО «ОргЭнергоГаз»

Защита диссертации состоится 16 мая 2005 г. в 16:30 в конференц-зале МИФИ на заседании диссертационного совета Д212.130.02 по адресу: 115409, Москва, Каширское шоссе, 31. Телефоны: 324-84-98,323-91-67.

С диссертацией можно ознакомится в библиотеке МИФИ.

Автореферат разослан « «й/^т^УА» 2005 г.

Ученый секретарь диссертационного совета доктор технических наук,

профессор

Петров Г.В.

2.00 40933

ОБЩАЯ ХАРАКТЕРИСТИКА ДИССЕРТАЦИИ

Актуальность темы

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

Из вышесказанного следует, что выбор средств связи между компонентами автоматизированной системы управления является важной задачей. Основным требованием, предъявляемым к этому средству (протоколу) связи, является обеспечение надёжности соединения. Весьма важным фактором является универсальность протокола, его способность передавать разнородную информацию как малых, так и больших объёмов с достаточно высокой скоростью. В качестве других особенностей протокола следует отметить также возможность защиты данных и простоту реализации.

Компоненты верхнего уровня автоматизированных систем управления в настоящее время часто работают под управлением различных версий операционной системы Windows NT/2000/XP. Данная система предоставляет стандартные средства для взаимодействия между приложениями, в том числе и удалёнными. Применение этих средств позволяет существенно упростить разработку компонентов верхнего уровня АСУ.

Основным средством межпрограммного взаимодействия в Windows является технология COM/DCOM. Так как выгоды от использования встроенной технологии очевидны, COM/DCOM активно используется во многих продуктах для АСУ. Однако особенности применения данной технологии для подобных систем недостаточно изучены, в результате чего многие из этих продуктов некорректно ведут себя во внештатных ситуациях или неоптимальным образом используют возможности COM/DCOM.

Отдельно следует упомянуть семейство стандартов ОРС (OLE for Process Control), основанное на 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 автоматизирован процесс распознания несанкционированного доступа и передача управляющих воздействий запирающим устройствам и сигнализации.

• Создан ОРС-сервер для ISaGRAF, использующийся в настоящее время в системах автоматизации нефтедобывающих и нефтехимических комплексов ОАО «Южоренбургнефть» и ОАО «Востсибнефтегаз» (всего десять систем) для управления кранами, задвижками в нефтяных резервуарах.

• ОРС-сервер для ISaGRAF внедрён в производстве бетона (система АСУБЕСТ разработки ООО «Оригон Строй») для автоматизации операций дозирования и смешивания исходных компонентов бетона.

• Разработаны ОРС-серверы для контроля и диспетчерского управления группой зданий, эксплуатируемой в настоящее время в микрорайоне 10А управы №4 г. Зеленограда. Автоматизировано слежение за различивши эксплуатационными и технологическими параметрами здания, накопление данных в архивах и анализ из динамики.

• Создан и передан в эксплуатацию ОРС-сервер для охранной системы, использующейся в московском офисе ТНК. Автоматизирован процесс распознавания пропусков и учёт рабочего времени.

• Создан ОРС-сервер для связи между системой центрального диспетчерского управления (СЦДУ) московской монорельсовой транспортной системы и электроподвижным составом (ЭПС). Данный сервер позволил автоматизировать управление движением поездов на линии.

• Для связи между СЦДУ и автоматизированной системой диспетчерского управления энергообеспечением (АСДУ-Э) используется промежуточный ОРС-сервер, как это предложено в диссертации. С его помощью автоматизирован процесс регулирования работы системы энергообеспечения в зависимости от потребностей других подсистем.

• Для связи между диспетчерской системой управления кондиционированием, вентиляцией, отоплением Успенской Звонницы и системой контроллеров Dec используется промежуточный ОРС-сервер, предложенный в диссертации. Автоматизирован процесс управления устройствами, поддерживающими микроклимат в помещении, в зависимости от внешних условий и установок оператора.

• Разработаны шлюзы DDE-OPC и OPC-SuiteLink, использующиеся для решения коммуникационных задач в АСУ, разработанных ЗАО «РТСофт» (в системе автоматизации Южнокузбасской ГРЭС и в информационно-управляющей системе, внедряемой в ОАО «Тюментрансгаз»). Эти продукты используются для передачи данных между компонентами уровня ЧМИ.

• Ведутся работы по разработке и внедрению ряда ОРС-серверов, использующих алгоритмы распараллеливания и взаимодействия с устройствами, предложенные в диссертации, и обеспечивающих взаимодействие с антипомпажными системами, системами управления газокомпрессорными цехами и станциями, системами телемеханики для управления газовыми кранами и газоизмерительными системами в информационно-управляющей системе (ИУС), внедряемой в ОАО «Тюментрансгаз». Эта система

автоматизирует сбор информации о работе устройств, обеспечивающих транспорт газа, и составление отчётов на основании этих данных.

• В рамках создания ИУС для ОАО «Тюментрансгаз» разработан промежуточный ОРС-сервер с дополнительными возможностями модификации данных. Данный сервер позволяет ИУС отслеживать резкие перепады давления на компрессорных станциях и вовремя информировать о них оператора, а также автоматически составлять отчёты о перепадах.

Основные положения, выносимые на защиту

• Повышение эффективности АСУ, использующих COM/DCOM для взаимодействия с устройствами, за счёт настройки COM/DCOM и выбора структуры СОМ-сервера.

• Разделение драйвера устройства на локальную и удалённую часть как основа методики использования COM/DCOM в распределённых АСУ.

• Алгоритмы передачи параметризованных команд и событий с помощью стандарта ОРС Data Access, позволяющие использовать встроенные возможности SCADA-систем.

• Применение промежуточного ОРС-сервера для повышения скорости обмена с удалённым ОРС-сервером и диагностирования потери связи при использовании SCADA-систем, имеющих проблемы с реализацией ОРС.

• Алгоритмы распараллеливания работы и взаимодействия с устройством ОРС-сервера, повышающие эффективность работы АСУ за счёт уменьшения времени простоя процессора.

• Метод создания с помощью ISAPI-библиотек человеко-машинного интерфейса для удалённого доступа к ОРС-серверам через интернет.

Апробация результатов диссертации

Результаты диссертации докладывались и обсуждались на научной сессии МИФИ-2003, секция А-1 (Москва, 2003 г.).

Публикации

По результатам диссертации опубликовано 8 статей и 1 тезисы доклада.

Структура и объём диссертации

Диссертация состоит из введения, 6 глав, заключения и списка литературы, включающего 123 наименования. Содержание диссертации изложено на 171 странице машинописного текста, включая 19 рисунков и 13 таблиц к основному тексту.

СОДЕРЖАНИЕ ДИССЕРТАЦИИ

Технология COM/DCOM, появившаяся впервые в операционной системе Windows NT 3.5 в 1993 году, предназначена для обеспечения взаимодействия программ, работающих на одном или на разных компьютерах. Достоинствами данной технологии являются:

• Строгое разделение интерфейсной части сервера и его реализации

• Возможность использовать различные транспортные протоколы без внесения изменений в приложения

• Возможность полнодуплексной связи между клиентом и сервером

• Решение проблем межплатформенного взаимодействия

• Гибкие настройки безопасности

• Поддержка на уровне операционной системы

Технология COM/DCOM разрабатывалась, в первую очередь, для офисных приложений и распределённых систем управления базами данных. Однако благодаря её универсальности область использования данной технологии может быть существенно шире. Широкое распространение COM/DCOM привело к появлению большого числа инструментов для разработки приложений, ориентирующихся на эту технологию. Высокоуровневая технология связи позволяет разработчику сосредоточиться на решении проблем общего характера, не отвлекаясь на низкоуровневые детали реализации обмена данными. Это существенно сокращает срок разработки приложений, повышает их надёжность и совместимость, что делает COM/DCOM весьма привлекательным решением в том числе и для АСУ.

Требования к типичному СОМ-серверу устройства в АСУ

СОМ-серверы очень удобны для обеспечения доступа к аппаратным устройствам на высоком уровне. Подобный сервер осуществляет низкоуровневое (обычно - на уровне сетевого протокола) управление устройством, а для своих клиентов предоставляет набор СОМ-интерфейсов, с помощью которых они могут влиять на работу устройства и получать данные о его текущем состоянии. Благодаря разделению интерфейса и реализации может быть обеспечен единообразный доступ к различным устройствам через ряд серверов, реализующих одинаковый набор интерфейсов.

Интерфейсы, экспортируемые сервером, могут регламентироваться каким-либо стандартом (самыми известными такими стандартами являются стандарты группы ОРС) или разрабатываться специально для нужд конкретной АСУ. При этом к СОМ-серверам, управляющим устройствами, предъявляются следующие требования:

• Запуск сервера не должен зависеть от запуска клиента: сервер должен быть самостоятельным приложением, так как он обычно должен осуществлять управление устройством независимо от того, используется ли он в данный момент клиентом

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

• Клиенты должны иметь возможность получать от сервера уведомления о событиях, возникающих в устройстве

• Сервер не должен передавать клиенту данные, не имеющие смысла вне адресного пространства сервера

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

В диссертации показано, что все перечисленные требования выполняются при использовании СОМ/ОСОМ. Во-первых, данная технология позволяет создавать СОМ-серверы в виде обычных исполняемых файлов, которые могут быть запущены автономно. Такие серверы без дополнительной настройки позволяют подключаться неограниченному числу клиентов. По умолчанию в целях безопасности для каждой клиентской учётной записи запускается собственный экземпляр сервера, но это легко отменить с помощью системных настроек. Те же системные настройки позволяют выполнять авторизацию клиентов и запрещать доступ тем, кому администратор системы не дал соответствующих прав. Во-вторых, механизмы интерфейсов обратного вызова и точек соединения, предусмотренные в СОМ/ОСОМ, могут использоваться для реализации событий.

Процесс передачи данных из одного приложения в другое носит в СОМ/ОСОМ название маршалинг. На уровне системы поддерживается маршалинг многих простых типов (в т.ч. через указатели), строк, массивов (в т.ч. безопасных массивов, поддерживаемых на уровне системы) и структур (в т.ч. содержащих указатели на другие структуры, строки или массивы). При необходимости передачи данных нестандартного типа разработчик сервера может вмешаться в процесс маршалинга.

Скорость передачи данных в COM/DCOM достаточно высока: при передаче по сети четырёх байт снижение скорости по сравнению с протоколом TCP/IP составляет 35%, при больших объёмах данных относительная доля служебной информации COM/DCOM уменьшается, и, следовательно, разница скоростей уменьшается. Такая скорость является достаточной для большинства АСУ.

На основании проведенного анализа в диссертации делается вывод, что технология COM/DCOM позволяет создавать серверы устройств, удовлетворяющие типичным требованиям к подобным серверам для АСУ.

Оптимальные системные настройки COM/DCOM для АСУ

В диссертации рассмотрены возможные системные настройки для DCOM и проведён анализ важности каждой из них для АСУ. Показано, что неправильные настройки могут сделать работу автоматизированной системы неустойчивой или вообще невозможной, приведены рекомендации по выбору правильных настроек.

Настройки для DCOM в целом и для отдельных СОМ-серверов в частности позволяет выполнять стандартная системная утилита DcomCnfg. Возможна настройка следующих параметров: уровня безопасности, прав доступа к серверу, места запуска сервера, учётной записи сервера и используемых транспортных протоколов. Очевидно, что приемлемость тех или иных настроек зависит задач, для которых используются серверы.

Уровень безопасности позволяет серверу проверять, под какой учётной записью запущен клиент, подключившийся к нему. При необходимости можно также включить защиту пакетов от изменения и шифрование. Если сервер проверяет клиента, можно выборочно запрещать или разрешать тем или иным пользователям подключаться к серверу. Данные настройки позволяют гибко управлять политикой безопасности в АСУ. Следует отметить, что система безопасности COM/DCOM основана на системе безопасности Windows. Поэтому, если система безопасности Windows не может быть задействована (например, если используется кроссплатформенное взаимодействие или взаимодействие через интернет), приходится отменять проверку пользователя и разрешать подключение всем пользователям.

Если клиент не указывает место запуска сервера, система по умолчанию пытается запустить его на том же компьютере, на котором работает клиент. С помощью системных настроек можно заставить сервер запускаться на удалённом компьютере. Эта опция очень полезна при использовании ранее разработанных компонентов (например, SCADA-системы Citect), которые не поддерживают в явном виде подключение к удалённым серверам. Однако она не может быть использована в тех

случаях, когда клиенты явно указывают, где именно должен запускаться сервер.

Неправильная настройка учётной записи сервера может блокировать работу АСУ. По умолчанию для сервера выбирается та учётная запись, под которой работает клиент. Если несколько клиентов, запущенных на разных компьютерах под разными учётными записями, пытается использовать один и тот же сервер, система запускает несколько экземпляров этого сервера. Эти экземпляры начинают конфликтовать из-за неразделяемых ресурсов, что приводит к невозможности нормальной работы. В диссертации показано, что для АСУ наилучшим вариантом является использование СОМ-сервера в качестве системной службы. Это возможно в случае, если серверы специально разрабатывались как службы. Для других типов серверов рекомендуется использовать учётную запись пользователя, вошедшего в систему.

Настройка транспортных протоколов позволяет использовать один и тот же сервер в сетях с различной конфигурацией. По умолчанию используется протокол TCP, который достаточно универсален и поэтому пригоден в большинстве случаев. В некоторых АСУ могут понадобиться ограничения на используемые для COM/DCOM порты (например, для совместимости с брандмауэром) или выбор более подходящего для данной сети протокола. В частности, при связи через интернет может быть полезен протокол Tunneling TCP, который транслирует все потоки данных через 80-ый порт, который брандмауэры оставляют открытым.

Анализу методов использования COM/DCOM для управления АСУ через интернет посвящен отдельный раздел диссертации. Полученные при этом выводы изложены ниже.

Диагностика и восстановление связи в COM/DCOM

Одним из главных достоинств COM/DCOM является прозрачность местонахождения сервера. Под этим подразумевается, что клиент единообразно работает как с локальным, так и с удалённым сервером. Однако разработчики COM/DCOM не уделили достаточное внимание решению проблем разрыва и восстановления связи. Эти проблемы являются несущественными при использовании локального соединения, но обязательно должны быть решены при организации работы с удаленным сервером. На основании анализа транспортного уровня COM/DCOM в диссертации предложен алгоритм эффективного контроля разрыва связи и её восстановления. Данный алгоритм многократно опробован автором на практике и в настоящее время используется в нескольких АСУ.

Согласно документации DCOM, ситуации потери связи с удалённым СОМ-сервером можно разделить на три основные группы:

• Неисправность сети, приведшая к потери связи менее чем на 6 минут

• Неисправность сети, приведшая к потере связи более чем на 6 минут

• Внеплановое завершение работы СОМ-сервера по тем или иным причинам

В случае использования протокола без соединения при разрыве связи менее чем на 6 минут система автоматически восстанавливает связь между клиентом и созданным для его обслуживания СОМ-объектом сервера. Если связь потеряна на более длительное время, система уничтожает СОМ-объект, используемый клиентом, что приводит к выгрузке сервера, если он не используется другими клиентами. В случае завершения работы СОМ-сервера система не перезапускает его и не создаёт СОМ-объекты для взаимодействия с клиентом.

Таким образом в большинстве случаев связь между сервером и клиентом автоматически не восстанавливается. Восстановить её должен клиент.

В диссертации отмечается, что клиент не может определить, по какой причине потеряна связь: из-за неполадок в сети или из-за проблем на стороне сервера. Поэтому рекомендуется не дожидаться автоматического восстановления связи, а начать попытки её самостоятельного восстановления. Чтобы избежать при этом утечки ресурсов, необходимо корректно освободить все ссылки на старые СОМ-объекты.

Диагностировать разрыв связи клиент может только в том случае, если он вызывает функции сервера: в этом случае функция вернёт код соответствующей ошибки. Для клиентов, которые работают только по событиям от серверов, обнаружение разрыва связи невозможно, за исключением тех случаев, когда от сервера должны приходить события с известной периодичностью. Поэтому для своевременного обнаружения проблемы клиент должен периодически вызывать какие-либо функции сервера. В диссертации показано, что использование функций интерфейса Шпкполто для этих целей неприемлемо из-за буферизации их вызовов на уровне заместителя в адресном пространстве клиента.

Если функции сервера постоянно вызываются только для того, чтобы проверить состояние связи с сервером, сеть оказывается загруженной бесполезными пакетами. Существенно уменьшить эту загрузку позволяет предложенный в диссертации комбинированный алгоритм проверки связи: клиент вызывает проверочную функцию только тогда, когда от сервера слишком долго не приходит никаких событий. Если сервер достаточно часто делает вызовы интерфейсов клиента, проводить дополнительные проверки связи не требуется.

Попытка вызова функций сервера, связь с которым потеряна, может занимать достаточно длительное время. В диссертации предлагается избегать безуспешных вызовов функций с помощью пингования в рамках протокола 1СМР (пингование - механизм эхо-ответа на полученный пакет, позволяющий отправляющей стороне получить гарантию исправности линии связи). Успешно выполненное пингование не даёт гарантии успешного вызова функции, но отсутствие ответа на пинг позволяет исключить выполнение значительной части заведомо безуспешных попыток.

Серверу также целесообразно пинговать клиентский компьютер перед использованием функций интерфейсов обратного вызова. Однако стандартные системные средства не позволяют серверу узнать 1Р-адрес клиентского компьютера. Следовательно, клиент должен специально оповестить сервер о своём местонахождении. В литературе предложены способы оповещения сервера об адресе клиента с помощью расширений протокола КРС, использующегося в СОМЛЗСОМ. В диссертации показаны недостатки данного метода и предложено выполнять оповещение через специально предусмотренную для этих целей функцию в одном из интерфейсов сервера.

Методика построения АСУ на базе СОМ/РСОМ

Опыт практического применения СОМЯ)СОМ в системе контроля доступа (СКД), разработанной при участии автора диссертации, показывает, что данная технология помогает делать автоматизированные системы управления масштабируемыми и модернизируемыми. Основой масштабируемости и модернизируемости является разделение системы на ряд компонентов, взаимодействующих через стандартные абстрактные интерфейсы. Благодаря этому СКД можно развернуть как на одном компьютере для управления небольшой системой, так и на сотнях компьютеров, управляющих системой из десятков тысяч устройств.

Аппаратной основой СКД является считыватель радиокарт, функциональная схема которого приведена на Рис. 1. Считыватель реагирует на поднесение к его антенне радиокарты - бесконтактной пластиковой идентификационной карты КИБИ-001, выпускаемой ОАО «Ангстрем» (г. Зеленоград). С управляющим компьютером считыватель связывается через интерфейс 118-485. Управляющий компьютер постоянно опрашивает подключенные к нему считыватели на предмет обнаружения поднесённой радиокарты и при необходимости может отправлять команды. Кроме того, через тот же интерфейс к компьютеру подключаются исполнительные устройства, которые при получении команды подают на внешние выводы напряжение, что может служить сигналом для электронного замка или турникета.

Рис. 1. Функциональная схема считывателя радиокарт

Для управления каждым типом устройств используется два СОМ-сервера, названные ехе-сервером и dll-сервером. Ехе-сервер является системным сервисом, который выполняется на компьютерах, к которым подключены соответствующие устройства. Данный сервер осуществляет непосредственное взаимодействие с устройством. Каждый из таких серверов экспортирует оригинальный набор СОМ-интерфейсов, которые разрабатываются с учётом специфики устройства. Клиентом ехе-сервера является соответствующий ему dll-сервер, основная задача которого -реализация пользовательского интерфейса для управления данным устройством. Всё dll-серверы экспортируют одинаковый набор интерфейсов, которые позволяют их клиенту отображать в своём окне соответствующий пользовательский интерфейс, а также получать от устройства события и отдавать ему команды.

Клиентами dll-серверов являются приложения ASC и ASCView. ASC используется для настройки устройств (через создаваемый dll-серверами интерфейс пользователя) и создания сценариев, благодаря чему команды одному устройству (или устройствам) могут выполняться при возникновении событий в другом устройстве. ASCView может использоваться для наблюдения за состоянием устройств.

События передаются через специальный СОМ-сервер ASCSysEventSrv, благодаря которому события от устройства может получить не только тот экземпляр ASC, который управляет данным устройством, но и другие экземпляры ASC, работающие на удалённых компьютерах. Благодаря этому можно создавать распределённые системы, в которых каждый узел с модулем ASC управляет своим набором устройств, и эти узлы взаимодействуют между собой. С другой стороны, при небольшом числе количестве устройств можно обойтись одним компьютером с одним модулем ASC, и на тот же компьютер установить ASCView для организации АРМа. Прозрачность местонахождения клиента и сервера в COM/DCOM позволяет создавать модули, которые легко соединяются друг с другом независимо от того, находятся они на одном компьютере или на разных, и какие протоколы могут быть использованы в сети.

Использованием COM/DCOM определяется ещё одно важное достоинство СКД: благодаря высокоуровневым СОМ-интерфейсам можно существенно расширить набор устройств, с которыми эта система может работать. Так как реализация отделена от интерфейса, возможно создание драйверов (в терминах СКД) для различных устройств: если эти драйверы поддерживают достаточно универсальный интерфейс для взаимодействия с ASC и ASCView, устройство может быть легко интегрировано в систему. В настоящее время кроме считывателя и исполнительного устройства реализованы драйверы для датчиков повреждения стекла, охранного шлейфа, видеокамер и поворотных устройств для них, а также драйверы виртуальных устройств, управляющих базами данных.

Таким образом, можно отметить следующие преимущества использования COM/DCOM в АСУ :

• Лёгкость настройки полученных модулей для работы в разных условиях (в том числе и при необходимости работы разных модулей на разных платформах).

• Возможность построения из одних и тех же модулей как простых, так и сложных распределённых систем.

• Лёгкость введения в систему дополнительных устройств как уже известных типов, так и новых типов.

• Сокращение (примерно на 10-12 человеко-месяцев) трудоёмкости разработки модулей благодаря широкой поддержке со стороны операционной системы и сред разработки приложений.

На основе анализа СКД предложена методика построения АСУ на основе COM/DCOM со следующими основными положениями:

• Для управления устройствами используются СОМ-серверы, работающие как системные службы.

• Данные серверы создают отдельный СОМ-объект для каждого клиента, и специальный объект для взаимодействия с каждым из устройств, и эти объекты при необходимости взаимодействуют между собой.

• Для обеспечения более тесной интеграции каждому такому СОМ-серверу придаётся парный ему СОМ-сервер, реализованный как внутренний. Задача внутреннего сервера - обеспечить взаимодействие с интегрирующим модулем, более тесное, чем это можно сделать в рамках COM/DCOM.

Использование ОРС в АСУ

Семейство стандартов ОРС (OLE for Process Control) предназначено для унификации обмена данными между устройствами и потребителями данных, в роли которых обычно выступают SCADA-системы. В настоящее время часть стандартов ОРС основана на XML и SOAP, но большая часть стандартов основана на COM/DCOM. Стандарты ОРС решают множество различных задач обмена данными с устройствами, но широкое распространение получил только один стандарт из этой группы -ОРС Data Access. Этот стандарт предназначен для передачи текущих значений параметров, контролируемых устройством. В нём также предусмотрены управляющие воздействия, заключающиеся в том, что клиент может изменять значения параметров. Здесь, как и во многих других работах, под термином «ОРС» далее будет пониматься ОРС Data Access, если иное не указано явно.

Преимущества использования ОРС в АСУ те же, что и при использовании COM/DCOM: приспособляемость системы к различным сетям, масштабируемость и модернизируемость. Дополнительным преимуществом является широкая поддержка стандарта ОРС производителями продуктов для автоматизированных систем. Эта поддержка позволяет объединять различные компоненты в одной системе.

Возможности стандарта ОРС для обмена текущими значениями параметров достаточно широки и в подавляющем большинстве случаев даже избыточны по сравнению с реальными потребностями АСУ. Тем не менее, обмен данными с устройствами не ограничивается обменом значениями параметров. Распространённым случаем является также отправка устройству команд и получение от него сообщений о событиях. В общем случае как команды, так и события могут иметь входные и выходные параметры.

Пересылку команд и событий, в принципе, можно реализовать через специально разработанные СОМ-интерфейсы, реализованные в ОРС-сервере в дополнение к стандартным интерфейсам ОРС. Однако такой подход нарушает совместимость, которая достигается за счёт

использования ОРС. Более того, семейство ОРС включает в себя стандарт, специально предназначенный для передачи событий - ОРС Alarms and Events. Но этот стандарт практически не получил поддержки у производителей SCADA-систем, поэтому его использование существенно снижает совместимость с ними. Вследствие этого возникает потребность приспособить ОРС Data Access для решения несвойственных данному стандарту задач: пересылки команд и событий. Это позволит сохранить совместимость с большинством современных SCADA-систем.

Поддержка новых возможностей должна быть основана на дополнительных соглашениях, которым будут следовать как сервер, так и клиент. Для передачи команды с параметрами в диссертации предлагается следующее решение: для всех входных и выходных параметров каждой команды в ОРС-сервере создаются переменные соответствующих типов. Кроме того, для каждой команды создаётся сигнальная переменная логического типа. Эта переменная по умолчанию имеет значение False. Когда ОРС-клиенту требуется отдать команду устройству, он сначала устанавливает нужные значения переменных для её входных параметров, а затем устанавливает сигнальную переменную данной команды в True. Изменение этой переменной служит для ОРС-сервера сигналом к отправке команды устройству. После того как устройство выполнит команду и вернёт серверу значения выходных параметров, он сначала обновляет значения переменных, соответствующих этим параметрам, а затем сбрасывает значение сигнальной переменной в False. Это изменение служит клиенту сигналом о том, что команда выполнена, а значения выходных параметров обновлены.

Аналогичный алгоритм предлагается и для получения событий от устройства. При получении события ОРС-сервер обновляет значения переменных, соответствующих входным параметрам события, а затем устанавливает сигнальную переменную события в True, что служит для клиента сигналом о получении события. Выполнив обработку события, клиент обновляет переменные, соответствующие его выходным параметрам, а затем сбрасывает сигнальную переменную в False. Это изменение вынуждает ОРС-сервер отправить устройству ответ на событие.

Описанные алгоритмы передачи команд и событий разработаны и опробованы в ходе работы над автоматизированной системой диспетчерского управления Московской монорельсовой транспортной системой (Рис. 2). ОРС-сервер, работающий по описанному алгоритму, используется для связи между СЦДУ и ЭПС. Испытания на макете показали пригодность данного алгоритма для решения поставленных задач.

Уровень управления

(АРМы диспетчеров)

Уровень ЧМИ (кластерный сервер со ЭСАЛА-сисгемой)

У СЦДУ

Контроллерный уровень (\/МЕ-42, центральный контроллер ЭПС)

Низовая автоматика,

датчики, ИУ и т.д.

Объект управления (ЭПС)

у СУ ЭПС

Рис. 2. Система диспетчерского управления Московской монорельсовой транспортной системы (фрагмент)

При использовании описанных алгоритмов два клиента, работающих с одним ОРС-сервером, могут конфликтовать при попытке отдать одинаковые команды с разными параметрами или по-разному обработать одно событие. В диссертации для преодоления этой проблемы

предлагается использовать независимые наборы переменных для каждого клиента. Предложены два способа создания независимых наборов. Первый способ предполагает создание независимых наборов переменных на уровне СОМ-объекта сервера. При использовании данного способа новый набор переменных создаётся сервером автоматически каждый раз при подключении нового клиента. Фактически, одни и те же имена переменных идентифицируют разные переменные для разных клиентов, поэтому клиенты не мешают друг другу. Второй способ заключается в том, что в адресном пространстве сервера заранее создаётся необходимое число наборов переменных. Эти переменные имеют разные имена, и каждый клиент должен использовать свой набор. Первый способ обеспечивает большую гибкость и безопасность, чем второй, т.к., во-первых, количество наборов переменных определяется реальным количеством клиентов, а во-вторых, каждый клиент может работать только со своим набором переменных. При использовании второго способа клиент должен следить за тем, чтобы использовать только свои переменные, так как его доступ к чужим переменным сервером не ограничивается. Если клиентов окажется больше, чем созданных наборов, может потребоваться перезапуск сервера для увеличения числа наборов. Несмотря на отмеченные недостатки в диссертации рекомендуется использовать второй способ, так как он существенно проще в реализации.

В диссертации отмечается, что независимые наборы переменных полностью решают только проблему отправки команд. Совместная обработка событий несколькими клиентами требует дополнительных соглашений, так как в итоге устройство должно получить только один ответ. Полное решение указанной проблемы возможно при введении в сервер дополнительных интерфейсов, не предусмотренных стандартами ОРС.

Многие проблемы использования ОРС в АСУ связаны с неполной или неправильной поддержкой ОРС клиентами. Анализ различных БСАБА-систем показал, что наиболее типичными недостатками являются: отсутствие поддержки качества (в стандартах ОРС с каждой переменной связано т.н. качество - специальный двухбайтный код, позволяющий судить о корректности значения переменной), использование синхронного или асинхронного чтения вместо подписки (это приводит к увеличению неоправданной нагрузки на сеть и снижению производительности, особенно при большом количестве медленно меняющихся переменных) и проблемы обнаружения разрыва и восстановления связи при работе с удалёнными ОРС-серверами.

Отсутствие поддержки качества, в принципе, решается введением дополнительных переменных (по одной на каждый реальный параметр). Значения дополнительных переменных кодируют качества основных

переменных. Данный способ достаточно эффективен, но может значительно повысить стоимость системы из-за того, что стоимость лицензии на использование БСАОА-системы существенно зависит от числа используемых ею переменных.

В диссертации предлагается альтернативный способ передачи качества, разработанный автором при работе над системой котроля и диспетчерского управления группой зданий для г. Зеленограда. Данный способ основан на особенностях БСАБА-системы СйесЛ, в которой оплачиваются только переменные ввода-вывода, а количество внутренних переменных лицензия не ограничивает. Все реальные переменные получают уникальный номер, а качество передаётся через одну целочисленную переменную, старший байт которой содержит качество, а младший байт - номер переменной, к которой это качество относится. Переменная периодически меняет своё значение, пробегая все реальные переменные. Клиент отслеживает эти изменения и записывает качества во внутренний массив. Такой способ учета качества является достаточно медленным при значительном числе используемых переменных. Так, если обновление переменной, кодирующий качество, происходит 1 раз в секунду, то при использовании 1000 переменных клиент будет получать информацию об изменении качества с задержкой около 8 минут. Для его ускорения можно разбить переменные на группы, и для каждой группы создать свою переменную. В частности, если 1000 переменных разбить на 10 групп, то за счёт введения девяти переменных среднее время задержки сократится до 50 секунд. Данный способ можно рекомендовать для использования в системах, в которых время реакции на изменение качества может быть достаточно велико.

Снижение производительности системы, связанное с использованием чтения переменных вместо подписки, является существенным только при работе с удалённым сервером. Эта проблема имеет много общего с проблемой неспособности ОРС-клиента обнаружить и устранить разрыв связи, поэтому в диссертации предлагается единое решение для обеих проблем. Это решение заключается в использовании промежуточного ОРС-сервера, получающего данные от удалённого ОРС-сервера. Промежуточный сервер является локальным для клиента, поэтому разрыв связи с ним крайне маловероятен, а обмен данными через память достаточно быстр даже при использовании чтения. Сам же промежуточный сервер работает с удалённым сервером по подписке, и реализует эффективный алгоритм проверки и восстановления связи. Промежуточный ОРС-сервер используется в системе диспетчерского управления московской монорельсовой транспортной системой для связи между СЦДУ и АСДУ-Э. Для обнаружения разрыва связи применялся описанный выше комбинированный алгоритм: при долгом отсутствии

вызовов от удалённого ОРС-сервера промежуточный сервер пингует его, вызывая функцию проверки статуса.

Для оценки того, насколько промежуточный ОРС-сервер снижает нагрузку на сеть, в диссертации предложена формула

, , С+ЫР

t=í0+-

V

где I - время, требуемое для выполнения одной транзакции (оно пропорционально нагрузке на сеть), г0 - время, требуемое для передачи служебной информации транзакции, С - объём параметров, не зависящих от числа переменных, N - число переменных, передаваемых в рамках транзакции, Р - объём данных, приходящихся на одну переменную, V скорость передачи данных. С помощью этой формулы показано, что использование подписки вместо прямого чтения даже в самом неблагоприятном случае снижает нагрузку на сеть на 22%, а в более типичных случаях нагрузка может уменьшатся в десятки и сотни раз.

Алгоритм, предложенный для промежуточного ОРС-сервера, использовался также в разработанной автором программе ШзОРСЫпк, являющейся шлюзом между протоколами ОРС и ЗиИеЬтк (закрытый протокол, использующийся в продуктах компании Wonderware). Для этих целей обычно используется стандартный шлюз производства "^пёепуаге, но он некорректно обращается с меткой времени передаваемых данных, что создаёт определённые проблемы. Программа ШБОРСЬтк была призвана решить, в первую очередь, именно указанные проблемы, но для проверки наличия связи с ОРС-сервером был использован описанный выше алгоритм. В настоящее время ШвОРСЬшк используется в системе мониторинга технологических процессов Южнокузбасской ГРЭС. Благодаря возможности быстрой диагностики потери связи (за 2-3 секунды вместо 10 минут при использовании стандартного шлюза) система более оперативно информирует оператора о возникших проблемах.

Распараллеливание работы ОРС-сервера

При обмене данными с устройствами обычно возникают достаточно длительные паузы, в течение которых программа ожидает ответа от устройства. Распараллеливание работы ОРС-сервера позволяет ему использовать эти паузы для решения других задач. Особенно эффективно распараллеливание в тех случаях, когда ОРС-сервер работает с несколькими устройствами (обычно однотипными).

Захват мыогвмса и выдача задания первой нити

Захват мъмтакеа и выдача задания ' второй икти

Захмт мьютакса и выдача задания -третьей нити

Ожидание события «

Событие завершения

Сяцщ

события запуска

Ожидание события 4 запуска

Ояощаиие события

Событие завершения

Омдонме

события лотуавг

Ожидание события запуска

Нити, взаимодействующие с устройствами

Рис. 3. Алгоритм распараллеливания с прямой выдачей задания

Кроме распараллеливания обмена данными с устройствами существует также распараллеливание обмена данными с ОРС-клиентами. В технологии СОМ/БСОМ наиболее предпочтительной моделью для ОРС-сервера является многонигевая модель, в рамках которой любая функция любого СОМ-объекта может быть вызвана из любой нити, входящей в пул нитей, созданный системой. Исключение составляют ОРС-серверы, не ведущие прямой обмен с устройствами (например,

моделирующие данные на основании математических моделей). У таких серверов отсутствуют паузы, связанные с ожиданием ответа, поэтому распараллеливание их работы приведёт только к увеличению нагрузки на процессор за счёт увеличения числа переключений между нитями.

В диссертации предлагаются два типовых алгоритма распараллеливания работы сервера, один из которых (названный алгоритмом прямой выдачи задания) ориентирован на низкую интенсивность обмена данными, другой (названный алгоритмом с промежуточной нитью) - на высокую интенсивность. Оба алгоритма предназначены для взаимодействия с устройством по специфическому поддерживающему соединение протоколу, в котором обе стороны могут послать запрос, все запросы квитируются, каждый запрос и ответ отправляется единым пакетом. Также рассмотрены иные варианты протокола обмена (отсутствие квитирования, односторонняя инициатива запроса, протокол без соединения) и предложены модификации алгоритма работы сервера для каждого из них. Предложен алгоритм работы нити, взаимодействующей с устройством, наиболее подходящий для изложенных способов распараллеливания задачи.

Для обслуживания каждого из устройств предлагается создавать отдельную нить, которая занимается только обменом данными с устройством. Эта нить может получать задание на отправку запроса устройству. При поступлении запроса от устройства эта нить помещает данные в буфер, откуда их затем могут взять другие нити.

С каждой нитью, взаимодействующей с устройством, должны быть связаны как минимум два события и один мьютекс (если устройство поддерживает запросы, требующие от сервера сложной алгоритмической обработки, событий будет больше). Первое событие служит для передачи нити сигнала о том, что необходимо отправить устройству запрос. Второе событие показывает, что нить завершила обработку запроса. Мьютекс используется для защиты нити от одновременного получения нескольких заданий: для выдачи ей задания нить должна сначала захватить соответствующий мьютекс.

Выдачу заданий осуществляют нити, обрабатывающие запросы от клиентов, а также нити, заполняющие буфер, рекомендуемый стандартом ОРС. Перед выдачей задания такая нить захватывает мьютекс, связанный с нужной ей нитью, взаимодействующей с устройством, заполняет специально отведённую для этого область памяти информацией о задании, а затем устанавливает событие, сигнализирующее о необходимости начать обработку задания. До получения задания нить, взаимодействующая с устройством, находится в приостановленном состоянии (или обрабатывает запрос от устройства и по завершении обработки переходит в приостановленное состояние). Событие выводит

нить из этого состояния. После того как запрос будет отправлен и ответ на него (или квитанция) получен, нить, взаимодействующая с устройством, устанавливает событие, сигнализирующее о завершении обработки задания. Нить, давшая задание, которая до этого находилась в приостановленном состоянии в ожидании этого события, начинает работу. Прежде всего, обрабатываются результаты выполнения задания, которые хранятся в специально отведённой для этого области памяти, затем освобождается мыотекс. После этого нить, взаимодействующая с устройством, доступна для получения других заданий. Описанный алгоритм выдачи задания позволяет выстроить все нити, дающие задания, в очередь и избежать одновременной выдачи нескольких заданий.

Нить, дающая задания, в общем случае нуждается в получении информации сразу от нескольких устройств, поэтому она должна дать задания нескольким нитям, взаимодействующим с устройствами. Целесообразнее давать задание нескольким нитям сразу и дожидаться завершения выполнения заданий ими всеми, как это показано на Рис. 3. Данный алгоритм назван в диссертации алгоритмом прямой выдачи задания.

Для оценки повышения производительности при использовании алгоритма прямой выдачи задания был использован модельный эксперимент, результаты которого показаны на Рис. 4. Из рисунка видно, что выигрыш от использования предлагаемого алгоритма составляет 250% при 2-ух нитях, дающих задания, и 20-ти устройствах, и 100% при 4-ёх нитях и 20-ти устройствах.

Алгоритм прямой выдачи задания позволяет эффективно распараллелить процесс обмена данными с устройством в тех случаях, когда нить, дающая задания, одна, или их несколько, но они редко дают задания и поэтому одновременные попытки доступа к одной и той же нити, взаимодействующей с устройством, происходят лишь изредка. Но высокий уровень конкуренции за нити, взаимодействующие с устройством, приводит к тому, что эти нити начинают простаивать даже тогда, когда в них есть потребность. Это происходит из-за того, что несколько нитей получают задания одновременно, и пока самая медленная нить не завершит выполнение задания, остальные нити будут также недоступны. Кроме того, если задание должно выдаваться нескольким нитям сразу, то это должно происходить в порядке строгой очереди. Из-за этого свободная нить не может получить задание и начать его выполнять, если предыдущая в очереди нить занята выполнением другого задания. В диссертации показано, что решение эти проблемы в рамках алгоритма прямой выдачи задания невозможно, так как это обязательно приведёт к появлению вероятности взаимной блокировки двух или более нитей и, как следствие, к неработоспособности сервера.

Количество устройств

Рис. 4. Скорость работы при использовании алгоритма прямой выдачи задания

Для решения этой проблемы предлагается алгоритм с промежуточной нитью. Его суть заключается в следующем: нить, дающая задание, запускает новые (промежуточные) нити, количество которых равно количеству нитей, взаимодействующих с устройствами, которые получают задание. Каждая промежуточная нить получает свою часть задания и передаёт её одной нити, взаимодействующей с устройством. Этот алгоритм показан на Рис. 5. Так как каждая из промежуточных нитей захватывает только одну нить, взаимодействующую с устройством, захват разных нитей выполняется независимо, и нить освобождается сразу после выполнения задания. Это почти полностью исключает простой процессора, когда есть задания, которые он может выполнить.

Модельный эксперимент показал, что использовании алгоритма с промежуточной нитью при 6-ти нитях, дающих задания, и 20-ти устройствах позволяет увеличить производительность на 180%, в то время как алгоритм с прямой выдачей задания даёт в этих условиях выигрыш только на 30%. Кроме того, алгоритм с промежуточной нитью повышает производительность как минимум на 10% в случае малого количества устройств, в то время как алгоритм с прямой выдачей задания в этом случае приводит к снижению производительности.

взаимодействующая еуоройстюм

Нкть. взаимодействующая

Рис. 5. Алгоритм распараллеливания с промежуточной нитью

На Рис. 6 показан алгоритм работы нити, взаимодействующей с устройством, предлагаемый в диссертации. Предполагается, что по отношению к протоколу обмена данными с устройством ОРС-сервер является клиентом, а устройство - сервером. Приведённый алгоритм учитывает следующие возможные ситуации:

• Выдача задания нити до того, как установлена связь с устройством.

• Отправка устройством запроса в промежуток времени между отправкой запроса сервером и получением этого запроса

устройством; в этом случае сервер вместо ответа на свой запрос получит встречный запрос.

Действия нити по обработке запроса зависят от типа запроса. Если запрос не требует алгоритмической обработки и ответ на него может быть сформирован сервером самостоятельно, то обработка запроса заключается в формировании ответа и его отправке. В более сложных случаях формирование ответа может потребовать каких-либо действий от клиента, связанных с обработкой полученных данных. Выше описывался предложенный в диссертации алгоритм взаимодействия между ОРС-сервером и ОРС-клиентом, предназначенный для реализации обработки таких запросов с помощью сигнальной переменной логического типа. В рамках описанного алгоритма работы нити он может бьггь реализован следующим образом: для каждой сигнальной переменной создаётся событие. Получив запрос, нить, взаимодействующая с устройством, обновляет все переменные, устанавливает сигнальную переменную в True и переходит в режим ожидания указанного события. Когда клиент сбрасывает сигнальную переменную в состояние False, та нить, которая обрабатывает соответствующий запрос, инициирует событие, выводя тем самым нить, взаимодействующую с устройством, из состояния ожидания, после чего эта нить формирует ответ на основании информации из буфера и отправляет его устройству.

Как сказано выше, нить, взаимодействующая с устройством, находится в приостановленном состоянии, из которого её может вывести, во-первых, получение запроса от устройства, а во-вторых, необходимость отправки запроса устройству (выполнения задания). В более общем случае может также понадобиться пингование устройства и корректное завершение нити при выходе из программы. Таким образом существует четыре события, которые могут вывести нить из приостановленного состояния.

Описанный алгоритм работы нити, взаимодействующей с устройствами, предназначен для поддержки сложных полнодуплексных протоколов обмена данными. Такие сложные протоколы используются далеко не всеми устройствами. В диссертации рассмотрены наиболее вероятные изменения протокола и способы упрощения предложенного выше алгоритма с учётом этих изменений.

Прежде всего, может использоваться протокол обмена с устройством, по отношению к которому ОРС-сервер является сервером, а устройство -клиентом. В этом случае предлагается создавать отдельную нить, отслеживающую попытки подключения. Для обслуживания каждого из подключений создаётся нить, реализующая алгоритм, аналогичный показанному на Рис. 6, за исключением того, что в нём отсутствует блок установления связи. При разрыве связи такая нить должна переходить в

приостановленное состояние, из которого его может вывести сигнал о повторном подключении устройства.

Рис. 6. Алгоритм работы нити, взаимодействующей с устройством

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

Наиболее типичным является протокол, в котором запросы может посылать только сервер, а устройство только отвечает на эти запросы. В этом случае из алгоритма работы нити удаляются все ветви, связанные с возможностью получить запрос устройства. Это существенно упрощает реализацию алгоритма, так как исчезает необходимость использования специфических событий библиотеки Windows Sockets 2, позволяющих осуществлять вывод нити из приостановленного режима при получении запроса.

В некоторых случаях протокол взаимодействия поддерживает только запросы от устройства к серверу. В этом случае нить, взаимодействующая с устройством, не может получать задания. Из всех событий остаётся только событие, вызывающее завершение нити, а нити, использующие данные, вынуждены брать эти данные из буфера.

Существуют также протоколы, в которых отсутствует понятие ответа на запрос. В этом случае сервер и устройство могут посылать друг другу запросы, но никогда не ждут ответов на них, что соответствующим образом отражается на алгоритме работы нити, взаимодействующей с устройствами. Эта нить по-прежнему может получать задания от других нитей, но выполнение задания сводится только к отправке запроса. Из алгоритма работы удаляются ветви, связанные с ожиданием ответа и, следовательно, с возможностью получения встречного запроса вместо ответа.

Все описанные алгоритмы являются модификациями одного общего универсального алгоритма. Этот алгоритм учитывает возможность разрыва связи и необходимость скорейшего автоматического её восстановления. Применение предложенного алгоритма позволяет создавать надёжные и быстрые ОРС-серверы.

Применение алгоритмов распараллеливания в АСУ

Описанные выше алгоритмы и их модификации используются в ряде ОРС-серверов, разработанных автором диссертации. Наиболее часто используемым среди них является ISaNOPC-сервер, являющийся шлюзом между ОРС и протоколом Extended ModBus, который поддерживается системой ISaGRAF. Т.к. ISaGRAF является стандартным средством программирования контроллеров SMART производства концерна Kontron, а других протоколов в сети Ethernet ISaGRAF не поддерживает, данный сервер стал эффективным средством связи с указанными контроллерами и применяется во многих АСУТП, в которых используется ISaGRAF. В настоящее время данный сервер используется в АСУТП нескольких нефтедобывающих и нефтеперерабатывающих комплексах, а также в АСУТП производства бетона. Из-за особенностей протокола Extended ModBus передача данных идёт очёнь медленно, поэтому

распараллеливание работы с несколькими контроллерами имеет в данном случае особую важность.

Алгоритм работы нити, взаимодействующей с устройствами, в том виде, в каком он описан выше, реализован в ОРС-сервере для связи с электроподвижными составами Московской монорельсовой транспортной системы. Протокол, который используют ЭПС, позволяет обеим сторонам посылать запросы, а время ответа на запрос задано достаточно жёстко. Описанный алгоритм работы через события позволил сделать время реакции сервера очень малым практически без увеличения нагрузки на процессор, т.к. во время ожидания события нить не использует процессорное время. Выделение взаимодействия с каждым из ЭПС в отдельную нить позволило сделать обмен с ними независимым друг от друга, т.е. проблемы, возникающие при обмене с одним из ЭПС, не приводят к задержкам в обмене с остальными ЭПС.

Несколько специфичным образом был реализован алгоритм работы нити, взаимодействующей с устройством, при разработке ОРС-сервера для связи с системой автоматизации газокомпрессорной станции ИНФО-КЦ. В данном случае ОРС-сервер имеет только один источник данных, поэтому вопрос о распараллеливании работы с устройствами не стоит. Тем не менее, взаимодействие с устройством выделено в отдельную нить, чтобы ошибки обмена не. влияли на реализацию пользовательского интерфейса. Специфика протокола обмена с системой ИНФО-КЦ заключается в том, что каждая сторона должна поддерживать по два сокета: один в режиме клиента, другой - в режиме сервера. Это усложняет процедуру инициализации нити. Чтобы не выносить в отдельную нить проверку подключения со стороны системы ИНФО-КЦ, для этого была также использована схема событийного управления, которую позволяет реализовать библиотека Windows Sockets. В настоящее время указанный ОРС-сервер используется на Комсомольском линейно-производственном управлении (ЖГУ) и планируется к внедрению на остальных ЖГУ ООО «Тюментрансгаз».

Доступ к ОРС-серверу через интернет

Под доступом к ОРС-серверу через интернет могут подразумеваться два варианта: прямой доступ ОРС-клиенга к ОРС-серверу через глобальную сеть и взаимодействие с ОРС-сервером через интерфейс браузера.

В диссертации проведён обзор литературы, посвящённой данному вопросу. Прямой доступ через интернет осуществляется с помощью настройки брандмауэров или использования протокола Tunneling TCP. Несмотря на некоторые существенные недостатки обоих этих способов в этой области, видимо, не может быть предложено ничего нового в рамках

имеющейся технологии COM/DCOM. Любое нововведение требует изменения этой технологии, что, во-первых, очень трудоёмко, а во-вторых, приведёт к потере совместимости с уже существующими программами и тем самым сведёт практически к нулю все выгоды от использования COM/DCOM.

Обзор имеющихся средств доступа к серверу через браузер показал, что они не позволяют осуществлять автоматическое выборочное обновление данных в окне браузера без использования дополнительного (не HTTP) канала связи, используют для доступа к серверу медленные автоматные интерфейсы и требуют определения списка переменных ещё на этапе разработки приложения. В диссертации предлагается новый метод доступа к ОРС-серверу через браузер, свободный от указанных недостатков. Основной данного метода является использование невидимых фреймов для частичного обновления страницы и создание отдельных нитей, взаимодействующих с СОМ-сервером, для каждого клиента.

Для иллюстрации предложенного метода автором разработан универсальный ОРС-клиент, основное окно которого показано на Рис. 7. В левом фрейме содержится список всех переменных сервера, выбранного пользователем, в правом - значения тех переменных, которые выбрал пользователь. Информация в правом фрейме обновляется с периодом, указанным пользователем, причём передаются значения только тех переменных, которые за истекший период обновились - это существенно снижает нагрузку на сеть, что в условиях глобальной сети становится особенно важным. Клиент допускает одновременное подключение неограниченного числа пользователей к одному или разным ОРС-серверам. Данный клиент может быть полезен для разработчика системы при её отладке, но практически бесполезен для оператора из-за неудобной формы представления данных. Тем не менее, клиент показывает возможности технологии ISAPI для создания подобных клиентов и, при необходимости, может быть легко модифицирован для решения конкретной задачи.

ISAPI-библиотека содержит функции, которые формируют HTML-страницы. URL такой страницы состоит из URL библиотеки и имени функции, разделённых вопросительным знаком. Функция может иметь параметры, которые передаются методом GET или POST. Существенным достоинством ISAPI-библиотеки является то, что она не выгружается из адресного пространства web-сервера между вызовами функций, поэтому разработчик может предусмотреть выполнение каких-либо действий в перерыве между этими вызовами. В данном случае между вызовами функций, формирующих страницы, библиотека обрабатывает уведомления от ОРС-сервера об изменении переменных.

ПШ1АКМ) DAI AI AI AI bfVal ПА1 At A1A2 iVd ПА1А1А.1 АЗЬЛ'Ы ПА1.А1 AI A4 iVal CA1A1A1 AibIVd BAlAlAlAi 1V1I DAlA!AlA?bIVil ПА1 AI AI AS iVil CAlAlAlASbIVil CAIALAI AlOiVil П AI AI AI All ЫУ«1 О AI AI Al.A12.bVdO ПА1.А1 A1.A12 bVill ПА1 AI AI A12bV»l2 DAI AI AI A12 bVjD BAI A1A1 A12.bViM ПА1 AI Al_A12bVil5 □ AlAlAl.A12.bVi6 ПА1 AI AI A12 bV«I7 13 AI AI AI A13bVal П AI AI AI А14 fVal ПА1А1Л1 AlSUVal ПА1 A1A1 AlibV^O ЯА1А1 AlAlSbVJl ÖA1 AI AI A16bVaj2 nAlAl-Al.A16bV>ß

ü

Рис. 7. Мониторинг переменных ОРС-сервера через браузер

Основная функция используемой ISAPI-библиотеки InetOPCClient в качестве параметров получает имя ОРС-сервера, с которым пользователь хочет работать, и частоту обновления (ввод этих параметров автоматизирован с помощью простейшей HTML-страницы). Эта функция формирует страницу, показанную на Рис. 7. Эта страница состоит из двух видимых и двух невидимых (т.е. имеющих нулевой размер) фреймов. Невидимые фреймы используются для вызова функций, страницы которых сами по себе не представляют интереса, но вызов которых влияет на то, какие страницы будут сформированы другими функциями в видимых фреймах.

В первый из невидимых фреймов загружается страница, содержащая сценарий, обновляющий правый фрейм (функции библиотеки InetOPCClient для создания сценариев использует язык VBScript, но можно также использовать и JavaScript). Эта страница автоматически перегружает себя с заданной частотой, обеспечивая своевременное обновление содержимого фрейма. Сценарий учитывает два возможных варианта обновления: изменение значений переменных, выбранных пользователем, и изменение списка переменных (добавление пользователем новых и удаление уже существующих переменных). Для добавления и удаления переменных используется второй невидимый

фрейм, через который вызывается соответствующая функция. При изменении списка переменных страница, формирующая правый фрейм, обновляется целиком. При изменении значений переменных сценарий содержит только команды обновления соответствующих полей. При большом количестве переменных в списке и медленном их обновлении такой подход позволяет добиться существенного снижения нагрузки на сеть. Если за указанный период значения переменных не изменились, сценарий содержит только команды своей автоматической перезагрузки. Это приводит к загрузке сети бесполезными пакетами, но в рамках поставленной задачи решение этой проблемы невозможно: протокол HTTP не позволяет серверу высылать пакеты клиенту по собственной инициативе, поэтому для пересылки уведомлений потребуется дополнительный канал связи. Но этот канал потребует настройки брандмауэров и установки дополнительного программного обеспечения.

Для поддержания связи с ОРС-сервером библиотека InetOPCClient создаёт отдельную нить для каждого соединения. Эта нить получает уникальный идентификатор, который должен передаваться в качестве параметра при всех последующих вызовах функций библиотеки. Таким образом, обеспечивается независимое подключение одного или нескольких клиентов к разным ОРС-серверам. Эта нить автоматически удаляется библиотекой, если в течение заданного времени к ней не было запросов. Это позволяет освобождать ресурсы, использованные отключившимися клиентами.

По совокупности достоинств (универсальность, частичное обновление, возможность независимой работы нескольких клиентов, скорость работы) предложенный в диссертации способ доступа к ОРС-серверам через браузер превосходит описанные в литературе способы. Его недостатком является сложность разработки библиотеки, поэтому в тех случаях, когда не требуются универсальность и высокая скорость работы, могут быть использованы другие методы, например, на основе IIS-приложений или технологии Remote Scripting.

Основные результаты работы

Основным результатом диссертации является разработка методики и средств для эффективного использования технологии COM/DCOM в программном обеспечении верхнего уровня автоматизированных систем для связи с устройствами. В ходе подготовки диссертации получены следующие результаты:

• Проведён анализ основных требований к серверу, обеспечивающему связь с устройством в АСУ, и показано, что СОМ-сервер удовлетворяет всем указанным требованиям.

• Предложены критерии выбора значений параметров настройки СОМЛЭСОМ для обеспечения контроля работы системы со стороны пользователя и повышения эффективности работы АСУ за счёт выбора оптимального способа обеспечения безопасности и недопущения дублирования сервера.

• Разработаны алгоритмы использования сигнальных переменных ОРС-сервером для реализации команд и событий устройства, позволяющие упростить создание АСУ за счёт использования встроенных возможностей БСАБА-систем.

• Предложены два алгоритма распараллеливания работы ОРС-сервера, позволяющие повысить производительность: алгоритм прямой выдачи задания (на 250% в случае 2-ух потребителей данных и 20-ти устройств) и алгоритм с промежуточной нитью (на 180% в случае 6-ти потребителей данных и 20-ти устройств).

• Предложено использование промежуточного ОРС-сервера в тех случаях, когда 8САОА-система реализует ОРС некорректно. Если 8САОА-система использует прямое чтение вместо подписки, использование промежуточного ОРС-сервера позволяет снизить нагрузку на сеть не менее чем на 22%, а в наиболее типичных случаях - в десятки и сотни раз.

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

• Разработан метод использования интерфейса браузера для взаимодействия с ОРС-серверами через интернет. Данный метод обеспечивает универсальность, поддержку множественных независимых подключений и низкую нагрузку на сеть, что позволяет реализовывать удалённый контроль работы АСУ.

На основе предложенных алгоритмов разработаны и переданы заказчику следующие программные продукты: система контроля доступа, девять типов ОРС-серверов, шлюз ОРС-БикеГлпк. Испытания указанных продуктов показали их соответствие требованиям технического задания, что указывает на эффективность предложенных в диссертации алгоритмов и методов создания АСУ с использованием технологии СОМ-БСОМ и стандарта ОРС. Указанные продукты входят в состав следующих систем:

• Различных АСУТП, использующих ВаОКАР З.Зх (в частности, АСУТП нефтедобывающих комплексов, АСУТП производства бетона).

• Системы мониторинга технологических процессов Южнокузбасской ГРЭС.

• Информационно-управляющей системы транспорта газа ОАО «Тюментрансгаз».

• Системы контроля и диспетчерского управления микрорайона 10А Управы №4 г. Зеленограда.

• Системы диспетчерского управления московской монорельсовой транспортной системы.

• Охранной системы московского офиса ТНК.

• Единой диспетчерской инженерных служб соборов Московского Кремля

Основные результаты диссертации изложены в работах:

1. Куцевич И.В., Григорьев А.Б. Стандарт ОРС - путь к интеграции однородных систем // Мир компьютерной автоматизации. - 2001. - №1. - с. 46-52

2. Григорьев А.Б. ОРС - средство общения разнородных систем // Промышленные АСУ и контроллеры. - 2002. - №4. - с. 38-40

3. Григорьев А.Б. Использование ОРС на примере системы интеллектуальных зда-ний // Промышленные АСУ и контроллеры. - 2003. - №5. - с. 32-36

4. Григорьев А.Б., Новиков E.H. Передача данных с помощью ОРС на примере системы интеллектуальных зданий // Мир компьютерной автоматизации, 2003. - №2. - с. 52-60.

5. Григорьев А.Б., Новиков E.H. ОРС-сервер для IndustrialSQL 7.1 // Промьпп-ленные АСУ и контроллеры. -2003.-№1. - с. 41-44.

6. Григорьев А.Б., Кадников A.A. Использование COM/DCOM для создания системы автоматизации здания // Научная сессия МИФИ-2003, сборник научных тру-дов в 14 томах, том 1. - М.:МИФИ. - 2003. - с. 54-55

7. Григорьев А.Б. Взаимодействие с ОРС-серверами через Internet // Промышленные АСУ и контроллеры. - 2002. -№11.-с. 40-42.

8. Григорьев А.Б. Использование COM/DCOM и ОРС в интернете // Мир компью-терной автоматизации. - 2003. - №6. -с. 56-59.

9. Григорьев А.Б. Применение ОРС в московской монорельсовой транспортной сис-теме // Промышленные АСУ и контроллеры. - 2004. -№6. - с. 41-43.

РНБ Русский фонд

2005-4 40933

Подписано в печать 04.04.200S г. Формат 60 х 90/16. Объем 1.2 п.л. Тираж 60 экз. Заказ № 0404051

Оттиражировано на ризографе в «ИП Гурбанов Сергей Талыбович» Св. о регистрации № 304770000207759 от 09 июня2рМтода ИНН 770170462581

/ esl ^

III

2 2 АИР 2005 V*y

Введение.

Постановка задачи.

Научная новизна диссертации.

Практическая значимость диссертации.

Основные положения, выносимые на защиту.

Глава 1. Анализ возможностей COM/DCOM.

1.1. Основные принципы взаимодействия приложений.

1.2. Нитевые модели.

1.3. Категории компонентов.

1.4. Безопасность в COM/DCOM.

1.5. Сетевой транспорт в COM/DCOM.

1.6. Задачи автоматизации, решаемые с помощью COM/DCOM.

Выводы.

Глава 2. Методика использования COM/DCOM в АСУ.

2.1. Требования к системе контроля доступа.

2.2. Описание системы контроля доступа.

2.3. Устройство ехе-сервера СКД.

2.4. Устройство dll-сервера СКД.

2.5. Роль COM/DCOM в СКД.

2.6. Недостатки СКД.

2.7. Алгоритмы диагностики и восстановления связи с СОМ-сервером.

2.8. Методика использования COM/DCOM при создании АСУ.

Выводы.

Глава 3. Группа стандартов ОРС.

3.1. ОРС Common.

3.2. ОРС Data Access.

3.3. ОРС Alarms and Events.

3.4. ОРС Batch.

3.5. ОРС Security.

3.6. ОРС Historical Data Access.

3.7. OPC Data Exchange.

3.8. OPC XML-DA.

3.9. Использование OPC в АСУ для взаимодействия с устройствами.

3.10. Быстродействие ОРС.

3.11. Недостатки ОРС.

Выводы.

Глава 4. Опыт использования ОРС в АСУ.

4.1. Использование ОРС на примере системы контроля и диспетчерского управления

4.2. Способы преодоления недостатков ОРС.

Выводы.

Глава 5. Распараллеливание работы ОРС-сервера.

5.1. Актуальность задачи распараллеливания работы.

5.2. Классификация протоколов обмена.

5.3. Распределение задач между нитями сервера.

5.4. Оптимизация выдачи заданий.

5.5. Алгоритм работы нити, взаимодействующей с устройствами.

5.6. Возможные изменения алгоритма распараллеливания задач.

5.7. Нитевая модель ОРС-сервера.

Выводы.

Глава 6. Использование COM/DCOM и ОРС в интернете.

6.1. Требования к методу доступа через интернет.

6.2. Прямой доступ с СОМ-серверам через интернет.

6.3. Использование браузера для взаимодействия с СОМ-серверами.

6.4. Недостатки имеющихся методов доступа к ОРС-серверу через браузер.

6.5. Доступ к ОРС-серверу с помощью ISAPI-библиотеки.

6.6. Рекомендации по выбору способа доступа к СОМ-серверу через интернет.

Выводы.

Современные АСУ являются сложными распределёнными системами, управляющими одновременно большим количеством разнородных объектов управления. Такие системы обычно состоят из нескольких уровней. В [1] описаны пять уровней АСУ предприятия: уровень низовой автоматики, контроллерный уровень, уровень человеко-машинного интерфейса (ЧМИ), уровень управления производством и уровень управления ресурсами предприятия. Каждый из этих уровней использует свои аппаратные и программные средства. Между уровнями идёт интенсивный обмен данными. Согласно [2] деление системы на уровни обусловлено не только различными требованиями, предъявляемыми к аппаратной и программной частям, но иерархией бизнес-процессов, связанных с АСУ.

На рис. 1 показана типичная многоуровневая АСУ предприятия. На нижнем уровне системы находятся датчики и устройства сопряжения с объектом (УСО), которыми управляет низовая автоматика — простые устройства, обеспечивающие простейшее оперативное управление системой. Этими устройствами, в свою очередь, управляют программируемые логические контроллеры (ПЛК), которые могут быть как относительно простыми и низкопроизводительными, так и многопроцессорными системами, сравнимыми по производительности с мощными серверами. ПЛК управляют устройствами низовой автоматики, собирая с них данные и выставляя параметры процесса регулирования. Обычно контроллер управляет множеством устройств низовой автоматики, управляя через них несколькими ОУ (объектами управления). В некоторых случаях контроллеры могут взаимодействовать непосредственно с датчиками и УСО без помощи низовой автоматики.

ЧМИ (человеко-машинный интерфейс) может быть реализован непосредственно ПЛК, но в большинстве случаев для этого используются отдельные компьютеры, получающие от ПЛК данные. Операторы АРМ посредством ЧМИ осуществляют общее управление частью системы. На этом же уровне осуществляется сбор и архивация данных, поставляемых ПЛК. Уровни системы от датчиков и УСО до уровня ЧМИ принято называть АСУТП.

На уровне управления производством осуществляется общее управление всеми АСУТП предприятия, что обеспечивает их совместную работу. Управление осуществляется, в основном, операторами АРМ, программное обеспечение не рассчитано на автономное принятие решений.

Управление производством деЯФЗЯЯ ИМ

Г г г Г'

ВР Г»

В Б

Е тЩ I

РЕ

Объекты управления

Рис. 1. Типичная структура АСУ предприятия

Уровень управления ресурсами предприятия на рис, 1 не показан. Этот уровень долгое время существовал независимо от остальных уровней АСУ, и до сих пор он далеко не везде связан с нижележащими уровнями.

Многие реальные системы, описанные в литературе, в целом соответствуют описанной иерархии, хотя уровни в них могут быть разделены не так чётко. Так, в АСУ Белорусского металлургического завода [3] ПЛК не имеют выхода в Ethernet и связываются с компьютерами уровня ЧМИ посредством технологической сети. Системы, описанные в [4, 5], соответствуют приведённой схеме, за исключением того, что в них отсутствует уровень управления. Практически полностью описанной схеме соответствуют системы, описанные в [611]. Интересный пример построения многоуровневой системе описан в [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 и АСУ сделаны автором с использованием языка С++, поэтому примеры кода даны в диссертации именно на этом языке программирования. Однако результаты могут быть легко реализованы на любых других языках программирования, поддерживающих 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 и выбора структуры СОМ-сервера.

• Разделение драйвера устройства на локальную и удалённую часть как основа методики использования COM/DCOM в распределённых АСУ.

• Алгоритмы передачи параметризованных команд и событий с помощью стандарта ОРС Data Access, позволяющие использовать встроенные возможности SCADA-систем.

• Применение промежуточного ОРС-сервера для повышения скорости обмена с удалённым ОРС-сервером и диагностирования потери связи при использовании SCADA-систем, имеющих проблемы с реализацией ОРС.

• Алгоритмы распараллеливания работы и взаимодействия с устройством ОРС-сервера, повышающие эффективность работы АСУ за счёт уменьшения времени простоя процессора.

• Метод создания с помощью ISAPI-библиотек человеко-машинного интерфейса для удалённого доступа к ОРС-серверам через интернет.

Выводы

На основании изложенного материала можно сделать следующие выводы:

1. Прямой доступ к СОМ-серверу через интернет возможен, но ограничен рядом условий, вытекающих из особенностей сетевых протоколов DCOM и их совместимости с брандмауэрами. Улучшение имеющихся способов в рамках COM/DCOM невозможно.

2. Предложенный в диссертации метод загрузки сценариев в невидимые фреймы позволяет осуществлять частичное обновление страницы, снижая нагрузку на сеть (при обновлении одной переменной при полном числе 20 этот метод дал снижение размера пакета с 2 килобайт до 30 байт).

3. Предложенный в диссертации метод доступа к ОРС-серверу через ISAPI-библиотеку позволяет использовать более производительные простые интерфейсы, в отличие от предложенных ранее методов, использующих медленные автоматные интерфейсы.

Предложенные методы позволяют осуществлять эффективную организацию специализированного ПО, обеспечивающего взаимодействие с устройствами в АСУ через глобальную сеть.

Заключение

В диссертации исследовались прикладные методы и средства применения COM/DCOM и ОРС в АСУ, взаимодействующих с устройствами. Особое внимание уделено повышению эффективности и живучести АСУ, созданных с использованием COM/DCOM, предложены алгоритмы диагностирования связи в АСУ.

В диссертации предложен комбинированный алгоритм диагностирования связи (являющийся комбинацией часто используемых алгоритмов диагностирования с периодической проверкой и по таймауту). Использование данного алгоритма позволяет уменьшить время обнаружения разрыва связи до 1-2 секунд. Это позволяет повысить качество процесса управления за счёт своевременной реакции АСУ на выход из строя её части.

На основе анализа различных настроек COM/DCOM, предоставляемых системой, даны рекомендации по выбору оптимальных настроек для повышения эффективности АСУ. В частности, показано, что для обеспечения удалённого запуска СОМ-сервера с заранее заданными правами и возможностью последующего управления следует использовать системную учётную запись, а при невозможности запуска сервера как службы - учётную запись взаимодействующего пользователя. Рассмотрены настройки безопасности COM/DCOM и приведены рекомендации по их использованию в верхнем уровне АСУТП и в мониторинговых системах. Предложенные меры позволяют частично автоматизировать процесс запуска системы и подключение к ней новых устройств.

Рассмотрены существующие стандарты семейства ОРС. На примере системы контроля и диспетчерского управления показано, что АСУ, взаимодействующая с устройствами, построенная на базе ОРС, легко модифицируется.

Предложены алгоритмы передачи параметризованных команд и событий с помощью ОРС Data Access. Эти алгоритмы использовать встроенные в SCADA-системы средства поддержки ОРС при автоматизации различных процессов, требующих двунаправленной передачи управляющих воздействий.

Предложено использовать промежуточный ОРС-сервер для преодоления недостатков реализации клиентской части ОРС Data Access, присущих некоторым SCADA-системам и снижающих эффективность и надёжность АСУ. Так, при использовании промежуточного сервера для SCADA-систем InTouch и Citect удалось снизить время обнаружения разрыва связи с 10 минут до 1-2 секунд. В соответствии с [62] при использовании iFix промежуточный ОРС-сервер снизил бы нагрузку на сеть с 3.5% до 0.1%. В диссертации показано, что даже в самом неблагоприятном случае использование промежуточного ОРС-сервера снижает нагрузку на сеть как минимум на 22%.

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

Предложены два алгоритма распараллеливания работы ОРС-сервера, реализующего обмен данными с устройством - алгоритм прямой выдачи задания и алгоритм с промежуточной нитью. Оба алгоритма предполагают создание отдельной нити для взаимодействия с каждым устройством и выдачу заданий этим нитям теми нитями, которые нуждаются в данных. Предложен алгоритм работы нити, взаимодействующей с устройством для наиболее типичного протокола обмена с устройством и его варианты для возможных модификаций протокола. На основании модельных экспериментов показано, что алгоритм прямой выдачи задания повышает производительность в случае двух потребителей данных на 15230% (в зависимости от числа устройств), а алгоритм с промежуточной нитью - на 10180% в случае шести потребителей (этот случай является неблагоприятным для алгоритма с прямой выдачей задания).

Предложен метод доступа к СОМ-серверам через интернет с помощью 18АР1-библиотеки. По сравнению с известными методами предложенный метод позволяет уменьшить трафик (в частности, обновление одной переменной требует передачи сценария размером около 30 байт вместо полной страницы размером в 2 килобайта), а его механизмы достаточно универсальны для удовлетворения широкого спектра потребностей. Использование данного метода позволяет осуществлять процесс управления через глобальные сети.

Рекомендации, методики и алгоритмы, предложенные в диссертации, являются обобщением опыта построения реальных АСУ и реализованы в ряде АСУ, разработанных при участии автора, и на практике доказали свою эффективность. В настоящее время результаты диссертации внедрены в следующих системах.

1. Разработана и передана в эксплуатацию система контроля доступа, используемая в качестве прототипа для ряда подобных систем. С помощью СОМЛЗСОМ автоматизирован процесс распознания несанкционированного доступа и передача управляющих воздействий запирающим устройствам и сигнализации.

2. Создан ОРС-сервер для ISaGRAF, использующийся в настоящее время в системах автоматизации нефтедобывающих и нефтехимических комплексов ОАО «Южо-ренбургнефть» и ОАО «Востсибнефтегаз» (всего десять систем) для управления кранами, задвижками в нефтяных резервуарах.

3. ОРС-сервер для ISaGRAF внедрён в производстве бетона (система АСУБЕСТ разработки ООО «Оригон Строй») для автоматизации операций дозирования и смешивания исходных компонентов бетона.

4. Разработаны ОРС-серверы для контроля и диспетчерского управления группой зданий, эксплуатируемой в настоящее время в микрорайоне 10А управы №4 г. Зеленограда. Автоматизировано слежение за различными эксплуатационными и технологическими параметрами здания, накопление данных в архивах и анализ из динамики.

5. Создан и передан в эксплуатацию ОРС-сервер для охранной системы, использующейся в московском офисе ТНК. Автоматизирован процесс распознавания пропусков и учёт рабочего времени.

6. Создан ОРС-сервер для связи между системой центрального диспетчерского управления (СЦДУ) московской монорельсовой транспортной системы и электроподвижным составом (ЭПС). Данный сервер позволил автоматизировать управление движением поездов на линии.

7. Для связи между СЦДУ и автоматизированной системой диспетчерского управления энергообеспечением (АСДУ-Э) используется промежуточный ОРС-сервер, как это предложено в диссертации. С его помощью автоматизирован процесс регулирования работы системы энергообеспечения в зависимости от потребностей других подсистем.

8. Для связи между диспетчерской системой управления кондиционированием, вентиляцией, отоплением Успенской Звонницы и системой контроллеров Dec используется промежуточный ОРС-сервер, предложенный в диссертации. Автоматизирован процесс управления устройствами, поддерживающими микроклимат в помещении, в зависимости от внешних условий и установок оператора.

9. Разработаны шлюзы DDE-OPC и OPC-SuiteLink, использующиеся для решения коммуникационных задач в АСУ, разработанных ЗАО «РТСофт» (в системе автоматизации Южнокузбасской ГРЭС и в информационно-управляющей системе, внедряемой в ОАО «Тюментрансгаз»). Эти продукты используются для передачи данных между компонентами уровня ЧМИ.

10. Ведутся работы по разработке и внедрению ряда ОРС-серверов, использующих алгоритмы распараллеливания и взаимодействия с устройствами, предложенные в диссертации, и обеспечивающих взаимодействие с антипомпажными системами, системами управления газокомпрессорными цехами и станциями, системами телемеханики для управления газовыми кранами и газо-измерительными системами в информационно-управляющей системе (ИУС), внедряемой в ОАО «Тюментрансгаз». Эта система автоматизирует сбор информации о работе устройств, обеспечивающих транспорт газа, и составление отчётов на основании этих данных.

11. В рамках создания ИУС для ОАО «Тюментрансгаз» разработан промежуточный ОРС-сервер с дополнительными возможностями модификации данных. Данный сервер позволяет ИУС отслеживать резкие перепады давления на компрессорных станциях и вовремя информировать о них оператора, а также автоматически составлять отчёты о перепадах.

1. Куцевич H.A. Инструментарий для интеграции разнородных систем // Мир компьютерной автоматизации. 2000. - №1. - с. 33-37.

2. Никитин В.А. Особенности систем менеджмента качества инжиниринговых фирм, соответствующих Международным стандартам ISO сер. 9000:2000 // Промышленные АСУ и контроллеры. 2003. - №5. - с. 5-8.

3. Асташов А.И., Шляхота С.С., Терлецкий М.Ю. Опыт применения SCADA-пакетов FIX32 и iFIX на Белорусском металлургическом заводе // Промышленные АСУ и контроллеры. -2003. №5. - с. 24-28.

4. Ханин В.Н., Крижановский О.В., Нишневич В.И. АСУТП в ОАО «УралВНИПИЭнергопром» // Промышленные АСУ и контроллеры. 2002. - №4. - с. 4-7.

5. Антропов А.Т. Средства пожарной автоматики для технологических объектов добычи, транспортировки и переработки нефти // Промышленные АСУ и контроллеры. -2002.-№11.-с. 54-56.

6. Бабков A.B. Опыт создания автоматизированной системы управления этиленпро-водом газового производства в ОАО «Саянскхимпласт» на базе контроллеров «Сателлит» и SCADA-пакета «Сириус-QNX» // Промышленные АСУ и контроллеры. -2002.-№11.-с. 21-24.

7. Андрианов С.А., Пастухов С.Н., Страшини Е.Э. Программно-технический комплекс АСУТП участка «Выщелачивание 2» Богословского алюминиевого завода // Промышленные АСУ и контроллеры. - 2001. - №6. - с. 42-45.

8. Хазарадзе Т.О., Куликов А.И. Построение масштабных АСУТП: опыт решения проблемы // Мир компьютерной автоматизации. 2002. - №5. - с. 37-45.

9. Скударь Е.Х., Сурков С.Н., Шевченко Д.А. Опыт построения системы автоматизации сбытовой деятельности на Сызранском НПЗ // Промышленные АСУ и контроллеры. 2002. - №11. - с. 17-20.

10. Волгушев С.Б., Бычик С.А. Разработка и внедрение автоматизированной системы оперативного диспетчерского управления // Промышленные АСУ и контроллеры.-2003.-№1. с. 22-24.

11. Тверской Ю.С., Таламанов С.А., Голубев А.В. Освоение новой технологии АСУТП в учебно-научном процессе энергетического университета // Промышленные АСУ и контроллеры. 2004. - №6. - с. 6-9.

12. Иванов В. Два примера «интеллектуального здания» // Мир компьютерной автоматизации. 2003. - №2. - с. 41-44.

13. Доброволинская Е.В., Зозуленко М.М., Кольцов И.М., Коновалов А. В. Распределённая САУ физическими устройствами // Научная сессия МИФИ-2003, сборник научных трудов в 14 томах, том 1. М.гМИФИ. - 2003. - с. 43-44.

14. Don Box. Q&A House of COM //Microsoft Systems Journal. 1998. - July. - c. 21-22.

15. D on В ox. Introducing Distributed COM and the New OLE Features in Windows NT™ 4.0 // Microsoft Systems Journal. 1996. - May. - c. 12-15.

16. DCOM on non-Microsoft Platforms // OPC Foundation. 2001. - January.

17. Трельсен Э. Модель COM и применение ATL 3.0: Пер. с англ., СПб.:ВНУ-Санкт-Петербург, 2000. - 752 е.: ил.

18. Bill Hludzinski. Understanding Interface Definition Language: A Developer's Survival Guide // Microsoft Systems Journal. 1998. - August. - c. 17-19.

19. Фролов А.В., Фролов Г.В. Программирование для Windows NT (часть вторая). -М.: ДИАЛОГ-МИФИ, 1997.-271 с.

20. DCOM Technical Overview. MSDN, Backgrounders, 1996.

21. Don Box. House of COM//Microsoft Systems Journal.- 1999.-January.-c. 43-44.

22. The DCE RPC Application Engineering Specification (AES). http://www.opengroup.org/

23. Don Box. Q&A ActiveX/COM // Microsoft Systems Journal. 1997. - January. - c. 3537.

24. Dr. GUI on Components, COM, and ATL // Dr. GUI Online. 1998. - MSDN, Welcome to the MSDN Library.

25. Kraig Brockschmidt. OLE Integration Technologies: A Technical Overview//Dr. Dobb's Journal, the newsstand special edition. 1994. - December. - c. 24-28.

26. Jeff Prosise. Wicked Code //Microsoft Systems Journal. 1998. -May. -c. 11-13.

27. Don Box, Keith Brown, Timothy J. Ewald, Chris Sells. Effective COM Programming: Seven Tips for Building Better COM-based Applications // Microsoft Systems Journal. 1998. - October. - c. 18-22.

28. Соломон Д., Руссинович М. Внутреннее устройство Microsoft Windows 2000. Мастер-класс: Пер. с англ. СПб.: Питер; М.: Издательско-торговый дом «Русская редакция», 2001. — 752 е.: ил.

29. Бин Ли, перевод К. Лазарева. Понимание потоковых моделей в СОМ при программировании на Delphi //http://www.geocities.com/SiliconValley/Campus/3207/Translations/Threading RUS.html

30. David Platt. Fashionable App Designers Agree: The Free Threading Model is What's Hot This Fall // Microsoft Systems Journal. 1997. - August. - c. 28-30.

31. D о n В о x. Q&A ActiveX/COM // Microsoft Systems Journal. 1997. - September. - c.16.19.

32. D о n В о x. Essential COM. USA, Addison Wesley Longman, Inc, 1998, - 432 е.: ил.

33. Jeff Prosise. Wicked Code: Eight lessons from the COM School of Hard Knocks // MSDN Magazine. 2000. - November. - с. 18-21.

34. Markus Horstmann, Mary Kirtland. DCOM Architecture//MSDN, Backgrounders. 1997.-July 23.

35. Keith Brown. Security Briefs // Microsoft Systems Journal. 1998. - November. - c.17.20.

36. Джонс Э., Оланд Д. Программирование в сетях Microsoft Windows. Мастер-класс: Пер. с англ. СПб.: Питер, М.: Издательско-торговый дом «Русская редакция». -2002.-608 е.: ил.

37. Michael Nelson. Using Distributed COM with Firewalls // MSDN, Backgrounders. -1998.-June 20.

38. Закер К. Компьютерные сети. Модернизация и поиск неисправностей: Пер. с англ. -СПб.: БХВ-Петербург. 2003. - 1008 е.: ил.

39. Guy Eddon, Henry Eddon. Understanding the DCOM Wire Protocol by Analyzing Network Data Packets // Microsoft Systems Journal. 1998. - March. - c. 23-25.

40. Distributed Component Object Model Protocol DCOM/1.0 // MSDN, Specifications. -1998.-January.

41. Jeff Prosise. Windows 2000: Asynchronous Method Calls Eliminate the Wait for COM Clients and Servers // MSDN Magazine. 2000. - April. - c. 26-28.

42. Brian Sabino. Non-Blocking Method Calls//MSDN, Technical Articles.- 1999.-August.

43. Власов В.А., Комиссарчук С.Ю., Лебедев В.О., Обносов A.B. Системно ориентированное программирование как средство решения задач реального времени // Промышленные АСУ и контроллеры. 1999. - №1. - с. 17-21.

44. Власов В. А., Лебедев В.О., Комиссарчук С.Ю. и др. Подсистема раннего обнаружения и устранения чрезвычайных ситуаций в реальном времени для АСУ экологически опасными технологическими процессами // Приборы и системы управления. 1997. - №8. - с. 28-29.

45. Власов В.А., Комиссарчук С.Ю., Лебедев В.О., Обносов A.B. Программные средства построения АСУТП MIK$Sys // Приборы и системы управления. -1998.-№9.-с. 32-37.

46. Власов В.А., Лебедев В.О., Комиссарчук С.Ю. и др. Обеспечение надёжности АСУТП с использованием комплекса программных средств MIK$Sys // Промышленные АСУ и контроллеры. 1999. - №12. - с. 27-29.

47. Комиссарчук С.Ю., Лебедев В.О., Обносов A.B. Построение надёжных и производительных многоплатформенных АСУТП на базе комплекса ПО МикСис // Промышленные АСУ и контроллеры. 2003. - №2. - с. 29-32.

48. Лебедев В.О., Комиссарчук С.Ю., Обносов A.B. Структура и основные особенности программного комплекса создания систем управления «МикСИС» ПТК «УМИКОН» // Промышленные АСУ и контроллеры. 2004. - №1. - с. 35-41.

49. Григорьев А.Б., Кадников A.A. Использование COM/DCOM для создания системы автоматизации здания // Научная сессия МИФИ-2003, сборник научных трудов в 14 томах, том 1. М.:МИФИ. - 2003. - с. 54-55.

50. Мамаев Е.В., Вишневский A.B. Microsoft SQL Server 7 для профессионалов -СПб.: «Питер», 2000. 896 е.: ил.

51. КренкеД. Теория и практика построения баз данных, 8-е издание: Пер. с англ. -СПб.: «Питер», 2003. 800 е.: ил.

52. Круглински Д., Уингоу С., Шеферд Дж. Программирование на Microsoft Visual С++ 6.0 для профессионалов: Пер. с англ. СПб.: Питер; М.: Издательско-торговый дом «Русская редакция», 2000. - 864 е.: ил.

53. Don Box. Q&A ActiveX/DCOM // Microsoft Systems Journal. 1998. - January. - c. 19-20.

54. Рихтер Дж., Кларк Дж. Д. Программирование серверных приложений для Microsoft Windows 2000. Мастер-класс: Пер. с англ. СПб.: Питер; М.: Издательско-торговый дом «Русская редакция». 2001. - 529 е.: ил.

55. Don Box. The Active Template Library Makes Building Compact COM Objects a Joy // Microsoft Systems Journal. 1997. - June. - c. 14-17.

56. Dr. GUI and ATL // MSDN, Welcome to the MSDN Library (part 1). 1998. - September. Part 2. - 1998. - November.

57. Причард Дж. Просто и доступно СОМ и CORBA. Архитектуры, стратегии и реализации: Пер. с англ. М.: «ЛОРИ», 2001. - 372 е.: ил.

58. Эдди С.Э. XML, справочник: Пер. с англ. СПб.: Издательство «Питер», 1999. -480 е.: ил.

59. Aaron Skonnard. SOAP: The Simple Object Access Protocol//Microsoft Internet Developer. 2000. - January. - c. 33-35.

60. Теркель Д. OLE for Process Control свобода выбора//Современные технологии автоматизации. - 1999. - .№3. - с. 28-32.

61. КуцевичН.А. SCADA-системы. Взгляд со стороны //Промышленные АСУ и контроллеры.- 1999.-№ 1.-е. 22-30.

62. Бунин В., Анопренко В., Ильин А и др. SCADA-системы: проблема выбора // Современные технологии автоматизации. 1999. - .№4. - с. 6-24

63. Ляпунов С.И., Корнеева А.И. Некоторые особенности развития SCADА-систем // Промышленные АСУ и контроллеры. 2002. - .№11. - с. 37-39.

64. ОРС XML-DA Specification, Version RC1.8, Release Candidate, June 13, 2002 // OPC Foundation (http://www.opcfoundation.org').

65. OPC Common Definitions and Interfaces, Version 1.0, October 27, 1998 // OPC Foundation (http://www.opcfoundation.org').

66. OLE for Process Control Data Access Standard (Updated) Version 1.0A September 11, 1997 // OPC Foundation (http://www.opcfoundation.org).

67. Data Access Custom Interface Standard, Version 2.05a, June 18, 2002 // OPC Foundation (http://www.opcfoundation.org).

68. Data Access Custom Interface Standard, Version 3.00, Released, March 4, 2003 // OPC Foundation (http://www.opcfoundation.org).

69. Alarms and Events Custom Interface Standard, Version 1.10, Final Release, October 2, 2002 // OPC Foundation (http://www.opcfoundation.org).

70. OPC Batch Custom Interface Specification, Version 2, July 19, 2001 // OPC Foundation (http://www.opcfoundation.org').

71. OPC Security Custom Interface, Version 1.0, October 17, 2000 // OPC Foundation (http://www.opcfoundation.org').

72. Historical Data Access Custom Interface Standard, Version 1.1, January 26,2001 // OPC Foundation (http://www.opcfoundation.org').

73. OPC Data eXchange Specification, Version 1.0, Release, March 5, 2003 // OPC Foundation (http://www.opcfoundation.org').

74. Куцевич И.В., Григорьев А.Б. Стандарт OPC путь к интеграции однородных систем // Мир компьютерной автоматизации. - 2001. - № 1. - с. 46-52.

75. Марков С.К., Макаров В.Н., Яковлев В.Г., Сергеев Е.М. Контроллеры серии Контраст. Опыт применения и перспективы // Промышленные АСУ и контроллеры. 2003. - № 1. - с. 49-51.

76. Куцевич Н.A. Factory Suite 2000 комплексный инструментарий следующего поколения // PC Week. - 1998. -№48. - с. 11-12.

77. Жучков А.А., Кольцов И.М., Рыбин В.М., Уваров А.В. Учебно-научная лаборатория «Современные интеллектуальные системы и технологии управления и контроля» // Научная сессия МИФИ-2003, сборник научных трудов в 14 томах, том 1. М.:МИФИ. - 2003. - с. 18-19.

78. Григорьев А.Б. ОРС средство общения разнородных систем//Промышленные АСУ и контроллеры. - 2002. - №4. - с. 38-40.

79. Григорьев А .Б. Использование ОРС на примере системы интеллектуальных зданий // Промышленные АСУ и контроллеры. 2003. - №5. - с. 32-36.

80. Дудников В., Набиев Д., Гареев В. Новые возможности управления технологическим процессом нефтедобычи // Современные технологии автоматизации. 2002. -№2.-с. 30-34.

81. Гибшман Е.А., Кузьмина Г. А. Слагаемые эффективности эксплуатируемой АСУ // Промышленные АСУ и контроллеры. 2003. - №5. - с. 3-5.

82. Jim Srothman. ОРС Spreads Wings//InTech. 2002. - June. - с. 18-19.

83. Paul Wacker. Extending the Reach of OPC// InTech. -2001.- September, -c. 12-13.

84. Modbus Messaging on TCP/IP. Implementation Guide Rev 1.0 May 8, 2002. -http://www.modbus.org/

85. Thomas J. Burke. Interoperability in Automation. OPC Evolves and Looks to Win Test of Time // InTech. 2003. - April. - с. 11-13.

86. Joans Berge. OPC DX Is the Soft Gateway // World Bus Journal. 2002. - April. - c. 56.

87. Шустов В., Петров Ю., Шмельков С., Малышев С. Системы аварийной сигнализации и контроля радиационной обстановки // Современные технологии автоматизации. 2000. - №2. - с. 42-48.

88. Системы, разработанные фирмой ПромАвтоматика и внедрённые на предприятиях страны // Промышленные АСУ и контроллеры. -2002. №4. - с. 33-37.

89. Григорьев А.Б., Новиков Е.Н. Передача данных с помощью ОРС на примере системы интеллектуальных зданий // Мир компьютерной автоматизации, 2003. №2. -с. 52-60.

90. Richard С. Harrison. DCOM, OPC and Performance Issues // OPC Foundation. -1998. March. - 3. (http://www.opcfoundation.org).

91. Thomas J. Burke. The Performance and Throughput of OPC. A Rockwell Software Perspective // OPC Foundation. 1998. - June. - 11. (http://www.opcfoundation.org).

92. Куминов В., Куцевич H. Свидание назначено: интеллектуальное производство и бизнес встречаются во всемирной сети, в реальном времени // Мир компьютерной автоматизации. 2002. -№1-2. - с. 19-23.

93. Перри С инк Восемь открытых промышленных сетей и Industrial Ethernet // Мир компьютерной автоматизации. 2002. - №1-2. - с. 94-109.

94. Гэри А. Минтчелл. Информационный обмен и программные стандарты//Мир компьютерной автоматизации. 2002. - №1-2. - с. 46-50.

95. Яловенко Н.П., Лутовинин А.В. Система мониторинга объектов городского хозяйства // Техника для городского хозяйства. 2001. - №3. - с. 48-50.

96. Яловенко H.П., Лутовинин A.B. Интеллектуальные системы сигнализации и новые технологии безопасности // Техника для городского хозяйства. 2001. - №4. -с. 24-28.

97. Куцевич H.A. Industrial SQL база данных реального времени //Мир компьютерной автоматизации. - 1999. - №3. - с. 56-60.

98. Куцевич H.A. Citect новая SCADA-система на российском рынке//Промышленные АСУ и контроллеры. - 2000. - №2. - с. 20-23.

99. Калядин А.Ю. SCADA-система Citect-что внутри?//PCWeek.- 1999.-№48.-с. 12-13.

100. Григорьев А.Б., Новиков E.H. ОРС-сервер для IndustrialSQL 7.1//Промышленные АСУ и контроллеры. -2003. -№1. с. 41-44.

101. Нейдорф P.A., Волков Р.В. Имитационное моделирование в задачах разработки АСУТП // Промышленные АСУ и контроллеры. 2003. - №5. - с. 29-31.

102. Григорьев А.Б. Применение ОРС в московской монорельсовой транспортной системе // Промышленные АСУ и контроллеры. 2004. - №6. - с. 41-43.

103. Шаманов М.А. Инструментальная система программирования логических контроллеров ISaGRAF. Учебное пособие, издание второе, переработанное. Самара: Самарский муниципальный комплекс непрерывного образования «Университет На-яновой», 1997.-c.118.

104. Фролов A.B., Фролов Г.В. Программирование для Windows NT (часть первая). М.: ДИАЛОГ-МИФИ, 1996. - с. 272.

105. Marc Levy. COM Internet Services//MSDN, Backgrounders. 1999.-April.-23.

106. Григорьев А.Б. Использование COM/DCOM и ОРС в интернете// Мир компьютерной автоматизации. — 2003. — №6. — с. 56-59.

107. Армстронг Т. ActiveX: создание Web-приложений: пер. с англ. К.: Издательская группа BHV, 1998. - 592 е.: ил.

108. Тимирбаев А., Лангманн Р. Веб-базированный доступ к технологической информации // Мир компьютерной автоматизации. 2002. - №5. - с. 53-62.

109. Молли Э. Хольцшлаг. Использование HTML 4, 6-е издание. Специальное издание: Пер. с англ., учебное пособие М.: Издательский дом «Вильяме», 2000. - 1008 е.: ил.

110. Колесов А., Павлова О. Visual Basic 6.0 упрощает разработку для Web. Часть 2: Создание IIS(WebClass)-npmi05KeHHii // КомпьютерПресс. 1999. - №5. - с. 29-32.

111. Jeff Webb. Automation for OLE 2.0 // MSDN, Backgrounders. 1993. - April. - 30.

112. OPC Data Access Automation Interface Specification, Version 2.02 Instead of version 2.01; released 03.02.99 // OPC Foundation (http://www.opcfoundation.org).

113. Dino Esposito. Cutting Edge: Remote Scripting // Microsoft Interactive Developer. -1998.- April, -c. 19-22.

114. Хилайер С., Мизнк Д. Программирование Active Server Pages: Пер. с англ.-3-е изд., доп. — М.: Издательско-торговый дом «Русская редакция», 2000. — 320 е.: ил.

115. Don Box Q&A House of COM // Microsoft Systems Journal. 1998. - September. - c. 34-35.

116. Григорьев А.Б. Взаимодействие с ОРС-серверами через Internet //Промышленные АСУ и контроллеры. 2002. - №11. - с. 40-42.

117. Jim Scmidt. ISAPI//Microsoft Interactive Developer. 1996. - Spring.-с. 23-25.

118. Using VBScript and JScript on a Web Page // MSDN, Technical Articles. 1998. - September.

119. Rajiv Dulepet. COM Security in Practice//MSDN, Technical Articles.

120. Mike Blaszczak. Writing Interactive Web Apps is a Piece of Cake with the New ISAPI Classes in MFC 4.1 // Microsoft System Journal. -1996. May. - c. 6-9.

121. Christian Gross. Taking the Splash Diving into ISAPI Programming//Microsoft Interactive Developer. 1997. - January. - c. 16-18.

122. Cariplo: Distributed Component Object Model // MSDN, Backgrounders. 1996.