В процессе автоматизации крупных складских комплексов часто возникает задача визуализации оперативной информации. Сборщики должны видеть актуальные задания, остатки или статус заказов на стационарных мониторах (экранах), распределенных по всей территории склада. Однако при масштабировании системы до сотен устройств многие сталкиваются с критической проблемой: время обновления информации на экранах составляет 30–60 секунд, что фактически парализует работу. В этой статье мы подробно разберем, почему возникают такие задержки и как оптимизировать связку WMS и систем отображения.
Одной из главных причин, как показывает практика, является некорректное проектирование беспроводной сети. Рассмотрим ситуацию, когда на 300 экранов (телевизоров с Wi-Fi) приходится всего 4 роутера. С точки зрения радиофизики это создает "эффект узкого горлышка".
Разберем подробнее понятие Airtime Fairness (справедливость эфирного времени). Стандарт Wi-Fi устроен так, что в один конкретный момент времени точка доступа может обмениваться данными только с одним клиентом. Когда 75 устройств пытаются одновременно получить данные от одной точки, они выстраиваются в очередь. Если хотя бы несколько телевизоров имеют слабый уровень сигнала, точка доступа тратит на них гораздо больше времени, снижая общую пропускную способность для всех остальных "соседей" по сегменту.
Проанализируем также влияние диапазона. Большинство бюджетных телевизоров работают на частоте 2.4 ГГц. В этом диапазоне всего 3 непересекающихся канала (1, 6 и 11). Если ваши 4 роутера работают в этом узком спектре, они неизбежно создают помехи друг другу (Co-Channel Interference). Это приводит к потере пакетов и постоянным повторным запросам, что и выливается в минутные задержки.
Рекомендации по сетевой части:
Второй критический фактор — это способ, которым экраны получают информацию от сервера WMS. Рассмотрим типичную ошибку: использование технологии HTTP Polling (короткие опросы). В этой схеме каждый из 300 экранов раз в 5–10 секунд отправляет запрос: "Есть ли для меня новые данные?".
Проанализируем нагрузку: 300 запросов каждые 5 секунд создают постоянный поток из 60 запросов в секунду на сервер WMS. Это приводит к постоянным блокировкам в базе данных и высокой нагрузке на CPU сервера. Если сервер не успевает ответить мгновенно, запросы копятся, и возникает задержка, которую мы и наблюдаем.
Выясним, как сделать лучше. Для систем реального времени рекомендуется использовать технологию WebSockets или MQTT. В отличие от стандартного HTTP, здесь устанавливается постоянное соединение, и сервер сам "проталкивает" (Push-уведомление) данные на экран только тогда, когда в WMS произошли реальные изменения.
Посмотрим на пример логики оптимизированного запроса на стороне 1С (если WMS построена на этой платформе). Вместо того чтобы каждый раз выполнять тяжелый запрос к базе данных, мы можем использовать механизм кеширования или отдельную таблицу "АктуальныеСостоянияЭкранов".
// Пример упрощенной функции обработки запроса от экрана
Функция ПолучитьДанныеДляЭкрана(ИдентификаторЭкрана) Экспорт
// Не выполняем тяжелый расчет, а берем готовое значение из быстрого кеша
Данные = РегистрыСведений.ТекущиеЗаданияЭкранов.Получить(Новый Структура("Экран", ИдентификаторЭкрана));
Если Данные.Версия = ТекущаяВерсияНаЭкране Тогда
Возврат КодСостояния.БезИзменений;
КонецЕсли;
Возврат СформироватьJSONДанных(Данные);
КонецФункции
Часто в роли экранов выступают бюджетные Smart TV. Проанализируем их аппаратную часть: обычно это крайне слабые процессоры и минимальный объем оперативной памяти. Встроенные браузеры таких телевизоров плохо справляются с тяжелыми веб-страницами.
Разберем по шагам, что можно сделать на фронтенд-части (то, что отображается на экране):
JavaScript.Если ваша WMS не предназначена для обслуживания сотен одновременных веб-соединений, рассмотрим внедрение промежуточного сервера (Broker/Middleware). Это может быть простой сервер на Node.js или Python, который выполняет роль прокси.
Схема работы будет выглядеть так:
WMS отправляет данные на промежуточный сервер один раз (при изменении), а промежуточный сервер по протоколу WebSockets мгновенно рассылает их на все 300 экранов. Таким образом, нагрузка на базу данных WMS снижается до минимума, а скорость доставки информации возрастает до миллисекунд.
Резюмируем план действий:
Только комплексный подход к сетевой инфраструктуре и архитектуре программного обеспечения позволит добиться мгновенного отклика системы, что критически важно для динамичной работы современного склада.