Найти в Дзене

Разработка программного обеспечения для ПЛК путем генерации кода из созданной математической модели объекта управления.

Авторы:
Олейников В.С.- старший преподаватель высшей школы киберфизических систем и управления.
Пересвет В.А., Курочкина В.С., Бурячек И.Ю. - студенты.
Большинство современных автоматизированных систем управления строится на основе программируемых логических контроллеров (ПЛК), управляющих процессами по заданному алгоритму работы при помощи считывания данных с датчиков и отправки управляющих сигналов на исполнительные устройства. Использование ПЛК позволяет реализовать выполнение достаточно сложных и разветвлённых алгоритмов, а также применять различные способы автоматизации. В частности, во многих системах управления внедрено автоматическое регулирование параметров технологического процессов, которое традиционно осуществляется по законам релейного и ПИД-регулирования [1]. Чаще всего при написании программного обеспечения (ПО) для ПЛК его отладка производится непосредственно на объекте управления. В случае отсутствия или недоступности технологического объекта разработка и отладка ПО у

Авторы:
Олейников В.С.- старший преподаватель высшей школы киберфизических систем и управления.
Пересвет В.А., Курочкина В.С., Бурячек И.Ю. -
студенты.

Большинство современных автоматизированных систем управления строится на основе программируемых логических контроллеров (ПЛК), управляющих процессами по заданному алгоритму работы при помощи считывания данных с датчиков и отправки управляющих сигналов на исполнительные устройства. Использование ПЛК позволяет реализовать выполнение достаточно сложных и разветвлённых алгоритмов, а также применять различные способы автоматизации. В частности, во многих системах управления внедрено автоматическое регулирование параметров технологического процессов, которое традиционно осуществляется по законам релейного и ПИД-регулирования [1].

Чаще всего при написании программного обеспечения (ПО) для ПЛК его отладка производится непосредственно на объекте управления. В случае отсутствия или недоступности технологического объекта разработка и отладка ПО усложняется и замедляется, так как разработчику потребуется вручную имитировать данные, приходящие от датчиков, и отслеживать соответствие реакций системы алгоритму её работы на всех этапах процесса [2].

При создании систем со сложными алгоритмами управления и несколькими контурами необходимо гораздо больше ресурсов, особенно времени, для настройки управления и отладки программ, так как необходима проверка множества параметров объекта управления и правильности взаимодействия всех частей системы [3]. Кроме того, отладка ПО сложных систем на реальном объекте может приводит к повреждению оборудования, перерасходу материалов и т. п.

Таким образом, если программное обеспечение разрабатывается для систем управления повышенной алгоритмической сложности или при отсутствии доступа к объекту управления, то целесообразнее создавать имитационную модель быть, объекта управления, которая обеспечивает более быструю и точную отладку программ для ПЛК, исключает риск повреждения оборудования и позволяет сэкономить ресурсы [4].

Моделирование системы можно выполнить непосредственно в среде программирования ПЛК, используя средства языков программирования МЭК 61131-3. Тем не менее, такой способ проблематично использовать при необходимости создания более сложной математической модели, так как отсутствие функциональных блоков многих передаточных функций и ограниченность математического аппарата в системах разработки программ ПЛК значительно усложняют составление точной модели объекта управления [1, 5]. Несмотря на недостатки такого подхода, он остаётся достаточно популярным, так как является доступным и оперативным решением, но используется без построения точных математических моделей, на уровне имитации управляющих сигналов и состояния датчиков (см. рис. 1).

Рисунок 1 – UML-диаграмма моделирования в среде программирования ПЛК
Рисунок 1 – UML-диаграмма моделирования в среде программирования ПЛК

Вторым подходом является создание имитационной модели в среде математического моделирования. Такое решение не является распространённым, так как работа ПО управления технологическим процессом осуществляется на ПЛК, а данный метод затрудняет возможность связи модели объекта с программой управления, работающей на контроллере.

