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

Анализ проблематики построения объектно-ориентированного канала связи с ПЛК

Описание протокола Modbus

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

Первоначально контроллеры MODICON использовали последовательный интерфейс RS-232. Позднее стал применяться интерфейс RS-485, так как он позволяет использовать более длинные линии связи и подключать к одной линии несколько устройств.

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

Основные понятия протокола Modbus

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

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

Основа структуры запросов и ответов протокола Modbus - элементарный пакет протокола, так называемый PDU (Protocol Data Unit). Структура PDU протокола Modbus не зависит от типа линии связи и включает в себя код функции и поле данных. Код функции - это однобайтовое поле. Оно может принимать значения в диапазоне 1…127. Значения 128…255 зарезервированы для кодов ошибок. Поле данных может быть переменной длины. Размер пакета PDU ограничен 253 байтами.

Для передачи пакета по физическим линиям связи PDU помещается в другой пакет, содержащий дополнительные поля. Этот пакет носит название ADU (Application Data Unit). Формат ADU зависит от типа линии связи.(Protocol Data Unit) - общая для всех физических уровней часть пакета MODBUS. Включает в себя код функции и данные пакета.(Application Data Unit) - полный пакет MODBUS. Включает в себя специфичную для физического уровня часть пакета и PDU.специфицирует 4 типа данных:

·   Discrete Inputs - однобитовый тип, доступен только на чтение.

·   Coils - однобитовый тип, доступен на чтение и на запись.

·   Input Registers - 16-битовый знаковый или беззнаковый тип, доступен только на чтение.

·   Holding Registers - 16-битовый знаковый или беззнаковый тип, доступен на чтение и на запись.

Стандарты MODBUS состоят из 3 частей:

Документ Modbus Application Protocol содержит спецификацию прикладного уровня сетевой модели OSI:

Элементарный пакет протокола, так называемый PDU (Protocol Data Unit), он един для всех физических уровней. PDU упаковывается в индивидуальный для каждого транспорта application data unit (ADU).

Коды функций и состав PDU для каждого кода.

Документ Modbus over serial line содержит спецификацию канального и физического уровней сетевой модели OSI для физических уровней RS485 и RS232. В принципе может использоваться любой физический уровень основанный на асинхронном приемопередатчике.

Документ MODBUS Messaging on TCP/IP Implementation Guide содержит спецификацию ADU для транспорта через TCP/IP стек.

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

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

Обычно в сети есть только один клиент, так называемое, «главное» (англ. master) устройство, и несколько серверов - «подчиненных» (slaves) устройств. Главное устройство инициирует транзакции (передаёт запросы). Главный может адресоваться индивидуально к подчиненному или инициировать передачу широковещательного сообщения для всех подчиненных устройств. Подчиненное устройство отвечает на запрос, адресованный именно ему. При получении широковещательного запроса ответ не формируется.

Спецификация Modbus описывает структуру запросов и ответов. Их основа - элементарный пакет протокола, так называемый PDU (Protocol Data Unit). Структура PDU не зависит от типа линии связи и включает в себя код функции и поле данных. Код функции кодируется однобайтовым полем и может принимать значения в диапазоне 1…127. Диапазон значений 128…255 зарезервирован для кодов ошибок. Поле данных может быть переменной длины. Размер пакета PDU ограничен 253 байтами.

Таблица 1. Modbus PDU

код функции	данные
1 байт	N < 253 (байт)

 

Для передачи пакета по физическим линиям связи PDU помещается в другой пакет, содержащий дополнительные поля. Этот пакет носит название ADU (Application Data Unit). Формат ADU зависит от типа линии связи. Существуют три варианта ADU, два для передачи данных через асинхронный интерфейс и один - через TCP/IP сети:ASCII - для обмена используются только ASCII символы. Для проверки целостности используется однобайтовая контрольная сумма. Начало и конец сообщения помечаются специальными символами (начало сообщения»: «, конец сообщения CR/LF).RTU - компактный двоичный вариант. Сообщения разделяются по паузе в линии, контроль целостности с помощью CRC.TCP - для передачи данных через TCP/IP соединение.

 

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

 

Таблица 2. Структура ADU

адрес ведомого устройства

код функции

данные

блок обнаружения ошибок

 

где

·   адрес ведомого устройства - адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248…255 - зарезервированы;

·   код функции - это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство;

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

