Организация взаимодействия с контроллерами

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

Для подсоединения драйверов ввода/вывода к SCADA - системе в настоящее время используются следующие механизмы:

· ставший стандартом de facto динамический обмен данными (DDE);

· собственные протоколы фирм-производителей SCADA - систем, реально обеспечивающие самый скоростной обмен данными;

· новый OPC - протокол, который, с одной стороны, является стандартным и поддерживается большинством SCADA - систем, а с другой стороны, лишен недостатков протоколов DDE.

Изначально протокол DDE применялся в первых человеко - машинных интерфейсах в качестве механизма разделения данных между прикладными системами и устройствами типа ПЛК (программируемые логические контроллеры). Для преодоления недостатков DDE, прежде всего для повышения надежности и скорости обмена, разработчики предложили свои собственные решения (протоколы), такие как AdvancedDDE или FastDDE - протоколы, связанные с пакетированием информации при обмене с ПЛК и сетевыми контроллерами. Но такие частные решения приводят к ряду проблем:

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

Основная цель OPC стандарта (OLE for Process Control) заключается в определении механизма доступа к данным с любого устройства из приложений. OPC позволяет производителям оборудования поставлять программные компоненты, которые стандартным способом обеспечат клиентов данными с ПЛК. При широком распространении OPC - стандарта появятся следующие преимущества:

• OPC позволят определять на уровне объектов различные системы управления и контроля, работающие в распределенной гетерогенной среде;
• OPC - устранят необходимость использования различного нестандартного оборудования и соответствующих коммуникационных программных драйверов;
• у потребителя появится больший выбор при разработке приложений.

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

2.3.1. Аппаратная реализация связи с устройствами ввода/вывода

Для организации взаимодействия с контроллерами могут быть использованы следующие аппаратные средства:

• COM - порты. В этом случае контроллер или объединенные сетью контроллеры подключаются по протоколам RS-232, RS-422, RS-485.
• Сетевые платы. Использование такой аппаратной поддержки возможно, если соответствующие контроллеры снабжены интерфейсным выходом на Ethernet.
• Вставные платы. В этом случае протокол взаимодействия определяется платой и может быть уникальным. В настоящее время предлагаются реализации в стандартах ISA, PCI, CompactPCI.

Прикладные протоколы, используемые для организации взаимодействия с контроллерами, оставлены за границей этой книги.

2.3.2. Особенности построения коммуникационного программного обеспечения

Перед рассмотрением реализации связи с устройствами ввода/вывода в SCADA - системах InTouch и Citect читателю предлагается общий взгляд на организацию коммуникационного ПО в системах управления (рис.2.18).

Рис. 2.18. Типовая архитектура системы управления

Коммуникационное программное обеспечение является многоуровневым. Количество уровней зависит от используемой операционной системы. Так, Applicom предлагает поддержку для следующих ОС: MS-DOS, UNIX SCO, HP-UX V10, OS/2, MS Windows 3.x, Windows 95/98, Windows NT4 на Intel и Alpha-платформах. Для Windows-платформ ПО включает следующие типы:

• статическая библиотека, используемая с традиционными языками программирования, такими как C, C++, Pascal;
• DLL (динамическая библиотека), применяемая со всеми Windows языками программирования (Visual Basic, Visual C/C++, Borland C/C++, Delphi, LabWindows CVI, LabView);
• DDE-сервер (имеет 16 и 32 битные реализации);
• пакетные реализации DDE протокола - FastDDE для продуктов линии Wonderware и AdvancedDDE для Rockwell линии;
• SuiteLink сервер, реализующий механизм обмена по SuiteLink протоколу, используемому компонентами пакета FactorySuite (Wonderware);
• OPC-сервер, поддерживающий интерфейс, определенный OPC- спецификацией.

На рис.2.19 показаны программные интерфейсы для Windows-приложений (в том числе и SCADA-систем) и спектр широко распространенных промышленных протоколов. Использование этих протоколов позволяет организовать взаимодействие с контроллерами, устройствами, объединенными промышленными (fieldbuses) и обычными сетями. Предлагаемая схема решения позволяет конечному пользователю, системному интегратору, единообразным способом организовать взаимодействие между ПО верхнего уровня и платами, специфичными для каждого типа промышленных сетей.

Рис. 2.19. Набор интерфейсов для SCADA - систем и спектр поддерживаемых протоколов

