В нынешних условиях на рынок России заходят новые производители оборудования, что является интересным событием и дарует много опыта. Я сегодня сходил, познакомился, вот теперь со своей колокольни пересказываю. В центре повествования производитель из Израиля - Unitronics.
Фирма производит: ПЛК, Панель+ПЛК, Частотники, Серводрайверы и сервопривода, коммутаторы. Чуть дольше остановим взгляд на ПЛК и Панель+ПЛК.
Камень внутри от фирмы NXP, если рассматривать Панель с плк, то там два МК. Рантайм ПЛК - Azure RTOS ThreadX, а панель - linux RT. Весь этот арсенал программируется, в основном, с помощь UniLogic.
Что мы получаем из коробки. Языки программирования - LD и C-function. Один основной цикл рабочей программы и на жирной комплектации ПЛК +1 цикл с частотой 1-5мс.
Протоколы взаимодействия из коробки: BACNet(лицензия на сервер), Modbus, Ethernet/IP, CANopen, EtherCAT(мастер, если купить модуль), визуальный конфигуратор посылок ASCII протоколов, MQTT, REST api(http/https), NMSP.
Панель и ПЛК, которые воедино, могут работать в разных сетях. В обычном плк, есть softHMI, которая открывается через VNS.
Есть SQL драйверы(mySQL, MSSQL, psql)
Включает модули расширения до какого-то там количества+ удаленные модули ввода-вывода. Имеет контроль управления движением с графическим конфигуратором механики и расчетом всех ограничений.
Среда разработки - включает в себя все, из-за этого выглядит пугающе, работает не совсем продуктивно, но это вкусовщина. Про качество и все такое я ничего сказать не могу, однако если у вас есть опыт, то прошу поделиться.
Я бы рассматривал это все для создания каких-то мелких и средних систем автоматизации, если у них будет адекватный ценник. Срок поставки - 6 мес.

Итан Чен - менеджер по продукции Moxa помогает сделать Выбор между открытыми или проприетарными решениями IIoT
Если коротко то выходит следующее: "Если требуется один производитель и железок мало, то берите проприетарное решение, если большой зоопарк, то не берите"(А возьмите шлюз Moxa)
Я бы рекомендовал смотреть в сторону решений для IIoT от фирм, которые не производят свои железки, а лишь предоставляют сервис, так как поднять свою собственную инфраструктуру, которая бы выходила за рамки сбор/хранение/отображение - сложный процесс.
Если очень хочется попробовать поиграть в индустрию 4.0, то могу предложить IoTCore от Яндекс с бесплатными лимитами и попытаться наладить отправку сообщений через него.

Смогут ли облачные и граничные решения заменить централизованное управление?
Если вам когда-то требовались аргументы в пользу облачных или граничных вычислений, то теперь она у вас есть, также как и против. На самом деле все сводиться к тому, что надо понимать какой инструмент подходит для какой задачи, а то будет как в той истории с молотком в руках.
Удобно применять облачные технологии и граничные вычисления, когда мы не связаны по времени и надежности, но где требуется большая вычислительная мощность или очень сложные алгоритмы. Всегда существует пересечения с граничными вычислениями, особенно если вы пытаетесь реализовать какую-то сложную логику на скаде. Технологии граничного и облачного вычисления могут снизить косты на определенные позиции, например хранения данных, а также дают доступ к современным технологиям.
Для связи с облаком требуется мост, которым могут стать граничные контроллеры, а они в свою очередь могут быть на базе ПЛК, где часть ядер будет задействовано под детерминированную логику, а другая часть ядер будет обрабатывать скриптики.
Не используйте для контроля облака и граничные вычисления там где требуетя надежность, отказоустойчивость и управление в реальном времени. НИКОГДА!
Да и в целом прочитайте статейку, это займет минут 15, но почитать взгляды различных людей из отрасли очень интересно.

