Управление и автоматизация

Тут видик по Адаптивным ПИД. Напишите в комментариях, если нужен исходник

Тут видик по корреляции. Напишите в комментариях, если нужен исходник

Доступны комментарии🫡

Оркестратор модульной системы поддержки принятия решений для промышленных объектов

Кратко:
Современные промышленные предприятия тонут в данных (ПЛК, датчики, состояние оборудования). Для их обработки используют системы поддержки принятия решений (СППР). Однако классические многомодульные СППР часто страдают от «раздутости»: для одного завода нужны прогнозы и графики, а для другого - поиск аномалий и корреляций.
Суть:
Предлагается добавить в архитектуру оркестратор - главный управляющий модуль. Его задача - динамически подключать, отключать, перезапускать и мониторить только те аналитические модули, которые действительно нужны предприятию в данный момент.
Техническая реализация:
Модули предлагается упаковывать в контейнеры (Docker/Podman) и управлять ими через системы оркестрации (Kubernetes). Это обеспечивает:
— Гибкость (легко добавить/удалить модуль);
— Отказоустойчивость (автоперезапуск при сбоях);
— Масштабируемость;
— Быстрое внедрение на любом производстве.
Состав модулей (пример):
Визуализация (графики, дашборды).
Выявление корреляций между параметрами.
Прогнозирование временных рядов.
Обнаружение аномалий (отклонений от нормы).
Главный вывод:
Предложенная архитектура с оркестратором повышает надежность, снижает сложность управления сервисами и позволяет быстро адаптировать СППР под нужды конкретного промышленного объекта.
__
Подробнее тут:
https://www.elibrary.ru/item.asp?id=89348138

Ссылка для цитирования:

Ждамирова, Е. В. Оркестратор модульной системы поддержки принятия решений для промышленных объектов / Е. В. Ждамирова, В. С. Олейников // Неделя науки ИКНК : Материалы Всероссийской научно-практической конференции, Санкт-Петербург, 01–20 апреля 2026 года. – Санкт-Петербург: ПОЛИТЕХ-ПРЕСС, 2026. – С. 301-303. – EDN CASKIM.

В промышленности растет внедрение методов искусственного интеллекта в системы управления технологическими процессами. По данным на 2026 год, ИИ-зрение используется в 41% случаев (контроль качества), ИИ-программирование – в 35% (генерация кода), аддитивные технологии – в 22%, облачные вычисления – в 19%.
Одновременно с этим количество кибератак на компоненты ИИ увеличилось вдвое по сравнению с предыдущим годом. Промышленность остается основной мишенью – 27,7% всех атак направлены на нее. В отличие от IT-сектора, где последствия ограничиваются утечкой данных, в промышленности атаки могут приводить к выходу оборудования из строя и угрозе жизни персонала.
Рассмотрены два основных типа атак за последнее десятилетие:
- Отравление данных – внесение или изменение данных в обучающей выборке. Модель машинного обучения усваивает неверные решения, что приводит к ошибкам прогнозирования, например, пропуску критических состояний оборудования или неверной оценке брака системой технического зрения.
- Состязательные атаки – воздействие на модель на этапе эксплуатации путем подачи специально модифицированных входных примеров. Методы включают атаку одним пикселем, метод быстрого градиентного знака (FGSM) и атаку на основе матрицы Якобиана (JSMA). Изменения, незаметные для человека, вызывают ошибочную классификацию модели.
Последствия таких атак в промышленности – выход оборудования из строя, блокировка аварийного отключения, травмирование персонала (например, при ошибке системы зрения робота).
Традиционные средства безопасности неэффективны против данных угроз. Предлагается комплексный подход, включающий адаптивный мониторинг (непрерывный сбор данных о состоянии модели для выявления атак) и методологию MLSecOps, которая обеспечивает защиту данных на всех этапах жизненного цикла, в отличие от DevOps, ориентированного только на код.
Этапы защиты:
- Сбор данных – фильтрация выборок алгоритмами обнаружения аномалий для предотвращения отравления.
- Разработка – включение состязательных примеров в обучающую выборку для повышения устойчивости, регулярное тестирование моделей на устойчивость к атакам.
- Эксплуатация – адаптивный мониторинг поведения модели, при обнаружении аномалий – принудительное вмешательство оператора и откат модели до предыдущей версии.
Вывод: внедрение ИИ в промышленность создает новые угрозы (отравление данных, состязательные атаки), последствия которых критичны для оборудования и безопасности людей. Обеспечить безопасную работу ИИ-систем способен только комбинационный подход – адаптивный мониторинг плюс защита на всех этапах через MLSecOps.
___
Подробнее тут: https://www.elibrary.ru/item.asp?id=89348165
_
АТАКИ НА СИСТЕМЫ ИСКУССТВЕННОГО ИНТЕЛЛЕКТА В ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ
Чуркина К.С., Олейников В.С.
В сборнике: Неделя науки ИКНК. Материалы Всероссийской научно-практической конференции. Санкт-Петербург, 2026. С. 332-333.