DDE, OPC - компоненты являются серверами по отношению к SCADA - системам. По отношению к ПО нижнего уровня (fieldbus) возможна организация Master/Slave и Client/Server. Внешние устройства способны посылать и принимать данные через плату. Когда вставная в персональный компьютер плата является Master/Client, то именно плата с поддерживаемым ПО является инициатором опроса промышленных устройств. В случае применения плат типа Slave/Server они реагируют на запросы внешних устройств. На некоторых вставных платах имеется разделяемая область памяти. Эта память доступна как приложению в ПК, так и встраиваемому ПО.

На рис.2.20 показана обобщенная схема организации коммуникационного ПО для Windows NT. На предлагаемой схеме отражены как традиционные решения на базе стандартных Windows NT - драйверов, так и с использованием библиотек, реализованных в расширении реального времени RTX от VenturCom.

Рис.2.20. Схема организации коммуникационного ПО для Windows NT

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

2.3.3. Серверы ввода/вывода в InTouch

При функционировании InTouch - приложения в реальном времени информация обо всех его переменных хранится в базе данных. К такой информации относятся имя переменной, ее тип, минимальное и максимальное значения, уставки, способ отображения (дисплей, журнал) и т. д., а также информация о коммуникационных каналах, по которым происходит обмен данными между технологическим процессом и приложением. InTouch - приложение поддерживает взаимодействие с DDE и OPC-серверами. Именно на организации взаимодействия с ними и остановимся ниже.

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

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 (рис.2.21).

2.21. Использование SuiteLink - протокола в SCADA - системах

Все описанные ниже особенности адресации распространяются и на OPC-серверы с одним лишь ограничением. При разработке InTouch - приложения создается канал связи с OPCLink - сервером (как с любым другим SuiteLink - сервером). Но рекомендуется использовать встроенный в InTouch OPC Browser для упрощения выбора параметров конфигурации подключаемого OPC - сервера.

Особенности адресации в InTouch

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

Так как InTouch предназначен для разработки и поддержания интерфейса сбора данных и диспетчерского управления (рис.2.22), среда исполнения WindowViewer при взаимодействии с контроллерным уровнем выступает, как правило, в роли приложения - клиента (узел View), запрашивающего данные у приложения - сервера (I/O Server).

Рис.2.22. Обмен данными между InTouch - приложением и технологическим процессом

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

Рис. 2.23. Схема обмена информацией 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, нужно обратиться к руководству по соответствующему серверу.

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

Рис. 2.24. Обмен информацией на примере Modbus - сервера

Фирма Wonderware предлагает DDE и SuiteLink - серверы, которые поддерживают более 800 типов контроллеров основных производителей и различные протоколы.

Если нужного драйвера все-таки нет, можно воспользоваться пакетом разработки драйверов FactorySuite Toolkit.

Схемы, приведенные на рис. 2.23, 2.24, интерпретируют стандартный обмен информацией между узлом (приложением) View и контроллером (ПЛК) в режиме сбора данных и управления. В этом режиме, как уже было сказано выше, приложение View - клиент по определению.

Обмен данными с другими приложениями

Но приложения InTouch могут взаимодействовать не только между собой, но и с другими Windows - приложениями. Одним из известных примеров такого приложения является Microsoft Excel. InTouch - приложение может считывать и записывать какие - либо значения в любую клетку открытой в Excel электронной таблицы. Аналогично и программа Excel может читать и записывать информацию в базу данных InTouch - приложения. Данный механизм обеспечивает одновременное обновление данных в одном приложении при изменении их значений в другом.

Если клиентом (приложением, запрашивающим информацию) по - прежнему является узел View, то Excel - это приложение, поставляющее информацию (сервер). В качестве группы или топика (Topic) тогда будет выступать имя таблицы Excel, а элемент обмена информацией - ячейка в таблице Excel (табл.2.5, вариант 1). Когда клиентом является приложение Excel, а сервером - приложение View, группой в этом случае всегда является словарь переменных InTouch (база данных) с именем Tagname. Элементом обмена будет элемент базы данных - имя переменной (табл.2.5, вариант 2).

Таблица 2.5 Приложение-клиент Приложение-сервер Группа Элемент View Excel Sheet1.XLS R1C1 Excel View Tagname R_Level

В случае обмена данными по сети с использованием пакета Wonderware NetDDE необходимо к трехуровневой структуре адреса добавить четвертый уровень - имя удаленного узла сети (Node Name).

