OmegabcRaw Data или Defined Data в DMR: кто отвечает за формат короткого сообщения
Две программы могут успешно передать байты по DMR и всё равно не понять содержание друг друга. Транспортная совместимость не задаёт автоматически структуру рабочего сообщения. ETSI различает Raw Data, где формат определяют приложения, и Defined Data с предусмотренным обозначением формата. Перед интеграцией нужно выбрать подходящий механизм и определить ответственность за содержимое.
Разделите контейнер и рабочую структуру
Для Raw Data опишите, как приложение кодирует поля, где указан тип события и как получатель отличает одну редакцию сообщения от другой. Если данные направляются по предусмотренным портам, зафиксируйте их назначение. Не используйте совпадение номера порта как доказательство совпадения структуры данных.
Для Defined Data согласуйте конкретное представление из поддерживаемых выбранным составом. Но и оно не объяснит смысл всех полей прикладного события. Например, текстовая кодировка определяет представление символов, а не то, что означает первая строка задания и какое число является его идентификатором.
Подготовьте примеры до разработки
Согласуйте несколько сообщений: обычное, с предельными допустимыми значениями и с необязательными полями. Для каждого сохраните понятное человеку представление и ожидаемую обработку. Если используются двоичные поля, определите длину, порядок и допустимые значения. Всё это относится к договорённости приложений и не должно приписываться общему стандарту DMR.
Испытайте отправку в обе стороны, если требуется двусторонняя работа. Программа, которая верно принимает собственные сообщения, ещё не подтверждает совместимость с другим участником. Успешный радиообмен нужно сопоставить с тем, какие поля фактически разобрал адресат и какой результат показал оператору.
Продумайте изменение формата
Новая редакция приложения не должна молча менять смысл уже используемого поля. Укажите признак версии или иной согласованный способ различения и правило обработки неизвестного варианта. Для постепенного обновления парка полезно заранее определить, какие сочетания версий допускаются и как выявляется несовместимость.
Отдельно предусмотрите неполное, ошибочное или неизвестное сообщение. Нельзя автоматически превращать его в правдоподобное рабочее событие с подставленными значениями. Поведение получателя должно быть явным и проверяемым: отказ разбора, диагностическая запись или другое согласованное действие.
В итоговый комплект включите выбранную службу DMR, формат прикладных данных, примеры и протокол сквозного испытания. Тогда ответственность будет распределена понятно: радиообмен доставляет предусмотренное представление, а приложения одинаково интерпретируют его содержание. Это позволяет искать ошибки формата отдельно от неисправностей радиосвязи и не лечить неверное поле повторным программированием всей сети.
Источник: ETSI TR 102 398 V1.5.1 (2023-11), раздел 6.3.2.2–6.3.2.3, стр. 32; раздел 7.3, стр. 35–36.