Одним из решений этой проблемы является объединение сред программирования ПЛК и математического моделирования с помощью технологии OPC (Open Platform Communications) [5, 6], предоставляющей универсальный интерфейс для управления объектами автоматизации и обеспечивающей обмен данными между ПК и ПЛК в режиме реального времени (см. рис. 2). Применение такого метода позволяет оценить работу всего алгоритма АСУ ТП и применять изменения при отладке системы как в математической модели, так и в логике ПЛК [5], но это также подразумевает необходимость наличия ПК с математической моделью, запущенной в среде моделирования, и зависимость от корректной работы всех компонентов, используемых в комбинированной системе создания модели. Кроме того, в этом случае процесс организации связи между программой управления и моделью объекта является весьма трудоёмкой задачей, а программа управления требует добавления коммуникационного функционала.

Рисунок 2 – UML-диаграмма моделирования с помощью технологии OPC
Рисунок 2 – UML-диаграмма моделирования с помощью технологии OPC

В ходе изучения вопроса о повышении эффективности отладки управляющего ПО для ПЛК в Санкт-Петербургском политехническом университете Петра Великого был опробован и проверен метод разработки программного обеспечения в среде моделирования, при котором осуществляется генерация кода для ПЛК из созданной математической модели. Отладка сгенерированного ПО и связь модели с программой управления происходит уже непосредственно в среде программирования ПЛК. Этот способ позволяет воспользоваться преимуществами каждой из сред, применяемой для моделирования системы и проверки её работы [3], избегая необходимости полагаться на надёжность их совместной работы, обеспеченной сторонними решениями, и используя при этом только контроллеры без привлечения ПК. В данном случае модель объекта управления и программа управления находятся на разных ПЛК, связанных между собой с помощью физических сигналов, поэтому система управления не требует дополнительного функционала, обеспечивающего связь с моделью (см. рис. 3).

Рисунок 3 – UML-диаграмма связи системы и объекта управления
Рисунок 3 – UML-диаграмма связи системы и объекта управления

Для реализации данного подхода была использована среда моделирования MATLAB Simulink с последующей генерацией в код на языке структурированного текста (ST) при помощи специализированного пакета PLC Coder [7] и дальнейшей работой с программой в среде разработки приложений для ПЛК CoDeSys 3.5.

В качестве технологического объекта моделирования был взят индивидуальный отопительный пункт (ИТП) с водоструйным элеваторным узлом, представленный на рисунке 4. Элеватор необходим для понижения температуры теплоносителя, приходящего с магистралей тепловых сетей. Согласно пункту 6.1.6 СП 60.13330.2016 [8] предельная температура теплоносителя, поступающего в здание, должна составлять 95 °С, в то время как по внешним трубопроводам отопления подаётся теплоноситель температурой до 130 °С‒150 °С. В элеваторном узле смешивается теплоноситель, поданный из тепловой магистрали, с охлажденным, вернувшимся из системы отопления, в результате чего в здание подается теплоноситель, имеющий необходимую температуру.

Рисунок 4 – Схема элеваторного узла: К1 – задвижка, Т1, Т01, Т02 – термометры,  ВЭ1 – водоструйный элеватор, G1, G2 – расход теплоносителя в подающем и обратном трубопроводах на вводе (G1 = G2), G3 – расход теплоносителя через перемычку, 
G0 – расход теплоносителя в системе отопления здания
Рисунок 4 – Схема элеваторного узла: К1 – задвижка, Т1, Т01, Т02 – термометры, ВЭ1 – водоструйный элеватор, G1, G2 – расход теплоносителя в подающем и обратном трубопроводах на вводе (G1 = G2), G3 – расход теплоносителя через перемычку, G0 – расход теплоносителя в системе отопления здания

