Web-HMI сбрасывает сессию через час: таймаут, keep-alive и прокси

Оператор открыл мнемосхему в браузере с планшета в обходе. Полчаса всё стабильно: тренды бегут, квитирование работает. Ровно через час экран моргнул, появилась форма логина, а на фоне насос ещё крутится. Смена говорит: «система сама выкинула». Вы смотрите журнал SCADA - разрывов связи с ПЛК нет, Modbus TCP живой. Зато в access-log reverse proxy видно 401 и новый session id в момент, когда оператор ничего не нажимал.

Такие обрывы почти никогда не связаны с «плохим ПЛК» или с правами оператора в классическом смысле. Чаще это цепочка таймаутов: idle timeout веб-клиента, session cookie на сервере HMI, настройки nginx или IIS, обрыв WebSocket без переподключения, корпоративный firewall, который режет долгие TCP-сессии. Статья разбирает именно веб-доступ к HMI и SCADA через браузер. Отдельная тема - роли «оператор/наладчик» на встроенной панели; здесь только сетевой и серверный слой сессии.

Короткий ответ

Если Web-HMI стабильно разлогинивает примерно через 60 минут бездействия или ровно через фиксированный интервал, ищите session timeout и idle disconnect, а не Modbus. Проверьте три уровня: таймаут сессии в SCADA/Web-клиенте, proxy_read_timeout / session timeout на reverse proxy, keep-alive и WebSocket ping на балансировщике и firewall. Типичные значения «час» дают политики безопасности AD, nginx proxy_read_timeout 3600s, IIS sessionState timeout="60", корпоративный SSL VPN. Симптом «данные на экране замерли, но логин не просят» - обрыв WebSocket при живой HTTP-сессии. Сверьте время разрыва с логами proxy и сервера приложения; одна таблица ниже сопоставит симптом со слоем.

Почему ровно час: откуда берётся магическое число

Шестьдесят минут - не случайность. Многие политики безопасности и веб-серверы по умолчанию задают idle timeout 3600 с. Оператор смотрит на тренд, не трогает экран - для сервера это «простой». HTTP-сессия истекает, cookie перестаёт быть валидной, клиент при следующем запросе (обновление тренда, квитирование) получает редирект на login.

Второй источник - reverse proxy перед SCADA. Nginx по умолчанию обрывает upstream-соединение при отсутствии данных между клиентом и backend дольше proxy_read_timeout. Если Web-клиент не шлёт keep-alive или heartbeat, proxy закрывает канал. Браузер может ещё показывать старую страницу из кэша, а подписка на теги уже мертва.

Третий слой - балансировщик или firewall между VLAN цеха и серверной. Некоторые устройства сбрасывают «тихие» TCP-сессии через 30-60 минут независимо от приложения. ICMP ping при этом проходит, потому что это другой протокол и другие таймеры.

Web-HMI vs панель оператора: разные механизмы сессии

На встроенной панели оператора сессия - это уровень доступа после ввода PIN или пароля на самом устройстве. Таймаут экрана и auto-logout настраиваются в проекте HMI и описаны в матрице ролей оператор/наладчик. Там же - кто может квитировать, кто меняет уставки.

Web-клиент проходит длиннее путь: браузер - TLS - proxy - сервер SCADA - драйверы OPC/Modbus - ПЛК. Разлогин на панели через два часа без касаний и «вылет» веб-мнемосхемы через час - разные настройки. Путать их на пуске опасно: наладчик увеличит timeout на панели, а оператор в браузере продолжит терять сессию.

Иерархия экранов и нагрузка на клиент тоже влияют на «активность». Тяжёлая мнемосхема с сотней анимаций шлёт больше запросов - сессия кажется «живой». Упрощённый дашборд с редким опросом чаще попадает под idle timeout. Про проектирование экранов без перегруза - в материале «HMI: иерархия экранов, аварии, тренды».

Session timeout в SCADA и веб-клиенте

Сервер приложения (MasterSCADA 4D Web, OPC UA Web client, отдельный web portal интегратора) хранит идентификатор сессии на стороне сервера или в подписанной cookie. Параметры: максимальное время жизни сессии, idle timeout, принудительный logout при смене IP (иногда включают по политике ИБ).

