2 Краткое описание контроллера мик-51 (стр. 3 из 5)
В шестой версии SCADA TRACE MODE технологии горячего резервирования поднялись на новую высоту. Теперь в проекте SCADA можно автоматически создавать не только дублированные (Double Force), но и троированные (Tri Force) узлы.
Особое внимание в SCADA TRACE MODE 6 уделено возможностям интеграции с базами данных и другими приложениями. Поэтому в эту SCADA встроена поддержка наиболее популярных программных интерфейсов: ODBC, OPC, DDE. Для облегчения настройки взаимодействия с внешними базами данных в интегрированную среду разработки TRACE MODE встроен редактор SQL-запросов. Кроме того, существует возможность подключения компонентов ActiveX, что свидетельствует о высокой степени открытости SCADA-системы TRACE MODE 6.
Подробнее на сайте производителя: www.adastra.ru
4 Краткое изложение принципов сопряжения контроллеров и SCADA систем
SCADA система является центром сбора, обработки и визуализации информации. Но непосредственное управление технологическими процессами производится Промышленными Контроллерами. Для правильной работы системы необходим обмен данными между SCADA и Контроллерами. Эту задачу выполняют промышленные сети и шины.
В общем случае производители контроллеров выпускают драйверы для работы их контроллеров с теми или иными шинами обмена данными. Если же механизмов работы с нужной шиной не предусмотрено можно использовать OPC.
OPC пока является наиболее эффективным средством сопряжения разнообразных контроллеров и SCADA-систем, отвечая за стандартные механизмы доступа приложений к данным технологических процессов по промышленным шинам DeviceNet, Fieldbus, Interbus, Profibus, VME/VXI и ряда других.
Данный текст содержит описание механизма объединения промышленного контроллера МИК-51 со SCADA системой Trace Mode 6 с помощью шины Modbus и OPC сервера.
5 Краткое описание шины Modbus
Modbus — коммуникационный протокол, основанный на клиент-серверной архитектуре. Разработан фирмой Modicon для использования в контроллерах с программируемой логикой (PLC). Стал стандартом де-факто в промышленности и широко применяется для организации связи промышленного электронного оборудования. Использует для передачи данных последовательные линии связи RS-485, RS-422, RS-232, а также сети TCP/IP. В настоящее время поддерживается некоммерческой организацией Modbus-IDA.
Контроллеры соединяются используя технологию главный-подчиненный, при которой только одно устройство (главный) может инициировать передачу (сделать запрос). Другие устройства (подчиненные) передают запрашиваемые главным устройством данные, или производят запрашиваемые действия. Типичное главное устройство включает в себя ведущий (HOST) процессор и панели программирования. Типичное подчиненное устройство - программируемый контроллер.
Главный может адресоваться к индивидуальному подчиненному или может инициировать широкую передачу сообщения на все подчиненные устройства. Подчиненное устройство возвращает сообщение в ответ на запрос, адресуемый именно ему. Ответы не возвращаются при широковещательном запросе от главного.
Протокол Modbus описывает единый простой формат передачи данных PDU, который в свою очередь входит в полный пакет ADU. Формат ADU меняется в зависимости от типа линии связи. Существуют три режима протокола: Modbus RTU, Modbus ASCII, Modbus TCP. Первые два используют последовательные линии связи (в основном RS-485, реже RS-422/RS-232), последний использует для передачи данных по сетям TCP/IP.
Протокол Modbus RTU предполагает одно ведущее (запрашивающее) устройство в линии (master), которое может передавать команды одному или нескольким ведомым устройствам (slave), обращаясь к ним по уникальному в линии адресу. Синтаксис команд протокола позволяет адресовать 247 устройств на одной линии связи стандарта RS-485 (реже RS-422 или RS-232).
Инициатива проведения обмена всегда исходит от ведущего устройства. Ведомые устройства прослушивают линию связи. Мастер подаёт запрос (посылка, последовательность байт) в линию и переходит в состояние прослушивания линии связи. Ведомое устройство отвечает на запрос, пришедший в его адрес. Окончание ответной посылки мастер определяет, по временному интервалу между окончанием приёма предыдущего байта и началом приёма следующего. Если этот интервал превысил время, необходимое для приёма двух байт на заданной скорости передачи, приём кадра ответа считается завершённым. Кадры запроса и ответа по протоколу modbus имеют фиксированный формат, приведённый в (Таблица 1-1).
| Адрес ведомого устройства | Номер функции | Данные | CRC |
| 1 байт | 1 байт | N < 253 (байт) | 2 байта |
Таблица 1-1. Кадр посылки Modbus RTU
где:
• адрес ведомого устройства — первое однобайтное поле кадра. Оно содержит адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 254. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство;
• номер функции — это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство;
• данные — поле содержит информацию, необходимую ведомому устройству для выполнения заданной мастером функции или содержит данные, передаваемые ведомым устройством в ответ на запрос ведущего. Длина и формат поля зависит от номера функции;
• CRC — (контрольная сумма) заключительное двухбайтное поле кадра. Контрольная сумма завершает кадры запроса и ответа и применяется для проверки отсутствия ошибок в кадре посылки Modbus RTU.
Следует отметить, что поле CRC записывается младшим байтом вперёд. Алгоритм расчёта CRC может отличаться для разных устройств.
Адресация данных в протоколе Modbus RTU
Все операции с данными привязаны к нулю, каждый вид данных (регистр, выходное/входное значение) начинаются с адреса 0000.
Адресация к ячейке начинается с 1.
Например: Флаг номер 1 программируемого контроллера имеет адрес 0000 (указывается в поле "Адрес").
Флаг номер 127 (DEC) имеет адрес 0x007E hex (126 dec) (указывается в поле "Адрес").
Запоминающий регистр 40001 будет иметь адрес 0000 в поле "Адрес" команды. Потому что код операции уже содержит в себе необходимую информацию об адресе. Операции с этими регистрами имеют смещение Адрес_регистра - 40000 = Значение Используемое В Поле "Адрес". Тип адресации команд в дальнейшем будем помечать т.о.
| смещение | обозначение |
| -40000 | 4x |
| -10000 | 1x |
Запоминающий регистр 40108 будет иметь адрес 006B hex (107 dec)
Контроль ошибок в протоколе Modbus RTU
Во время обмена данными могут возникать ошибки двух типов:
• ошибки, связанные с искажениями при передаче данных;
• логические ошибки.
Ошибки первого типа обнаруживаются при помощи фреймов символов, контроля чётности и циклической контрольной суммы CRC-16-IBM (используется число-полином = 0xA001).
RTU фрейм
В RTU режиме сообщение начинается с интервала тишины равного времени передачи 3.5 символов при данной скорости передачи в сети. Первым полем затем передается адрес устройства.
Вслед за последним передаваемым символом также следует интервал тишины продолжительностью не менее 3.5 символов. Новое сообщение может начинаться после этого интервала.
Фрейм сообщения передается непрерывно. Если интервал тишины продолжительностью 1.5 возник во время передачи фрейма, принимающее устройство заканчивает прием сообщения и следующий байт будет воспринят как начало следующего сообщения.
Таким образом, если новое сообщение начнется раньше 3.5 интервала, принимающее устройство воспримет его как продолжение предыдущего сообщения. В этом случае устанавливается ошибка, так как будет несовпадение контрольных сумм.
Подробнее на сайте некоммерческой организации поддерживающей протокол шины Modbus: www.modbus.org
Технология связывания и внедрения объектов для систем промышленной автоматизации OPC (OLE for Process Control) предназначена для обеспечения универсального механизма обмена данными между датчиками, исполнительными механизмами, контроллерами, устройствами связи с объектом и системами представления технологической информации, оперативного диспетчерского управления, а также системами управления базами данных.
Производители аппаратных средств, пользуясь спецификацией OPC, имеют возможность разрабатывать единственный сервер OPC для обеспечения единственного и наиболее общего способа организации доступа к данным и передачи в адрес приложений-клиентов различных производителей программного обеспечения для промышленной автоматизации.
Структура взаимодействия между приложениями-клиентами и серверами OPC различных производителей показана ниже.
Опираясь на объектную технологию COM/DCOM, стандарт OPC фиксирует определенную модель взаимодействия между клиентом и сервером.
Базовым понятием этой модели является элемент данных (Item). Каждый элемент данных имеет значение, время последнего обновления (timestamp) и признак качества, определяющий степень достоверности значения. Значение может быть практически любого скалярного типа булево, целое, с плавающей точкой и т.п. или строкой (так называемый OLE VARIANT). Время представляется с 100-наносекундной точностью (FILETIME Win32 API). Реальная точность измерения времени обычно бывает хуже и, в общем случая, зависит от реализации сервера и аппаратуры. Качество это код, содержащий в себе грубую оценку UNCERTAIN, GOOD и BAD (неопределено, хорошее и плохое), а на случай плохой еще и расшифровку, например QUAL_SENSOR_FAILURE ошибка датчика.