Что такое целевая платформа codesys

IPC@CHIP + CoDeSys или маленькие ядра для большой артиллерии. Часть 3

Итак, мы делаем большой шаг и переходим в мир CoDeSys, как и было обещано во второй части нашей статьи (см. КиТ № 6’2005). Именно в мир CoDeSys, а не IPC@CHIP, потому что работа в этой системе программирования практически одинакова для любого контроллера — в этом и заключается цель CoDeSys и стандарта МЭК 61131-3. Недаром лозунгом организации CoDeSys Automation Alliance (рис. 1), объединяющей изготовителей оборудования для промышленной автоматизации, является фраза «One world. One tool» («Один мир. Один инструмент»). Но все-таки у BECK IPC@CHIP есть одна очень важная особенность, о которой мы поговорим в этой статье.

Идеология CoDeSys

CoDeSys состоит из двух частей: системы программирования и системы исполнения. Система программирования — это приложение Windows, которое позволяет создавать и отлаживать приложения на языках МЭК. Первая — это программа, которая выполняется в целевом устройстве и поддерживает базовые функции системы программирования, отладку, визуализацию и, самое главное, процесс выполнения МЭК-приложения. В случае c BECK IPC@CHIP связь между системой программирования и системой исполнения осуществляется по RS-232 или Ethernet.

Проект, созданный с помощью CoDeSys, в принципе, может выполняться на любом контроллере, поддерживающем CoDeSys. Но как система программирования узнает, на каком контроллере будет выполняться приложение? Ведь разные ПЛК имеют разные процессоры, разный набор входов/выходов и т. д. Для этого используется так называемый Target support package (TSP) — набор конфигурационных файлов, которые дают системе программирования полную информацию о контроллере. В системе программирования CoDeSys может быть установлено сразу несколько TSP для контроллеров различных производителей. Таким образом, один раз написав приложение на языках МЭК, мы можем загружать его в разные контроллеры, используя при этом разные TSP. Далее в статье приводится пример приложения для управления движением на перекрестке с помощью контроллера BECK IPC@CHIP. Но ничто не мешает запустить этот пример на любом другом контроллере с CoDeSys.

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

Что такое CoDeSys для производителя контроллера? Тут все несколько сложнее. Производитель контроллера должен сначала купить систему исполнения в исходных текстах, адаптировать ее под свое «железо», подготовить TSP и только после этого отдать контроллер, уже с поддержкой CoDeSys, конечному пользователю. Процесс адаптации недешев и требует привлечения высококвалифицированных специалистов. В итоге реализовать поддержку CoDeSys в своих контроллерах могут только достаточно крупные компании, имеющие значительный годовой объем производства. Для изделий, выпускаемых на заказ и в малых объемах, адаптация нерентабельна.

В данной ситуации решение фирмы BECK выглядит революционным. Вместе с IPC@CHIP фирма BECK IPC GmbH бесплатно поставляет специальную программу IEC Platform Builder, которая позволяет создать систему исполнения CoDeSys и набор конфигурационных TSP-файлов под конкретное оборудование, построенное на базе BECK IPC@CHIP (рис. 2).

Часть системы исполнения, отвечающая за работу с внешними аппаратными средствами, поставляется в исходных текстах на языке С. В результате мы получаем возможность дооснастить IPC@CHIP любыми устройствами (внешние АЦП, счетчики, удаленные модули ввода и т. п.) и включить их поддержку в CoDeSys. Наш пользователь получит контроллер с готовой системой программирования. Никаких дополнительных драйверов или специальных библиотек ему не нужно. Поддержка «железа» уже реализована.

Такое решение фирмы BECK открывает возможность даже небольшим фирмам создать собственное устройство с полноценной поддержкой CoDeSys.

Подробно изучать IEC Platform Builder мы не будем — это выходит за рамки данной статьи. Рассмотрим по шагам работу CoDeSys с уже готовыми устройствами на базе IPC@CHIP. В качестве примера возьмем оценочную плату DK50 производства фирмы BECK IPC GmbH.

Мы постараемся дать первое представление о базовых возможностях CoDeSys, которые будут полезны при работе с BECK IPC@CHIP. Желательно, чтобы читатель был знаком со второй частью данного цикла статей (см. КиТ № 6’2005), где описаны первые шаги по использованию файловой системы BECK IPC@CHIP и настройке основных параметров.

Шаг первый. Установка файлов целевой платформы на ПК

