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