Опрос статуса в DMR Tier III: какое сообщение действительно приносит значение
Диспетчерская программа умеет отправлять статусы и показывает успешное принятие команды сетью. Из этого ещё нельзя заключить, что она умеет запросить текущее значение у другой станции. В DMR Tier III передача заранее выбранного статуса и опрос статуса различаются по смыслу и по завершению процедуры. При проверке интеграции нужно проследить, откуда именно появилось показанное оператору число.
Как начинается опрос
В описанной редакции стандарта специальное значение Status 127 обозначает запрос Status Polling. Инициатор обращается к индивидуальной станции. Это служебный признак операции, поэтому показывать его пользователю как полученный рабочий статус ошибочно. Например, надпись «статус 127 принят» ещё ничего не сообщает о готовности конкретной бригады.
Инфраструктура направляет опрашиваемой станции запрос C_AHOY. Когда станция отвечает принятием опроса, её фактический статус находится в поле Response_Info подтверждения. Сеть переносит это поле в окончательный ответ инициатору. Таким образом, проверяемая цепочка состоит из запроса, ответа адресата и доставки результата тому, кто начал опрос.
Ожидание не равно результату
В ходе процедуры возможны промежуточные сообщения: продолжение обработки, занятость абонента или очередь ресурса. Они объясняют состояние обслуживания, но не заменяют запрошенное значение. В интерфейсе приложения разумно разделить «опрос выполняется», «получен статус» и «опрос завершился без результата». Это предложение по организации интерфейса, а не требование к виду дисплея радиостанции.
Если адресат не ответил, сеть может повторить обращение либо прекратить обслуживание и передать отказ. Поэтому таймаут приложения нельзя незаметно подменять последним сохранённым статусом. Старое значение допустимо показывать как историю с явной отметкой времени, если такая функция предусмотрена системой.
Приёмочный пример
Для испытания задают станции один известный статус и выполняют индивидуальный опрос. В журнале сохраняют адрес инициатора, адрес опрашиваемого абонента, последовательность подтверждений и значение Response_Info в успешном завершении. Затем меняют статус и повторяют проверку. Второй результат помогает обнаружить кэш, который ошибочно выдаёт прежнюю запись вместо нового ответа.
Отдельный прогон проводят при недоступном адресате. Ожидают документированное завершение без свежего результата, а не произвольное число на экране. Если окончательное подтверждение повторяется ради надёжности, приложение должно учитывать, что один опрос может породить повтор доставки одного значения.
Такой тест подтверждает содержательную работу опроса. Он не устанавливает значение производственных кодов вроде «свободен» или «на задании»: соответствующий словарь согласуют в конкретной организации отдельно от транспортной процедуры.