АДАПТИВНЫЙ ПИД-РЕГУЛЯТОР НА НЕЧЁТКОЙ ЛОГИКЕ
__
Мы рассматрели возможность использования нечёткой логики для адаптации коэффициентов ПИД-регулятора, управляющего линейным объектом - апериодическим звеном первого порядка.
Классические настройки регулятора, выполненные, например, методом Зиглера–Николса, рассчитаны на фиксированные параметры объекта. ❗Однако на практике коэффициент усиления или постоянная времени могут изменяться, что ухудшает качество регулирования.
Решением может стать адаптивный регулятор, в котором пропорциональная, интегральная и дифференциальная составляющие корректируются в реальном времени с помощью блока нечёткой логики.
❗Для проверки этой идеи в среде Simulink были собраны две системы: с обычным ПИД-регулятором и с гибридным, где базовые коэффициенты (настроенные по классике) умножаются на поправки, вычисляемые нечётким контроллером. Входными переменными для нечёткого регулятора служат ошибка регулирования и её производная, а выходными - масштабирующие коэффициенты для KpKp​, KiKi​ и KdKd​. База правил составлена на основе типовых инженерных соображений: при большой ошибке нужно увеличить пропорциональную составляющую и временно ослабить интегральную, при большой производной — уменьшить дифференцирование и так далее.
После оптимизации вспомогательных коэффициентов усиления (ke, kde и других) гибридная система показала заметно лучшее быстродействие. Например, при критическом коэффициенте усиления объекта, равном 8,5, переходный процесс в системе с нечёткой адаптацией устанавливался за 0,6 секунды против 1,27 секунды у классического ПИД-регулятора. нием параметров объекта. Когда коэффициент усиления увеличивали с 3 до 10 и даже до 17, адаптивный регулятор продолжал уверенно отрабатывать сигнал, тогда как классический ПИД начинал давать значительные колебания или слишком долгий переходный процесс. В то же время, если менялась не столько величина усиления, сколько постоянная времени объекта, оба регулятора начинали работать хуже, а при появлении случайных помех их поведение становилось почти одинаковым.
На линейных объектах преимущества нечёткого адаптивного ПИД-регулятора не являются революционными. Однако система становится заметно более робастной к изменениям коэффициента усиления, а значит, такой подход вполне оправдан там, где параметры заведомо «плывут» во времени. А вот по-настоящему раскрыться нечёткая логика должна на нелинейных объектах.
______
Подробнее тут: https://www.elibrary.ru/item.asp?id=50520618
______
Если пишите свои статьи на похожую тему, сошлитесь на нас:
_
Олейников В. С., Жиракова П. С. Адаптация коэффициентов ПИД-регулятора, управляющего объектом с переменным коэффициентом усиления // Наукосфера. – 2023. – № 3 (2). – С. 204–214. – ISSN 2542-0402.

Товарищи, оставляйте реакции, а то не понятно, интересно или нет

Методология CI/CD и особенности ее применения в промышленной автоматизации
(4 часть из 4)

Препятствия и перспективы такого внедрения
Т.к. способ автоматизации выгрузки ПО не протестирован на практике, стоит учесть все риски и угрозы такой реализации.
Первой же проблемой является тот факт, что не все виртуальные ПЛК соответствуют стандарту O-PAS, и подойдут лишь определенные модели. Также для экономии средств можно выбрать бесплатные open-source модели виртуальных ПЛК, что существенно сократит расходы.
Для безопасности, при написании содержания пайплайна необходимо продумать, где могут возникать уязвимости при автоматическом развертывании, из-за чего возникнет риск кибератак и кражи данных. Т.к. нахождение системы управления в собственной локальной сети не гарантирует полную защиту, кибербезопасность требует особого внимания, особенно для такой системы управления, как кустовая нефтедобывающая площадка.
Устойчивость и стабильность сети также является важным фактором, реализация которой может быть дорогостоящей в виду территориального размещения кустовой площадки. Стоит также упомянуть, что созданный пайплайн должен гарантированно корректно разворачивать ПО на виртуальных машинах без потери данных, иначе длительная остановка процесса системы управления может повлечь финансовые убытки.
Однако, если учесть все препятствия и уделить должное внимание для их решения, перспективы данного внедрения могут значительно сократить время на развертывание ПО, ведь ручное обновление оператором для каждого объекта управления требует в несколько раз большего количества времени. Существенно упростится добавление новых объектов (например, еще одного сепаратора или печи), ведь кластеризация виртуальных машин существенно упрощает этот процесс. При этом вся информация хранится на удаленном репозитории на отдельном сервере, что гарантирует безопасность и сохранность данных.

Источник: DOI: 10.1109/ElCon-EE69794.2026.11453271

