Содержание к диссертации
Введение
ГЛАВА 1. Состояние вопроса, цель и задачи исследования 11
1.1 Технологический процесс как объект управления 13
1.2 Формулировка критериев разработки систем управления технологическими процессами в промышленности 15
1.3 Состав и характер задач, решаемых при разработке систем управления технологическими процессами 17
1.4 Обзор процесса разработки специального программного обеспечения 23
1.5 Цель и задачи исследования 26
ГЛАВА 2. Программные аспекты структуры управления технологическими процессами 28
2.1 Архитектура современных АСУТП 29
2.2 Программируемый логический контроллер 32
2.3 Конечные автоматы и программирование ПЛК 34
2.4 Средства разработки программного обеспечения для ПЛК 36
2.5 Разработка SCADA-систем 43
2.6 Применение моделирования в разработке СПО для АСУТП 47
2.7 Выводы из главы 2 50
ГЛАВА 3. Предлагаемая методика разработки программной части проектов автоматизации ТП 52
3.1 Система компьютерных моделей 52
3.2 Формулировка предлагаемой методики 58
3.3 Выбор компьютерных моделей 62
3.3.1 Применение технологии автоматного программирования 65
3.3.2 Применение методологии разработки DSL 70
3.4 Единая информационная среда разработки СПО для СУ ТП 79
3.4.1 Верификация моделей 83
3.4.2 Генерация программного кода 86
3.4.3 Интеграция инструментального средства «MetaAuto» в ЕИС 89
3.4.4 Разработка СПО для СУ ТП в ЕИС 91
3.5 Архитектура построения программ для ПЛК 93
3.6 Выводы из главы 3 97
ГЛАВА 4. Экспериментальное исследование разработанной методики на примере проекта энергетической отрасли 98
4.1 Выкладка из технического задания 98
4.2 Разработка прототипа СУ ТП 110
4.3 Моделирование программ ПЛК 114
4.4 Экспериментальное тестирование разработанной СУ ТП 121
4.5 Выводы из главы 4 123
Основные результаты и выводы 126
Список сокращений и условных обозначений 128
Список литературы 130
- Состав и характер задач, решаемых при разработке систем управления технологическими процессами
- Конечные автоматы и программирование ПЛК
- Формулировка предлагаемой методики
- Моделирование программ ПЛК
Состав и характер задач, решаемых при разработке систем управления технологическими процессами
Автоматизация технологических процессов начала своё развитие с возникновением первых производств и до 18-ого века представляла собой применение самодействующих устройств. Самодействующие устройства применялись для механизации локальных небольших операций технологического процесса в прядильном, ткацком, металлообрабатывающем и деревообрабатывающем производствах как обособленные механизмы. В 18-19 веках в условиях промышленной революции и резкого увеличения масштабов производства, возникла необходимость в замене человека в производственных процессах машинами и специальными механизмами. Это послужило началом развития принципиально нового направления технического прогресса – «автоматической системе машин», в котором человек является наблюдателем и оставляет за собой право на принятие управленческого решения. Причинами сохранения человеческого контроля над процессом управления могут быть сложность или нецелесообразность автоматизации как ТП в целом, так и отдельных его операций.
В промышленности только в 1769 году впервые была применена система автоматического регулирования (САР). Это был разработанный Джеймсом Уаттом автоматический центробежный регулятор скорости вращения вала паровой машины. Спустя почти сто лет британский физик, математик и механик – Джеймс Клерк Максвелл (Член Лондонского королевского общества) заложил математические основы теории управления, используя дифференциальное уравнение как модель регулятора. И в 1868 году создал математическую модель регулятора для паровой машины. В 1913 году Генри Форд на своем предприятии внедрил механизированную сборку автомобилей, в 1952 году в Массачусетском технологическом институте разработаны станки с числовым программным управлением (ЧПУ) и т.д. На производствах всего мира начали использовать автоматические и автоматизированные СУ, преследуя одну цель, – повысить эффективность использования потенциальных возможностей объекта управления (ОУ).
Во второй половине 20-ого века центральное место в архитектуре систем автоматизации ТП заняли программируемые устройства автоматизации. Первым отечественным устройством такого класса считается микропроцессорный контроллер «Ремиконт Р-100», разработанный под руководством Певзнера В.В. [3].
Основы науки об автоматическом управлении были заложены английским физиком Дж. К. Максвеллом и русским ученым И. А. Вышнеградским в совместном труде «Теория автоматического регулирования (линеаризованные задачи)» [4]. В России систематизацией и развитием теории автоматического регулирования занимались ученые: М.А. Айзерман [5], А.А. Воронов [6], Е.П. Попов [7], А.Я. Лернер [8].
Родоначальником «математической теории управления» считается великий русский математик и механик Александр Михайлович Ляпунов – автор классической теории устойчивости движения [9].
В настоящее время в России развитием и применением теории управления в сфере автоматизации производств занимается один из ведущих научных центров – Институт проблем управления им. В.А. Трапезникова РАН (созданный в 1939 году как Институт автоматики и телемеханики (ИАТ) АН СССР).
В рамках данной диссертационной работы под ОУ понимается ТП, а рассматриваемые СУ предназначены для автоматизации ТП. 1.1 Технологический процесс как объект управления
В данной диссертационной работе ТП рассматривается как объект автоматизации, управление которым основано на ПЛК. Тип ТП (стационарный, передвижной, дискретный, непрерывный и др.), как и его назначение, характеристики сырья, топлива или основного продукта в данной работе не рассматриваются.
Современные ТП являются сложными ОУ с большим количеством входных, выходных переменных и сложными нелинейными связями между ними.
В научных трудах по «Теории управления» [10-12] и «Теории систем» [13-15] объекты и процессы, подлежащие управлению, представляются схематично в виде одномерного или многомерного объектов. Представление ТП в виде многомерного объекта также применяется в системах поддержки управления качеством продукции [16-18].
Конечные автоматы и программирование ПЛК
В двадцать первом веке в сфере разработки программного обеспечения уже активно применяется теория моделирования.
Для моделирования программных систем в 2001 году группой «Object Management Group (OMG)» был запущен проект «Model-Driven Architecture» (проектирование на базе моделей) [45,46], который стал новым направлением в программной инженерии. Основной идеей этого подхода является независимое рассмотрение моделей, создаваемых при проектировании системы, от деталей их реализации на конкретной программно – аппаратной платформе [47,48].
Подход на основе моделей позволяет неразрывно связать все этапы разработки ПО – от сбора и анализа требований до приемочного тестирования. Сама идея модельно-ориентированного проектирования является революционной в программной инженерии и позволяет идти в ногу с темпами роста сложности программного управления ТП.
В области разработки СПО для ПЛК данный подход нашел своё отражение в виде программного пакета «Simulink PLC Coder» компании «MathWorks» [49]. Программный пакет предназначен для моделирования сложных математических функций и генерации аппаратно-независимого программного кода на языке структурного текста “Structured text” по диаграммам «State flow» и встроенным функциям «MATLAB» (сокращение от англ. «Matrix Laboratory») [50].
Компания «MathWorks» объявила о выпуске первого продукта — «Simulink 5.0.2» в 2002 году. С тех пор программный пакет эволюционировал до версии «Simulink 8.1» 2013 года. Данный продукт позволяет автоматически генерировать согласно стандарту «IEC 61131» программный код для ПЛК. Это нововведение позволяет использовать модельно-ориентированное проектирование для промышленного и силового оборудования, управляемого ПЛК [51].
С помощью «Simulink PLC Coder» инженеры могут автоматически генерировать код для промышленных систем управления, включая замкнутые системы и системы контроля с обратной связью [52]. Автоматическая генерация кода – неотъемлемая часть модельно-ориентированного проектирования – помогает устранить ошибки, связанные с традиционным «ручным» написанием программного кода, и уменьшает время разработки и тестирования СПО.
Помимо продукции компании «MathWorks» существует множество других программных средств модельно-ориентированного проектирования для систем как с открытой, так и с закрытой архитектурой. Например, программный продукт «LabVIEW» компании «National Instruments» [53-54] (последняя версия продукта: LabVIEW 2012 - 12.0.0.4029 - August 2012) [55], «KTechlab» [56], «Microsoft Visual Programming Language» или «MVPL» [57], «IBM Rational Rose» [58-59] и др. Как правило, в современных программных пакетах графические языки программирования основаны на нотации UML [60-62]. Наиболее часто применяются диаграммы «Flowchart» и «Stateflow» [63-65].
Сразу следует отметить, что моделирование сложной логики поведения системы на языке UML затруднено в связи с отсутствием в стандарте формального однозначного описания правил интерпретации поведенческих диаграмм. Кроме того, связь поведенческих диаграмм с кодом на целевом языке программирования в современных широко известных средствах моделирования, например, «IBM Rational Rose», реализована слабо, либо вообще не реализована [66].
Также следует отметить, что все современные среды модельно-ориентированного проектирования предоставляют массу различных решений в рамках пока только одного ФБ. То есть программист моделирует отдельные части ТП, абстрагируясь от системы в целом и от деталей реализации на конкретной программно-аппаратной платформе. Это лишает программный код всего проекта общей структуры. Конечный программный продукт «собран» из функций и функциональных блоков, написанных на разных языках и в разных стилях. Часть программного кода генерируется автоматически по различным правилам преобразования, другая часть пишется вручную несколькими разработчиками, у каждого из которых своя манера разработки программного кода. Как следствие программный код очень трудно читать и сопровождать. Или часто бывает дешевле разработать новое СПО.
Еще одна серьезная проблема применимости современных средств моделирования к разработке СПО для ПЛК – это отсутствие связей между моделями отдельных подсистем или функций. Нет возможности создать единую целостную модель, объединяющую все подмодели. Нет однозначных правил трансформации моделей в программный код и, как следствие, программный код не имеет единой структуры. Назовем это свойство «динамической привязкой программного кода к единой модели».
Таким образом, современные средства модельно-ориентированного проектирования в рамках индустрии промышленной автоматизации позволяют создавать модели и генерировать по ним программный код только для компонента, части системы. СПО самой системы в целом является статичным. То есть по единой модели системы нельзя сгенерировать программный код, необходимо для каждой модели отдельной подсистемы определить правила трансформации в исходный код и выполнить преобразование. А потом связать все сгенерированные исходные коды подсистем в единое СПО. При отсутствии связей между моделями подсистем («подмоделями») и однозначных правил их преобразования в исходный код структура модели системы является нецелостной. Модель не имеет динамического свойства.
При работе над небольшими проектами современных средств моделирования вполне достаточно для разработки СПО на основе моделей. Однако при больших и сложных проектах (более 5000 точек контроля и управления ТП, распределенная архитектура, различные ПЛК, протоколы передачи данных и т.д.) этих возможностей уже недостаточно для эффективной разработки СПО.
Формулировка предлагаемой методики
Подсистема управления комплектной трансформаторной подстанцией собственных нужд (КТП СН) и распределительным устройством (РУ 0,4кВ).
Контролируемые подсистемой параметры: состояние автоматических выключателей на отходящих линиях РУ 0,4кВ; состояние автоматических силовых выключателей QF1-QF4; тепловое состояние трансформаторов первой и второй секции; контроль параметров электрической сети на вводах от трансформаторов и на вводе от резервной дизельной электростанции. Контроль теплового состояния осуществляется по дискретным сигналам от каждого трансформатора, по которым формируется аварийная сигнализация.
Контроль параметров электрической сети осуществляется по информации, получаемой от многофункциональных измерителей «РМ710» по цифровой сети. В том числе по этим данным определяется наличие напряжения на вводах и на выходе РДЭС, что необходимо для управления схемой автоматического ввода резерва (АВР) в автоматическом режиме.
Управление силовыми выключателями QF1-QF4 и контроль их состояния осуществляется через дискретные сигналы. Входные сигналы от каждого выключателя:
Сигнал состояния РДЭС поступает по цифровой сети от подсистемы управления РДЭС. Управление выключателями может осуществляться индивидуально, по командам оператора или автоматически для обеспечения АВР. Имеется два режима работы схемы АВР, выбор каждого из которых осуществляется переключателем на лицевой панели РУ 0,4 кВ. В «Ручном режиме» на действия оператора не влияет работа схемы автоматики. Управление аппаратами QF1, QF2, QF3, QF4 производится с лицевой панели РУ 0,4 кВ. Пуск и остановка РДЭС в Ручном режиме производится из блок-модуля РДЭС.
В автоматическом режиме управление вводными и секционным выключателями РУ 0,4 кВ производится без участия персонала. Предусматривается контроль исправности дополнительных контактов, регистрирующих положение главных контактов силовых автоматов и их готовность к переключению (сигнал «Автоматический выключатель готов к включению»). В случае несоответствия состояния блок контактов выключателя положению главных контактов включается индикация «Авария резервирования», отключается и блокируется дальнейшая работа схемы АВР в автоматическом режиме. То же происходит при отсутствии готовности их к переключению. Пуск и Останов РДЭС в автоматическом режиме также производится автоматически. Алгоритм работы схемы АВР: при исчезновении питания на одном из вводов с выдержкой времени (от 0 до 1 минуты) отключается выключатель ввода, с которого исчезло напряжение, контролируется его положение и включается секционный выключатель; при восстановлении питания на вводе порядок переключения вводных и секционного выключателей зависит от состояния секционного выключателя 6,3кВ. При включенном секционном выключателе при восстановлении напряжения на вводе производится его контроль и через заданное время сначала включаются QF1 и QF2. После их включения отключается QF3. Если секционный выключатель отключен, то при восстановлении напряжения на вводе производится его контроль и через заданное время включается QF1 или QF2, в зависимости от того какой ввод восстановился. Включение второго ввода при замкнутом секционном выключателе QF3 и разомкнутом секционном выключателе 6,3кВ блокируется; при исчезновении напряжения на обоих вводах через заданное время дается команда на отключение обоих вводных выключателей (QF1 и QF2). Производится контроль положения вводных выключателей и после подтверждения их отключения дается команда на пуск РДЭС (двухсекундным импульсом). При получении сообщения РДЭС «На линии» дается команда на включение QF3, QF4 и с выдержкой время на включение QF3. Если в течении заданного времени после подачи команды на пуск РДЭС подтверждение включения QF4 не поступило, выводится сообщение «Авария РДЭС» или «Отказ выключателя QF4» (в зависимости от события). Если не включился QF3 (при включении QF4) 101 выводится сообщение «Отказ секционного выключателя РУ 0,4 кВ », РДЭС продолжает работать на секцию 1; при восстановлении питания на вводах 1 или 2 и работающей РДЭС через заданное время дается команда на синхронизацию РДЭС с этим вводом (средствами РДЭС по команде от АСУ). При этом при наличии напряжения только на вводе 1 синхронизация производится через выключатель ввода 1. При наличии напряжения только на вводе 2 синхронизация производится через выключатель ввода 2. При наличии напряжения на вводе 1 и вводе 2 синхронизация производится через выключатель ввода 1. При получении сообщения о достижении синхронизации от РДЭС (синхронизатор в контейнере РДЭС) производит включение вводного выключателя. После подтверждения включения соответствующего вводного выключателя формируется команда на отключение QF4, а затем с выдержкой времени команда (двухсекундный импульс) на остановку РДЭС. При неотключении QF4 или не включении (отказе синхронизации) QF1 (QF2) после выдержки времени выводится сообщение об аварии резервирования. В этом случае решение на останов РДЭС или отключение выключателей (при необходимости) принимает оперативный персонал. Входные параметры (рисунок 4.1):
Моделирование программ ПЛК
Экспериментальное исследование КТП СН и РУ 0,4кВ, находящихся под управлением разработанной СУ ТП, показало, что поведение ОУ в различных режимах тестирования полностью соответствует прогнозируемым результатам.
Разработанная СУ ТП успешно прошла приёмосдаточные испытания на объекте заказчика, что свидетельствует о применимости предложенной методики к разработке СПО для АС.
Разработанный прототип может быть использован в качестве тренажера-симулятора с возможностью моделирования внештатных аварийных ситуаций для обучения и тренировки обслуживающего персонала и операторов ТП.
Концепцию модельно-ориентированной разработки через комплексное тестирование прототипа и ЕИС не выгодно применять при создании АС с количеством точек контроля и управления менее 5000, так как поддержка информационных решений в области автоматизации ТП, которую оказывает ЕИС, необходима только для сложных СУ ТП.
Разработанная методика подходит к применению в любой отрасли промышленности при разработке СУ ТП на базе ПЛК и SCADA-систем и значительно улучшает экономические показатели проектов автоматизации ТП (данные приведены на рисунках раздела «Экономические показатели»).
Экономические показатели. Возможность смещения начала разработки СПО к самым ранним стадиям проекта оказывает положительный экономический эффект на разработку проекта автоматизации ТП (рисунок 4.25). Разработка через комплексное тестирование прототипа сокращает время пропорционально объему и сложности проекта. То есть чем сложнее и объемнее проект, тем меньше времени и трудозатрат потребуется на разработку СПО (относительно традиционной методики). В среднем в проектах от 5000 до 6000 точек контроля и управления предлагаемая методика позволяет сократить время на разработку СПО от 20% до 40% (рисунок 4.26). Если в проекте используются готовые технические решения из базы знаний, то время на разработку сокращается от 30% до 80%.
Предположения на будущее. Помимо изначально задуманного применения предлагаемой методики – разработки СПО для ПЛК и SCADA-систем – все больше инженерных задач перекладывается на модели в виде дополнительных свойств, методов трансформаций, конфигурации различных протоколов передачи данных и т.д., что делает проекты автоматизации целостными и менее уязвимыми к ошибкам.
Предлагаемая в диссертационной работе методика отлично себя зарекомендовала за почти двухлетнее применение и в данный момент продолжает своё развитие в крупной международной компании «Schneider Electric».
Диссертация является научно – квалификационной работой, в которой на основании выполненных автором исследований изложены научно – обоснованные информационные и программные решения по автоматизации программирования логических контроллеров на основе компьютерных моделей, имеющие существенное значение при автоматизации и управлении сложными технологическими процессами в промышленности (свыше 5000 точек контроля и управления).
Установлены связи между техническим заданием, включающим спецификации устройств, алгоритмы управления, математические модели на разработку системы управления технологическими процессами и специальным программным обеспечением, реализующем на реальном технологическом процессе систему управления посредством программируемых логических контроллеров и SCADA-систем.
На основании установленных связей разработана и впервые применена для решения задач автоматизации технологических процессов система компьютерных моделей, позволяющая создать методику автоматизированной разработки специального программного обеспечения, работающего на ПЛК, для систем управления технологическими процессами в промышленности, в основу которой положены компьютерная база знаний и комплексное тестирование прототипа разрабатываемой системы.
Предложены компьютерные модели, особенностью которых является отражение аналитических зависимостей между характеристиками технологического процесса, требуемым компьютерным функционалом системы управления технологическим процессом и конечным специальным программным обеспечением, работающим на программируемых логических контроллерах и SCADA-системах.
Для поддержки созданной методики разработана единая информационная среда, обеспечивающая: согласование принятых проектных решений между разработчиком и заказчиком (в том числе в режиме удаленного доступа); итерационную верификацию системы компьютерных моделей (прототипирование разрабатываемой системы); генерацию по текущему состоянию компьютерных моделей исходных программных кодов для программируемых логических контроллеров и SCADA-систем.
Результаты диссертационной работы использованы при разработке проектов автоматизации в металлургической и энергетической отраслях промышленности на 7 объектах: ОАО "Международный Аэропорт Внуково" г. Москва, ЗАО «Северо-западная Фосфорная Компания» Мурманская обл., ОАО «Кольская горно-металлургическая компания» г. Мончегорск и др.
Полученные результаты рекомендуется использовать при разработке систем управления технологическими процессами на предприятиях промышленности с целью диспетчеризации, контроля, учета и управления технологическими процессами, имеющими свыше 5000 точек контроля и управления, а также в учебном процессе при подготовке инженерно-технических кадров по направлениям подготовки «Автоматизация технологических процессов и производств».
Результаты, полученные в диссертационной работе, используются на практике в международной компании «Schneider Electric» при разработке проектов автоматизации ТП в энергетической отрасли, а также в российской инжиниринговой компании «АНХ-Инжиниринг» при разработке проектов автоматизации ТП в металлургической отрасли.
