Собирал на hh.ru. Java и PHP не объединялись, просто среднее значение обеих выборок получилось одинаковым.
График показывает зарплаты всех вакансий с открытой вилкой, где язык указан в названии.
Состав выборок разный. В Java есть джуны, а в Kotlin их вообще нет. В C++ 39 из 52 вакансий, а в Go 26 из 32 относятся к сеньорам. Отсюда и большой разрыв.
Вы говорите о разработке собственной embedded-платформы, а я об эксплуатации готового контроллера на заводе. Это совершенно разные вещи.
Асушник из эксплуатации никогда не будет самостоятельно лезть в контроллер и менять runtime, драйверы или прошивку. Зачастую у него нет ни исходников, ни необходимых компетенций, ни разрешения это делать. За такие дела ему руководство просто надает по рукам))
А Linux дает ему возможность в разрешенных производителем рамках добавить свои приложения, не вмешиваясь во внутреннее устройство контроллера.
Кажется, мы говорим немного о разных вещах. Я не утверждаю, что RTOS не поддерживает загружаемые модули или что приложения под Linux не нужно тестировать.
Просто в таких открытых контроллерах есть штатный PLC-runtime производителя, внутри которого циклически выполняется IEC 61131-3-программа. Пользователь может менять проект ПЛК, но не пересобирает сам runtime или прошивку контроллера, чтобы добавить, например, web-интерфейс, архивирование или новый сервис обмена.
Дополнительные пользовательские приложения работают в отдельной Linux-среде и взаимодействует с PLC-runtime через предусмотренный производителем API, общую память или промышленный протокол. При этом само пользовательское Linux-приложение можно отдельно установить, обновить или удалить.
Преимущество Linux здесь в том, что для некритичных задач пользователь получает знакомую среду, стандартные библиотеки и инструменты, не вмешиваясь в реализацию PLC-runtime. RTOS тоже позволяет построить такую архитектуру, но обычно она сильнее зависит от SDK и механизмов конкретного производителя.
Кажется, вы не до конца понимаете, в чем здесь основная идея... Речь не о том, что OPC UA, web-интерфейс или база данных могут работать только на Linux.
Просто в RTOS они становятся частью общей прошивки. И для добавления новой функции ее нужно пересобрать, загрузить и заново протестировать. В открытом Linux-контроллере пользователь может устанавливать, обновлять и удалять отдельные приложения уже в процессе эксплуатации, не пересобирая основную прошивку и PLC-проект.
Например, можно позднее добавить преобразование Modbus RTU в OPC UA. Или установить локальный web-интерфейс, архив данных и тп. Если задача изменилась, эти приложения можно заменить или удалить.
Получается , что главное преимущество - возможность самостоятельно расширять функциональность контроллера на протяжении его жизненного цикла.
Это не совсем мое решение)) Но если мы об этом заговорили, то ctrlX CORE поддерживает задачи от 125 мкс, PLCnext AXC F 3152 - от 500 мкс, а у ОВЕН ПЛК210 время пустого цикла кажется 3 мс. При этом Linux-приложения в жестком цикле не участвуют, за него отвечает PLC-runtime.
По поводу приложений я написал ниже в комментариях. Но дело не в самом питоне, а в том что на нем можно написать свой драйвер, например, для преобразования протоколов и запустить под Linux. Можно БД установить - SQLite или InfluxDB, например.
Например, есть небольшая локальная система, для которой устанавливать отдельную SCADA слишком дорого и нецелесообразно. PLC-runtime управляет насосами, клапанами или вентиляцией, а Linux:
записывает параметры в базу данных, например SQLite или InfluxDB;
показывает их через web-интерфейс или дашборд в какой-нибудь Grafana;
обрабатывает данные и передает их в смежные системы (SCADA, MES или облачный сервис).
Еще один вариант - преобразование протоколов. Контроллер, например, читает данные по Modbus-RTU, обрабатывает их в приложении на Python или C++ и передает дальше по OPC UA.
С первой частью согласен. Для 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-проекта. В этом смысле контроллер может быть программно расширяемым, оставаясь аппаратно проприетарным.
А проблемы с драйвером AllenBradley не было?) У нас такая проблема возникла, после добавления 1000+ тегов драйвер просто встал) Пришлось с помощью костылей оперативно решать эту проблему.
А какую Low-Code платформу использовали? Обучали, используя данные одного конкретного производства или нескольких? Было бы интересно увидеть пример рекомендаций, которые система выдает...
Собирал на hh.ru. Java и PHP не объединялись, просто среднее значение обеих выборок получилось одинаковым.
График показывает зарплаты всех вакансий с открытой вилкой, где язык указан в названии.
Состав выборок разный. В Java есть джуны, а в Kotlin их вообще нет. В C++ 39 из 52 вакансий, а в Go 26 из 32 относятся к сеньорам. Отсюда и большой разрыв.
Пример вакансий из выборки:
Java - 200–300 тысяч на руки
PHP - 200–350 тысяч на руки
C++ - 250–350 тысяч на руки
Kotlin - 200–260 тысяч на руки
Go - 250–350 тысяч на руки
Вы говорите о разработке собственной embedded-платформы, а я об эксплуатации готового контроллера на заводе. Это совершенно разные вещи.
Асушник из эксплуатации никогда не будет самостоятельно лезть в контроллер и менять runtime, драйверы или прошивку. Зачастую у него нет ни исходников, ни необходимых компетенций, ни разрешения это делать. За такие дела ему руководство просто надает по рукам))
А Linux дает ему возможность в разрешенных производителем рамках добавить свои приложения, не вмешиваясь во внутреннее устройство контроллера.
Кажется, мы говорим немного о разных вещах. Я не утверждаю, что RTOS не поддерживает загружаемые модули или что приложения под Linux не нужно тестировать.
Просто в таких открытых контроллерах есть штатный PLC-runtime производителя, внутри которого циклически выполняется IEC 61131-3-программа. Пользователь может менять проект ПЛК, но не пересобирает сам runtime или прошивку контроллера, чтобы добавить, например, web-интерфейс, архивирование или новый сервис обмена.
Дополнительные пользовательские приложения работают в отдельной Linux-среде и взаимодействует с PLC-runtime через предусмотренный производителем API, общую память или промышленный протокол. При этом само пользовательское Linux-приложение можно отдельно установить, обновить или удалить.
Преимущество Linux здесь в том, что для некритичных задач пользователь получает знакомую среду, стандартные библиотеки и инструменты, не вмешиваясь в реализацию PLC-runtime. RTOS тоже позволяет построить такую архитектуру, но обычно она сильнее зависит от SDK и механизмов конкретного производителя.
Кажется, вы не до конца понимаете, в чем здесь основная идея... Речь не о том, что OPC UA, web-интерфейс или база данных могут работать только на Linux.
Просто в RTOS они становятся частью общей прошивки. И для добавления новой функции ее нужно пересобрать, загрузить и заново протестировать. В открытом Linux-контроллере пользователь может устанавливать, обновлять и удалять отдельные приложения уже в процессе эксплуатации, не пересобирая основную прошивку и PLC-проект.
Например, можно позднее добавить преобразование Modbus RTU в OPC UA. Или установить локальный web-интерфейс, архив данных и тп. Если задача изменилась, эти приложения можно заменить или удалить.
Получается , что главное преимущество - возможность самостоятельно расширять функциональность контроллера на протяжении его жизненного цикла.
Это не совсем мое решение)) Но если мы об этом заговорили, то ctrlX CORE поддерживает задачи от 125 мкс, PLCnext AXC F 3152 - от 500 мкс, а у ОВЕН ПЛК210 время пустого цикла кажется 3 мс.
При этом Linux-приложения в жестком цикле не участвуют, за него отвечает PLC-runtime.
По поводу приложений я написал ниже в комментариях. Но дело не в самом питоне, а в том что на нем можно написать свой драйвер, например, для преобразования протоколов и запустить под Linux.
Можно БД установить - SQLite или InfluxDB, например.
Например, есть небольшая локальная система, для которой устанавливать отдельную SCADA слишком дорого и нецелесообразно. PLC-runtime управляет насосами, клапанами или вентиляцией, а Linux:
записывает параметры в базу данных, например SQLite или InfluxDB;
показывает их через web-интерфейс или дашборд в какой-нибудь Grafana;
обрабатывает данные и передает их в смежные системы (SCADA, MES или облачный сервис).
Еще один вариант - преобразование протоколов. Контроллер, например, читает данные по Modbus-RTU, обрабатывает их в приложении на Python или C++ и передает дальше по OPC UA.
С первой частью согласен. Для 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-проекта. В этом смысле контроллер может быть программно расширяемым, оставаясь аппаратно проприетарным.
А проблемы с драйвером AllenBradley не было?) У нас такая проблема возникла, после добавления 1000+ тегов драйвер просто встал) Пришлось с помощью костылей оперативно решать эту проблему.
А какую Low-Code платформу использовали? Обучали, используя данные одного конкретного производства или нескольких? Было бы интересно увидеть пример рекомендаций, которые система выдает...