Первое, что нужно сделать, установить систему программирования CoDeSys. Ее можно найти на диске, который поставляется вместе с чипом или на сайте http://www.3s-software.ru. Убедитесь, что устанавливаемая версия не ниже, чем 2.3.4.1.

Теперь приступим к установке конфигурационных файлов целевой платформы. Для этого нам понадобиться TSP для BECK IPC@CHIP.

Установка каждого такого TSP одинакова. Мы будем использовать пример TSP DK51_WV, поставляемый в комплекте с платой DK50. Данный TSP включает поддержку Ethernet и веб-визуализации. Его можно найти на диске из комплекта DK51, либо скачать с сайта http://www.beck-ipc.com/codesys.

Установка TSP очень проста — достаточно запустить командный файл install.bat из папки tsp.

Шаг второй. Установка системы исполнения для BECK IPC@CHIP

Система исполнения CoDeSys — это программа, которая выполняется в контроллере (целевом устройстве). Она отвечает за связь с системой программирования, управляет МЭК-приложением, созданным с помощью CoDeSys, и всей периферией устройства на базе IPC@CHIP.

Пример системы исполнения для DK50 называется достаточно легкомысленно — myrts.exe — и находится в том же пакете разработчика, что и TSP.

Скопируйте этот файл на диск a: или b: IPC@CHIP. Использование внешнего flash-диска (b:) позволит работать с веб-визуализацией CoDeSys.

Затем нужно прописать запуск myrts.exe в autoexec.bat. Например, если вы используете внешний диск, то autoexec.bat должен выглядеть следующим образом:

Таким образом, система исполнения будет запущена после включения питания IPC@CHIP. Так как система исполнения выполняется под управлением многозадачной операционной системы RTOS, то параллельно с системой исполнения могут выполняться и другие программы.

Шаг третий. Создание приложения для BECK IPC@CHIP

Теперь перейдем к самому важному шагу — созданию приложения для BECK IPC@CHIP. Сначала рассмотрим простой пример управления движением на перекрестке. Возможно, вам будет удобнее иметь исходные тексты данного примера. Их можно скачать с сайта, посвященного CoDeSys — www.3s-software.ru.

Постановка задачи

Есть перекресток двух дорог. Движение автомобилей на нем управляется двумя светофорами, каждый из которых разрешает или запрещает движение по одной из дорог. Светофоры работают в противофазе — то есть когда светофор A разрешает движение, светофор B запрещает.

Обычно интенсивность движения по каждой из дорог различна в разное время суток. Например, если интенсивность движения по дороге A больше, чем по дороге B, то логично сделать так, чтобы зеленый сигнал светофора A горел дольше, чем у светофора B. Это позволит повысить пропускную способность перекрестка. Правда, водители автомобилей на дороге B будут не очень рады — придется постоять на перекрестке немного дольше.

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

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

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

В итоге, после того как мы сделаем этот важный шаг, получим возможность управлять светофором (включать/выключать, задавать периоды действия разрешающего сигнала) удаленно, например через Интернет.

Создание проекта

Открываем CoDeSys, в меню File выполняем команду New. Теперь нужно выбрать целевую платформу (устройство), в которой будет выполняться наше приложение. Выбираем DK51_WV — это плата DK50 с поддержкой веб-визуализации (рис. 3).

Появляется диалоговое окно, в котором нам предлагается создать новый программный компонент (POU). По умолчанию это PLC_PRG — программа, вызываемая в каждом рабочем цикле контроллера. Выбираем язык SFC и соглашаемся с прочими опциями диалога New POU (рис. 4).

Функциональный блок TRAFFICSIGNAL

Но на время забудем про PLC_PRG — будем строить приложение снизу вверх. Создадим функциональный блок TRAFFICSIGNAL, который будет отвечать за работу одного светофора. Функциональный блок будет иметь следующий интерфейс (рис. 5). Вход SWITCH_GREEN включает зеленый сигнал светофора, SWITCH_YELLOW — желтый, SWITCH_RED — красный. После включения зеленый сигнал будет гореть в течение времени GREEN_DELAY, а красный сигнал горит в течение времени RED_DELAY. Время работы желтого сигнала не подается на вход, так как оно фиксированно и составляет 2 с.

Свыходами все понятно — GREEN, YELLOW и RED включают сигналы соответствующих цветов.

