Соглашения проектирования в CoDeSys Текст научной статьи по специальности «Компьютерные и информационные науки»

ТЕХНИЧЕСКИЕ НАУКИ

УДК 004.02

О.В. Агеев

канд. техн. наук, доцент, кафедра автоматизации технологических процессов, ФГБОУ ВПО «Уфимский государственный авиационный технический университет»

СОГЛАШЕНИЯ ПРОЕКТИРОВАНИЯ В CODESYS

Аннотация. В статье представлен ряд соглашений, которым предлагается следовать при разработке проектов для программируемых логических контроллеров (ПЛК) в среде CoDeSys. Цель разработки соглашений - повышение ясности структуры ПЛК-проектов. Основным инструментом для достижения цели является объектно-ориентированный подход c использованием языка CFC.

Ключевые слова: программируемые логические контроллеры, CoDeSys, соглашения, язык CFC.

O.V. Ageev, Ufa State Aviation Technical University

THE DESIGN AGREEMENTS IN CODESYS

Abstract. The article presents a number of agreements, which are offered to follow when developing projects for programmable logic controllers (PLC) in the CoDeSys environment. The purpose of the agreements is increasing clarity patterns PLC projects. The main instrument to achieve the goal is the object-oriented approach with the use of CFC language.

Keywords: programmable logic controllers, CoDeSys, agreements, CFC language.

В системах автоматизации технологических процессов часто применяют программируемые логические контроллеры (ПЛК). Разработано семейство стандартов МЭК 61131 по аппаратному и программному устройству ПЛК. Третья часть стандарта МЭК 61131-3 описывает языки программирования и компоненты организации прикладного программного обеспечения (ПО) ПЛК [2]. Большинство производителей ПЛК, которые следуют указанному стандарту, не производят собственные среды разработки и исполнения ПЛК-программ, а адаптируют универсальные инструменты. Лидеры рынка в России среди таких инструментов - CoDeSys [2] и IsaGRAF.

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

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

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

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

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

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

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

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

3. Корневой компонент должен называться Main и разрабатываться на языке CFC. Допускается разбивать одну диаграмму Main на несколько Main(N): Mainl, Main2 и т.д. Вызов всех диаграмм Main(N) на выполнение производить из списка вызова компонентов одной циклической задачи в порядке, указанном номером N в имени Main(N). Кроме переменных ввода-вывода и констант к компоненту на диаграмме Main(N), можно подключить только компонент, также представленный на диаграмме Main(N). Порядок расположения входных переменных и выходных переменных (интерфейса) компонента в их списках должен выбираться, исходя из наглядности представления интерфейса компонента на CFC-диаграммах. Нужно учитывать, что расположение линий на CFC-диаграмме устанавливается редактором автоматически. Разработка компонентов на языке CFC приветствуется, если это помогает лучше понять уровни проекта, расположенные ниже Main(N).

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

4. Имена глобальных переменных ввода-вывода никак не должны быть связаны с предметной областью проекта и обозначать именно типы и номера каналов ввода/вывода: DI(N)/DQ(N) - дискретные, AI(N)/AQ(N) - аналоговые и т.п., где N - это номер канала. Все подключения к переменным ввода-вывода должны быть показаны только на диаграмме Main или диаграммах Main(N). Другими словами, прямые выражения с участием переменных ввода-вывода (DQ5: = TRUE) недопустимы.

Если следовать этому соглашению, то реализация прикладной задачи будет абстрагирована от конфигурации ввода-вывода, и проекты будут переносимыми между ПЛК c CoDeSys разных производителей. Кроме того, это позволит наглядно изменять подключение переменных программы к каналам ввода-вывода на диаграммах Main(N) при изменении конфигурации ввода-вывода или схемы подключения к объекту управления.

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

6. Если используется визуализация, то ее интерфейс должен быть обязательно пред-

16

№ 5 (33) - 2014

ставлен на диаграмме Маш^) в виде компонента с «пустой» реализацией. Все объекты визуализации (кнопки, метки и т.п.) могут быть связаны только с переменными своего интерфейса визуализации. Связь с переменными других компонентов не допускается.

Если следовать этому соглашению, то все связи подсистемы визуализации и компонентов будут видны на диаграмме, любые изменения компонентов, структуры программы не будут неожиданными для подсистемы визуализации, и наоборот. Пример одной из диаграмм списка Маш^) приведен на рисунке 1.

Улица

flow

Вода

Давление

mbS RO n

GSM CW 1

OR

mbM. R7

mbM R13

mbM R19

mbM.Rl

mbS RH

mbS R12

mbS R13

mbS R14

mbS R15

mbS R16

mbS R17

mbS R18

DI 5

t#5s

Heating

TICode

T2Code

T3Code

PressCode

T1_HIGH

Tl_LOW

T2_HIGH

T2_LOW

T3_HIGH

T3_LOW

Press_HIGH

Press_LOW

Pump

BoilerCmd BoilerOnTime

T1 T2 T3 Press TlAlarm Г2А1агт ГЗА1агт PressAlarm BoilerRelay

mbS R1

mbS R2

mbS R3

mbS R4

GSM.SW.5

GSM.SW. 6

GSM.SW.7

GSM.SW. 8

GSM.ResetCW.1

DQ2 |

Рисунок 1 - Пример диаграммы Main

Компонент GSM отвечает за ввод-вывод по каналу GSM (SMS и CSD), рассматривается как элемент конфигурации ввода-вывода и только поэтому является глобальным экземпляром библиотечного функционального блока FB_GSM. GSM вызывается на другой диаграмме Main(N). Переменные mbM и mbS являются экземплярами оригинальных для этого проекта структур ST_MBM и ST_MBS. В ПЛК фирмы ОВЕН mbM и mbS размещаются напрямую в образе конфигурации (%I*, %Q*). Образ должен быть предварительно создан в конфигураторе ПЛК и соответствовать типам ST_MBM и ST_MBS. В ПЛК фирмы Beckhoff, где регистры Modbus не входят в конфигурацию, mbM и mbS все равно рассматриваются как элементы конфигурации ввода-вывода, размещаются в списке глобальных переменных и используются как параметры компонентов библиотеки, реализующей Modbus.

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

Из приведенного примера видно, что решение даже простых задач должно вестись не «с наскока». Требуется предварительно проектирование как структур ST_MBM и ST_MBS, так и всего остального проекта.

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

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

1. Арлоу Д. UML 2 и Унифицированный процесс: практ. объект.-ориентиров. анализ и проектирование: пер. с англ. / Д. Арлоу, И. Нейштадт. 2-е изд. СПб.: Символ-Плюс, 2007. 624 с.

2. Петров И.В. Программируемые контроллеры. Стандартные языки и приемы прикладного проектирования / И.В. Петров; под ред. В.П. Дьяконова. М.: СОЛОН-Пресс, 2004. 256 с.