Оператор открыл мнемосхему в браузере с планшета в обходе. Полчаса всё стабильно: тренды бегут, квитирование работает. Ровно через час экран моргнул, появилась форма логина, а на фоне насос ещё крутится. Смена говорит: «система сама выкинула». Вы смотрите журнал 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 при этом проходит, потому что это другой протокол и другие таймеры.
На встроенной панели оператора сессия - это уровень доступа после ввода PIN или пароля на самом устройстве. Таймаут экрана и auto-logout настраиваются в проекте HMI и описаны в матрице ролей оператор/наладчик. Там же - кто может квитировать, кто меняет уставки.
Web-клиент проходит длиннее путь: браузер - TLS - proxy - сервер SCADA - драйверы OPC/Modbus - ПЛК. Разлогин на панели через два часа без касаний и «вылет» веб-мнемосхемы через час - разные настройки. Путать их на пуске опасно: наладчик увеличит timeout на панели, а оператор в браузере продолжит терять сессию.
Иерархия экранов и нагрузка на клиент тоже влияют на «активность». Тяжёлая мнемосхема с сотней анимаций шлёт больше запросов - сессия кажется «живой». Упрощённый дашборд с редким опросом чаще попадает под idle timeout. Про проектирование экранов без перегруза - в материале «HMI: иерархия экранов, аварии, тренды».
Сервер приложения (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.
Типичная схема: 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. Если остался - настройки сервера приложения.
Современные 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 на уровне TCP не продлевает HTTP-session автоматически. Нужен прикладной heartbeat: легкий запрос GET /api/ping или обновление подписки OPC каждые 30-120 с. Некоторые клиенты шлют heartbeat только при движении мыши - планшет в кронштейне без касаний «молчит».
Варианты для эксплуатации без ослабления ИБ:
периодический опрос видимых тегов с интервалом меньше idle timeout (настраивается в проекте Web); серверный механизм «slide session» - любой авторизованный API-запрос сдвигает expiry; отдельная роль «только просмотр» с более длинным idle для диспетчерского монитора на стене.
Жёстко отключать timeout «чтобы не мешало» на производстве нельзя - аудит ИБ закономерно вернёт политику обратно, часто без предупреждения наладчиков.
Оператор заходит через 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 сценарий: «мнемосхема открыта в 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 минут без касаний - ожидаемое поведение зафиксировано в паспорте».
| Симптом | Слой | Что проверить и настроить |
|---|---|---|
| Ровно через 60 мин форма login, Modbus жив | Session timeout SCADA / cookie | Idle timeout приложения; политика AD; продление при API-запросах |
| Данные замерли, login не просят | WebSocket / proxy | `proxy_read_timeout`, Upgrade headers; reconnect в клиенте; ping interval |
| Сброс только через VPN или Wi-Fi | VPN / firewall / NAT | Idle TCP на gateway; таблица NAT; тест из серверной VLAN |
| Сброс при свёрнутой вкладке | Браузер throttle | Heartbeat не от мыши; visible page polling; предупреждение оператору |
| 401 в логе proxy, SCADA молчит | Reverse proxy auth | Basic auth на nginx; рассинхрон с app session; двойная аутентификация |
| После обновления страницы сразу login | Cookie / HTTPS | Secure flag; разные host; SameSite; смешение http/https |
| Несколько операторов, один «вылетает» | Клиент / роль | Старая вкладка; лимит сессий на пользователя; concurrent login policy |
| Панель OK, Web-HMI нет | Разные механизмы | Не трогать timeout панели; настраивать web stack отдельно |
Можно ли просто поставить session timeout 24 часа?
Технически да, но ИБ и здравый смысл на производстве обычно против. Лучше явный logout, короткий idle на общих устройствах и отдельный режим для диспетчерского монитора.
Почему после re-login тренд пустой до прокрутки?
Клиент заново подписывается на архив. Это не потеря данных в историке, а задержка загрузки буфера. Если пусто дольше минуты - смотрите права роли и границы архива.
Виноват ли Modbus timeout 1 с?
Нет. Modbus timeout влияет на опрос регистров, не на HTTP-session. Если ПЛК недоступен, увидите Bad quality или alarm связи, а не login form через ровно час.
Нужен ли отдельный Web-HMI для цеха и для диспетчерской?
Не обязательно, но разные политики idle на разных URL или ролях упрощают жизнь: цех - короче, диспетчерская - длиннее, с аудитом.