Проверка на стенде: откройте Web-HMI, не трогайте мышь, засеките время до login form. Повторите с открытым DevTools Network - смотрите, какие запросы уходят каждые N секунд. Если запросов нет 50 минут, а на 60-й приходит 302 на /login - idle timeout сервера.

Увеличение timeout - не всегда правильный ответ. Для АСУ ТП длинная неактивная сессия с правами оператора - риск на общем планшете в цехе. Компромисс: разумный idle (15-30 мин для цеха, 60 для диспетчерской), явное предупреждение «сессия истечёт через 2 минуты», кнопка «продлить» без полного re-login.

Reverse proxy: nginx, IIS, Apache

Типичная схема: SCADA слушает localhost:8080, снаружи nginx на 443 с сертификатом. Оператор ходит на https://scada.plant.local. В конфиге nginx критичны:

proxy_read_timeout - сколько ждать ответа от backend; proxy_send_timeout - сколько ждать при отправке; keepalive_timeout - жизнь keep-alive соединения с клиентом.

Для WebSocket добавляют Upgrade и Connection "upgrade", отдельный proxy_read_timeout для location /ws или /signalr. Без этого websocket обрывается раньше HTTP-сессии - на экране «замёрзшие» значения, login ещё не просят.

IIS с ARR (Application Request Routing) имеет аналоги: idle timeout приложения, limits на connection. В журнале IIS ищите sc-status 401/440 в момент жалобы.

Практический тест: временно подключите Web-HMI напрямую к порту SCADA, минуя proxy. Если часовой сброс исчез - копайте proxy и firewall. Если остался - настройки сервера приложения.

WebSocket, SignalR и «тихий» обрыв

Современные Web-клиенты SCADA держат канал push через WebSocket или long polling. Браузерная вкладка в фоне на планшете может throttle JavaScript - heartbeat перестаёт уходить. Сервер считает клиента отключённым, освобождает подписки. При возврате на вкладку UI живой, данные старые.

Признаки: в Network вкладке WebSocket status finished или код 1006; тренд не обновляется, но кнопки ещё кликаются до первого failed XHR. Решение на стороне проекта: периодический reconnect, ping/pong на уровне протокола, fallback на polling с интервалом меньше proxy timeout.

Не путайте с Bad quality тегов - там связь с ПЛК есть, quality в драйвере BAD. При обрыве WebSocket теги в клиенте могут оставаться GOOD из последнего снимка - оператор принимает решение по устаревшей цифре. Для критичных величин добавляют индикатор «нет связи с сервером» поверх мнемосхемы, не только маленький значок в углу.

Keep-alive и активность сессии: что считать «действием»

Keep-alive на уровне TCP не продлевает HTTP-session автоматически. Нужен прикладной heartbeat: легкий запрос GET /api/ping или обновление подписки OPC каждые 30-120 с. Некоторые клиенты шлют heartbeat только при движении мыши - планшет в кронштейне без касаний «молчит».

Варианты для эксплуатации без ослабления ИБ:

периодический опрос видимых тегов с интервалом меньше idle timeout (настраивается в проекте Web); серверный механизм «slide session» - любой авторизованный API-запрос сдвигает expiry; отдельная роль «только просмотр» с более длинным idle для диспетчерского монитора на стене.

Жёстко отключать timeout «чтобы не мешало» на производстве нельзя - аудит ИБ закономерно вернёт политику обратно, часто без предупреждения наладчиков.

Корпоративная сеть: VPN, SSL inspection, NAT

Оператор заходит через VPN подрядчика или корпоративный SSL VPN. Туннель рвёт idle TCP через час - симптом тот же, что session timeout. Отличие: в логах SCADA сессия ещё валидна, обрыв на уровне VPN gateway. Проверка - тот же Web-HMI из серверной VLAN без VPN.

SSL inspection на firewall подменяет сертификаты и иногда ломает WebSocket или укорачивает соединения. Симптом плавающий: с одного ПК OK, с планшета через guest Wi-Fi - сброс каждые 20 минут.