Данный объект управления был выбран для разработки системы управления с погодным регулированием, повышающим энергоэффективность, и отладки на мобильном стенде изучения принципов промышленной автоматизации и моделирования технологических процессов. Проект реализован при поддержке Политехнического университета в рамках программы 5-100 как проект-победитель грантового конкурса СПбПУ «Polytech Project».

Температура поступающего в нагревательные приборы теплоносителя Т01 определяется в результате смешивания теплоносителя, поступающего из подающего трубопровода и имеющего температуру Т1 и расход G1, и теплоносителя из обратного трубопровода, имеющего температуру Т02 и расход G3. Расход теплоносителя в системе отопления здания G0 не меняется, соответственно, можно вывести соотношение, отражённое в формуле (1).

-5

Таким образом, закон сохранения количества теплоты в элеваторном узле будет иметь следующий вид:

-6

Уравнение объекта управления примет вид [9]:

-7

Учитывая формулы (1)‒(3), представим математическую модель системы отопления с элеваторным узлом в виде структурной схемы, отображённой на рисунке 5, где u равняется отношению G3 к G1.

Рисунок 5 – Структурная схема системы отопления с элеваторным узлом
Рисунок 5 – Структурная схема системы отопления с элеваторным узлом

Создадим математическую модель объекта в MATLAB Simulink (см. рис. 6). Параметры k, T1 и T2 изменяются в зависимости от наружной температуры.

Рисунок 6 – Математическая модель объекта в MATLAB Simulink
Рисунок 6 – Математическая модель объекта в MATLAB Simulink

PLC Coder не имеет средств для работы с аналоговыми блоками [7], поэтому необходимо выполнить дискретизацию модели, которая позволяет заменить непрерывные блоки апериодических звеньев на их дискретные эквиваленты. Во вкладке Analysis выбираем пункт Control Design, а затем подпункт Model Discretizer.

В окне дискретизации модели (см. рис. 7) необходимо задать метод преобразования. В поле Transform method выбираем билинейное преобразование (преобразование Тастина) — конформное отображение, используемое для преобразования непрерывной передаточной функции в дискретную передаточную функцию. В поле Replace current selection with указываем дискретные блоки (вводят параметры в s-область). Это действие создает дискретные блоки, параметры которых аналогичны параметрам соответствующих непрерывных блоков. Нажимаем кнопку s→z для перехода от s-плоскости к z-плоскости.

Рисунок 7 – Настройка параметров дискретизации модели
Рисунок 7 – Настройка параметров дискретизации модели

Для упрощения модели сгруппируем блоки в подсистему. Выделяем нужные объекты и в контекстном меню выбираем пункт Create Subsystem for Selection. Результат создания подсистемы отображён на рис. 8.

Рисунок 8 – Созданная подсистема
Рисунок 8 – Созданная подсистема

Удаляем алгебраические циклы путём добавления единичных задержек с помощью блоков Unit Delay, которые выполняют задержку входного сигнала на один шаг модельного времени (см. рис. 9). Каждый сигнал может быть как скалярным, так и векторным. При векторном входном сигнале задержка выполняется для каждого элемента вектора. Блок поддерживает работу с комплексными и действительными сигналами.

Рисунок 9 – Добавление блоков Unit Delay
Рисунок 9 – Добавление блоков Unit Delay

Открываем параметры конфигурации модели, которые можно вызвать с панели инструментов, и выбираем вкладку решателя (Solver). В поле Type устанавливаем вид решателя, в данном случае с фиксированным шагом (Fixed-step), а решатель выбираем цифровой без непрерывных состояний – discrete (no continuous states), он будет использоваться для вычисления состояния модели во время моделирования или генерации кода (см. рис. 10). Применяем заданные параметры.

Рисунок 10 – Настройка параметров решателя
Рисунок 10 – Настройка параметров решателя

Указываем в поле времени окончания моделирования на панели инструментов необходимое время, выраженное в секундах, например 36000 секунд (10 часов), и запускаем симуляцию модели. Полученный график отображен на рис. 11.

