Мэк 61131 3 что это

Объектно-ориентированные расширения МЭК 61131-3

Сегодня мы представляем вам статью основателя и директора компании Smart Software Solutions GmbH Дитера Хесса. Ему принадлежит ряд идей, которые уже вошли в стандарты либо активно обсуждаются в рабочих группах МЭК. В очередной раз он предоставляет CoDeSys в качестве рабочей платформы для практического исследования передовых новшеств.

Цели

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

Требования

В результате, компанией 3S-Smart Software Solutions было принято решение расширить нормы стандарта МЭК 61131-3, введя поддержку ООП в новое поколение системы программирования CoDeSys. Расширения стандарта должны подчиняться следующим требованиям:

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

Расширения

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

Следующий пример показывает определение и вызов простого метода:

Естественно, вызов метода можно выполнить и в графических языках:

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

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

Для упрощения, правила видимости заданы жестко:

Тип элемента	Внешний доступ на чтение	Внешний доступ на запись	Внешний вызов
VAR	—	—	—
VAR_INPUT	—	+	—
VAR_OUTPUT	+	—	—
METHOD	—	—	+

Уже существующий класс может быть дополнен с помощью ключевого слова EXTENTS.

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

Следующий пример иллюстрирует данную технику:

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

Как можно видеть, все методы интерфейса Drive наполнены специальными реализациями, построенными на CAN сообщениях. Сверх того здесь присутствуют некоторые специфические переменные и методы. В данном случае это метод, устанавливающий CAN Id. Далее мы могли бы описать еще один вид привода, например аналоговый (AnalogDrive). В нем можно реализовывать методы совершенно иначе, чем для цифрового привода (CANDrive).

Теперь можно написать функциональный блок, получающий интерфейс в качестве параметра:

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

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

Заключение
Может возникнуть вопрос: насколько целесообразны или даже допустимы описанные расширения действующего стандарта МЭК 61131-3?

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

Вы могли заметить, что описанные расширения языков программирования МЭК 61131-3 уже есть в других современных языках, таких как Java или C#. Однако инструментов созданных на их основе специально для решения задач автоматизации нет. Кроме того, переход на эти языки не соответствует практическим требованиям прикладных программистов.

В заключение, мы сталкиваемся с вопросом: действительно ли программистам ПЛК нужна технология ООП? Наши исследования тысяч приложений созданных в CoDeSys показали, что уже сейчас многие программисты пытаются реализовать конструкции ООП в своих проектах. Имея дело с абстрактными приводами, сетями или агрегатами машин, они создают функциональные блоки с управляемым специальными флагами поведением. Это, указывает на растущую необходимость прихода объектного подхода в мир автоматизации. Достаточно многие пользователи 3S пытаются самостоятельно компенсировать отсутствие ООП, прилагая значительные усилия, чтобы иметь возможность автоматически генерировать код для однотипных приложений. Некоторые же открыто взывают нас к добавлению объектно-ориентированной функциональности.

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

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

Основные термины и определения¶

IEC 61131-3 — раздел международного стандарта МЭК 61131 (также существует соответствующий европейский стандарт EN 61131), описывающий языки программирования для программируемых логических контроллеров.

Среда разработки для языков стандарта IEC 61131-3 — система программных средств, используемая инженерами по автоматизации, для разработки прикладного программного обеспечения на высокоуровневых языках стандарта IEC 61131-3 под различные целевые платформы, которая включает в себя:

Текстовые и графические редакторы языков стандарта IEC 61131-3;

Транслятор диаграмм графических языков в текстовый язык;

Транслятор текстового языка в язык C;

Механизмы плагинов для взаимодействия с модулями УСО;

Механизмы добавления компиляторов под целевую платформу;

Механизмы соединений с целевыми устройствами;

Модули УСО — модули ввода/вывода, обеспечивающие подключение датчиков и исполнительных механизмов.

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

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

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

Переменная — область памяти, в которой находятся данные, с которыми оперирует программный модуль.

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

Программный модуль — элемент, представляющий собой функцию, функциональный блок или программу. Каждый программный модуль состоит из раздела объявлений и кода. Для написания всего кода программного используется только один из языков программирования стандарта IEC 61131-3.

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

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

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

Задача — элемент представляющий время и приоритет выполнения программного модуля типа «Программа» в рамках экземпляра проекта.

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

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

© Copyright 2018, JSC «INEUM named after I.S.Bruk» Revision 27f4abdd .

Языки стандарта IEC-61131 для вычислительных комплексов на базе отечественных микропроцессоров с архитектурой SPARC

Управление технологическими процессами, как правило, осуществляется с помощью программируемых логических контроллеров (ПЛК), или Programmable Logic Controller (PLC). ПЛК – комплекс электронных и программных компонент и средств (включая модули ввода-вывода), предназначенный для выполнения логических функций (не включает в себя сенсоры, исполнительные элементы и средства взаимодействия с оператором). ПЛК пришли на смену релейно-контактным схемам управления с жесткой логикой. Программируемые контроллеры упростили схему управления технологическими процессами и обеспечили высокий уровень надежности и долговечности.

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

Современные вычислительные комплексы на базе отечественных микропроцессоров с архитектурой SPARC (МЦСТ R-500S) являются достаточно миниатюрными и имеют высокую производительность, что позволяет создавать на их базе ПЛК, отвечающие всем современным требованиям по производительности, надежности и защищенности, предъявляемым к этому классу устройств.

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

Стандарт IEC 61131-3 устанавливает пять языков программирования ПЛК (три графических и два текстовых) со следующими названиями:

