Процесс-ориентированная технология программирования: модели, языки и инструментальные средства для спецификации алгоритмов управления сложными техническими системами тема диссертации и автореферата по ВАК РФ 05.13.17, кандидат наук Зюбин, Владимир Евгеньевич

• Зюбин, Владимир Евгеньевич
• кандидат наук
• 2013

Оглавление диссертации кандидат наук Зюбин, Владимир Евгеньевич

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ..................................................................4

Глава 1. Существующие подходы к реализации программного

обеспечения систем управления....................................................................15

1.1. Роль алгоритма управления при проектировании современных

систем промышленной автоматизации........................................................15

1.2. Классификационные признаки задач управления........................................20

1.3. Психологические аспекты описания управляющих алгоритмов................25

1.3. Языки МЭК 61131-3..........................................................................................50

1.4. Возможные альтернативы МЭК 61131-3.......................................................61

Выводы главы...........................................................................................................77

Глава 2. Гиперпроцесс: математическая модель алгоритма управления.............80

2.1. Исторические предпосылки создания модели конечного автомата...........80

2.2. Математическая модель абстрактного автомата...........................................89

2.3. Модернизированная модель конечного автомата.........................................96

2.4. Автоматы Мили и Мура...................................................................................97

2.5. Способы задания автоматов Мили и Мура....................................................98

2.6. Анализ исторических условий использования конечных автоматов

в начале компьютерной эпохи.....................................................................103

2.7. Достоинства и ограничения модели конечного автомата..........................106

2.8. Варианты расширения модели конечного автомата...................................109

2.9. Процесс и событийный полиморфизм.........................................................112

2.10. Функция-состояние. События и реакция на событие...............................113

2.11. Математическая модель гиперпроцесса.....................................................114

2.12. Редуцированная модель гиперпроцесса для алгоритмов управления ... 117

2.13. Операциональная демонстрация свойств гиперпроцесса........................117

Выводы главы.........................................................................................................120

Глава 3. Программная реализация гиперпроцесса................................................124

3.1. Логический параллелизм................................................................................124

3.2. Программная реализация на процедурных языках. Язык Си....................130

3.3. Программная реализация на языках потоков данных. Язык G пакета

Lab VIEW.........................................................................................................137

3.4. Программная реализация модели гиперпроцесса на языках МЭК

61131-3............................................................................................................144

3.5. Устранение условий идеального синхронизма. CLIPS..............................147

3.6. Способы статической балансировки вычислительной нагрузки

при многопоточной реализации гиперпроцесса.......................................151

Выводы главы.........................................................................................................164

Глава 4. Специализированные языки процесс-ориентированного

программирования........................................................................................169

4.1. Язык Рефлекс...................................................................................................169

4.2. eST - процесс-ориентированное расширения языка ST из состава

МЭК 61131-3..................................................................................................185

4.3. Hyper-Process Diagram: графическая спецификация алгоритма

управления в процесс-ориентированном стиле........................................186

Глава 5. Генерация исполняемого кода..................................................................195

5.1. Трансляторы языка Рефлекс (R2C, R2CNF, R2Py).....................................195

5.2. Системная интеграции генерируемого кода................................................200

Выводы главы.........................................................................................................204

Глава 6. Использование средств процесс-ориентированного

программирования в задачах промышленной автоматизации................207

6.1. Примеры решения типовых задач средствами процесс-

ориентированного программирования.......................................................207

6.2. Пример практической задачи. Система управления выращиванием

монокристаллов кремния (метод Чохральского)......................................224

6.3. Разработка программ в процесс-ориентированном стиле

с использованием виртуальных объектов управления.............................237

6.4. Виртуальные лабораторные стенды: обучение студентов

программированию задач промышленной автоматизации.....................249

6.5. Примеры использования виртуальных объектов управления на

практике..........................................................................................................258

ВЫВОДЫ И РЕЗУЛЬТАТЫ....................................................................................266

Список сокращений...................................................................................................268

Список литературы....................................................................................................269

Приложение 1. Синтаксис языка Рефлекс..............................................................283

Приложение 2. Таблица соответствия русскоязычного и англоязычного

варианта синтаксиса языка Рефлекс..........................................................287

Приложение 3. Информация о внедрении результатов........................................293

Введение диссертации (часть автореферата) на тему «Процесс-ориентированная технология программирования: модели, языки и инструментальные средства для спецификации алгоритмов управления сложными техническими системами»

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

Актуальность работы и степень ее разработанности. В настоящее время задачи обработки информации и управления технологическими процессами и производствами решаются исключительно с использованием цифровых систем. Базовый элемент промышленной автоматизации -специализированный вычислитель - программируемый логический контроллер (ПЛК), функционирующий в соответствии с заданным алгоритмом управления, который реализуется в виде компьютерной программы.

Рост масштабов работ по интенсификации и компьютеризации технологического производства, комплексная автоматизация производства, разработка новых многомерных технических объектов управления и функциональное развитие уже созданных программно-аппаратных комплексов предполагают постоянное усложнение алгоритмов управления.

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

Проблема создания алгоритмов управления особенно остро стоит в случае систем управления сложными техническими объектами на предприятиях металлургической и химической промышленности, атомных электростанциях, предприятиях космической индустрии и военно-промышленного комплекса при отработке новых технологий, при эксплуатации объекта в граничных областях или в условиях, исключающих непосредственное присутствие оператора.

Такие объекты управления изначально предполагают: серьезные последствия выхода технологического процесса из-под контроля; высокую вероятность возникновения нештатных ситуаций (например, при отказе оборудования или из-за отсутствия теоретической модели объекта управления); высокую функциональную наполненность алгоритма управления и его неоднородность (например, алгоритм может одновременно обеспечивать логическое управление и регулирование); предсказуемость алгоритма управления и жесткие требования по времени реакции на внешнее событие.

Ошибка в программном обеспечении (ПО) системы управления сложным техническим объектом может обернуться не только серьезными

материальными потерями, но и привести к катастрофическим последствиям, в том числе, к гибели людей.

В качестве примера сложного объекта управления можно упомянуть ростовую установку для выращивания монокристаллического кремния методом Чохральского. Технологический процесс характеризуется: а) отсутствием теории, позволяющей в аналитическом виде описать процесс кристаллизации; б) многомерным фазовым пространством состояний объекта;

в) многокритериальностью показателя качества конечного продукта;

г) отсутствием масштабной инвариантности; д) сложным алгоритмом управления; е) вероятностью возникновения аварийных ситуаций и нерегламентных быстротекущих процессов, угрожающих жизни обслуживающего персонала.

В силу специфики предметной области разработка и реализация алгоритмов управления технологическими процессами представляет собой отдельную ветвь программирования.

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

К настоящему времени наиболее распространенное средство создания ПО систем управления - набор языков МЭК 61131-3. Однако каждый из языков МЭК 61131-3, взятый в отдельности, имеет выраженную ориентацию на узкую подобласть (логическое управление, регулирование, вычислительные задачи, рецептурные процессы), поэтому при создании сложных управляющих алгоритмов разработчики вынуждены прибегать к так называемому мультиязыковому программированию (описывать один алгоритм частично на одном, а частично на другом языке). Это обстоятельство вынуждает переходить на альтернативные продукты, например пакет Lab VIEW, а в некоторых случаях даже прибегать к языкам общего назначения Си или Си++.

Отечественные и зарубежные исследователи (Ф. Вагнер, А. Бласс, М. Самек, К. Кратер, А. Хубер, А. А. Шалыто и др.) указывают на высокий потенциал модели конечного автомата и обосновывают, в частности, ее

преимущества по сравнению с моделями, используемыми в языках МЭК 61131-3. Однако, несмотря на теоретические предпосылки, модель конечного автомата крайне редко используется на практике. Это объясняется:

а) недостаточным соответствием модели специфике промышленной автоматизации (например, в модели отсутствует механизм, позволяющий организовать совместное функционирование нескольких конечных автоматов, что затрудняет спецификацию естественной иерархии и параллелизма, которые характерны для реальных технологических процессов);

б) отсутствием ориентированных на промышленную автоматизацию формальных языков, реализующих модель конечного автомата;

в) специфическим понятийным аппаратом модели, который затрудняет ее восприятие и изучение специалистами в области информационных технологий.

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

Объект исследования - программное обеспечение автоматизированных систем управления сложными техническими системами.

Предмет исследования - понятийные и лингвистические средства спецификации алгоритмов управления технологическими процессами и автоматизированными промышленными системами.

Цель работы - сокращение трудоемкости реализации и повышение качества ПО уровня ПЛК путем разработки теоретических основ, лингвистических и инструментальных средств создания алгоритмов управления технологическими процессами.

В соответствии с поставленной целью в работе решаются следующие основные задачи исследования:

1) проанализировать специфику алгоритмов управления технологическими процессами, недостатки существующих средств их программирования и сформулировать требования к формальным и лингвистическим средствам спецификации управляющих алгоритмов;

2) разработать понятийный аппарат и формальную математическую модель управляющего алгоритма;

3) определить варианты программной реализации разработанной формальной модели управляющего алгоритма;

4) на основе разработанной модели предложить лингвистические средства для спецификации алгоритма работы сложного технического объекта;

5) разработать и реализовать инструментальные средства генерации исполняемого кода по формальному описанию управляющего алгоритма;

6) предложить подход к отладке управляющих алгоритмов;

7) исследовать предложенные средства программирования на задачах создания автоматизированных систем управления.

Основная гипотеза. Программирование алгоритмов управления в задачах промышленной автоматизации - отдельная область программирования, обладающая уникальной спецификой и предполагающая, таким образом, особый проблемно-ориентированный подход.

На базе модифицированной модели конечного автомата можно создать унифицированные понятийный аппарат и лингвистические средства программирования алгоритмов управления широкого класса. Создаваемая понятийно-инструментальная база будет иметь практическую ценность, если:

а) модифицированная модель будет отражать специфику задач автоматизации;

б) понятийный аппарат модифицированной модели будет соответствовать текущим тенденциям в области информационных технологий.

Научная новизна. В диссертационной работе предложена, разработана и исследована новая технология программирования алгоритмов управления технологическими процессами, в основе которой лежат понятийные, лингвистические и инструментальные средства процесс-ориентированного программирования.

Принципиальный вклад в развитие технологии процесс-ориентированного программирования вносят следующие научные результаты, полученные автором:

1. Для алгоритма управления объектом автоматизации построена оригинальная математическая модель гиперпроцесса, отнимающаяся от существующих тем, что представляет алгоритм управления в виде

совокупности циклически активизируемых параллельных процессов, которые задаются набором альтернативных функций-состояний (активных и пассивных), имеют индивидуальный счетчик времени, сбрасываемый при смене текущей функции-состояния, и взаимодействуют, в частности, через операторы контроля функций-состояний.

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