Рисунок 12 – Настройка монолитности подсистемы
Рисунок 12 – Настройка монолитности подсистемы

Прежде чем программное обеспечение начнет анализ, оно проверяет совместимость модели, а затем создает представление модели. Для проверки совместимости подсистемы выбираем пункт PLC Code в контекстном меню подсистемы, а затем подпункт Check Subsystem Compatibility. Если модель совместима, то программа не выдаст ошибок и можно работать дальше.

После проверки совместимости открываем параметры конфигурации модели и заходим на вкладку генерации кода ПЛК (PLC Code Generator). Выбираем целевую среду разработки (Target IDE), в данном случае это 3S CoDeSys 3.5, далее применяем заданные параметры и нажимаем на кнопку генерации кода (см. рис. 13). Сгенерированный код сохраняется в папке plcsrc, находящейся в той же директории, что и проект.

Рисунок 13 – Настройка параметров генерации кода ПЛК
Рисунок 13 – Настройка параметров генерации кода ПЛК

В контекстном меню подсистемы модели выбираем пункт PLC Code и подпункт Generate Code for Subsystem для генерации кода на языке ST. Если операция прошла успешно, то появляется окно, информирующее о положительном результате. Название файла с кодом будет такое же, как у проекта, в нашем случае это PLC_Model.xml.

Переходим в CoDeSys 3.5, создаём стандартный проект, во всплывающем окне выбираем программируемое устройство и язык программы PLC_PRG (см. рис. 14).

Рисунок 14 – Создание стандартного проекта в CoDeSys 3.5
Рисунок 14 – Создание стандартного проекта в CoDeSys 3.5

Для импортирования сгенерированного из Simulink-модели кода выбираем во вкладке Проект пункт Импорт PLCopenXML и в открывшемся окне указываем необходимые нам элементы для импорта (см. рис. 15). После этого в POU добавится функциональный блок подсистемы, созданной в Simulink, и два файла: с константами и с переменными.

Рисунок 15 – Выбор элементов для импорта
Рисунок 15 – Выбор элементов для импорта

Задаём необходимые переменные и создаём вызов функционального блока подсистемы (см. рис. 16).

Создаём визуализацию для построения графика в реальном времени, используя специальные элементы управления [10]. Выбираем графический примитив Трассировка и задаём его конфигурацию, для этого можно выбрать пункт Трассировка в свойствах графического элемента, либо использовать команду Конфигурация трассировки в контекстном меню элемента. В поле Задача указывается POU, предоставляющий данные для визуализации (см. рис. 17). В левом поле добавляются элементы отображения, по нажатию на которые можно задать их параметры.

Рисунок 16 – Задание параметров функционального блока подсистемы
Рисунок 16 – Задание параметров функционального блока подсистемы

Задаём оси трассировки: вертикальная представляет собой температурную шкалу от 0 °С до 80 °С, горизонтальная – временной диапазон длиной в 10 часов (см. рис. 18). Вкладка делений отображается некорректно в русскоязычной версии CODESYS V3.5 SP11 Patch 5 [10]. Для изменения языка интерфейса следует в меню Инструменты выбрать пункт Опции, перейти во вкладку Международные установки и изменить язык на английский.

Рисунок 17 – Конфигурация трассировки
Рисунок 17 – Конфигурация трассировки
Рисунок 18 – Настройка оси трассировки
Рисунок 18 – Настройка оси трассировки

Задаём тип конфигурации PLC_PRG, в нашем случае циклический с интервалом в 100 миллисекунд (см. рис. 19) [11].

Рисунок 19 – Настройка конфигурации PLC_PRG
Рисунок 19 – Настройка конфигурации PLC_PRG

Чтобы запустить программу и получить график симулируемого процесса (см. рис. 20), выбираем пункт Логин во вкладке Онлайн, а затем во вкладке Отладка нажимаем Старт.

