В этом тексте я напишу атрибуты хорошего простого канального Master-Slave протокола для пакетного обмена информацией между устройствами на общей шине таких как RS485, CAN, LoRa, BLE или поверх TCP, UDP. Несмотря на то, что есть канальные протоколы ModeBus, CANOpen, J1913, DLMS, RDS, UBX, ASN.1, NEC, Pelco-D, yModem, многие российские компании просто не могут себе позволить купить на них лицензию и спецификацию и всё же колхозят свой собственный протокол для взаимодействия между своими электронными платами. Тут представлены общие атрибуты таких доморощенных протоколов.
1--M2M протокол должен быть бинарным*
Это сделает трафик компактнее и проще в обработке на стороне firmware.
2--Должна быть преамбула*
Преамбула нужна, чтобы конечный автомат мог выхватывать пакеты из потока байтов.
3--Преамбула должна быть параметризируемая*
Преамбулу следует параметризировать так как должна быть предусмотрена возможность туннелирования пакетов одного и того же протокола. Это особенно полезно когда физика трансивера за раз может отправить только N байт, а сам пакет M байт. При этом N<M. В этом случает маленькими пакетами передается большой пакет как поток байтов.
4--Должен быть порядковый номер пакета*
Это позволит на стороне приемника определить потерю непрерывности потока.
5--Должно быть поле, которое отвечает за длину полезных данных*
Это позволит сделать протокол универсальным и сделает возможность передавать данные разной длинны.
6--Передавать многобайтовые поля в заголовках следует в Big Endian
Так проще анализировать сырые пакеты в текстовом редакторе или на осциллографе.
7--В пакете должна быть контрольная сумма*
Это позволит проверить, что пакет не повредился в процессе передачи из-за радиопомех помех или дребезга контактов.
8--В заголовке должен быть бит честности данных
Это вспомогательная защита целостности данных хоть и менее надежная, чем с контрольная сумма.
9--Контрольная сумма должна быть в конце пакета
Это позволит проще вычислять СRС, захватывая как данные так и заголовок.
10--Должен быть идентификатор типа полезных данных
Это позволит приемнику быстрее понять как интерпретировать полезные данные внутри пакета.
11--Должно быть подтверждение принятого пакета*
Так Master Node(а) поймет, что Slave Node(а) точно съела пакет
12--Должна быть повторная отправка в случае отсутствия подтверждения*
Это повысит надежность передачи данных.
13--В заголовке должна быть TimeStamp отправки пакета
Для отладки хронологии диалога и оценки быстродействия обработки. Есть аппаратные способы прослушивать трафик в той же RS485.
14--Спецификацию протокола следует делать в формате общих электронных таблиц*
Делать спеки протоколов в doc это уже архаично. Электронные таблицы идеально подходят для представления структуры массива. Любой пакет это по факту обыкновенный массив. В электронных таблицах можно сортировать пакеты, быстро искать нужный пакет, раскрашивать поля, проверять полноту, находить свободные идентификаторы, и даже авто генерировать парсеры в виде С-кода для синтаксического разбора пакетов.
15--Должно быть шифрование PayLoad(а)*
В случае ответственных задач имеет смысл запилить шифрование полезных данных пакета ,чтобы нелегальные узлы не могли наблюдать за работой системы и подключать к общей шине свою телеметрию и телематику.
16--Пакетная синхронизация должна производится по преамбуле
Раз приняли преамбулу и CRC валидная значит пришел новый пакет.
17--Пакетная синхронизация должна производится по TimeOut
Также можно делать пакетную синхронизацию по TimeOut(у). То есть после продолжительного молчания на шине сбрасывать конечный автомат приема и ждать новой преамбулы.
Вывод
Это основные требования к реализации кибернетики очередного обобщенного компанейского бинарного протокола передачи данных. Это протокол для M2M взаимодействий.
Если вам известны еще атрибуты хорошего протокола передачи данных, то пишите их в комментарии. Также пишите про те стандартные протоколы с которыми вам приходилось сталкиваться и делитель впечатлениями от работы с разными протоколами.
