Динамический состав аварийной ad hoc MC-группы: прибытие и уход сотрудников во время события
Список в начале события не остаётся неизменным
Аварийное ad hoc MC-оповещение продолжается, а состав сотрудников на объекте меняется. Новая бригада подходит к месту работ, один специалист покидает соответствующую область. Для такого сценария сервер продолжает проверять, кто отвечает условиям действующего оповещения.
Поэтому сохранённый в начале список не описывает всю дальнейшую историю. Прибывшего пользователя могут добавить в ad hoc группу, направить ему alert и получить ответ. Уполномоченное рабочее место получает обновлённые сведения о составе и неподтвердивших.
Что проверить для нового участника
В тестовом контуре задают однозначный критерий и запускают учебное событие. Затем изменяют условия для дополнительного клиента так, чтобы он начал соответствовать критерию. Инженер прослеживает решение сервера, сообщение клиенту, уведомление пользователя и ответ.
Если в группе уже продолжается аварийное общение, проверяют предусмотренное добавление к нему по процедуре соответствующей службы. Сам факт получения alert не заменяет наблюдение медиа. Для MCPTT, MCVideo и MCData результаты сервисной части подтверждают отдельно в требуемом проектом объёме.
Уход из состава имеет важное условие
Когда пользователь больше не отвечает критерию, сервер запускает отмену для этого клиента и обновление состава. Но раздел содержит существенную оговорку: если для пользователя продолжается общение в ad hoc группе, удаление из группы откладывается до его завершения.
Поэтому немедленное отсутствие alert и фактическое исключение из любого текущего общения нельзя считать одним событием. Приёмка должна покрывать два опыта: выход без продолжающегося общения и выход во время него.
В журнале сохраняют момент изменения условий, серверное решение, уведомление клиента и фактическое удаление. Это помогает объяснить, почему карта или справочник уже показывают новое положение, а участие в текущем общении ещё сохраняется согласно процедуре.
Как вести оперативный отчёт
Отчёт должен показывать изменения состава во времени. Последний снимок списка скрывает, кто присоединился поздно и кто покинул событие раньше его окончания. Для расследования полезны последовательность уведомлений и исходные идентификаторы пользователей.
Конкретные критерии, источники данных и допустимые задержки устанавливаются проектом. Общая процедура не обещает мгновенное реагирование на любое перемещение.
Готовность подтверждается корректными входом, выходом и сохранением предусмотренного текущего общения. Такой тест позволяет оценить реальное сопровождение динамической бригады, а не только красивый исходный список. Дежурный понимает, почему состав меняется, и может отличить ожидаемую задержку удаления от ошибки обработки нового состояния сотрудника.