Подводя итог вышесказанному, следует подчеркнуть, что информация по доступу к данным устройств ввода/вывода или других приложений должна храниться в приложении (в словаре переменных). И разработчику в InTouch-приложении важно подключиться к вышеописанному каналу доступа. Для этого в InTouch необходимо определить имя доступа Access Name и связать его с переменной приложения.

Определение имени доступа в словаре переменных InTouch

В InTouch - приложениях вся информация о переменных приложения хранится в Tagname Dictionary (Словарь переменных). Это не что иное, как база данных реального времени - один из центральных компонентов InTouch.

При определении переменной в базе данных InTouch запрашивает определенную информацию о каждой переменной, например, имя переменной, ее тип, имя доступа и т. д. В пакете InTouch используется два базовых типа переменных - Memory (внутренние) и I/O (переменные ввода/вывода). Переменные типа Memory могут быть использованы для создания различных системных констант, моделирования элементов системы управления и в вычисляемых переменных, доступных другим Windows - программам. Все переменные, которые получают или передают свое значение другой Windows - программе, должны иметь тип ввода/вывода (I/O). В эту категорию попадают переменные, которые посредством канала доступа (Access Name) принимают или отправляют данные из/в серверов ввода/вывода, других приложений InTouch, других программ Windows.

Определение новой переменной в базе данных InTouch, как и просмотр, и модификация атрибутов уже существующих переменных, производится в диалоге Tagname Dictionary (рис.2.25). Доступ к этому диалогу осуществляется командой Speсial/Tagname Dictionary в окне среды разработки WindowMaker или двойным щелчком по иконке Tagname Dictionary в окне Application Explorer.

Рис. 2.25. Диалог Tagname Dictionary (Словарь переменных)

Поля Tagname и Comment предназначены для ввода имени переменной и соответствующего комментария. По умолчанию включена опция Read/Write (чтение/запись). Можно отметить и опцию Read Only, если в процессе исполнения WindowViewer должен только читать значение переменной. В любое время в режиме проектирования можно открыть список переменных приложения щелчком по кнопке Select для выбора соответствующей переменной, просмотра списка или модификации атрибутов. Диалог Select Tag (выбор переменной) представлен на рис.2.26.

Рис. 2.26. Диалог Select Tag (выбор переменной)

Для каждой переменной в этом диалоге приведена следующая информация: имя переменной, ее тип, имя доступа, группа аларма и комментарий. Группа алармов (Alarm group, рис.2.26) для переменной определяется в диалоге, вызываемом нажатием кнопки Group диалога Tagname Dictionary. Все, что касается алармов, рассматривается в соответствующем разделе ниже. Выбор типа переменной осуществляется в диалоге Tag Types (тип переменной, рис. 2.27), вызываемом на экран нажатием кнопки Туре диалога Tagname Dictionary.

Рис. 2.27. Диалог Tag Types (тип переменной)

В этом диалоге представлен полный список основных типов переменных InTouch. Выбор завершается отметкой соответствующей опции и щелчком по Ok. После выбора типа переменной программа возвращает пользователя в диалог Tagname Dictionary (Словарь переменных). При этом будет открыт и дополнительный диалог подробного описания переменной, содержание которого зависит от выбранного типа. На рис.2.28 представлен диалог подробного описания вещественной переменной типа I/O Integer.

Рис. 2.28. Диалог подробного описания переменной типа I/O

Кнопка Access Name (имя доступа) используется для определения канала обмена (канала доступа) с сервером, с которым будет связана описываемая переменная. Имя доступа Access Name определяется именем узла, именем приложения и именем группы или топика. Имя топика должно совпадать с соответствующим именем, заданным при конфигурировании DDE, SuiteLink-сервера. Имя элемента, как компонента многоуровневого адреса, определяется в поле Item (рис.2.28).

В распределенных системах InTouch имя доступа может быть определено либо как локальный адрес, либо как глобальный.

Локальные адреса используются в том случае, когда View - узлы имеют свои серверы ввода/вывода. На рис. 2.29 узлы исполнения (View - узлы), каждый со своей копией одного и того же приложения, ссылаются на свои собственные источники данных ввода/вывода (серверы ввода/вывода).

Рис. 2.29. Сеть View - узлов с собственными серверами ввода/вывода

Поэтому при определении канала доступа к информации ввода/вывода достаточно трехуровневого адреса (Application - приложение, Topic - объект, Item - элемент). Имя узла (Node) в этом случае опускается. Щелчок по кнопке Access Name (рис.2.30) вызывает на экран одноименный диалог.

