Интерфейс modbus
 Скачать 44.48 Kb.
|
|
МИНИСТЕРСВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ ФГБОУ ВО «ЮГОРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» Институт нефти и газа РЕФЕРАТ по дисциплине «Автоматизация технологических процессов нефтедобычи» ТЕМА: «Интерфейс MODBUS» Выполнил: обучающийся группы: 2н92в ФИО Копылова Алена Валерьевна Проверил: Усманов Р. Ханты-Мансийск 2022г. Содержание…………………………………………………………………………………1 Введение…………………………………………………………………………………….2 1. История……………………………………………………………………………………3 2. Стандарт MODBUS………………………………………………………………………5 2.1. Специфическая терминология…………………………………………………………5 2.2. Состав стандарта………………………………………………………………………..6 2.3. Достоинства стандарта…………………………………………………………………7 2.4. Недостатки стандарта…………………………………………………………………..7 3. Контроллеры………………………………………………………………………………8 4. Категории кодов функций………………………………………………………………11 5. Модель данных…………………………………………………………………………..12 6. Стандартные функции протокола Modbus……………………………………………..13 6.1. Чтение данных………………………………………………………………………….14 6.2. Запись одного значения…………………………………………………………………15 6.3. Запись нескольких значений……………………………………………………………15 7. Контроль ошибок в протоколе Modbus RTU……………………………………………17 7.1. RTU фрейм……………………………………………………………………………….17 7.2. Логические ошибки………………………………………………………………………18 7.2.1. Стандартные коды ошибок……………………………………………………………..19 Заключение …………………………………………………………………………………….20 Литература …………………………………………………………………………………..…21 Введение Modbus — открытый коммуникационный протокол, основанный на архитектуре «клиент-сервер». Широко применяется в промышленности для организации связи между электронными устройствами. Может использовать для передачи данных через последовательные линии связи RS-485, RS-422, RS-232, а также сети TCP/IP (Modbus TCP). Не следует путать MODBUS и MODBUS Plus. MODBUS Plus - проприетарный протокол, принадлежащий Schneider Electric. Физический уровень уникальный, похож на Ethernet 10BASE-T, полудуплекс по одной витой паре, скорость 1Мбит/с. Транспортный протокол - HDLC, поверх которого специфицировано расширение для передачи MODBUS PDU. 1. История Modbus является одним из самых распространенных промышленных протоколов. Согласно отчету HMS Industrial Networks за 2020 год он занимает 10% рынка (5% приходится на Modbus RTU и 5% – на Modbus TCP). При этом Modbus является одним из первых (а, возможно, и самым первым) промышленных протоколов – он был представлен в 1979 году разработчиками ПЛК линейки Modicon (с которой в конце 1960-х началось зарождение рынка ПЛК) – и, собственно, название протокола означает «Modicon Bus». Позже бренд Modicon был перепродан компании Schneider Electric, которая владеет им и в настоящее время. Вместе с брендом Schneider Electric долгое время владела правами на протокол Modbus, но в 2004 передала их некоммерческой организации Modbus IDA. Таким образом, в настоящий момент за протоколом не стоит «основной» вендор, который занимается его контролем и развитием (например, для EtherCAT таким вендором является Beckhoff, для Profibus/Profinet – Siemens, для CC-Link – Mitsubishi Electric и т.д.). В принципе, это является редкостью – из других известных протоколов, не связанных с конкретными вендорами, можно вспомнить разве что CANopen и EtherNet/IP (из современных – еще OPC UA и MQTT). За счет этого Modbus стал одним из популярных способов интеграции устройств различных производителей – например, для ПЛК Siemens основным протоколом может быть PROFINET, а для Mitsubishi Electric – CC-Link, при этом каждый ПЛК не поддерживает протокол «конкурента», но они оба поддерживают Modbus TCP, что позволяет настроить между ними обмен данными. На момент создания протокола – в качестве физического уровня использовался интерфейс RS-232, но в настоящий момент в основном используется RS-485 (для Modbus RTU/ASCII) и TCP/IP (для Modbus TCP). 2. Стандарт MODBUS В настоящее время развитием Modbus занимается некоммерческая организация Modbus-IDA. 2.1. Специфическая терминология PDU (Protocol Data Unit) - общая для всех физических уровней часть пакета MODBUS. Включает в себя код функции и данные пакета. ADU (Application Data Unit) - полный пакет MODBUS. Включает в себя специфичную для физического уровня часть пакета и PDU. MODBUS специфицирует 4 типа данных: Discrete Inputs - однобитовый тип, доступен только на чтение. Coils - однобитовый тип, доступен на чтение и на запись. Input Registers - 16-битовый беззнаковый тип, доступен только на чтение. Holding Registers - 16-битовый беззнаковый тип, доступен на чтение и на запись. 2.2. Состав стандарта Стандарты MODBUS состоят из 3 частей: Документ Modbus Application Protocol содержит спецификацию прикладного уровня сетевой модели OSI: Элементарный пакет протокола, так называемый PDU (Protocol Data Unit), он един для всех физических уровней. PDU упаковывается в индивидуальный для каждого транспорта application data unit (ADU). Коды функций и состав PDU для каждого кода. Документ Modbus over serial line содержит спецификацию канального и физического уровней сетевой модели OSI для физических уровней RS485 и RS232. В принципе может использоваться любой физический уровень, основанный на асинхронном приемопередатчике. Документ MODBUS Messaging on TCP/IP Implementation Guide содержит спецификацию ADU для транспорта через TCP/IP стек. 2.3. Достоинства стандарта Основные достоинства стандарта - открытость и массовость. Огромное количество датчиков и исполнительных устройств выпущено промышленностью. Практически все промышленные системы контроля и управления имеют программные драйвера для работы с MODBUS сетями. 2.4. Недостатки стандарта Стандарт в своей основе был написан очень давно и многие актуальные для современных промышленных сетей вопросы не были учтены. Стандарт специфицирует метод передачи только двух типов данных. Отсутствие четкого указания в стандарте привело к тому, что с другими типами данных сторонние производители МОДБАС-решений поступали по своему усмотрению. Разброд де-факто в этом вопросе не позволил впоследствии сделать уточнения в официальном документе: это вызвало бы всплеск недовольства производителей и возможную войну форматов. Стандарт не позволяет никакой оперативной сигнализации от конечного устройства к мастеру в случае необходимости (прерывания). Нужно ждать своей очереди в опросе. Это существенно ограничивает применимость МОДБАС-решений в системах управления реального времени. Стандарт не позволяет конечным устройствам обмениваться фиксированными данными друг с другом без участия мастера. Это существенно ограничивает применимость МОДБАС- решений в системах регулирования реального времени. 3. Контроллеры Контроллеры на шине Modbus взаимодействуют, используя клиент-серверную модель, основанную на транзакциях, состоящих из запроса и ответа. Обычно в сети есть только один клиент, так называемое, «главное» (англ. master) устройство, и несколько серверов — «подчиненных» (slaves) устройств. Главное устройство инициирует транзакции (передаёт запросы). Главный может адресоваться индивидуально к подчиненному или инициировать передачу широковещательного сообщения для всех подчиненных устройств. Подчиненное устройство отвечает на запрос, адресованный именно ему. При получении широковещательного запроса ответ не формируется. Спецификация Modbus описывает структуру запросов и ответов. Их основа — элементарный пакет протокола, так называемый PDU (Protocol Data Unit). Структура PDU не зависит от типа линии связи и включает в себя код функции и поле данных. Код функции кодируется однобайтовым полем и может принимать значения в диапазоне 1…127. Диапазон значений 128…255 зарезервирован для кодов ошибок. Поле данных может быть переменной длины. Размер пакета PDU ограничен 253 байтами.
Для передачи пакета по физическим линиям связи PDU помещается в другой пакет, содержащий дополнительные поля. Этот пакет носит название ADU (Application Data Unit). Формат ADU зависит от типа линии связи. Существуют три основных реализации протокола Modbus, две для передачи данных по последовательным линиям связи, как медным EIA/TIA-232-E (RS-232), EIA-422, EIA/TIA-485-A (RS-485), так и оптическим и радио: Modbus ASCII — для обмена используются только ASCII символы. Для проверки целостности используется алгоритм en:Longitudinal redundancy check. Сообщение разделяется на столбцы с помощью символа «:» и заканчивается символами новой строки CR/LF. Modbus RTU и для передачи данных по сетям Ethernet поверх TCP/IP: Modbus TCP. Общая структура ADU следующая (в зависимости от реализации, некоторые из полей могут отсутствовать):
где адрес ведомого устройства — адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248…255 — зарезервированы; номер функции — это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство; данные — поле содержит информацию, необходимую ведомому устройству для выполнения заданной мастером функции или содержит данные, передаваемые ведомым устройством в ответ на запрос ведущего. Длина и формат поля зависит от номера функции; блок обнаружения ошибок — контрольная сумма для проверки отсутствия ошибок в кадре. Максимальный размер ADU для последовательных сетей RS232/RS485 — 256 байт, для сетей TCP — 260 байт. Для Modbus TCP ADU выглядит следующим образом:
где ид транзакции — два байта, обычно нули ид протокола — два байта, нули длина пакета — два байта, старший затем младший, длина следующей за этим полем части пакета адрес ведомого устройства — адрес подчинённого устройства, к которому адресован запрос. Обычно игнорируется, если соединение установлено с конкретным устройством. Может использоваться, если соединение установлено с бриджем, который выводит нас, например, в сеть RS485. Поле контрольной суммы в Modbus TCP отсутствует. 4. Категории кодов функций В действующей в настоящее время спецификации протокола определяются три категории кодов функций: Стандартные команды Их описание должно быть опубликовано и утверждено Modbus-IDA. Эта категория включает в себя как уже определенные, так и свободные в настоящее время коды. Пользовательские команды Два диапазона кодов (от 65 до 72 и от 100 до 110), для которых пользователь может реализовать произвольную функцию. При этом не гарантируется, что какое-то другое устройство не будет использовать тот же самый код для выполнения другой функции. Зарезервированные В эту категорию входят коды функций, не являющиеся стандартными, но уже используемые в устройствах, производимых различными компаниями. Это коды 9, 10, 13, 14, 41, 42, 90, 91, 125, 126 и 127. 5. Модель данных Одно из типичных применений протокола — чтение и запись данных в регистры контроллеров. Спецификация протокола определяет четыре таблицы данных:
Доступ к элементам в каждой таблице осуществляется с помощью 16-битного адреса, первой ячейке соответствует адрес 0. Таким образом, каждая таблица может содержать до 65536 элементов. Спецификация не определяет, что физически должны представлять собой элементы таблиц и по каким внутренним адресам устройства они должны быть доступны. Например, допустимо организовать перекрывающиеся таблицы, В этом случае команды, работающие с дискретными данными и с 16-битными регистрами будут фактически обращаться к одним и тем же данным. Следует отметить, что со способом адресации данных связана определённая путаница. Modbus был первоначально разработан для контроллеров Modicon. В этих контроллерах для каждой из таблиц использовалась специальная нумерация. Например, первому регистру ввода соответствовал номер ячейки 30001, а первому регистру хранения — 40001. Таким образом, регистру хранения с адресом 107 в команде Modbus соответствовал регистр № 40108 контроллера. Хотя такое соответствие адресов больше не является частью стандарта, некоторые программные пакеты могут автоматически «корректировать» вводимые пользователем адреса, например, вычитая 40001 из адреса регистра хранения. 6. Стандартные функции протокола Modbus
A1 и A0 — адрес элемента, Q1 и Q0 — количество элементов, N — количество байт данных D — данные 6.1. Чтение данных Для чтения значений из перечисленных выше таблиц данных используются функции с кодами 1—4 (шестнадцатеричные значения 0x01—0x04): 1 (0x01) — чтение значений из нескольких регистров флагов (Read Coil Status) 2 (0x02) — чтение значений из нескольких дискретных входов (Read Discrete Inputs) 4 (0x04) — чтение значений из нескольких регистров хранения (Read Holding Registers) 3 (0x03) — чтение значений из нескольких регистров ввода (Read Input Registers) Запрос состоит из адреса первого элемента таблицы, значение которого требуется прочитать, и количества считываемых элементов. Адрес и количество данных задаются 16-битными числами, старший байт каждого из них передается первым. В ответе передаются запрошенные данные. Количество байт данных зависит от количества запрошенных элементов. Перед данными передается один байт, значение которого равно количеству байт данных. Значения регистров хранения и регистров ввода передаются начиная с указанного адреса, по два байта на регистр, старший байт каждого регистра передаётся первым:
Значения флагов и дискретных входов передаются в упакованном виде: по одному биту на флаг. Единица означает включённое состояние, ноль — выключенное. Значения запрошенных флагов заполняют сначала первый байт, начиная с младшего бита, затем следующие байты, также от младшего бита к старшим. Младший бит первого байта данных содержит значение флага, указанного в поле «адрес». Если запрошено количество флагов, не кратное восьми, то значения лишних битов заполняются нулями:
6.2. Запись одного значения 5 (0x05) — запись значения одного флага (Force Single Coil) 6 (0x06) — запись значения в один регистр хранения (Preset Single Register) Команда состоит из адреса элемента (2 байта) и устанавливаемого значения (2 байта). Для регистра хранения значение является просто 16-битным словом. Для флагов значение 0xFF00 означает включённое состояние, 0x0000 — выключенное, другие значения недопустимы. Если команда выполнена успешно, ведомое устройство возвращает копию запроса. 6.3. Запись нескольких значений 15 (0x0F) — запись значений в несколько регистров флагов (Force Multiple Coils) 16 (0x10) — запись значений в несколько регистров хранения (Preset Multiple Registers) Команда состоит из адреса элемента, количества изменяемых элементов, количества передаваемых байт устанавливаемых значений и самих устанавливаемых значений. Данные упаковываются так же, как в командах чтения данных. Ответ состоит из начального адреса и количества изменённых элементов. Ниже приведён пример команды ведущего устройства и ответа ведомого (для Modbus RTU).
7. Контроль ошибок в протоколе Modbus RTU Во время обмена данными могут возникать ошибки двух типов: ошибки, связанные с искажениями при передаче данных; логические ошибки. Ошибки первого типа обнаруживаются при помощи фреймов символов, контроля чётности и циклической контрольной суммы CRC-16-IBM (используется число-полином = 0xA001). При этом младший байт передается первым, в отличие от байтов адреса и значения регистра в PDU 7.1. RTU фрейм В RTU режиме сообщение должно начинаться и заканчиваться интервалом тишины — временем передачи не менее 3,5 символов при данной скорости в сети. Первым полем затем передаётся адрес устройства. Вслед за последним передаваемым символом также следует интервал тишины продолжительностью не менее 3,5 символов. Новое сообщение может начинаться после этого интервала. Фрейм сообщения передаётся непрерывно. Если интервал тишины продолжительностью 1,5 возник во время передачи фрейма, принимающее устройство должно игнорировать этот фрейм как неполный. Таким образом, новое сообщение должно начинаться не раньше 3,5 интервала, так как в этом случае устанавливается ошибка. Немного об интервалах (речь идёт о Serial Modbus RTU): при скорости 9600 и 11 битах в кадре (стартовый бит + 8 бит данных + бит контроля чётности + стоп-бит): 3.5 * 11 / 9600 = 0,00401041(6), то есть более 4 мс; 1.5 * 11 / 9600 = 0,00171875, то есть более 1 мс. Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс соответственно. 7.2. Логические ошибки Для сообщений об ошибках второго типа протокол Modbus RTU предусматривает, что устройства могут отсылать ответы, свидетельствующие об ошибочной ситуации. Признаком того, что ответ содержит сообщение об ошибке, является установленный старший бит кода команды. Пример кадра при выявлении ошибки ведомым устройством, в ответ на запрос приведён в (Таблица 2-1). 1. Если Slave принимает корректный запрос и может его нормально обработать, то возвращает нормальный ответ. 2. Если Slave не принимает какого-либо значения, никакого ответа не отправляется. Master диагностирует ошибку по тайм-ауту. 3. Если Slave принимает запрос, но обнаруживает ошибку (parity, LRC, or CRC), никакого ответа не отправляется. Master диагностирует ошибку по тайм-ауту. 4. Если Slave принимает запрос, но не может его обработать (обращение к несуществующему регистру и т. д.), отправляется ответ, содержащий в себе данные об ошибке.
7.2.1. Стандартные коды ошибок 01 — Принятый код функции не может быть обработан на подчиненном. 02 — Адрес данных, указанный в запросе, не доступен данному подчиненному. 03 — Величина, содержащаяся в поле данных запроса, является недопустимой величиной для подчиненного. 04 — Невосстанавливаемая ошибка имела место, пока подчиненный пытался выполнить затребованное действие. 05 — Подчиненный принял запрос и обрабатывает его, но это требует много времени. Этот ответ предохраняет главного от генерации ошибки тайм-аута. 06 — Подчиненный занят обработкой команды. Главный должен повторить сообщение позже, когда подчиненный освободится. 07 — Подчиненный не может выполнить программную функцию, принятую в запросе. Этот код возвращается для неудачного программного запроса, использующего функции с номерами 13 или 14. Главный должен запросить диагностическую информацию или информацию об ошибках с подчиненного. 08 — Подчиненный пытается читать расширенную память, но обнаружил ошибку паритета. Главный может повторить запрос, но обычно в таких случаях требуется ремонт. Заключение Несмотря на свой возраст, Modbus активно используется и с современными технологиями — например, он отлично чувствует себя в облаке. Многие провайдеры предлагают возможность создания облачных IoT-платформ — для снижения затрат на разработку IoT-сервисов, обеспечения сбора данных и управления устройствами в real-time-режиме. И поддержка Modbus — обязательный пункт для подобных решений, так как невозможно построить межмашинное взаимодействие без протокола, реализованного множеством поставщиков на тысячах различных устройств. Такая сочетаемость с современными трендами лишний раз показывает, что за прошедшие годы Modbus не только не утратил своей популярности, но и до сих пор остается одним из самых востребованных протоколов в промышленной производственной среде. Литература https://mcsjournal.ru/blog/modbus-dlya-m2m-vzaimodejstviya; Промышленный Ethernet в системах промышленной автоматизации, АСУ ТП (bookasutp.ru). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||