CC BY
341
УДК 004.4'2
ЕДИНАЯ ПЛАТФОРМА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРОМЫШЛЕННЫХ АВТОМАТИЗИРОВАННЫХ СИСТЕМ УПРАВЛЕНИЯ
Ф.А. Данилкин, А.В. Новиков
Рассмотрен типовой подход к проектированию современных промышленных АСУ. Отмечены недостатки существующих средств разработки программного обеспечения АСУ. Приведены требования к технологии разработки программного обеспечения, позволяющие избежать этих недостатков. Предложена концепция единой платформы разработки программного обеспечения для всех уровней АСУ на базе нового общего объектно-ориентированного языка. Показано применение объектноориентированного подхода к реализации различных аспектов программного обеспечения АСУ.
Ключевые слова: промышленная автоматизированная система управления, единая платформа, единый объектно-ориентированный язык программирования, компилятор, контроллер, модуль ввода-вывода, видеоэкран.
Задача проектирования автоматизированных систем управления подразумевает реализацию многоуровневой архитектуры [2], показанной на рис. 1.
На нижнем уровне системы производится измерение параметров, формирование управляющих воздействий, а также обеспечивается функционирование алгоритмов управления. Как правило, данный уровень системы реализуется на базе программируемых логических контроллеров (ПЛК) в сочетании с набором модулей ввода-вывода, обеспечивающих взаимодействие системы с объектом управления. Алгоритм управления зачастую описывается на одном из языков программирования стандарта МЭК 61131-3 (а в общем случае - на любом языке высокого уровня), хранится в памяти контроллера вместе с параметрами конфигурации модулей ввода-вывода и выполняется в рамках установленной в контроллере операционной системы.
При этом предполагается, что контроллер имеет какой-либо интерфейс цифровой связи, позволяющий осуществить его взаимодействие с техническими средствами верхнего уровня.
На верхнем уровне системы реализуются механизмы сбора и хранения данных, а также визуального отображения информации на экране автоматизированного рабочего места оператора. Программное обеспечение данного уровня обычно базируется на так называемых SCADA-системах -программных комплексах, позволяющих осуществить создание видеоэкранов пользователя, реализовать логику выдачи аварийных и предупредительных сообщений, обеспечить хранение истории изменения значений
отдельных параметров. Перечисленные задачи решаются с применением входящих в комплекс 8СЛВЛ-системы приложений-конструкторов, для чего в большинстве случаев не требуется написания какого-либо программного кода.
Верхний уровень Нижний уровень
Рис. 1. Типовая схема организации программного обеспечения АСУ
Одной из сложностей разработки проектов автоматизированной системы является наличие большого числа программных компонентов, каждый из которых настраивается по-своему. Например, для программирования технических средств нижнего уровня требуется задание программных кодов на языке структурного или функционального программи-
80
рования, создание таблиц переменных в специальных редакторах, задание различных настроечных параметров в диалоговых окнах среды разработки. Программное обеспечение верхнего уровня предполагает создание большого числа таблиц переменных («тегов») различного назначения, видеоэкранов в графическом редакторе, программного кода на скриптовом языке для реализации нестандартных функций, задания множества конфигурационных параметров в различных форматах с помощью разных инструментов. В результате проектировщик-программист АСУ вынужден применять большое количество языков программирования, конструкторов и утилит. Это осложняет проектирование, приводит к увеличению сроков и снижению качества разработки.
Тщательной проработки требуют вопросы обеспечения взаимодействия между верхним и нижним уровнем системы. Эта задача осложняется тем, что операционная система программируемого логического контроллера и SCADA-система разрабатываются разными производителями. И SCADA-системы, и ПЛК имеют стандартизированные, но не одинаковые протоколы взаимодействия друг с другом. Так, например, большинство SCADA-систем работают по протоколу OPC для взаимодействия с нижним уровнем, а многие ПЛК работают с протоколом MODBUS для взаимодействия с верхним уровнем. Для обеспечения их состыковки используется преобразователь протоколов. Такое преобразование сокращает функциональные возможности каналов передачи данных. В большинстве систем используется принцип взаимодействия «master-slave» с циклическим опросом, в результате чего ПЛК, являющийся подчиненным устройством, не имеет возможности инициировать передачу данных до того, как он будет опрошен, даже в случае аварийной ситуации. Это, с одной стороны, облегчает реализацию обмена данными, а с другой - существенно ограничивает возможности системы и снижает ее безопасность. Кроме того, это приводит к значительным затруднениям при реализации некоторых алгоритмов, являющихся обязательными при реализации современных систем управления. Примером такого алгоритма является блокировка - запрет на выдачу управляющего воздействия при невыполнении ряда условий с индикацией возникшей ситуации на экране автоматизированного рабочего места оператора.
Кроме того, упрощенные протоколы обмена между верхним и нижним уровнями системы не позволяют реализовать взаимный обмен конфигурацией программного и аппаратного обеспечения различных уровней. В результате, при добавлении или удалении какого-либо датчика или исполнительного механизма возникает необходимость модификации программного обеспечения на всех уровнях - возможность автоматического обновления конфигурации при традиционном подходе к проектированию АСУ полностью отсутствует.
Перечисленные выше трудности, возникающие при проектировании АСУ, демонстрируют необходимость обеспечения более тесного взаимодействия между программным обеспечением верхнего и нижнего уровней. Это позволяют выдвинуть следующий ряд требований, которым должна удовлетворять новая технология проектирования:
1. Технология проектирования АСУ должна подчиняться ментальной модели пользователя АСУ. Реализация базовых понятий проектирования АСУ - сигналов, аварийных и предупредительных сообщений, блокировок, операторских экранов, журналов действий оператора и протоколирования значений параметров - должна осуществляться минимальным объемом программного кода и конфигурационных параметров.
2. Данные, обрабатываемые на верхнем и нижнем уровне системы должны находиться в едином информационном поле. Это значит, что ячейке памяти программируемого логического контроллера, хранящей значение какого либо параметра, должна однозначно соответствовать ячейка памяти АРМ оператора. Ячейки памяти, хранящие значение одного параметра на разных уровнях должны быть синхронизированы - обновление значения параметра на одном уровне должно приводить к обновлению значения этого же параметра на другом уровне. При этом время, затрачиваемое н обновление данных должно быть минимальным и ограничено лишь пропускной способностью канала ввода-вывода.
3. Синхронизация данных на разных уровнях не должна требовать вмешательства прикладного программиста АСУ. Обновление данных должно быть полностью автоматическим и не должно требовать написания программного кода или составления каких-либо таблиц связей между переменными.
4. Конфигурация системы, набор параметров управления, а также действия при их изменении должны рассматриваться как неотъемлемая часть алгоритма управления. Технология проектирования должна позволять описать все допустимые ситуации, возникающие при изменении конфигурации, а также действия, которые необходимо выполнить для адаптации системы к новой конфигурации на всех уровнях.
5. Программирование всех подзадач на всех уровнях системы должно выполняться на одном языке.
Предлагаемый подход основан на едином программном обеспечении, что подразумевает один текст программы для всех устройств, включенных в состав системы. При этом программный код будет включать в себя как алгоритмы управления объектом, так и структуру системы, описание переменных, видеоэкранов и все настроечные параметры. Для обеспечения данных возможностей предлагается специализированный язык программирования. На рисунке 2 показано, каким образом идет процесс создания программного обеспечения на базе этого языка.
Рис. 2. Новая технология разработки программного обеспечения АСУ на основе единой платформы
Базовым элементом единого языка является класс сигнала. Каждый сигнал представляет собой экземпляр определенного класса. Обязательным элементом любого класса сигнала является поле-контейнер, хранящее информацию о значении сигнала в текущий момент времени. Для описания выхода сигнала во внешнюю среду в классе описываются два типа интерфейсов - полевые и визуальные. Схематичное изображение информации, составляющей класс сигнала, приведено на рис. 3.
Рис. 3. Схематичное представление класса сигнала
К полевому типу относятся интерфейсы, соответствующие каналам модулей ввода вывода. При описании интерфейса данного типа указываются физические характеристики данного сигнала. Для входных сигналов указывается и измеряемая величина, единица и диапазон измерения. Для выходных - регулируемая величина, единица и диапазон регулирования. Например, измеряемой величиной может являться температура с пределами измерения от -10 до 100 градусов Цельсия. Регулируемой величиной может являться частота вращения электропривода, диапазон регулирования - от 0 до 1000 об/мин. Датчики измеряемых величин и исполнительные устройства, осуществляющие выдачу регулируемых воздействий, подключается к модулям ввода-вывода посредством унифицированных сигналов напряжения и тока - «4 .. 20 мА», «0 .. 10 В», «дискретный сухой контакт» и т. п. Тип такого интерфейса также указывается при описании класса сигнала.
К визуальному типу интерфейсов относятся описания отображения сигнала на видеоэкране АРМ оператора. Отображение может быть текстовым или графическим. Для текстового представления задается шрифт и начертание, для графического - указывается набор визуальных примитивов, формирующих наглядное изображение состояния сигнала (индикаторы, имитации измерительных приборов, указатели перемещения и пр.).
Для каждого сигнала выбирается некий алгоритм предобработки и указываются параметры этого алгоритма. Например, в качестве алгоритма предобработки может оказаться сглаживание сигнала, а в качестве параметра алгоритма - постоянная времени сглаживания.
Процесс управления объектом может рассматриваться как некая совокупность контуров управления. Контур реализуется в виде отдельных
классов, которые могут представлять собой иерархическую структуру: контуры управления отдельным механизмом, линией и объектом в целом вложены друг в друга с применением таких понятий объектноориентированной парадигмы программирования, как наследование и инкапсуляция.
К ключевым понятиям, характеризующим сигнал, относятся события. События характеризуют поведение системы во времени. Можно считать, что они являются основой для реализации алгоритмов управления. События бывают простыми и сложными: к первому типу относятся события, возникающие при изменении значения какого-либо одного сигнала, ко второму - события, возникающие при одновременном изменении группы сигналов. Условия, инициирующие запуск процедур-обработчиков событий, могут быть различными - это может быть достижения сигналом какого-либо порога, вхождение в заданный коридор значений или просто любое изменение состояния сигнала.
Задание обработчиков событий для всех сигналов, изменение которых влияет на процесс управления объектом. При описании событий используются стандартные алгоритмические конструкции, операторы присваивания, арифметические и логические выражения, а также библиотеки математических (синус, логарифм) и системных (временная задержка) функций. Событийная модель реализации алгоритма управления позволяет отказаться от цикличной обработки данных, заключающийся в многократном повторении одной и той же процедуры, снизить объем потребляемых процессорных ресурсов и время реакции системы на изменение внешних сигналов.
С событиями связываются такие понятия проектирования АСУ как блокировки - запрет определенных действий при заданном состоянии сигнала, «алармы» - аварийные сигналы и сообщения, активизирующиеся при определенных условиях, «тренды» - массивы данных, хранящих историю изменения соответствующего сигнала. Для перечисленных элементов программного обеспечения АСУ характерно тесное взаимодействие нижнего и верхнего уровней архитектуры АСУ. Например, блокировка, осуществляющая останов механизмов объекта управления при превышении давления в критически важной линии, алгоритмически реализуется в ПЛК. При этом необходима обратная связь от ПЛК к АРМ оператора, которая позволила бы осуществить отображение на экране АРМ сообщение о том, что блокировка сработала. Существующие на данный момент технологии программирования АСУ не позволяют эффективно справиться с этой задачей, однако технология единого языка в совокупности с событийной моделью делают ее тривиальной.
Все технические средства, включенные в состав автоматизированной системы (модули, контроллеры, серверы, сети), так же, как и сигналы, представляются объектами определенных классов. При этом наследование
реализует классификацию и модификацию технических средств, а инкапсуляция используется для определения иерархической структуры взаимного подключения технических средств. На рис. 4 показаны примеры кода, реализующие различные варианты описания структуры системы. Первый пример показывает, как описать структуру, в которой имеется одно ведущее устройство (ПЛК) и несколько ведомых (модули ввода-вывода). Здесь объекты, описывающие ведомые устройства, инкапсулируются в класс, описывающий контроллер. Второй пример отражает архитектуру, в которой любое устройство может стать ведущим (что актуально для интерфейсов CAN или Ethernet). В этом случае необходимо в коде программы описать класс сети, в который инкапсулированы все устройства, включенные данную сеть.
Вариант описания структуры на базе архитектуры П/1К «master-slave» (ПЛК - ведущий, модули - ведомые)
і і
Модуль аналогового ввода, 4..20 мА
Модуль аналогового вывода, 0..20 мА
1
1 Модули дискретного ввода (2 шт)
Модуль дискретного вывода
\ г
controller PLC1:PLCModel {
Analoglnput4_20 ai; AnalogOutputO_20 ao; Discretelnput di[2]; DiscreteOutput do;
}
Вариант описания структуры на базе архитектуры с равноправными элементами
network Netl
{
AnalogInput4_20 ai; AnalogOutputO_20 ao; Discretelnput di[2]; DiscreteOutput do; PLCModel pic;
}
Рис. 4. Примеры описания структуры комплекса технических
средств
Так же объектно-ориентированный подход применяется и при реализации видеокадров автоматизированной системы. Каждому видеокадру соответствует класс, в который инкапсулируются ссылки на статические графические элементы и визуальные интерфейсы сигналов.
Особую роль в синтаксисе предлагаемого языка играют массивы. Как известно, массив предназначен для хранения однородных данных, на которые отображаются различные однородные объекты: сигналы, контуры управления, механизмы. Например, если объект управления включает в себя несколько одинаковых агрегатов, управляемых по идентичным алгоритмам, то классы, реализующие контур управления агрегатом, объединя-
ются в единый массив. Это означает, что добавление дополнительного однотипного агрегата не приводит к необходимости написания отдельного программного кода - достаточно просто увеличить количество элементов в массиве контуров управления, что может быть выполнено в процессе работы системы, без соответствующей перекомпиляции программного кода.
Массивы в предлагаемом языке эффективно применяются и при разработке визуального интерфейса. В случаях, когда необходимо отобразить группу значений однородных технологических параметров, в класс видеокадра инкапсулируется ссылка на массив сигналов, соответствующий данной группе. В этом случае сигналы отобразятся в окне оператора в виде таблицы. Это, опять же, вносит преимущества при добавлении в систему нового однотипного сигнала - в такой ситуации не потребуется перекомпиляции проекта с его перепрограммированием в устройства.
Кроме того, массивы используются для создания списков критически важных сигналов и блокировок. Например, в единый список группируются датчики давления, останавливающие все механизмы объекта управления при превышении давлением заданного порога. Блокировка на отключение определяется для всех элементов данного списка. Это означает, что при добавлении в систему нового датчика и отнесении его к классу критически важных сигналов блокировка для этого датчика пропишется автоматически.
Еще одним важным положительным следствием применения единой платформы программирования АСУ является то, что у компилятора появляется возможность оптимизации процесса выполнения алгоритма управления [1]. Цели такой оптимизации могут быть разными: равномерное распределение вычислительной нагрузки между контроллерами в случае сложных алгоритмов управления или, что гораздо более актуально для современных АСУ, снижение объемов информации, передаваемой по шинам обмена данными.
В процессе трансляции компилятор анализирует структуру алгоритма и выделяет в системе отдельные контуры управления. При формировании исполняемого кода для контроллеров компилятор учитывает эти контуры, распределяя отдельные операторы таким образом, чтобы в рамках одного контура управления было задействовано минимальное количество контроллеров. Кроме того, компилятор выдает рекомендации по подключению датчиков сигналов к модулям ввода-вывода. Эти рекомендации помогают подключить датчики именно к тем модулям, которые находятся на одной шине с контроллером, обрабатывающим данные сигналы.
Такое компактное распределение алгоритма управления между кот-роллерами уменьшает объем данных, передаваемых по межконтроллерным сетям. Правильное распределение задач и сигналов между контроллерами помогает избавиться от лишней передачи данных на более высокие уровни архитектуры АСУ. Это позволяет снизить скорость передачи данных, до-
бавить избыточные коды для обеспечения контроля ошибок, что, в конечном итоге, существенно повышает надежность системы.
Все вышеизложенное позволяет сформулировать следующие преимущества единой платформы разработки программного обеспечения промышленных АСУ.
1. Легкость программирования. Нет необходимости изучать большое языков программирования, утилит и средств разработки - все задачи решаются в одном тексте программы на едином языке.
2. Безопасность. Сообщения об авариях и блокировках отображаются оператору без задержек.
3. Эффективность. Увеличение числа однотипных сигналов в системе не требует остановки и перекомпиляции программного обеспечения.
4. Надежность. За счет оптимизации вычислительного процесса снижается нагрузка на сеть передачи данных, что уменьшает количество ошибок и сбоев.
Список литературы
1. Данилкин Ф.А., Новиков А.В. Распараллеливание алгоритмов для мультипроцессорных систем / М-во образования и науки РФ, Гос. образовательное учреждение высш. проф. образования «Тульский гос. ун-т». Тула, 2010/ 158 с.
2. Сергеев Н.Е., Добровольский С.В. АСУ ТП большой информационной мощности от проектирования до промышленной эксплуатации/Известия Южного федерального университета. Технические науки. 2001. Т. 22. № 4. С. 246-248.
Данилкин Федор Алексеевич, д-р техн. наук, проф., fdanilkin@yandex.ru, Россия, Тула, Тульский государственный университет,
Новиков Алексей Владимирович, к-т техн. наук, доц., novikov82@gmail.com, Россия, Тула, Тульский государственный университет
INTEGRATED PLATFORM FOR INDUSTRIAL CONTROL SYSTEMS DEVELOPMENT
F.A. Danilkin, A. V. Novikov
Considered a model approach to the design of modern industrial control systems. Marked deficiencies of the existing software development process control. The requirements for software development technology to avoid these disadvantages. Proposed the concept of a unified software development platform for all levels of automated control system based on a new common object-oriented language. Shows the use of object-oriented approach to the implementation of various aspects of the software control systems.
Key words: industrial automation control system, a unified platform, unified object-oriented programming language, a compiler, controller, input-output video screen.
Danilkin Fiodor Alekseevich, doctor of technical science, professor, fdanilkin@yandex.ru, Russia, Tula, Tula State University,
Novikov Aleksey Vladimirovich, candidate of technical science, docent, novikov82@gmail.com , Russia, Tula, Tula State University,
УДК 004.415.52
СИСТЕМА АНАЛИЗА ПРОИЗВОДИТЕЛЬНОСТИ ПРОГРАММОГО КОДА
Е. И. Дараган
Рассмотрены особенности анализа производительности программного кода, программ. Описан и представлена реализация метода оценки стоимости выполнения операций программного кода для абстрактной вычислительной системе.
Ключевые слова: программа, код, стоимость, операция.
Иерархическая структура, присущая всем алгоритмам и всегда воплощенная в программах, является хорошим источником для рационального использования ресурсов. Все современные языки программирования обязательно не только отражают, но и подчеркивают иерархическую структуру алгоритмов. Выделение, подчеркивание иерархий, реализация принципа структурного и объектно- ориентированного программирования способствует пониманию правильного выполнения алгоритма, упрощению разработки программы.
Разбиение на частные, элементарные подпрограммы обеспечивается представлением алгоритма в виде одного или нескольких взаимодействующих процессов. Процессы - логически завершенные, преимущественно значительные по объему вычисления, на которые необходимо разбить выполняемый алгоритм. При формировании процессов основополагающими являются требования оптимальной сегментации программ для распределения вычислений между средствами вычислительной среды и распределения в ней ресурсов при параллельной выполнении нескольких процессов.
Одновременно между процессами существуют два вида зависимости: процессы могут быть явно зависимы (влияют на выполнение друг друга, могут порождать или прекращать другие процессы) и зависимость может быть реализована на уровне операционной системы. Для первого случая характерно, что процессы,объединённые в рамках одной задачи, используют закрепленную для этой задачи общую память. Данная характе-
