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