Comments 15
Да уж и времена когда для подключения к AWS по MQTT, OPC UA или WEB сервер нужен был Линукс тоже прошли.
Сейчас это достаточно легко делается на обычной легковесной RTOS типа ThreadX
или FreeRTOS.
Современные агенты за пару дней перенесут все нужные стеки на RTOS включая навороченные GUI и базы данных.
Кстати, ПЛК типа WAGO PFC200 не делают на одном процессорном чипе.
Вот у меня такой один убитый лежит :
Тут как минимум два SoC и две разные операционки. И по ходу есть место еще для одного SoC
Убить такие контроллеры достаточно легко. Программа выполняется из DDRAM, грузится из NAND. Куча мест где что-то может пойти не так.
Но они никогда не станут открытыми, потому что в них всегда есть какой нибудь кастомный чип на шине. Их межмодульная шина - самый большой секрет. Проблема еще в том что программу хранимую вне SoC гораздо труднее защитить. А в Европе, к примеру, вступает в силу Cyber Resilience Act. И с ним сделать защиту Линукса ох как нелегко. Придется возится с Trusted Firmware-A или с OP-TEE. А иначе не дадут разрешение на использование нигде.
А с обычным микроконтроллером прожег фьюзы и все! Дело сделано.
Поэтому на мой взгляд надежней ПЛК будет на SoC с интегрированной Flash и RAM с Error-Correcting Code.
Таких сейчас достаточно много дешевых: RP2354 , ESP32-P4 , RA8P1 , STM32N657 ...
Вот за ними-то и вижу перспективы. И дёшево, и надёжно.
С первой частью согласен. Для MQTT, HTTP и даже OPC UA Linux сегодня и правда не обязателен. Все это можно сделать на FreeRTOS, ThreadX и других RTOS. Но преимущество Linux-контроллера не в наличии MQTT или web-сервера, а в том что можно устанавливать дополнительные приложения независимо от основной прошивки. На RTOS это тоже можно сделать, но потребуется пересборка, тестирование и обновление всей прошивки.
По поводу PFC200. WAGO пишет про Cortex-A8 и один real-time Linux с PREEMPT_RT, внутри которого работает CODESYS runtime. Инфы про два SoC и две ОС не видел.
Касаемо "открытости". Под "открытым" в статье понимается не полностью открытая аппаратная схема или межмодульная шина, а возможность штатно запускать собственные приложения вне PLC-проекта. В этом смысле контроллер может быть программно расширяемым, оставаясь аппаратно проприетарным.
Но какие приложения?
Можете назвать что нибудь стоящее, кроме питона , Node-RED, Arduino и прочих интепретаторов-прокладок, необходимость в которых полностью отпадает при наличии агентов прямо пишущих на C.
С вашим понятием "открытости" и Windows можно назвать полностью открытой операционкой.
Потом интересно какой минимальный период цикла поддерживает ваше решение на Линуксе?
На обычном микроконтроллере 240 МГц нормально держать жесткий цикл в 100 и меньше мкс.
Это не совсем мое решение)) Но если мы об этом заговорили, то ctrlX CORE поддерживает задачи от 125 мкс, PLCnext AXC F 3152 - от 500 мкс, а у ОВЕН ПЛК210 время пустого цикла кажется 3 мс.
При этом Linux-приложения в жестком цикле не участвуют, за него отвечает PLC-runtime.
По поводу приложений я написал ниже в комментариях. Но дело не в самом питоне, а в том что на нем можно написать свой драйвер, например, для преобразования протоколов и запустить под Linux.
Можно БД установить - SQLite или InfluxDB, например.
ctrlX CORE это 64 Bit Quad-Core ARM CPU и 2 Гб RAM
И все ради каких-то 125 мкс
И вы хотите сказать, что будущее вот такое - дорогущие платформы на избыточном софте?
Я же думаю :
Там все это только лишь от того, что код был по любому дороже.
А теперь когда код стал дёшев, они разорятся на таких монстрах.
а какие примеры приложений на контроллере с линуксом? ну там веб-интерфейс или что-то для визуализации, просто интересно какие задачи решает линукс в таком встроенном окружении
Например, есть небольшая локальная система, для которой устанавливать отдельную SCADA слишком дорого и нецелесообразно. PLC-runtime управляет насосами, клапанами или вентиляцией, а Linux:
записывает параметры в базу данных, например SQLite или InfluxDB;
показывает их через web-интерфейс или дашборд в какой-нибудь Grafana;
обрабатывает данные и передает их в смежные системы (SCADA, MES или облачный сервис).
Еще один вариант - преобразование протоколов. Контроллер, например, читает данные по Modbus-RTU, обрабатывает их в приложении на Python или C++ и передает дальше по OPC UA.
SQLite, OPC UA, Modbus-RTU уже давно портированы на RTOS для мелких контроллеров. Им Линукс не нужен от слова совсем.
InfluxDB - требует от 1 Гб RAM-а , это не про Линукс, а про масштаб.
Python и Grafana - в embedded лишние надсройки. ИИ агенты теперь делают графики в каком угодно стиле и формате вообще не привлекая сторонние тулсы на голом css и js
Конверетеры протоколов однозначно на RTOS будут работать быстрее и детерминирование
Подключаться к облакам теперь умеет любой ESP. А Amazon специально для FreeRTOS сделал модуль подключения к AWS. В ThreadX есть спецально под нее модуль подключения к Microsoft Azure IoT. И там есть всё: апгрейд прошивки по воздуху , автоматическое развертывание миллионов дивайсов, телеметрия, управление по MQTT и проч.
Кажется, вы не до конца понимаете, в чем здесь основная идея... Речь не о том, что OPC UA, web-интерфейс или база данных могут работать только на Linux.
Просто в RTOS они становятся частью общей прошивки. И для добавления новой функции ее нужно пересобрать, загрузить и заново протестировать. В открытом Linux-контроллере пользователь может устанавливать, обновлять и удалять отдельные приложения уже в процессе эксплуатации, не пересобирая основную прошивку и PLC-проект.
Например, можно позднее добавить преобразование Modbus RTU в OPC UA. Или установить локальный web-интерфейс, архив данных и тп. Если задача изменилась, эти приложения можно заменить или удалить.
Получается , что главное преимущество - возможность самостоятельно расширять функциональность контроллера на протяжении его жизненного цикла.
Просто вы почему-то странно заостряете внимание на "пересобрать, загрузить и заново протестировать".
Как будто в Линуксе не нужно загружать и тестировать. Пересобрать да, если у вас скрипты, то не нужно. Но и реальное время тогда вам не светит.
А если мне не нужно реального времени, то я и планшет могу приспособить под ПЛК и даже терефон. Т.е. это это уже не совсем ПЛК.
Пересборка под RTOS длится секунды.
Не надо думать что подгружаемые исполняемые модули есть только в Линуксе. В ThreadX также есть механизм подгрузки исполняемых модулей. Это не какая-то магия, а довольно примитивный процесс.
И под RTOS можно все подключть позднее. Или хотитет сказать, что изучить сам API Modbus RTU и все опции запуска и их влияние вы под Линуксом быстрее сделаете? Да нет, вы это сделаете это медленнее. Потому что имеете там меньше инструментов отладки реального времени. Потому что вы лишаетесь сквозной отладки.
В жестком реальном времени нужна сквозная отладка от момента вызова файловой операции и до выдачи команды CMD52 на интерфесе SDIO. Иначе месяцами будете ждать ответа вендора и ручками бегать сбрасывать свой контроллер.
В RTOS я могу через трассировку в SWD видеть не то что все вызовы, а все потоки прерываний в реальном времени и не использовтаь при этом никакого инструментального кода.
Про архивы вообще бы не говорил. У вас там такая же SD карта, как и в RTOS. Но ваш драйвер этой карты не вылизан так как они вылизаны под RTOS. Не согласованы каналы DMA, не выставлены приоритеты у этих каналов, не очищено все от избыточности косвенных вызовов и абстракций, не убраны избыточне объекты синхронизации и т.д. и т.п.
Кажется, мы говорим немного о разных вещах. Я не утверждаю, что RTOS не поддерживает загружаемые модули или что приложения под Linux не нужно тестировать.
Просто в таких открытых контроллерах есть штатный PLC-runtime производителя, внутри которого циклически выполняется IEC 61131-3-программа. Пользователь может менять проект ПЛК, но не пересобирает сам runtime или прошивку контроллера, чтобы добавить, например, web-интерфейс, архивирование или новый сервис обмена.
Дополнительные пользовательские приложения работают в отдельной Linux-среде и взаимодействует с PLC-runtime через предусмотренный производителем API, общую память или промышленный протокол. При этом само пользовательское Linux-приложение можно отдельно установить, обновить или удалить.
Преимущество Linux здесь в том, что для некритичных задач пользователь получает знакомую среду, стандартные библиотеки и инструменты, не вмешиваясь в реализацию PLC-runtime. RTOS тоже позволяет построить такую архитектуру, но обычно она сильнее зависит от SDK и механизмов конкретного производителя.
Знаете, CODESYS ведь изначально был сделан под микроконтроллеры с RTOS, а не Линукс. И да, там изначально пользоваетель грузил приложения не пересобирая runtime.
Пересобирать runtime или нет - это очень мелкий ворос.
У меня к примеру сейчас приложение из пары тысяч файлов , они состовляют фреймворк общий для кучи проектов. Я мог бы спокойно его изолировать и сделать из него такой отдельный модуль.
Но мне это не нужно. Зачем мне от себя что-то изолировать?
Я его перекомпилирую каждый день вместе с прикладным кодом.
Благодаря этому он у меня теперь проверен вдоль и поперёк, при любых уровнях оптимизации , при любых раскладах памяти.
А если вы держите runtime как священную корову, к ней не прикасаясь, то сами себя лишаете гибкости.
Кто решил что такой runtime эффективен? Тот кто даже не видел ваши задачи! Нет, runtime можно и должно менять. Теже протоколы, они постоянно меняются. А ведь они в runtime. К кому бежите чтобы там поменять пару команд?
Так что аргумент "зато мы не трогаем runtime" ну совсем не катит.
А некритичным задачам так и вовсе ПЛК не нужен. Он и дорог, и место занимет и потребляет как не в себе.
WEB сервер по HTTPS и всеми поддержками сертификатов у ThreadX не хуже чем в Линуксе.
И еще момент.
В WAGO PFC200 runtime c CODESYS единолично захватывает драйвер шины клемников K-Line. Свое приложение либо должно отключить CODESYS чтобы забрать драйвер и само организовать цикл, либо в runtime химичить мост. И опять ваше утверждение про "зато мы не трогаем runtime" не катит.
Тут еще прикол буквально сейчас я схватил. Claude Fable отказывается работать с исходниками, где просишь сделать защиту доступа к контроллеру.
Т.е. теперь trust zone в Линуксе вне закона для простых смертных. Это еще один повод не лезть в системы с внешними носителями кода.
Вы говорите о разработке собственной embedded-платформы, а я об эксплуатации готового контроллера на заводе. Это совершенно разные вещи.
Асушник из эксплуатации никогда не будет самостоятельно лезть в контроллер и менять runtime, драйверы или прошивку. Зачастую у него нет ни исходников, ни необходимых компетенций, ни разрешения это делать. За такие дела ему руководство просто надает по рукам))
А Linux дает ему возможность в разрешенных производителем рамках добавить свои приложения, не вмешиваясь во внутреннее устройство контроллера.
без критики, личное мнение.
В любом деле главный принцип - не усложнять систему. Чем больше времени проходит с 22 года, тем больше уважаю свои машины на промодулях конца 80х годов.
Всё оборудование из нового, что через скада и облако работают, всё это постоянно требует манипуляций с прошивками и прочими багами.
ПЛК перестает быть закрытой коробкой. Зачем контроллеру Linux?