Теперь опишем логику работы данного функционального блока на языке FBD. Чтобы управлять светофором, нам понадобится таймер TP, который входит в библиотеку standard.lib (она присоединяется к проекту автоматически при его создании). Логика работы таймера показана на рис. 6.

Вход IN включает выход Q на время PT. Время с момента включения выхода индицируется на выходе ET.

Используя такой таймер, работу светофора можно описать с помощью трех FBD-схем (рис. 7).

Функциональный блок состоит из двух разделов: объявлений и схем, которые описывают логику его работы. В разделе объявлений описываются входы/выходы функционального блока, а также внутренние переменные. В данном случае внутренними переменными являются экземпляры функциональных блоков TP — по одному на каждый сигнал.

С работой функционального блока, наверное, все понятно.

PLC_PRG

Созданный нами функциональный блок TRAFFICSIGNAL позволяет лишь включать и выключать сигналы светофора. Теперь нам предстоит задать последовательность включения сигналов каждого светофора. Заметим, что сигналы одного светофора зависят от сигналов другого.

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

Возвращаемся к программе PLC_PRG, которую мы создали в самом начале.

В разделе объявлений нужно объявить два экземпляра функционального блока TRAFFICSIGNAL: TS1 и TS2 (рис. 8). TS1 — для управления светофором A, TS2 — для управления светофором B.

По умолчанию схема состоит из одного шага INIT. Добавим еще четыре, как показано на рис. 9.

Каждый шаг описывает одну стадию работы светофоров.

Начнем с шага INIT:

Здесь мы задали время включения каждого из сигналов светофоров.

Следующий шаг RED включает красный сигнал светофора A и зеленый сигнал светофора B. Для реализации этого шага нам понадобится два действия — входное и основное. Входное действие выполняется один раз при входе вшаг, основное — в каждом цикле, пока не будет достигнуто условие перехода. Во входном действии мы просто включаем нужные сигналы светофора:

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

Шаг YELLOW1 состоит из трех действий. Входной шаг включает желтый сигнал светофора A:

В основном шаге вызывается TS1, до тех пор, пока желтый сигнал A не выключится.

Выходное действие выполняется, когда переход уже «сработал». В нем выключается зеленый сигнал светофора B:

Шаг GREEN включает зеленый сигнал светофора A и красный сигнал светофора B. Для этого во входном действии шага прописываем:

В основном действии:

Последний шаг YELLOW2 включает желтый сигнал светофора B и выключает зеленый сигнал светофора A.

Входное действие YELLOW2:

Основное действие YELLOW2:

Выходное действие YELLOW2:

Описанная последовательность шагов выполняется циклически.

Теперь добавим в нашу программу возможность включения/выключения светофора. Желтый сигнал выключенного светофора должен мигать. Выключение светофора можно проводить только после завершения полного цикла его работы.

За включение/выключение светофора будет отвечать глобальная логическая переменная ON.

Добавим в нашу SFC-схему альтернативную ветвь, которая выполняется, когда светофор выключен (ON = FALSE).

В альтернативной ветви (рис. 10) есть два шага. Шаг BLINK_YELLOW включает желтый сигнал обоих светофоров на две секунды:

После того как желтые сигналы будут выключены, в выходном действии сбрасываются входные сигналы:

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

Шаг DELAY пустой. Он нужен только для задержки, которая длится 2 c. В течение этого времени желтый сигнал светофора не горит. Для задания этой задержки нужно в свойствах шага определить параметр Minimum time (рис. 11).

Осталось лишь модифицировать программу так, чтобы можно было задавать период работы светофора и время включения зеленого сигнала светофора. Будем считать, что период работы светофора должен быть от 20 с до 6 мин. Достаточно лишь задать время включения зеленого сигнала светофора A, так как время включения красного можно посчитать через период.

Время зеленого сигнала B будет соответствовать времени красного сигнала A, а время красного B — зеленому A. Это связано с тем, что светофоры работают в противофазе.

Период работы светофора будет храниться в переменной TS_period, а время разрешающего сигнала светофора A (в процентах от периода) — в переменной TS1_greentime.

Установку времени включения сигналов обоих светофоров будем проводить в шаге INIT.

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

Настройка входов/выходов

Начнем с определения входов/выходов. Обычно они объявляются с помощью ПЛК-конфигуратора — по МЭК-адресу объявляется глобальная переменная, которая в проекте будет являться входом или выходом (рис. 12).

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

Для этого в функциональном блоке TRAFFICSIGNAL нужно модифицировать объявления выходов функционального блока следующим образом:

