В АСУТП разработчику как правило приходится иметь дело с Legacy. Оборудование работает десятилетиями, системы управления стареют вместе с ним. Это не отменяет потребности в периодической модернизации, которая, за давностью времен, прошедших со времени первоначальной установки, зачастую превращается в восхитительный квест. Когда собираются вместе три «Всадника Апокалипсиса» Индастриал-дева: Сименс, Майкрософт и Хьюлетт-Паккард, скучно долго не будет.
Итак, что мы имеем
Предприятие керамической отрасли. Печи, горелки, вентиляторы, перемещающиеся платформы и т. д. Управление технологическим процессом — SCADA-система на базе Siemens WinCC. Четыре контроллера S7-300/400 в заводской сети. Год издания — 2013. Платформа — HP ProLiant DL380p Gen8 + MS Windows Server 2008R2 + Siemens WinCC 7.0
Заказчик не планировал замену железа. Требовалось подняться до максимального официально поддерживаемого уровня софта на том, что есть. Вариации «в принципе как правило нормально встает» не рассматривались ввиду степени ответственности проекта. Исходя из этого верхняя граница миграции была определена как MS Windows Server 2012R2 + Siemens WinCC 7.5SP2Upd15. Шестнадцатый апдейт тоже в принципе был доступен, но он вставал как-то не очень убедительно, и им было решено пожертвовать.
Подготовительную часть задачи — всплытие до MS Windows Server 2012 + Siemens WinCC 7.5 и клонирование полученной системы на два сервера — мы здесь опустим. Она заслуживает отдельного живописания. Начнем сразу с десерта. Итак, имеем два полностью работающих идентичных сервера, отличающихся только сетевыми именами.
Задача
средствами WinCC поднять горячее резервирование (Redundancy) двух серверов SCADA без доменной инфраструктуры — в Workgroup. Подключить клиентскую рабочую станцию с автоматическим переключением между серверами.
В общем, задачка из тех, что не встречаются каждый день. Скажем честно, нам она до этого момента не встретилась ни разу… Так что разбираться пришлось с нуля.
Плюс заключался в том, что задача решалась на стенде, полностью повторяющем конфигурацию установленных на производстве серверов и имеющем при этом коннект с боевыми ПЛК. Поэтому мы экспериментировали смело, полагаясь на бэкапы. И читателю советуем. Помнить о бэкапах в смысле. Мементо мори.
После того, как система заработала на стенде, увидела контроллеры, отработала синхронизацию и т.д., мы перевезли ее на завод. Но обо всем - по порядку.
Конфигурация.
Сервер 1 | Сервер 2 | Клиент | |
|---|---|---|---|
Имя | SCADASERVER1 | SCADASERVER2 | SCADACLIENT0 |
Железо | HP ProLiant DL380p Gen8 | HP ProLiant DL380p Gen8 | HP ProLiant DL380p Gen8 |
ОС | Windows Server 2012 R2 | Windows Server 2012 R2 | Windows Server 2012 R2 |
WinCC | 7.5 SP2 Upd15 | 7.5 SP2 Upd15 | 7.5 SP2 Upd15 (Client) |
SQL Server | 2016 SP3 | 2016 SP3 | 2016 SP3 |
Основная сеть | 192.168.0.1 | 192.168.0.2 | 192.168.0.3 |
Backbone | 10.10.10.1 | 10.10.10.2 | — |
Backbone — выделенная сеть между серверами через отдельные сетевые адаптеры (прямое соединение патч-кордом). По замыслу Сименс она используется для взаимодействия серверов на предмет определения статуса друг друга. Сам процесс репликации данных между SCADA-системами backbone не использует. (Строго говоря, в этой связи он и не является бэкбоном в классическом понимании, но название прижилось). Обмен данными при синхронизации проходит по основной сети. Основная сеть — заводская, в ней также живут контроллеры, клиенты и прочая инфраструктура.
Базовая документация от Siemens по теме — «Redundancy in WinCC V7.x» (ID 109772627) [1]. Мы будем ссылаться на неё, отмечая моменты, где практика разошлась с теорией. Общее представление об архитектурах WinCC (standalone, client/server, redundancy) даёт обзор [2]. Другие полезные для понимания ссылки приведены в конце статьи.
Пойдем степ-бай-степ. Ибо дорогу осилит идущий.
Шаг 1. SIMATIC Shell — настройка связи
Первая же попытка заставить серверы увидеть друг друга обескуражила. Серверы видят ПЛК контроллеры, видят всю сеть, пингуют друг друга, но никак не видят статус друг друга в контексте резервирования. Оказалось, что начиная с версии WinCC 7.5 Remote Communication в SIMATIC Shell по умолчанию… выключена [3]. Нашли, включили.
Далее. В скрижалях Siemens сказано: откройте SIMATIC Shell, выберите сетевой адаптер, включите Remote Communication. Назначьте адрес. Звучит просто.
На практике выяснилось, что в SIMATIC Shell есть два независимых набора настроек:
Settings (он же Terminal Bus) — определяет адаптер для общения с клиентами и другими станциями по основной сети.
Redundancy settings — определяет адаптер для обмена данными между серверами redundancy-пары. То, что мы назвали Backbone.
Это две разные кнопки в контекстном меню SIMATIC Shell, и привязывать их нужно к разным адаптерам:
Terminal Bus → основная сеть (192.168.0.x)
Redundancy → backbone (10.10.10.x)
В доке Siemens это упоминается, но между строк, на уровне «a dynamic or static IP can be assigned both in the WinCC Redundancy Editor and in the SIMATIC Shell redundancy settings». Ничтоже сумняшеси, настраиваем Redundancy settings на адреса бэкбона. Это правильно. Про Terminal Bus не догоняем. Потом нам это аукнется… Но покамест сервера увидели друг друга в SIMATIC Shell! Праздник души! А между тем сказке далеко до развязки…
Шаг 2. DCOM — «Initialization of Remote Communication failed»
Запускаем рантайм и видим, что радоваться рано. В логе WinCC WinCC_Sys_XX.log каждые пять минут:
RedundancyAgent: Initialization of Remote Communication failed
Статус партнёра — «Отключён». Оба сервера считают себя одинокими…
Надо настраивать DCOM
Это оказалось самым веселым.
DCOM (Distributed COM) — это механизм, через который WinCC RedundancyAgent на одном сервере управляет компонентами WinCC на другом. Синхронизация архивов, обмен статусами master/standby, переключение ролей при отказе — всё это DCOM-вызовы между серверами.
В доменной среде эти механизмы работают из коробки: контроллер домена выдаёт обоим серверам Kerberos-токены, на основании которых они доверяют друг другу. В Workgroup контроллера домена нет, и всю цепочку доверия нужно выстроить вручную. Видимо, по этой причине в большинстве случаев народ плюёт и разворачивает домен. То, что нам в конце концов удалось продраться сквозь все рогатки и ловушки, оставаясь в пределах Workgroup, оплачено. Какой ценой? О цене умолчим. Но граблей на этой тропе собралось штук пять.
Грабли первые. Служба WinCC под Administrator
Первый затык. По умолчанию службы WinCC работают под учётной записью LocalSystem. У неё нет сетевой идентичности — при DCOM-вызове к партнёру она не может «представиться». Партнёр не знает, кто к нему стучится, и отказывает в доступе.
Иными словами, служба CCRedundancyAgent-Service должна работать под явной учётной записью, в нашем случае .\Administrator. Открываем утилиту Services:
Win+R → Services.msc → CCRedundancyAgent-Service → Log On → This account → .\Administrator → пароль
Administrator — реальная учётная запись, которая существует на обеих машинах. Не обязательно использовать встроенную учётку, более того, это в известном смысле моветон, но для стендовых испытаний мы не стали сильно мудрить. Тут важно было, чтобы пароли совпадали. И как можно меньше дополнительных неявных факторов. Учетку после перестроить можно, когда все заработает.
Грабли вторые. DCOM Permissions
Следующий шаг: разрешения для Анонима.
Открываем утилиту dcomcnfg:
Win+R → dcomcnfg → Component Services → Computers → My Computer → Properties
Вкладка COM Security: Access Permissions → Edit Limits. Настраиваем:
Пользователь | Local Access | Remote Access |
|---|---|---|
Everyone | Allow | Allow |
ANONYMOUS LOGON | Allow | Allow |
Там же Access Permissions → Edit Default: то же самое. |
Как это работает [5]: первичное DCOM-подключение между машинами в Workgroup проходит анонимно — ещё до того, как стороны обменяются учётными данными. Это как стук в дверь: сначала нужно разрешить подойти к двери и постучать. Вот он, анонимный доступ: кто-то стучит, а кто - не знаем. Если ANONYMOUS LOGON не имеет Remote Access — стук не раздастся, и до проверки документов (в нашем случае пароля) дело вообще не дойдёт.
“Вот теперь представьтесь”: Launch and Activation Permissions → Edit Limits:
Пользователь | Local Launch | Remote Launch | Local Activation | Remote Activation |
|---|---|---|---|---|
Administrators | Allow | Allow | Allow | Allow |
Everyone | Allow | Allow | Allow | Allow |
ANONYMOUS LOGON | Allow | Allow | Allow | Allow |
Launch — право запустить COM-объект. Activation — право активировать уже зарегистрированный. RedundancyAgent на S1 говорит S2: «запусти мне такой-то COM-компонент WinCC». Без явного разрешения он получит отказ, даже если Access Permissions уже настроены. Это второй уровень защиты: сначала разрешили подойти к двери и постучать, теперь разрешаем войти.
Launch and Activation Permissions → Edit Default:
Пользователь | Local Launch | Remote Launch | Local Activation | Remote Activation |
|---|---|---|---|---|
SYSTEM | Allow | Allow | Allow | Allow |
Administrators | Allow | Allow | Allow | Allow |
Administrator | Allow | Allow | Allow | Allow |
Здесь выяснился еще один нюанс: необходимо добавить конкретного пользователя Administrator (не только группу Administrators). В Workgroup при удалённом вызове Windows может не раскрыть членство в группе, а вот конкретную учётку проверит обязательно. В конечном итоге очень помогли разобраться с настройками DCom [6] и [7].
Грабли третьи. Default Properties
Едем дальше. Это еще далеко не все. В той же оснастке dcomcnfg, вкладка Default Properties:
Enable Distributed COM on this computer: проверяем, чтобы было. Обычно стоит по умолчанию, но иногда слетает. Это главное.
Default Authentication Level: Connect. Означает. что аутентификация происходит один раз при установлении соединения, а не при каждом вызове. Для redundancy этого достаточно. В принципе, будет работать и без этого… А может и не будет. Не проверяли. Вообще, надо сказать, не исключено, что кое-где мы прошли не самым простым путем… Возможно, найдутся эксперты, которые смогут этот путь оптимизировать. Но мы ставили перед собой практическую задачу, а не исследовательскую. Получилось так, как получилось.
Default Impersonation Level: Identify. Аналогично.
Грабли четвертые. LocalAccountTokenFilterPolicy
Очередной барьер. UAC в Windows Server 2012 R2 по умолчанию «урезает» токен локального администратора при удалённом входе. Даже если DCOM-вызов приходит от правильной учетки с правильным паролем, он получает токен обычного пользователя. Прав на запуск COM-объектов у него нет. Соответственно, опять ничего не работает.
Такое поведение по умолчанию — защита от удалённой эксплуатации учётных записей [8]. В доменной среде это не проблема: доменные аккаунты не фильтруются, но в Workgroup это напрочь блокирует DCOM-вызовы.
Грубо отключаем фильтрацию в PowerShell:
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" ` -Name "LocalAccountTokenFilterPolicy" -Value 1 -PropertyType DWORD -Force
Это, как и все предыдущие манипуляции, надо выполнить на обоих серверах. Перезагрузка не требуется, но рантайм WinCC придется в очередной раз перезапустить.
Грабли пятые. Разрешение имён: hosts
DCOM обращается к партнёру по имени компьютера, не по IP-адресу [9]. Когда RedundancyAgent на S1 инициирует вызов к S2, он использует имя SCADASERVER2. Windows должна преобразовать это имя в IP-адрес.
В доменной среде за это отвечает DNS-сервер. В Workgroup его нет, и Windows решает проблему с помощью старинных широковещательных запросов NetBIOS. И это ужасно. Потому, что:
Широковещательные запросы работают только в пределах одной подсети. Плохо, но терпимо.
Оно работает ненадёжно и медленно. Тоже плохо.
А самое главное — мы хотим, чтобы имя партнёра разрешалось в адрес backbone, а не в адрес основной сети.
Если Windows разрешит SCADASERVER2 в 192.168.0.2 (а NetBIOS так и поступит, если не принять меры) — DCOM-трафик redundancy пойдёт через заводскую сеть вместе со всем остальным трафиком. Казалось бы, и что такого? Однако, если основная сеть для одного из серверов окажется недоступной — redundancy ляжет вместе с ней, и весь его смысл потеряется.
Решение есть. В явном виде прописываем в C:\Windows\System32\drivers\etc\hosts на каждом сервере имя партнёра с IP-адресом backbone:
На SCADASERVER1: 10.10.10.2 SCADASERVER2 ScadaServer2 На SCADASERVER2: 10.10.10.1 SCADASERVER1 ScadaServer1
Файл hosts имеет приоритет над любыми другими способами разрешения имён. Теперь при DCOM-вызове к партнёру Windows даже не будет пытаться искать его через NetBIOS — сразу возьмёт адрес backbone из hosts.
Для клиентской станции все проще — клиент подключается через основную сеть. Как мы понимаем, к бэкбону он даже физического доступа не имеет.
На SCADACLIENT0 (клиент): 192.168.0.1 SCADASERVER1 ScadaServer1 192.168.0.2 SCADASERVER2 ScadaServer2
Чтобы не получать этими граблями вновь и вновь, записи в hosts нужно обновлять при любой смене IP-адресов. Это ручная операция, и о ней легко забыть. Если после смены адресов redundancy перестал работать — проверяйте hosts в первую очередь.
Проверка
Грабли второго шага закончились! Теперь - быстрый тест — с одного сервера к другому. На SCADASERVER1 проверяем доступ к SCADASERVER2:
Get-WmiObject -Class Win32_OperatingSystem -ComputerName SCADASERVER2
Если команда возвращает информацию об ОС партнёра — вся цепочка DCOM работает: анонимный доступ → аутентификация → запуск COM-объекта → результат. Если Access Denied — один из звеньев цепочки разорван, надо проверять по шагам все настройки.
Обратный тест с SCADASERVER2 на SCADASERVER1 будет выглядеть зеркально:
Get-WmiObject -Class Win32_OperatingSystem -ComputerName SCADASERVER1
Результат всех наших шишек: после перезапуска рантайма — один сервер стал Master, второй Standby. Redundancy заработал!
Шаг 3. PSK и SecureCommunication — еще один невидимый барьер
Redundancy на стенде заработал, но о клиенте мы пока даже не вспоминали. Серверы видят друг друга, роли распределились, синхронизация идёт. При этом SecureCommunication в SIMATIC Shell по умолчанию отключена — галка «Verschlüsselte Kommunikation» снята. Backbone это не волнует: два сервера в изолированной сети, других станций нет, SCS discovery находит партнёра безо всяких паролей.
Переходим к клиенту — и упираемся в стену. Клиентская станция C0 подключена к основной сети, в которой живут контроллеры, старые SCADA-станции и прочая инфраструктура. WinCC Explorer на клиенте видит содержимое серверных папок, предлагает выбрать стартовый экран — но при запуске рантайма: «Невозможно найти стартовый экран». Мозг взрывается: вот же он, в списке, я его только что выбрал!
В конце концов все тайное становится явным. Главное - правильно выбрать бубен. Вот он, бумеранг, прилетевший из шага 1! Причина оказалась в том, что Terminal Bus в SIMATIC Shell на клиенте не был привязан к адаптеру основной сети. Без этого клиент может обращаться к сетевым папкам серверов (это обычный SMB), но защищённый канал WinCC — SCS (SIMATIC Communication Service) — не работает [10]. А рантайму нужен именно он.
Настроили Terminal Bus — клиент по-прежнему не подключается. Серверы его не видят, он не видит серверов. И тут мы добрались до PSK.
Грабли очередные. Pre-Shared Key — фильтр, а не шифрование
В SIMATIC Shell есть кнопка Festlegen (да, реально на немецком, несмотря на все language packs). Она задаёт Pre-Shared Key — пароль, по которому станции опознают «своих». PSK в данном случае - это не про шифрование трафика. Это про фильтрацию: станции с одинаковым PSK образуют группу и видят только друг друга через SCS discovery.
На backbone это было некритично — там двое, не запутаешься. А вот в основной сети без PSK клиент свои сервера не распознает.
Задали одинаковый PSK на всех трёх станциях, включили SecureCommunication — клиент мгновенно подключился. На стенде всё заработало.
Шаг 4. Переезд на завод. Грабли не заканчиваются.
Сетевой профиль — тихий убийца DCOM
Ура! Система работает, пора выдвигаться к заказчику. Перевозим серверы на предприятие, настраиваем по месту IP-адреса основной сети… Снова «Initialization of Remote Communication failed». Redundancy отвалился.
Первый сюрприз при переезде на завод, нигде не описанный и никем не предсказанный. Windows Server 2012 R2 при смене IP-адреса автоматически переключает профиль сетевого подключения на Public. Параноя.
В профиле Public:
DCOM-вызовы блокируются
SMB-доступ ограничен
Многие правила файрвола неактивны
Проверяем:
Get-NetConnectionProfile
Если NetworkCategory = Public — нужно исправить:
Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private Set-NetConnectionProfile -InterfaceAlias "Ethernet 2" -NetworkCategory Private
Это нужно сделать для обоих адаптеров (основная сеть и backbone) на обоих серверах.
Артефакт SecureCommunication
Исправили профили. Снова «Initialization of Remote Communication failed».
Профили Private. Файрвол выключен. DCOM настроен. Hosts обновлены. Пинг по backbone ходит. Галка SecureCommunication стоит, PSK задан. Станции видят друг друга в SIMATIC Shell. С виду всё нормально — но ничего не работает. Серверы не видят друг друга, клиент не видит стартовую страницу.
Поменяли PSK — не помогло. Да что за наваждение!
И только когда по какому-то наитию мы сняли галку SecureCommunication — серверы мгновенно увидели друг друга. Клиент, понятное дело, нет. И лишь после того, как мы заново задали PSK на всех трёх станциях, включили SecureCommunication обратно — всё заработало.
Что это было?
По нашей версии, при смене IP-адресов служба SecureCommunication перешла в коматозное состояние. Внутренние привязки SCS (MAC-адрес, IP в реестре) устарели, но система не выдала ни одной ошибки — просто молча перестала работать. И вот что особо коварно: backbone тоже перестал работать, хотя его IP не менялся. SecureCommunication, как оказалось, — это глобальный параметр службы, а не просто настройка адаптера. Если служба в смятении, то и backbone не работает.
Отсюда родилось Золотое правило SIMATIC Shell: при любой смене IP-адресов — сбросить SecureCommunication (снять галку), затем заново задать PSK и после этого включить галку обратно. Орднунг юбер аллес.
Шаг 5. Клиент — «Переменная не определена»
Redundancy между серверами работает. Переходим к клиенту. Создаём Client Project, загружаем Server Data (.pck файл, сгенерённый на одном из серверов), запускаем рантайм. Поначалу все попытки запустить проект на клиенте оканчивались сообщением «Невозможно найти стартовый экран». Только когда мы разобрались с настройкой терминальных интерфейсов, проект на клиенте запустился. Теперь понятно, почему: для работы рантайма на клиенте нужен защищённый канал. А показать содержимое сетевых папок он может и без этого.
И вот, наконец, картинки отображаются, теги читаются — вроде всё хорошо.
Но при нажатии на чекбокс тренда в окне с отображением графиков — ничего не происходит. Ни линии на графике, ни ошибки.
Отладка, сэр
Добавляем в обработчик чекбокса:
On Error Resume Next Call CheckTrandClick(...) MsgBox "After call, err=" & Err.Number & " " & Err.Description
Результат: err=500 «Переменная не определена».
Скрипт CheckTrandClick — это Project Module, определённый на сервере. На клиенте его нет. VBScript интерпретирует вызов несуществующей процедуры как обращение к неопределённой переменной.
Решение. Если ничего не получается, прочитайте, наконец, инструкцию.
В документации Siemens написано: «It is necessary to copy the scripts from the Server Project into the corresponding folders of the Client Project» [11]. Мы это недооценили.
Копируем папку ScriptLib из серверного проекта в клиентский:
copy \\SCADASERVER1\D$\WinCC_Project\ScriptLib\* D:\WinCC_Client\ScriptLib\
После перезапуска рантайма — все тренды заработали сразу. Без каких-либо префиксов или дополнительных настроек. WinCC Client автоматически подставляет серверный префикс для архивных тегов того сервера, с которым в данный момент работает. Клиент полностью функционален, тренды рисуются.
Шаг 6. Момент истины
Самая волнительная проверка: выключаем Master-сервер и смотрим, что происходит на клиенте.
Тест 1: отключение Master (S1)
Останавливаем рантайм на S1. Клиент моментально переключается на S2. Никакого провала в трендах. Данные продолжают поступать. Навигация работает. Оператор, не глядя на статусную панель, не заметит переключения.
Тест 2: холодный старт клиента без Master
S1 для клиента — предпочтительный сервер. Поступаем сурово: выключаем рантайм клиента, выключаем S1 полностью. S2 включён. Запускаем рантайм на клиенте с нуля. Клиент успешно подключается к S2 (ставшему Master, как только он остался в одиночестве) и работает штатно.
Это было ключевым требованием: клиент должен работать при любой комбинации доступных серверов.
Тест 3: восстановление Master
Поднимаем S1. Он стартует как Standby, получает синхронизацию от текущего Master (S2). После завершения синхронизации — система полностью восстановлена, оба сервера в строю. Однако клиент по-прежнему подключён к S2, который по-прежнему остаётся Мастером: система не делает ненужных переключений. Аналогичное поведение при синхронизации архивов описано в [12]. Выключаем S2. Клиент мгновенно переключается на S1, который мгновенно становится Мастером.
Результат: реально бесшовный failover в обе стороны!
О задержке синхронизации
Стоит отметить и ещё одно обстоятельство, которое нас поначалу немало озадачило. Клиент действительно переключается между серверами мгновенно. А вот синхронизация между Мастером и Standby отнюдь не спешит. Это было очень неприятно в первый раз: синхронизация не работает! Всё пропало, шеф! Минут через пятнадцать она сработала, и жить сразу стало легче. Позже мы нашли упоминание в скрижалях о том, что время срабатывания синхронизации в норме может составлять от 10 до 20 минут [1]. Таким образом Siemens интегрирует мелкую морось, которая может возникать на производстве с сетями, питанием и т. п. Синхронизация — процесс сложный, его легко запутать, если часто дёргать туда-сюда. Сименс в документации в явном виде рекомендует отключать резервирование на время проведения профилактических работ, пуско-наладки и прочей суеты. Именно с целью “не мельтешить” система делает выдержку перед тем, как запустить процесс синхронизации: если были какие-то сбои: пусть уже всё, наконец, восстановится, а уж потом я буду выравнивать… В принципе, логично.
Итоги: что нужно знать, но негде прочитать
Вот список вещей, на которые мы потратили больше всего времени и которые не описаны (или описаны недостаточно) в документации Siemens. Практические вопросы по настройке redundancy обсуждаются на форумах [13], но системного описания всех подводных камней мы не нашли нигде:
# | Проблема | Симптом | Решение |
|---|---|---|---|
1 | SIMATIC Shell: два набора настроек | Серверы не видят друг друга | Terminal Bus → основная сеть, Redundancy → backbone |
2 | Служба под LocalSystem | «Remote Communication failed» | CCRedundancyAgent-Service → .\Administrator |
3 | PSK не задан | Клиентские станции не обнаруживаются | Festlegen с одинаковым паролем на всех станциях |
4 | SecureCommunication при смене IP | Всё выглядит правильно, но не работает | Снять галку → задать PSK заново → включить обратно |
6 | Public network profile | DCOM блокируется | Set-NetConnectionProfile → Private |
7 | ScriptLib не скопирован | err=500 на клиенте | Копировать ScriptLib с сервера в клиентский проект |
Также будет справедливым отметить, что большинство затыков решались-таки методом поиска соответствующей информации в соответствующем руководстве. Это хорошо и правильно. Поэтому в завершении - список нарытых в ходе проекта скрижалей.
Интересная была задачка. Как раз как мы любим.
Ссылки и источники
Redundancy in WinCC V7.x and WinCC Professional (ID 109772627) — основной документ по настройке redundancy.
WinCC V7.5 SP1 Architectures — обзор архитектур WinCC: standalone, client/server, redundancy.
WinCC v7.5 — Simatic Shell (Siemens Forum) — проблемы с обнаружением станций, настройка Remote Communication.
Network Adapter SCS (Siemens Forum) — привязка SCS к сетевому адаптеру, проблемы с несколькими адаптерами.
DCOM: Machine Access Restrictions (Microsoft Learn) — настройка DCOM Access/Launch Permissions, разница между Limits и Default.
Setting up a DCOM connection for WMI on host machines — пошаговое руководство по настройке DCOM для удалённого доступа.
DCOM Configuration on Windows Server 2012/2019/2022 — наглядное руководство с скриншотами по настройке dcomcnfg.
Windows Remote UAC — LocalAccountTokenFilterPolicy — зачем нужен LocalAccountTokenFilterPolicy и как UAC фильтрует токены в Workgroup.
Requirements for WinCC in Distributed Systems — требования к распределённым системам WinCC: сетевая конфигурация, порты, firewall.
Tosibox & Connecting to WinCC — сетевые требования SCS и Multicast.
SIMATIC HMI WinCC V7.4 Configurations — System Manual — Client Project, Server Data, Package (.pck), Graphics Runtime.
Redundancy in WinCC + Process Historian Connection (DMC) — кейс по настройке redundancy с Process Historian, наблюдения про синхронизацию архивов.
Redundancy Configuration in WinCC (control.com) — практические вопросы и ответы по настройке redundancy.
Application of WinCC Redundant System in Production Line — академическая статья о применении WinCC Redundancy на производстве.
Юрий Климов ака Иван Бернар. Тимлид ООО *Инфрасеть, 2026.
