Моделирование и АСУ ТП
Давайте представим, что нам нужно построить сложный объект — скажем, самолет, поезд или вообще атомную электростанцию. Строить «наобум» невероятно дорого и рискованно. Гораздо разумнее выполнить предварительные расчеты и скорректировать слабые места. Есть разные виды расчетов, ну например расчет прочности конструкции, расчет стоимости сооружения или эксплуатации, расчет последствий аварии (для АЭС). Расчеты бывают статические например расчет фундамента, расчет толщины стены, или просто расчет нагрузки на балку. И динамические - расчет некоторого процесса разворачивающегося во времени например: расчет процесса нагрева котла в доме, расчет процесса разгона авиационного двигателя, расчет процесса поддержания давления в кабине самолета при изменении высоты. В динамических расчетах сложных объектов, как правило необходимо учитывать работу автоматической системы управления (АСУ), поскольку система управления влияет на процесс.
Если мы говорим об АСУ ТП (Автоматической Системе Управления Технологическими Процессами), то само название как бы намекает на наличие некоторого процесса во времени, а значит тут есть место для динамического рассчета. Вот здесь-то на сцену и выходит "Среда динамического моделирования технических систем 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
Комментарии (48)
vasiliy_moscow
01.02.2026 21:39Отлично, очень рад за вас! Отрадно видеть, что кто-то занят большим и серьезном делом, а не жалуется на отсутствие печенек в офисе, токсичное начальство, «рынок АйТи уже не торт» и вообще в таких невыносимых условиях труда в «этой стране» ничего путного сделать невозможно!
ePGfree
01.02.2026 21:39Отличный и подробный материал про сквозное проектирование. Однако, как всегда, в погоне за технологичностью и красотой для интегратора забывается ключевой аспект — ремонтопригодность и удобство для службы эксплуатации. Внедрение языков типа С и сложных модульных сред (NordWind) без учета реальных навыков и практик персонала, который будет обслуживать систему 20-30 лет, — это создание будущей "черной коробки". Прежде чем тратить годы на создание такой платформы, нужно было провести годы в беседах с наладчиками, дежурными инженерами и ремонтниками. Спросить: "Как вы ищете поломку? Что вам нужно видеть в первую очередь при аварии? Какие инструменты вы реально умеете и готовы использовать?". Иначе мы получаем идеальную систему, отлаженную на модели, но абсолютно хрупкую и непонятную в реальной жизни. Интегратор уйдет через полгода с готовым проектом, а завод останется с загадкой на долгие десятилетия.
petuhoff Автор
01.02.2026 21:39Именно поэтому, тут SimInTech, где можно открыть диаграмму и добайта проследить как работает алгоритм. Это АЭС алгоритмы в SimInTech у проектанта конструктора производителя АСУ ТП. Открывай изкчай повторяй!
ePGfree
01.02.2026 21:39Вы правы, SimInTech — отличный инструмент для проектанта. Но мой тезис не о возможностях анализа, а о рабочих инструментах ремонта в условиях аварии.
Инженеру на производстве недостаточно «открыть диаграмму и добайтать». Ему нужен инструмент для действий, причём в формате, который он знает:
Диагностика: Быстро найти, какая именно ветка логики сработала или не сработала. Для этого нужны не графы в SimInTech, а триггеры, трассировка, статусы в реальном времени в том же LAD, который он видит на инженерной станции.
Экстренная модификация: Иногда нужно быстро дописать сервисный код (логирование, обход сломанного датчика, временный алгоритм пуска), чтобы запустить оборудование до прибытия запчастей. Для этого нужен доступ к программе ПЛК в родном, понятном ему языке, а не в сгенерированном C или блок-схемах SimInTech.
Языковой барьер: С — это язык системного программиста, а не инженера-наладчика. На производстве живут МЭКовские языки (LAD, FBD, ST), и LAD — король для визуальной диагностики. Инженеров, знающих С на уровне чтения чужого сгенерированного кода под давлением, — единицы.
Пример: аварийный дизель-генератор на АЭС. Время на поиск — минуты. Нет времени «изучать и повторять» алгоритм в SimInTech. Нужно открыть программу ПЛК этого дизеля, на родном языке, увидеть, почему не прошёл сигнал запуска, и, возможно, временно заблокировать ложный сигнал от неисправного датчика давления масла — чтобы обеспечить энергобезопасность сейчас.
Именно об этом я и говорю: сквозное проектирование должно быть «сквозным» и для эксплуатации. Генерация кода на С — это тупик для ремонтопригодности. Идеальная платформа должна позволять:
Генерировать/анализировать логику в высокоуровневых средах (SimInTech).
Предоставлять для эксплуатации ту же самую логику в нативных МЭКовских языках с возможностью безопасной временной модификации и продвинутой диагностики.
Иначе мы получаем идеально смоделированную систему, которая в момент реальной поломки превращается для персонала в непрозрачную магию, потому что ключ к пониманию (родная программа ПЛК) заменён на шифр (бинарник на С).
petuhoff Автор
01.02.2026 21:39Именно так это и работает.
К контроллеру подключается ноутбук с SimInTech и на диаграмме видно как внутри контроллера работает алгоритм. Можно его править и по нажатию кнопки заливать в стойку исправленную версию.
После внедрения на АЭС программист уже не ездил в командировку. Технолог сам правил диаграммы и заливал в стойки РБМК
В видео примерно на 7 минуте ноутбук с алгоритмами который отражает все что происходит в это время контроллере
ePGfree
01.02.2026 21:39Вы меня не слышите. Но дам вам один совет. Привлеките в свой проект экспертизу реальной эксплуатации.
petuhoff Автор
01.02.2026 21:39Это рналтная стстема с АЭС. Именно так и это работает, ровно как вы и описали.
Родной программой ПЛК в этом случае является диаграмма алгоритма в SimInTech.
Диагрмма SmInTech это как язык FBF от МЭК, только проще.
ePGfree
01.02.2026 21:39А зачем вы делаете велосипед? И кому проще. Да и если проще значит нельзя делать сложные вещи? Вопросов больше чем ответов =)
petuhoff Автор
01.02.2026 21:39Наоборот, проще для пользователя и поэтому можно делать гораздо более сложные вещи, чем пощволяет стандарт свверху вниз и слева на право.
Внутри встроенная сортировка блоков, пользователь не обязательно строго следить за последовательностью алгоритма. Система сама поправит и на.алгебраические петли укажет. Те кто с МЭК знаком разниыу не заметят, те кто только учатся освоится быстрее. Я же реальный пример привел, програмиста перестали на обьект брать технолог на реактор все делал в SimInTech.
Siemargl
01.02.2026 21:39Экстренная модификация: Иногда нужно быстро дописать сервисный код (логирование, обход сломанного датчика, временный алгоритм пуска), чтобы запустить оборудование до прибытия запчастей.
Это категорически запрещёно.
Crocodile77
01.02.2026 21:39Для каких-то атомных реакторов наверное пойдёт. Для реальных АСУ ТП которые на любом заводе есть - вряд ли. Там настоящие контроллеры работают.
petuhoff Автор
01.02.2026 21:39Вот пример ппошивки отечественного миландра ровно по той же технологии.
Прмер есть когда электпомобиль так же прошивали из SimInTech.
А вот тут вообще га0овый котел для обогрева дома:
NutsUnderline
01.02.2026 21:39NordWind — это исполняемая среда, которая обеспечивает работу алгоритмов, разработанных в SimInTech и не только, на целевом программируемом контроллере.
на каких таргетах это работает? в этом материале этот момент просто напросто плохо расписан. нарисованы какие то ардуины и stm32, в предыдущей статье - ESP32 devkit . а по тексту linux - ваше все.
NutsUnderline
01.02.2026 21:39из системных требований
Оперативная память: 2 ГБ для Windows 7/8/10
Операционная система: Windows 7/8/10
Для того чтобы это было на гос.предприятии система обязана работать на отечественной ОС из списка. Никаких windows. за использование 7 чуть ли не уголовное преследование. За 2Гб для Windows 10 - пользователи во всем мире уже ms "благодарны" со страшной силой.
petuhoff Автор
01.02.2026 21:39Давно уже на Aстре и Ред Linux все работает.
NutsUnderline
01.02.2026 21:39а это первый же вопрос который возникает, в наше время (про реестр тоже, но это на сайте есть). все таки оф.инфа на офсайте, тут на картинках винда выглядывает. а в разделе скачать - beta под некий linux
NutsUnderline
01.02.2026 21:39
NutsUnderline
01.02.2026 21:39в целом все это выглядит и описано довольно привлекательно, но это надо щупать щупать и щупать
petuhoff Автор
01.02.2026 21:39согласен полностью надо просто пробовать, у некоторых получается и вполне себе не плохо
NutsUnderline
01.02.2026 21:39ради пощупать приходится сообщить Вам все реквизиты. Хорошо что не кредитной карты :). Для первого приближения у Вас очень занятные видео, изучаю. Просмотров не мало. НО с моей колокольни:
1) Youtube похоже деградировал не только сам по себе но и эти самые видео - до 360p (да он так делает где думает что мало просмотров)
2) В рабочих условиях могут быть заблокированы и vk video и rutube
3) отделить эти видео от личных покатушек на лыжах тоже неплохо бы
предлагаю: размещать оригинал на ya disk - для просмотра и скачивания. ссылку на это дело на сайте не забыть.
petuhoff Автор
01.02.2026 21:39у меня на канале контент как раз развлекательный для реального обучения есть раздел в хлпе начало работы
NutsUnderline
01.02.2026 21:39О!.. это хорошо!. почему только этого на сайте нету ;)
petuhoff Автор
01.02.2026 21:39это ссылка на сайт вообще то :)))
NutsUnderline
01.02.2026 21:39Ну хоть что то у Вас хорошо ! :) как то я это пропустил, действительно, но сперва - видео.
Tyiler
01.02.2026 21:39Подписывайтесь на канал Технолог Петухов там без цензуры
Подписываемся!
PS: ну нельзя же так. следите немного за языком. у вас не прогеры разве пишут Nordwin и тд. считайте, что вы своих прогеров вот так вот обесценили всех, соотв-но можно подумать и о том, что там они написали, с таким отношением сверху.
petuhoff Автор
01.02.2026 21:39Это самокритика! :)))
Хотя с другой стороны, мы нв работу прогеров не берем, на больше физики нужны. Програмировать мы научим ща две недели есши в физики человек сечет.
d_nine
01.02.2026 21:39Оно и заметно, когда в одних блоках углы в радианах, в других в градусах без каких-либо хотя бы подписей. Хочешь повернуть вертикальный элемент, чтобы он стал горизонтальным? Открываешь модальное окно свойств, находишь там поворот и как любой нормальный человек вбиваешь 90 и... получаешь сюрприз. Про окно свойств тоже: хочешь открыть для пары блоков свойства? Нет, такое окно только одно. Выпадающие списки через строки с разделителями... и много чего ещё.
Не умаляю заслуг вашего продукта, но для новичков и людей привыкших работать с кодом это правда порой то ещё удовольствие.
Ivan_Motorov
01.02.2026 21:39Ну раз человек так прогеров не любит, позвольте полюбопытствовать.
Как вы позиционируете свою АСУ ТП с точки зрения архитектуры: относится ли она к классу DCS или к иной распределённой системе управления?
То что вы рассказываете про турбину, это обычный ЭЧСР паровой турбин, причем без теплофикационных и паровых отборов, что значительно упрощает математику устойчивости, а вся модель паровых турбин сводится к подсчету паровых объемов.
В статье я не увидел ничего принципиально нового для себя, возьмем китайскую железку вкрутим туда qnx который создали инженеры Американской компании Расбери и установим рантайм скорее всего это уже готовый кодесис разработанный немецкими инженерами и навернем свой красивый интерфейс, в статье принципиально не сказано, какова нагрузка системы? Количество точек ввода вывода, не приведены времена операций и скорости их выполнения с плавающей точкой или без, не сказано как обеспечивается резервирование больших объемов данных, в общем пока только болтовня не подкрепленная ни технической информацией не сказано о самом важном интеграции систем и протоколам передачи данных.
petuhoff Автор
01.02.2026 21:39Почему не люблю? Люблю, хоть они и дебилы рукожопые.
Что касается класификации, то у нас среда позволяет создавать любые варианты аохитектуры, от простых один контролер и одно устройство, до многоуровневых распределенных как АСУ ТП всей АЭС.
Все зпаисит от ТЗ и проектанта.
EmCreatore
Мда, это типа хотели продемонстрировать SIL ( Software-in-the-Loop ) , а показали пародию на SIL с дикой кучей кабелей и еще какими-то доморощенными макетками.
Т.е. так и не смогли полностью софтварную модель сделать?
petuhoff Автор
Какие доморощенные макеты? Это реальная стойка которая реально турбиной АЭС управляет.
Кабеля нужны для полной проверки контура управления. Из модели получаем температуру давление, пересчитываем их токовые значениф и отправляем на платы ввода-выводв в стойке. Обратно таким же путем стойка работает так же как на объекте, даже привод двигает, только турбины нет.
EmCreatore
В этом и проблема. Какой еще привод? Все должно быть в софте.
Какие еще кабеля? Вы стойку проверяете (ее ввод-вывод что, еще не проверили до сих пор?) или работу алгорима стойки с моделью? Или стойка настолько примитивна что не имеет цифрового интерфейса?
petuhoff Автор
В софте все есть вот эта модель:
И да можно залитые в стойку алгоритмы к этой модели подключить и проверить. Только это будет малоосмысленная проверка. Алгоритмы которые заливаются в стойку создаются в виде модели SimInTech и проверяются во всех режимах прямо в SimInTech. Математически алгоритмы в SimInTech и стойке АСУ ТП тождественны. Все косяки на стадии разрботки в модели устраняются.
Главаная задача стенда проверить уже связку алгоритмы + платы ввода-вывода. С их задержками, дискретностью, точностью и каналами связи плата - центральный процессор. А тут еще и преобразователи с приводами тестировали.
EmCreatore
Не ну это точно не SIL, а какое-то недоразумение.
Т.е. получается вы идеально умеете модерировать атомный реактор или что там у вас, а моделировать значит дискретность, задержки, точности у примитивыных плат ввода-вывода не можете?
И совсем не умеете моделировать преобразователи с приводами , поэтому делаете какие-то странные макеты, кторые наверно никто и на адекватность не проверяет.
По моему вы немного запутались в своем агрессивном маркетинге.
nv13
Задача подобных систем не только моделирование и симуляция, но и возможность комплексной аппаратно-програмной отладки всей системы, когда отдельные элементы системы могут маппиться на симуляторы, эмвляторы и аппаратные блоки. То есть на схеме модель и алгоритм один и тот же, а конфигурирование позволяет как чисто программную симулируемую отладку, так и аппаратную, когда вся модель выполняется на реальном железе. Так что этот sil лишь часть функционала подобных систем
EmCreatore
Речь не о методике тестирования, а о том как криво она реализована у автора.
Это несколько смешно - напыщенно говорить о симуляции атомного реактора, и не уметь симулировать даже простые преобразователи. Ставить какие-то крутилки имитируя турбину. Не уметь иммитировать операционную среду самой стойки управления. Это позор!
nv13
А речь и не идёт о тестировании. Это технология sw/hw codesign, которой лет 30 уже.
petuhoff Автор
Ну если у вас детская игрушка или смыв в туалете, то проверять железо можно на обекте немножко повоняет и все.
А если у вас турбина АЭС, то проверять стойку управления в сборе, лучше на модели.
Например латентность на шине данных платы ввода вывода, зависит от потока данных, а поток моделируется реальными данными с модели в исследуемых переходных режимах.
Когда вы говорите о моделировании управления привода, то там есть ШИМ, c его частотой 20 кГц, каким средствами вы эту модель в алгоритмы одадите с ьакой дискретноость.
Siemargl
Что за бред, вы там что, из Лего собираете?
Хотя отвечать не надо. Уже понятно и так что вы и кто вы
Скрытый текст
Продавцы очередного матлаба. А не разработчики самой асу, потому можно не бояться
petuhoff Автор
По этой методике уже лет 20 собираются АСУ ТП для АЭС. Видео нарезка с реалтных испытаний реальной АСУ ТП реальной турбины реальной АЭС.
И мы уже 20 лет так АСУ ТП для АЭС, Ледоколов, и АПЛ изготавливаем.
Ты сам то что то тяжеле dicka в жизни поднимал?
Siemargl
Я конкретно про вот этот пассаж
Вы либо не разбираетесь своем железе (поправка - все верно, железо то не ваше, ваша только теорчасть ) , либо оно у вас уровня 80286.
Собственно, Вам на это уже указали.
petuhoff Автор
Просто есть разняе задачи если три прихлопа три притопа и система простая, но нет проблем не спамятью не с пропускной способностью.
А есть сложные где с электрпитанием, массой и местом проблем нет, как на АЭС, там датчиками обвешивают все что можно, а потом чешут репу, как это все передать по сети и шинам.
Siemargl
Довожу до Вашего сведения, что на все нормальное оборудование имеется (и обязана) документация производителя с количественными и временными характеристиками в разрезе ввода вывода.
Мне неинтересно рассказывать базовые понятия, извините уж.
Ну у вас там на видео мелькают ещё мезонинные крейты, кажется я лет 20 таких уже не видел, могу и забыть как это называется.
petuhoff Автор
Если вы работали с реальным оборудованием, то вы бы знали что написанное в документации, и реальная работа это две большие разницы. А при сборке стоийки где есть контроллер и набор плат ввода-вывод и связб с системой верхнего уровня, а так же резервирование, всегда есть шанс что что то пойдет не так, как написано в паспорте.
ePGfree
Вам надо задуматься над тем что вы только что написали =) Может пора, что то менять, а то так и будем на жигулях ездить. Это кстати видно из ваших рамок в документации.
petuhoff Автор
А рамки чем не нравятся? Это просто и удобно, они сами заполняются, на алгоритм вообще не влияют. Просто есши SimInTech использует проектант, он может вообще документ выпустить как ТЗ на АСУ ТП.
А вот те кто контроллер шьют, могут взять алгоритм, а могут сами написать по документу. Как договор составлен.