Роли и доступ на панели: От «все видят всё» до разумного разграничения

На пуске панель часто живёт без разграничения: один пароль на завод, сервисные кнопки рядом с пуском, уставки открыты «чтобы не бегать к АСУ ТП». Через полгода это превращается в спор «кто нажал», случайную запись и невозможность спокойно отдать смене только обзор. Роли на HMI - не бюрократия ради галочки, а способ не дать ошибке пройти через красивый экран и оставить след в журнале, если что-то всё же пошло не так.

На объекте с СТАБУР обычно хватает трёх уровней: оператор (смена у шкафа), наладчик (АСУ ТП, сервис), администратор (редко - проект, пользователи, сеть). Пароль не на стикере на двери; уставки, которые «ведёт» технолог, на панели либо только на чтение, либо в отдельном коротком списке по регламенту. Ниже - как это согласовать с эксплуатацией без учебника по IEC 62443 и что положить в протокол приёмки.

Оператору нужен обзор участка, пуск и останов в рамках режима, квитирование аварии своего агрегата. Ему не нужны калибровка датчиков, карта Modbus, загрузка проекта с флешки и принудительные теги на выходах. Наладчику наоборот нужен сервис, диагностика связи с ПЛК, иногда ограниченная запись уставок по акту - но не обязательно право заводить пользователей или менять IP панели «на минуту». Администратор появляется эпизодами: резерв проекта, учётки, выгрузка журнала за период.

Если всё это смешано в одной учётке, граница панели и SCADA размывается: смена меняет то, что по регламенту только в диспетчерской, или наладка выглядит в журнале как «оператор нажал пуск». На малом объекте один человек может совмещать наладку и админку, но в системе лучше две разные учётки - иначе при разборе инцидента не отличить обслуживание от сменной работы.

Оператор видит главный экран участка, аварии, то, что разрешено регламентом по пуску и останову, уставки в режиме просмотра, короткий локальный тренд, если смене это нужно у шкафа. Сервисные страницы, сырые значения AI, настройка пользователей, прошивка и force для него закрыты не «потому что злой интегратор», а потому что ошибка на таком экране дороже, чем лишний клик «войти как наладчик».

Наладчик получает всё операторское плюс детализацию участка, проверку связи, сервисный режим (на посту при этом имеет смысл табличка «наладка»), запись отдельных уставок только там, где это прописано в акте или наряде, и журнал своих принудительных тегов. Создание учёток, смена сетевых параметров панели, удаление журнала и обновление прошивки без согласованного окна - за пределами его роли.

Администратор занимается пользователями, резервом и восстановлением проекта панели, сетевыми настройками, выгрузкой журнала. Повседневное управление процессом только под этой учёткой - плохая привычка: админская сессия не должна подменять смену, а force на выходах без физической изоляции привода - отдельный запрет, который стоит проговорить с эксплуатацией вслух, а не только спрятать кнопку.

Обзор цеха на семидюймовой панели у двери шкафа - не копия всей SCADA; про иерархию экранов уже писали отдельно.

Один пароль на всех и на двери шкафа - самый частый «временный» компромисс, который забывают убрать. Операторская учётка меняется по регламенту заказчика (квартал, увольнение, утечка). Пароль наладчика смене «на всякий случай» не передают: если смене нужен доступ - это отдельное решение технолога, а не копия сервисного пароля.

Таймаут сессии после нескольких минут бездействия раздражает в перчатках, но отключать вход «для удобства» хуже, чем подобрать крупные кнопки и цвета по регламенту. Wi‑Fi офиса и доступ к панели в цехе - разные истории: панель сидит в сегменте АСУ ТП и не должна открываться из корпоративной сети «чтобы директор посмотрел с телефона» без согласования с ответственным за OT.