Субботняя байка. Как я с коллегой сегодня воевали с РРГ 12 от Элтачприбора, подключенного по RS485, связь осуществляется по протоколу ModbusRTU. Запускаю объект, сегодня по плану надо было завести в программу ПЛК РРГ(регуляторы расхода газа) . Монтаж полевого оборудования делал подрядчик№2, по проекту, который делал другой подрядчик№1, монтажные панели собирал также подрядчик №1. И вот приехал я с ноутбуком на перевес.
Что может быть проще чем просто завести регистры в ПЛК 210 CS3 фирмы ОВЕН? Логика простая, заводим одну РРГ, меняю ей адрес, потом завожу вторую РРГ, ей тоже меняю адрес и после завожу оставшуюся. Вижу цель не вижу препятствий. Завел первую подключаюсь и вижу красный треугольник, а шина не поднялась. Уже наученные горьким опытом идем сразу в поле. Кабель -цель, концы не попутаны, все подключено согласно проекту, проверяем еще раз - результата ноль. Оказалось, что в проекте A,B забираются с пинов 5,6, а по документации 4,5 и такое возможно. Исправили подключение, завели заново ПЛК и... ничего... В документации дефолтное подключение 19200 бод, адрес 1. Вопросики остаются по битам, стоповым битам и четности, но мы берем позицию абсолютного дефолта 8,1,None.
Дальше в доке идет инфа о том, что есть вариант адреса 0 и тогда РРГ не будет отвечать, чтобы точно убедиться требуется подключиться по 232 через спец программу. Есть ли у меня адаптер. Ну разумеется... разумеется нет, но я вспоминаю, что в проекте идут два конвертера TCP/IP - RS232/485/422. Вот оно спасение подумал я, открываю софтину и понимаю, что она вот не умеет общаться через TCP/IP, но взгляд упал на поле Адрес устройства -3.
Вносим адрес 3 и все подключилось. Я конечно удивился необычному выбору стандартного адреса, но все же. Сменили адрес, подключаем вторую РРГ и отваливаются обе разом... Оказывается у второй РРГ стандартный адрес уже не 3, а 1... Пошаманили, поменяли адрес.
У последней РРГ стандартный адрес был 2. Как мы пришли к логическому заключению, что при заказе партии приборам для удобства просто вшили номера по порядку, чего я точно не могу ожидать.
Вывод - всегда отправляйте на объект паспорта устройств, возможно есть шанс, что там эта информация будет.

Продолжим дальше разбираться с граничными вычислениями. Все же для начала стоит определиться с терминологией.
Граничные вычисления — это распределенная вычислительная среда, которая приближает корпоративные приложения к источникам данных, таким как устройства IoT или локальные граничные серверы. Эта близость к данным в их источнике может обеспечить значительные преимущества для бизнеса: более быстрое понимание, улучшенное время отклика и лучшую доступность полосы пропускания.
Логично будет спросить, а зачем нам граничные вычисления, когда мы еще с облачными не разобрались. Все упирается в данные. С производства идет огромный поток данных, который формирует "озеро данных" и вот такое озеро нельзя на прямую слать в облака, так как это большая нагрузка, да и дорого, и смысла нет, а еще, судя по тому что я подслушал, многие производства бояться слать свои данные в облака, так как вдруг их кто-то прочитает. Ну и скорость обработки и доступа к информации в случае граничных вычислений гораздо выше.
Для хорошей работы граничных вычислений нам потребуется:
1) Процессы сокращения данных. Используя процессы сокращения данных, провайдеры могут существенно минимизировать требования, необходимые для хранения данных. Прореживание данных значительно оптимизирует хранение и помогает организациям сократить расходы.
2) Подключение 5G для периферийных вычислений.
3) Туманные вычисления - это то, где децентрализованная вычислительная инфраструктура используется в граничных вычислениях.
В ответ на все это граничные вычисления нам предлагают:
1) Более быстрое и всестороннее понимание данных и аналитика.
2)Улучшенное время отклика, учитывая, что убран один слой приема-передачи данных(облако), а безопасность находится на переднем крае.
3)Лучшая доступность полосы пропускания, поскольку источник данных(датчики, плк, IIoT устрйоства) находится прямо возле граничных серверов или максимально близко.
Ну и по минусам. Это все же сложно обосновать, требуется дополнительное оборудование для периферии, новый пул навыков, что тоже немного тормозит внедрение.
@wtfcontrolsengineer

