Автор - Гришин Дмитрий Анатольевич, инженер-разработчик в «Эй энд Ти Текнолоджис» (Группа «КАСТОМ»)
Российский потребитель, делая выбор из обширного перечня модульных и моноблочных программируемых контроллеров, для решения широкого спектра задач часто предпочтение отдавал иностранному производителю. Сегодняшние тенденции побуждают склоняться не к импортным решениям, а присматриваться к отечественным разработкам. Одной из них является серия модульных программируемых контроллеров «К15».
ЦПУ ПЛЮС «КОРЗИНА» МОДУЛЕЙ
Что такое «К15»? Модульные контроллеры этой линейки реализуют классическую концепцию программируемых логических контроллеров (ПЛК): центральное процессорное устройство (ЦПУ) плюс «корзина» модулей ввода-вывода. Такой подход, в отличие от моноблочных вариаций либо смешанных решений, дает возможность создать гибкую, масштабируемую локальную систему управления ровно под те задачи, которые необходимо решить в данный момент.
Это позволяет не переплачивать за лишнее «железо», но в то же время иметь возможность практически бесшовно - просто докупив необходимые модули - расширить и усложнить систему при необходимости.
Еще один несомненный плюс такого решения – простота и дешевизна эксплуатации. Не нужно менять дорогостоящий ПЛК ради пары каналов ввода-вывода, вышедших из строя. Всего лишь меняем неисправный модуль – и система снова в работе.
Серия «К15» отличается от других подобных решений неплохой эргономичностью: классическое крепление на DIN рейку вкупе с малой шириной модулей. Все модули, включая ЦПУ, имеют один форм-фактор, что существенно упрощает компоновку при проектировании шкафного оборудования.
Также следует отметить удобное расположение интерфейсной шины, соединяющей модули с ЦПУ: она уложена непосредственно в DIN рейку и фиксируется в ней от выпадения. Это дает возможность менять модули, не разбирая «корзину» и даже не отключая питания. Но об этом далее.
ДЛЯ ШИРОКОГО СПЕКТРА ПОТРЕБНОСТЕЙ
Сердцем и ключевым компонентом системы «К15», конечно же, является центральное процессорное устройство. Их в семействе на данный момент 3 модели: F1, F4 и H7. Эти ЦПУ призваны покрыть достаточно широкий спектр потребностей автоматизации.
Для интеграции с системами верхнего уровня, а также для построения распределенных систем все ЦПУ реализуют широко распространенный протокол обмена Modbus, доступный через все имеющиеся интерфейсы. Приятным дополнением к этому имеется возможность реализации нестандартных протоколов обмена.
F1 имеет достаточно скромные характеристики и подойдет для небольших задач, где требуется изящное недорогое решение с сохранением всех преимуществ модульной схемы. (Рисунок №1, Таблица №1)
F4 – более мощный собрат F1, имеющий на борту Ethernet интерфейс. Помимо увеличенных тактовой частоты процессора, RAM и Flash, данное ЦПУ имеет встроенный веб-интерфейс. Он позволяет в свою очередь следить за состоянием корзины, ее составом, производить ее мониторинг и диагностику в реальном времени.
Также веб-интерфейс дает возможность производить загрузку проекта в ЦПУ без применения программатора и обновлять программное обеспечение подключенных модулей ввода-вывода.
(Рисунок №2, Таблица №2)
H7 это наиболее производительное ЦПУ из представленных. Имея неплохие характеристики процессора, а также возможность применения внешнего Flash-накопителя в виде SD карты, он способен «проворачивать» достаточно сложные алгоритмы с хорошим быстродействием. Также стоит отметить применение FRAM вместо EEPROM в качестве энергонезависимой памяти. Веб-интерфейс, конечно, также присутствует.
(Рисунок №3, Таблица №3)
Все ЦПУ работают под управлением операционной системы реального времени (ОСРВ), что повышает надежность системы, ее быстродействие и позволяет использовать аппаратные возможности процессоров на все сто процентов.
Одна голова – хорошо.
МОДУЛИ ВВОДА-ВЫВОДА: СОЗДАЕМ АБСОЛЮТНО ПРОИЗВОЛЬНЫЕ СИСТЕМЫ
А как обстоят дела с периферией? Вот тут открывается простор для фантазии – линейка «К15» может похвастаться обширной номенклатурой модулей ввода-вывода. От банальных и простых дискретных модулей ввода и вывода, до гальванически развязанных аналоговых модулей вывода, счетных модулей, PWM модулей и т. д. Комбинируя их в «корзине», можно создавать абсолютно произвольные системы. Причем это могут быть как системы совсем без модулей, с одним модулем либо сложные вариации до 8 модулей с одним ЦПУ.
Ключевая особенность всех этих модулей – механизм взаимодействия с ЦПУ. Тут стоит остановиться немного подробнее. Как было сказано выше, между ЦПУ и модулями предусмотрена интерфейсная системная шина. Она выполнена на базе CAN интерфейса и физически представляет собой 5-контактную шину T-Bus, на которую устанавливаются ЦПУ и модули в процессе монтажа на DIN рейку. Так как шина расположена в задней части корпуса модулей со стороны рейки, появляется возможность без труда снимать и устанавливать модули без демонтажа всей «корзины».
Но главное состоит в том, что модули ввода-вывода можно заменять даже на работающей системе, не отключая питания (так называемая «горячая замена»). Это бывает весьма критично там, где отключение и перезапуск локальной системы управления связаны с нарушением технологического процесса или серьезными производственными издержками.
В ближайшей перспективе планируется выпуск специальной серии модулей ввода-вывода «К15», оснащенных интерфейсом RS485, на котором будет реализован все тот же популярный протокол Modbus. Это позволит произвести буквально помодульное дооснащение имеющихся ЛСУ и РСУ без применения ЦПУ «К15» в тех проектах, где уже имеются ЦПУ, но не хватает каналов ввода-вывода.
Ключевые особенности программирования
«язык высокого уровня»
Ну и, конечно же, нельзя не поговорить о том, как «оживить» контроллеры «К15». В отличие от классических языков Международной электротехнической комиссии (МЭК), которые позволяют без глубоких знаний программирования создавать управляющие проекты для таких систем, «К15» предлагает создание проектов на широко распространенных языках высокого уровня С/С++.
Стоит согласиться, что это не совсем популярный метод работы с модульными системами в сфере автоматизации. Хотя тут можно вспомнить, что в качестве скриптовых языков С, С++, С#, VBA используются в контроллерах Siemens, B&R, Allen Bradley, Schneider и других изделиях. Какие же преимущества дает создание проектов таким способом?
Во-первых, не стоит пугаться формулировки «язык высокого уровня». В конце концов упомянутые С и С++ очень похожи на один из языков МЭК – ST (Structured Text). По сути это все те же переменные, циклы, условия, переходы. Но если ST позволяет реализовать лишь то, что заложено в Runtime-оболочке контроллера, которая является как бы исполняемой средой для нашего проекта, то язык Си позволяет заглянуть за рамки этой среды.
Нам доступен весь синтаксический инструментарий этого мощного орудия программирования. К тому же многие алгоритмические приемы на С/С++ реализуются проще и понятнее, а создание структур, приведение типов, callback функции, перегруженные функции и прочие приемы программирования – приятный бонус использования языка.
Во-вторых, немаловажное значение играет инструментарий разработки. Далеко не все среды разработки проектов под те или иные модульные системы легки и понятны в освоении. Например, описание работы со средой TIA Portal занимает более 1000 страниц руководства программиста. Не менее сложна в освоении и Studio 5000 для контроллеров Allen Bradley серий Control и CompactLogix. А чтобы уверенно работать в CodeSys, нужен не один месяц освоения среды.
Семейство «К15» программируется в среде разработки CubeIDE – это официальная свободно распространяемая IDE от компании STMicroelectronics, чьи процессоры и являются главным элементом контроллеров на данный момент. В комплекте с контроллерами идет стартовый проект и подробная инструкция с описанием работы. Просто открываем проект в CubeIDE, компилируем его и «отправляем» в контроллер. Система уже будет работать, отображать веб-интерфейс, опрашивать модули. Ну, а затем, используя описанные структуры и функции, можно реализовать задуманное.
(Рисунок №4, Рисунок №5)
В-третьих, доступность среды разработки и ценовой аспект. Если кто-то приобретал лицензии для работы с контроллерами Emerson, Siemens, B&R, Yokogawa и многих других - знают, что это порой немалая сумма.
Да, возможно, читатель возразит: а как же CodeSys, Beremiz, OwenLogic и прочие системы? Да, они не требуют приобретения лицензий, но и далеко не все модульные системы ими поддерживаются. Как правило, каждый производитель старается разработать свой инструментарий как платформозависимый программный продукт либо как свою экосистему. Это, например, DeltaV, TIA Portal, FactoryTalk и прочие.
И если до недавнего времени все эти программные продукты можно было хотя бы свободно приобрести, то, учитывая повальный уход с рынка зарубежных игроков, это уже будет сделать весьма затруднительно. В противовес этому тем более привлекательно решение «К15» – использовать доступную среду CubeIDE, не требующую лишних затрат на приобретение лицензий.
Ну, и, наконец, процесс отладки проекта. Это то, что непосредственно влияет на скорость разработки. В чем одна из ключевых особенностей языков МЭК – механизм он-лайн трассировки и отладки проекта. «К15» также может похвастать этим функционалом, который изначально заложен в самой IDE. Но отладка здесь, как и подобает любому языку высокого уровня, гораздо более многосторонняя и глубокая. Тут и классический вывод текущих переменных, и точки останова, и принудительная запись значений, и пошаговое исполнение кода. Также есть возможность вернуться на шаг назад либо выполнить остановку исполнения кода по условию. Дополнительным удобством для разработчика можно считать контекстную подсветку значений переменных при наведении курсора.
Одним словом, вся мощь языков С/С++, к вашим услугам. Это делает разработку быстрее и качественнее, а дальнейшее сопровождение и рефакторинг проекта – дешевле для конечного потребителя. Если вы – убежденный сторонник МЭК, то, конечно, переход на такой способ разработки нельзя назвать совсем простым. Но некоторые усилия, потраченные на изучение языков Си, по крайней мере в рамках поставленных задач, с лихвой окупятся в дальнейшем.
ПРИМЕР РЕАЛИЗАЦИИ ЗАДАЧИ: ПРОСТОТА СОПРОВОЖДЕНИЯ И МАСШТАБИРОВАНИЯ ПРОЕКТА
Теперь рассмотрим, как решаются прикладные задачи средствами разработки «К15». Возьмем вполне конкретный пример. Допустим, у нас есть факельная установка с электроискровым розжигом дежурной горелки и фотодатчиком наличия пламени. Наша задача: реализовать режим автоматического розжига дежурной горелки.
При подаче сигнала пуска должен открываться клапан топливного газа, а розжиг должен происходить циклично до тех пор, пока либо не загорится пламя, либо не будут сделаны 3 попытки розжига. Также алгоритм должен обеспечивать автоматический перерозжиг горелки в случае погасания пламени.
Что ж, перейдем к реализации. Сначала попытаемся реализовать задуманное средствами Codesys. Пускай это будет всеми любимый язык МЭК – FBD. Создадим необходимые переменные и функциональные блоки.
(Рисунок №6)
start_DI – сигнал пуска системы (например, кнопка)
stop_DI – сигнал остановки системы
foto_DI – фотодатчик наличия пламени
iskra_DO – управление подачей искры
valve_DO – управление клапаном
Затем создаем функциональную схему, реализующую алгоритм (Рисунок №7):
Рассмотрим ее по порядку. При подаче сигнала пуска через детектор переднего фронта срабатывает триггер rs1, принимая логическое состояние 1. Открывается клапан, далее сигнал следует на блок AND. Так как флаг совершения попытки розжига try и сигнал с фотодатчика имеют логический 0, то инверсивный сигнал на входе блока имеет 1, и происходит подача искры через таймер импульсного сигнала tp1 во второй строке схемы.
Одновременно с этим запускается таймер ожидания пламени ton1. По завершению его счета, спустя 10 секунд выставляется флаг совершения попытки. Вместе с этим счетчик ctu1 производит инкрементирование числа попыток на 1, сравнивая полученное число с уставкой, равной трем. При достижении трех попыток взводится флаг try_out, который вызывает сброс триггера rs1. Также его сброс вызывает и подача сигнала остановки системы розжига.
При установке флага try происходит изменение значения флага iskra сначала на 0, затем вновь на 1. Тем самым запускается новый цикл розжига. Здесь следует иметь ввиду, что переменная try должна быть объявлена как глобальная и не сбрасываться при каждом цикле скана используемого POU.
В случае горения флаг foto_DI принимает логическое состояние 1. Благодаря этому через инверсию блок AND на выходе принимает логическое состояние 0, блокируя цикл розжига. Если пламя гаснет, блок AND снова принимает состояние 1, и цикл розжига начинается снова.
Таким образом, для реализации задуманного потребовалось создать, помимо простых переменных, еще 8 функциональных блоков, что для такой простой задачи немало.
Теперь попробуем решить ее в рамках программного функционала «K15». Весь код размещаем в файле UCL.c. Здесь также не обойтись без объявления переменных.
(Рисунок №8)
Для единообразия, сигналы имеют схожее обозначение. Дополнительно добавились переменные state (стадия работы системы), count (аккумулятор счетчика времени) и try_count (аккумулятор числа попыток розжига). Далее обратимся к самому коду.
(Рисунок №9)
Алгоритм выполняется в основном цикле файла. Работа системы разбита на стадии: СТОП, РОЗЖИГ и ГОРЕНИЕ. Код достаточно компактный и читаемый. Создание дополнительных функциональных блоков не требуется. Следует обратить внимание, что число стадий может быть легко увеличено, например, можно добавить стадию АВАРИЯ.
В целом, конечно, проект небольшой, задачи весьма тривиальны, но даже тут читатель сможет заметить хороший потенциал использования «К15» в плане программной реализации, простоту сопровождения и масштабирования проекта.
НАДЗОР ОТ СОЗДАТЕЛЕЙ И ОБРАТНАЯ СВЯЗЬ С ПОТРЕБИТЕЛЯМИ
Любая современная разработка не может обходиться без постоянного совершенствования, а также без исправления неизбежно существующих текущих недостатков. Если продукт «живой», он нуждается в неусыпном надзоре его непосредственных создателей. «К15» полностью соответствует этому принципу.
Более того, постоянно собирается информация при обратной связи с клиентами, разрабатывающими свои проекты на «К15», а также с конечными потребителями, эксплуатирующих эти изделия у себя на объектах. Затем, путем коллективного анализа пожеланий наиболее критические из них сразу же идут «под карандаш» разработчиков. Менее важные перманентно внедряются в последующих релизах. Это касается как программной части, так и аппаратного оснащения. Например, увеличение скорости работы FRAM, асинхронное чтение регистров Modbus, реализация пользовательских протоколов и многое другое – это то, что хотели видеть потребители в наших контроллерах.
Как сказано выше, бывают и неполадки. Их нет лишь у того, кто ничего не делает. Тут важна оперативная реакция и своевременное их устранение. С этим тоже все в порядке. Любая неполадка или возникший вопрос обрабатываются в течение 24 часов квалифицированными инженерами, которые без проблем проконсультируют клиента и предложат варианты решения проблемы. Ну, и, разумеется, не останутся без внимания и те, кто столкнулся с трудностями создания проектов – программисты также вникнут в проблематику и поделятся своим опытом решения.
ДОСТОЙНАЯ КОНКУРЕНЦИЯ УШЕДШИМ
Контроллеры «К15» реализуют не только классическую модель ПЛК. Здесь мы видим несколько иной, альтернативный подход к реализации модульных систем. Перекрывая большинство задач, которые решают обычные модульные ПЛК, данная линейка дает разработчику нечто большее, позволяет вывести свои проекты на качественно иной уровень.
Линейка «К15» - отличная отечественная альтернатива в сфере автоматизации как промышленного, так и других сегментов, требующих надежных решений. Это постоянно развивающийся динамичный продукт, способный составить достойную конкуренцию ушедшим вендорам, является экономически эффективным по стоимости владения, эргономичным и надежным решением отвечающим необходимым стандартом качества.