На панели у шкафа не нужен полный audit trail уровня MES. Нужно, чтобы при споре можно было ответить: кто вошёл, когда квитировали, меняли ли уставку (старое и новое значение), заходили ли в сервис, делали ли force, грузили ли проект, были ли неудачные попытки входа. Длинные отчёты остаются SCADA; у шкафа - короткий журнал с выгрузкой за смену. Любой force на объекте лучше связывать с записью - это же тема отладки HMI на месте.

Панель - узел технологической подсети, не офисной VLAN. Доступ к WebVisu или к проекту визуализации с ноутбука - из наладочной или АСУ ТП сети; проброс порта визуализации в интернет на практике не оправдывает риск. Физический доступ к шкафу (дверь, ключ) остаётся дополнительным барьером, но не заменой ролей: открытая дверь и одна учётка «admin» снова дают «все видят всё».

Учётки панели не стоит дублировать на SCADA «для простоты» с разными правами на бумаге и одинаковым паролем в жизни. Если заказчику нужна глубокая сегментация и политики ИБ - это отдельный проект; для большинства объектов хватает разделения сетей, трёх ролей на HMI и честного журнала.

Сервисные экраны уводят за пароль наладчика или показывают только при активном сервисном режиме в ПЛК. На уровне программы контроллера запись в «опасные» теги привязывают к уровню доступа, а не только к видимости кнопки: скрытая кнопка всё равно находится через карту тегов. Калибровка, карта Modbus, пользователи, загрузка с USB, force и симуляция - не на главном экране оператора.

В CODESYS (TargetVisu) и MasterSCADA 4D роли задаются в проекте визуализации и часто дублируются проверкой на ПЛК: запись разрешена только при Level >= Engineer или аналоге. Старт с подключением - в документации и в материале «Первый старт».

Порядок внедрения обычно простой: согласовать матрицу с эксплуатацией, убрать сервис с первого экрана смены, включить журнал и проверить выгрузку, обучить одному паролю оператора и объяснить, что делать при «доступ запрещён», зафиксировать ревизию в паспорте объекта. Без подписанной матрицы через год никто не вспомнит, почему наладчику разрешили именно эти уставки.

В протокол с эксплуатацией удобно вложить текст ниже: в Тильде - заголовок роли и два коротких списка «разрешено / запрещено», без markdown-таблицы. Полный текст без разметки лежит в файле gold-article-102-matrica-rotey-hmi-shablon-tilda.txt в этой же папке.

Шапка: Матрица ролей HMI. Объект: [код]. Ревизия: [дата]. Проект панели: [ревизия].

Оператор (смена). Разрешено: обзор участка, аварии и квитирование, пуск/стоп по регламенту, просмотр уставок, локальный тренд 15–60 мин. Запрещено: запись уставок, сервис и наладка, калибровка и сырые AI, карта Modbus, пользователи, загрузка проекта с USB, force.

Наладчик (АСУ ТП). Разрешено: всё операторское, детальный экран, диагностика связи, сервисный режим с табличкой на посту, ограниченная запись уставок по акту, журнал force. Запрещено: учётки и роли, IP и сеть панели, прошивка без окна, удаление журнала.

Администратор. Разрешено: пользователи и роли, резерв/восстановление проекта, сеть, экспорт журнала. Запрещено: ежедневная работа смены под админом, force на выходах без изоляции привода.

Примечания: уставки технолога - отдельным списком тегов; совмещение ролей - разные логины; при приёмке оператор не видит сервис, наладчик видит свой журнал force.

На части малых объектов регламент так и строят - тогда роли и журнал на SCADA важнее, но риск случайного нажатия на панели при открытой двери остаётся.

Три роли - нормальная рабочая схема. Десять уровней без сопровождения путают всех сильнее, чем защищают.

Только наладчик или админ по регламенту, с записью в журнале, не «1234 на стикере».

•Граница панели и SCADA;

•Отладка HMI на объекте;

•Цвета и подтверждения для смены;

•HMI: иерархия экранов;

•Панели оператора СТАБУР: выбор.