NAT session table на промышленном маршрутизаторе переполняется или агрессивно чистит старые записи. Для длинных сессий снижают число параллельных вкладок, включают HTTP/2 multiplexing где поддерживается, или поднимают лимиты на оборудовании по согласованию с сетевиками.

FAT и приёмка: что записать в паспорт Web-доступа

На стенде редко проверяют поведение сессии дольше получаса. Добавьте в протокол FAT сценарий: «мнемосхема открыта в Chrome, без касаний 75 минут». Ожидаемое поведение должно быть согласовано с ИБ заказчика заранее - либо logout с формой входа, либо предупреждение и продление, либо баннер «нет связи с сервером» при обрыве WebSocket. Без записи в паспорте эксплуатация воспримет разлогин как дефект интегратора.

Зафиксируйте версию браузера, URL, наличие proxy, значения timeout в nginx и в SCADA. При смене корпоративного антивируса или политики GPO через полгода поведение может измениться - baseline в паспорте ускорит спор.

Для планшета в цехе отдельно проверьте режим энергосбережения Android/iOS: затемнение экрана не равно разрыву сессии, но throttle фоновых вкладок - равен. Рекомендация в паспорте: kiosk-mode или отключение sleep на зарядке.

Типичные ошибки при настройке

Первая - копирование конфига nginx с интернет-сайта без proxy_read_timeout под WebSocket. Вторая - увеличение только session timeout в SCADA, пока proxy рвёт через 60 минут. Третья - смешение аутентификации AD и локальных пользователей SCADA: AD session живёт по одним правилам, cookie приложения - по другим.

Четвёртая - несколько вкладок с одной учёткой: logout в одной вкладке инвалидирует сессию для всех. Оператор думает, что «система выкинула», хотя коллега на соседнем посту нажал «выход».

Пятая - тест только с движением мыши. На объекте планшет в кронштейне - тест без касаний обязателен.

Диагностика по шагам на объекте

Зафиксируйте точное время сброса три раза подряд. Совпадение до минуты - таймер, не «случайная сеть». Соберите: access-log proxy с timestamp, application log SCADA (login/logout/session expired), при возможности capture на порту клиента (Wireshark) - FIN/RST от кого пришёл.

Сопоставьте с расписанием: не совпадает ли с ночным backup, антивирусным сканом, перезапуском пула IIS. Иногда «час» - это cron на сервере, который рестартует службу SCADA.

Документируйте рабочую конфигурацию: URL, proxy, значения timeout, версия браузера. Chrome и встроенный браузер панели ведут себя по-разному. Для FAT добавьте сценарий «мнемосхема открыта 90 минут без касаний - ожидаемое поведение зафиксировано в паспорте».

Симптом, слой и настройка

Вопросы с пуска

Можно ли просто поставить session timeout 24 часа?
Технически да, но ИБ и здравый смысл на производстве обычно против. Лучше явный logout, короткий idle на общих устройствах и отдельный режим для диспетчерского монитора.

Почему после re-login тренд пустой до прокрутки?
Клиент заново подписывается на архив. Это не потеря данных в историке, а задержка загрузки буфера. Если пусто дольше минуты - смотрите права роли и границы архива.

Виноват ли Modbus timeout 1 с?
Нет. Modbus timeout влияет на опрос регистров, не на HTTP-session. Если ПЛК недоступен, увидите Bad quality или alarm связи, а не login form через ровно час.

Нужен ли отдельный Web-HMI для цеха и для диспетчерской?
Не обязательно, но разные политики idle на разных URL или ролях упрощают жизнь: цех - короче, диспетчерская - длиннее, с аудитом.

Ссылки по теме

• Роли доступа на панели оператора: матрица оператор/наладчик;
• HMI для оператора: иерархия экранов, аварии, тренды без перегруза;
• Отладка HMI: объект, симуляция, force, журнал оператора;
• Панель оператора и SCADA: граница уставок и аварий;
• Modbus TCP для интегратора: таймауты и диагностика.