3. Создан новый формальный язык программирования четвертого поколения - Си-подобный процесс-ориентированный язык Рефлекс, предназначенный для спецификации алгоритмов работы сложных объектов автоматизации. Основные отличительные особенности языка Рефлекс: а) средства описания входных/выходных переменных, с указанием их привязки к физическим портам ввода/вывода и области видимости; б) средства описания процессов и активных функций-состояний; в) средства структуризации программы (операторы запуска процессов, операторы останова, средства контроля текущей функции-состояния и средства генерации временных событий).

4. Определены алгоритмически эквивалентные преобразования языка Рефлекс в языки Си, Formula Node и Python, предложена программная реализация параллелизма процессов в рамках модели кооперативной многопоточности, отличающаяся выделением архитектурно-зависимых функций в отдельный модуль.

5. Разработаны оригинальный метод статической балансировки вычислительной нагрузки программы, описанной на процесс-ориентированном языке и реализуемой в рамках кооперативной многопоточности, на основе учета данных о ресурсоемкости функций-состояний и времени реакции процессов на внешнее событие, а также субоптимальный алгоритм его реализации, отличающийся низкой вычислительной сложностью при удовлетворительном качестве балансировки: а) процессы с одинаковыми временами реакции на внешнее событие объединяются в группы; б) для каждой из групп с временем реакции, превышающим значение периода активизации гиперпроцесса, определяется

базовый делитель частоты активизации Z); в) для каждого из процессов группы затем определяется индивидуальное смещение активизации О е {0, 1, ... ,D- 1}.

6. Определены и классифицированы варианты интеграции процесс-ориентированных алгоритмических структур в программы LabVIEW через dll-механизм, механизм Formula Node и интерпретатор Python, а также вариант реализации гиперпроцесса средствами языка G с помощью: а) тактированного цикла по условию для организации циклической активизации с заданным периодом; б) структур выбора для реализации функций-состояний процесса с ловушкой для диагностики неспецифицированных состояний во время исполнения; в) строковых переменных для хранения идентификатора текущей функции-состояния процесса, - различающиеся между собой по ресурсоемкости реализации, возможности интеграции с элементами пользовательского интерфейса, необходимости использования сторонних программных пакетов и пакета разработки LabVIEW и по уровню контроля семантической корректности кода.

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

Теоретическая и практическая значимость результатов исследования. Разработанная информационная технология, реализованная в виде набора трансляторов языка Рефлекс и программ, созданных на языке Рефлекс, позволяет унифицированно описывать управляющие алгоритмы широкого класса в виде, который понятийно, структурно и терминологически соответствует автоматизируемому технологическому процессу, что обеспечивает эффективную коммуникацию разработчика и пользователя-технолога во время разработки системы, а также облегчает изучение, верификацию и модификацию программ на протяжении жизненного цикла системы управления. Благодаря этому не только снижаются сроки разработки, но и повышается качество создаваемого ПО, что особенно важно при автоматизации технологических процессов и научных исследований, при отработке и внедрении новых технологий.

Созданное ПО и теоретические результаты исследования использовались в работах по созданию автоматизированных цифровых комплексов по выращиванию методом Чохральского монокристаллического кремния («ЦУК-М», 2002-2005 гг.) и корунда («Корунд», 2004-2006 гг.), при создании системы тестирования радиоэлектронной аппаратуры («М700-У», 2007-2009 гг.), автоматизированного комплекса контроля качества монтажных работ («Стенд-09», 2009 г.), при разработке технологических линий передела с/х продукции и пищевых отходов (проекты «Углеводные добавки», «Биогаз», «Биодизель», 2006—2011 гг.), при создании микроконтроллерного адаптера промышленных весов («Адаптер», 2012 г.), при модернизации системы тестирования радиоэлектронной аппаратуры («М700-У12», 2012-2013 гг.)

Результаты работы использовались при выполнении: гранта Миннауки №4917ф (Российская научно-техническая программа "Кремний России", 1995-1996 гг.); интеграционного проекта №84 Сибирского отделения РАН «Монокристалл» 2006-2008 гг., программы развития научно-образовательнош центра Института автоматики и электрометрии СО РАН 2007-2009 гг.; программы «Научно-исследовательский университет НГУ» 2009—2012 гг.; гранта №2012-1.2.1-12-000-2013-012 (ФЦП «Научные и научно-педагогические кадры инновационной России»),

Теоретические результаты диссертационных исследований и набор виртуальных лабораторных стендов позволили повысить качество подготовки студентов по дисциплинам «Программирование информационно-управляющих систем на основе конечных автоматов» и «Процесс-ориентированное программирование» (факультет информационных технологий НГУ) и по дисциплине «Теория управления» (Высший колледж информатики НГУ).

Документальные подтверждения эффективности полученных результатов при практическом использовании приведены в Приложении к диссертации.

Методологические основы и методы исследования. Задачи, поставленные в работе, решались с использованием теории конечных автоматов, теории автоматического регулирования, методов системного анализа и математического моделирования, процедурного программирования, экстремального программирования и программирования на основе потоков данных. Специфика алгоритмов управления технологическими процессами выявлена на основе содержательного подхода. При анализе существующих

языков программирования алгоритмов управления использовался преимущественно логико-исторический подход. Содержательный подход позволил также сформулировать базовые требования к формальным и языковым средствам описания управляющих алгоритмов. Разработка математической модели управляющего алгоритма и программных средств базировалась на формальном подходе. Эмпирический метод использовался при исследовании эффективности предложенного понятийного аппарата и набора разработанных средств программирования в задачах автоматизации технологических процессов и физико-технических исследований.

Область исследования. Содержание диссертации соответствует паспорту специальности 05.13.17 «Теоретические основы информатики» (технические науки) по следующим областям исследований: п. 2 «Исследование информационных структур, разработка и анализ моделей информационных процессов и структур»; п. 6 «Разработка методов, языков и моделей человекомашинного общения; разработка методов и моделей распознавания, понимания и синтеза речи, принципов и методов извлечения данных из текстов на естественном языке»; п. 8. «Исследование и когнитивное моделирование интеллекта, включая моделирование поведения, моделирование рассуждений различных типов, моделирование образного мышления»; п. 10 «Разработка основ математической теории языков и грамматик, теории конечных автоматов и теории графов»; п. 12 «Разработка математических, логических, семиотических и лингвистических моделей и методов взаимодействия информационных процессов, в том числе на базе специализированных вычислительных систем»; п. 14 «Разработка теоретических основ создания программных систем для новых информационных технологий».

Научные результаты, выносимые на защиту:

1. Набор классификационных признаков, характерных для алгоритмов уровня ПЛК: а) дуализм системы «управляющий алгоритм - управляемый объект»; б) цикличность и неопределенная продолжительность функционирования алгоритма управления; в) гибридность; г) событийность; д) синхронизм; е) логический параллелизм; ж) структурность и абстрактность формальной спецификации.

2. Математическая модель гиперпроцесса, представляющая управляющий алгоритм в виде периодически активизируемой совокупности

логически параллельных слабосвязанных процессов, каждый из которых представлен снабженной индивидуальным таймером событийно-управляемой полиморфной функцией (альтернативными активными и пассивными функциями-состояниями).

3. Варианты модификации модели гиперпроцесса, обеспечивающие повышенную утилизацию вычислительных ресурсов платформы и статическую балансировку вычислительной нагрузки: а) гиперпроцесс с плавающим периодом активизации; б) гиперпроцесс с индивидуальными делителями частоты активизации процессов.

4. Си-подобная грамматика процесс-ориентированного языка программирования Рефлекс, позволяющая описывать алгоритмы управления широкого класса.

5. Программно-алгоритмические решения, использованные при проектировании транслятора языка Рефлекс и его реализации, обеспечивающие повышенную портируемость пользовательских программ на микроконтроллерных платформах.

6. Итерационный подход к разработке алгоритмов управления на основе унифицированной связки «алгоритм управления - виртуальный объект управления» и программно-алгоритмические решения, обеспечивающие использование виртуальных лабораторных стендов для обучения программистов в области промышленной автоматизации.

Апробация работы. Результаты диссертационной работы докладывались и обсуждались на: VIII Международной конференции по электронным публикациям «EL-Pub2003» (Новосибирск, 2003); семинарах научной школы «Информационные технологии» ИАиЭ СО РАН (Новосибирск, 2004, 2008); III Международной конференции "Идентификация систем и задачи управления" SICPRO'04 (Москва, 2004); Совещании «Кремний-2004» (Иркутск, 2004); Международной научно-технической конференции «Информационные, измерительные и управляющие системы» (Самара, 2005); Second LASTED International Multi-Conference on "Automation, Control, and Information Technology" (Новосибирск, 2005); Третьей Российской школе ученых и молодых специалистов по физике, материаловедению и технологиям получения кремния и приборных структур на его основе «Кремний. Школа-2005» (Москва, 2005); Международной научной конференции "Современные проблемы информатики" (Воронеж, 2006, 2009-

2011, 2013); V Международной конференции "Идентификация систем и задачи управления", SICPRO'Oö (Москва, 2006); IEEE International Siberian Conference on Control and Communications, SIBCON-07 (Томск, 2007); Четвертой российской конференции с международным участием по физике, материаловедению и физико-химическим основам технологий получения легированных кристаллов кремния и приборных структур на их основе «Кремний-2007» (Москва, 2007); Всероссийских научных чтениях с международным участием, посвященных 75-летию член-корр. АН СССР М. В. Мохосоева (Улан-Удэ, 2007); 2nd International Conference "Telecommunications, Electronics and Informatics", ICTEI 2008 (Chisinau, 2008); Международной научно-практической конференции «Пища. Экология. Качество» (Краснообск, 2008, 2010, 2013, Казахстан, Алматы, 2011); IEEE International Conference on Computational Technologies in Electrical and Electronics Engineering, SIBIRCON-08 (Новосибирск, 2008); Четвертой международной научно-практической конференции-выставки

"Промышленные контроллеры 2008: от А до Я" (Москва, 2008); Седьмой международной конференции «Перспективы систем информатики» (Новосибирск, 2009); Международной научной конференции «Кремний 2009» (Новосибирск, 2009); Всероссийской научно-практической конференции «Имитационное моделирование. Теория и практика», ИММОД-2009 (Санкт-Петербург, 2009); Всероссийской научной конференции «Когнитивные науки: междисциплинарные исследования мышления и интеллекта» (Томск, 2009); Second LASTED International Multi-Conference on "Automation, Control, and Information Technology" (Новосибирск, 2010); Pacific Conference on Computer Technology and Applications (Владивосток, 2010); Ershov Informatics Conference (Новосибирск, 2011); Международной конференции по актуальным проблемам физики, материаловедения, технологии и диагностики кремния, наноразмерных структур и приборов на его основе "Кремний-2011" (Москва, 2011); Международной научно-практической конференции «Металлургический кремний-2012. Физико-химические процессы и технологии получения металлургического кремния» (Казахстан, Караганда, 2012); IEEE International Siberian Conference on Control and Communications, SIBCON-13 (Красноярск, 2013).

Публикации. По теме диссертации опубликовано 94 печатных работ, из них две монографии, 29 статей в рецензируемых журналах из Перечня ВАК, два патента и четыре свидетельства об официальной регистрации программ.

