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

Поддерживаемые коммуникационные протоколы. DDE Dynamic Data Exchange - динамический обмен данными представляет собой коммуникационный протокол, разработанный компанией Microsoft для обмена данными между различными Windows - приложениями.

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

Необходимость в появлении более совершенного технологичного протокола созрела! Но следует отметить, что отказ от DDE-механизма происходит не мгновенно хотя бы потому, что в мире наработано большое количество DDE - серверов. С целью расширения возможностей стандартного протокола DDE на локальную сеть компания Wonderware предложила NetDDE. Он позволяет приложениям, запущенным на объединенных в локальную сеть компьютерах, вести DDE - обмен.

Позднее NetDDE лицензируется компанией Microsoft и поставляется в дистрибутивном пакете Windows. Следует отметить и то, что NetDDE допускает обмен информацией между приложениями на IBM PC и приложениями на машинах другого типа с операционной системой VMS или UNIX. Компания Wonderware предлагает и инструментальные средства для разработки DDE-серверов, в том числе и для не-Windows-платформ. Протокол SuiteLink был специально разработан фирмой Wonderware для того, чтобы удовлетворить таким требованиям, как целостность данных, высокая производительность и простота диагностики.

В основе протокола SuiteLink лежит протокол TCP IP. SuiteLink не является заменой протоколам DDE, FastDDE и NetDDE. Новый протокол разработан для поддержания быстродействующих промышленных систем и обладает следующими характеристиками Передача данных осуществляется в формате VTQ Value, Time, Quality - значение, время, качество, в соответствии с которым каждая пересылаемая клиенту единица информации сопровождается метками времени и качества данных. Благодаря системному монитору операционной системы Windows NT Performance Monitor стал возможным расширенный анализ производительности по передаче данных, степени загрузки сервера, степени потребления ресурсов компьютера и сети, что особенно важно для проектирования и сопровождения больших распределенных промышленных сетей.

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

Для реализации функций OPC - клиента Wonderware предлагает OPCLink - сервер, преобразующий OPC в SuitLink - протокол. В материалах, предложенных компанией Wonderware, отмечается, что большинство реализованных OPC-серверов создают для каждого подключаемого к серверу клиента новый канал связи или нить. Для текущей обработки каждого клиента сервер должен переключаться между нитями. Каждая нить использует DCOM Distributed Component Object Model для организации обмена данными, и DCOM также управляет переключением нитей.

В итоге возможна достаточно низкая производительность в сети. Тесты, проведенные фирмой Wonderware, показали, что при обслуживании OPC-сервером 7 клиентов при передаче 4 целых чисел в режиме обновления сервер на 95 занимал ресурсы CPU. Это означает, что ресурсы компьютера практически целиком были заняты переключением нитей и DCOM- процедурами. Поэтому на текущем этапе параметры производительности протокола SuiteLink превосходят параметры DCOM. Поставляемый в комплекте FactorySuite Wonderware OPCLink Server обеспечивает прием информации с OPC- сервера и передачу ее по протоколу SuiteLink в SCADA - систему InTouch и наоборот.

Именно OPCLink Server рекомендуется устанавливать на одном узле с OPC- сервером, чтобы для сетевых передач использовался SuiteLink- протокол, а не DCOM рис.7 . Рис. 7. Использование SuiteLink - протокола в SCADA - системах. Все описанные ниже особенности адресации распространяются и на OPC-серверы с одним лишь ограничением.

При разработке InTouch - приложения создается канал связи с OPCLink - сервером как с любым другим SuiteLink - сервером. Но рекомендуется использовать встроенный в InTouch OPC Browser для упрощения выбора параметров конфигурации подключаемого OPC - сервера. Особенности адресации в InTouchВ InTouch вышеуказанные механизмы положены в основу обмена данными между приложениями InTouch и DDE и SuiteLink - серверами, которые, в свою очередь, связаны коммуникационными каналами с устройствами нижнего уровня контроллерами. Так как InTouch предназначен для разработки и поддержания интерфейса сбора данных и диспетчерского управления рис.8 , среда исполнения WindowViewer при взаимодействии с контроллерным уровнем выступает, как правило, в роли приложения - клиента узел View, запрашивающего данные у приложения - сервера I O Server. Рис.8. Обмен данными между InTouch - приложением и технологическим процессом.

Через сервер ввода вывода InTouch - приложение имеет возможность читать данные из контроллера или писать данные в него. Процесс обмена информацией InTouch - приложения с контроллером можно представить следующей схемой Здесь и встает один из главных вопросов организации обмена с серверами ввода вывода каким образом обеспечить клиенту доступ к запрашиваемой им информации? Для организации обмена с приложением определяются каналы обмена или каналы доступа, характеризующиеся следующими параметрами имя узла Node Name имя приложения Application Name имя группы данных или топик Topic Name имя элемента Item Name. Имя приложения - это имя программы Windows, которая выполняет функции DDE, FastDDE, SuiteLink - серверов.

Имя группы данных топика определяется при конфигурировании сервера на прием или передачу группы данных, которыми сервер будет обмениваться с контроллером или объединенными в сеть контроллерами.

Определенные параметры группы топика зависят от конкретного сервера поэтому рекомендуется изучать документацию и справочную систему выбранного сервера. Например, при использовании Modbus - сервера, позволяющего обеспечить взаимодействие с контроллером Modicon Micro 984 PLC, в качестве имени приложения Application Name должен быть Modbus, в качестве имени группы или топика Topic Name вводится любое имя текстовая строка, но среди необходимых параметров группы из списка выбирается имя контроллера Modicon 984 PLC. А в качестве имени элемента Item Name следует выбирать название конкретного регистра контроллера например, 40001 для контроллера Modicon Micro 984 . Чтобы узнать правильный синтаксис имени элемента, необходимый для конкретных PLC, нужно обратиться к руководству по соответствующему серверу.

Определены все компоненты коммуникационного канала.

С учетом введенных понятий схема обмена информацией для рассмотренного выше примера будет выглядеть следующим образом рис.9 . Рис. 9. Обмен информацией на примере Modbus - сервера. Фирма Wonderware предлагает DDE и SuiteLink - серверы, которые поддерживают более 800 типов контроллеров основных производителей и различные протоколы.

Если нужного драйвера все-таки нет, можно воспользоваться пакетом разработки драйверов FactorySuite Toolkit. Схемы, приведенные на рис. 9, интерпретируют стандартный обмен информацией между узлом приложением View и контроллером ПЛК в режиме сбора данных и управления. В этом режиме, как уже было сказано выше, приложение View - клиент по определению.