Данная запись говорит о том, что эти выходы функционального блока будут являться выходами контроллера. Теперь определим, какими именно.

Для этого в глобальных переменных проекта в списке variable_configuration напишем следующее:

Запись говорит о том, что PLC_PRG.TS1.RED соответствует нулевому выходу контроллера, PLC_PRG.TS1.YELLOW — первому и т. д. То есть когда значение переменной PLC_PRG.TS1.RED равно TRUE, нулевой выход будет активен. Аналогично и для других выходов.

Создание визуализации

Осталось только создать интерфейс пользователя — и наша система управления движением на перекрестке будет готова. Нам нужно создать визуализацию на вкладке CoDeSys Visualization. Создадим визуализацию с именем PLC_VISU.

Теперь нужно нарисовать форму. Начнем со светофора. Светофор — это три окружности и один прямоугольник — все очень просто (рис. 13).

Аналогично настраиваются другие сигналы светофора.

Теперь клонируем (выделяем и копируем) созданный светофор, изменяем имена переменных (меняем TS1 на TS2) — и наши светофоры готовы.

Приступим к созданию блока управления светофором. Во-первых, нам нужна кнопка включения/выключения светофора. Это обычный прямоугольник. Настраивается он примерно так же, как и сигналы светофора. Различие в том, что он предназначен для ввода информации, поэтому нужно указать, какая переменная будет изменяться при нажатии на эту кнопку. Как это сделать, показано на рис. 16.

У нас есть светофоры, мы можем их включать и выключать, осталось только создать поля для ввода периода работы светофора и времени включения разрешающего сигнала светофора A.

Делается это следующим образом.

Сделанные настройки указывают на то, что период работы светофора будет вводиться с экранной клавиатуры в диапазоне от 20 до 600 с.

Поле ввода для времени включения разрешающего светофора A настраивается аналогично, только в качестве переменной textdisplay используется переменная TS1_greentime, а величина задается в диапазоне от 10 до 90 с.

В итоге должна получиться картинка, показанная на рис. 20.

Как только мы соединимся с контроллером, загрузим и запустим проект, светофоры оживут, и на дорогах воцарится порядок.

Как сделать этот последний шаг?

Настройка связи с контроллером

Открываем меню Online/Communication parameters и создаем TCP/IP-соединение, в котором нужно указать ip-адрес контроллера (рис. 21).

И, наконец, выполняем команду Login, затем Run — дело сделано (рис. 22).

Мы можем управлять светофором с помощью визуализации через Интернет, как бы далеко он от нас не находился.

Согласитесь, что создать визуализацию для управления контроллером в CoDeSys гораздо проще, нежели написать специальное cgi-приложение.

Мы коснулись только самых простых возможностей использования CoDeSys в собственных устройствах. Описания промышленных систем, использующих CoDeSys, и практические примеры их применения вы найдете страницах сайта Automation Alliance www.automation-alliance.com.

Надеемся, что наше краткое введение поможет вам в практической реализации собственных интересных идей. Будем рады, если вы найдете возможность рассказать о своих достижениях.

Источник

CODESYS для программирования встраиваемых систем

В системах промышленной автоматизации базовым интеллектуальным элементом является программируемый логический контроллер (ПЛК) [1, 2, 3, 6, 7]. С точки зрения программирования главная особенность ПЛК состоит в том, что для работы с ним не требуется образование в области информатики. Инструменты и языки программирования ПЛК должны быть максимально просты и в то же время эффективны. Упрощение использования не должно повлечь за собой ограничение круга решаемых задач.

Рис. Эволюционный набор для PLC Core модулей SYSTEC с системой исполнения и визуализацией CODESYS V3

Для удовлетворения этих противоречивых требований были созданы специальные языки программирования. В 1982 г. вышла первая редакция международного стандарта МЭК61131-3 (далее МЭК). В нем определено пять языков программирования ПЛК: три оригинальных визуальных и два, пришедших из мира компьютеров. Так, к первым относятся языки «релейных схем» (Ladder Diagram, LD), «функциональных блоковых диаграмм» (Function Block Diagram, FBD) и «последовательных функциональных схем» (Sequential Function Chart, SFC). А «Список инструкций» (Instruction List, IL) — это аппаратно-независимый ассемблер. Высокоуровневый язык «структурированный текст» (Structured Text, ST) представляет собой модифицированный Паскаль. Отдельные программные компоненты можно описывать на разных языках МЭК даже в одном проекте. В зависимости от уровня подготовки, типа решаемой задачи и личных предпочтений прикладной МЭК-программист выбирает оптимальный язык.

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

