codesys что это за программа
Что такое CoDeSyS 2.3 и с чем его едят?
Приветствую вас друзья, я надеюсь, что у вас сегодня хорошее настроение, наливайте себе зелёного чаю, берите печенье, всякие вкусняшки. В этой статье мы с вами поговорим об универсальной среде разработки программ для программируемых логических контроллеров (ПЛК) CODESYS 2.3
Итак, что же это за программа такая. Это среда разработки, то бишь некая программа, которая создает в себе другие программы для логических устройств. CoDeSyS разработан фирмой 3S Software, немецкими разработчиками. Это универсальный инструмент программирования контроллеров и встраиваемых систем. Комплекс программируется на стандартных языках МЭК 61131-3. О них буду говорить позже.
Из этой статьи вы узнаете:
Сама система реализована на языке С. Существует несколько модификации для различных микропроцессоров. Для привязки к конкретному контроллеру требуется конфигуратор, в настройках которого идет распределение памяти, интерфейс и привязка входов-выходов. Об этом будет ниже.
На рисунке выше я разместил рабочее окно проекта, чтобы показать как оно выглядит. Особенностями данного пакета являются:
Стандартные языки МЭК
Выбор стандарта языков программирования МЭК основан на том, что он является универсальным и удобным языком для программистов, инженеров и технологов. В течение времени язык программирования формировался и изменялся. Как вы думаете, было бы разумно делать мощный инструмент, опираясь на прошлый опыт разработок. В условиях конкурентного производства оборудования очень важно внедрять технологию быстро.
Всего таких языков из стандарта МЭК существует 5:
Какими языками удобнее всего пользоваться? Ну, это для кого как и кому как удобно, жёстких правил нету. Для программистов ближе будет ST, для электриков LD, для технологов скорее всего CFC.
Мне удобно пользоваться CFC и ST. На CFC языке всё наглядно видно, а это очень важно. Особенно когда идёт процесс наладки программы. А ST удобен своей гибкостью, и сложность программы ограничивается лишь вашей фантазией. А какие языки выбрали вы??
Кстати я чаще всего использую комбинацию различных языков. Я использовал такой трюк в проекте с холодильной камерой. Очень сложный проект, на написание программы у меня ушло 2 недели времени.
Конфигуратор входов/выходов
Теперь вернёмся к конфигуратору входов-выходов. О чем идёт речь? Предположим, у вас есть контроллер. У него много входов и выходов, аналоговых и дискретных. И, нам же к каждому входу и выходу нужно каким-то образом привязаться. Чтобы мы могли управлять, либо считывать данные.
Компания 3S Software реализовала в своём пакете CoDeSyS структуру дерева, в которой уже подготовлены некие ячейки памяти, отвечающие за каждый вход и выход контроллера. И мы просто присваиваем имя каждой ячейке, чтобы в дальнейшем управлять ими.
Очень большой плюс комплекса CoDeSyS в том, что среда разработки внедрена во многих логических контроллерах, как и в отечественных, так и в заморских.
Список контроллеров внушителен, поэтому я приведу те, которые знаю:
В целом CoDeSyS это мощный инструмент для реализаций технических задач. Для изготовления пультов управления технологическим процессом, от простых до сложных. Удобен для автоматизации умных домов. Минусом является стоимость подобных систем. Ну как говорится, в автоматике, чем надёжнее система, тем она дороже.
На этом у меня всё, успешных вам внедрений.
Как вам статья? Если понравилась, обязательно поделитесь ею в социальных сетях и подписывайтесь на новости блога.
ПО CODESYS для программирования ПЛК
CODESYS («кодесис») – комплексный инструмент для программирования промышленных контроллеров (ПЛК).
CODESYS v3 – это совершенно новая разработка. В основу CODESYS v3 положен модульный принцип, который позволяет дополнять систему посредством подключения дополнительных модулей.
Единожды изучив среду программирования, вы будете уметь программировать огромное количество контроллеров, основанных на CODESYS.
Особенности ПО для программирования и конфигурирования ПЛК CODESYS
В соответствии со стандартом МЭК 61131-3 CODESYS поддерживает 5 языков программирования:
Кроме этих языков CODESYS включает в себя еще один язык – CFC (Continuous Function Chart). Он похож на FBD, но позволяет располагать функциональные блоки свободно на экране и задавать порядок их выполнения.
Первая версия CODESYS увидела свет в 1994 году. С тех пор CODESYS обрел огромную популярность среди пользователей и производителей ПЛК. На данный момент сотни производителей выпускают тысячи моделей контроллеров на базе CODESYS.
CODESYS очень удобен для программиста.
Единожды изучив среду программирования, вы будете уметь программировать огромное количество контроллеров, основанных на CODESYS.
Описание ПО для программирования и конфигурирования ПЛК CODESYS
CODESYS – это не только среда программирования — это целый комплекс средств по работе с промышленным оборудованием. Он включает собственный OPC-сервер, графический редактор для создания визуализаций, менеджер рецептов, лог аварий и многое другое. На данный момент выпускаются контроллеры на базе двух версий CODESYS: версия 2 и версия 3.
CODESYS v2 поддерживается производителем только в режиме исправления ошибок. Новые функции в него уже не добавляются. Тем не менее, функционала CODESYS v2 достаточно для подавляющего большинства задач. К тому же он требует меньше ресурсов ПЛК и компьютера.
CODESYS v3 – это совершенно новая разработка. В основу CODESYS v3 положен модульный принцип, который позволяет дополнять систему посредством подключения дополнительных модулей.
Основные отличия СODESYS v3 от v2:
И это лишь немногие изменения, которые принесла третья версия CODESYS. Таким образом, CODESYS v3 аккумулировал в себе многие тенденции современной промышленной автоматизации и продолжает регулярно обновляться, обзаводясь всё новыми и новыми функциями.
О тенденциях в промышленных сетях
С тех пор, как в 1979 году появился протокол Modbus, он стал де-факто стандартом промышленной сети. Изначально он был спроектирован для использования с последовательными интерфейсами RS-232/RS-485. Позже практически без изменений он «перекочевал» в сети Ethernet в виде протокола Modbus TCP.
Всемирная популярность протокола Modbus обусловлена несколькими причинами:
При разработке протокол был рассчитан на потребности и вычислительные возможности оборудования того времени. Многие актуальные для сетей нынешнего времени вопросы учтены не были:
Стремление к развитию промышленных сетей привело в появлению в 2003 году стандарта EtherCAT.
Основой EtherCAT является технология Ethernet, что позволяет использовать все преимущества данной технологии.
CoDeSys – повседневный инструмент программиста ПЛК
Представлены архитектура, основные особенности и возможности многофункционального программного комплекса, предназначенного для решения задач промышленной автоматизации, CoDeSys V3, названы наиболее важные и новые его компоненты.
Назначение и области применения CoDeSys
Изначально CoDeSys был нацелен на задачи, требующие автономности, надежности и предельного быстродействия при минимизации аппаратных средств. Благодаря этому он вышел далеко за рамки традиционных для МЭК 61131-3 систем ПЛК. Сегодня автомобили, краны, экскаваторы, самосвалы, яхты, печатные машины, деревообрабатывающие станки, литейные и прокатные машины, сборочные автоматы крупнейших мировых брендов включают один или группу встроенных контроллеров с CoDeSys. Компанией ITQ GmbH в 2011 г. было проведено исследование характеристик и распространенности программных инструментов в областях машиностроения и мобильных применений в Европе [1]. По его результатам, CoDeSys и инструменты на его базе (Bosh Rexroth IndraWorks, Beckhoff TwinCAT и др) используют 36% компаний. Конкурирующие с CoDeSys универсальные инструменты совместно составили 7%.
На сегодняшний день CoDeSys успешно применяется во всех без исключения областях промышленности. В мире более 350 компаний, изготавливают контроллеры с CoDeSys в качестве штатного инструмента программирования. За 2011 г. продано 500 тыс. лицензий на различные устройства с CoDeSys. Все конкурирующие системы отстают в разы, что позволяет доказательно говорить о мировом лидерстве.
Как продукт, CoDeSys ориентирован на изготовителей контроллеров. Разрабатывая новый контроллер, они устанавливают в него систему исполнения CoDeSys Control. Собирают из ее компонентов требуемую конфигурацию, добавляют собственные ноу-хау и специфические компоненты и получают собственное инструментальное ПО. Как правило, к пользователю CoDeSys попадает в коробке вместе с оборудованием. Ему нужно только установить систему и перейти к решению своих практических задач. Все коммерческие и технические вопросы, связанные с поддержкой ядра контроллера, всех типов его аппаратных модулей, библиотек, стеков и конфигураторов сетей его беспокоить не должны. Все это должно быть решено за него разработчиками ПЛК и CoDeSys совместно.
Рис. 1. Редактирование FBD диаграммы в CoDeSys
Среда программирования CoDeSys включает набор инструментов для подготовки и отладки программ, компиляторы, конфигураторы, редакторы визуализации и т.д. При необходимости функциональность системы дополняется опциональными компонентами. Проект CoDeSys можно хранить не только на диске ПК, но и в контроллере, если он имеет достаточный объем памяти, что позволяет избежать потери исходных текстов или путаницы в проектах. Для больших проектов предусмотрено использование системы контроля версий (SVN).
Для отладки пользователю не нужно открывать специальных отладочных окон или составлять каких-либо списков переменных. При подключении к ПЛК редакторы ввода программ «оживают». Непосредственно в них отображаются значения всех видимых на экране переменных. Причем в сложных выражениях видны все промежуточные результаты.
В CoDeSys V3 впервые в мире была реализована поддержка объектно-ориентированного программирования (ООП) в языках стандарта МЭК 61131-3. Разработка концепции была начата в 2005 г. [2]. Введен ряд новых ключевых слов для определения методов, свойств, интерфейсов и наследования, позволивших эволюционно развить в объект привычный функциональный блок. Пользователь может по своему усмотрению писать программы привычным образом или использовать объекты. Такой подход не создает лишних проблем «старым» прикладным программистам. В тоже время молодые специалисты, изучившие ООП в вузе и уже не представляющие себе серьезную работу без данной технологии, смогут реализовать свой потенциал. Предложенные расширения ООП прошли проверку временем в CoDeSys, получили широкое одобрение и будут включены в стандарт.
Из новшеств CoDeSys, добавленных за последний год, следует отметить странично-ориентированный FBD и поддержку языка Python для автоматизации работы в среде программирования. Обычно для таких целей используются пакетные файлы. Они удобны для примитивных задач, но не позволяют выполнять разные действия по условиям, разобрать XML файл, обработать результаты и отправить их по электронной почте. Использование Python снимает все мыслимые ограничения.
CoDeSys включает конфигураторы ввода/вывода с поддержкой полевых сетей Modbus, PROFIBUS, PROFINET, DeviceNet, CANopen, J1939, EtherCAT, SERCOS III, Ethernet IP и большое число сервисных модулей.
CoDeSys поставляется бесплатно. С сайта 3S-Smart Software Solutions доступен для загрузки полнофункциональный дистрибутив. В него входит интерфейс и интерактивная документация на русском языке.
CoDeSys Automation Platform
Типовые области применения CoDeSys Automation Platform:
расширение функциональности CoDeSys: возможность добавления в среду программирования нового редактора программ, инструмента конфигурирования специализированной полевой сети, автоматизация некоторых типовых операций (мастера) и др.;
замена составных компонентов (plug-in) CoDeSys: если штатный компонент среды программирования не удовлетворяет требованиям пользователей, то возможно заменить его, например, изменить форму отображения программ, вид окон и др.;
создание собственного программного комплекса на базе CoDeSys. Известными примерами могут служить системы SoMachine от Schneider Electric и TwinCAT 3 от Beckhoff.
Система исполнения CoDeSys Control
В общей сложности CoDeSys Control включает более 200 компонентов. Каждая «сборка» под конкретную модель ПЛК будет отличаться. Ее состав определяется возможностями аппаратуры и типом ПЛК. Включение абсолютно всех компонентов, на всякий случай, привело бы к неоправданному росту аппаратных ресурсов и стоимости. Например, включение функции «горячей» правки кода без остановки ПЛК удваивает требования к ОЗУ. Некоторые компоненты представлены в нескольких вариантах. Например, компонент «менеджер задач». Самый дешевый ПЛК может иметь единственный аппаратный таймер, «тикающий» каждые 10 мс, и не иметь ОС. Для него подойдет простой планировщик циклических задач без вытеснения. С ним не смогут работать некоторые другие компоненты, например, ЧПУ или стек CANopen, но они и не требуются в ПЛК такого уровня. Для ПЛК с мощным 32- или 64-битным процессором и ОС РВ разумно включить наиболее совершенный «менеджер задач» с поддержкой событий, реального времени и нескольких приложений в одном устройстве. С каждым таким приложением можно работать как с независимым ПЛК: загружать, запускать, останавливать и отлаживать программы, не влияя на работу других приложений.
CoDeSys Control может функционировать под управлением любой ОС или даже без нее. Наиболее часто используют ОС VxWorks, Windows CE и Linux. Имеются адаптации под RT-OS32 (RTKernel), QNX, Nucleus, pSOS, OS9, TenAsys INtime. Изготовитель оборудования может самостоятельно адаптировать CoDeSys Control под другую ОС.
В некоторых случаях адаптация CoDeSys Control в свое оборудование может быть проблематична. Ограничением может стать отсутствие технических специалистов, соответствующего уровня или экономические условия. В таких случаях целесообразно использовать готовые процессорные модули (PLCcore) с уже адаптированным и установленным CoDeSys Control. Популярным PLCcore для CoDeSys является Beck IPC@CHIP.
CoDeSys Control непрерывно развивается. Добавляются принципиально новые компоненты, совершенствуются и «мелкие детали». Например, для современных быстрых ПЛК c CoDeSys пришлось вводить новый тип данных для работы с наносекундными интервалами времени. Обычному пользователю CoDeSys не нужно заботиться об устройстве системы исполнения. Ему достаточно только периодически загружать и устанавливать бесплатные обновления в соответствии с рекомендациями изготовителя ПЛК.
SoftPLC CoDeSys SP RTE
CoDeSys SP RTE представляет собой специальную систему исполнения для ОС семейства Windows со встроенным ядром жесткого реального времени. Она позволяет превратить обычный компьютер в быстродействующий ПЛК. Ввод/вывод подключается через полевые сети. SP RTE обеспечивает стабильность рабочего цикла МЭК программ в диапазоне микросекунд и работу контроллера при зависании ОС.
Среда CoDeSys оснащена встроенной системой визуализации и операторского управления. Непосредственно в CoDeSys можно построить графический интерфейс оператора или модели объекта, без использования внешних инструментов. Для интеграции с программой достаточно прописать в свойствах элементов соответствующие переменные. Не требуется создавать символьные файлы, настраивать связь или выполнять иные рутинные операции. Если работает CoDeSys, то работают и средства визуализации.
Визуализация CoDeSys может параллельно работать на нескольких устройствах:
CoDeSys WebVisu позволяет контролировать работу своей системы из любого места и в любое время через Internet. Web-сервер является компонентом системы исполнения.
Из последних новшеств визуализации CoDeSys выделяется пакет библиотек элементов визуализации для различных прикладных областей с современным графическим представлением [См. рис 2.]. Наиболее впечатляющим элементом можно назвать 3D редактор движений для SoftMotion.
Рис.2. Визуализация панели автомобиля
Рис. 3. G-код движения в CoDeSys и его визуальное представление
Комплекс Safety ориентирован на обеспечение безопасности там, где присутствует человек. CoDeSys Safety представляет собой комплекс инструментов, который позволяет разрабатывать контроллеры, удовлетворяющие требованиям стандарта IEC 61508 для оборудования систем безопасности Safety Integrity Levels 3 (SIL3). Он включает безопасную систему исполнения, безопасный компилятор, конфигураторы безопасных сетей, библиотеки PLCopen Safety и набор документов, включающий методику тестирования и сертификации. Эта технология существенно сложнее обычных ПЛК систем. Так, например, до запуска кода выполняется целый ряд специальных проверок. После загрузки машинного кода в контроллер и создания загрузочного образа код скачивается обратно в среду разработки, производится его декомпиляция и сравнение с исходным текстом. Безопасные контроллеры уровня SIL3 должны проходить обязательную сертификацию. Это весьма сложный и дорогостоящий процесс. Применение CoDeSys Safety позволяет существенно упростить его.
Выше упоминалась технология PLCcore, позволяющая радикально упростить создание контроллеров с CoDeSys. Похожая идея воплощена и для безопасных контроллеров. Ее основой служит сертифицированный модуль TwinSafe EL6900 компании Beckhoff. Встроив это в устройство, имеющее поддержку CoDeSys и EtherCAT Master, получаем собственный SIL3 контроллер.
Для систем уровня SIL2 все гораздо проще. CoDeSys сертифицирована как надежная система, имеющая боле 1 млн. применений. Для SIL2 используются все стандартные редакторы МЭК языков, компактная система исполнения с определенным набором компонентов, сертифицированные библиотеки элементов и безопасный ввод/вывод.
В противоположность безопасным (Safety), надежные системы (Redundancy) чаще необходимы в местах, куда человеку трудно добраться, либо там, где остановка работы оборудования недопустима по технологическим или финансовым критериям. Например, 5 мин простоя линии разгрузки крупного морского порта обходятся дороже стоимости всего электронного оборудования.
CoDeSys Redundancy представляет собой специальный плагин для среды программирования и набор компонентов системы исполнения, обеспечивающий синхронизацию, диагностику и переключение основного и дублирующего контроллеров.
CoDeSys Professional Developer Edition
Интеграция UML стала следующим логическим шагом после реализации в CoDeSys ООП. Диаграмма классов дает визуальное представление зависимостей функциональных блоков, методов и интерфейсов, которые теперь могут редактироваться графически. Диаграммы состояний и диаграммы активности представляют собой новые языки для разработки прикладных проектов. Они позволяют описывать состояния и переходы сложных процессов. Оба высокоуровневых языка призваны упростить совместную работу программистов и инженеров технологов, ускорить построение структуры приложения и собственно программирование.
Статический анализатор кода осуществляет проверку исходного кода МЭК программ на соблюдение более чем 50 адаптивных правил. Он выявляет потенциально опасные места, способные вызвать ошибки и устранить их сразу, еще до фазы отладки и тестирования проекта. Это улучшает качество кода, ускоряет работу и позволяет избежать ошибок с самого начала работы.
Комплект инструментов профессионального разработчика продолжает расширяться. В настоящее время в разработке находятся: профилировщик кода и генератор тестов.
CoDeSys Application Composer
CoDeSys Application Composer напротив, ориентирован не на сложные научные проекты, а на повседневные прикладные задачи. В них решающими являются время создания проекта, простота процесса программирования и надежность итогового кода. При выполнении работ по автоматизации однотипных объектов, например умных домов или типографских машин, Application Composer позволит повысить производительность труда на два порядка.
Составление прикладного проекта выполняется на основе заранее подготовленных наборов прикладных программных модулей. Такой модуль может обслуживать определенную часть машины или системы. Например, это может быть пневматический цилиндр, автооператор, терморегулятор, либо программный блок управления доступом или конфигуратор сети. Каждый модуль включает программный код, конфигурацию входов/выходов, параметры и графическое представление для визуализации. Пользователь строит структуру своей системы управления, используя необходимые модули. Он определяет их настройки и связи в специальных редакторах. Затем интегрированные генераторы кода автоматически создают законченное, хорошо структурированное программное приложение на языках стандарта МЭК61131-3. Одновременно генерируется соответствующая визуализация. Программы компилируются и загружаются в контроллер. Пользователь может просматривать и корректировать полученный код при необходимости.
Рис. 4. Проект управления перекладчиком в Application Composer
Такой подход позволяет перейти от рутинного программирования к модульному проектированию прикладных проектов. Он открывает двери пользователям, хорошо знающим устройство машин, технологию соответствующего производства, но не владеющих программированием.
Благодаря своим отличным функциональным возможностям, надежности и открытым интерфейсам, CoDeSys стал лидером в области инструментов программирования ПЛК. Не случайно он выбран в качестве базового инструмента многими ведущими мировыми поставщиками аппаратных решений для промышленной автоматизации.
В мае 2012 г. в г. Смоленске проходила ежегодная конференция пользователей CoDeSys, на которой главный инженер Европейского отделения компании Hitachi господин Kenji Shimoda рассказал о переводе новых контролеров Hitachi с фирменного ПО на CoDeSys, занявшего немногим более 1 года. Это небольшой срок для разработки нового ПЛК с CoDeSys. Перевод включал собственно адаптацию, интеграцию с собственным ПО, тесты всего функционала на опытных ПЛК, написание руководства по применению и стартовых примеров, обучение дистрибьюторов. Типичный для некоторых конкурирующих МЭК систем подход ускоренной бюджетной установки с переносом части затрат и технических сложностей на плечи пользователей в CoDeSys принципиально не применим. Вы не встретите CoDeSys в ПЛК, собранных «на коленке». Это всегда будут продукты компаний, твердо стоящих на ногах и имеющих достаточно ресурсов на грамотный маркетинг, качественную разработку и сопровождение.
1. Jorn Linke. Der SPS-Benchmark: Das Ergebnis. Computer Automation. 2011. 9.
2. Дитер Хесс. Объектно-ориентированные расширения МЭК 61131-3 // Современные технологии автоматизации. 2006. №2.
Исследование безопасности: CODESYS Runtime — фреймворк для управления ПЛК. Часть 1
Исследование безопасности технологий, которые используются разработчиками систем автоматизации и имеют потенциал применения на промышленных объектах по всему миру, является одним из приоритетных направлений работы Центра реагирования на инциденты информационной безопасности промышленных инфраструктур «Лаборатории Касперского» (Kaspersky ICS CERT).
В этой статье мы продолжаем рассказ об исследовании популярных OEM-технологий, входящих в состав продуктов большого количества производителей. Уязвимости в таких технологиях с большой вероятностью сказываются на безопасности многих, если не всех продуктов, в которых они используются. Иногда это могут быть сотни продуктов, используемых на производстве и в критической инфраструктуре. Именно так обстоит дело с CODESYS Runtime ® — фреймворком для разработки и выполнения программ автоматизированного управления технологическим процессом от компании CODESYS.
Согласно официальной информации от компании-разработчика, CODESYS Runtime уже адаптирован для более чем 350 устройств от различных вендоров, которые используются в энергетики, промышленном производстве, системах интернета вещей и промышленного интернета вещей и т.д. Отметим также, что в реальности эта цифра значительно больше, так как устройства множества компаний, которые используют фреймворк CODESYS Runtime для своих ПЛК, не находятся в официальном списке. Количество таких устройств постоянно растет — в 2016 году их было всего 140, — и мы не будем удивлены, если оно продолжит расти и в будущем.
Фрагменты технической информации были удалены в связи с требованием CODESYS Group. Более подробную информацию можно запросить по адресу security@codesys.com.
Фреймворк
В современном мире использование готового программного кода в своем продукте — скорее правило, чем исключение. Это позволяет разработчикам нового продукта не заниматься «изобретением велосипеда» и сокращает время на разработку.
Степень влияния стороннего кода на использующий его программный продукт и степень влияния на безопасность системы, в которой этот продукт используется, может быть различной.
Сторонний код часто используется для реализации конкретной функции или набора функций, таких как, отрисовка изображения, отображение пользовательского интерфейса, печать на принтере или сохранение данных в БД. Мы уже проводили исследования безопасности и обнаруживали уязвимости в различном стороннем коде. Например, в 2017 году — для части программно-аппаратного комплекса контроля соблюдения лицензионных соглашений и защиты приложения от «взлома» SafeNet Sentinel, а в 2018 — для библиотеки OPC UA от OPC Foundation.
С фреймворком CODESYS ситуация другая: разработчик ПЛК на основе CODESYS адаптирует фреймворк для работы на своих аппаратных комплексах и разрабатывает при необходимости дополнительные модули, используя предоставляемые CODESYS сервисные функции. Конечный пользователь ПЛК (инженер) разрабатывает при помощи среды разработки CODESYS код программы автоматизации технологического процесса. И поток выполнения разработанных дополнительных модулей и программы автоматизации технологического процесса контролируется на ПЛК адаптированным под него вариантом CODESYS Runtime.
Контроль фреймворком потока программы означает, что использование фреймворка накладывает ограничения на уровне архитектуры — на этапе проектирования продукта. Иначе говоря, фреймворк представляет собой уже созданный сложный механизм,
а пользовательский код должен стать винтиком в этом механизме.
С точки зрения обеспечения безопасности при использовании фреймворка разработчику необходимо ответить на следующие вопросы:
Данная статья посвящена исследованию безопасности CODESYS Runtime. В ней мы дадим ответы на первые два вопроса: что происходит внутри этого фреймворка и как он работает. Также мы продемонстрируем один из способов обнаружения уязвимостей без возможности анализа исходного кода.
Описание объекта исследования: CODESYS Runtime
Прежде чем говорить о результатах исследования безопасности объекта, необходимо разобраться в том, что он из себя представляет. Техническое описание CODESYS Runtime, приведенное в этой главе, было сформировано нами в ходе его изучения.
Связка продуктов компании CODESYS Group
Компания CODESYS Group разрабатывает два основных продукта:
Оба продукта работают в связке. CODESYS Development System представляет собой IDE для разработки программ управления устройствами, на которых запущен CODESYS Runtime. В среду включено множество инструментов для упрощения процесса разработки и тестирования.
В контексте нашего исследования важно, что CODESYS Development System — это кастомизируемая среда разработки. На её основе созданы IDE SoMachine от компании Schneider Electric, TwinCAT от компании Beckhoff Automation, IdraWorks от компании Bosch, Wagilo Pro от компании WAGO, одноименные IDE CODESYS от компаний Owen, STW Technic, prolog-plc и другие IDE.
Для программирования контроллера с помощью IDE CODESYS Development System, на нем должен быть запущен CODESYS Runtime. Для корректного запуска CODESYS Runtime на конкретном устройстве его необходимо адаптировать под выбранную операционную систему и железо. Согласно информации на официальном сайте CODESYS, сами разработчики CODESYS адаптировали CODESYS Runtime только для 15 устройств. Дистрибьютерами же CODESYS Runtime был адаптирован для более чем 350 устройств.
Среди адаптированных CODESYS Runtime есть версии:
Архитектура
Компоненты
CODESYS Runtime основан на компонентно-ориентированной архитектуре, то есть представляет собой набор компонентов — модулей, на которые разделена каждая логическая или функциональная часть CODESYS Runtime.
Каждый компонент ответственен за свою задачу и область действия — например, отвечает за логирование, за сетевое взаимодействие, за взаимодействие по серийному кабелю, за распределенную нагрузку на ядрах, за отладку программы и т.д.
Компонентно-ориентированная архитектура CODESYS Runtime (источник)
Среди всех компонентов CODESYS Runtime можно выделить основные:
У разработчика есть несколько способов расширить CODESYS Runtime:
Структура компонентов
Компоненты CODESYS — это динамические библиотеки (аналог *.dll в ОС Windows и *.so в ОС Linux). Все компоненты загружаются компонентом Component Manager.
CODESYS Runtime может иметь статическую и динамическую сборку.
Если CODESYS Runtime имеет статическую сборку, то программный код компонентов содержится в самом исполняемом файле.
Если же CODESYS Runtime имеет динамическую сборку, то в конфигурационном файле указывается список загружаемых компонентов, а файлы компонентов находятся отдельно от исполняемого файла.
Структура самого файла компонента не являлась объектом данного исследования, однако можно с уверенностью сказать, что в этой структуре содержится:
Структура интерфейсов взаимодействия
Более интересным, чем структура файла компонента, для исследования является то, каким образом CODESYS Runtime взаимодействует с внешними компонентами, и как внутренние компоненты взаимодействуют друг с другом.
Каждый компонент обязан содержать следующие функции: функцию инициализации, функцию экспорта, функцию импорта, функцию обработки событий, функции удаления и создания своей сущности. Также компонент обязан иметь свой уникальный числовой идентификатор.
Функции удаления и создания своей сущности — опциональны. Они оказались пустыми для большинства компонентов. Поэтому мы не станем здесь их рассматривать. Остальные же функции будут рассмотрены далее.
Реализация функции инициализации
Функция инициализации — аналог entry point для PE и ELF файлов, с той лишь разницей, что непосредственную работу компонента она не начинает. Вызов этой функции осуществляется компонентом Component Manager.
Декомпилированный код функции инициализации компонента CmpBlkDrvUdp из группы Communication
Функция ModuleCmpBlkDrvUdp_entry — функция инициализации. Аргумент для этой функции структура INIT_STRUCT. Обычно эта функция вызывается с использованием Component Manager для заполнения структуры. Функция инициализации заполняет поля в структуре, среди которых — все вышеперечисленные функции и идентификатор компонента, который для компонента CmpBlkDrvUdp равен 7.
Реализация функции обработки событий
Следующая интересная функция — это функция обработки событий. Для компонента CmpBlkDrvUdp этой функцией является ModuleCmpBlkDrvUdp_hook. Эта функция определяет по полученному идентификатору события, что от неё требует выполнить Component Manager.
Идентификаторы основных событий:
Сравнение жизненного цикла работы компонента CODESYS с циклом работы динамически подключаемой библиотеки Windows (Dynamic Link Library)
События для обработки компонентом, как и события вызова DLL Windows, созданы «зеркальными» парами: [СH_INIT_SYSTEM — CH_EXIT_SYSTEM], [СH_INIT — CH_EXIT] и т.д.
Декомпилированный код функции ModuleCmpBlkDrvUdp_hook, в котором продемонстрирована обработка событий компонентом CmpBlkDrvUdp
На примере функции ModuleCmpBlkDrvUdp_hook видно следующее:
Реализация функций импорта и экспорта
Функция экспорта и функция импорта используют механизм, который в совокупности дает эффект работы экспортируемых и импортируемых функций в динамических библиотеках ОС Windows и Linux. Главная разница функций экспорта и импорта с библиотеками ОС Windows и Linux в том, что во время работы этих функций происходит регистрация экспортируемых функций и инициализация указателей на импортируемые функции.
Псевдо-код функции экспорта компонента CmpRasPi (есть исключительно в CODESYS Runtime for Raspberry PI)
Функция CMRegisterAPI использует в качестве первого аргумента указатель на заполненный массив, содержащий сведения об экспортируемых функциях, а в качестве последнего — идентификатор компонента. Для примера экспортируемой функции: на строке 10 есть заполненная структура exported_function с указателем на функцию sub_84e5bc0, именем функции “raspiyuv”, хешем 0xF81Fd05 и версией 0x3050400.
Таким образом компонент CmpRasPi предоставляет API для взаимодействия с модулем камеры на устройстве Rapsberry PI для всех остальных компонентов СodeSys и прикладных программ. Пример использования этого API продемонстрирован в примере проекта Camera.project для CODESYS Control for Raspberry Pi.
Код программы проекта Camera.project
Функция импорта в компонентах пытается найти функции, экспортируемые другими компонентами, и запомнить их местоположение.
Функция импорта модуля CmpApp
Функция CMGetAPI2 ищет функцию, которая была зарегистрирована другим компонентом. Первый аргумент — это имя функции, второй — значение, куда сохранить полученный указатель на функцию, третий — это ожидаемый хеш функции, если передается, и последний — ожидаемая версия.
Перед этим все эти функции были зарегистрированы компонентом SysTarget.
Фрагмент массива с экспортируемыми функциями
Механизм импорта и экспорта функций предоставляет разработчикам основную функциональность для создания собственных компонентов или расширения возможностей существующих.
Настройка компонентов
Механизм настройки компонентов демонстрирует, как работает часть архитектуры CODESYS Runtime. Поэтому он будет рассмотрен здесь как заключительная часть главы про архитектуру CODEYS Runtime.
Пользователю CODESYS Runtime предоставляется возможность управления компонентами через конфигурационный ini-файл. Конфигурационный ini-файл — это обычный текстовый файл, в котором находятся ключи и параметры для настройки компонентов.
Фрагмент файла конфигурации для CODESYS Control for Raspberry Pi
Component Manager инициализирует все компоненты. В первую очередь он инициализирует системные компоненты, такие как CmpMemPool, CmpLog, CmpSettings и SysFile и т.д.
Фрагмент лога запуска исполняемого файла CODESYS Control for Raspberry Pi
Среди системных компонентов есть компонент CmpSettings. Он интересен нам тем, что функция экспорта этого компонента регистрирует API, которыми пользуются все остальные компоненты для получения параметров из файла конфигурации.
Фрагмент массива экспортируемых функций компонента CmpSettings
Функции SettgGetIntValue и SettgGetStringValue используются большинством компонентов для определения параметров своей работы. По перекрестным ссылкам вызовов этих функций можно определить, какие компоненты могут быть настроены через файл конфигурации, и какие ключи необходимо указать в файле конфигурации.
Используя метод поиска вызовов функции SettgGetIntValue, по перекрестным ссылкам можно найти ключ DemoTimeUnlimited для настройки компонента ComponentManager:
Ключи настройки компонента ComponentManager
Адаптация
Возможность адаптировать CODESYS Runtime под любое железо и операционную систему — несомненно, главная его особенность. На разработчиках продукта с использованием фреймворка лежит ответственность по адаптации системных компонентов CODESYS Runtime под нужды и требования конкретного применения, включая тип технологического процесса. Адаптированный фреймворк CODESYS Runtime должен уметь взаимодействовать с аппаратными интерфейсами, Ethernet, освобождать и выделять память, работать с таймером, событиями, межпотоковым взаимодействием и т.д.
Системные компоненты из компонентно-ориентированной архитектуры CODESYS Runtime
Адаптация системных компонентов происходит путем экспортирования функций, которые требуют остальные компоненты (этот путь описан в предыдущей главе).
Проведя анализ нескольких вариантов CODESYS Runtime, мы выяснили, что системных компонентов всего 25.
Список основных системных компонентов:
После обеспечения работоспособности системных компонентов разработчик должен создать собственные модули CODESYS Runtime для ПЛК со специфичной функциональностью.
Реализация
В декабре 2016 вышла первая версия CODESYS Control for Raspberry Pi. В июне 2018 года — версия для Linux (CODESYS Control for Linux SL). Помимо этого, еще есть эмулятор CODESYS Control для Windows, который входит в пакет программ CODESYS Development System. Все эти реализации однотипны с реализацией CODESYS Control for Raspberry Pi и имеют схожие или полностью идентичные элементы реализации.
В этой главе мы рассказываем о реализации CODESYS Runtime на примерах CODESYS Control for Raspberry Pi и CODESYS Control for Linux SL.
Файл — установщик
Файл конфигурации
Файл конфигурации содержит огромное количество различных параметров конфигурации для CODESYS Control. По содержимому этого файла можно сделать следующие выводы:
Содержимое файла конфигурации CODESYS Control For Raspberry Pi v3.5.14.10
Исполняемый файл
Параметры защиты файла
Первичный анализ исполняемых файлов, как правило, включает в себя проверку опций компиляции на предмет установки параметров защиты. Инструмент checksec показывает эти значения параметров защиты для исполняемых файлов.
Результат обработки утилитой checksec исполняемых файлов CODESYS Control for Raspberry Pi v3.5.14.10
По результатам работы утилиты видно, что исполняемые файлы CODESYS Control for Raspberry Pi v3.5.14.10 были скомпилированы без дополнительной защиты, которая могла бы усложнить эксплуатацию бинарных уязвимостей.
Чуть лучше ситуация с компиляцией файла CODESYS Control for Linux SL, потому что в этом файле содержится установленная опция PIE.
Результат обработки утилитой checksec исполняемых файлов CODESYS Control for Linux SL v3.5.14.10
Состояние исполняемого файла
Статический анализ исполняемого файла с помощью инструмента IDA Pro показывает, что этот файл на 99% состоит из данных (зеленый цвет), а не из машинного кода:
Состояние запокованного исполняемого файла CODESYS Runtime For Raspberry Pi
Обычно такое состояние характерно для исполняемых файлов, машинный код которых был запакован. Тем не менее, для всех исполняемых файлов обязательным атрибутом является наличие точки входа (Entry point). Для исполняемого файла CODESYS Runtime for Raspberry Pi точкой входа является функция start. С этой функции можно начать анализ.
Ассемблированный код функции start
Код функции start нормально распознается, и IDA Pro подсказывает, что функция sub_86a0840, она же функция main, также содержит валидный программный код.
Декомпилированный псевдокод функции sub_86a0840
Иначе говоря, строка 5 готовит область памяти к распаковке и возможности выполнения программного кода в этом участке памяти. Затем вызывается следующая функция (строка 6) и в качестве аргумента передается указатель на участок памяти, которым является переменная dword_86A0460, – это указатель на оригинальную функцию main после распаковки.
Таким образом, для дальнейшего исследования файла необходимо его распаковать.
Запущенный процесс
CODESYS Runtime for Raspberry Pi и for Linux выполняет трассировку своего процесса, то есть CODESYS Runtime for Raspberry Pi и For Linux занимается отладкой самого себя. Данный механизм используется в двух случаях: для перехвата системных вызовов (syscalls) и для реализации простейшей защиты от отладки: к запущенному процессу CODESYS Runtime нельзя присоединиться, используя сторонние инструменты отладки, такие как gdb, IDA Pro, radare или же strace.
Трассировка
Запуск утилиты strace с ключом –f на исполняемый файл CODESYS Control For Raspberry Pi v3.5.14.00
Далее родительский процесс пытается возобновить работу остановленного дочернего процесса вызовом функции ptrace с аргументом PTRACE_CONT (строка 17). Дочерний процесс в это время выполняет ptrace с аргументом PTRACE_TRACEME (строка 20), обозначив этим, что этот процесс должен быть трассирован родительским процессом.
Однако, результат выполнения функции указывает на то, что процесс не может быть трассирован родительским процессом. Из-за этого дочерний процесс завершает свою работу (строки 21:22). После этого родительский процесс получает ответ от функции ptrace (строка 23) и узнает, что дочернего процесса уже нет в системе. Далее родительский процесс пытается еще раз обратиться к дочернему процессу (строка 28) и, снова не обнаружив его, завершает свою работу (строки 29:30).
На этом утилита strace завершает свою работу.
Отладка
Аналогичная ситуация возникнет, если попробовать запустить исполняемый файл под отладчиком gdb.
Запуск отладчика gdb на исполняемый файл CODESYS Control For Raspberry Pi v3.5.14.00
Для отладки дочернего процесса для gdb необходимо выставить соответствующий режим set follow-fork-mode child (строка 17). После этого запустить CODESYS Runtime (строка 18). Далее создается дочерний процесс (строка 22), и спустя некоторое время программа самозавершается (строки 26:27).
Таким образом, для исследования исполняемого файла после распаковки его нужно привести в состояние, способное к отладке.
Необходимо сказать, что существует возможность сэмулировать успешно созданный процесс трассировки файла, указав в качестве переменной окружения LD_PRELOAD библиотеку, которая будет содержать функции fork, ptrace, getppid и getsid. Однако на этом этапе это не будет иметь особой эффективности.
Потоки
CODESYS Runtime — многопоточное приложение. Помимо того, что запущенный процесс клонируется и выполняет трассировку дочернего процесса, дочерний процесс порождает огромное количество потоков. Системные утилиты Linux ps и htop получают список потоков, созданных процессом.
Получение списка потоков, порожденных процессом исполняемого файла CODESYS Control for Raspberry Pi v3.5.14.00
По результату выполнения утилиты ps и фильтрации вывода утилитой grep видно, что дочерний процесс имеет идентификатор 5405 (строка 03).
Результат выполнения команды htop для процесса 5405 (строка 06) выводит потоки, созданные дочерним процессом (строки 09:18).
Из имен потоков частично узнаются имена компонентов группы коммуникации (компонент BlkDrvTcp, компонент BlkDrvUdp), имя индустриального протокола OPC UA.
Сетевые коммуникации
По результатам работы утилиты netstat, CODESYS Runtime слушает следующие порты:
Список прослушивающих портов, открытых процессом исполняемого файла CODESYS Control for Raspberry Pi v3.5.14.00
CODESYS Runtime слушает как TCP, так и UDP порты. TCP порт 11740 (строка 2) используется для TCP-связи между CODESYS Runtime и CODESYS Development System.
UDP порт 1740 (строка 7) используется для этой же цели, только общение осуществляется по UDP-протоколу.
Также CODESYS Runtime слушает UDP порт 1740 на широковещательном адресе (строка 6). Широковещательные адреса на стороне клиентов обычно слушаются для возможности обнаружения этих клиентов серверами, т.е. в качестве discovery service. TCP порт 4840 (строки 4:5) используется в качестве discovery service OPC UA.
Информация в открытых источниках
Поиск информации в открытых источниках — неотъемлемая часть исследовательской работы. Нами было найдено:
К сожалению, вся обнаруженная документации датируется концом 2015 года. Однако её изучение было необходимо: несмотря на устаревшие версии документов, они дали множество подсказок на вопросы, которые возникали во время исследования протокола общения между CODESYS Development System и CODESYS Runtime.