Моделирование и АСУ ТП
Давайте представим, что нам нужно построить сложный объект — скажем, самолет, поезд или вообще атомную электростанцию. Строить «наобум» невероятно дорого и рискованно. Гораздо разумнее выполнить предварительные расчеты и скорректировать слабые места. Есть разные виды расчетов, ну например расчет прочности конструкции, расчет стоимости сооружения или эксплуатации, расчет последствий аварии (для АЭС). Расчеты бывают статические например расчет фундамента, расчет толщины стены, или просто расчет нагрузки на балку. И динамические - расчет некоторого процесса разворачивающегося во времени например: расчет процесса нагрева котла в доме, расчет процесса разгона авиационного двигателя, расчет процесса поддержания давления в кабине самолета при изменении высоты. В динамических расчетах сложных объектов, как правило необходимо учитывать работу автоматической системы управления (АСУ), поскольку система управления влияет на процесс.
Если мы говорим об АСУ ТП (Автоматической Системе Управления Технологическими Процессами), то само название как бы намекает на наличие некоторого процесса во времени, а значит тут есть место для динамического рассчета. Вот здесь-то на сцену и выходит "Среда динамического моделирования технических систем SimInTech."
Хотите узнать, как поведёт себя котельная установка, двигатель, система вентиляции и тд? Вместо того, чтобы собирать макет и проводить натурные испытания (иногда практически невозможные), мы используем SimInTech. SimInTech — это программное обеспечение, в котором можно создать математическую модель объекта и провести все испытания на компьютере, без риска и лишних затрат. Это позволяет найти ошибки и оптимизировать конструкцию объекта и отладить систему управления ещё до начала реального производства.
1.1 Как работает структурное моделирование
Практически любой физический процесс, будь то движение механизмов, течение жидкости или нагрев котла, можно описать системой дифференциальных уравнений. В SimInTech уравнения можно либо написать вручную различными способами, либо (что чаще всего и происходит) просто использовать готовые блоки. В эти блоки уравнения уже «вшиты»! Нам остается собрать модель как конструктор, выбрать подходящий численный метод и запустить расчет. Программа произведет вычисления и покажет, как будет вести себя ваша система во времени.
Взглянем на рисунок 1. На нем представлен пример одномерной теплогидравлической модели, собранной в SimInTech. Вместо длинных и страшных формул — наглядные блоки, соединенные линиями. Модель визуально напоминает технологическую схему системы, что облегчает её восприятие. В результате расчета мы получаем подробную картину изменения давления, температуры и скорости жидкости в каждой точке нашей системы. Результаты этих расчетов видны на графиках справа и снизу.
Важный момент: точность расчета зависит от исходных данных и принятых допущений. SimInTech не дает абсолютное совпадение с реальностью.
Описанный подход к созданию моделей из блоков можно применять к системам любой сложности в различных областях — от электротехники и гидравлики до механики.
Но как мы можем быть уверены в результатах?
Любому инженеру важно знать, что результаты моделирования соответствуют действительности. Мы провели простой, но наглядный эксперимент.
Посмотрим на рисунок 2. Мы смоделировали простую электрическую цепь — источник напряжения и параллельно соединенные резистор с конденсатором (RC-цепь). Мы специально взяли пример, у которого есть аналитическое решение. Зачем? Чтобы устроить проверку SimInTech. На графиках мы сравнили ток, рассчитанный по формулам, с тем, что получила программа, используя выбранный нами численный метод. Результаты идеально сошлись — значит, моделированию можно доверять!
1.2 Упрощаем проектирование АСУ ТП
Мы уже знаем, что в SimInTech можно создать математическую модель объекта. Но это только часть его возможностей. Рано или поздно наступает момент, когда модель должна превратиться в реальный физический объект. Именно здесь раскрывается вся сила SimInTech — в его возможности реализовывать сквозное проектирование алгоритмов для АСУ ТП (автоматизированной системы управления технологическим процессом).
1.2.1 Что такое АСУ ТП? Проще простого!
Давайте разберемся, как устроена любая автоматизированная система управления технологическим процессом на современном производстве. Ее структура условно делится на три уровня, они представлены на рисунке 3.
1 Нижний уровень. «Рабочие руки и органы чувств»
Здесь находятся:
- Датчики – «глаза и уши» системы. Они измеряют температуру, давление, расход и превращают эти физические величины в электрические сигналы, которые передаются на следующий уровень.
- Исполнительные механизмы – «руки» системы. Получив электрический сигнал от объектов среднего уровня, они выполняют команды: открывают клапан, запускают двигатель или включают насос.
2 Средний уровень. «Мозговой центр»
Это самый важный «этаж» ! Здесь «живут» программируемые логические контроллеры (ПЛК) — настоящие «мозги» всей операции, и их помощники: устройства связи с объектом (УСО) и промышленные сети. Они обрабатывают данные от датчиков, выполняют заданную программу управления, отдают команды исполнительным механизмам. Промышленные сети обеспечивают передачу информации между контроллерами и от ПЛК к элементам верхнего уровня АСУ ТП.
3 Верхний уровень. «Командный пункт»
Это операторский уровень, где происходит взаимодействие «человек-машина». Операторы видят на мониторах компьютеров всю картину происходящего в реальном времени: графики изменения параметров, предупредительные и аварийные сигналы, состояние оборудования и тд. С этого уровня можно вручную подавать команды системе или изменять ее настройки.
1.2.2 О проектировании АСУ ТП: классика жанра
Проектирование АСУ ТП — это сложный, многоэтапный процесс. Давайте разберем традиционный подход к проектированию по шагам:
1 Планирование:
Всё начинается с технического задания (ТЗ). В нём мы определяем, как будет устроена система, из чего она состоит, что именно должна делать и какие данные для этого нужны.
2 Проектирование:
На этой стадии работа ведется в нескольких направлениях:
- Разработка схем автоматизации: создаются принципиальные электрические схемы, показывающие физическое подключение всех устройств – от датчика до клемм контроллера, и функциональные схемы, демонстрирующие логическую связь элементов системы.
- Разработка логики управления (средний уровень): создаются программы и алгоритмы для программируемых логических контроллеров (ПЛК), которые напрямую управляют технологическим процессом.
- Создание операторского интерфейса (верхний уровень): настраивается SCADA-система: разрабатываются мнемосхемы и панели управления (HMI – human machine interface), настраивается архивирование данных и система сигнализации для взаимодействия персонала с системой.
3 Стендовые испытания:
Разработанные программы переносятся на реальные промышленные контроллеры, которые подключаются к упрощенному макету объекта — физическому стенду. Здесь проводится проверка корректности работы всей логики управления в условиях, близких к реальным, но без риска для настоящего оборудования.
4 Пусконаладка:
После успешных испытаний проверенная программа загружается на реальный объект, где осуществляется комплексная настройка: проверка всех каналов ввода/вывода ПЛК, настройка ПИД-регуляторов и SCADA-системы. Далее система запускается в эксплуатацию.
5 Работа и анализ:
После запуска система не остается без внимания. В процессе эксплуатации продолжается сбор данных, анализ работы и, при необходимости, оптимизация.
Таким образом, традиционный подход к проектированию АСУ ТП характеризуется последовательным выполнением этапов, где переход к следующему этапу происходит только после полного завершения предыдущего.
1.2.3 Как софт мешает нам работать: кто главный враг в проектировании?
Необходимость итераций в процессе разработки АСУ ТП – суровая реальность проектирования.
Процесс проектирования не всегда линейный. Идеально пройти весь путь от ТЗ до ввода в эксплуатацию практически невозможно. На этапе испытаний мы выявляем ошибки или неточности, анализируем результаты, вносим коррективы (например, в код или в модель) и повторяем тесты. Также меняются требования к системе или состав ее оборудования. Цикл продолжается до тех пор, пока поведение системы не станет именно таким, как мы задумали. Поэтому нам крайне необходимо иметь возможность легко возвращаться к любому из этапов разработки (например, к проектированию или тестированию), оперативно вносить изменения и проверять их.
Представим идеальный процесс: технолог видит ошибку во время испытаний, за пять минут вносит правку в алгоритм, и через мгновение обновленная программа уже тестируется на контроллере. Это и есть та самая гибкость, к которой мы все стремимся — возможность легко вернуться на любой этап, быстро внести изменения и сразу проверить результат.
Но что происходит на самом деле?
Привычное проектирование осуществляется с использованием большого количества ПО: алгоритмы – в одной программе, код – в другой, модель – в третьей, а визуализация – в четвертой.
К чему это приводит? К двум главным проблемам:
1. Эффект «испорченного телефона» на стыке специальностей
Технолог, проектирующий логику, и программист, переводящий её в код, говорят на разных языках. Малейшая неточность в техническом задании или его интерпретации, и в программу вкрадывается ошибка. А ведь это два разных человека, работающих в разных программах! Получается, что ошибки рождаются не из-за некомпетентности специалистов, а из-за самой организации процесса.
2. Долгий цикл «исправления-проверки»
Классическая ситуация: на этапе аппаратных испытаний выясняется, что технолог допустил ошибку в логике. Что дальше?
- технолог исправляет её в своих документах или моделях;
- формирует новое задание для программиста;
- программист вносит правки в код (и может ошибиться снова);
- обновленная программа загружается на контроллер для повторной проверки;
Цикл исправлений затягивается, отнимая дни или даже недели. Одно небольшое изменение приводит к долгому последовательному процессу исправлений.
Очевидное решение проблемы – использование единой среды разработки, а также замена большого количества узких специалистов на одного универсального.
1.2.4 Решаем главную проблему. Один инструмент вместо десятка программ
Как было сказано ранее, одна из основных сложностей в классическом проектировании АСУ ТП — это необходимость постоянно переключаться между разными программами: одна для моделирования, другая для программирования, третья для визуализации... Проблема усугубляется необходимостью постоянного обмена данными в разных форматах между участниками разработки – технологами, инженерами-программистами, специалистами по визуализации и тд. В итоге проектирование превращается не в создание системы, а в постоянную синхронизацию данных между людьми и программами. Знакомая история?
SimInTech предлагает единую среду для всей работы.
Суть проста: это единый и непрерывный процесс от идеи до пуска системы. Вместо того чтобы «прыгать» из программы в программу, вы всё делаете в одной среде — от написания логики управления до её проверки на модели и, наконец, применения на настоящем оборудовании. И самое главное – это все может реализовать один специалист – инженер. Удобно, не правда?
На рисунке 5 можно увидеть главные этапы проектирования с использованием SimInTech.
Давайте рассмотрим подробнее, как это выглядит на практике.
1. Техническое задание: живой проект, а не куча бумаг
Техническое задание (ТЗ) в SimInTech — это не просто набор документов, а готовый проект. Мы сразу создаем структуру будущей системы, а все параметры и сигналы хранятся в единой базе данных SimInTech. И главное — ТЗ можно сразу же проверить на корректность, не переключаясь в другие программы.
2. Проектирование: работа для технолога, а не программиста
- Модель объекта. Специалист собирает модель из готовых графических блоков (гидравлика, механика, электрика и т.д.). Писать сложные уравнения и тем более решать их не нужно!
- Алгоритмы управления АСУ ТП. Разработанный алгоритм – это и есть та программа, которая будет выполняться на ПЛК и управлять реальным объектом. SimInTech предлагает несколько способов создания логики управления: использовать готовые стандартные блоки, разработать собственные блоки или написать часть кода на встроенном языке программирования или на языке C.
- Виртуальный пульт управления. Интерфейс для оператора также создается в SimInTech. Не нужно осваивать отдельную SCADA-систему — вы сразу создаете мнемосхемы и панели управления в знакомой среде.
3. Виртуальные испытания: собираем все воедино
На этом этапе мы соединяем все части вместе (модель объекта, логику управления и интерфейс оператора) в комплексную модель. На этой виртуальной модел�� мы можем:
- протестировать и отладить взаимодействие между алгоритмом и моделью;
- настроить регуляторы для устойчивой работы системы в любых режимах;
- проверить поведение системы при запуске, остановке и в штатном режиме, убедившись, что все параметры соответствуют требованиям.
4. Генерация программы для контроллера: два в одном
В SimInTech этот этап полностью автоматизирован и состоит из двух шагов, которые выполняются одной кнопкой:
- Генерация кода. SimInTech за секунды преобразует отлаженный алгоритм управления в текст программы на промышленных языках (C или ST) для ПЛК. Используя готовые шаблоны кода, SimInTech создает код, не требующий ручных правок. Вам не нужно быть программистом — вы работаете с блоками, а SimInTech делает код.
- Компиляция. Полученный код автоматически компилируется в исполняемый файл. Результатом является программа или динамическая библиотека (.so, .dll), адаптированные под конкретное целевое устройство.
В итоге, вы нажимаете одну кнопку, и отработанный в SimInTech алгоритм превращается в готовое решение, идеально адаптированное под целевую платформу (рисунок 6). А если потребуется нестандартное решение, вы всегда можете создать собственный шаблон генерации кода, взяв за основу существующие и адаптировав их под свои нужды. Это обеспечивает поддержку даже самого нестандартного оборудования.
Мы соединяем запрограммированный контроллер с компьютерной моделью того объекта, которым он должен управлять. Это позволяет провести реалистичные испытания перед запуском, во время которых можно найти и исправить оставшиеся недочеты.
Такой подход дает целый ряд преимуществ еще до выхода на реальный объект:
- предсказуемость: можно заранее увидеть, как алгоритм будет вести себя в различных режимах работы;
- безопасная отладка: легко находить и исправлять ошибки на модели, не рискуя оборудованием;
- тестирование сложных сценариев: можно проверить, как система себя ведет в аварийных случаях;
- точная настройка: возможность анализировать устойчивость регуляторов и оптимизировать их работу.
Как мы могли заметить, SimInTech используется на четырех из пяти этапов проектирования. Но что обеспечивает переход на пятый этап — работу алгоритма на реальном контроллере и его связь с виртуальной моделью? Одним из решений этой задачи является использование исполняемой среды NordWind, созданной нами – разработчиками SimInTech.
2 Что такое NordWind и зачем он нужен?
NordWind — это исполняемая среда, которая обеспечивает работу алгоритмов, разработанных в SimInTech и не только, на целевом программируемом контроллере.
Основные задачи исполняемой среды:
- циклическое выполнение программы: запускает алгоритмы с строго заданным периодом;
- обмен данными: обеспечивает коммуникацию с другими устройствами;
- управление памятью: работает с внешними и внутренними переменными алгоритмов;
- обработка сбоев: контролирует работу системы и реагирует на ошибки.
Таким образом, NordWind выступает надежной прослойкой между вашим алгоритмом и аппаратной частью, беря на себя все рутинные операции.
Архитектура NordWind — модульная (микро ядерная). Это означает, что существует основная программа, которая дополняется только необходимыми для решения конкретной задачи модулями. Зачем такие сложности? Требования безопасности (ГОСТ Р МЭК 60880-2006) предписывают: на критически важном оборудовании должны быть реализованы только те функции, которые непосредственно необходимы для работы. Всё лишнее — место потенциальной ошибки.
2.1 NordWind на контроллере
В основе работы любого современного контроллера лежит операционная система. Nordwind тесно взаимодействует с этой ОС, раскрывая все возможности оборудования.
2.1.1 Операционная система: Linux или ОСРВ?
Представьте сложные системы, где важна каждая миллисекунда: турбина электростанции, конвейер на заводе или система в самолете. Здесь любая задержка может привести к аварии или огромным убыткам. Всеми процессами управляет ПЛК. Чтобы добиться максимальной точности, Nordwind использует специальную операционную систему — ОСРВ (Операционную Систему Реального Времени). Её главная задача — гарантировать, что управляющая команда выполнится строго в нужный момент, с заданной точностью. Если требования жёсткого реального времени отсутствуют, целесообразно использовать ОС Linux.
2.1.2 NordWind: фундамент управления
Основной модуль NordWind выполняет несколько ключевых функций при запуске системы:
Создает общую область памяти для данных (базу данных). Разные алгоритмы (расчетные модули) должны постоянно обмениваться данными. NordWind автоматически строит для них специальную общую область памяти, к которой все модули имеют доступ на чтение и запись. Условно, эту базу данных можно разделить на две части:
Структура данных, описывающая расположение переменной в массиве данных (например, «температура в зоне А» — строка 5, столбец 3).
Значения переменных со служебной информацией. Каждое значение имеет статус достоверности (например, «достоверно», «недостоверно»), указывающий на качество полученных данных, и временную метку, фиксирующую точный момент времени, когда это значение возникло. Это позволяет системе отличать актуальные и надежные данные от устаревших или ошибочных.
Загружает алгоритмы. NordWind подгружает необходимые библиотеки с алгоритмами (расчетные модули), которые содержат логику управления оборудованием системы.
Восстанавливает последнее состояние. При перезапуске система не начинает работу с нуля. NordWind загружает последнее сохраненное состояние, позволяя продолжить работу с точки останова.
ОС с заданными временными интервалами [P1] запускает алгоритмы (расчетные модули) на исполнение. Те, в свою очередь, берут данные из общей области памяти, выполняют вычисления и записывают результаты обратно. Все это происходит с высочайшей точностью и предсказуемостью, укладываясь в строго отведенное временное окно. Как только вычисления на текущем такте завершены, система начинает выполнять другие операции строго до начала следующего временного интервала: происходит обмен данными по сети с другими контроллерами, запись текущих значений в архивы для последующего анализа и тд (см. рисунок 9). Этот подход гарантирует, что критичные функции управления никогда не будут прерваны второстепенными задачами.
2.1.3 Не только основной модуль
Основной модуль NordWind отвечает за выполнение главной задачи – запуск алгоритмов, но настоящую гибкость и силу системе придают дополнительные модули. Их подключают по мере необходимости, создавая набор функций, идеально подходящих для конкретной задачи.
Вот некоторые ключевые модули:
- GdbServer — это инструмент для удаленной отладки и управления контроллером. С его помощью вы можете с компьютера по сети (TCP IP) подключаться к работающему контроллеру.
- Модуль libnet.so реализует обмен данными по протоколу UDP между контроллерами с NordWind. В строго заданный такт работы алгоритма модуль отправляет пакет с данными по сети, получение пакета происходит асинхронно, то есть независимо от выполнения основного расчетного модуля.
- Модуль libtrends.so реализует ведение архивов. Запись значений в архив происходит не через равные промежутки времени, а при изменении значения дискретного сигнала или превышении порога изменения (апертуры) аналогового сигнала. Это позволяет эффективно использовать память.
- Модуль libnetinit.so реализует механизм горячего резервирования. Модуль обеспечивает синхронизацию данных двух резервируемых контроллеров. В случае аварии или планового останова одного из контроллеров другой подхватит управление, используя актуальные данные, что обеспечивает безударную работу системы.
- NordWind_Web_Server реализует веб-доступ к данным контроллера. Подключившись к нему через браузер (как Chrome) с любого компьютера в сети, вы можете просматривать данные или изменять их значения.
- Модуль NordWind_Modbus_Server обеспечивает обмен с устройствами с использованием открытого протокола Modbus TCP.
- Модуль NordWind_OPC_UA позволяет контроллеру «общаться» с любыми современными системами по единому промышленному стандарту OPC UA. [P3] [TK4]
Кроме использования стандартных модулей существует возможность создавать собственные с помощью SDK(Software Development Kit – набор инструментов для разработки). Вы можете:
- разработать функционал модуля libio.so, который реализует ввод-вывод данных. Он преобразует физические сигналы от датчиков в цифровые данные для расчетного модуля и, наоборот, превращает расчетные сигналы в команды для управления реальными механизмами.
- разработать приложение с использованием существующего открытого протокола, которое будет работать с базой данных NordWind напрямую.
Вы не ограничены набором наших модулей, вы можете создать собственный идеальный инструмент.
Система растёт вместе с вашими задачами благодаря модульной архитектуре.
Одна и та же технология может работать как на компактных встраиваемых контроллерах, так и масштабироваться до мощных архивных серверов для сложных систем.
Разработан открытый протокол для обмена данными с базой данных NordWind
2.2 Суперсила NordWind: удаленная отладка в реальном времени на модели SimInTech
Главная особенность NordWind — возможность удаленной отладки алгоритмов в реальном времени на модели SimInTech. Эту возможность обеспечивает сервер отладки GdbServer, который позволяет с рабочего места инженер�� в реальном времени отслеживать и изменять любые переменные в контроллере и управлять выполнением программы: ставить на паузу, возобновлять или останавливать расчеты прямо со своего рабочего места.
Существует два уровня удаленной отладки.
2.2.1 Уровень 1. Проверяем алгоритмы, не вставая из-за компьютера
Представьте: вы проектируете систему управления, и нужно проверить, как алгоритмы будут работать на реальном контроллере. Но самого контроллера под рукой нет — он может находиться за сотни километров от вас! Или же собранного шкафа управления еще нет, а есть только процессорная плата «из коробки». Как в такой ситуации проверить, что всё работает правильно? Решение – удаленная отладка. Она может быть реализована в двух вариантах: на виртуальной машине или процессорной плате.
Принцип работы в обоих случаях один и тот же. Данные (расход, давление, температура) и команды из вашей модели передаются по сети. Алгоритмы на виртуальном контроллере или реальной плате обрабатывают их и мгновенно возвращают результат обратно. Вы сразу видите на своём компьютере, как в реальном времени «оживает» ваша модель: меняются показания датчиков, включаются насосы и обновляются графики.
Такой подход позволяет оценить работу контроллера и обнаружить ошибки до того, как алгоритмы попадут на реальный объект. Вы можете тестировать любые сценарии работы системы прямо со своего рабочего места.
2.2.2 Уровень 2. Контроллер готов к работе
Представьте, что ваш алгоритм управления работает на настоящем контроллере, но взаимодействует не с физическим объектом, а с его моделью в SimInTech.
Для проведения испытаний необходимо разработать УСО (устройство сопряжения с объектом). Это своего рода преобразователь между реальным и виртуальным мирами. Схема удаленной отладки с использованием УСО представлена на рисунке 11.
Математическая модель в SimInTech с определенным тактом передает по сети физические значения величин из модели на УСО. Здесь происходит ключевое преобразование: физические величины из модели превращаются в реальные электрические сигналы, которые через устройства ввода/вывода поступают на контроллер.
Контроллер, получая эти сигналы, выполняет цикл регулирования — анализирует данные, принимает решение и формирует управляющие команды. Эти команды в виде электрических сигналов возвращаются на УСО, где снова преобразуются в физические величины и отправляются обратно в модель SimInTech, замыкая цикл.
Комплексная отладка модели и реального оборудования открывает уникальные возможности для всесторонней проверки самого «железа» и его поведения в реальных условиях.
Мы можем осознанно создавать различные сценарии и наблюдать за реакцией системы:
- проверить корректность преобразования сигналов (АЦП и ЦАП) и работу алгоритмов обработки первичных да��ных;
- имитировать отказы устройств ввода-вывода и наблюдать за реакцией системы
- провести комплексные испытания УСО в условиях, максимально приближенных к реальным
- создавать нештатные ситуации на математической модели: выходы за диапазоны, аварийные сценарии
- намеренно вносить искажения в электрические сигналы, чтобы оценить, как УСО обрабатывает такие ситуации
По сути, удаленная отладка позволяет обеспечить полноценную испытательную базу, на основе которой можно безопасно и осознанно проверить работу всего оборудования в различных — даже самых критических — сценариях, не рискуя реальным оборудованием. Это позволяет выявить и устранить потенциальные проблемы на этапе проектирования, прежде чем система будет запущена в эксплуатацию.
3 Конфигуратор NordWind
NordWind — это модульная программа. Для работы большинства её модулей необходимы конфигурационные файлы. По сути, это текстовые файлы, которые содержат все необходимые для работы настройки:
- списки сигналов для архивирования;
- параметры сетевого обмена;
- адреса отправителей и получателей данных;
- перечни сигналов для обмена с устройствами ввода/вывода.
Чем сложнее задача контроллера (больше модулей, алгоритмов и сигналов) или чем больше контроллеров в АСУ ТП, тем больше и запутаннее становятся эти конфигурационные файлы. Ручное создание и редактирование превращается в головную боль, где легко ошибиться.
Чтобы решить эту проблему, мы создали «Конфигуратор NordWind». Это инструмент, который автоматизирует создание файлов, делая процесс быстрым и безошибочным.
Конфигуратор NordWind — это проект, созданный в SimInTech.
Но прежде, чем мы углубимся в детали проекта, давайте разберёмся с одним важным понятием — ПТК (программно-технический комплекс) и тем, как он связан с АСУ ТП.
Если просто, ПТК — это «физическое воплощение» АСУ ТП. Это набор всего необходимого «железа» (контроллеры, датчики, серверы) и программного обеспечения, которые вместе решают задачу автоматизации конкретного технологического процесса. Можно сказать, что АСУ ТП — это задача, а ПТК — готовое решение, «собранное на площадке».
Структура ПТК полностью повторяет структуру АСУ ТП, которую мы рассматривали ранее.
На рисунке показана лишь упрощённая схема. В реальности ПТК — это сложный и разветвлённый «организм». И его конфигурирование (то есть настройка каждого компонента) — это огромный объём работы:
- нужно прописать все сигналы от датчиков и на исполнительные механизмы;
- указать расположение модулей ввода/вывода в стойках;
- настроить сетевые подключения и обмен данными между контроллерами;
- сформировать списки сигналов для архивирования и отображения на мнемосхемах;
и многое другое.
Делать всё это вручную — крайне трудоёмко и очень легко допустить ошибку.
Мы создали «Конфигуратор NordWind», чтобы упростить настройку контроллеров в ПТК. Он предназначен для работы на уровне контроллеров, где установлена исполняемая среда NordWind. В проекте вы формируете логическую структуру вашей системы: соединяете контроллеры, настраиваете сети и их взаимодействие.
После определения топологии системы выполняется индивидуальная настройка каждого контроллера.
Настройка | Что позволяет сделать? |
Выполнение алгоритмов | Привязать проекты SimInTech к контроллеру, задав период и количество их вызова. |
Межконтроллерный обмен | Сформировать списки сигналов для отправки и приёма при взаимодействии с другими контроллерами. |
Архивирование данных | Определить перечень сигналов, которые необходимо записывать в архив для последующего анализа. |
Обмен с устройствами | Настроить подключение к оборудованию ввода/вывода по протоколу Modbus. |
Восстановление каналов | Задать список каналов, для которых должно работать автоматическое восстановление связи. |
Сетевой обмен | Обмен данными с использованием протоколов OPC UA, Web Socket, HTTP. |
После завершения настройки достаточно нажать одну кнопку. Конфигуратор автоматически:
Проверит созданную схему на целостность и ошибки.
Сгенерирует все необходимые файлы конфигурации и динамическую библиотеку.
Разложит их по нужным папкам, полностью подготовив систему к работе.
Проверка выявляет ключевые несоответствия:
- сети: корректность IP-адресов контроллеров и их подсетей;
- сигналы: совпадение списков сигналов для обмена и архива с реальными сигналами контроллера;
- связи: соответствие между отправляемыми и получаемыми списками сигналов у связанных контроллеров;
- время: синхронизация частоты отправки данных с тактом работы алгоритмов.
Это позволяет избежать большинство типовых ошибок, характерных для ручного конфигурирования.
Заключение
Таким образом, с появлением «Конфигуратора NordWind» SimInTech превращается в единую и законченную платформу для сквозного проектирования АСУ ТП – от идеи до готовой реализации.
Наличие такой среды разработки обеспечивает два ключевых преимущества:
Снижение ошибок и потерь данных. Поскольку весь проект ведется в рамках одной платформы, исключаются риски, связанные с преобразованием и переносом данных между разными, несовместимыми программами.
Высокая скорость итераций. При обнаружении ошибки на любом этапе проектирования инженер может оперативно внести необходимые изменения прямо в модель и сразу же проверить результат, не привлекая других специалистов и не запуская трудоемкий процесс согласования данных между различными инструментами.
Это позволяет одному специалисту уверенно управлять всем жизненным циклом проекта, обеспечивая его целостность и значительно ускоряя разработку.
Ну и пример как это реально работает для АСУ ТП турбиного отделения АЭС
Подписывайтесь на канал Технолог Петухов там без цензуры про новости импортозамщения. https://t.me/Tech_Petuhoff/825