CODESYS включает в себя редакторы и трансляторы для всех пяти стандартных языков с рядом существенных расширений. Он также поддерживает значительное число специализированных отладочных и сервисных функций. На сегодня CODESYS — мировой лидер среди МЭК-комплексов. С его помощью ежегодно программируется более полумиллиона контроллеров. После долгих лет горячих споров 18.01.2013 г. была одобрена третья редакция стандарта МЭК 61131-3. В нее вошли оригинальные объектно-ориентированные расширения языков МЭК [4], впервые реализованные в комплексе CODESYS V3. Таким образом, CODESYS создал новый международный стандарт. Описанию его составляющих, приемам эффективной работы и практике применения посвящено несколько книг и множество статей [1, 3, 6, 7, 8, 9].

Аспекты программиста

Чаще всего программисты встраиваемых систем противопоставляют CODESYS интегрированным компиляторам языка С/C++. Попробуем сравнить их технически (результаты сравнения приведены в таблице).

Как показано в таблице, для человека, имеющего образование по специальности программирование, C/C++ является естественным выбором. Переход к использованию МЭК-языков потребует некоторых усилий по освоению. Обычно начальный дискомфорт в CODESYS вызывает отсутствие главного цикла и функций ввода/вывода, которые полностью «спрятаны» в системе исполнения. Существенно отличается работа с таймерами. Ближе всего к языку C в CODESYS язык ST. Как правило, для его уверенного освоения программисту достаточно нескольких часов [5].

Использование МЭК-языков может не дать явных преимуществ мгновенно. Они проявляются ярко при необходимости пояснения прикладной программы другим людям. В этом смысле весьма эффективна связка языков SFC и ST. Диаграмма SFC визуально представляет интуитивно понятный алгоритм работы, буквально «оживающий» в онлайновом режиме. Действия шагов SFC описываются на привычном высокоуровневом языке ST.

Аспекты руководителя

Некоторые успешные практические применения CODESYS во встраиваемых системах инициировались не техническими специалистами, а менеджментом компании. Чаще всего главной причиной становилась одна из четырех, перечисленных ниже.

Проблема правильной организации работ

Как правило, в компании есть системный программист с соответствующим образованием. Он начинает с «оживления» платы, установки операционной системы (ОС) или самостоятельной разработки необходимого функционала нижнего уровня. Кажется логичным, чтобы он продолжил работу над системой далее, включая прикладные функции. Ему приходится потратить немало времени на то, чтобы разобраться с прикладной сферой. Будь то газовый котел, система управления яхты, пульт авиационного тягача или что угодно, постепенно он начнет ориентироваться в теме не хуже заказчика. Иногда даже лучше, поскольку вынужден разобраться с причинно-следственными связями и выстроить алгоритмы. В итоге компания приобретает абсолютно уникального специалиста. Работа успешно сдается. Далее становится ясным, что только этот специалист способен сопровождать систему. Его нельзя отвлекать или заменять, нельзя предоставить отпуск или уволить. Компания попадает в зависимость от специалиста.

Рис. Самолетный тягачком пании TREPEL. Вместо обычных рычагов управления он оснащен встраиваемым панельным PC c CODESYS компании Janz Tec

Вначале сам программист рад своей уникальной позиции. По прошествии нескольких лет он замечает, что «золотой фонтан» не забил, а работа стала утомительной. Он отстал от новых технологий по основной специальности. Сменить работу не реально. Проблема возникает с двух сторон.

CODESYS выручает благодаря свойствам 2 и 5 (см. таблицу). Нижним уровнем, включая установку системы исполнения CODESYS, занимаются системные программисты. Прикладной проект делается в CODESYS специалистами по прикладной области. Благодаря 4, им не требуется специальное образование. Системный и прикладной уровни четко разделены, как и требования к их исполнителям. При необходимости сопровождение ПО может быть передано заказчику. Специалистам заказчика достаточно пройти двухдневные учебные курсы.

Проблема развития универсальности системы и расширения рынка сбыта

Рис. Пульт управления яхтой, разработанный компанией Exor

