Динамическое структурирование проектов автоматизации технологических процессов

О.А. Большаков

аспир., OlegBolshakov@mail.ru

ИКТИ РАН

А.В. Рыбаков

канд. техн. наук, доц. каф. «АСОИУ» avr48@rambler.ru

МГТУ  СТАНКИН, г. Москва

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

 

При подготовке проектов автоматизации существующих технологических процессов (ТП) их инженерная часть, как правило, состоит из:

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

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

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

Данная статья касается программной составляющей проектов автоматизации, которая реализуется на ПЛК.

Разработка проектов автоматизации

Разработка проектов автоматизации  сегодня – это работа программиста(ов) по созданию программного обеспечения (ПО) согласно техническому заданию. ПО разрабатывается в специализированных программных средах. Это обусловлено тем, что ведущие мировые вендоры в области автоматизации, такие как Siemens (контроллеры серии S-300, S-400), Schneider Electric (контроллеры серии Modicon M340, Premium, Quantum), Rockwell   

Automation (контроллеры серии MicroLogix, SLC500 и др.) производят ПЛК с закрытой архитектурой. Специализированные программные пакеты для разработки программ управления технологическим процессом (ТП), как правило, выпускаются теми же производителями ПЛК. Например, у компании Siemens– это программный пакет SIMATICSTEP 7; для контроллеров компании Schneider Electric используются программные пакеты UnityProXL и ConceptXL; для программирования ПЛК концерна Rockwell Automation используется среда программирования RSLogix. Все эти программные пакеты объединяет поддержка стандарта «IEC61131-3» международной электротехнической комиссии [1].

Данный стандарт описывает пять языков программирования и фактически определяет возможности построения программ для ПЛК. Автоматизация разработки ПО при таком подходе достигается за счёт локализации задач путём создания пользовательских функциональных блоков с их многократным использованием по принципу «тип – экземпляр». Это традиционный подход, при котором программист на основе технического задания разрабатывает ПОна пяти доступных языках программирования. При работе над небольшими проектами такого подхода к организации процесса разработки программного продукта вполне достаточно. Однако при больших и сложных проектах, длящихся не один год и построенных на ПЛК разных производителей, этих возможностей уже недостаточно для эффективной разработки ПО (под термином «эффективность разработки ПО» понимается отношение показателей качества программного продукта к затраченному времени и стоимости его разработки).С увеличением топологии аппаратной части проекта (число используемых контроллеров, устройств управления, устройств сбора данных ТП) и возрастанием сложности логики управления эффективность традиционного подхода значительно снижается. Затрачивается неоправданно много времени на проектирование, реализацию и интеграцию ПО. Основные причины, по которым это происходит:

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

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

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

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

рис. 1 Традиционный метод разработки ПО

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

Формулировка предлагаемого метода

Предлагаемый метод разработки ПО для ПЛК основан на синтезе трех технологий (рис. 2):

рис. 2 Создание методики на основе трех технологий

