Часть 1. Лирическая.
Перекличка эпох. Буквально недавно я опубликовал очередную cool-story о лихих математиках из лихих 90-х, как получил живое свидетельство алгоритмов управления прямиком из тех легендарных времен.
По работе сейчас нужно сделать стенд-демонстратор. Задача – показать, как, используя среду математического моделирования, можно заливать одни и те же технологические алгоритмы АСУ ТП в контроллеры от разных производителей и на разных аппаратных платформах. Идея в том, чтобы спроектировать алгоритм в SimInTech один раз, а потом, при смене контроллера (привет санкциям и старушке Шапокляк фон дер Ляйен), уже ничего не нужно проектировать заново: ни этот же самый алгоритм, ни создавать его заново в другой среде разработки. Открываем SimInTech с готовым проектом – и пожалуйста:
«…нажми на кнопку – получишь результат,
И твоя мечта осуществится.
Что ж ты не рад?
Тебе больше не к чему стремиться!»
А вот если алгоритм в среде разработки Siemens, то тут уже фигушки, нужно его опять пересобирать в среде разработки от другого производителя. А нам её ещё нужно найти, что нетривиальная задача. Если все разработчики автоматики, за редким исключением, собирали свои алгоритмы в различных импортных Codesys, запрещённых нашими немецкими партнёрами из ЕС.
«…а ещё вчера все вокруг говорили: Siemens – друг, Siemens наш немецкий друг…»
На этом месте возник у меня вопрос: а что, собственно, взять в качестве примера для стенда-демонстратора? Первая мысль, конечно, обратиться к текущим проектам в которых нас привлекают как консультантов:
Уважаемый редактор,
Может, лучше про реактор,
Про любимый лунный трактор?
Но тут сегодня у нас на страже корпоративные всякие органы службы безопасности. После моего недавнего видео с выставки (с чужого стенда, Карл, со стенда на выставке!) в канале «Технолог Петухов» мне две организации оборвали телефон с просьбой убрать видео, ибо органы возбуждаются. А возбуждённый орган мешает работать, как яйца мешают плохому танцору. Причём каждая из организаций считала, что это их модель засветилась в моём видео.
Поэтому мне пришла в голову гениальная идея: поднять старый проект системы управления трубопроводной системы «Восточная Сибирь – Тихий океан». Делали мы его в доисторическую эпоху динозавров, когда я был двухметровым блондином с голубыми глазами, трава была зеленее, а девушки были исключительно с размером бюста 3+.
Программная палеонтология в почтовом ящике себя оправдала: в почте вместе с нюдсами подруг нашлась модель 2007 года. И что совсем хорошо и удивительно – современной версией SimInTech эта модель открылась и запустилась почти без ошибок. Через 20 лет, Карл, 20 лет.
На этом месте я вспомнил наши тогдашние разговоры с хозяином одной, широко известной в узких кругах конторы, который открывал мне, наглому выскочке и мамкиному стартапёру, правду жизни:
«Твоя жалкая частная лавка “ИЧП Напрасный труд” схлопнется в самое ближайшее время. А моя контора – это толстая жирная бородавка на теле Росатома, уже 30 лет работает в отрасли, и её все знают. Мы даже владели одно время институтом ВНИАЭС. Поэтому мы, как корпорация “Амбрелла”, будем жить даже после зомби-апокалипсиса! А это очень важно для атомной отрасли, где проекты должны работать через 50 лет! Так что выбор у тебя, чушпана, простой, как две копейки, или оператор IF ELSE:
1) иди нахер
2) иди ко мне работать за те же две копейки».
Но вот прошло 20 лет, а наши проекты алгоритмов прекрасно открываются и считаются в последней версии SimInTech, в отличие от той конторы, где с тех пор уже три несовместимых версии системы моделирования сменились и сейчас пилится четвёртая, в которой модели версии первых вряд ли откроются.
И сейчас на ваших глазах получается уникальный живой эксперимент длиной в 20 лет. У меня есть модель алгоритмов управления, разработанная 20 лет назад на стадии проектирования реального объекта – ТС ВСТО, и современный контроллер от отечественного производителя. Нужно их совокупить. Прошить мозги, разработанные 20 лет назад, в новое железо. Это примерно как DOOM 2 запустить на телефоне.
Мы получим ответ на вопрос: что делать, когда объект работает уже 20 лет и нужно менять аппаратуру системы управления в условиях, когда иных уж нет, а те далече? А кто раньше не знал, теперь давно забыл, как эта труба работает. Это, если что, про меня: я вообще не вкуриваю, как эта нефтяная труба работает, и буду по ходу разбираться.
Тут я немного утрирую. Реальность, конечно, отличается от демонстрации. После того как ВНИИСТ в 2006 году собрал модель управления трубопроводом ТС ВСТО в SimInTech, институт, запуская алгоритмы в модели, проверил и отладил регламент работы. Как мне говорили, там даже нашли режимы, при которых система могла раскачиваться. Для чего, собственно, и нужно моделировать процессы.
Далее этот проверенный регламент отдали в виде бумажного ТЗ производителям систем автоматизации. Весь трубопровод поделили на системы, подсистемы, каждую из которых могла собирать отдельная компания и даже на разной аппаратуре. Производители АСУ ТП создавали программы по ТЗ в CodeSys или других средах проектирования от Siemens, Emerson и прочих Schneider Electric (что в то время было модно-молодёжно у автоматчиков нефтянки). Потом испытали всё это на объекте. Периодически, я предполагаю, задавали вопросы и проводили численные исследования на нашей модели, уже не привлекая нас. Это я сужу по закупкам лицензий и оплате технической поддержки в соответствующих институтах, где эта модель использовалась после окончания самого проекта. Но никакого сквозного применения модели от проекта до контроллеров у нефтяников тогда не наблюдалось.
А ведь к тому времени, к 2006 году, у нас уже была готовая сквозная технология модельно-ориентированного проектирования АСУ ТП, которая позволяла сгенерировать код для контроллеров по нажатию кнопки. И она реально работала и применялась для систем управления АЭС в системах безопасности.
Более того, у нас был готов генератор кода ST для ПЛК Schneider Electric с готовой загрузкой по кнопке в среду Unity, которая, в свою очередь, прошивала контроллеры Schneider. Причём этот генератор кода мы делали для частной конторы РТСофт. Там был соображающий инженер, который понимал, что проверка на модели алгоритмов перед заливкой в контроллер – это очешуенно полезная фишка. И мы для него реализовали генерацию. Он даже выполнил сравнение ручного кода и кода из SimInTech, где сам убедился и другим доказал, что наш код неплохо подходит. Но жадные эффективные менеджеры тогда зажали денег на лицензии – частный бизнес считает каждую копейку.
С ВНИИСТ, где создавали модель ТС ВСТО, была другая история: там в это время всем рулил товарищ Вексельберг, у которого даже яйца были от Фаберже. Денег было не просто много, а очень много, и поэтому там брали всё самое лучшее, самое дорогое, всё самое западное, самое американское и самое европейское.
Как же на этом празднике жизни оказался SimInTech, а не толерантный MATLAB Simulink, спросите вы?
Я отвечу. Всё просто: этот трубопровод был первый в России, который управлялся единой автоматической системой управления.
До этого все трубопроводы управлялись по телефону. Примерно так:
Из диспетчерской звонили на первую насосно-перекачивающую станцию (НПС) и говорили:
– Иваныч, включай свои насосы, как раскрутишь – сообщи.
Иваныч по месту врубал насосы, считывал показания и звонил диспетчеру:
– Два насоса завелись, третий в ремонте, у четвёртого движок скоммуниздили геологи. Качаю двумя, держу давление 50, нефть пошла. Пришлите спирту и новый движок!
Диспетчер ставил точку давления на графике, звонил на вторую НПС:
– Михалыч, едрить, не спать! Там Иваныч запустился, через час у тебя давление долбанёт, готовься включаться.
И в принципе это работало. Я помню мой шок, когда первый раз увидел в модели запуск НПС: три насоса включились на полную, давление, расход, тонны нефти улетают в трубу. Смотрю на следующую станцию по ходу трубопровода — они на экране в модели рядом, а там ничего от слова совсем. Ни расхода, ни давления. Ни-че-го!
– Эй, а куда нефть-то уходит?
– В трубу. Там расстояние – сотни километров. Труба под давлением расширяется, вся нефть в это расширение и уходит тоннами. Только через 40 минут – час времени на следующей НПС заметят, что давление поднимается.
А я-то привык к тому, что в реакторах включил – секунды, насос разогнался, и сразу и давление, и расход по всей системе в секунду виден, особенно если в модели несжимаемая вода. В нефтянке с тысячами километров труб всё немного не быстро. И можно не торопиться.
Но для ТС ВСТО решили сделать всё по фэн-шую и красоте: единая система управления, общий алгоритм-регламент, который чётко включает-выключает, частотниками регулирует обороты насосов, открывает-закрывает задвижки и так далее, и тому подобное. Но чтобы не налажать в первый раз, во ВНИИСТ решили создать модель, на которой всю эту модную красоту-ляпоту проверить. Течение нефти по трубам считать умели, работу насосов тоже считали, а вот единой системы управления для всего трубопровода никто до этого не создавал в виде динамической модели. К кому обратиться? У кого есть такой же сложный объект? Оказалось, что это АЭС: там тоже до фига труб, насосов, задвижек и прочих клапанов с регуляторами. Только на АЭС они в большую бетонную коробку в виде комка спутанных ниток утоптаны. А трубопроводная система нефтепровода – это тот же самый клубок, только на тысячи километров по стране размотан.
Совпало также, что у атомщиков до этого с успехом завершился проект «Полигон АСУ ТП Бушер АЭС», где всю эту некислую тучу трубопроводов и сопутствующего железа моделировали, чтобы отечественную АСУ ТП проверить. Но, как в нашем богоспасаемом отечестве благочестивыми предками заведено, после победы состоялось награждение не причастных и наказание невиновных. Полигон передали другой организации, которая начала делать модель АЭС уже на американских тренажёрных технологиях.
«…Контракт предполагал разработку прикладного программного обеспечения для всех технологических систем энергоблока, включая системы управления (АСУ ТП), при участии советских инженеров на системной платформе US3 американской фирмы, участие американских инженеров в наладке и испытании разработанного ПО и, что самое главное, – передачу этой технологии для дальнейшей самостоятельной разработки тренажёров…»
Ну а оставшихся не у дел участников команды с полигона Бушер позвали повторить подвиг, но уже в нефтянке. А они уже знали, как мы можем моделировать большие системы, обратились к нам. Так SimInTech – атомная среда моделирования – оказался в проекте ТС ВСТО, совершенно неожиданно для нефтяных менеджеров.
На одном из совещаний при мне был примечательный диалог. Один из эффективных менеджеров из нефтяников, прибывший в составе очередной комиссии, строго спросил:
– А с хера ли тут какая-то непонятная русская убогая программа моделирует наши замечательные нефтяные алгоритмы? Вы что, дебилы, не могли купить нормальный MATLAB Simulink? У вас денег нет? Вы тут свои нищебродские привычки бросайте, здесь вам не тут, у нас солидная нефтяная организация. Только лохи покупают галстук за $10, когда точно такой же можно купить за $200.
– А ты попробуй в своём Simulink собрать хоть одну насосную станцию, а потом приходи сюда выёживаться.
И это был реальный аргумент: ну не мог рассчитывать в 2006 году Simulink такие большие проекты. И манагерам пришлось платить за лицензии русского софта и за создание моделей, хотя видно было, что очень им хотелось купить за нефтедоллары, полученные за углеводороды, отбитые казаком Ермаком у хана Кучума, настоящего американского софта CAE и ездить на конференции, как завещал будущий посол США Макфол. И поэтому, как только мы решили задачу моделирования большой системы как единого объекта модели, в дальнейшем жизненном цикле нашу систему уже почти не применяли. Хотя и мы предлагали присмотреться к генерации кода:
– Всем спасибо, все свободны!
– Модельно-ориентированное проектирование? Генерация кода в контроллеры? SimInTech управляет системой безопасности АЭС?
– Очень, очень интересно, но на́ хер это туда!
Включились в дело корпоративные стандарты. Как объяснял мне один из нефтяных манагер:
– Наш корпоративный стандарт автоматизации – Schneider и Emerson, и не колышет!
И правда, абсолютно не колебало до 2022 года. А теперь колеблет. Теперь ваш корпоративный стандарт автоматизации – «пьяные бабы-роботы»!
Тогда было обидно. Зато сейчас мы можем использовать эти нефтяные алгоритмы для демонстрации возможности SimInTech по сквозному модельно-ориентированному процессу проектирования АСУ ТП от проекта до заливки в любой контроллер. Любой алгоритм – любой контроллер, даже через двадцать лет после его создания.
Часть 2. Практическая.
Открываю модель и начинаю её исследовать. Очень сильно помогает то, что изначально модель планировалась к распечатке в виде альбома: сама модель одновременно является документом, готовым к печати. Оформление модели в SimInTech – это не просто красиво, но удобно и практично: через двадцать лет открываешь как букварь и читаешь.
Поэтому даже без особых знаний в предмете можно понять, о чём идёт речь в алгоритмах: достаточно знания русского языка. Двигаясь по вложенной структуре данных, просто читаем, что написано русским языком.
Вот, например, читаем название алгоритма «Откачка резервуаров НПС двумя насосами ПНА» – и любому понятно, что тут происходит. Даже мне, бывшему физику-ядерщику, понятно.
Многоуровневая структура с разной глубиной вложенности всегда кончается функционально-блочной диаграммой, которую понять может даже школьник. Например, вот функционально-блочная диаграмма из проекта, изображённая на следующем рисунке. Слева – вход, справа – выход, в середине – математика, которая обеспечивает расчёт значений выхода алгоритмов по значениям входа.
В таблицах входов и выходов приведены коды сигналов из базы данных, которые обеспечивают кодирование оборудования по заданной системе. Это удобно для тех, кто работает с проектом: они легко могут прочитать вот такой код: 1N01AD004_1. Для них это первый насос напорного коллектора 4 НПС. Но даже если мы не знаем, что это за насос, мы легко можем это выяснить, используя базу данных сигналов. Чуть попозже покажу как.
Просто читаем, что написано, вернее даже нарисовано. Это просто как раз, два, три:
1) формируем условие 1 включения первого насоса откачки ПНА-1:
Сравниваем давление на входе в МНС с уставкой 4.32. Если значение меньше уставки, включён режим «Откачка на НПС-4 двумя ПНА» и давление на выходе МНС больше 0.8, то условие выполнено.
Если условие 1 выполняется, то включаем насос ПНА-1 (код этого насоса –1N04AD004_1).
2) Если насос ПНА-1 включён, то запускаем таймер на 60 секунд. По истечении этого времени, в случае выполнения всех условий из пункта 1, включается второй насос ПНА-2 (код насоса – 1N04AD004-2).
3) Если насосы включены, то открываем задвижки на линиях с этими насосами.
Для простоты можно представить, что эта единичная диаграмма алгоритма в контроллере запускается с заданным тактом и в каждом такте читает входные сигналы, делает вычисления и записывает выходные сигналы.
Всё именно так и работает, за исключением того, что локальным сигналам каждой диаграммы не требуется чтение – это просто переменные в памяти, имена которых указаны в таблице.
Если не хватает толку понять рисунок или нарисована какая-нибудь совсем сложная хренотень, то вспомни, что SimInTech – это среда моделирования. Всегда можно запустить на расчёт и посмотреть, что же там происходит в этой математике: подсветка линий и отображение значений выходов прямо на схеме во время моделирования.
А для проверки работы пользователь может добавить на схему ключи и во время расчёта включать и выключать эти ключи, чтобы поменять значения сигналов. Для блоков можно в дополнение к значениям на линии связи построить графики и посмотреть, что вообще происходит в программе во время выполнения алгоритма.
Нам нужно найти для демонстрации понятный алгоритм, который обеспечивает некоторый наглядный технологический процесс. Очень желательно, чтобы он был локальным и его можно было запустить на контроллере и проверить моделированием. Модель течения нефти у меня отсутствует – её в проекте 20 лет назад делали на софте другой компании, поэтому модель для проверки работы будем делать тоже в SimInTech, её тоже не хотелось бы сильно усложнять. И алгоритм откачки двумя насосами из ёмкости подходит здесь как нельзя лучше.
Есть два насоса, ёмкость, несколько задвижек и трубопроводов. Всё это можно быстро реализовать в модуле HS SimInTech.
У меня получился вот такой простой проект. Источник с высоким давлением – трубопровод с задвижкой Z11 – обеспечивает наполнение резервуара. Мы можем наполнить резервуар до любого уровня и протестировать алгоритм откачки. Можно посмотреть, как будет проходить откачка, если одновременно идёт наполнение.
Два насоса и три задвижки на линии откачки будут управляться алгоритмами, созданными 20 лет назад. Поэтому имена совпадают с именами в базе данных сигналов старого проекта.
Тут нужно сказать, что мы воспользуемся не только алгоритмами управления: мы возьмём готовую модель задвижек и насосов, которая создана 20 лет назад. Для этого достаточно указать имя задвижки из базы данных сигналов в настройках проекта гидравлики – и всё готово, SimInTech всё остальное сделает за нас. Чтобы было понятно, что это за хрень –база данных сигналов, как её готовить и с чем её едят, посмотрите на следующую картинку. SimInTech позволяет собирать комплексные модели из нескольких проектов:
Каждый из проектов отдельно считает свою математику и обменивается данными через базу данных сигналов. Такая организация модели позволяет легко и просто есть слона по частям. Можно собирать сложную модель, постепенно добавляя модели. Но можно и разбирать: всегда можно отключить любую часть проекта, никак не мешая расчёту остальных частей. С точки зрения отдельных частей модели, отключение выглядит просто как заморозка значений сигналов в базе данных.
Например, если отключили модель теплогидравлики, где рассчитывается давление в трубопроводе, в базе данных останется последнее значение. Модель автоматики продолжает спокойно работать – просто значение давления не меняется. Таким образом, вместо полной модели оригинального нефтепровода я собрал за пять минут гидравлический имитатор отдельного резервуара и подключил его к проекту автоматики.
Это не просто, а очень просто, или элементарно, Ватсон, как говорил Шерлок Холмс. Открываем окно свойств задвижки, заходим в раздел «Связь с базой данных» и записываем имя этой задвижки, которое мы прочитали в алгоритмах управления, – всё! Теперь задвижка управляется из алгоритмов, которые мы исследуем.
Давайте посмотрим, что там в базе данных скрывается под этим именем. Выбираем имя в свойствах, нажимаем «Найти в базе данных» и видим такую картину маслом:
В категории «Блок управления задвижкой» (БУЗ) под номером 230 видим группу сигналов, имя которой совпадает с именем задвижки, заданным в свойствах задвижки на гидравлической схеме. В этой группе целых 83 сигнала. Там есть как параметры задвижки, например, время открытия, время закрытия, положение упоров,команды управления, сигнализация СВБУ, положение исполнительных механизмов и так далее, и тому подобное. Все эти переменные находятся в базе данных, и их можно использовать для выполнения расчётов при моделировании. Что особенно хорошо в базе данных, так это то, что каждая переменная описана русским языком, и даже если я не понимаю, зачем нужна большая часть из них, я всё равно могу найти то, что мне нужно.
Для гидравлики нам нужна всего одна переменная – положение задвижки. Она так и называется: «Положение для модели гидравлики XQ02». Именно это имя сигнала мы используем в настройке задвижки. Полное имя сигнала (переменной) для нашей задвижки выглядит так: 1N04AS004_3_XQ02.
Можно было бы вручную вписать эту переменную в свойствах задвижки при её настройке: «Степень открытия, %» (см. настройки задвижки).
Спрашивается, а что делать с вот этой кучей сигналов в базе данных? Зачем они нужны и куда их девать? А ничего делать и никуда девать их не нужно! Всё уже сделано до нас, за нас и для нас! И теперь у нас в модели есть для этих сигналов готовый волшебный компонент – «Блок управления задвижкой» (БУЗ), который все эти сигналы, переменные и константы обработает и пережуёт, и выдаст в лучшем виде.
Вообще, технология создания типовых блоков в SimInTech – это уникальная фишка, которая позволяет использовать графическое представление математических моделей объектов в концепции объектно-ориентированного программирования (ООП). Я уже писал об этом в двух статьях:
Объектно ориентированное програмирование в графических языках и
ООП в графических языках программирования. ч.2 МОП и ООП
Дело в том, что для типовых блоков, которые многократно повторяются в проекте, можно создать модель в виде графической диаграммы и использовать многократно. Вот, например, как выглядит модель задвижки, которая использует все эти 82 сигнала из базы данных:
Те, кто хоть немного шарит, могут с удивлением обнаружить, что здесь явно нарисована релейная схема – это же язык релейных диаграмм. (Язык релейных или лестничных диаграмм LD (от англ. Ladder diagram) представляет собой простой в обращении графический язык разработки. В его основе лежат релейно-контактные схемы, поэтому элементами логики здесь выступают обмотки реле, контакты реле и линии связи.) Но одновременно здесь же присутствуют и логические блоки.
Да, детка, это SimInTech: здесь можно всё что хочешь. Любой каприз за ваши деньги: хочешь – FBD-диаграмма, хочешь – LD-диаграмма, хочешь – конечные автоматы, и всё это на одной схеме, не отходя от кассы. SimInTech – возможно всё и немного больше.
Видно, что эту модель создавали, глядя на принципиальную электрическую схему, и, скорее всего, это была схема УКТС (Унифицированного комплекса технических средств). В самом деле, вот так выглядела электрическая принципиальная схема УКТС БУЗ для Балаковской АЭС.
Изначально была реальная электрическая плата, которая отвечала за логику работы задвижки и ставилась в шкаф управления – одна плата на одну задвижку. Эта плата получала сигналы, обрабатывала и отправляла команды на электропривод, а также выдавала сигнализацию на локальные пульты управления и блочный щит управления АЭС.
В далёкие времена, когда создавались первые модели, разработчики в SimInTech просто добавили релейные блоки и дали возможность создавать модели прямо на основе принципиальных электрических схем, буквально их повторяя. А уже математическое ядро SimInTech формировало программу управления.
Может показаться странным: зачем делать сложные релейные блоки в графическом языке SimInTech, когда есть простые логические операции? Но кому это вообще нужно? Лично для меня логический блок как операция гораздо понятнее и нагляднее. Но оказалось, все эти шутки про «слаботочников» ни разу не шутки. Есть целый класс специалистов, для которых релейная схема с электрическим током роднее и понятнее, чем эти ваши логические конъюнкции, дизъюнкции и блоки И, ИЛИ.
Для таких слаботочников принципиальная электрическая схема – это самый краткий способ объяснить принципы работы устройства. Ведь описывать словами схемы, во-первых, трудоёмко, а во-вторых, описание словами ведёт к двоякому восприятию, тогда как любая схема жёстко прописывает алгоритм работы.
Для слаботочников специальные учебники пишут, как переводить логические схемы в электрические. Вот, например, как понять работу RS-триггера простому слаботочнику? Надо представить его в виде электрической схемы – и всё станет понятно:
Вот для таких особо одарённых электриков в SimInTech и сделали релейные блоки, чтобы они не пугались сильно, а постепенно привыкали. Потому что SimInTech сделан с заботой о людях, даже если они слаботочники.
Как пишут в одном из учебников:
«Проанализировав несколько схем, вы со временем забудете о преобразовании логических элементов в релейно-контактные схемы и начнёте привыкать к человеческой логике!»
А когда эти схемы переносились в логические схемы при замене железной логики на программную, в SimInTech ничего не менялось – там ровно эта логика и работает в процессе моделирования!
Но если на реальной станции ставились сотни реальных плат, в SimInTech все они моделировались одной-единственной схемой: просто в каждой линии на схеме был вектор из сотен значений сигналов с моделируемых задвижек.
То есть получается, что с помощью SimInTech можно загружать в новые контроллеры не только алгоритмы управления, созданные 20 лет назад в среде SimInTech, но и алгоритмы, созданные 50 лет назад в виде релейных схем УКТС АЭС!
SimInTech – сохраним знания великих предков!
Нужно понимать, что наша модель БУЗ содержит не только программу управления (логику обработки входящих сигналов), но и модель самого электропривода. Это означает, что, получив команду на открытие или закрытие, модель не только выполняет логические вычисления за локальную систему управления, но и моделирует работу электромотора привода задвижки и выдаёт на выходе уже точное положение задвижки в текущий момент времени.
Вот, например, как выглядит этот расчёт для исследуемого проекта ВСТО. Здесь модель электропривода – это простой интегратор с ограничением: приходит команда «Открыть» – значение увеличивается, приходит команда «Закрыть» – значение уменьшается. При этом команды не просто подаются на интегратор для расчёта положения, а ещё предварительно обрабатываются блоком с оригинальным названием «ОТКАЗЫ», в котором, вы ни за что не догадаетесь, на команды накладываются возможные отказы в системе. Например, отказ «Потеря силового питания» приводит к тому, что задвижка стоит на месте при любых командах.
Видно, что в этом сложном полотне схем разобраться, конечно, можно, но это долго, нудно и трудно. Но нам этого делать совсем не нужно. Поскольку это готовая типовая модель, нам уже не нужно в ней разбираться – она работает из коробки. Её, как и другие компоненты, уже умные люди сделали и в десятках проектов оттестировали. Нам надо просто добавить эту задвижку в наш демонстрационный проект и пользоваться ею.
Зачем использовать такую сложную хренотень, если можно просто двигать задвижку в гидравлике по команде алгоритмов? На самом деле не всё так просто. Те алгоритмы, которые мы решили взять для демонстрационного макета, формируют команды: включить насос, выключить насос, открыть задвижку, закрыть задвижку. Для гидравлической модели этого недостаточно – нам нужно знать скорость, с которой открываются задвижки и раскручиваются насосы. Именно для этого в базе данных есть переменные «Время открытия» и «Время закрытия». Всё это рассчитывается вот в этой развесистой диаграмме.
Более того, если посмотреть на базу данных сигналов, то мы увидим, что кроме «Времени открытия» и «Времени закрытия», которые определяют скорость, есть также «Нижний упор», «Верхний упор» для концевых выключателей. Есть также «Люфт», который означает, что задвижка не сразу будет менять направление движения при смене команды, и т.п.
Всё происходит как в реальной жизни: задвижка подключается как готовый блок с кнопкой «Открыть». В жизни оператор из SCADA запускает процесс, нажав на кнопку и получив результат. В процессе выполнения программы формируется команда «Открыть», и она отправляется в блок БУЗ, который и сделает всё «по красоте». Он проверит наличие электропитания, состояние отказов, рассчитает скорость по времени открытия, учтёт люфт, положение концевиков, рассчитает состояние сигнализации, вычислит перемещение задвижки и запишет все необходимые сигналы в базу данных.
Гидравлической модели останется только забрать положение задвижки и рассчитать течение в трубе с учётом этого положения. Сложная модель нефтяного трубопровода собирается легко, как конструктор «Lego», даже легче.
Что очень прикольно: эта схема рассчитывает все задвижки, которые есть в нашей модели ВСТО, – их всего 681 штука, и поэтому по всем линиям на схеме передаётся вектор из 681 числа. Хотя у нас в гидравлике всего 4 задвижки, все остальные в модели присутствуют и рассчитываются. Как сказано выше, модель продолжает считать управление, даже если сама часть, которой нужно управлять (весь нефтепровод ВСТО), исключена из расчёта.
В реальности работать модель будет следующим образом:
1) Алгоритм сформирует команду открыть задвижку.
2) Команда открыть задвижку попадёт в базу данных сигналов.
3) Типовая модель задвижки соберёт команды для всех задвижек в вектор из 681 сигнала, в том числе и нашу команду.
4) По собранным сигналам типовая модель задвижки произведёт расчёт положения исполнительных механизмов всех задвижек и запишет результаты (положение всех задвижек) в базу данных сигналов.
5) Задвижка в модели теплогидравлики прочитает своё положение из базы данных сигналов.
6) Гидравлический модуль рассчитает перепад давления и расход согласно степени открытия задвижки и выдаст показания датчиков.
Чтобы настроить все эти 6 шагов во время расчёта, достаточно, чтобы имя задвижки совпадало с именем группы сигналов в базе данных.
Точно так же мы устанавливаем связь имени насоса с именем в базе данных в свойствах блока – и всё, дело сделано: можно управлять насосом из алгоритмов через базу данных, но не только.
SimInTech – это визуальная среда, поэтому для управления любым блоком на схеме можно вызвать окно управления, из которого наглядно и удобно формируются команды. Например, для базы данных можно войти в базу данных и вручную выбрать команду управления «ОТКРЫТЬ», а можно вызвать окно управления задвижкой на схеме и уже в этом окне подать команду. В последнем случае можно даже не знать, как эта команда называется.
Пользователь просто нажимает кнопку «Открыть», в базу данных сигналов приходит соответствующая команда, а уже блок управления типовым оборудованием начинает рассчитывать процесс открытия с учётом характеристик оборудования, которые тоже заданы в базе данных.
В этом же окне можно ввести отказы оборудования, которые ровно таким же образом будут переданы в базу данных сигналов, где блок управления оборудованием начнёт рассчитывать поведение выбранного оборудования с учётом отказов. Например, можно даже не знать, как называется сигнал в базе данных, отвечающий за отказ «Потеря силового питания», – просто поставим галочку в меню, и задвижка не будет открываться, несмотря на команды управления.
Добавим красоты. Для демонстрационного примера из большой модели можно забрать также видеокадры управления. Все видеокадры нам не нужны, достаточно видеокадра НПС-4, на котором мы должны наблюдать откачку нефти из резервуара. Этот видеокадр у меня также присутствует в модели ВСТО, созданной 20 лет назад. И этот видеокадр тоже открывается в SimInTech, несмотря на то, что прошло 20 лет.
И, как это было сказано выше, нам не обязательно иметь полностью собранную и подключённую модель. Для тех элементов видеокадра, у которых нет соответствующих моделей в теплогидравлике, просто ничего не меняется. Поэтому берём готовый видеокадр и подключаем его к нашей модели.
Кроме видеокадров, мы можем забрать готовые окна управления оборудованием, которые были созданы 20 лет назад. Панели управления подключаются к любому проекту, вызываются по клику и работают с той же самой базой данных сигналов.
В итоге у меня получается модель в виде пакета, которая содержит следующие проекты, обменивающиеся данными через базу данных сигналов:
1) Алгоритм технологический – алгоритм откачки нефти двумя насосами. Этот алгоритм я взял из большой модели для демонстрации возможности загрузки в разные контроллеры.
2) components – проект, в котором содержатся необходимые типовые компоненты для расчётов задвижек, насосов и клапанов.
3) Резервуар – гидравлическая модель резервуара с двумя насосами откачки и задвижками, используемыми в алгоритмах.
4) Controller – часть технологического алгоритма для загрузки в контроллер.
5) mnemo – видеокадр насосной станции из проек��а.
Кроме видеокадров, мы можем забрать готовые окна управления оборудованием, которые были созданы 20 лет назад. Панели управления подключаются к любому проекту, вызываются по клику и работают с той же самой базой данных сигналов.
В итоге у меня получается модель в виде пакета, которая содержит следующие проекты, обменивающиеся данными через базу данных сигналов:
1) Алгоритм технологический – алгоритм откачки нефти двумя насосами. Этот алгоритм я взял из большой модели для демонстрации возможности загрузки в разные контроллеры.
2) components – проект, в котором содержатся необходимые типовые компоненты для расчётов задвижек, насосов и клапанов.
3) Резервуар – гидравлическая модель резервуара с двумя насосами откачки и задвижками, используемыми в алгоритмах.
4) Controller – часть технологического алгоритма для загрузки в контроллер.
5) mnemo – видеокадр насосной станции из проекта.
Алгоритм технологический
Как уже было сказано выше, модель алгоритмов ВСТО была создана в виде альбома, готового к печати. Все алгоритмы разбиты на операции, каждая из которых может быть, в свою очередь, также разбита на операции и шаги. Глубина вложенности не ограничена. На нижнем уровне вложенности у нас будет схема алгоритмов –лист функционально-блочных диаграмм алгоритма.
Операция 1 – здесь выполняется проверка готовности системы к откачке, проверяется оборудование НПС, наличие давления в магистралях и т.п. Поскольку в нашей демонстрационной модели этого оборудования нет, мы принимаем, что система полностью готова к откачке. И чтобы запустить процесс, просто добавляем на схему ручное включение прямо из проекта алгоритмов. Для этого добавляем триггер, который включается от входного сигнала.
Операция 2 – вторая операция обеспечивает подготовку к запуску, которая тоже связана с оборудованием нефтепровода, не входящим в модель нашего стенда. Здесь просто выдаются команды на закрытие одних задвижек и открытие других в той части трубопровода, которой у нас нет в модели, поэтому мы просто оставляем этот алгоритм без изменений.
Операции 3 и 4 – последовательное включение двух насосов и открытие задвижек при получении команды об откачке двумя насосами, а также последовательное выключение насосов при достижении заданных уровней. Именно эти алгоритмы мы и будем переносить на контроллер, поэтому в этом проекте они выключены из расчёта. Это ещё одно преимущество использования базы данных сигналов: любая часть проекта может отключаться и подключаться независимо.
Операция 5 – завершает процесс откачки. Здесь проверяется давление, которое мы не рассчитываем, – принимаем, что оно всегда будет отличным. Проверяется уровень в резервуаре по двум датчикам, и если он ниже 830 мм, то устанавливается команда на завершение процесса откачки.
Резервуар
Эта теплогидравлическая модель, в которой происходит расчёт физики течения жидкости в трубопроводах, наполнение и откачка резервуара. Если запускать её индивидуально, то можно «вручную» управлять системой, включать и отключать насосы, открывать и закрывать задвижки. Можно проводить исследования, подбирать перепады давления, проходные сечения трубопроводов и т.п. Но сейчас модель интересует нас исключительно как средство проверки алгоритмов управления. Для этого мы связываем её с базой данных сигналов. Чтобы связать, нужно просто дать правильные имена объектам (как вы яхту назовёте, так она и поплывёт). Имена у нас уже есть в базе данных сигналов ВСТО, на листах алгоритмов они прямо прописаны, поэтому просто копируем, вставляем – и всё готово!
Во время моделирования модель получает положение задвижек и обороты насоса из базы данных сигналов, рассчитывает давление в системе и расходы по трубопроводам, уровень в резервуаре и записывает в базу данных сигналов показания датчиков. В нашем случае это показание одного датчика – уровня в резервуаре.
Controller
Это проект, в который мы перенесли две диаграммы из технологического алгоритма. Именно эту часть алгоритмов системы управления мы будем переносить в контроллер для демонстрации волшебства работы со средой моделирования. Алгоритмы контроллера мы выключили из расчёта в основном технологическом алгоритме и перенесли в новый проект controller.prt.
Операция 3 – при получении команды начать процесс проверяет уровень в резервуаре, и если он выше 1,5 метра, то открывает задвижку 1N04AS004_3, а через 15 секунд включает насос ПНА-1 (1N01AD004_1). Если насос ПНА-1 включён, то через 30 секунд открывается задвижка 1N04AS004_1, а через 60 секунд включается насос ПНА-2 (1N04AD004_2).
Данный алгоритм обеспечивает заданную последовательность: открытие задвижек и включение двух насосов с заданным временным интервалом между включениями.
В качестве демонстрации мы можем менять время задержки между включениями и последовательность включения насосов, демонстрируя, как быстро и легко можно менять технологические алгоритмы управления в контроллере прямо из среды моделирования.
Операция 4 – обеспечивает отключение насосов и закрытие задвижек при достижении заданного минимального уровня, а также формирует сообщение в систему управления о завершении процесса.
После того как модель создана, мы можем проверить её путём моделирования процессов.
Поскольку и видеокадры управления, и диаграммы алгоритмов созданы в единой среде, я могу любой элемент видеокадра скопировать на расчётную схему. В этом случае легким движением руки элегантные шорты превращаются… схема превращается в видеокадр управления. Мы прямо из схемы можем запустить процесс в контроллере, как с обычной SCADA-системой, и тут же наблюдать, что происходит с насосами, прямо на этой же самой схеме.
Что удобно, когда у вас есть проект большой системы и вы хотите отладить какую-либо произвольную часть проекта.
Как говорится, почувствуй себя нефтяником! Отсоси немного нефти из резервуара.
Модель, которую мы собрали, позволяет наполнять резервуар, открывая вручную задвижку Z11, и запускать алгоритм откачки резервуаров, созданный 20 лет назад в рамках проверки регламента ВСТО, и смотреть, что происходит. Мы можем проверить поведение алгоритмов при разных расходах и уровнях наполнения резервуара.
Обратите внимание, что, используя SimInTech, мы просто копируем два блока с диаграммами алгоритмов из общего проекта в отдельный проект и отключаем их в общем проекте из расчёта. Все подключения, все связи переменных между проектами продолжают работать как ни в чём не бывало, поскольку передача данных происходит через общую базу данных сигналов. И нам не нужно «вручную» устанавливать связи между переменными в разных проектах. Это позволяет просто переносить между проектами и на контроллер любые части наших алгоритмов управления.
После того как всё готово и работает так, как мы задумали, переходим к формированию программы для контроллеров.
На самом деле делать это не просто, а очень просто.
Для начала в настройках проекта укажем имя программы, под которым она будет сохраняться в файлах исходного кода на Си и запускаться на контроллере. Назовём его VSTO_demo.
SimInTech из диаграммы генерирует код ANSI Си, математически однозначно соответствующий диаграмме, созданной в редакторе. Данный код содержит только математические преобразования и может быть использован в любом контроллере, в любой среде, которая поддерживает этот код Си. Можно брать код и руками вставлять в любую среду программирования.
Но зачем работать руками, если разработчики уже всё за вас сделали с помощью шаблонов? В зависимости от выбранного шаблона SimInTech заберёт сгенерированный код Си и добавит всё, что нужно, чтобы этот код мог быть скомпилирован и собран для заданного контроллера. Например, если у нас контроллер ESP32, мы сначала выбираем в настройках директорию, куда всё сложить, – src, и шаблон кода – \ESP32_devboat_v1\
Затем переходим на вкладку «Загрузка», выбираем проект Controller.prt. Устанавливаем период вызова 100 мс и нажимаем кнопку «Пересобрать модули и конфигурации».
После этого в заданной директории появится множество файлов, необходимых для загрузки программы в ESP32.
После этого можно открывать среду разработки VC и собирать проект для заливки в ESP32 штатными средствами, как об этом рассказано в статье: Ядерные погремушки в каждой избушке. Технологии атомной индустрии в автоматизации бытового теплоснабжения
В случае если контроллер работает под Linux, как у меня сейчас, мы выбираем шаблон NordWind_Linux_ARM и сразу получаем в директории готовую библиотеку в формате shared object – VSTO_demo.so.
Её можно вручную загрузить на контроллер под управлением Linux, но можно прямо из SimInTech перейти на вкладку «Отладчик», установить режим отладки — «Удалённая» и прописать сетевой адрес контроллера. После этого у нас появляется возможность прямо из SimInTech запускать и останавливать наш испытуемый контроллер, в который мы грузим готовый алгоритм в виде библиотеки shared object.
И теперь, если в настройках проекта controller.prt указать режим отладки «Удалённый» и указать, что нужно транслировать все входы алгоритмов в исполнительную систему и выходы из неё.
После этого можно запускать пакет с комплексной моделью как обычно. Для пользователя практически ничего не меняется, кроме того, что один из проектов работает не в среде SimInTech на компьютере, а на контроллере. Как говорят модные западные технологи, это режим HIL (Hardware In the Loop), когда процессор залупили с моделью и проверяют его работу. В этом режиме SimInTech отображает на схеме алгоритма процесс управления, можно посмотреть значения на линиях связи и наблюдать вживую, как меняются цифры в блоке задержки. Чистая магия. У волшебника Сулеймана всё по-честному, без обмана.
Магия и её разоблачение.
Давайте разбираться, как это всё работает. На ПЛК под управлением Linux или QNX у нас работает исполнительная система реального времени NordWind. Это диспетчер, который в зависимости от конфигурации запускает различные библиотеки. На следующем рисунке изображена типовая структура ПО, работающего на одном контроллере.
Исполнительная среда запускается при старте системы и читает файл конфигурации. В зависимости от его содержимого запускаются требуемые модули в формате, например:
libio – чтение и запись с карт ввода-вывода в контроллере. Здесь происходит чтение показаний датчиков и передача команд на исполнительные механизмы. Эта библиотека позволяет любому производителю периферийных устройств написать код и создать программу для подключения своих устройств к контроллеру с исполнительной средой NordWind.
libnet – обмен данными по сети между контроллерами (если система распределённая) и системами верхнего уровня SCADA. Сам SimInTech может работать на верхнем уровне как SCADA-система. Видеокадр, который мы использовали в режиме моделирования, может подключиться к контроллеру через этот протокол, отображать реальный технологический процесс для оператора и отправлять на контроллер команды для управления оборудованием.
opcserv – сервер OPC UA, который обеспечивает связь ПЛК с любой SCADA-системой, поддерживающей протокол OPC UA.
gdb_server – сервер отладки, обеспечивающий связь между алгоритмами в среде SimInTech и алгоритмами, скомпилированными в программу для контроллера. Благодаря этому мы можем прямо на схеме наблюдать работу алгоритма.
VSTO_demo.so – алгоритм, который мы создали в среде SimInTech.
Получается, что наш алгоритм в контроллере с заданным тактом проверяет значения входов и рассчитывает команды для выходов. Если посмотреть на диаграмму работы программного обеспечения в контроллере в течение определённого такта, то она выглядит так, как показано на следующем рисунке:
В начале каждого такта происходит чтение карт ввода-вывода, прочитанные значения помещаются в память. Далее выполняются вычисления алгоритма, расчёт выходных значений. Рассчитанные значения записываются в карты ввода-вывода, после этого формируется запись в архивы (если архив предусмотрен в системе), затем рассчитанные значения выходов отправляются по сети в систему верхнего уровня.
У нас с вами демонстрационный стенд, поэтому всё гораздо проще: всё, что не связано с процессором и демонстрационным алгоритмом, берёт на себя среда SimInTech. Мы тестируем только процессор в режиме HIL, в котором крутится, как может, наш алгоритм, сгенерированный из диаграммы SimInTech. Модель запускается в реальном времени в среде SimInTech, при этом расчёт замедляется таким образом, чтобы время в модели соответствовало реальному времени, что позволяет синхронизировать работу модели и контроллера (контроллер всегда работает в реальном времени).
Чтобы этот алгоритм обменивался с внешним миром, нам достаточно одного отладочного сервера (gdb_server).
Этот модуль будет забирать значения входов алгоритмов из базы данных SimInTech и размещать их во внутренней памяти контроллера. Таким образом, алгоритм на каждом шаге (кванте времени) будет работать с данными, которые находятся в базе данных SimInTech. Для алгоритма во время его работы нет разницы, получены эти данные от изменения реального процесса через платы ввода-вывода или из модели SimInTech, где происходит расчёт уровня резервуара.
Результаты работы алгоритма сохраняются в память контроллера на каждом такте, точно так же как и при реальной работе контроллера в составе АСУ ТП. Отладочный сервер забирает выходы алгоритма и передаёт их в базу данных сигналов SimInTech. Там эти сигналы уходят в модель, где происходит необходимый расчёт положения задвижки, пересчёт давления, расходов и уровня, которые тоже передаются в базу данных сигналов.
Получается, что каждая из моделей в комплексном проекте работает с базой данных независимо и не знает, откуда в базе данных появляются данные. Поэтому для любой сложной и распределённой модели можно создавать распределённую систему на ПЛК и достаточно просто заливать в неё ПО и настраивать прямо из модели в SimInTech.
Такое решение обеспечивает проверку алгоритма непосредственно на аппаратуре вместе с комплексной моделью, но на схеме алгоритма мы наблюдаем весь процесс расчёта ровно так же, как мы его наблюдаем при моделировании. Линии связи меняют цвет в зависимости от величины передаваемого сигнала: >0 – розовые, <0 – чёрные; можно посмотреть значение на линии связи. При необходимости можно подключить систему тестирования и гонять различные режимы АСУ ТП, проверяя алгоритмы в ПЛК.
А можно не только исполнять алгоритмы, но и управлять, если у нас к контроллеру подключены реальные платы ввода-вывода?
Разберём на простейшем примере: пусть у нас к контроллеру подключена кнопка включения через плату ввода дискретных сигналов. Добавим в алгоритм, загружаемый в контроллер, ещё один блок, который будет отвечать за взаимодействие с входным дискретным сигналом.
Внутри этого блока находится субмодель, в которой слева расположен стандартный блок записи сигналов в базу данных SimInTech, а справа – блоки, необходимые для инициализации системы чтения входных дискретных сигналов.
Как только мы поставили блок записи в базу данных сигналов, у нас автоматически появился сигнал в базе данных – ButtonOn_A1. Его могут использовать все проекты в пакете.
Специальные блоки взаимодействия с платами ввода-вывода выполняют двойную функцию: во время моделирования в SimInTech они выдают в среде моделирования нужные сигналы, имитирующие работу плат ввода, а при работе на контроллере забирают дискретные сигналы с платы ввода.
В настройках блока мы указываем, к какому контакту (pin) платы ввода подключена наша железная кнопка. Внутри этих блоков размещён необходимый код на Си, который добавляется в общий код модуля при генерации кода. С помощью данного кода осуществляются все необходимые процедуры для инициализации и получения сигналов с плат ввода.
Нажимаем кнопку «Сгенерировать код» и видим в полученном коде для нашего проекта настроенную инициализацию дискретного ввода, к которому мы подключили кнопку.
После этого, если нажать на кнопку, алгоритм получит сигнал с дискретного входа и отправит его в базу данных, в сигнал ButtonOn_A1.
Нам остаётся забрать этот сигнал из базы данных в технологический алгоритм и использовать его для включения режима откачки нефти с физической кнопки. И если объединить этот сигнал с ручным запуском через блок «ИЛИ», то мы получим два варианта запуска алгоритмов. Таким образом, мы можем запускать демонстрационный алгоритм как из проекта технологического алгоритма в SimInTech, так и нажимая физическую кнопку.
Выводы
Полученный демо-пример показывает, как создавать управляющее программное обеспечение АСУ ТП, полностью независимое от производителей аппаратуры.
На глазах изумлённой публики мы взяли алгоритмы, разработанные 20 лет назад, и загрузили их в современный контроллер отечественного производителя. Этот подход делает проектантов и хозяев сложных технологических производств и процессов абсолютно независимыми от диктата производителей АСУ ТП.
Долой диктат производителей аппаратуры!
Даёшь суверенную АСУ ТП каждому технологическому процессу!
Ну а производители контроллеров, вместо того чтобы разрабатывать свои собственные среды разработки или сидеть на неправославном CodeSys, могут спокойно брать SimInTech и создавать программы управления легко и просто, как показано в данной статье. И в видео ниже.
Подписываейтесь на канал Технолог Петухов, там еще больше тяжелого дижитала и без цензуры.
