ЖУРНАЛ СТА №3/1999

точка). При добавлении элемента в группу клиент всегда указывает это пол- ное имя. Заметим, что группы, создавае- мые клиентом на сервере, не обязаны совпадать (и, как правило, не совпада- ют) с подразделами пространства имен сервера, элементы в группу добавляют- ся вразнобой. Единственное, что их объединяет, – это общая частота обнов- ления и синхронность отправки клиен- ту. Наконец, на верхней ступеньке ие- рархии понятий находится сам OPC- сервер. Из всех перечисленных (OPC- группа, OPC-элемент) он единственный является COM-объектом, все остальные объекты доступны через его интерфей- сы, которые он предоставляет клиенту. Схема взаимодействия ОРС-клиентов с ОРС-сервером представлена на рисунке. Обмен данными между клиентом и сервером может осуществляться в двух режимах — синхронном и асинхрон- ном. При асинхронном варианте обме- на сервер сам оповещает клиента об из- менившихся значениях данных, на ко- торые подписался клиент (по возмож- ности с частотой, заданной клиентом при создании группы). При синхрон- ном клиент осуществляет инициатив- ное чтение или запись данных. Запись может быть только синхронной. Производительность Затраты ресурсов компьютера на поддержку OPC-взаимодействия и пре- дельно достижимая интенсивность об- мена между клиентом и сервером зави- сят от ряда факторов, но прежде всего – от того, находится ли сервер непосред- ственно в адресном пространстве кли- ента (так называемый внутризадачный — InProcess Server) или он является са- мостоятельным приложением. В по- следнем случае важно, расположен сер- вер на том же компьютере, что и клиент, или на другой станции локальной сети. Третий по важности фактор – это воз- можность группировки данных для от- правки клиентам. Так, передача раз в 1 секунду 100 тегов займет значительно меньше ресурсов, чем одного тега через каждые 10 миллисекунд. Ориентировочные эксперименталь- ные данные о пропускной способности интерфейсов OPC опубликованы на Web-узле OPC Foundation — www.opc- foundation.org (там же можно получить более подробное описание условий проведения эксперимента). Предельная пропускная способность внутризадачного сервера может дости- гать (здесь и далее – на компьютере с процессором Pentium-233) 1 млн. эле- ментов OPC в секун- ду, что значительно превышает все мыс- лимые реальные по- требности. Однако не все OPC-серверы имеют внутризадач- ный (InProcess) вари- ант – для этого они должны оформлять- ся как динамические библиотеки (DLL), а не как самостоятель- ные программы. В случае локально- го сервера (отдель- ная программа, но на том же компьютере) пропускная способ- ность колеблется примерно от 3 до 60 тысяч элементов в секунду. Наихудший вариант соответству- ет передаче единст- венного элемента с максимальной часто- той, наилучший – пе- редаче одновремен- но 100 или более эле- ментов с соответственно меньшей час- тотой. Наконец, для удаленного сервера (в сети Ethernet 10Base–T) пропускная способность оказалась заключена в пределах 330 – 7000 элементов в секун- ду (наилучший и наихудший варианты соответствуют тем же самым крайним случаям). Не следует придавать приведенным цифрам абсолютное значение – они могут варьироваться в зависимости от системной конфигурации, а также осо- бенностей реализации сервера и кли- ента. Так, по данным Rockwell Automation, OPC-сервер (отдельное приложение, не внутризадачный) мо- жет обеспечить обмен с сетевыми кли- ентами до 200000 элементов в секунду. С другой стороны, столь оптимистичес- кие оценки могут быть резко снижены за счет ресурсоемкости обмена с реаль- ной аппаратурой – коммуникационны- ми портами, интерфейсными модулями и т.п., что, конечно, не учитывалось в те- стовых экспериментах, поскольку не имеет прямого отношения к OPC. С точ- ки зрения программной реализации, важно, насколько сервер использует многопоточность (multithreading), в ча- стности, для обслуживания различных групп, а также производится ли кэши- рование значений тегов с целью мини- мизации количества запросов к аппара- туре. Процесс стандартизации Стандарт OPC разрабатывает незави- симая организация – OPC Foundation, насчитывающая более 170 членов, среди которых Siemens, Fisher-Rosemount, Honeywell, Rockwell, Iconics и др., то есть практически все известные (и не очень известные) компании-производители SCADA-систем и оборудования для сис- тем промышленной автоматизации. Тех- ническая деятельность OPC Foundation осуществляется в рабочих группах по направлениям. Среди этих направлений: ● доступ к данным реального времени OPC (Data Access Working Group); ● обработка тревог и событий (OPC Alarms and Events Working Group); ● защита данных (OPC Security Working Group); ● подтверждение соответствия стандар- там OPC (OPC Compliance Working Group); ● доступ к историческим (архивным) данным (OPC Historical Working Gro- up); ● Windows CE (OPC Windows CE Wor- king Group). К настоящему моменту выпущена вто- рая версия спецификации (версия 2.0), определяющая интерфейс доступа к данным реального времени (октябрь 1998 г.). До этого действовала специфи- кация 1a, которая продолжает поддер- живаться OPC-клиентами (то есть сер- веры, разработанные в соответствии со ОБЗОР ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ 31 3/99 Схема взаимодействия ОPC-клиентов с OPC-сервером