Этот диалог предназначен для определения нового канала доступа (кнопка Add), модификации существующего (Modify) или удаления (Delete). Щелчок по кнопке Add вызывает диалог определения нового канала доступа (рис.2.31).

Рис. 2.30. Диалог Access Names (имена доступа)

Рис.2.31. Диалог определения нового канала доступа (локальный адрес)

Диалог определения канала доступа заполнен в соответствии с примером, рассмотренным на рис.2.24. В качестве имени (канала) доступа (Access Names) рекомендуется выбирать имя группы или топика (Topic Name). Следует подчеркнуть, что поле Node Name (имя узла) оставлено пустым. Щелчок по кнопке Ok возвращает пользователя в диалог Access Names (имена доступа) с определенным именем доступа.

Рис.2.32. Диалог Access Names с определенным именем доступа

Глобальные адреса источников данных ввода/вывода позволяют нескольким View - узлам обращаться к одному и тому же серверу ввода/вывода. Такой подход предоставляет возможность отказаться от нескольких серверов ввода/вывода, однако менее защищен от отказов (рис.2.33).

Рис.2.33. Архитектура с двумя View - узлами и сервером ввода/вывода.

Два View - узла исполняют идентичные копии одного и того же приложения и ссылаются на один и тот же источник ввода/вывода (I/O сервер). Поэтому при определении канала доступа к информации ввода/вывода необходимо использовать четырехуровневый адрес (Node - узел, Application -приложение, Topic - объект, Item - элемент). Заполненный диалог при определении имени доступа для такой конфигурации представлен на рис. 2.34.

Рис.2.34. Диалог определения нового канала доступа (глобальный адрес).

При выборе имени доступа действует то же правило, что и при локальной адресации: рекомендуется, чтобы это имя совпадало с именем группы данных или топика (Topic Name). Но поле Node Name (имя узла) необходимо заполнить. В качестве этого имени при глобальной адресации выбирают имя узла, на котором установлен сервер ввода/вывода, являющийся источником данных для нескольких приложений.

Для каждой переменной ввода/вывода задается атрибут Access Name. С одним именем доступа, как правило, связано большое количество переменных. Распределение переменных по группам (топикам) - произвольное. Но для оптимизации функционирования серверов рекомендуется в одну группу относить переменные с одинаковой частотой обновления. В противном случае частота, задаваемая при конфигурировании топика в сервере, должна соответствовать минимальному временному кванту. Желательно на этапе конфигурирования сервера определить группы (топики) для каждого частотного диапазона и в соответствии с этими группами создать имена доступа (Access Name) в InTouch (лучше даже, чтобы имена групп совпадали с именами доступа). А далее каждую описываемую в InTouch-приложении переменную типа I/O связывать с подходящим именем доступа для обеспечения рационального пакетирования данных.

2.3.4. Коммуникационные возможности в Citect

Коммуникационные протоколы

Для обмена данными с контроллерами в Citect могут использоваться следующие способы: встраиваемые драйверы, DDE - обмен, OPC - протоколы.

• Первый путь предполагает создание динамических библиотек, выполняющих функцию драйверов. Citect поставляется с более чем 120 драйверами ввода/вывода. Все эти драйверы 32 - разрядные и обеспечивают подключение более 300 типов ПЛК, RTU, микроконтроллеров, Loop - контроллеров и т. д. Среди них контроллеры фирм ABB (AC 110, AC 160, AC 410, AC 450, Commander 100, 150, 200, 300), Advantech (Adam 4000, Adam 5000), Allen Bradley (PLC-5, PLC-5/250, PLC-2, PLC-3, SLC 500), Bristol Babcock (33хх RTUs), Control Microsystems (TeleSAFE), Fuji, Foxboro (760 Series), GE Fanuc (Series 90, Series 9070, Series 9030, Series 6), Hewlett Packard (HP 3852A), Hitachi (H20, H200, H250, H700), Honeywell (620 Series, TDC2000, UDC3000), Koyo (405 Series), Mitsubishi (Melsec A, AnA, FX), Modicon (Series 484, Series 584, Series 884, Series 984), Motorola (Moscad RTU), Omron, Samsung (Fara PLC), Siemens (Simatic - модели S5, S7, TI), Toshiba (EX 100, EX 250, EX 500, EX 2000, Tosdic-200, DPCS, PCS, OIS, SIS), Yokogawa (4082 Hybrid Recorder, 3880 Hybrid Recorder, Micro XL, Centum XL) и многих других фирм. Если нужного драйвера в системе Citect не окажется, можно воспользоваться пакетом разработки драйверов Driver Development Kit (DDK).
• Связь через DDE - сервер использует стандартный коммуникационный протокол Windows. Citect поддерживает связь с любым DDE - сервером.
• Система Citect может функционировать в качестве и OPC - сервера и OPC - клиента.