·          технология модельно – ориентированного проектирования. Идея модельно – ориентированной разработки ПО принадлежит группе Object Management Group (OMG), запустившей проект Model Driven Architecture (MDA,http://www.omg.org/mda/). Этот проект стал новым направлением в программной инженерии. Основной идеей этого проекта является независимое рассмотрение моделей, создаваемых при проектировании системы, от деталей их реализации на конкретной программно – аппаратной платформе. Эта идея позволяет создать связь между этапами жизненного цикла ПО. Модель не является чем-то специфическим, что может понять только программист. Модель в данном случае – это абстрактное отражение ТП. Модель проста в понимании и редактировании для всех участников проекта. Применение этой технологии к разработке проектов автоматизации ТП является актуальным вопросом в настоящий момент и, по мнению авторов данной статьи, весьма перспективным;

·          DSL (предметно – ориентированные языки программирования) [2-5]. В области автоматизации ТП, в связи с ростом сложности алгоритмов управления, возникает необходимость в графическом представлении структуры проектного кода. По этой причине адаптивные объектные модели строятся без использования объектно– ориентированных языков общего назначения. Элементами предметно – ориентированного языка являются разработанные специально для определённой предметной области графические модели. Это основное отличие от технологии DSL и точка синтеза модельно – ориентированного проектирования и предметно – ориентированного проектирования. То есть, для автоматизации разработки ПО создаётся предметно – ориентированный язык программирования, элементами которого являются графические модели предметной области. Таким образом, этап моделирования и этап разработки исходного кода на целевом языке программирования являются одним целым;

·          SWITCH – технология [6], также известная как технология автоматного программирования, включает в себя математический аппарат для формального и изоморфного преобразования автоматных моделей в программный код, что является ключевым преимуществом перед другими технологиями моделирования поведения сложных систем. SWITCH – технологию предлагается использовать для моделирования динамической части разрабатываемого ПО, а для построения каркаса программного кода и моделирования ТП как процесса в целом используется предметно – ориентированный язык в графическом представлении. Таким образом, интеграция моделей предметной области и автоматных моделей является второй точкой синтеза трех технологий.

Применение методики динамического структурирования проектов

Применение методики динамического структурирования проектов начинается с создания собственного предметно – ориентированного языка. Процесс создания делится на три этапа:

1.     определение абстрактного синтаксиса;

2.     определение конкретного синтаксиса;

3.     определение правил трансформации.

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

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

Правила трансформаций – это правила, по которым абстрактное представление транслируется в исполнимое.

На рис. 3 показана связь этих трех элементов предметно – ориентированного языка.

рис. 3 Связь абстрактного синтаксиса и конкретного синтаксиса

Для создания библиотеки графических элементов, определения их свойств и манипулирования этими элементами используется векторный графический редактор Microsoft Visio. Разработка библиотеки графических элементов для предметно – ориентированного языка осуществляется с помощью Shape Sheet – информации для графических элементов [7]. Благодаря возможности присвоения графическому элементу Shape Sheetинформации, Microsoft Visio стал уникальной системой со схематическим отображением данных в виде таблицы для каждого графического элемента диаграммы или схемы. Простая фигура может инкапсулировать в себе сложное поведение, включая сложные математические формулы и функции, которые хранятся и вводятся в таблицы таким же образом, как вводятся данные в клетки листа Excel.

рис. 4 Процедура трансформации модели в исходный код

Извлечение информации из файлов MS Visio в библиотеку объектов выполняется с использованием COM – объекта (технологический стандарт от компании Microsoft) [8]. Далее на основе данных из библиотеки объектов формируется XML описание модели. Созданный  XML файл обрабатывается XSLT – процессором с применением заданного пользователем шаблона. Шаблон XSLT содержит в себе правила трансформации конфигурационного XML файла и структуру целевого языка программирования. Рис. 4 отображает всю процедуру трансформации.

Верификация

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

В настоящее время проверка моделей «Modelchecking»[9-12] базируется на полном просмотре пространства состояний модели: для каждого состояния проверяется– удовлетворяет ли оно сформулированным требованиям. Алгоритмы гарантированно завершаются, так как модель конечна [13].

Основная причина применения метода «Modelchecking» для верификации моделей предметной области состоит в том, что в отличие от классической формальной верификации первый метод позволяет проверять динамические свойства программ – те, которые можно записать с помощью темпоральной (временной) логики. А классический метод проверяет – соответствует ли состояние переменных на выходе из программы условиям, накладываемым на их входное состояние [14].

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

Заключение

В данной статье рассмотрен метод «Динамического структурирования проектов», в основе которого лежит синтез трёх технологий: модельно – ориентированной разработки, языков предметной области и автоматного программирования. Модельно – ориентированная разработка в совокупности с языком предметной области рождают идею создания методики проектирования графических модельно – ориентированных языков предметной области. Графический язык предметной области с привязкой к программному коду позволяет моделям проходить полный жизненный цикл ПО и быть единым лаконичным информационным центром данных о разрабатываемой системе для всех участников проекта.

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

Данная методика была успешно апробирована в металлургической и энергетической отраслях на оборудовании компаний Schneider Electric и Siemens.

Литература

1.    Karl-Heinz John, Michael Tiegelkamp. Programming Industrial Automation Systems. Concepts and Programming Languages, Requirements for Programming Systems, Aids to Decision-Making Tools. 2001.

2.    Мартин Фаулер. Предметно-ориентированные языки программирования. Издательство: Вильямс. Серия: Signature Series. ISBN 978-5-8459-1738-6, 978-0-321-71294-3; 2011 г. 576 стр.

3.    Marjan Mernik. Formal and Practical Aspects of Domain-Specific Languages: Recent Developments. ISBN 1466620927; 2012 г.410 стр.

4.    Stefan Kroes. Domain Specific Embedded Languages and Model Driven Engineering: Building a Model Transformation Language as a DSEL using Ruby. ISBN 3844319468; 2011 г. 76 стр.

5.    Ayende Rahien. DSLs in Boo: Domain Specific Languages in .NET. ISBN 1933988606; 2010 г. 352 стр.

6.    Поликарпова Н.И., Шалыто А.А. Автоматное программирование. Второе издание. 2011.

7.    Chapter 3: Understanding the Shape Sheet (Microsoft Visio 2010 Business Process Diagramming and Validation) URL: http://msdn.microsoft.com/en-us/library/office/gg144579(v=office.14).aspx#VisDiagramValidBk_Introduction

8.    Официальный сайт разработчика,URL: http://www.microsoft.com/com/default.mspx

9.    Katoen J.-P. Concepts, Algorithms and Tools for Model Checking. Lehrstuhlfür Informatic VII, Friedrich-Alexander Universität Erlangen-Nürnberg. Lecture Notes of the Course (Mechanised Validation of Parallel Systems) (course number 10359). Semester 1998/1999.

10. Clarke E.M., Grumberg O., Peled D.A. Model Checking.http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=3730

11. Clarke E. M, Jr. Lectures on Model Checking. Computer Science Department, Carnegie Mellon University, 2005.

12. Покозий Е.А. Методы спецификации и верификации параллельных моделей с непрерывным временем. Автореферат диссертации на соискание ученой степени кандидата физико-математических наук. Институт систем информатики Сибирского отделения РАН. Новосибирск, 1999.

13. Вельдер С.Э., Шалыто А.А.Введение в верификацию автоматных программ на основе метода Model Cheking. Санкт-Петербургский государственный университет информационных технологий, механики и оптики. Кафедра компьютерных технологий. 2006.

14. Кормен Т., Лейзерсон Ч., Ривест Р., Штайн К. Алгоритмы: построение и анализ, 2-е издание. Перевод с английского языка  - М.: Издательский дом «Вильямс», 2005.