Рисунок 20 – График симулируемого процесса в CoDeSys 3.5
Рисунок 20 – График симулируемого процесса в CoDeSys 3.5

Литература

1. Рыбалев, А. Н. Компьютерное моделирование нетиповых законов регулирования для программируемых логических контроллеров / А. Н. Рыбалев // Информатика и системы управления. – 2016. – №4 (50). – С. 33–43.

2. Создание имитационных моделей технологических процессов для отладки программ ПЛК и проектов SCADA/HMI / Н. Н. Луцкая, А. Н. Пупена, С. Н. Швед // Автоматизация в промышленности. – 2013. – №7. – С. 50–54.

3. Разработка и реализация на базе ПЛК комплексных стратегий управления / П. Кодати, Т. Эрккинен, А. Туревский ; Softline // Электронные компоненты. – 2012. – №3. – С. 79–82.

4. Model-Based Systems Engineering of Process Control for Energy Installations / V. Khokhlovskiy, V. Oleinikov // 2019 International Multi-Conference on Industrial Engineering and Modern Technologies : материалы конференции, 1–4 октября 2019 г., Владивосток. – [Пискатауэй, Нью-Джерси, США] : IEEE, 2019. – С. 384-389. – DOI 10.1109/FarEastCon.2019.8934790

5. Бракоренко, А. С. Моделирование технологических процессов в ходе разработки и отладки автоматических систем управления технологическими процессами / А. С. Бракоренко // Вестник ГГТУ им. П. О. Сухого. – 2014. – №4 (59). – С. 69–76.

6. Разработка и эмулирование АСУ ТП с использованием программ разных производителей и типов / А. Н. Рыбалев, Ф. А. Николаец // Вестник Амурского государственного университета. Серия: Естественные и экономические науки. – 2014. – №65. – С. 73–82.

7. Simulink® PLC Coder™ User's Guide / The MathWorks, Inc. – Version 3.3 (Release R2020b). – Natick, MA, United States, 2020. – 364 с. – URL: https://www.mathworks.com/help/pdf_doc/plccoder/plc_st_ug.pdf. (дата обращения: 20.09.2020). – Текст. Изображение : электронные.

8. СП 60.13330.2016 Отопление, вентиляция и кондиционирование воздуха = Heating, Ventilation and Air Conditioning : свод правил : актуализированная редакция СНиП 41-01-2003 (с Изменением N 1) : утвержден приказом Министерства строительства и жилищно-коммунального хозяйства Российской Федерации от 16 декабря 2016 г. № 968/пр : дата введения: 2017-06-17 / подготовлен Департаментом градостроительной деятельности и архитектуры Министерства строительства и жилищно-коммунального хозяйства Российской Федерации. – Москва, 2017. – 117 с.

9. Солдатенков, А. Е. Автоматизация децентрализованного отопления комплекса зданий с основными схемами теплопотребления : специальность 05.13.16 «Автоматизация и управление технологическими процессами и производствами (строительство)» : диссертация на соискание ученой степени кандидата технических наук / Солдатенков Алексей Сергеевич ; Белгородский государственный технологический университет им. В. Г. Шухова. – Белгород, 2014. – 196 с. – Библиогр.: с. 143–154. – Текст : непосредственный.

10. CODESYS V3.5. Визуализация / ОВЕН. – Версия 2.0. – Москва, 2018. – 443 с. – URL: https://ftp.owen.ru/CoDeSys3/11_Documentation/03_3.5.11.5/CDSv3.5_Visu_v2.0.pdf (дата обращения: 22.09.2020). – Текст. Изображение : электронные

11. Шаги расчета в системах. – Текст : электронный // ЦИТМ Экспонента : [сайт]. – 2020. – URL: https://docs.exponenta.ru/simulink/ug/managing-sample-times-in-systems.html (дата обращения: 23.09.2020)