Структура и объем диссертации. Диссертация состоит из введения, шести глав, заключения и приложения. В первой главе обсуждается специфика задач промышленной автоматизации, проводится критический анализ существующих подходов к реализации ПО систем управления, формулируются требования к формальным и лингвистическим средствам описания сложных управляющих алгоритмов. Во второй главе предлагается формальная математическая модель управляющего алгоритма в виде гиперпроцесса и приводится понятийный аппарат процесс-ориентированного программирования. В третьей главе рассматриваются возможные варианты модификации модели гиперпроцесса и способы его алгоритмической реализации различными языковыми средствами. Четвертая глава посвящена языку Рефлекс, вариантам процесс-ориентированного расширения языков МЭК 61131-3 и графическому языку процесс-ориентированного программирования HPD. В пятой главе описывается реализация трансляторов языка Рефлекс в язык Си, язык формата Formula Node и язык Python, предлагаются варианты интеграции создаваемого трансляторами кода в системы управления, в том числе на базе пакета LabVIEW, даются классификационные признаки для предложенных вариантов интеграции. В шестой главе приводятся сведения о практическом использовании языка Рефлекс, в частности излагается и демонстрируется на примерах концепция виртуальных объектов управления. Приложения содержат спецификацию синтаксиса языка Рефлекс с помощью расширенной формы Бэкуса-Нуара, список его резервированных слов и вспомогательные материалы, копии документов о результатах использования средств процесс-ориентированного программирования на практике.

Глава 1. Существующие подходы к реализации программного обеспечения систем управления

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

1.1. Роль алгоритма управления при проектировании современных систем промышленной автоматизации.

На современном этапе развития техники в качестве ядра любой системы промышленной автоматизации используется программируемый логический контроллер (ПЛК) - специализированный цифровой вычислитель, к которому со стороны объекта автоматизации подключаются датчики и исполнительные устройства (рис. 1.1). Через датчики в ПЛК поступает информация о текущем состоянии объекта, а через исполнительные устройства ПЛК может изменять состояние управляемого объекта. Эта базовая схема может усложняться. Например, ПЛК может подключаться к АРМ оператора для супервизорного управления или к базе данных (БД) для накопления информации и интеграции в АСУ предприятия.

Типовые датчики (рис. 1.2) - сигнализаторы конечного положения, датчики температуры и давления, расходомеры жидкости и газа, видео-регистраторы, датчики угла поворота, скорости, ускорения и тому подобное с самыми разными типоразмерами, эксплуатационными характеристиками, интерфейсами для интеграции в систему и физическими принципами, лежащими в основе измерений.

Список литературы диссертационного исследования кандидат наук Зюбин, Владимир Евгеньевич, 2013 год

Источник питания

СЪ

Рис. 6.5. Структурная схема установки и системы управления

6.2.3. Требования к БУМ УВМК

Для обеспечения работоспособности УВМК аппаратура и программное

обеспечение (ПО) БУМ УВМК должны удовлетворять следующим требованиям:

а) высокая надежность и устойчивость ПО, контроль возникновения аварийных ситуаций во время работы и предотвращение действий оператора, ведущих к аварийным ситуациям;

б) визуальное отображение состояния установки на видеомониторе, в частности, процесса роста от видеокамеры телевизионного датчика;

в) постоянный контроль отказов оборудования и выдача четких диагностических сообщений в случае неисправности;

г) дружественный интерфейс с оператором;

д) документирование текущих параметров с возможностью их считывания извне для последующего анализа и обработки специализированным ПО;

е) удаленный мониторинг технологического процесса;

ж) реализация алгоритма управления с большим числом параллельно исполняемых процессов;

з) высокая степень гибкости и модифицируемости алгоритма управления;

и) пыле- и влагозащищенность оборудования, невозможность использования при штатной работе клавиатуры персонального компьютера и манипулятора типа мышь;

к) высокая степень модульности и возможность модификаций/модернизации как во время отладки, так и на протяжении всего жизненного цикла.

6.2.4. Архитектура системы управления БУМ УВМК

БУМ УВМК реализован на базе высокопроизводительных процессоров

Intel х86 серии в промышленном исполнении, имеет распределенную многомашинную архитектуру и конструктивно выполнен в виде герметичного шкафа, на передней панели которого расположен сенсорный экран, а на боковой - блок разъемов для подключения выносных устройств и аналого-цифровых сигналов с УВМК [186]. На переднюю панель шкафа также выведена аварийная кнопка, выключатель питания и звуковой динамик. К блоку разъемов по последовательному каналу подключаются приводы, выносной пульт оператора, датчики и источник питания. БУМ УВМК оснащен бесперебойным источником питания, обеспечивающим сохранение функционирования системы при кратковременных сбоях питания.

Приводы обеспечивают перемещение и вращение затравкодержателя и тигля.

С помощью датчиков производятся бесконтактные измерения геометрии выращиваемого кристалла, температуры нагревателя, а также температуры и уровня расплава.

Выносной пульт оператора используется как альтернативное устройство ввода команд и заданий в основные контуры регулирования в ручном режиме с визуальным контролем оператором процессов в ростовой камере через имеющиеся по ее периметру иллюминаторы.

Шкаф БУМ УВМК содержит (рис. 6.5):

• крейт контроллера программного управления (КПУ), выполненный в стандарте MicroPC и реализующий функции управляющей ЭВМ; КПУ обеспечивает исполнение алгоритма работы, контроль, регулирование, измерение; модульная архитектура крейта обеспечивает модифицируемость аппаратуры и гибкую настройку на условия конкретного применения;

• панельный компьютер оператора (ПКО) типа IBM PC/AT с сенсорным экраном, имеющий достаточное качество графического изображения и большую емкость дисковой памяти. ПКО обеспечивает ввод команд оператора и отображение информации, поступающей от КПУ. Для этого типа компьютеров имеется большой спектр программного обеспечения, в том числе и кросс-средств. Сенсорный экран ПКО, с одной стороны, позволяет не использовать клавиатуру и манипулятор типа «мышь», которые трудно защитить от воздействий внешней среды, а с другой стороны, - обеспечивает простое взаимодействие оператора с системой управления.

В качестве базового элемента КПУ выбрана плата процессора CPU686E фирмы Fastwel [187]. Процессор имеет высокую производительность и надежность. Файловая система расположена на виртуальном дисковом накопителе, который выполнен на флэш-памяти. На плате имеются встроенные последовательные каналы типа RS-232 и порт Ethernet.

Крейт КПУ содержит дополнительный модуль последовательных интерфейсов 5554/5558 фирмы Octagon Systems [188] с четырьмя последовательными каналами типа RS 232/485, два модуля расширения входов/выходов UNI096-5 фирмы Fastwel [189], позволяющие подсоединять к

КПУ до 192 аналого-цифровых каналов (рис. 6.6). Крейт КПУ обладает следующими характеристиками :

• тактовая частота 300 МГц;

• флэш-память 8 Мбайтов;

• оперативная память 32 Мбайта;

• системная магистраль PC/XT;

• шесть последовательных каналов типа RS-232;

• скоростной канал 10/100 Base-T Ethernet;

• возможность подключения до 192 гальванически развязанных аналого-цифровых сигналов.

Применение флэш-памяти для хранения кода программ КПУ обеспечивает возможность оперативной модификации программного обеспечения во время отладки, поскольку программирование микросхем производится без их извлечения из процессорного модуля, через выделенный последовательный канал RS-232 со штатного ПКО. Еще один последовательный канал RS-232 обеспечивает связь прикладных программ КПУ и ПКО. Разработанный протокол обмена данными по последовательному каналу предусматривает проверку контрольной суммы и повторную передачу пакетов в случае сбоев. Двухканальная схема позволяет производить независимый мониторинг исполнения программ во время штатной работы. Это решение стало одним из ключевых для данного проекта, поскольку отлаживать программное

Панельный компьютер оператора

Выносные активные устройства (датчики, пульты, источники питания)

\

RS-232

\

RS-232/ RS-485

Модуль процессорный

Модуль

последовательных интерфейсов

Рис. 6.6. Структурная схема крейта КПУ

обеспечение традиционными методами затруднительно ввиду его объема и сложности.

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

Два модуля входов/выходов UNI096-5 с модулями 73L фирмы Grayhill [190] обеспечивают ввод и гальваническую развязку дискретных и аналоговых сигналов с УВМК. Разрядность аналоговых сигналов - 12, приведенная погрешность АЦП/ЦАП - 0,3 %. Максимальное время преобразований - 18 мс.

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

используется как инструментальная машина для хранения исходных текстов программ, получения исполняемых файлов, загрузки исполняемых файлов в КПУ и отображения отладочной информации. Имеется возможность подключения ПКО к локальной вычислительной сети цеха и дистанционный контроль нескольких УВМК одним оператором.

Таким образом, вычислительная часть системы управления представляет собой гибкий многомашинный комплекс, который в совокупности с программным обеспечением позволяет удовлетворить жестким требованиям, предъявляемым объектом управления.

ПО системы управления

ПО системы управления состоит из ПО ПКО и ПО КПУ [185]. Разделение

некритической для технологического процесса функции интерфейса с оператором и собственно управление УВМК позволило строить ПО ПКО на базе так называемой Wintel архитектуры.

ПО оператора обеспечивает: начальную инициализацию системы; прием информации от КПУ по последовательному каналу RS-232; ведение протокола событий в системе и архивирование параметров технологического процесса; вывод информации на экран видеомонитора в виде цифровых полей, элементов мнемосхемы, графиков, текстовых и голосовых сообщений; ввод команд оператора и их передачу в КПУ для последующего исполнения; отработку алгоритмов, созданных технологом и определяющих ход процесса выращивания кристалла; предоставление информации на персональный компьютер технолога (ПКТ) для удаленного мониторинга и последующего анализа; прием и передачу на ПКТ файлов с конфигурационной информацией и ТП.

При выборе средства разработки для ПО ПКО анализ имеющихся на рынке SCADA-пакетов и ОРС-компонентов показал, что ни один из них не удовлетворяет требованиям к функциональным возможностям. Проблемы вызывает работа с сенсорным экраном, организация голосовых сообщений,

создание журнала событий и архива для периодического технологического процесса и т. д. Несмотря на достаточно удобные средства создания стандартных элементов управления (кнопок, полей ввода, мнемосхем), затраты на доработку таких систем оказались бы соизмеримы с созданием уникальной специализированной системы, что при учете стоимости покупных инструментов делало их использование экономически неэффективным. В результате выбор был сделан в пользу самостоятельной разработки.

ПО оператора построено по модульному принципу. В его состав входят программа взаимодействия с оператором (ПВО) и одиннадцать компонентов обработки информации: ведения базы данных параметров, ведения списка текущих сообщений, ведения журнала событий, архивирования данных, программной диагностики, отработки ТП, связи с КПУ, накопления команд к контроллеру, обработки сообщений от КПУ, общесистемной таблицы интерфейсов и обмена информацией с ПКТ.

