На линии стоит панельный контроллер: локальный экран на двери шкафа, тот же runtime отдаёт визуализацию в браузер. Ночная смена ставит расход 12.4 с панели. Технолог с ноутбука в диспетчерской в ту же минуту пишет 11.0 в то же поле. Цикл ПЛК один. Регулятор берёт последнее записанное значение. Через два часа разбор: «кто сменил уставку?» В журнале HMI - два события с почти одним временем, разные клиенты, никто не считал себя главным. Наладчик говорит: «ну это же одна мнемосхема». Именно поэтому гонка и случилась.
Разбираем одновременную работу TargetVisu (локальный экран целевого устройства) и WebVisu (браузер) на одном runtime визуализации: гонка записи уставок, сессии, приоритет «кто имеет право писать», нагрузка на цикл, что фиксировать в регламенте смены. Это не выбор «планшет вместо панели» и не спор, какое железо ставить на дверь. Фокус - два клиента одной визуализации на одном контроллере. Нет урока по вёрстке мнемосхемы и нет разбора таймаута прокси как отдельной темы: сессии касаемся только там, где они ломают приоритет записи.
Короткий ответ
TargetVisu и WebVisu в типичной среде CODESYS 3.5 - два клиента одной визуализации и одних переменных приложения. Локальный экран не «главнее» браузера сам по себе: побеждает тот, кто последним записал тег, если в проекте нет блокировки, роли и журнала источника. Два оператора с правом записи на одно поле уставки - это split-brain контура, не удобство.
Закрывают гонку в проекте, не уговором: флаг местного/удалённого управления, запрет записи веб-клиенту в режиме «у машины», именные сессии, журнал «кто / откуда / старое / новое», таймаут веб-сессии, лимит одновременных WebVisu. Регламент смены называет хозяина уставки на каждом режиме (местный, диспетчерский, сервис). Нагрузка CPU визуализации и веб-сервера - отдельный бюджет: второй клиент не бесплатен для цикла.
Похожий конфликт бывает у любой пары «экран на контроллере + веб-клиент» в другой среде на том же железе. Механика та же: один образ переменных, две руки.
Два клиента, один образ переменных
Панельный ПЛК совмещает задачу управления и задачу визуализации. TargetVisu рисует кадры на встроенном дисплее, ходит в те же VAR, что и программа. WebVisu отдаёт ту же (или почти ту же) визуализацию через веб-сервер runtime: браузер на посту, в диспетчерской, у технолога. Для ST-программы это не «два контроллера». Это два входа в одну память.
Отсюда три следствия, которые на пуске любят игнорировать.
Первое: нет естественного приоритета железа. Кнопка на стекле двери не старше поля в Chrome, пока вы это не закодировали. Среда не спрашивает, кто ближе к насосу.
Второе: визуализация пишет в переменные так же, как программа. Input-поле уставки - запись в GVL или в FB. Последний цикл с новой записью побеждает. Если оба клиента попали в соседние циклы, «истина» - последняя. Оператор у шкафа этого не видит, пока не обновится кадр.
Третье: сессии не равны. TargetVisu часто живёт как постоянное рабочее место смены: экран включён часами, роль «оператор» не истекает. WebVisu живёт логином, idle timeout, обрывом WebSocket, прокси. Через час тишины браузер просит пароль, хотя контур ещё в AUTO. Локальный экран при этом продолжает писать. Разрыв веб-сессии не откатывает уставку, которую уже записали. Поведение таймаута браузера как таковое разобрано в материале про сброс сессии web-HMI; здесь важно другое: истекшая сессия не снимает конфликт, она его маскирует. Технолог думает, что «уже не в системе», а последнее значение его руки уже в регуляторе.
Не путайте это с архитектурой «панель на двери и отдельная SCADA на сервере». Там хотя бы два приложения, можно развести права и архив. TargetVisu + WebVisu - один application, один набор прав визуализации, если вы не построили матрицу сами.
Смена устройства (планшет вместо выреза в двери) - другая постановка: где физически сидит оператор, что делать без Wi-Fi, где живёт грибок стопа. Это разбирали отдельно: планшет вместо стационарной панели. Ниже планшет появляется только как ещё один WebVisu-клиент к тому же контроллеру, на котором уже горит TargetVisu.
Гонка уставки: кто побеждает без проекта
Типовой контур: PID или позиционер, SP пишет оператор. На кадре одно поле. Права «все, у кого пароль оператора». Два человека считают себя сменой.
Сценарий А. Оба смотрят число 80. Первый пишет 90 на двери. Второй, не дождавшись обновления, пишет 70 в браузере. Регулятор идёт к 70. Первый видит на экране 70 через секунду и думает, что «система сбросила». Начинается война кнопок.
Сценарий Б. Диспетчер держит WebVisu «на всякий случай» с правом записи. Ночью меняет SP, не подойдя к агрегату. Местный оператор работает по инструкции «уставка только с панели». Инструкция не в коде. Код слушает обоих.
Сценарий В. Наладчик в WebVisu, роль шире, чем у смены. Сидит в том же поле SP, что оператор. Force и сервисные экраны не отделены. Утром в тренде ступенька, подписи нет.
Сценарий Г. Два браузера плюс TargetVisu. Три писателя. Вероятность гонки растёт не линейно: кто-то оставляет вкладку открытой на чужом ПК.
Без блокировки победитель всегда один: last write wins. Среда визуализации не делает транзакцию «прочитай-измени-запиши» для поля SP. Не делает и арбитра «ближний экран важнее». Это нужно нарисовать в ST/FBD: либо единственный источник SP в каждый момент, либо очередь команд с подтверждением.
Сравнение с границей «панель / SCADA» полезно как аналогия, не как копия. Когда уставка живёт на панели и на сервере, правило «кто хозяин SP» всё равно пишут явно; иначе ночной мастер со SCADA и смена у шкафа спорят так же. Разбор границы прав на уставку и аварию между панелью и SCADA - в отдельном материале: панель оператора и SCADA. Для TargetVisu/WebVisu сервера может не быть вообще: оба клиента бьют в один ПЛК. Правило ещё нужнее, потому что спрятаться за «это другой компьютер» нельзя.
Приоритет, который можно закодировать
Рабочие схемы, которые сдают на SAT. Выбирают одну и учат смену, не три сразу.
Ключ или дискретный «Местное / Дистанционное». Физический переключатель на двери или ключ режима. В LOCAL запись SP с WebVisu отбрасывается (поле read-only или запись в брак с сообщением). В REMOTE наоборот: локальные input-поля не пишут SP, только показывают. Аварийный стоп и блокировки не зависят от ключа. Это самый понятный арбитраж для цеха: видишь ключ - знаешь, чья рука.
Программный владелец с таймаутом. Бит bLocalOwner. Панель берёт владельца кнопкой «управление здесь». WebVisu берёт другой кнопкой. Владелец один. Idle 5–15 минут без действий - сброс владельца в безопасный профиль (обычно LOCAL, если человек у машины). Журнал смены владельца обязателен. Минус: забытый бит. Плюс: нет второго ключа в шкафу.
Роль без права записи на одном из клиентов. Оператору на TargetVisu - SP, квитирование, ручной режим по регламенту. Веб-клиенту технолога - тренды, просмотр, квитирование информационных сообщений, без SP. Наладчику WebVisu - сервисные кадры по именной учётке, не по паролю смены. Матрица ролей на панели как практика не отменяется: оператор / наладчик. Её нужно распространить на тип клиента, не только на ФИО.
Команда, а не прямая запись SP. Браузер и даже панель не пишут REAL уставки напрямую. Пишут запрос: «установить 12.4». Программа принимает, проверяет пределы, источник, режим, логирует, затем копирует в SP. Повтор запроса с тем же числом идемпотентен. Две противоречивые заявки - отказ второй с причиной «владелец другой» или очередь на подтверждение у хозяина режима. Это тяжелее вёрстки, зато разбор после аварии не гадание.
Что не работает: надпись на кадре «уставку менять только с панели». Надпись не держит тег. Что почти не работает: «договоримся, что технолог только смотрит». До первого ночного звонка.
Пользователи визуализации. Именные учётки, запрет общего operator на оба клиента сразу. Если WebVisu пускает гостя без логина «чтобы быстрее», гонка становится анонимной. Анонимную запись в SP на объекте с двумя клиентами закрывают в первую очередь.
Current user / current client в визуализации стоит вывести в журнал вместе с значением. Иначе SAT покажет красивую матрицу, а в архиве будут два «operator» без адреса.
Сессии: веб отвалился, панель жива
Асимметрия сессий - отдельный источник сюрпризов, даже когда гонку уставок закрыли.
TargetVisu не спрашивает cookie. Смена отошла, экран открыт, роль активна. Это риск локальный: проходящий может ткнуть. Его закрывают таймаутом подсветки, PIN при возврате, либо принимают как политику «у машины экран живой».
WebVisu отваливается по idle, по прокси, по смене IP Wi-Fi. Оператор на обходе думает, что «меня выкинуло, значит я ничего не пишу». Последний успешный POST уже в ПЛК. Регламент: после разлогина смотреть значение на панели или дождаться обновления кадра, не считать разлогин откатом.
Две веб-сессии под одним логином. Кто-то не вышел в диспетчерской, кто-то вошёл у себя. Политика «один логин - одна сессия» либо явный запрет параллели. Иначе журнал врёт: одно имя, две руки.
Сессия наладчика в браузере переживает смену. Утром оператор видит сервисный кадр, оставленный вкладкой. Права наладчика не должны переживать без повторного входа, и сервисные экраны не должны быть доступны по прямой ссылке без роли.
Keep-alive веб-клиента, если его включают «чтобы не выкидывало», удлиняет окно, в котором забытый ноутбук продолжает быть писателем. Для обхода это удобно. Для split-brain - вредно. Таймаут пишут под задачу: пост у агрегата - длиннее; домашний просмотр тренда - короче и строго read-only.
Нагрузка: второй клиент ест тот же цикл
Визуализация на панельном контроллере - не бесплатный зритель. Задача отрисовки, обмен с тегами, для WebVisu ещё HTTP/WebSocket и кодирование кадров, делят CPU с задачей IEC. Один TargetVisu уже заложен в расчёт. Каждый браузер добавляет подписки и перерисовку.
Симптомы, которые сваливают на «глючный ПЛК»: рост jitter цикла при открытии второго клиента; подёргивание локального экрана, когда в диспетчерской открыли тяжёлую мнемосхему; редкий watchdog при трёх WebVisu и тренде на том же устройстве. Это не гонка уставки, но тот же корень: один runtime, много глаз.
Что делать в рамках этой темы, не превращая текст в разбор бюджета GPU. Ограничить число одновременных веб-клиентов в runtime. Не отдавать полный кадр линии на каждый обход: обходной кадр легче, без лишних трендов. Тяжёлую историю и отчёты не держать на контроллере. Приёмка: замерить цикл с одним TargetVisu, затем с TargetVisu + 1 WebVisu, затем с пределом клиентов. Если на пределе цикл не лезет в ТЗ - лимит клиентов в регламент и в настройки, не «потом оптимизируем картинку».
Приоритет задач оставляют за управлением. Визуализация не должна быть равной по приоритету задаче, которая закрывает клапаны. Если веб-клиент начинает тормозить - это лучше, чем сорванный цикл. Смена должна знать: «браузер подтупил» не равно «автоматика умерла». Локальный экран при живом цикле остаётся источником правды по состоянию, даже если страница в Chrome замерла.
Онлайн с force и записью с двух клиентов одновременно на FAT лучше запретить сценарием: один писатель. Иначе приёмка сама создаёт гонку и списывает её на стенд.
Регламент смены: что написать, чтобы код не остался сиротой
Код без текста смены не работает. Текст без кода - тоже. Минимальный лист, который кладут рядом с инструкцией оператора.
В режиме производства хозяин SP - местный оператор на TargetVisu, ключ LOCAL. WebVisu смены и технолога - просмотр. Исключения (дистанционный пост) - только при ключе REMOTE и именном входе.
Смена ключа / бита владельца - событие в журнале: кто, когда, с какого клиента.
Запрещено держать WebVisu с правом записи на незаблокированном ПК диспетчерской «чтобы быстрее».
Наладчик не работает в полях смены под своей ролью во время выпуска, кроме заявки. Сервисный вход отзывается.
При расхождении числа на панели и в браузере истинным для контура считается значение в программе (оно же должно быть на TargetVisu после цикла обновления). Браузер мог показать кэш. Сначала панель, потом спор.
Конец смены: веб-сессии закрыть, не оставлять вкладки. Локальный экран - кадр обзора, не сервис.
Разбор инцидента: выгрузка журнала визуализации и, если есть, тренд SP с меткой клиента. Без метки клиента разбор - фольклор.
Журнал оператора, force и «кто ткнул» на объекте уже имеют свою дисциплину отладки HMI; её не заменяет надежда, что WebVisu «сам подпишется». Практика журнала и force - в материале про отладку HMI. Для двух клиентов в журнал добавляют поле источника: TargetVisu / WebVisu / ID сессии.
Иерархия кадров остаётся в силе: аварии и уставки не прячут на третьем уровне, где их найдёт только тот, у кого открыт браузер. Локальный кадр у машины должен уметь то, без чего нельзя остановить вред. Веб не обязан дублировать всё, но не должен давать «секретную» запись SP, которой нет на двери. База по экранам - иерархия HMI.
Таблица: сценарий, кто побеждает, как закрыть в проекте
| Сценарий | Кто побеждает без защиты | Как закрыть в проекте |
|---|---|---|
| Панель и браузер пишут одно поле SP в соседних циклах | Last write wins, обычно веб, если кадр панели ещё не обновился | Ключ LOCAL/REMOTE или единственный владелец; поля SP read-only у «не хозяина» |
| Диспетчер меняет SP ночью, смена работает «только с двери» | Диспетчер, инструкция не в коде | Запрет записи WebVisu в LOCAL; журнал источника; регламент совпадает с ключом |
| Два браузера плюс TargetVisu, один логин | Непредсказуемо, журнал врёт | Один логин - одна сессия; именные учётки; лимит клиентов |
| WebVisu разлогинило через час, уставка уже записана | Значение в ПЛК остаётся; оператор думает, что откатался | Разлогин ≠ откат; после сессии сверять SP на панели; таймаут не маскирует запись |
| Наладчик в WebVisu и оператор на TargetVisu в одном поле | Наладчик, если права шире | Роль наладчика не пишет рабочие SP во время выпуска; отдельные сервисные кадры |
| Забытая вкладка WebVisu на ПК поста | Вкладка, когда кто-то шевельнёт поле или скрипт обновит запись | Idle timeout; запрет записи с общих ПК; авто-read-only |
| Тяжёлая мнемосхема в трёх браузерах, цикл плывёт | Не уставка, а jitter / watchdog; «побеждает» нагрузка | Лимит WebVisu; лёгкий обходной кадр; замер цикла на FAT с клиентами |
| Расхождение числа на стекле и в Chrome | Программа (и TargetVisu после обновления); браузер может кэшировать | Источник истины - переменная ПЛК; кнопка «обновить»; не спорить по скрину |
| Квитирование аварии с двух клиентов сразу | Оба могут снять отображение, первопричина жива | Квитирование с журналом клиента; сброс аварии - отдельное право, не дублировать «с любого экрана» без роли |
| Команда пуска с панели и стоп с веба в одном цикле | Последняя команда; возможен двойной фронт | Команды через FB с приоритетом стопа; не два независимых бита пуск/стоп без арбитра |
Таблица - заготовка протокола SAT: каждый сценарий либо воспроизводят на стенде, либо вычёркивают как «недоступно правами». Вычеркнуть словами нельзя.
Типовые ошибки
Включить WebVisu «для удобства технолога» с теми же правами, что у панели. Получаете второго оператора без рабочего места у машины.
Считать локальный экран главным по умолчанию. Runtime так не считает.
Закрыть гонку надписью на мнемосхеме. Надпись не пишет в VAR.
Общий логин на TargetVisu и WebVisu. Журнал бесполезен, разбор ночной уставки невозможен.
Не замерить цикл с веб-клиентами на FAT. На объекте «внезапно» растёт задача visu.
Keep-alive веб-сессии «чтобы не надоедало» на клиенте с правом записи. Забытый ноутбук остаётся писателем.
Путать тему с заменой панели планшетом. Можно оставить дверь и всё равно получить split-brain через браузер.
Отдать квитирование и сброс защит в WebVisu без роли. Удобство диспетчера против дисциплины смены.
Вопросы при работе
Можно ли оставить WebVisu только для просмотра и не трогать проект блокировок?
Да, если право записи на SP, режимы и сброс аварий с веба выключено ролью, а не «мы договорились». Просмотр тоже нагружает CPU - лимит клиентов всё равно нужен.
TargetVisu и WebVisu показывают разные числа. Кто врёт?
Смотрите переменную в online. Панель обычно ближе к образу. Браузер имеет кэш, задержку WebSocket и отвалившуюся сессию. Не крутите SP, пока не сверите источник.
Нужен ли отдельный пользователь «веб-технолог»?
Нужен, если этому человеку нельзя то, что можно смене у машины. Один operator на оба клиента - отказ от матрицы.
Что делать на пуске, когда наладчику нужен и экран, и ноутбук?
Явный режим сервиса: один писатель, второй смотрит. Запись в протокол. После SAT сервисный вход сузить.
WebVisu обязательно, если есть TargetVisu?
Нет. Веб включают по задаче обхода и поста, не «потому что в runtime галочка есть». Каждая галочка - клиент и риск записи.
Как понять, что гонка уже была?
Ступеньки SP без совпадения с журналом панели; жалобы «само сбросилось»; два события записи с разных ClientId в одну секунду. Без ClientId в журнале остаётся догадка.
Обсуждение