Если устройство оказалось востребованным, то постепенно возникает необходимость специальных исполнений для разных заказчиков. Появляется несколько «прошивок» программы. Потом разрабатывается специальная компьютерная программа — конфигуратор системы. Она настраивает параметры устройства. Постепенно число параметров возрастает. Соответственно, разбухает документация. Но по-прежнему находятся заказчики, которым не хватает нужного именно им функционала. Рождается логичная мысль пойти дальше и дать заказчикам (дистрибьюторам, установщикам) возможности программирования системы. С языком C++ это нереально. CODESYS решает данную проблему. Существует ряд специализированных контроллеров для печатных машин, деревообрабатывающих станков, заправочных станций, дорожных машин, химических аналитических приборов и др., которые оснащены CODESYS и дополнены специализированными библиотеками. Изготовитель соответствующей машины сам адаптирует контроллер под разнообразные модели и наращивает функционал. Изготовитель встраиваемой системы выигрывает за счет унификации и расширения областей применения.

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

Проблема интеграции с устройствами других компаний

Обычно в успешно развивающейся системе возникает необходимость подключения приборов, датчиков и других устройств ведущих мировых изготовителей. Самостоятельная реализация стандартных полевых сетей значительна по трудоемкости. Покупка готового стека дорога. CODESYS (см. п. 10 таблицы) позволяет поддержать практически все стандартные сети. В нашей практике к использованию CODESYS во встраиваемых системах чаще других приводила необходимость поддержки стеков CANopen и EtherCAT.

Проблема замены ПЛК встраиваемой системой

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

Установка к CODESYS

Для того чтобы устройство программировалось в CODESYS, в нем предварительно должна быть установлена так называемая система исполнения CODESYS Control. Она включает планировщик задач, загрузчик, функции отладки, обслуживает полевые сети, ввод/вывод и т. д. Именно благодаря ей МЭК-программа оказывается аппаратно-независимой. Набор ресурсов, которые должна обслуживать система исполнения, отличается у разных контроллеров. Речь идет не только о микроконтроллере, но и об устройстве в целом. По этой причине нельзя просто скопировать систему исполнения с одного устройства на другое. Она всегда требует некоторой индивидуальной адаптации. Все существующие встраиваемые системы с CODESYS созданы одним из трех способов:

По требованию российских заказчиков Beck создала специальное исполнение чипов с расширенным температурным диапазоном (–40 °С). Существует исполнение для энергетики с поддержкой коммуникационной библиотеки МЭК 61850.

Первый путь выбирают крупные изготовители встраиваемых систем. Он оправдан при выпуске от нескольких сотен изделий в год и выше. В странах ЕС все более развивается практика заказа разработки. По числу применений в России лидирует технология Beck IPC@CHIP. В любом случае среда программирования CODESYS поставляется бесплатно. Никаких ограничений в функционале и числе установок в ней не предусмотрено. В CODESYS имеется встроенный эмулятор контроллера. Это позволяет начать работу без приобретения аппаратных средств.

Рис. «Беспилотный» транспортер E&K AUTOMATION на базе собственного встроенного контроллера и модулей ввода/вывода Wago IO

Заключение

Сегмент встраиваемых систем в суммарном годовом объеме применений CODESYS ежегодно увеличивается. CODESYS применяется во встраиваемых контроллерах компаний Bosh, Rolls-Royce Marine, Praxis, CC Systems, Moba и др. Это далеко не опытные прототипы, речь идет о десятках тысяч изделий. Примеры нескольких применений показаны на фотографиях.

Среди МЭК-систем программированиия CODESYS выделяется тем, что, подобно компиляторам С/С++, непосредственно генерирует надежный и компактный машинный код, пригодный для встраиваемых систем. Простые в освоении языки МЭК позволяют привлечь к разработке и сопровождению специалистов прикладной области. Интерес для разработчика встраиваемых систем может представлять богатый функционал комплекса CODESYS. Многозадачность реального времени, обработка событий, встроенная визуализация, развитый набор коммуникаций, «горячее» обновление кода, полевые сети, поддержка управления через Интернет, средства национальной локализации проектов и другие функции CODESYS могут быть не востребованы во встраиваемой системе изначально. Но необходимо учитывать, что все они создавались эволюционно, исходя из практических требований, возникавших у пользователей контроллеров в разных странах, разных условиях и на разных этапах работ. В процессе жизни встраиваемой системы неизбежно возникают аналогичные или близкие задачи. Например, задача настройки и тестирования оборудования заказчиком, интеграция с другим оборудованием, веб-интерфейс и т. п. Во многих случаях CODESYS даст готовое решение.

Источник