ПВО обеспечивает операторский контроль технологического процесса. В задачи программы входит: визуализация параметров плавки, уведомление оператора о

возникновении нештатных ситуаций, предоставление интерактивных средств управления установкой,

конфигурирование датчиков и регуляторов системы, координация совместной работы всех программных модулей.

Рис. 6.7. На «горячих» испытаниях системы управления: поиск оптимальных режимов выращивания монокристалла кремния (полуавтоматический режим)

ПО ПКО написано на объектно-ориентированном языке Си++ в среде разработки Microsoft Visual Studio [191] и рассчитано на работу в операционной системе Microsoft Windows. Модули обработки информации созданы на базе

модели компонентных объектов COM/DCOM от Microsoft. ПВО представляет собой диалоговое приложение, разработанное с использованием библиотеки классов Microsoft Foundation Classes (MFC).

ПО КПУ включает системно-независимую управляющую программу и вспомогательные системные средства (ВСС). ВСС исполняются под операционной системой MS DOS 6.22, поставляемой производителем процессорного модуля. Во время начальной настройки системы ВСС обеспечивают прием кодов управляющей программы по последовательному каналу RS-232 от ПО ПКО и запись их на флэш-диск. Во время штатной работы, при включении питания ВСС загружают код управляющей программы с флэш-диска в ОЗУ и запускают управляющую программу на исполнение. Во время работы управляющей программы ВСС и функции операционной системы не используются. Системно-независимая управляющая программа реализует алгоритм работы установкой.

Управляющая программа выполняет следующие основные функции:

• инициализацию и тестирование системы;

• сбор информации о положении исполнительных устройств УВМК и ее последующую передачу в ПВО для отображения;

• регулирование параметров;

• исполнение режимов работы установки;

• исполнение команд оператора, поступающих от ПВО;

• контроль возникновения аварийных ситуаций.

Автоматический режим выращивания разбит на 23 этапа, которые могут запускаться как отдельные макрокоманды. Алгоритм управления предусматривает специализированные технологические режимы проверки исправности комплекса технических средств и постоянный контроль возникновения аварийных ситуаций (перегрев в магистралях охлаждения, разрушение тигля, отказ управляющих утройств и т. д.). При аварии активизируются процессы переключение с отказавших мешанизмов на

дублирующие, а при невозможности устранить аварию производится автоматический перевод ростовой установки в безопасное состояние. Перед исполнением команд оператора проводится контроль корректности условий исполнения и с возможностью блокировки команды.

Программное обеспечение управляющей программы ядра системы выполнено на языке процесс-ориентированного программирования Рефлекс. Транслятор языка позволяет создавать системно-независимый исполняемый код с высоким уровнем переносимости.

Реализованный алгоритм работы УВМК [185] описывается гиперпроцессом из более 700 процессов, организованных в гибкую, иерархическую структуру.

По функциональному признаку эти процессы делятся на пять категорий: 1) снятие данных; 2) регулирование параметров; 3) реализация алгоритма работы; 4) контроль возникновения аварийных ситуаций, обнаружение и исправление ошибок; 5) системный мониторинг.

Управляющая программа при запуске перехватывает системные прерывания и контролирует возникновение нештатных ситуаций типа деления на ноль. В случае возникновения таких ситуаций выдается соответствующая диагностика. При этом, в отличие от общепринятой практики, останова алгоритма управления не происходит, и общее функционирование системы сохраняется. Такой подход обеспечивает повышенную устойчивость алгоритма.

Программная реализация логического параллелизма определяет высокое быстродействие алгоритма. Замеры ресурсоемкости реализованной программы показали пиковую нагрузку в 8 мс (в основном определяется временем аналого-цифрового преобразования). Период активизации гиперпроцесса установлен в 100 мс, что обеспечивает приемлемое время реакции на внешнее событие при гарантированном выполнении гипотезы идеального синхронизма.

Практическая отработка алгоритма в составе ростовых установок позволила отработать технологию получения монокристаллов кремния диаметром 150 мм. Код, созданный средствами процесс-ориентированного языка Рефлекс, показал

высокую надежность и модифицируемость: даже существенные расширения функциональности имеют локальный характер и не затрагивают общей структуры программы.

Разработанная архитектура была использована и в проекте по автоматизации процесса выращивания корунда тем же методом (вытягивания из расплава). В силу отличий программа была модифицирована, при этом установлено, что изменения в коде, взятом за основу, носили локальный характер.

6.3. Разработка программ в процесс-ориентированном стиле с использованием виртуальных объектов управления

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

Качество создаваемого ПО в первую очередь обеспечивается за счет среды разработки. На основании этого даже вводится понятие «надежность языкового средства», которое в большинстве случаев трактуется как мера степени обнаружения ошибок на этапе трансляции и исполнения программы. Основной упор при этом делается на формальные методы: строгую типизацию

переменных, выявление синтаксических и семантических ошибок. Тем не менее, формальный подход имеет вполне очевидные ограничения.

При построении любой языковой системы имеется предел обнаруживаемых ею ошибок, и ошибки в логическом построении программы принципиально не поддаются автоматическому обнаружению. Причем, чем сложнее создаваемый алгоритм, тем более вероятно возникновение таких ошибок. На помощь приходит прагматика и психология программирования: успешно бороться с логическими ошибками помогает использование специализированных языков, ориентированных на специфику решаемой задачи. Но и это не гарантирует стопроцентного успеха. Дальнейшая работа по выявлению возможных ошибок производится через усиленное тестирование созданной программы. Для этого в интегрированные среды разработки включаются дополнительные возможности по трассировке программ и их отладке, прогонке тестов. В особо ответственных проектах тестирование - ключевая операция, вокруг которой выстраивается весь процесс разработки.

Но насколько универсальны такие средства отладки? Можно ли их использовать для отладки управляющих алгоритмов? Анализ показывает, что встроенные средства таких мощных сред, как .NET или Visual С++, ориентированы исключительно на отладку WIMP-систем (Windows-Icons-Menus-PointerDevices). Специфичен не только процесс создания управляющих алгоритмов, но и процесс их отладки, в силу того, что для тестирования управляющего алгоритма необходима некоторая модель управляемого объекта.

6.3.1. Системы имитационного моделирования. Базовая функциональность и область использования

Моделирование на протяжении столетий выступало (и выступает) как

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

искусственных объектов (технических комплексов и инженерных конструкций) и при управлении процессами в физических, химических, биологических, социальных системах.

До недавнего времени исследование моделей было возможно только в двух вариантах. В первом варианте модель объекта задается в виде набора правил (формул, уравнений) и затем исследуется аналитическими методами. При этом исследователь подставляет интересующие его начальные значения в правила, описывающие модель, и получает результат либо в виде численных значений, либо в виде функций. Второй вариант - так называемое физическое моделирование - предполагает использование физических имитаторов -реальных объектов со свойствами, схожими со свойствами моделируемого объекта. При физическом моделировании исследователь физически воздействует на объект-имитатор и наблюдает за его поведением.

Физическое моделирование, привлекательное низкими требованиями к квалификации исследователя, сопряжено с принципиальными проблемами, которые резко сужают область его использования. Сложность подбора и конструирования имитатора, проблемы с безопасностью при исследовании в граничных условиях и практическая невозможность модификации - наиболее часто упоминаемые недостатки физического моделирования. В противоположность физическому моделированию математическое описание объекта и аналитическое исследование модели, хотя и может распространяться на неограниченно широкий класс объектов, справедливо связывается с трудоемкостью расчетов, отсутствием наглядности результатов и сложностью их интерпретации.

Компьютеризация современной жизни, в частности широкое распространение компьютеров в области физико-технических исследований, произвела революцию в моделировании. Сначала использование ЭВМ практически вытеснило аналитические методы исследования за счет широкого внедрения в практику вычислительных методов, а затем и вовсе привело к смене

базового исследовательского подхода: модель объекта задается исключительно программно. Широкое распространение подхода, основанного на идее программной имитации исследуемого объекта, позволяет ряду исследователей заявлять о наступлении «эры компьютерного моделирования» [192].

Инструменты компьютерного моделирования получили широкое распространение в промышленности. Программные пакеты предоставляют автоматизированные средства и библиотеки элементов, посредством которых можно обыгрывать различные варианты размещения оборудования, моделировать материалопотоки, создавать обучающие комплексы для операторов и технологов [193], готовить программирующих специалистов уровня ПЛК [179], оптимизировать ТП [194]. Визуализация - неотъемлемый атрибут программной имитации - радикально упрощает работу исследователя, скрывая многоэтажные формулы математической модели за наглядностью элементов компьютерной графики.

Программная имитация позволяет [192]:

• манипулировать течением модельного времени, ускорять медленные процессы и замедлять быстротекущие, повышая эффективность восприятия исследователем поведения системы;

• изменять параметры запуска модели в широком диапазоне, тем самым предоставляя исследователю мощный эвристический инструмент, чтобы разрабатывать и выдвигать новые гипотезы, модели, теории;

• существенно сократить число натурных экспериментов, во многих случаях заменяя их численными, что особенно важно в случае рисков (например, аварийный останов производства при исследовании систем со скрытыми связями) или этических последствий (например, при решении задачи оптимизации числа рабочих мест);

• решать педагогические задачи, в частности, позволяет сократить сроки и повысить качество подготовки персонала (операторов, технологов);

• упростить анализ взаимозависимостей, предоставляя возможность настройки, упрощения модели, исключения тривиальных параметров. В дополнение к этому программный имитатор может быть использован в качестве инструмента маркетинга - для демонстрации, обсуждения и обоснования предлагаемого решения перед потенциальным или реальным заказчиком проекта [195]. Принцип «лучше один раз увидеть» позволяет не только сократить объяснения, но и повысить убедительность утверждений.

Первоначально в качестве средств создания программных имитаторов использовались универсальные языки программирования (Algol, Fortran), позже начали появляться специализированные языки программирования (GPSS, Simula). Однако подобные средства не могут претендовать на роль промышленного инструмента, так как сложность освоения, трудоемкость моделирования, слабые средства визуализации результатов сильно ограничивают их применение для решения инженерных задач по сравнению со специализированными пакетами визуального программирования и библиотеками типовых элементов [195].

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

При создании управляющих алгоритмов уровня ПЛК имитационное

моделирование востребовано не меньше, чем при моделировании предприятия в целом. Имитационное моделирование промышленных объектов автоматизации позволяет существенно повысить эффективность подготовки программирующих специалистов: изучить типовые стратегии управления, применимые в различных производствах, обеспечить наглядность решаемых задач и ввести игровой элемент (что также позитивно сказывается на процессе обучения) [179]. Но, несомненно, еще большую значимость имитация объектов управления имеет в реальных проектах. Текущая практика промышленной автоматизации такова, что в подавляющем большинстве случаев пусконаладочные работы на новом объекте становится своеобразным «моментом истины»: первый запуск ПО

