Мараев И.Е.
ЗАПРОСНО-ОТВЕТНЫЙ ПРОТОКОЛ ОБМЕНА ДАННЫМИ ДЛЯ СИСТЕМ АВТОМАТИЗАЦИИ *
Аннотация:
в работе разработан запрос-ответный протокол обмена данными, позволяющий производить обмен информацией между ПК (клиентом) и модулем сбора и передачи данных на базе микроконтроллера (сервером)
Ключевые слова:
протокол обмена данными, модуль сбора и передачи данных, последовательный интерфейс
УДК 004.031.2
Мараев И.Е.
студент бакалавриата
Национальный исследовательский ядерный университет «МИФИ»
(г. Москва, Россия)
ЗАПРОСНО-ОТВЕТНЫЙ ПРОТОКОЛ
ОБМЕНА ДАННЫМИ ДЛЯ СИСТЕМ АВТОМАТИЗАЦИИ
Аннотация: в работе разработан запрос-ответный протокол обмена данными, позволяющий производить обмен информацией между ПК (клиентом) и модулем сбора и передачи данных на базе микроконтроллера (сервером).
Ключевые слова: протокол обмена данными, модуль сбора и передачи данных, последовательный интерфейс.
Сегодня в условиях быстро развивающихся технологий и повсеместного использования средств автоматизации, создание эффективных модулей сбора и передачи данных является актуальной задачей во многих областях человеческой деятельности. Модули сбора и передачи данных используются в многих отраслях, от промышленности до медицины и научных исследований. Эти системы позволяют собирать данные с различных устройств, преобразовывать их и передавать их на другие устройства. Стоит отметить, что задача получения и обработки данных в таких ответственных и экстремальных ситуациях является нетривиальной и требует высокой надёжности от системы. И поэтому решение на базе микроконтроллеров, обладающих высокой производительностью и малым энергопотреблением, при своих малых размерах, очевидно, становится наиболее актуальным.
В работе разработан запрос-ответный протокол передачи данных, позволяющий производить обмен информацией между ПК (клиентом) и модулем сбора и передачи данных на базе микроконтроллера (сервером).
Разрабатываемый протокол является запросно-ответным, то есть полудуплексным. Но возможна работа в потоковом варианте в полнодуплексном режиме. Для этого в приборе реализованы циклические входной буфер и обычный выходной.
Физическим уровнем протокола является интерфейс RS-232C/RS-485 (также планируется Ethernet). Сам протокол обеспечивает простейшую адресацию для создания элементарной сети. Через Ethernet пакет протокола будет передаваться в поле данных фрейма UDP.
Рисунок 1. Схема применения протокола на различных интерфейсах
(пунктир – планируемый к разработке функционал).
Инициатором обмена данными между прибором (сервером) и клиентом (ПК, КПК и т.п.) всегда является клиент. Обмен данными происходит посредством сообщений (пакетов). Клиент посылает пакет-запрос, прибор отвечает либо пакетом-ответом, либо сообщением об ошибке. Если прибор не прислал ответ клиенту в течении 3-х секунд, то клиент начинает обрабатывать ситуацию тайм-аута (прибор не отвечает).
Пакеты имеют переменную длину, но не могут быть меньше 12 байт (статический заголовок пакета должен быть всегда). Исходящий от клиента - не может превышать 1 Кбайт. Исходящие от прибора – не более 1.4 Кбайт (стандартного размера фрейма стека TCP/IP). Но в целом размеры пакетов определяются памятью, выделенной под буферы. Однако при работе в потоковом варианте возможен сбой в работе буфера и при меньших размерах входящих пакетов, если прибор не успевает обрабатывать входящие сообщения. В полудуплексном варианте работы – такой сбой исключен.
Также, пакет должен содержать четное число байт. Это необходимо для будущей совместимости с интерфейсом Ethernet и поддержкой протоколов, входящих в TCP/IP стек.
Пакеты разделяются между собой таймаутами на шине, равными примерно времени передачи 10-12 байт на текущей скорости. В случае, если превышена максимальная длина пакета или произошел сбой буфера приема, то прибор ожидает окончание пакета (таймаут в 10-12 байт), после чего обрабатывают возникшую ошибку.
В случае передачи пакета по UDP, разделение пакетов происходит разделением по фреймам UDP. Один пакет целиком укладывается в один фрейм UDP.
Все контрольные суммы имеют размер 2 байта и рассчитываются согласно общепринятому стандарту (см. 5.5.3 Практическая реализация CRC).
Обмен происходит с помощью пакетов. Все пакеты (как запросные, так и ответные) имеют одинаковые поля. Пакет имеет вид:
Рисунок 2. Структура пакета данных.
Первые 7 полей образуют статический заголовок размером 12 байт. Этот заголовок является обязательным элементом и в случае его повреждения прибор не будет отсылать ответный пакет, во всех остальных случаях ответ/подтверждение о приеме - обязателен.
Последние 2 поля образуют поле для передачи данных – это необязательный элемент, размер которого может быть переменным.
1) Frame Type (1 byte).
Тип пакета (1 байт) - определяет направление пакета. Сообщения, отсылаемые клиентом, маркируются как 0x7B. От прибора к клиенту – 0x7A. В случае, если приборы образуют элементарную сеть, то исходящий от клиента пакет принимается всеми приборами, но отвечает клиенту только тот прибор, чей адрес был указан в этом пакете. Остальные приборы принимают пакет без каких-либо действий. При исходящем пакете от прибора (в случае элементарной сети), этот пакет также полностью принимают как клиент, так и другие приборы, но они также игнорируют данный пакет.
2) Addr Device (1 byte).
Адрес прибора (1 байт) - соответствует адресу прибора, который абсолютно необходим при работе в элементарных сетях. По умолчанию 0x05.
3) Command (2 byte).
Код команды (2 байта). Прибор, отвечая на команду с кодом “X”, отсылая ответный пакет помещает в это поле ответный код команды “X+0x8000” – если команда обработана верно, либо указывает в этом поле код ошибки. Соответственно общее пространство кодов команд имеет следующие разделы:
0x0000…0x7EFF – команды от сервера к прибору;
0x8000…0xFEFF – ответные команды прибора;
0xFF00…0xFFFF – коды ошибок.
4) Length of data (2 byte).
Длина поля данных (2 байта) - содержит общую длину (в байтах) поля передачи данных (+2 байта контрольной суммы поля данных – поле 9). В случае, если данные передаваться вместе с этим пакетом не будут, данное поле должно быть равно 0.
5) Packet ID (2 byte).
Уникальный ID данного пакета. В случае передачи, например, по UDP, где не гарантируется последовательный прием пакетов по времени, с помощью данного поля осуществляется контроль потоковой передачи данных.
6) NULL (2 byte).
Поле зарезервировано.
7) CRC (header) (2 byte).
Контрольная сумма статического заголовка. Рассчитывается как CRC в TCP/IP стеке по стандарту RFC1071.
8) Data (N word).
Поле данных произвольной длины. Должно содержать четное количество байт.
9) CRC (data) (2 byte).
Контрольная сумма поля данных. Рассчитывается как CRC в TCP/IP стеке по RFC1071.
Разработанный протокол позволяет передавать структуры данных размером до 1.4 Кбайт, а также имеет проверку целостности передачи данных, идентификацию пакетов и адресацию. Типовое применение протокола – системы автоматизации измерений.
СПИСОК ЛИТЕРАТУРЫ:
Номер журнала Вестник науки №7 (64) том 4
Ссылка для цитирования:
Мараев И.Е. ЗАПРОСНО-ОТВЕТНЫЙ ПРОТОКОЛ ОБМЕНА ДАННЫМИ ДЛЯ СИСТЕМ АВТОМАТИЗАЦИИ // Вестник науки №7 (64) том 4. С. 244 - 249. 2023 г. ISSN 2712-8849 // Электронный ресурс: https://www.вестник-науки.рф/article/9595 (дата обращения: 17.05.2024 г.)
Вестник науки СМИ ЭЛ № ФС 77 - 84401 © 2023. 16+