Установка связей с устройствами ввода/вывода

Система Citect имеет в своем составе специальную утилиту - Express Communications Wizard (система установки связи) - средство быстрого и простого конфигурирования устройств. Эта программа использует полученную на каждом шаге процесса установки информацию и снабжает разработчика установками по умолчанию, оставляя в тоже время варианты выбора параметров ввода/вывода. Каждый диалог программы содержит четыре кнопки управления процессом установки связи:

• Next - продолжение установки;
• Back - возврат на предыдущий шаг;
• Cancel - отмена установки;
• Help - справочная информация.

Щелчок по кнопке Finish последнего диалога завершает установку связи. Доступ к системе установки связи осуществляется в Citect Explorer из папки Communications соответствующего проекта (рис. 2.35).

Рис. 2.35. Доступ к мастеру коммуникаций из Citect Explorer

Двойной щелчок по иконке Express I/O Device Setup запускает процесс установки и конфигурирования устройств ввода/вывода.

В этом диалоге предлагается определить Citect -компьютер как сервер ввода/вывода и присвоить ему уникальное имя.

Последовательное нажатие клавиши Next (далее) открывает перед разработчиком новые диалоги, предлагая ввести необходимую информацию по установке связи между Citect и устройством ввода/вывода.

Citect предоставляет возможность пользователю разрабатывать и отлаживать проект без необходимости физического подключения к реальному устройству ввода/вывода. Просто при конфигурировании устройства ввода/вывода его можно определить как внутреннее (Memory I/O Device) или как диск (Disk I/O Device).

Теперь Citect будет работать так, как будто взаимодействует с реальным контроллером. При выборе Disk I/O Device данные сохраняются в виде файла на жестком диске. При перезапуске Citect данные остаются доступными. Disk I/O Device может использоваться и другими компьютерами через ЛВС (LAN). Данные, записанные в Memory I/O Device, теряются при перезапуске системы.

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

Одним из основных элементов при обмене данными между компьютером и устройством является адрес устройства. Эту информацию можно найти в документации на используемый сервер ввода-вывода.

В результате работы Express Communications Wizard будет заполнено несколько диалогов, полностью характеризующих установленную связь между Citect- компьютером и устройством ввода/вывода. Находясь в Citect Explorer (см. рис. 2.35), можно дважды щелкнуть по соответствующей каждому диалогу иконке и отредактировать параметры связи.

Диалоги, автоматически заполненные в процессе работы Express Communications Wizard при установке связи между Citect - компьютером и контроллером Mitsubishi Melsec-FX Series PLC, подсоединенным к последовательному порту Com1, показаны на рис. 2.36.

• В диалоге Server (сервер) для определения сервера задают его имя в поле Server Name. При наличии двух серверов (дублирование) каждый сервер должен иметь свое имя.
• Диалог Boards (интерфейсная плата) включает следующие поля:
• имя сервера (Server Name);
• имя интерфейсной платы (Boards Name);
• тип интерфейсной платы (Boards Type);
• адрес интерфейсной платы (Address);
• адрес порта в интерфейсной плате (I/O port).

Рис. 2.36. Диалоги конфигурирования параметров связи

• Диалог Ports (порт) включает следующие поля:
• имя порта (Port Name);
• номер порта (Port Number);
• имя интерфейсной платы (Boards Name);
• скорость в бодах (Baud Rate);
• количество битов (Data Bits) - 7 или 8;
• количество стоповых битов (Stop Bits) - количество битов в конце посылки (1 или 2);
• контроль на четность (Parity).
• Диалог I/O Device (устройство ввода/вывода) включает следующие поля:
• имя устройства ввода/вывода (Name);
• номер устройства ввода/вывода (Number) - 0 - 4095;
• адрес (Address); - протокол (Protocol) - большинство устройств поддерживает ряд протоколов, выбор которых зависит от выбранного метода связи;
• имя порта (Port Name), обеспечивающего взаимодействие с устройством ввода/вывода.