фактически означает начало его тестирования на уровне ПЛК. Поэтапный ввод ПО в состав системы управления (автономное тестирование, комплексное тестирование) не обеспечивает (и не может обеспечить) обнаружения ошибок на логическом уровне алгоритма, поскольку фактически сводится к проверке корректности подсоединения сигнальных линий.

Возможности моделировать объекты управления нет и в пакетах разработки. Средства для отладки управляющего ПО, предоставляемые производителями программных пакетов на базе МЭК 61131-3, позволяют только «оторвать» сигнальный кабель от датчика и назначить его значение вручную. То есть в качестве имитатора объекта выступает сам программист, что означает невозможность проверить даже логическую корректность сколько-нибудь сложного алгоритма, не говоря уже о тестировании его устойчивости или динамических характеристик. Другие технологии верификации ПО, такие как статический анализ исходного кода, испытания на автоматизируемом объекте, хотя и обладают огромным потенциалом, но, тем не менее, не в состоянии заменить тестирование как доминирующую технологию [196], которая в случае алгоритмов управления предполагает активное моделирование поведения объекта управления.

Объективная причина, обусловливающая сложившуюся практику, заключается в ограниченности средств МЭК 61131-3 [169]: концептуальной разнородности языков, недостаточности выразительных возможностей, несоответствии специфике автоматизации в части обеспечения необходимых процессуальных и структурных свойств алгоритма:

• событийности (управляемости по событиям);

• синхронизма (возможность работы с временными интервалами);

• средств организации взаимодействия параллельно-исполняемых процессов, в частности, в виде иерархических структур;

• средств абстрагирования и создания программных модулей, понятийно отражающих автоматизируемую технологию.

В результате проверка алгоритма откладывается до этапа пусконаладочных работ на объекте автоматизации. Степень готовности алгоритма до этого момента неизвестна.

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

Риски растут по мере укрупнения выполняемого проекта и сложности управляющего алгоритма.

6.3.3. Практикуемые приемы снижения рисков

Заметно минимизируют риски компании, уже имеющие за своими плечами

«портфель» выполненных проектов и штат «проверенных в боях» исполнителей. У таких компаний есть в наличии готовые стратегии автоматизации, библиотеки алгоблоков, методики отладки алгоритмов на объекте автоматизации, т. е. опыт («...сын ошибок трудных»). Именно поэтому начинающие компании в области промышленной автоматизации особо остро испытывают дефицит в клиентах. Этим же обстоятельством во многом объясняется и специализация компаний по отраслям, наблюдаемая на практике.

В продвинутых компаниях используются три подхода для предварительной отладки ПО уровня ПЛК.

Физические имитаторы. ПО ПЛК отлаживается на физических имитаторах, которые воспроизводят автоматизируемый процесс в той или иной степени детализации. Физические имитаторы подсоединяются к ПЛК через имеющиеся датчики и исполнительные устройства либо через их аналоги. Этот подход сопряжен с уже описанными проблемами, сопутствующими физическому моделированию: трудностью в выборе имитатора, невозможностью модификации модели, сложностями с использованием тех же датчиков и исполнительных устройств, что и на объекте, а также высокой стоимостью поддержания оборудования в работоспособном состоянии [179].

Программно-аппаратные имитаторы. Более продвинутый подход, применяемый на практике, - использование в качестве имитатора отдельного программно-аппаратного комплекса, «комплиментарного» создаваемой системе управления (рис. 6.8). Такой цифровой имитатор содержит программу, воспроизводящую поведение объекта управления, и формирует входные аналоговые/цифровые сигналы для отлаживаемой системы управления через свои модули выходов на основании управляющих сигналов, считываемых через аналоговые и цифровые модули входов.

AI/DI

Программно-аппаратный комплекс с отлаживаемым алгоритмом

AO/DO

AO/DO

Программно-аппаратный комплекс -имитатор объекта управления

AI/DI

с=С> с=^> 3

Рис. 6.8. Схема отладки алгоритма управления с использованием программно-аппаратного имитатора (А1 - аналоговые входы, - цифровые входы, АО - аналоговые выходы, БО - цифровые выходы)

В отличие от физического имитатора, такая схема позволяет тестировать алгоритмы управления для широкого спектра объектов и изменять поведение моделируемого объекта. В силу упоминавшейся комплиментарности системы управления и объекта этот подход позволяет также применять уже используемые языки программирования, что дает очевидное преимущество по сравнению со специализированными средствами компьютерной имитации. Еще одно достоинство подхода - простая коммутация алгоритма от имитатора к реальному объекту управления. Однако программно-аппаратное моделирование предполагает дополнительные затраты на технические средства, примерно равные затратам на аппаратуру системы управления.

Встраиваемые программные имитаторы. Иногда применяется подход, при котором для тестирования ПО ПЛК входные сигналы «отрываются» от физических модулей ввода и формируются программно. При этом в алгоритм управления внедряются специализированные программные модули - имитаторы оборудования. Этот подход также позволяет в какой-то степени отладить алгоритм, но тесная интеграция тестируемой и тестирующей части ПО вызывает сложности при последующем удалении тестирующего кода из алгоритма управления. По этой же причине серьезные проблемы возникают и при попытке организовать групповую работу над проектом.

Несомненно, когда дело касается такого критического производства, как атомная электростанция, средств на тестирование и моделирование не жалеют. Хотя анализ случившихся за последнее время техногенных катастроф показывает, что тестирование ПО на моделях проводится явно в недостаточном объеме*

* Причина аварии не обязательно кроется в программных ошибках. ПО может работать и без сбоев, но авария все равно может произойти, например, при ошибках в спецификации, при отсутствии необходимых блокировок на действия оператора или запутанном пользовательском интерфейсе. Разумеется, причина аварий может заключаться и в «чистых» сбоях

аппаратных средств, но подавляющее большинство проблем в системе управления выявляется при тестировании ПО на моделях.

6.3.4. Итерационный метод разработки управляющих алгоритмов на основе виртуальных объектов

Значительно упростить тестирование ПО ПЛК, сделать его разработку более

комфортным можно, используя для отладки ПО уровня ПЛК идею виртуальных лабораторных стендов (ВЛС), развиваемую в Институте автоматики и электрометрии СО РАН [179].

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

Поскольку управляющий алгоритм и алгоритм поведения объекта управления комплиментарны по интерфейсам и имеют одинаковую процессную природу, поведение ВОУ также можно описать средствами языка Рефлекс, что используется при создании сложных объектов. При этом ВЛС включает два

интерпретатора Python, один из которых реализует алгоритм управления, а другой имитирует объект управления. Схема замыкания входов на выходы алгоритма управления и ВОУ аналогична представленной на рис. 6.8. При этом для отладки алгоритма необходим только ПК. Другой важный момент - если не требуется изменения в части графики, то изменения в системе касаются только описаний алгоритма управления и поведения управляемого объекта.

Возможность отделять коды алгоритма и программного имитатора объекта управления позволяет не только тестировать алгоритм управления, но и использовать при разработке алгоритма итерационную схему (рис. 6.9).

£г>

Рис. 6.9. Итерационная модель разработки алгоритма управления (АУ) с тестированием на виртуальном объекте управления (ВОУ)

Итерационная разработка алгоритма управления начинается с фиксации частичной модели объекта управления, для которой пишется программный имитатор и алгоритм управления. После этого проверяется взаимное соответствие алгоритма и программного имитатора объекта. Обнаружение несоответствия означает наличие ошибок либо в алгоритме, либо в программной модели объекта, которые устраняются. В случае успешного прохождения теста частичная модель объекта управления усложняется. Цикл повторяется до реализации полноразмерного имитатора объекта управления.

Поскольку создание модели и алгоритма ведется независимо, радикально снижается вероятность не выявленных до начала пусконаладочных работ

ошибок, которая может быть оценена как произведение вероятностей ошибок в алгоритме управления и ВОУ:

•^остаточная ~ -^ошибки АУ -^ошибки ВОУ •

Для проведения работ требуются только ПК, а само ПО представлено тремя независимыми частями: 1) базовой функциональностью с визуализацией, оформляемой в виде исполняемого файла; 2) текстовой спецификацией поведения объекта; 3) текстовой спецификацией алгоритма управления. Поэтому, во-первых, программирование может вестись автономно от разработки аппаратуры; во-вторых, разработка алгоритма может вестись разными группами и, возможно, даже разными организациями; в-третьих, к процессу разработки могут привлекаться представители заказчика. Последнее особенно важно, поскольку коммуникативные проблемы между исполнителем и заказчиком (например, разночтения в техническом задании, ошибки в нем, вариативность реализаций интерфейса оператора), обусловленные математическим подходом при формулировке технического задания, могут стать причиной затягивания окончания работ (хотя бы потому, что обычно «всплывают» только на этапе пусконаладки).

Появляется возможность оперативно согласовать с заказчиком текущие вопросы по интерфейсу оператора, предметно обсудить разночтения и устранить неоднозначность технического задания. В конечном итоге разработка ведется без потенциально опасной неопределенности, что позволяет избегать психологических нагрузок, свойственных водопадной модели разработки. Становится возможным контролировать выполнение проекта и использовать для оценки степени готовности численные показатели, например, число обнаруженных ошибок как функцию времени [105].

Особый интерес описанный подход представляет в случае применения для программирования пакета Lab VIEW, расширенного языком Рефлекс, так как при этом сохраняется исходная однородность программных средств и концепций. В

этом случае вовлечение в процесс разработки представителей эксплуатирующей организации позволяет не только отработать эргономичность пользовательского интерфейса, но и заблаговременно ознакомить с ним будущих операторов и инструкторов.

6.4. Виртуальные лабораторные стенды: обучение студентов программированию задач промышленной автоматизации

С незначительными модификациями идея виртуальных объектов управления может быть использована и для решения проблемы подготовки специалистов в области промышленной автоматизации.

Качество получаемого образования определяется не только уровнем теоретической подготовки, но и умением использовать полученные знания на практике. Практические навыки обучающийся специалист приобретает через лабораторные работы и семинарские занятия, специально предусматриваемые в учебном плане. Достигаемые при этом эффекты: снижение «порога вхождения» в изучаемую область, сокращение времени на освоение материала, повышение уровня понимания теоретических положений. Для повышения уровня практической подготовки научных и технических специалистов в последние годы все более широкое применение находят информационные технологии, в частности, при организации лабораторных практикумов [198].

При изучении языков программирования, ориентированных на создание управляющих алгоритмов, также требуется, чтобы теоретические положения были подкреплены лабораторно-практическими занятиями по решению типовых задач из области промышленной автоматизации. Однако лабораторные стенды, реализующие физическое моделирование технологического процесса даже в упрощенном виде, предполагают серьезные финансовые затраты на их создание и поддержку в работоспособном состоянии. При таком подходе необходимо создать не только модель технологического процесса, но и оснастить ее датчиками, исполнительными устройствами и обеспечить сопряжение с компьютером через модули ввода-вывода. Стенды громоздки, занимают много