·   блок обнаружения ошибок - контрольная сумма для проверки отсутствия ошибок в кадре.

Максимальный размер ADU для последовательных сетей RS232/RS485 - 256 байт, для сетей TCP - 260 байт.

Для Modbus TCP ADU выглядит следующим образом:

 

Таблица 3. Modbus TCP ADU

ID транзакции

ID протокола

длина пакета

адрес ведомого устройства

код функции

данные

 

где

·   ID транзакции - два байта, обычно нули

·   ID протокола - два байта, нули

·   длина пакета - два байта, старший затем младший, длина следующей за этим полем части пакета

·   адрес ведомого устройства - адрес подчинённого устройства, к которому адресован запрос. Обычно игнорируется, если соединение установлено с конкретным устройством. Может использоваться, если соединение установлено с мостом, который выводит нас, например, в сеть RS485.

Поле контроля целостности в Modbus TCP отсутствует, т. к. целостность данных обеспечивает TCP/IP стек.

 

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

 

CoDeSys это универсальный комплекс МЭК программирования высшего класса, немецкой компании Smart Software Solutions GmbH (3S). Комплекс CoDeSys включает специализированные редакторы МЭК языков, конфигуратор контроллера, обеспечивает поддержку промышленных сетей и многое другое. Основная его отличительная особенность это встроенный компилятор кода. МЭК программы непосредственно преобразуются в машинные коды микропроцессора. В итоге достигается очень высокое быстродействие прикладных проектов. Помимо этого, комплекс обеспечивает многозадачность в прикладных проектах (циклические и вызываемые по событиям задачи). Среда программирования имеет встроенный графический интерактивный отладчик и эмулятор, многоканальный графический анализатор, встроенную систему визуализации объекта и программы управления (на ПК, в контроллере и Web), развитый набор библиотек.обладает рядом особенностей, выделяющих его среди остальных систем:

Быстрое внедрение. 3S-Smart Software Solutions может выполнить тестовую адаптацию системы исполнения (включая базовые он-лайн функции) для любой стандартной процессорной платформы не более, чем за 2 дня. CoDeSys имеет интегрированные компиляторы для большинства широко распространенных аппаратных платформ. Простота адаптации не отражается на быстродействии прикладных проектов. Компилятор и система исполнения тщательно отработаны. Все это позволяет подготовить ваши контроллеры к выходу на рынок в минимальные сроки.

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

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

·   Эмулятор ПЛК;

·   Редакторы для программирования на языках:

·   Список Инструкций (IL);

·   Диаграммы Функциональных блоков (FBD);

·   Релейно-контактные схемы (LD);

·   Структурированный текст (ST);

·   Последовательные функциональные схемы (SFC);

·   Непрерывные функциональные диаграммы (CFC);

·   DDE и OPC серверы;

·   Элементы визуализации;

·   Графический иерархический ПЛК конфигуратор;

·   Менеджер библиотек;

Он-лайн функции:

·   мониторинг значений переменных

·   запись и фиксация значений переменных в ПЛК

·   отладка проекта (точки останова, выполнение по шагам и по циклам, контроль стека вызовов)

·   горячая коррекция кода, без остановки ПЛК

·   контроль процесса выполнения

·   графическая трассировка

Языки программирования:

·   Список Инструкций (IL). Простой машинно-независимый ассемблер.

·   Структурированный текст (ST). Высокоуровневый «Паскаль-подобный» язык.

·   Функциональные блоковые диаграммы (FBD). Графический язык описания логических и аналоговых вычислений в очень простой и выразительной форме. CoDeSys автоматизирует составление FBD диаграмм самостоятельно размещая программные компоненты и соединения.

·   Релейно-контактные схемы (LD). Графический язык, описывающий логику работы программы в форме соединения контактов и обмоток реле. Как и в FBD, редактор LD автоматически размещает и проводит соединения компонентов схемы.

·   Последовательные функциональные схемы (SFC). Графический язык, ориентированный на описание взаимосвязанных состояний и действий системы. CoDeSys поддерживает все без исключения типы действий предусмотренные стандартом.

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

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

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

Требования

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

● ООП-расширения должны быть не обязательными, а опциональными;

● ООП- и не ООП-программирование можно совмещать;

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

● ООП должно быть применимо во всех языках МЭК 61131-3;

● программист не должен сталкиваться со сложными определениями.

Расширения

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

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

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