Методология CI/CD и особенности ее применения в промышленной автоматизации
(3 часть из 4)

Описание архитектуры для развертывания ПО кустовой площадки

Для примера совместного использования стандарта O-PAS и методологии был придуман концепт проекта, активно использующий оба этих инструмента.
Предположим, на некоторой кустовой площадке для нефтедобычи расположены две печи, два сепаратора, кустовая насосная станция (КНС), OPC-сервер и центр принятия решений, расположенный в локальной сети.  Каждый компонент на площадке оснащен собственной виртуальной машиной. Центр принятия решений предназначен для оркестрации CI/CD процессов и хранения ПО в удаленном репозитории. При этом OPC-сервер обеспечивает унифицированный обмен данными между виртуальными машинами и центром принятия решений. Для запуска пайплайна оператор с помощью запроса или любого изменения кода в репозитории запускает предварительно описанный пайплайн, благодаря которому до каждого объекта системы доставляется некоторый пакет ПО, описанный в конвейере. Таким образом, благодаря единоразовому изменению кода, вся система управления получает необходимое программное обеспечение одновременно без временных трат на установку вручную.
Чтобы разобрать процесс доставки ПО более детально, в схеме останется только печь (ее можно заменить любым из 5 компонентов), OPC-сервер, центр принятия решений и панель оператора.
По определению, конвейер автоматически запускается при изменении кода либо при ручном запуске и содержит несколько стадий. Благодаря этому, в одном пайплайне ПО из одного или нескольких репозиториев может тестироваться, собираться и выгружаться на виртуальной машине. В нашем случае, для работы площадки потребуется виртуальный ПЛК, SCADA и система принятия решений (например Python-скрипт), и их сборку легко описать в пайплайне. После сборки программного обеспечения в единый пакет, он отправляется в OPC-сервер, который в свою очередь устанавливает и обновляет пакет ПО на каждой виртуальной машине. После установки на панель оператора через сервер возвращается уведомление о статусе установки, что обеспечивает надежность обратной связи по системе управления.
Описанный способ позволяет оператору автоматически выгружать ПО на кустовую площадку, что существенно сокращает время и трудозатраты. Однако при реализации могут возникнуть сложности, которые необходимо предусмотреть, чтобы максимально устранить риск остановки процесса добычи на кустовой площадке.

Источник: DOI: 10.1109/ElCon-EE69794.2026.11453271

Методология CI/CD и особенности ее применения в промышленной автоматизации
(2 часть из 4)

Методология CI/CD и особенности ее применения в промышленной автоматизации

Перед тем, как приступить к анализу пользы CI/CD для промышленной автоматизации, следует ознакомиться с определением данного понятия, а также разобрать точки соприкосновения методологии и сферы АСУ ТП.
Методология CI/CD, или же Continuous Integration / Continuous Deployment представляет собой набор методов, предназначенных для оптимизации процесса переноса изменений из системы контроля версий в рабочую среду или из релиза в производство. Аббревиатура CI/CD состоит из двух частей: CI, т.е. Continuous Integration, означает непрерывную интеграцию, в то время как CD (Continuous Deployment) необходима для непрерывного деплоя (доставки). Основные цели CI — быстрее находить и устранять ошибки, повышать качество программного обеспечения и сокращать время, необходимое для проверки и выпуска новых обновлений программного обеспечения. CI включает в себя процесс постоянного объединения кода в общий репозиторий, при этом проходящего автоматическую проверку и тестирование, в то время как CD подразумевает автоматическую доставку. Этот процесс реализуется с помощью так называемых конвейеров (или же пайплайнов). В контексте CI/CD пайплайн – набор процессов (автоматизированных), автоматически выполняющихся при любом изменении кода. В пайплайне может быть несколько стадий, например тестирование, деплой или сборка. Способы его описания различаются в зависимости от используемой системы (например, Gitlab CI или Jenkins).
Методология CI/CD находит применение не только в сфере информационных технологий, но и в сфере промышленной автоматизации. Ее использование может значительно облегчить разворачивание ПО (а также виртуальных ПЛК, SCADA-систем и систем принятия решений) на объектах системы управления. При этом из-за использования данного набора практик в сфере автоматизации возникают ограничения по безопасности, а также необходимость использования единого стандарта. Эта необходимость удовлетворяется именно за счет использования стандарта O-PAS (Open Process Automation Standart), который был описан в пункте выше.
Польза применения CI/CD для проектов с ПЛК уже была доказана рядом статей, но она была описана только для физических ПЛК. Данная статья задевает работу именно с open-source виртуальными ПЛК, поэтому могут возникнуть нюансы при использовании описанной методологии. Более подробная информация по развертыванию ПО на ПЛК такого типа описана в пункте «Описание архитектуры для развертывания ПО кустовой площадки»

Источник: DOI: 10.1109/ElCon-EE69794.2026.11453271