места, а ошибки, допускаемые студентами-практикантами при работе с ними, зачастую приводят к выходу стенда из строя.

В этих условиях наиболее перспективный способ организации практических занятий по курсам промышленной автоматизации - использование виртуальных лабораторных стендов (BJIC), основанных на идее виртуального объекта управления. По сравнению с физическими моделями BJTC имеют ряд очевидных преимуществ, дающих существенное сокращение материальных и временных затрат на создание, тиражирование и сопровождение лабораторных стендов.

6.4.1. Базовые требования, учитываемые при создании BJIC

ВЛС должен отвечать следующим требованиям, обеспечивающим разумный

баланс между наглядностью создаваемых имитаторов робототехнических комплексов, развитостью средств программирования алгоритмов управления и трудоемкостью решаемых задач.

При создании нового стенда следует учитывать:

• возможность создания анимированных двухмерных объектов;

• допустимость использования при моделировании объекта автоматизации нескольких слоев с изображениями;

• наличие поведения у имитируемого объекта, т. е. возможность задавать реакцию модели имитируемого объекта не только на основании текущих воздействий на модель, но и с учетом предыдущих воздействий;

• возможность подключения стороннего алгоритмического блока, создаваемого студентом-практикантом;

• стандартный интерфейс подключения стороннего алгоритмического блока, исключающий коррекцию имитируемого объекта, а равно связей между имитируемым объектом и сторонним алгоритмическим блоком в случае изменений алгоритма, создаваемого студентом-практикантом.

Во время практической работы обучающегося со стендом следует обеспечить:

• наличие ручного и автоматического режимов управления;

• использование языка программирования, ориентированного на управляющие алгоритмы, для создания алгоритма управления;

• наличие диагностической и отладочной информации.

6.4.2. Программные и технологические средства, используемые при создании BJIC

Чрезвычайно привлекательная идея использовать концепцию BJIC для создания лабораторного практикума осложняется отсутствием программных средств, ориентированных на имитационное моделирование объектов автоматизации. Схожая задача создания операторских тренажеров решается на практике с большими трудозатратами: либо с использованием SCADA-пакетов, например InTouch (Wonderware), Shadow Plant (Honeywell), либо, чаще всего, вообще без использования специализированных пакетов, на языках Си/Си++ [198-202], явно не предназначенных для решения таких задач. При таком подходе цена тренажера может достигать 1 млн долларов США [201]. Большинство широко известных языков имитации, таких как ARENA, Extend, WITNESS, QUEST, Enterprise Dynamics, AnyLogic и др., не имеют простых и мощных механизмов включения в модель правил и алгоритмов принятия решений [202], что не позволяет создавать на них «поведенческие» модели.

В этой связи вполне определенный интерес представляют пакеты прикладных программ технических вычислений и системы автоматизации научных исследований типа MATLAB и LabVIEW, широко используемые, в частности, как средства имитационного моделирования [203].

Использование в качестве базовой среды пакета LabVIEW имеет следующие обоснования. Хотя LabVIEW [79] позиционируется как средство разработки программно-аппаратных комплексов для тестирования, измерения, ввода данных, анализа и управления внешним оборудованием, с точки зрения решаемой задачи пакет имеет целый ряд привлекательных свойств. Интерфейс пользователя позволяет отображать результаты не только в виде графиков и целого спектра графических элементов, но также работать с изображениями в

форматах tiff и bmp. Специальный механизм (блок-диаграмма) дает возможность программировать функции управления объектами графического интерфейса. Вполне определенный интерес представляет и возможность оформить создаваемые имитационные модели в виде автономных модулей (.ЕХЕ) и в виде совместно используемых динамических библиотек (.DLL), предоставляемая в Lab VIEW Pro. Это позволяет тиражировать создаваемые стенды и исполнять их автономно от среды разработки. Немаловажное обстоятельство - популярность Lab VIEW и его широкое использование в обучающем процессе, в частности, для создания лабораторных стендов. И хотя такое использование затрагивает в основном аналоговые случаи (электротехника, оптика, термодинамика и т. п. [204]), опыт показывает, что средствами Lab VIEW можно создавать и несложные поведенческие алгоритмы, в частности, дискретные и событийно-управляемые (см. напр. [125]).

Однако при усложнении алгоритмов необходимо использовать полноценный процесс-ориентированный язык, в нашем случае - язык Рефлекс.

Для интеграции алгоритмов, создаваемых на языке Рефлекс, в среду Lab VIEW был использован интерпретатор языка Python [205, 206]. В отличие от варианта [207], в котором применялся встроенный в Lab VIEW способ интеграции алгоритмического блока - механизм Formula Node, это позволяет создать законченное приложение, независимое от пакета разработки Lab VIEW. В описываемом подходе алгоритм на языке Рефлекс, создаваемый обучаемым, преобразуется в текст на языке Python, который затем запускается на исполнение интерпретатором языка Python и взаимодействует с имитатором объекта (рис. 6.10). Эквивалентная запись алгоритма на языке Python получается транслятором, созданным на базе существующего транслятора языка Рефлекс в язык Си. Интерпретатор языка Python интегрирован в среду Lab VIEW через механизм ActiveX. При реализации взаимодействия управляющего алгоритма и имитатора объекта используется программная модель языка Рефлекс -многопоточный вариант гиперпроцесса. Тактирование гиперпроцесса

произведено штатными средствами LabVIEW: основной цикл гиперпроцесса «обернут» тактируемым циклом с периодом 100 мс.

Текст алгоритма на языке Рефлекс

О

Текст алгоритма на языке Python

Интерпретатор языка Python

обмен данными

Имитатор объекта

Рис. 6.10. Схема получения управляющего алгоритма для взаимодействия

с имитатором объекта

Обмен данными между моделью объекта управления и программой управления реализован через массивы ввода/вывода. Для автоматической выборки входных/выходных переменных из массива использован стандартный синтаксис языка Рефлекс. Внутренние переменные гиперпроцесса, обеспечивающие идентификацию текущих функций-состояний процессов fcar и текущих времен icur, сохраняются в регистровых массивах, что гарантирует сохранение значений от цикла к циклу и независимость структурных связей от проектируемого алгоритма. В отличие от обычно используемых на практике [125], такой подход на основе массивов обеспечивает и неизменность структурных связей между программными модулями для заданного виртуального стенда, поскольку исключает влияние количества переменных на эти связи. Замечательно, что при описываемом подходе структура связей сохраняется и для различных лабораторных стендов, за исключением места присоединения модели виртуального объекта к массивам ввода/вывода, которые, очевидно, должны быть откорректированы в соответствии со сценарием задачи и моделью объекта управления. Механизм ActiveX обеспечивает доступность входных/выходных массивов, необходимых для взаимодействия управляющей программы с объектом управления, и служебных переменных, требующихся для работы модели гиперпроцесса, из текста на языке Python.

Работа студента-практиканта с виртуальным стендом в рамках описываемой концепции происходит следующим образом (рис. 6.11). Сначала создается текстовая спецификация алгоритма на языке Рефлекс, затем запускается ее трансляция в язык Python. При обнаружении синтаксических ошибок во время трансляции происходит возврат к редактированию. После успешной трансляции алгоритм управления, представленный уже в тексте языка Python, запускается на исполнение и тестируется на корректность путем создания различных ситуаций, предусмотренных сценарием задачи. В случае обнаружения некорректного поведения алгоритма происходит возврат к начальному этапу редактирования текста алгоритма управления.

6.4.4. Пример реализации BJIC. Набор виртуальных лабораторных стендов

Продемонстрируем работу BJIC на упрощенной задаче управления автоматизированной линии розлива бутылок, рассмотренной ранее (из исходной системы исключен нагреватель).

Текст Транслятор Запуск

на языке <=Ф языка алгоритма и

Рефлекс Рефлекс тест на модели

ошибки

ошибки

I

Рис. 6.11. Схема работы по созданию и отладке управляющего алгоритма

Автоматизированная линия розлива бутылок, имитационная модель которой изображена на рис. 6.12, состоит из конвейера, по которому слева направо двигаются пустые бутылки, и бака с разливаемой жидкостью. Конвейер можно включать и отключать. В баке имеется сопло, которое можно открывать и закрывать. Также в системе присутствуют два дискретных датчика: для

определения нахождения бутылки под соплом и контроля уровня жидкости в бутылке.

Сценарий задачи | Алгоритм ф | Ошибки • \ Ру-Соде * \ Помощь | КОНЕЦ РАБОТЫ

Виртуальный стенд #7 Автоматизированная линия розлива бутылок

9

ММ:

ГУГЫЯкЛиЯвЯП»

Рис. 6.12. Реализация виртуального лабораторного стенда «Автоматизированный розлив бутылок»: внешний интерфейс

Имитационная модель линии розлива реализуется штатными средствами ЬаЬУ1Е\У для работы с изображениями путем наложения графических примитивов конвейера и бутылки. Наполнение бутылки жидкостью имитировалось через постепенное закрашивание горизонтальных слоев пикселей от дна бутылки. Срабатывание датчиков наличия бутылки под соплом и уровня жидкости в бутылке определялось путем анализа цвета пикселей в заданных координатах сцены. В случае открытия сопла при отсутствии бутылки или при переполнении бутылки предусмотрена имитация пролива жидкости на конвейер.

Пользовательский интерфейс приложения обеспечивает возможность ввода алгоритма (закладка «Алгоритм») и просмотра результатов трансляции (закладки «Ошибки» и «Ру-Соёе»). Краткое описание условия задачи доступно через закладку «Помощь». Выход из приложения осуществляется через закладку «КОНЕЦ РАБОТЫ».

Стенд предусматривает два режима управления конвейером и соплом: ручной и автоматический. В ручном режиме имеется возможность

непосредственного управления линией (конвейером и соплом). В автоматическом режиме возможность ручного управления блокируется, а команды управления соплом и конвейером формируются алгоритмом, созданным студентом-практикантом по описанной выше схеме. В обоих режимах имеется возможность установки бутылки на конвейер. В специальном окне отображаются числовые идентификаторы текущих функций-состояний процессов.

Блок-диаграмма организации взаимодействия ActiveX компонента и модели объекта управления приведена на рис. 6.13.

Рис. 6.13. Реализация виртуального лабораторного стенда «Автоматизированный розлив бутылок». Блок-диаграмма соединений

ActiveX компонента с интерпретатором Python: 1 - массивы входных/выходных и служебных переменных, поступающие на вход

интерпретатора Python; 2 - интерпретатор Python; 3 - формируемые массивы выходных и служебных переменных; 4 - навигационное окно программы (светлым выделен отображаемый участок блок-диаграммы); 5 - код на языке Python, получаемый из текста на языке Рефлекс

L

На входы компонента подаются массивы входных/выходных переменных, служебных переменных и текст на языке Python, получаемый из текста на языке Рефлекс. В результате работы формируются массивы выходных переменных и служебных переменных. Выходные переменные затем отрабатываются моделью объекта управления, а служебные переменные запоминаются для использования на следующем цикле.

