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

Если бы не пару другую тестовых проектов, то я бы точно не вспомнил как открывать сокет) К итогу часового стрима мы можем коннектится к TCP серверу и больше ничего))) В следующий заход разберемся с приемом и передачей данных.
Если кому требуется TCP сервер со стрима, то он во вложении. Работает исключительно на 64 битной винде.(порт 7001)

Дамы и господа, прошу обратить ваш взор на еще одного предстаивтеля линейки виртуального производства. Стоит отметить, что это не цифровой двойник, но вещь весьма полезная для развития. На борту имеет месячный триал, чтобы вдоволь ознакомится с продуктом. Публикую насмотренности для.
https://simumatik.com/

Дальше работаем с сокетами. Часть вторая
https://youtu.be/SFPiyti5sOg

Тут в июне месяце прошло событие ROKLive от Rockwell Automation и Plex Systems и на базе этого мы получили 15 советов по автоматизации
1. Разработайте эффективную стратегию киберустойчивости.
От себя добавлю: Пожалуйста. Закройте уже 502 порты что смотрят наружу, не используйте ПО для взлома паролей на ППО ПЛК. Просто немного подружитесь с методами шифрования.
2. Производители оригинального оборудования (OEM) могут добиться большей рентабельности, производительности и удовлетворенности клиентов.
И тут очень тонкий аспект цирофвой трансформации. Сроки поставок теперь дольше, а сроки реализации проекта меньше. Ошибки теперь стоят дороже.
3. В водоснабжении и водоотведении инициативы по устойчивому водоснабжению стимулируют использование интеллектуальной автоматизации для промышленных пользователей и водоканалов.
4. Устойчивое развитие, экология, социальная ответственность и управление (ESG) приобретают все большее значение для производства
5. Кризис цепочки поставок продолжает сжимать управление операциями для производителей продуктов питания. Кроме того, частые новые рецепты, новая упаковка и новые ограничения требуют от производителей продуктов питания постоянного и частого переосмысления бизнес-процессов.
6. Наблюдение за операциями в режиме реального времени помогает в инициативах по постоянному совершенствованию.
От себя: Стоит отметить, что в такие системы входят как различные инструменты с аналитикой, так и грамотный интерфейс оператора помогает в таких задачах. Вот вам статейка, которую если переосмыслить, то выйдет идеально.
7. Предоставьте удаленным операторам возможность повысить производительность труда.
8. Собирайте данные об операционных процессах для лучшей аналитики и управления данными
9. Искусственный интеллект (ИИ), применяемый в автоматизации, помогает предприятиям увеличить автономность операций
10. Цифровая трансформация делает производство более разумным и своевременным. Бедствия в виде нехватки квалифицированных рабочих, сбоев в цепочке поставок и снижения рисков бросают вызов нормам производства.
11. Повышайте маржу за счет строгости операций и визуализации данных.
Меньше отходов, меньше брака, меньше простоя производственных линий
12. Преобразуйте производство с помощью цифрового двойника.
13. Виртуальный ввод в эксплуатацию использует программное обеспечение для 3D-эмуляции, чтобы сделать цифровую инженерию более продуктивной. Программное обеспечение может помочь в разработке и отладке управляющего кода еще до создания автоматизированного оборудования.
14. Упрощение управления жизненным циклом активов.
Знаете ли вы, когда активы приближаются к концу жизни? Когда они нуждаются в исправлении? Какие активы, версии, серии и программное обеспечение есть на заводе?
15. Программное обеспечение для автоматизации процессов может решить проблему нехватки квалифицированной рабочей силы. Производителям во всем мире становится все труднее находить квалифицированных работников, что приводит к незаполненным рабочим местам и высоким затратам на обучение.
@wtfcontrolsengineer
#post #OT #АСУТП