CC BY
8УДК 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).
Обмен происходит с помощью пакетов. Все пакеты (как запросные, так и ответные) имеют одинаковые поля. Пакет имеет вид:
1 ■1 3 4 5 6 7 S 9
Frans Addr Command Length Packet mill CRC Data CRC :
type Dsviis of diti Ш hsidsr diti ;
Static Header
Data
Рисунок 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 Кбайт, а также имеет проверку целостности передачи данных, идентификацию пакетов и адресацию. Типовое применение протокола - системы автоматизации измерений.
СПИСОК ЛИТЕРАТУРЫ:
1. ГОСТ 7.32-2017 Система стандартов по информации, библиотечному и издательскому делу
2. Гук М., Интерфейсы ПК // Гук М. - СПб: ЗАО «Издательство «Питер», 1999
3. Магда Ю., Программирование и отладка C/C++ приложений для микроконтроллеров ARM // Магда Ю. - М.: ДМК Пресс, 2012.
4. GD32F470ZKT6 [Электронный ресурс] // Datasheet. -https://datasheet.lcsc.com/lcsc/2207141800 GigaDevice-Semicon-Beiiing-GD32F470ZIT6 C5110333.pdf
5. Zhang H., Design of the Data Acquisition System based on STM32 // Zhang H. - [Электронный ресурс]. -https://www.researchgate.net/publication/257719775_Design_of_the_Data_Acquisiti on_System_Based_on_STM32
Maraev I.E.
undergraduate student National Research Nuclear University "MEPhl" (Moscow, Russia)
REQUEST-RESPONSE DATA EXCHANGE PROTOCOL FOR AUTOMATION SYSTEMS
Abstract: the paper has developed a request-response data exchange protocol that allows the exchange of information between a PC (client) and a microcontroller-based data acquisition and transmission module (server).
Keywords: data exchange protocol, data acquisition module, transmission module, serial interface.