Вечерние интересности. И да-да у нас неделя граничных вычислений. На этот раз да же на русском языке.Настоящие периферийные контроллеры: какие они?
Автор статьи хочет нам рассказать за edge- контроллеры, которые на своем борту имеют как ОСРН(операционную систему реального времени) с детерминизмом и управлением процессом, а также ОСОН(операционная система общего назначения), которая бы занималась бы вычислениями и коммуникациями.
Под это описание идеально заходит ПЛК2xx от ОВЕН))
Как в моем понимание, то пограничный контроллер, это такой аппаратный продукт, который должен идеально подходить для OEM решений, когда у интегратора нет возможности поднимать инфраструктуру на месте, а расширенный функционал нужен.
На моей памяти, такое решение я предлагал для компьютерного зрения, когда уже обученная нейронка крутилась на какой-то внятной ОС, а за управление оборудованием отвечал runtime.
Также в статье упоминаются различные базы данных и контейнеризация и много чего еще, вот с этим я очень не согласен, но и такие решения возможны. Если мы хотим получать доступ к архиву нашего оборудования при отсутствии возможности отправки данных в более подходящее место.
Ну и самый хороший аспект в статье - гипервизор реального времени для таких решений, чтоб у нас если обычная ос отвалится, то производство не встало. Примером всего послужили Emerson PACSystems.
Но даже если у вас есть только плк который может в modbusTCP и есть возможность воткнуть в сеть одноплатник, то можно уже радоваться и тестировать различные граничные решения

Коллеги, вечер добрый. У меня к вам есть очень интересный вопрос, считайте мини исследование для тех, кто является наемным работником в сфере АСУТП. Как звучит ваша должность; когда вы устраивались, то чем предполагали заниматься и чем занимаетесь по факту?

Мне очень не хватает)

Очень люблю статьи с практическими кейсами. Даже если мне это не пригодиться, но я всегда могу подчерпнуть какие-нибудь идеи.
https://habr.com/ru/company/severstal/blog/676990/
Хорошая статья от Северсталь, где рассказывают про то, как они организовали ТОиР. Основную мысль, которую я подчеркнул, что MVP может работать и в экселе.

Я немного этот момент пропустил, а давно?
https://www.arduino.cc/pro/

А че так можно было???

Пока у меня тут череда ПНР, а интересных новостей мне в глаза не попадается, то разрешите спросить, а кто в курсе за IEC 61499?

Накидал небольшой список производителей отчественного оборудования. В скором времени буду дополнять. Если есть кого добавить кидайте ссылки в комментарии.

https://blog.engcore.ru/spisok_proizvoditelei_rossiskogo_oborudovania/

Всем же уже понятно, что граничные вычисления будут применяться в промышленности так как без них никуда. Все же ПЛК - это за надежность и детерминируемость, но не за производительность, а современные тенденции бережливого производства требуют больших расчетов.
И тут на сцену выходят "истино периферийные" контроллеры. В статье рассказывается за симбиоз ПЛК и граничных вычислений на одной железке, где существует ОСРВ и основная ОС, которая как-то может получать данные из системы реального времени по защищенным каналам связи и все это должно быть определенно программно.
Теперь субъективное мнение меня. Системы в которых есть смысл использовать граничные вычисления, мощность которых базируется на том же железе, что и контроль технологии производства имеет смысл лишь в ограниченных условиях. К примеру, когда мы поставляем юнит на производство, где мы нет граничных вычислений или персонал не может поднять такие процессы.

У меня появилось очень много вопросов...
Немецкий производитель
Овен

Пойдемте немного поработаем с сокетами в Codesys
https://youtu.be/p-Dl7GkRWV8