• структурированный текст (ST – Structured Text);
• последовательные функциональные схемы (SFC – Sequential Function Chart);
• диаграммы функциональных блоков (FBD – Function Block Diagram);
• релейно-контактные схемы, или релейные диаграммы (LD – Ladder Diagram);
• список инструкций (IL – Instruction List).

Языки IEC 61131-3 базируются на определённых принципах. Вся программа разбивается на множество функциональных элементов – Program Organization Units (POU), каждый из которых может состоять из функций, функциональных блоков и программ. Любой элемент IEC-программы может быть сконструирован иерархически из более простых элементов. Стандарт требует строгой типизации данных. Указание типов данных позволяет легко обнаруживать большинство ошибок в программе до ее исполнения. Имеются средства для исполнения разных фрагментов программы в разное время, с разной скоростью, а также параллельно. Для выполнения операций в определенной последовательности, которая задается моментами времени или событиями, используется специальный язык последовательных функциональных схем (SFC). Стандарт поддерживает структуры для описания разнородных данных. Например, температуру подшипников насоса, давление и состояние «включено-выключено» можно описать с помощью единой структуры «Pump» и передавать ее внутри программы как единый элемент данных. Стандарт обеспечивает совместное использование всех пяти языков, поэтому для каждого фрагмента задачи может быть выбран любой, наиболее удобный, язык. Программа, написанная для одного контроллера, может быть перенесена на любой контроллер, совместимый со стандартом IEC 61131-3.

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

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

• адаптация и запуск среды исполнения программ на процессорных модулях ПЛК;
• разработка функциональных блоков для интерфейсов CAN, Modbus и т.д., обеспечивающих связь с удаленными модулями ввода-вывода, другими ПЛК и системами верхнего уровня;
• разработка функциональных блоков для обмена данными с драйверами создаваемых унифицированных электронных модулей ввода/вывода сигналов.

На данный момент существует ряд широко известных инструментов разработки прикладных программ для ПЛК на языках стандарта IEC 61131-3, например ISaGRAF, CoDeSyS и т.д. Но в процессе адаптации таких сред разработки для ПЛК с аппаратной частью на новой, нестандартной, архитектуре может возникнуть ряд проблем. Например, отсутствие необходимых компиляторов под конкретную архитектуру или невозможность внесения изменений, требующих доступа к исходному коду определённого компонента среды. Кроме того, данные инструменты являются коммерческим продуктом и для их применения необходимо пройти процесс лицензирования, требующий больших финансовых вложений. Существует и ряд других инструментов, одним из которых является свободно-распространяемая среда с открытым исходным кодом Beremiz (www.beremiz.org). Возможность иметь доступ ко всем её компонентам и вносить любые изменения даёт преимущества для адаптации данного инструмента под конкретную аппаратную архитектуру, поэтому для написания прикладных программ на языках IEC 61131-3 для вычислительных комплексов на базе отечественных микропроцессоров с архитектурой SPARC предлагается адаптировать среду разработки Beremiz.

Содержание:

Введение
Обзор Beremiz
Разработка плагинов
Обзор Cygwin
Обзор Crosstool

Код для размещения ссылки на данный материал в блоге: Как будет выглядеть ссылка:

Языки стандарта IEC-61131 для вычислительных комплексов на базе отечественных микропроцессоров с архитектурой SPARC

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

• Автор: И.А. Баранов, к.т.н. А.В. Глухов
• Дата: 27 июня 2012 года
• Тэги:Публикации, ТЕГ БЛОКА «SPARС», СМ 1820

Программирование на языках ГОСТ МЭК 6-1131/3

Программирование в SCADA TRACE MODE 7 производится на языках стандарта ГОСТ МЭК 61131/3. Число аргументов и переменных в программах TRACE MODE 7 не ограничивается. Программы оформляются в виде шаблонов, обрабатываемых серверами TRACE MODE 7: МРВ и/или Глобальным регистратором, их резервированными аналогами — Double Force МРВ и Глобальным регистратором дублированным, а также Micro TRACE MODE (встраиваемые системы).

В TRACE MODE используются языки Техно ST и Техно FBD. Данные языки являются модификациями языков ST (Structured Text) и FBD (Function Block Diagram) стандарта ГОСТ МЭК 61131/3. Техно ST — процедурный язык, а Техно FBD — визуальный.

Языки TRACE MODE совместимы. Функции языка Техно ST могут быть вызваны в Техно FBD как блоки, а FBD-блоки в ST как функции.

Редактор программ TRACE MODE 7 содержит библиотеку готовых FBD-блоков для АСУ ТП.

Перед использованием программы компилируются. TRACE MODE 7 ведет контроль синтаксиса программ, ошибки, обнаруженные при компиляции, отображаются в протоколе. Компилятор позволяет создавать нативный для процессоров x64 код программ, что обеспечивает значительное ускорение вычислений.

Типы данных, определенные для языков, включают булевы переменные, целые размерностью от 1 до 4 байт, вещественные числа (с плавающей запятой) 4 и 8 байт (LONG), а также строки.

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

Возможны векторные вычисления.

В ST-программе допускается использование функций из динамических библиотек (DLL в Windows и SO в Linux). TRACE MODE 7 располагает развитыми средствами отладки программ (в том числе и удаленной). Отладка включает в себя несколько режимов непрерывного и пошагового выполнения программы с возможностью установки точек останова. При удаленной отладке Инструментальна система запрашивает значения аргументов и глобальных переменных программы у узла, выполняемого под управлением МРВ на удаленном компьютере или EmbeddedRTM (Micro TRACE MODE) в контроллерах. Это позволяет отлаживать программу на реальных значениях обрабатываемых сигналов.