Предложенная методика была использована при создании набора виртуальных лабораторных стендов (рис. 6.14—6.20) [111, 208], который внедрен в учебный процесс в Новосибирском государственном университете (см. акты о внедрении).

Рис. 6.14. Внешний интерфейс BJ1C «Электросушилка для рук»

Рис. 6.15. Внешний интерфейс BJIC «Перекресток»

Py-Coda >

Помощь КОНЕЦ РАБОТЫ

Cmilipirft моачи Алгоритм Ошибки •

Виртуальный стомд ш 3 Автоматизированный poima бутылок

Рис. 6.16. Внешний интерфейс ВЛС «Линия розлива бутылок»

Сценарий задачи Алгоритм • Ошибки • Ру СсиЗе • Помощь КОНЕЦ РАБОТЫ

Виртуальный станд ш 5 Лифт пятиэтажного дома

ЗБ' С*

5Г

з»

' -Ч' Ч I' ■

<а> СЗ

С»

съ С»

О О

э э э

Ш |» у», р»,

О Ж Н а к««) Огщ*ч« 9 * •

о ачмп> ] оп*мп> • •

О « Опрмч} • •

о ** и«1 Оп*«: • •

Рис. 6.17. Внешний интерфейс ВЛС «Сортировочный конвейер»

Сценарий задачи Алгоритм • Ошибки • Ру-СоРе • Помощь КОНЕЦ РАБОТЫ Турнжаты

Рис. 6.18. Внешний интерфейс ВЛС «Лифт»

Рис. 6.19. Внешний интерфейс ВЛС «Турникет»

Виртуальный стенд * 7 Батоиосмесительный умл

задачи Алгоритм • Ошибки • Ру-СоРе • Помощь КОНЕЦ РАБОТЫ

Рис. 6.20. Внешний интерфейс ВЛС «Бетоносмесительный узел»

6.5. Примеры использования виртуальных объектов управления на практике

Рассмотрим примеры возможного практического использования виртуальных объектов управления.

6.5.1. Технологическая линия получения углеводных кормовых добавок

При разработке технологии осахаривания крахмалов возникла проблема автоматизации технологического процесса. Технология (рис. 6.21) включает следующие операции: измельчение зерна до фракции дробленки, дезинтеграция водно-зерновой суспензии в диспергаторе кавитационного действия с одновременным нагреванием смеси. В емкости рециркуляции последовательно идут стадии желатинизации-клейстеризации и ферментативное разжижение. Далее гидролизат перемещают в ферментер и проводят стадию ферментативного осахаривания. Готовую продукцию перекачивают в емкость для хранения и далее в кормораздатчик. В отдельную стадию выделена водоподготовка, на которой происходит очистка воды фильтрованием и ее нормализация.

Т«г»тг-М11 Мол»

«П.щЖ». $ Ц

Р 1 СП вг-т-яг* Р " 1

•Г 1»> ¡¡¿2 ~~|

т»а

| I

Е I

ц»|5в ]

•пл е I

гттт?

«ъ-юл Е | •л_грол ЕР | •с.сшвл £Г~I

Рис. 6.21. Компьютерная модель технологической линии получения кормовых паток из зернового сырья (интерфейс оператора)

Автоматизация процесса позволяет повысить производительность оборудования, снизить квалификационные требования к обслуживающему персоналу, обеспечить повторяемость процесса и постоянное качество производимой продукции, а также исключить нарушения технологического регламента, которые могут приводить не только к порче исходного сырья, но и к простоям оборудования.

Автоматизация систем управления химическими процессами ставит перед программистом проблему отладки управляющего алгоритма. С одной стороны, необходима обкатка алгоритма с целью проверки его корректности, а с другой стороны, такая обкатка на реальном объекте сопряжена с опасностью возникновения аварийных ситуаций: поломкой дорогостоящего оборудования, травматизмом обслуживающего персонала или аварией техногенного характера с тяжелыми экологическими последствиями.

Моделирование велось на базе пакета LabVIEW [127, 209, 210, 211]. В качестве языка программирования алгоритмов управления был использован язык Рефлекс.

Для интеграции алгоритмов, создаваемых на языке Рефлекс, в среду LabVIEW был использован механизм Formula Node.

Помимо отработки алгоритмов управления и схемы установки, созданное программное обеспечение в дальнейшем выполняло и маркетинговую функцию: с его помощью потенциальным заказчикам наглядно демонстрируются возможности и преимущества продвигаемой технологической схемы.

6.5.2. Технологические линии получения биогаза и биодизеля

Подход, аналогичный описанному, был использован при отработки

технологий получения топлив альтернативной энергетики [212-215]. Исследовались возможность и алгоритмы автоматизации получения газообразного топлива из органических отходов (биогаза) и жидкого топлива из рапсового масла (биодизеля).

Технологическая схема получения биодизеля из рапсового масла включает (рис. 6.22): приемную емкость для масла; фильтр для очистки масла от примесей; промежуточную емкость очищенного масла; реактор для смешивания спирта (С2Н5ОН) со щелочью (КОН, NaOH); кавитационную установку с емкостью для рециркуляции, где идет процесс получения биодизеля (реакция переэтерификации); емкость для отделения биодизеля от глицерина; емкость для

промывки (очистки) биодизеля; емкость для хранения глицерина; емкость для хранения биодизеля.

Технологическая линия получения биогаза (рис. 6.23) состоит из приемного бункера, дробилки предварительного измельчения, кавитатора с емкостью рециркуляции, ферментеров аэробного и анаэробного брожения, устройства для сушки и очистки биогаза, газгольдера, средств преобразования получаемого газа в тепло и (или) электроэнергию.

ЛИНИЯ ПОЛУЧЕНИЯ БИОДИЗЕЛЯ

Рис. 6.22. Компьютерная модель технологической линии получения биодизеля

В качестве базовой среды визуализации также использовался пакет LabVIEW (рис. 6.22, 6.23), но в отличие от предыдущего примера был использован механизм интеграции на основе интерпретатора Питон. В дополнение к базовой схеме введена возможность спецификации на языке Рефлекс и поведения модели. Это позволяет не только оперативно изменять алгоритм управления и исследовать его, не привязываясь к среде разработки LabVIEW, но и оперативно изменять модель объекта управления.

Используемый подход показал не только удовлетворительную наглядность модели, возможность изменения параметров модели в широком диапазоне, но и возможность создания моделей с нетривиальным (событийно управляемым)

поведением и использования созданных алгоритмов при дальнейшей автоматизации процесса.

iiiiiiiaiiiiini

01 ос ю х я » v а

II U U И И 16

7=Г' Г *" ISHa

Рис. 6.23. Компьютерная модель технологической линии получения биогаза

Выводы главы

Использование языка Рефлекс демонстрируется на тестовых примерах создания управляющих алгоритмов: технологическая линия загрузки гравия, управление микроволновой печью, линия розлива бутылок.

Далее приводятся сведения об использовании языка Рефлекс при создании АСУ технологическим процессом выращивания монокристаллического кремния методом Чохральского.

Система построена на серийно изготавливаемой элементной базе и имеет распределенную многомашинную архитектуру, включающую набор программных средств технологического уровня и программно-технические комплексы (ПТК) производственного участка, объединенные цеховой сетью Ethernet.

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

включает ростовую установку и герметичный шкаф программного управления, на передней панели которого расположен сенсорный экран промышленного ПК, реализующий мультимедийный интерфейс пользователя. Высоконадежный контроллер обеспечивает отработку технологических программ, интеграцию цифровых устройств: приводов, датчиков, выносного пульта оператора, источника питания, - и управление подсистемами ростовой установки.

Высокая вероятность нерегламентного течения технологического процесса и серьезный материальный ущерб при аварии с возможным травматизмом обслуживающего персонала, сложность и разнородность алгоритма управления позволяют отнести технологический процесс к классу критических.

Вытекающие из этого базовые требования к ПО (высокая надежность и устойчивость ПО; постоянный контроль возникновения аварийных ситуаций во время работы, их точная диагностика и автоматическое устранение; предотвращение действий оператора, ведущих к аварийным ситуациям; необходимость интеграции в систему удаленных датчиков и серводвигателей, документирование текущих параметров с возможностью их считывания извне для последующего анализа и обработки специализированным ПО; удаленный мониторинг технологического процесса; реализация гетерогенного алгоритма управления с большим числом параллельно исполняемых процессов; высокая степень гибкости и модифицируемости алгоритма управления; высокая степень модульности алгоритма с возможностью модификации как во время отладки, так и на протяжении всего жизненного цикла) обусловили двухуровневую архитектуру построения ПО с явным выделением управляющего ПО в качестве ядра системы и подчинением ему ПО, реализующего интерфейс оператора.

Для спецификации алгоритма управления использовался процесс-ориентированный язык Рефлекс. Вычислительная платформа - М1сгоРС с процессором СРиб86Е фирмы Раз1\уе1, 300 МГц. Алгоритм управления был описан в виде гиперпроцесса с числом процессов около 800. Размерность

1 лЗО

поведенчески-эквивалентного конечного автомата - порядка 10 состоянии. Вариант реализации - системонезависимая (инструментальные функции загрузки возложены на ОС MS DOS 6.22). Для получения целевого машинного кода использовался транслятор Рефлекс версии 1.5 в совокупности с компилятором Borland С++ версии 3.1. Период активизации гиперпроцесса -100 мс. Пиковая нагрузка - не более 9 мс. Время реакции на внешнее событие -не более 110 мс (достижимое время реакции - 20 мс).

Практическая апробация алгоритма в составе ростовых установок позволила отработать технологию получения монокристаллов кремния диаметром 150 мм. Код, созданный средствами процесс-ориентированного языка Рефлекс, показал высокую надежность и модифицируемость: даже существенные расширения функциональности носят локальный характер, что обусловлено ключевым свойством средств процесс-ориентированного программирования создавать управляющие алгоритмы, структурно эквивалентные технологическому описанию объекта управления.

Предложена и обсуждена концепция итерационной разработки управляющих программ на основе виртуальных объектов управления (ВОУ), которая интенсифицирует процесс разработки управляющих алгоритмов и снижает риски при вводе систем управления в эксплуатацию.

Использование метода в реальных проектах по автоматизации позволяет:

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

2. Контролировать процесс создания управляющих алгоритмов и снизить психологическую нагрузку на коллектив разработчиков.

3. Уменьшить трудоемкость проекта и имеющиеся риски этапа пусконаладки.

4. Гибко расширять круг лиц, участвующих в процессе разработки и приемо-сдаточных испытаний, в том числе, с целью выявить и устранить ошибки в техническом задании, согласовать варианты исполнения,

сократить время подготовки операторов к этапу внедрения и последующей эксплуатации.

Подход использовался при автоматизации технологического процесса

контроля радиоэлектронной аппаратуры (схема: Lab VIEW, язык G). Полученные результаты подтверждают теоретические выводы: до пусконаладочных работ выявлен и устранен ряд неопределенностей в техническом задании, сокращены сроки выполнения работы, продолжительность приемо-сдаточных испытаний сокращена с одного месяца (планируемый срок) до рабочей недели. Последующая существенная модернизация проекта проводилась дистанционно, без присутствия разработчика на приемо-сдаточных испытаниях.

