Для начала проведем небольшой анализ архитектурных подходов в системах АСУТП: от проприетарных SCADA к унифицированным стандартам OPC UA.
В сфере промышленной автоматизации (АСУТП) традиционный подход к выбору систем верхнего уровня управления, таких как SCADA (Supervisory Control And Data Acquisition), зачастую сводится к выбору решений, предлагаемых производителями аппаратных контроллеров. Типичная практика включает использование следующих проприетарных платформ:
Siemens: SIMATIC WinCC
Wonderware: InTouch
Schneider Electric: EcoStruxure
И другие аналогичные решения включая совсем не дешевые российские разработки.
На этапе проектирования, фокус нередко смещается на обеспечение функциональности сбора данных, в то время как вопросы последующей обработки, анализа и использования этой информации зачастую остаются без должного внимания.
Несмотря на широкое распространение, проприетарные SCADA-системы обладают рядом существенных ограничений, которые снижают их применимость по сравнению с более гибкими решениями, такими как ручное заполнение форм Microsoft Excel (в контексте аналитики и отчетности):
Высокая стоимость лицензирования программного обеспечения.
Значительные затраты и длительные сроки разработки "под ключ", включая конфигурирование, программирование и интеграцию.
Избыточный объем встроенных компонентов и функционала, что приводит к увеличению размера установочных пакетов (например, 10-20 ГБ для решений Siemens), не всегда полностью используемого в конкретных проектах.
Закрытая архитектура, характеризующаяся ограниченной функциональностью и сложной интеграцией со сторонним программным обеспечением.
Стоимость разработки и внедрения таких комплексных SCADA-решений сопоставима с затратами на создание всей системы автоматизации первого уровня (полевого уровня). Это делает их доступными преимущественно для крупных промышленных предприятий с соответствующими бюджетами и ресурсами.
Для малых и средних предприятий возникает потребность в более легковесных и экономически эффективных решениях, ориентированных на следующие ключевые задачи:
Удаленный мониторинг производственных процессов.
Сбор, хранение и визуализация данных в виде графиков.
Логирование и учет производственных рецептов.
Автоматизированная загрузка рецептов на оборудование с верификацией данных.
Именно в этом контексте стандарт OPC UA (Unified Architecture) приобретает все большее значение в промышленной автоматизации, предлагая унифицированный и открытый подход к интеграции.
Система автоматизированного управления технологическими процессами (АСУТП) на основе OPC UA (Open Platform Communications Unified Architecture) представляет собой современное решение, обеспечивающее интеграцию и взаимодействие различных компонентов автоматизации. В данном контексте, SCADA-система получает непосредственный доступ к контроллерам, что значительно упрощает управление и мониторинг процессов.
Основные компоненты разработанной системы АСУТП СКАДА на OPC UA:
Контроллеры, такие как Siemens Simatic S7-1200 и S7-1500, поддерживают OPC UA, что позволяет им напрямую обмениваться данными с SCADA-системой. Это обеспечивает низкую задержку и высокую надежность передачи данных.
OPC UA - Это протокол для обмена данными, который обеспечивает безопасность, оперативность и масштабируемость. Поддерживает разнообразные типы данных и позволяет интегрировать устройства от разных производителей.
СКАДА -система: Программа написанная на Visual С++ по технологии MFC в системах с операционной средой Windows
Немного про забытый стандарт разработки Microsoft Foundation Class (MFC) — это мощная библиотека, разработанная для упрощения создания настольных приложений под операционную систему Windows. Она предоставляет объектно-ориентированную обертку над многими API Win32, Win64 и COM, что значительно облегчает разработку программного обеспечения. Давайте подробнее рассмотрим ключевые аспекты MFC:
Объектно-ориентированная библиотека: MFC использует принципы объектно-ориентированного программирования, что позволяет разработчикам создавать более структурированные и поддерживаемые приложения.
Упрощение разработки: MFC сокращает время разработки, предоставляя готовые классы и функции для выполнения распространенных задач, таких как обработка окон, управление событиями и работа с графикой.
Поддержка Windows API: Библиотека оборачивает Win32 API в удобные для использования C++ классы, что позволяет разработчикам сосредоточиться на логике приложения, а не на низкоуровневых деталях.
Интеграция с Visual Studio: MFC полностью интегрирована с Microsoft Visual Studio, что обеспечивает удобные инструменты для разработки, отладки и тестирования приложений.
Гибкость и расширяемость: MFC позволяет разработчикам создавать как простые, так и сложные приложения, включая поддержку различных интерфейсов, таких как диалоговые окна, меню и панели инструментов.
Для обеспечения полноценного функционирования SCADA-системы (Supervisory Control And Data Acquisition) требуется комплексное решение, включающее интеграцию с реляционной базой данных SQL Server и использование современного протокола связи OPC UA.
1. Интеграция с Базой Данных SQL Server:
SCADA-система должна осуществлять взаимодействие с SQL Server для извлечения и хранения критически важных конфигурационных и операционных данных. Ключевые наборы данных, получаемые из базы, включают:
I. Список контроллеров для связи и параметры их подключений: Эта информация управляется структурой
StrDBCP, которая содержит:iNom: Уникальный идентификатор записи.iNOMEQ: Ссылка на соответствующую запись в базе данных оборудования.strADRESS: Сетевой адрес контроллера (IP-адрес или hostname).iType: Тип подключаемого оборудования.bStartOnLine: Флаг автоматического запуска подключения при старте системы.bOnLine: Текущий статус подключения (онлайн/офлайн).UA_Client* g_clientOnline: Указатель на объект клиента OPC UA, используемый для установления соединения.UA_UInt32 g_subscriptionId: Идентификатор активной подписки на данные OPC UA.UA_StatusCode uStatus: Код статуса последней операции с подпиской.DWORDLONG* arrayValue: Указатель на массив для хранения получаемых данных.UINT sizearray: Размер массива для хранения данных.
II. Список данных для чтения из контроллера: Структура
StrDBINIопределяет параметры для чтения данных с контроллеров:iNom: Уникальный идентификатор записи.iTYPECPU: Идентификатор контроллера, к которому относится данная запись.iID: Идентификатор тега или переменной в пакете данных контроллера.iIDUA: Идентификатор узла (NodeId) в адресном пространстве OPC UA.iTYPEID: Тип данных переменной (например, целочисленный, вещественный, булев).bSaveDb: Флаг, указывающий, следует ли логировать данное значение в базу данных.iEQ: Идентификатор оборудования, к которому относится данный параметр.iLine: Столбец в интерфейсе SCADA для отображения данного параметра.
III. Список сохраненных данных: Структура
StrDBVALиспользуется для хранения исторических значений переменных:iNom: Уникальный идентификатор записи.CTime timeVal: Временная метка записи.iNOMEQ: Идентификатор оборудования, к которому относится значение.iItem: Идентификатор переменной (тега).iVal: Значение переменной.
IV. Подключение к данным верхней MES-системы: Для обеспечения комплексного управления и мониторинга, SCADA-система должна интегрироваться с MES (Manufacturing Execution System). Полной структуры MES мы приводить не будем (большой объем), ключевые сущности, с которыми осуществляется взаимодействие, включают:
StrDBEQ: Список оборудования.StrDBCFG: Конфигурация рецептов.StrDBSTATUS: Статусы оборудования.StrDBPRODUCT: Список производимых продуктов.StrDBPART: Список партий продукции.StrDBUser: Список пользователей с правами доступа.StrDBMAT: Список материалов, используемых в рецептах.StrDBREC: Список рецептов, связанных с продуктами.
2. Механизм подключения к контроллерам по протоколу OPC UA:
Подключение к контроллерам реализуется с использованием библиотеки open62541 (https://github.com/open62541/open62541), высокоуровневого клиента OPC UA.
Интеграция библиотеки: Для использования функционала OPC UA, в проект необходимо включить соответствующие заголовочные файлы:
Код С++ Конфигурация безопасности: Поддерживаются различные политики безопасности для установления защищенных соединений:
Функция подключения
CMainFrame::ConnectCPUOnline: Эта функция инициализирует клиент OPC UA, настраивает параметры соединения (включая URL конечной точки сервера, URI приложения и политику безопасности) и устанавливает соединение с контроллером. В приведенном примере кода используется политикаSECURITYPOLICY_NONEдля установления соединения.
bool CMainFrame::ConnectCPUOnline(UINT iAdr) { UA_StatusCode uStatus = UA_STATUSCODE_GOOD; UA_ClientConfig* cc; UA_Int32 command; UA_Boolean issecure; CT2A ascii(StrCPUADR[iAdr].strADRESS); //Initialize Client and Configuration StrCPUADR[iAdr].g_clientOnline = UA_Client_new(); cc = UA_Client_getConfig(StrCPUADR[iAdr].g_clientOnline); /* set logging level (the demo logger interprets the context pointer as min. level) */ /* cc->logger.context = (void*)UA_LOGLEVEL_TRACE; */ cc->logger.context = (void*)UA_LOGLEVEL_ERROR; UA_ClientConfig_setDefault(cc); cc->securityMode = UA_MESSAGESECURITYMODE_NONE; cc->endpoint.endpointUrl = UA_String_fromChars(ascii.m_psz); cc->clientDescription.applicationUri = UA_String_fromChars(APPLICATIONURI); cc->securityPolicyUri = g_psChosenSecurityProfileUri; /******************************************************************** Establish the connection to the server ********************************************************************/ uStatus = UA_Client_connect(StrCPUADR[iAdr].g_clientOnline, ascii.m_psz); if (uStatus != UA_STATUSCODE_GOOD) { return false; } else { return true; } }
Создание подписки и мониторинг данных: После успешного подключения, создается подписка на данные, и затем настраивается мониторинг для каждого требуемого тега.
// Создание подписки UA_CreateSubscriptionRequest request = UA_CreateSubscriptionRequest_default(); /* Create Subscription ***/ UA_CreateSubscriptionResponse response = UA_Client_Subscriptions_create(StrCPUADR[iAdr].g_clientOnline, request, NULL, NULL, NULL); if (response.responseHeader.serviceResult == UA_STATUSCODE_GOOD) StrCPUADR[iAdr].g_subscriptionId = response.subscriptionId; else return false; int iCount = 0; UA_MonitoredItemCreateRequest monRequest = UA_MonitoredItemCreateRequest_default(g_NodeId_Variable); UA_MonitoredItemCreateRequest dataItem; UA_MonitoredItemCreateRequest_init(&dataItem); dataItem.monitoringMode = UA_MONITORINGMODE_REPORTING; dataItem.itemToMonitor.attributeId = UA_ATTRIBUTEID_VALUE; UA_MonitoredItemCreateResult monResponse; UA_MonitoredItemCreateResult_init(&monResponse); for (UINT ini = 0; ini < m_iLoadDataIni; ini++) { if (StrCPUADR[iAdr].iNOMEQ == StrCPUINI[ini].iTYPECPU) { g_NodeId_Variable = UA_NODEID_NUMERIC(NAMESPACEINDEX_S7, StrCPUINI[ini].iIDUA); dataItem.itemToMonitor.nodeId = g_NodeId_Variable; monResponse = UA_Client_MonitoredItems_createDataChange(StrCPUADR[iAdr].g_clientOnline, StrCPUADR[iAdr].g_subscriptionId, UA_TIMESTAMPSTORETURN_BOTH, dataItem, NULL, UaServer_DataChangedCallback, NULL); if (monResponse.statusCode != UA_STATUSCODE_GOOD) { break; } iCount++; } }
Цикл обработки данных в отдельных потоках: Для обеспечения непрерывного опроса контроллеров и обработки поступающих данных, используется отдельный поток выполнения. Пример такого потока представлен ниже.
UINT OnLoadTreadOnline(LPVOID pParam) { CMainFrame* pFrame = (CMainFrame*)pParam; while (pFrame->m_bOnline) { for (UINT all = 0; all < pFrame->m_iLoadDataAdr; all++) { if (pFrame->StrCPUADR[all].bOnLine) pFrame->StrCPUADR[all].uStatus = UA_Client_run_iterate(pFrame->StrCPUADR[all].g_clientOnline, 500); } Sleep(500); } return 0; }
Этот поток периодически (с интервалом 500 мс) вызывает UA_Client_run_iterate для каждого активного клиента OPC UA, что обеспечивает получение обновленных данных от контроллеров.
Реализация функционала управления рецептурами и их версионирования на контроллерах
Для обеспечения гибкости производственных процессов и возможности воспроизводимости, SCADA-система включает функционал управления рецептурами, включая их загрузку на контроллеры и детальное логирование каждой операции загрузки.
Загрузка рецептуры на контроллер включает следующие этапы:
Извлечение данных рецептуры: SCADA-система запрашивает данные рецептуры из SQL Server, используя структуры
StrDBRECиStrDBCFG.Формирование набора данных для загрузки: На основе извлеченных данных, SCADA-система формирует пакет значений, соответствующих параметрам рецептуры, которые необходимо записать в контроллер.
Установление соединения с контроллером: Используется ранее описанный механизм подключения через OPC UA клиент (
UA_Client* g_clientOnline) с применением соответствующей политики безопасности.Запись данных в контроллер: Для каждого параметра рецептуры, SCADA-система выполняет операцию записи (write) в соответствующий тег (NodeId) контроллера, используя OPC UA. Это реализовано путем вызова функций типа
UA_Client_write.Верификация загруженных данных: После выполнения операции записи обязательно проводится верификация. Чтение записанных значений обратно из контроллера и сравнение их с исходными значениями рецептуры.
Логирование операции загрузки: Это критически важный этап, обеспечивающий прослеживаемость и аудит. Каждая успешная (или неуспешная) операция загрузки рецептуры фиксируется.
Номер артикула, номер партии, даты загрузок. Проверенные данные отмечены синей галочкой.
Итоговое резюме:
Программное решение было разработано с применением эффективных методологий управления проектами, что позволило достичь исключительно короткого цикла разработки. В частности, полная реализация всего функционала заняла всего 3 месяца. Этот результат был достигнут благодаря высокой квалификации и продуктивности единственного разработчика, который продемонстрировал глубокое понимание предметной области и техническое мастерство.
Программное решение демонстрирует исключительную гибкость в плане развертывания, будучи разработанным как нативное приложение для операционной системы Windows. Его исполняемый образ имеет минимальный размер — всего 6 Мб. Это достигается за счет отсутствия зависимостей от высокоуровневых фреймворков, таких как .NET. Таким образом, программа функционирует непосредственно на уровне операционной системы, начиная с Windows XP 64-bit и вплоть до современных версий, включая Windows 11. Такая архитектура обеспечивает высокую производительность, низкое потребление системных ресурсов и предсказуемое поведение в различных средах эксплуатации, минимизируя риски, связанные с версионными несовместимостями фреймворков.
Механизм установления связи с целевыми контроллерами реализован с использованием параллельной обработки данных. Применение многопоточной архитектуры для инициализации каждого соединения позволяет достичь сверхбыстрого времени подключения — порядка 3 секунд для подключения всех контроллеров. Такой подход обеспечивает эффективное использование вычислительных ресурсов и значительно сокращает начальные задержки при запуске системы или при восстановлении связи после сбоев. Каждый поток управляет жизненным циклом одного соединения, что гарантирует изоляцию процессов и предотвращает взаимное влияние при возникновении ошибок на уровне отдельных подключений.
Эффективное управление памятью и интеграция с СУБД: Несмотря на скромный объем оперативной памяти, занимаемый самим исполняемым кодом и данными (20 Мб), программа активно взаимодействует с SQL Server. Такая конфигурация достигается за счет стратегического кэширования части данных непосредственно в оперативной памяти приложения, в виде блоков данных. Это позволяет минимизировать количество обращений к дисковой подсистеме СУБД, ускоряя доступ к часто используемой информации и снижая нагрузку на сервер базы данных. Такой подход обеспечивает оптимальный баланс между скоростью доступа к данным и потреблением оперативной памяти, делая решение эффективным даже в условиях ограниченных ресурсов.
Пропускная способность канала связи и масштабируемость: Программа демонстрирует высокую эффективность использования пропускной способности сетевого канала при работе с промышленными контроллерами. При одновременном чтении 30 параметров с 5 контроллеров (150 параметров), общий объем трафика составляет всего 16 Кбайт. Масштабируемость решения подтверждается линейным увеличением потребления трафика: при работе с 50 контроллерами (1500 параметров) трафик возрастает до 160 Кбайт. Это свидетельствует о высокой степени оптимизации протокола передачи данных и позволяет успешно применять решение в системах с большим количеством подключаемых устройств без существенного увеличения нагрузки на сетевую инфраструктуру.
Обмен с контроллерами Программное решение предоставляет единую, высокоинформативную панель управления (dashboard), предназначенную для динамической визуализации операционного статуса всего парка промышленного оборудования.
Продвинутый механизм архивирования, парсинга и экспорта исторических данных для аналитики: Система располагает сложным модулем для сбора, обработки и анализа исторических данных, который обеспечивает глубокую детализацию информации о работе оборудования. Этот модуль выполняет комплексный парсинг сохраненных потоков данных, фиксируя каждое событие и изменение состояния с высокой временной точностью. Данные сохраняются в виде структурированных временных рядов, что позволяет проводить всесторонний анализ производительности, выявлять закономерности и аномалии.
Основной отчет о работе оборудования Формирования регламентированной отчетности. Интеграция с Microsoft Excel посредством прямого экспорта данных предоставляет пользователям максимальную гибкость в дальнейшем исследовании информации, позволяя применять любые инструменты анализа, доступные в офисных приложениях, и создавать кастомизированные отчеты для руководства и технических специалистов.
Он же выгруженный в Excel Отображать на графике данные по нескольким параметрам одновременно, обеспечивая корреляционный анализ и выявление взаимосвязей между различными показателями. Эта функция является неоценимым активом для инженеров по эксплуатации и технологов, предоставляя им возможность детально изучать историю работы оборудования, выявлять причины проблем и оптимизировать производственные циклы на основе объективных данных.
График работы оборудования Реализация рецептур с хранением каждой загрузки на контроллер потребовало комплексного подхода, включающего работу с базами данных, протоколом OPC UA, а также разработку механизмов логирования и верификации для обеспечения надежности и прослеживаемости производственных процессов.
Рецепт включает в себя более 50 параметров
Итог. Система АСУТП на базе OPC UA с непосредственным доступом SCADA к контроллерам Siemens представляет собой мощное решение для автоматизации процессов, обеспечивая высокую эффективность, безопасность и гибкость при минимальной стоимости разработки.
