Цель статьи. Рассмотреть возможности взаимодействия SCADA системы zenon с внешним программным обеспечением, выбрать из доступных решений наиболее подходящие и обосновать возможность их применения для конкретных задач.
Постановка задачи. В промышленности существуют классы объектов управления, при автоматизации которых основное значение имеет качество управления, а не быстродействие. Разработка систем управления для таких объектов связана с большими временными затратами на выбор и реализацию алгоритма управления. При этом реализация алгоритма может быть выполнена на уровне программируемого логического контроллера или SCADA системы на базе программного логического контроллера, скриптов, VBA, VSTA или других технологий.
Непосредственно разработка алгоритмов и их первичная проверка выполняется в специализированном программном обеспечении таком как: MATLAB, LabVIEW, Mathematica, Maple и другие. Прямой перенос алгоритмов на программируемый логический контроллер или в SCADA систему требует больших временных затрат, что связано с особенностями реализации языков программирования как программного обеспечения, так и средств автоматизации.
Из этого следует, что на этапе разработки целесообразно использовать в качестве устройства выполнения алгоритма управления персональный компьютер с соответствующим программным обеспечением, а в качестве устройства управления программируемый логический контроллер или модули удаленного ввода-вывода. При этом доступ к программируемому логическому контроллеру или модулям удаленного ввода-вывода может быть организован как напрямую (если данный контроллер поддерживается программным обеспечением), так и при помощи SCADA системы обладающей необходимым набором драйверов.
Одним из лидеров рынка SCADA систем является zenon, выпускаемый австрийской компанией COPA-DATA. Данная система обдает широким функционалом, большим выбором драйверов (более 300), прошла сертификацию компании Microsoft и соответствует требованиям множества международных стандартов. Рассмотрим возможности SCADA системы zenon Supervisor 7.10 по взаимодействию с внешним программным обеспечением MATLAB R2012b.
Определяющей особенностью SCADA zenon является вертикальная открытость. Благодаря передовым технологиям, внедренным в данный программно-технический комплекс, все потоки информации, собранные на уровне датчиков и исполнительных механизмов, могут быть оперативно обработаны и переданы во внешние MES- и ERP-системы, где осуществляется анализ и планирование современного производства.
В состав SCADA системы zenon входит коммуникационный шлюз zenon Process Gateway. Он предназначен для установки связи с системами высокого уровня и включает следующие модули: DEC Slave, DNP3 Slave, ICCP/TASE.2, IEC61870-5-01/104 Slave, Modbus Slave, OPC DA Server, OPC UA Server, SNMP Server, SQL Online. Модули не зависят от SCADA системы, требуют отдельного лицензирования и могут быть разработаны и расширены отдельно от нее.
DEC Slave модуль позволяет осуществлять двунаправленный обмен с системами хранения данных S-DEC, работающими под управлением операционной системы UNIX. Обмен данными построен на базе протокола TCP.
DNP3 Slave модуль позволяет осуществлять двунаправленный обмен данными между компонентами АСУ ТП. При коммуникации используется последовательный интерфейс или Ethernet.
ICCP/TASE.2 модуль позволяет осуществлять двунаправленный обмен данными в соответствии с стандартом МЭК 60870-6. Стандарт определяет базовый протокол передачи простых сообщений для удаленного контроля между двумя системами. Для обмена данными может использоваться последовательный интерфейс или Ethernet.
IEC61870-5-01/104 Slave модуль позволяет осуществлять двунаправленный обмен данными в соответствии с стандартом МЭК 61870-5-104. Для обмена данными может использоваться последовательный интерфейс или Ethernet.
Modbus Slave модуль позволяет осуществлять двунаправленный обмен данными в соответствии с протоколами Modbus RTU и Modbus TCP/IP. Для обмена данными может использоваться последовательный интерфейс или Ethernet.
OPC DA Server модуль позволяет осуществлять двунаправленный обмен данными c OPC DA клиентами версий 1.X, 2.X. Передача данных построена на базе технологий OLE, COM/DCOM компании Microsoft.
OPC UA Server модуль позволяет осуществлять двунаправленный обмен данными, независящий от аппаратно-программной платформы клиента, а также типа его сети. Транспортный механизм обмена данными построен на базе SOAP, XML, HTTP и сервисов.
SNMP Server модуль позволяет осуществлять двунаправленный обмен данными, основанный на базе архитектуры UDP/TCP.
SQL Online модуль позволяет осуществлять однонаправленную запись в базу данных SQL. При этом модуль следит за тем, что бы в базе данных всегда находились актуальные значения.
Если у потребителя имеется готовое решение, выступающее в сети ведомым устройством или сервером другой технологии, то zenon позволяет беспрепятственно подключиться к нему при помощи соответствующего драйвера: DNP3 Driver Next Generation, IEC 60870-5-10X, Modbus RTU and Open Modbus TCP, OPC Client V2-0 driver, OPC UA Client driver, SNMP Driver, SQL Driver, Write variable value in SQL.
Для организации двунаправленной связи с приложениями SAP/RP ERP в систему интегрировано модуль SAP Interface. Благодаря этому пользователи, которые занимаются планированием бизнес процессов, могут в онлайн режиме взаимодействовать с уровнем производства предприятия.
Так же для обмена данными с SCADA системой zenon может быть использован механизм взаимодействия приложений DDE, являющийся стандартным для семейства операционных систем Microsoft Windows.
Проанализировав перечисленный перечень решений, можно сделать вывод, что наиболее подходящими для поставленной задачи являются технологии DDE, OPC DA и SQL, которые и будут рассмотрены далее.
Dynamic Data Exchange (DDE) – это механизм обмена данными между разным программным обеспечением, используемый в Windows. Данная технология поддерживает как однократную передачу данных, так и непрерывную.
Механизм DDE реализует клиент-серверную архитектуру. В качестве клиента может выступать любое программное обеспечение позволяющее отправлять запросы к серверу, а в качестве сервера – программное обеспечение умеющее принимать запросы от клиента и посылать данные в ответ на запрос. У одного сервера может быть один или несколько клиентов.
Данные доступные DDE серверу адресуются с помощью темы “Topic” и раздела “Item”. Сервер может включать несколько тем, каждая из которых в свою очередь может иметь несколько разделов. Обмен данными между клиентом и сервером организуются на основе транзакций. Рассмотрим два основных типа транзакций. Транзакция запроса данных “Транзакция 1” начинается с запроса от клиента к серверу, в котором должны быть указаны название сервера “Приложение 1”, название темы “Topic 1”, название раздела “Item 1”. В ответ на запрос сервер возвращает данные связанные с темой и разделом “Данные 1”. На этом транзакция завершается. Транзакция передачи данных “Транзакция 2” состоит только из запроса от клиента к серверу, в котором указывается название сервера “Приложение 1”, название темы “Topic 1”, название раздела “Item 1” и сами данные “Данные”.
SCADA система zenon может функционировать как DDE сервер и как DDE клиент. Так как внешнее программное обеспечение MATLAB может выступать только в роли DDE клиента, рассмотрим процесс настройки SCADA системы zenon в режиме DDE сервера.
Для этого в SCADA системе zenon создадим внутреннюю переменную “DDEVariableOutput” целочисленного типа “INT”.
Что бы данная переменная была доступна DDE серверу и, следовательно, внешнему программному обеспечению в ее настройках необходимо установить флаг “Permanently read variable” (Постоянный опрос переменной), при этом значение переменной DDE сервера будет обновляться каждые 500 миллисекунд.
Доступ к переменным SCADA системы zenon возможен только во время работы среды исполнения (Runtime). При формировании запроса со стороны DDE клиента в качестве имени сервера должно быть задано значение “ZENVIS”. Переменные доступные для DDE сервера находятся в теме “VARIABLE”, а название раздела совпадает с именем переменной “DDEVARIABLEOUTPUT”, регистр символов в названии переменной значения не имеет.
Далее приведен пример программы на языке MATLAB, позволяющий получить значение переменной “DDEVariableOutput” и задать ей новое значение:
OPC Data Access – это наиболее широко используемая технология стандарта OPC, предназначенная для предоставления единого интерфейса управления объектами автоматизации, технологическими процессами, и организации обмена данными между программным обеспечением разработанным под семейство операционных систем Microsoft Windows. Она построена на базе технологий OLE, COM/DCOM и осуществляет чтение, запись и мониторинг переменных в реальном времени, представляющих собой контролируемые параметры. Операции чтения и записи могут выполняться синхронно, асинхронно, по обновлению данных и спонтанно.
Технология OPC DA имеет клиент-серверную архитектуру. В качестве OPC клиента может выступать любое программное обеспечение, поддерживающее один из интерфейсов: “Custom” или “Automation”.
Интерфейс “Custom” используется в клиентах, разрабатываемых на компилируемых языках программирования (С, C++). Такие клиенты, работают с OPC серверами напрямую посредством COM интерфейса.
Интерфейс “Automation” построен на базе технологии “OLE Automation”, которая позволяет обращаться к COM-компонентам из интерпретируемых языков программирования (MATLAB, Maple, Mathcad, VBScript). Такие клиенты используют интерфейс “OPC Automation interface” для связи с оберткой “OPC Automation Wrapper”, которая посредством COM интерфейса напрямую работает с OPC серверами.
В качестве OPC сервера может выступать специализированное программное обеспечение, имеющее COM интерфейс и обеспечивающее доступ к объектам автоматизации и программному обеспечению при помощи интерфейса программирования приложений “Native API”.
В своем большинстве OPC сервера разрабатываются производителями аппаратного и программного обеспечения, чтобы предоставить доступ к их данным внешнему программному обеспечению. Для этого OPC сервера включают в себя наборы драйверов, с помощью которых они получают доступ к данным аппаратного или программного обеспечения и COM интерфейс, позволяющий получить доступ к этим данным из любого внешнего программного обеспечения. Этот подход дает возможность работать с данными из разных источников, абстрагируясь от процесса их формирования.
Рассмотрим взаимодействие программного обеспечения OPC сервера с клиентами. Исходно OPC сервер находится в выключенном состоянии. При запросе клиента сервер запускается, после чего между ними устанавливается соединение. Далее выполняется инициализация клиента.
Во время инициализации происходит настройка доступа к данным. Клиент запрашивает у сервера список элементов “Item”, к которым имеет доступ OPC сервер. Сервер возвращает “ItemID” доступных элементов, которые представляют собой текстовые, уникальные в приделах сервера, идентификаторы, однозначно связанные с его элементами.
В свою очередь каждый элемент представляет собой объект, содержащий данные устройства или программного обеспечения, к которым предоставляет доступ OPC сервер. Кроме самих данных, объект содержит метку времени и информацию об их качестве (как точно соответствуют данные сервера данным устройства или программного обеспечения).
Далее клиент создает группы “Group”, настраивает их свойства, и помещает в них элементы, с данными которых он будет взаимодействовать. Группы создаются на стороне сервера и могут быть частными “private” или общими “public”. Частные группы доступны только клиенту, который их создал, общие группы доступны всем клиентам. При этом для каждого клиента сервер создает копию общей группы. То есть по факту, каждая конкретная группа, принадлежащая конкретному клиенту, физически располагается на стороне сервера, а логически – на стороне клиента. На основании групп формируются иерархические структуры, которые объединяют данные связанные общей логикой происхождения или использования.
Группы обладают свойствами, позволяющими управлять обновлением данных OPC сервера:
По завершению этапа инициализации клиент получает доступ к данным элементов OPC сервера. Обмен данными может происходить как в синхронном, так и асинхронном режимах. После того как последний клиент отключится от OPC сервера, он выключится.
На рисунке приведена типовая структура взаимодействия “Приложения” клиента с OPC серверами. Программируемые логические контроллеры подключены к “OPC серверу 1”, панели человеко-машинного интерфейса к “OPC серверу 2”, а SCADA система zenon к “OPC серверу N”. “Приложение” посредством “OPC клиента” подключено ко всем OPC серверам. Элементы OPC серверов добавлены в группы таким образом, чтобы удобно было определить к какому устройству или программному обеспечению они относятся.
SCADA система zenon может функционировать как OPC сервер и как OPC клиент. Так как внешнее программное обеспечение MATLAB может выступать только в роли OPC клиента, рассмотрим процесс настройки SCADA системы zenon в режиме OPC сервера.
OPC DA Server хотя и входит в состав zenon Process Gateway представляет собой отдельное программное обеспечение “zenon OPC Server”, которое регистрируется в операционной системе Microsoft Windows под именем “zenOPCSrv.Server.1” и запускается во время работы среды исполнения по запросу от OPC клиента. Данный сервер является локальным и поэтому доступен для приложений только того персонального компьютера на котором работает среда исполнения, кроме того он не может быть запущен в операционных системами Microsoft Windows CE.
Если zenon OPC сервер недоступен через OPC клиент, его необходимо зарегистрировать. Для этого требуется запустить “zenon Startup Tool” от имени администратора, выбрать в окне инструментов “Tools” пункт “OPC server” и задать в строку “Command line parameters” (Командная строка параметров) параметр “ /RegSrvD” (перед параметром необходимо добавить пробел).
zenon OPC сервер предоставляет доступ к переменным всех проектов, выполняемых средой исполнения. Каждой переменной проекта SCADA системы zenon соответствует элемент, имеющий идентификатор вида <PROJECT.Variable>, где PROJECT – имя проекта, а Variable – имя переменной в этом проекте. Элементы, соответствующие переменным разных проектов, не могут находиться в одной группе, поэтому для каждого проекта необходимо использовать отдельную группу. Кроме того, так как SCADA система zenon и zenon OPC сервер работают на одном компьютере, сервер игнорирует свойство группы “время опроса” и выполняет обновление данных сразу после их изменения.
Создадим в SCADA системе zenon внутреннюю переменную “OPCVariableOutput” целочисленного типа “INT”. Для организации доступа к OPC серверу переменная не требует никаких дополнительных настроек в zenon. Поэтому после запуска среды исполнения она сразу будет доступна OPC клиенту.
Далее приведен пример программы на языке MATLAB, позволяющий получить значение переменной “OPCVariableOutput” и задать ей новое значение (для того чтобы в MATLAB работал OPC Toolbox, необходимо предварительно при помощи команды “opcregister('install')”) установить OPC клиент:
В автоматизированных системах управления технологическими процессами (АСУ ТП) базы данных используются для обмена данными с программируемыми логическими контроллерами, хранения списков событий и тревог, а также исходных данных для построения исторических трендов. Среди существующих систем управления базами данных (СУБД) наиболее широкое распространение получили реляционные, поддерживающие формальный непроцедурный язык программирования SQL.
Язык SQL используется для создания структур баз данных, получения доступа к данным, изменения данных и подробно описан в стандарте ANSI. Однако разработчики широко используемых СУБД выполняют самостоятельное расширение языка программирования SQL, что обеспечивает поддержку нестандартных типов данных и дополнительных возможностей серверов, а также ухудшает совместимость и переход между продуктами разных производителей. В связи с этим для доступа к СУБД зачастую используются стандартизированные интерфейсы ODBC и OLE DB.
Open Database Connectivity (ODBC) представляет собой программный интерфейс, обеспечивающий доступ к различным СУБД при помощи специальных драйверов, предоставляемых разработчиками, которые реализуют правильное формирование запросов к базам данных.
Рассмотрим взаимодействие программного обеспечения с базой данных при помощи интерфейса ODBC. Перед тем как “Приложение” сможет получить доступ к источнику данных, необходимо создать имя источника данных “Data Source Name” (DSN). Эта операция выполняется с помощью “Администратора источника данных ODBC”, который является системной утилитой, поставляемой в составе операционных систем Microsoft Windows.
При создании DSN выбирается тип доступа к источнику данных: пользовательский (доступный текущему пользователю), системный (доступный всем пользователям) и файловый (настройки DSN сохраняются в отдельном файле). Выбирается драйвер, для которого выполняется создание источника данных, то есть с какой СУБД он будет связан. Настраиваются параметры драйвера. Задается имя источника данных DSN, представляющее собой уникальный текстовый идентификатор.
Доступ к источнику данных из “Приложения” осуществляется при помощи “Библиотеки доступа к ODBC”. Библиотека на запросы “Приложения” выполняет вызовы функций ODBC API, формируя тем самым SQL-команды для источника данных с соответствующим именем DSN. SQL-команды передаются “Диспетчеру драйверов ODBC”, который перенаправляет их соответствующему драйверу связанному с DSN. В ответ на вызов функции “Приложение” получает запрашиваемые данные или результат выполнения SQL-команды.
Таким образом, “Приложение” может работать с данными “Microsoft SQL Server” посредством DSN “СУБД 1”, с “Microsoft Access” посредством DSN “СУБД 2” и “MySQL” посредством DSN “СУБД 3”.
Object Linking and Embedding Dat abase (OLE DB) представляет собой набор интерфейсов, основанный на COM-технологии. Он должен был прийти на смену интерфейса ODBC, однако на сегодняшний день оба решения имеют большую распространённость. Главным отличием OLE DB от ODBC является добавление в первый поддержки СУБД, не использующих язык SQL, а так же добавление поддержки неструктурированных источников данных.
Рассмотрим взаимодействие программного обеспечения с базой данных посредством интерфейса OLE DB. Перед тем как потребитель данных “Приложение” сможет получить доступ к источнику данных, необходимо настроить свойства канала передачи. Эта операция выполняется непосредственно в “Приложении” при помощи инструментов предоставляемых COM-компонентом.
Во время настройки выбирается поставщик “provider”, который может выступать в качестве поставщика данных “OLE DB Data Provider” (предоставляет доступ к собственным данным) или поставщика служб “OLE DB Data Service” (предоставляет определенные услуги и не имеет собственных данных). Задаются параметры соединения с источником данных и права доступа к ним.
Доступ к источнику данных из “Приложения” осуществляется при помощи “Библиотеки доступа к OLE DB”. Библиотека на запросы “Приложения” создает COM-объекты, получает интерфейсы и вызывает их методы, формируя тем самым команды. Команды обрабатываются соответствующим провайдером, который запрашивает данные у источника, формирует записи, заполняет их полученными данными и возвращает приложению.
Таким образом, “Приложение” может работать с данными “Microsoft SQL Server” посредством “Поставщика 1”, с текстовыми файлами посредством “Поставщика 2”, с сообщениями электронной почты посредством “Поставщика 3” и источниками данных, которые поддерживают только интерфейс ODBC посредством “Поставщика N”.
SCADA система zenon позволяет использовать для связи с СУБД оба описанных интерфейса. Рассмотрим использование интерфейса OLE DB, который поддерживается модулем SQL Online, входящий в состав zenon Process Gateway.
Модуль SQL Online предназначен для односторонней передачи в СУБД актуальных значений переменных. Для его использования не требуется внесения изменений в проект, достаточно во время работы среды исполнения выполнить его настройку при помощи zenon Process Gateway. После чего в базе данных будут созданы две таблицы “ONLINE_VARIABLES” и “ONLINE_VALUES”.
В таблице “ONLINE_VARIABLES” хранится имя переменной и ее идентификатор.
№ | Столбец | Тип данных | Размер массива | Описание |
---|---|---|---|---|
1 | VARIABLE | int | 4 | Идентификатор переменной (ключ) |
2 | NAME | varchar | 128 | Имя переменной |
В таблицу “ONLINE_VALUES” сохраняются текущие значения переменных, выбранных при настройке zenon Process Gateway, штампы времени и слова состояния в формате SCADA системы zenon.
№ | Столбец | Тип данных | Размер массива | Описание |
---|---|---|---|---|
1 | VARIABLE | int | 4 | Идентификатор переменной (ключ) |
2 | VALUE | varchar | 64 | Текущее значение в виде строки |
3 | VALUE_NUM | float | 1 | Текущее значение в виде вещественного числа |
4 | TIMESTAMP | int | 4 | Временной штамп текущего значения в формате UNIX |
5 | TIMESTAMP2 | datetime | 1 | Временной штамп текущего значения в формате Дата/Время |
6 | STATUS | int | 4 | Слово состояния текущего значения |
Для того чтобы получить текущее значение переменной из СУБД, внешнее программное обеспечения должно вычитать из таблицы “ONLINE_VARIABLES” идентификатор переменной, после чего в соответствии с ним из таблицы “ONLINE_VALUES” должно быть считано текущее значение.
Рассмотрим использование модуля SQL Online на практике. Для этого в SCADA системе zenon создадим внутреннюю переменную “SQLPVariableOutput” целочисленного типа “INT”. Далее запустим среду исполнения и “zenon Startup Tool”.
Для запуска zenon Process Gateway необходимо в окне инструментов “Tools” выбрать пункт “Process Gateway” и задать в строку “Command line parameters” параметр “ /ini:<имя файла настроек>.ini” (перед параметром необходимо добавить пробел). В качестве имени файла настроек служит имя созданной переменной – “SQLPVariableOutput”. Если zenon Process Gateway ранее не запускался строку параметров можно оставить пустой.
После запуска zenon Process Gateway необходимо выбрать библиотеку “AccessSQL.dll”, соответствующую модулю SQL Online.
В появившемся окне конфигурации модуля выбирается СУБД, в которую должны сохраняться переменные, а так же сами переменные среды исполнения.
Окно свойств канала передачи данных соответствует стандартному окну интерфейса OLE DB. В качестве источника данных выберем поставщик ODBC драйвера “Microsoft OLE DB Provider for ODBC Drivers”.
Перед выполнением дальнейшей настройки канала передачи данных необходимо выполнить параметризацию ODBC драйвера. Для этого нужно создать имя источника данных DSN. Во время подготовки статьи в данном вопросе авторы столкнулись с рядом особенностей, связанных с использованием 64-разрядной операционной системы:
В связи с перечисленными особенностями было создано два имени источника данных DSN, первое – “SQLPVariableOutput_x64” для SCADA системы zenon в 64-х разрядной версии “Администратора источника данных ODBC”, второе – “SQLPVariableOutput_x86” для MATLAB в 32-х разрядной версии “Администратора источника данных ODBC”. Процесс создания первого описан ниже.
После запуска администратора источника данных ODBC нужно создать источник данных на основе драйвера “Microsoft Access Driver (*.mdb)”, задать его имя и создать файл базы данных. Далее аналогичным образом необходимо создать имя источника данных в 32-х разрядной версии администратора и выбрать созданный файл базы данных.
Созданный 64-х разрядный источник данных необходимо указать в настройках соединения OLE DB. По завершению настройки модуля SQL Online zenon Process Gateway автоматически создаст таблицы “ONLINE_VARIABLES” и “ONLINE_VALUES”, после чего текущие данные выбранных переменных SCADA системы zenon станут доступны диспетчеру драйверов ODBC.
Далее приведен пример программы на языке MATLAB, позволяющий получить значение переменной “SQLPVariableOutput”:
Отображение таблиц “OLINE_VARIABLES” и “ONLINE_VALUES” в программном обеспечении Microsoft Access до и после изменения значения переменной:
SCADA система zenon поддерживает как однонаправленный, так и двунаправленный доступ к значениям переменных через СУБД. Для реализации двунаправленного доступа используется драйвер “SQL Driver”. В отличие от модуля SQL Online, драйвер использует одну таблицу для получения данных через СУБД, а вторую таблицу для передачи данных. Ниже на рисунке приведен процесс обмена данными между SCADA системой zenon и программным обеспечением MATLAB.
СУБД содержит две таблицы: первая “ZRECEIVE” – для приема данных, вторая “ZSEND” – для передачи данных. В начальный момент текущее значение переменной “SQLVariableOutput” типа INT соответствует 13. В момент возникновения события изменения значения переменной (например, задание оператором значения 66 через числовой индикатор) новое значение передается драйверу, который в свою очередь помещает его в таблицу “ZSEND”.
Внешнее программное обеспечение MATLAB выполняет опрос таблицы “ZSEND”, в результате чего происходит вычитка из нее значения переменной 66. На этом цикл передачи значения переменной завершается. Однако следует подчеркнуть, что на данном этапе значение переменной “SQLVariableOutput” в SCADA системе zenon соответствует 13, а в MATLAB соответствует 66.
Во время работы “SQL Driver” выполняет циклический опрос таблицы “ZRECEIVE”. После того, как MATLAB поместит значение переменной 66 в таблицу, драйвер произведет считывание и удаление ее содержимого, а полученное значение будет присвоено переменной “SQLVariableOutput”. В случае если в таблице находится несколько значений одной и той же переменной, будет использовано значение с наибольшим идентификатором. На этом этапе значение переменной “SQLVariableOutput” в SCADA системе zenon становится равным 66, и цикл передачи значения переменной завершается.
Рассмотрим использование драйвера “SQL Driver” на практике. При добавлении драйвера через его настройки можно создавать имена источников данных DSN. Однако в связи с тем, что необходимо иметь источник данных для 32-х разрядного диспетчера драйверов ODBC “SQLVariableOutput_x86” и для 64-х разрядного “SQLVariableOutput_x64”, их удобнее добавить при помощи “Администратора источников данных ODBC”.
Во время настройки драйвера выбирается источник данных, задается таблица, из которой драйвер будет вычитывать данные “Receive table” и таблица, в которую драйвер будет записывать данные “Send table”.
Далее в драйвере создаются переменные СУБД, каждой из которых задается имя “Name” (“Benennung”), тип данных “Data type” (“Datentyp)” и уникальный числовой идентификатор “Memory number” (“Merker”), который позволяет драйверу организовать связь между переменными SCADA системы zenon и переменными СУБД.
Для создания переменных SCADA системы zenon на основе описания переменных СУБД, используется операция импорта “Import variable from driver…”. В окне импорта выбираются необходимые переменные, после чего среда разработки автоматически создаст переменные SCADA системы zenon соответствующего типа данных и выполнит настройку их адресации.
Чтобы SCADA система zenon могла работать с СУБД, в последней необходимо создать две таблицы с именами, заданными в настройках драйвера “ZRECEIVE” и “ZSEND”.
Таблица “ZRECEIVE” будет использоваться для получения данных из СУБД, а таблица “ZSEND” – для передачи данных в СУБД. Обе таблицы имеют одинаковую структуру.
№ | Столбец | Тип данных | Описание |
---|---|---|---|
1 | ID | Счетный | Счетчик с автоматическим приращением (ключ) |
2 | NAME | Текстовый | Имя переменной |
3 | DATUMZEIT | Дата/Время | Штамп времени DD.MM.YYYY HH:mm:ss |
4 | ZEIT_MS | Числовой | Миллисекунды штампа времени |
5 | WERT | Текстовый | Значение переменной |
6 | STATUS | Числовой | Слово состояния (64-бита) |
В случае использования в настройках драйвера функции резервирования “Redundancy”, таблица “ZRECEIVE” должна быть расширена:
№ | Столбец | Тип данных | Описание |
---|---|---|---|
1 | ACK_SRV | Числовой | 1 – сервер прочитал данные |
2 | ACK_SB | Числовой | 1 – standby сервер прочитал данные |
3 | INSERZEIT | Дата/Время | Время добавления строки (вычисляется функцией Now) |
Далее приведен пример программы на языке MATLAB, позволяющий получить значение переменной “SQLVariableOutput”:
Далее на рисунке приведена последовательность изменений значений переменных в таблицах “ZRECEIVE” и “ZSEND”, выполняющаяся во время работы программы:
На основании рассмотренных решений можно сделать следующие выводы:
Бойко Олег Александрович, Национальный горный университет, кафедра Автоматизации и компьютерных систем, ассистент
Голинько Александр Анатольевич, компания СВ АЛЬТЕРА, инженер по автоматизации
Проценко Станислав Николаевич, Национальный горный университет, кафедра Автоматизации и компьютерных систем, доцент