Рассмотрен пример использования концепции ВОУ при отработке технологий получения углеводных кормовых добавок и побочных продуктов пищевой промышленности в биотопливо (биогаз и биодизель). В работах проведена оценка параметров технологического процесса, уточнен состав технологического оборудования, получены алгоритмы управления технологическими процессами и компьютерные модели, активно используемые в качестве демонстрационных макетов при общении с заказчиками.

Рассмотрен пример использования концепции ВОУ при создании набора виртуальных лабораторных стендов, ориентированных на практическое освоение основ программирования задач промышленной автоматизации. Приведена архитектура системы. В качестве рабочей среды использована среда Lab VIEW, расширенная языком процесс-ориентированного программирования Рефлекс. Интеграция транслятора Рефлекс в среду Lab VIEW выполнена на основе интерпретатора языка Python и механизма Active X.

Реализованный набор виртуальных лабораторных стендов позволил подкрепить лекции практическими занятиями по автоматизации технологических процессов, исключить из рассмотрения рутинные вопросы физического моделирования и сконцентрироваться на концептуальном уровне создания управляющих алгоритмов.

ВЫВОДЫ И РЕЗУЛЬТАТЫ

В диссертации решена крупная научная проблема, имеющая важное народно-хозяйственное значение, - проблема создания понятийных, лингвистических и инструментальных средств для спецификации алгоритмов управления сложными техническими системами на основе теоретически обоснованной и практически подтвержденной технологии процесс-ориентированного программирования, внедрение которой вносит значительный вклад в развитие экономики страны и повышение ее обороноспособности.

В диссертации получены следующие основные результаты:

1. Выявлен и описан набор уникальных классификационных признаков, характерных для задач промышленной автоматизации; на их основе сформулированы требования к формальным и лингвистическим средствам описания управляющих алгоритмов.

2. Разработаны понятийный аппарат процесс-ориентированного программирования и формальная математическая модель гиперпроцесса, представляющая управляющий алгоритм в виде периодически активизируемой совокупности логически параллельных слабосвязанных процессов событийно-управляемых полиморфных структур с индивидуальными таймерами.

3. Определены варианты программной реализации модели гиперпроцесса на процедурных языках, языках МЭК 61131-3, LISP и G, выявлены возможные модификации гиперпроцесса, обеспечивающие повышенную утилизацию вычислительных ресурсов платформы и статическую балансировку вычислительной нагрузки в средах с кооперативной многопоточностью: а) гипер процесс с плавающим периодом активизации; б) гиперпроцесс с индивидуальными делителями частоты активизации процессов.

4. Предложены грамматики текстовых и графических процесс-ориентированных языков (Си-подобного языка Рефлекс, расширенного языка ST / МЭК 61131-3, графического языка HPD).

5. Разработаны и реализованы трансляторы языка Рефлекс для генерации Си-кода (R2C), кода на языке Formula Node (R2CFN) и Python-кода (R2Py).

6. Предложен новый итерационный подход к разработке управляющих алгоритмов уровня ПЛК средствами процесс-ориентированного программирования на основе унифицированной связки «алгоритм управления - виртуальный объект управления» и разработан набор виртуальных лабораторных стендов, позволяющих организовать практическую отработку стратегий создания управляющих алгоритмов средствами процесс-ориентированного программирования.

7. Проведена практическая апробация предложенных средств процесс-ориентированного программирования на серии задач создания систем управления: автоматизация процесса выращивания монокристаллического кремния, корунда; автоматизация технологического процесса контроля радиоэлектронной аппаратуры; отработка технологий переработки органического сырья в биотопливо и зерновые патоки.

Список сокращений

EBNF - Extended Backus-Naur Form.

FBD - Functional Block Diagram, один из графических языков МЭК 61131-3. HPD - Hyper-process Diagram.

IL - Instruction List, ассемблероподобный язык из состава МЭК 61131-3. LabVIEW - Laboratory Virtual Instrumentation Engineering Workbench, графическая среда разработки компании National Instruments.

LD - Ladder Diagram, графический язык из состава МЭК 61131-3, реализующий концепцию релейно-контактных схем.

MRDS - Microsoft Robotics Developer Studio, графическая среда разработки компании Microsoft.

SFC - Sequential Function Chart, один из графических языков МЭК 61131-3, реализующий концепцию сетей Петри.

ST - Structured Text, паскалеподобный язык из состава МЭК 61131-3.

АРМ - автоматизированное рабочее место.

АУ - алгоритм управления.

БД - база(ы) данных.

БУМ - базовый управляющий модуль.

BJIC - виртуальный лабораторный стенд.

ВОУ - виртуальный объект управления.

КПУ - контроллер программного управления.

ММКА - модернизированная модель конечного автомата.

МЭК - Международная электротехническая комиссия.

ОУ - объект управления.

ПЛК - программируемый логический контроллер. ПКО - персональный компьютер оператора. ПО - программное обеспечение.

ПО АС - процесс-ориентированная алгоритмическая структура.

СПТФП - строковая переменная текущей функции процесса.

ТП - технологическая программа.

УВМК - установка для выращивания кремния.

УСО - устройство связи с объектом.

Список литературы

1. Ляпунов А. А. О логических схемах программ // Проблемы кибернетики, 1958. Вып. 1.С. 5-22.

2. Щедровицкий Г. П. Два понятия системы / в кн.: Избранные труды. М.: Школа культурной политики, 1995. С. 228-231.

3. Закревский А. Д. Параллельные алгоритмы логического управления. М.: Эдиториал УРСС, 2003. 200 с.

4. Зюбин В. Е. Язык Рефлекс. Математическая модель алгоритмов управления // Датчики и системы. 2006. № 5. С. 24-30.

5. Banatre, J-P. Parallel multiset processing: From explicit coordination to chemical reaction // Lecture Notes in Computer Science. Vol. 1061/1996. Springer Berlin/Heidelberg. 1996.

URL:http.7/www.springerhnk.com/content/75875q5712ri37k3/fulltext.pdf

6. Зюбин В. E. Многоядерные процессоры и программирование // Открытые системы. 2005. №7-8. С. 12-19. URL:http://www.osp.ru/os/2005/07-08/185743/

7. Hanisch Н.-М. Closed-Loop Modeling and Related Problems of Embedded Control Systems in Engineering / In book: Abstract State Machines, SpringerVerlag, LNCS Vol. 3052, 2004. P. 6-1.

8. Янг С. Алгоритмические языки реального времени: конструирование и разработка. М.: Мир, 1985.

9. Кнут Д. Искусство программирования для ЭВМ. М.: Мир, 1976.

10. Хоор К. О структурной организации данных. В кн.: Дал У., Дейкстра Э., Хоор К. Структурное программирование. М.: Мир, 1978.

11. Dijkstra Е. W. GOTO Statement Considered Harmful, Communication of the ACM, Vol. 11, No 3, 1968

12. Abelson H., Sussman G. J., Sussman J. Structure and Interpretation of Computer Programs. // L.; N.-Y.: The MIT Press; McGraw Hill, 1996. - 657 p.

13. Green T. R. G., Petre M. When Visual Programs are Harder to Read than Textual Programs // Human-Computer Interaction: Tasks and Organisation, Proc. ECCE-6 (6th European Conference on Cognitive Ergonomics). G. C. van der Veer, M. J. Tauber, S. Bagnarola and M. Antavolits (Eds.) CUD: Rome, 1992. URL:http://citeseer.ni.nec.com/green92when.html

14. Brooke J. В., Duncan K. D. Experimental studies of flowchart use at different stages of program debugging // Ergonomics. 1980. V. 23.

15. Curtis В., Sheppard S., Kruesi-Bailey E., Bailey J. and Boehm-Davis D. Experimental evaluation of software documentation formats. // J. Systems and Software. 1989. V. 9. No 2.

16. 16. Whitley K. N. Visual Programming Languages and the Empirical Evidence For and Against // Journal of Visual Languages and Computing. 1997. V. 8/ No 1. URL :http://citeseer.ni .nec.com/whitlev96visual.html

17. вэн Дам Э. Пользовательские интерфейсы нового поколения // Открытые системы. 1997. № 6. URL:http://www.osp.ru/os/1997/06/34.htm

18. Карпов Д. Ю. Этот мерзкий, неудобный, противоестественный оконный интерфейс [опубликовано на URL:http://www.webclub.ru ]

19. Ершов А. 77. О человеческом и эстетическом факторах в программировании // Кибернетика. - 1972. - № 5. С. 95—99.

20. Дал У., Дейкстра Э., Хоор К Структурное программирование. М.: Мир. 1975.-248 с.

21. Шнейдерман Б. Психология программирования. М.: Радио и связь. 1984. -304 с.

22. Ericsson К. A., Kintsch W. Long-Term Working Memory // Psychological Review. 1995. V. 102. No 2.

23. Miller G. A. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information // Psychological Review. 1956. V. 63. No 2.

24. Авербух В. JI. Метафоры визуализации. // Программирование. 2001. № 5. С. 13-17.

25. Зюбин В. Е. Графика или текст: какой язык нужен программисту? // Открытые системы. 2004. № 1. С. 54-58.

26. Зюбин В. Е. Человеко-ориентированное программирование // Вестник ТГУ. 2010. № 1.С. 52-60

27. Бургин М. С. Переменные в языке блок-схем // Программирование. 1978. №2.

28. Саркисян А. А. Повышение качества программ с помощью автоматизированных методов. М. 1991.

29. Arthur 77. Watson, Thomas J. McCabe, Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric // NIST Special Publication 500-235. National Institute of Standards and Technology, August 1996

30. Kaner, Dr. Cem, Software Engineer Metrics: What do they measure and how do we know? // CiteSeerX: 10.1.1.1.2542

31. Lincke R., Lundberg J., Lowe W. Comparing software metrics tools // International Symposium on Software Testing and Analysis 2008. P. 131-142

32. Зюбин В. E. Исследование условий применимости языка параллельного программирования СПАРМ для задач построения надежных управляющих программ // Распределенная обработка информации: Тр./Шестой международный семинар. -Новосибирск. 1998

33. Андриенко Г. Л., Андриенко 77. В. Интеллектуальная картографическая визуализация для поддержки исследования данных в системе IRIS // Программирование. 1997. № 5.

34. IEC 61131-3. Programmable controllers. Part 3: Programming languages, 2nd Ed. // IEC 65B/373/CD, International Electrotechnic Commission. 1998.

35. Касьянов В. 77. Применение графов в программировании // Программирование. 2001. № 3.

36. Бабурин Д. Е., Бульонков М. А., Емельянов 77. Г., Филаткина 77. 77. Средства визуализации при перепроектировании программ. // Программирование. 2001. №2.

37. Жоголев Е. А. Графические редакторы и графические грамматики // Программирование. 2001. № 3.