Итак, канал связи полностью определен, и это заняло у опытного пользователя всего несколько десятков секунд (в крайнем случае, пару минут). Теперь предлагается определить переменные, подключаемые к этому каналу связи. Находясь в Citect Explorer, следует открыть папку Tags, а затем дважды щелкнуть на иконке Variable Tags. На экране появится диалог (рис.2.37).

Рис. 2.37. Диалог Variable Tags (переменная)

Для каждого переменной следует определить:

• уникальное имя (Variable Tag Name);
• тип данных (Data Туре);
• имя устройства ввода-вывода (I/O Device Name);
• адрес (Address);
• формат данных (Format) и т. д.

Этот диалог придется заполнять для каждой переменной, нажимая каждый раз клавишу Add (добавить). Хотя информация, вводимая по каждой переменной, достаточно однотипна, при большом количестве переменных процесс будет достаточно трудоемким.

Все переменные проекта хранятся в формате DBF, и возможно непосредственное редактирование баз данных с использованием таких программных продуктов, как Microsoft Excel. Файл с базой данных Variable.dbf находится в директории \Citect\User\. Такая возможность работы с базой данных переменных позволит существенно сократить сроки разработки проекта. Фрагмент файла Variable.dbf приведен на рис. 2.38.

Рис. 2.38. Фрагмент базы данных в таблице Excel

2.3.5. Подключение узлов Citect

Архитектура клиент – сервер

Citect ориентирован на реализацию архитектуры клиент - сервер и имеет в своем составе пять функциональных модулей (серверов или клиентов):

• I/O - сервер ввода/вывода. Обеспечивает передачу данных между физическими устройствами ввода/вывода и другими модулями Citect.
• Display - клиент визуализации. Обеспечивает операторский интерфейс: отображение данных, поступающих от других модулей Citect, и управление выполнением команд оператора.
• Alarms - сервер алармов. Отслеживает данные, сравнивает их с допустимыми пределами, проверяет выполнение заданных условий и отображает алармы на соответствующем узле визуализации.
• Trends - сервер трендов. Собирает и регистрирует трендовую информацию, позволяя отображать развитие процесса в реальном масштабе времени или в ретроспективе.
• Reports - сервер отчетов. Генерирует отчеты по истечении определенного времени, при возникновении определенного события или по запросу оператора.

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

Для средних и больших проектов (тысячи и десятки тысяч параметров) можно использовать сетевые возможности Citect. Компьютеры системы управления могут быть распределены по всему предприятию (цехам, участкам, офисам) и поставлять информацию оперативному персоналу и различным службам.

Сетевые возможности Citect допускают использование в локальной сети до 256 компьютеров. Каждый из них может играть роль Display Client. Но по меньшей мере один из этих компьютеров должен быть сервером (ввода/вывода, алармов, трендов, отчетов).

Архитектура клиент - сервер может быть представлена разнообразными вариантами: например, один компьютер может быть сервером ввода/вывода данных и сервером алармов, другой - сервером отчетов и сервером трендов. Остальные компьютеры сети являются клиентами визуализации - Display Client (рис.2.39 - слева).

File Server - компьютер с большой емкостью памяти (жесткий диск, лазерные диски) для хранения всей информации локальной сети (сервер базы данных). Для очень больших систем можно предложить вариант, в котором каждая задача обслуживается отдельным компьютером (сервер ввода/вывода, сервер тревог, сервер трендов и сервер отчетов), причем клиентами визуализации могут быть несколько компьютеров. Пример такой системы приведен на рис. 2.40.

Рис. 2.40. Вариант сетевой архитектуры системы Citect

Следует отметить, что для рассматриваемых архитектур можно использовать только один сервер алармов, сервер трендов и сервер отчетов. В то же время допускается использование нескольких серверов ввода/вывода (I/O Server).

Конфигурирование Citect-компьютеров в сети

Сетевые средства Citect построены на базе NetBIOS и поддерживаются такими сетевыми протоколами, как NetBEUI, IPX/SPX, TCP/IP. С другой стороны, Citect поддерживает все сетевые протоколы, совместимые с NetBIOS, что существенно расширяет спектр сетей, с которыми может взаимодействовать Citect. К таким сетям можно отнести Ethernet, Arcnet, Internet, Novell Netware, LAN Manager и др.

Конфигурирование Citect-компьютеров в локальной сети, т. е. распределение клиент-серверных задач между узлами системы управления, производится с помощью системы конфигурирования компьютеров (Computer Setup Wizard), входящей в состав системы Citect.

При этом пользователю не предлагается выбор