Блокчейн в промышленности. И эта статья показывает как одну из острых проблем можно решить современными средствами. Дайте знать если бы вы хотели узнать чуть больше про блокчейны и что это такое вне контекста криптовалют.
И так Прозрачная система отслеживания активов для управления цепочками поставок с использованием блокчейна. В моей голове была мысль, а как организовать систему поставок так, чтобы и менеджеров задействовать по минимальному, и сроки были более реалистичны и чтобы не было простоя в оборудования. Тут конечно влетала мысль об Индустрии 4.0, сборе метрик с производства и передача в ERP, где бы и должны были создаваться запросы на покупку нужных позиций от поставщиков, которые готовы предоставить данные о производимой продукции и складских запасов ну и так далее.
Теперь нам предлогают использовать блокчейн для хранения и обмена всей информацией, связанной с контрактами на перевозку, местонахождением в реальном времени, климатическими условиями, транспортировкой и обработкой физических активов, тем самым создавая единый источник достоверной информации, доступный для всех заинтересованных сторон. систему и устранение потенциальных проблем, таких как несвоевременная сверка, ненадлежащее обращение с активами и т. д.
Структура состоит из следующих шести основных шагов:

1. Онбординг заинтересованных сторон по отслеживанию активов. Подготавливается блокчейн консорциума, и администратор рассылает заинтересованным сторонам сети грузовых перевозчиков приглашения присоединиться к системе. После создания учетной записи и входа в систему каждая заинтересованная сторона генерирует децентрализованный идентификатор (DID) и сохраняет соответствующий документ DID в блокчейне.
2. Переговоры по договорам перевозки и архивирование. Все контракты на фрахт (например, соглашения с брокерскими перевозчиками, тендеры на погрузку, согласование тарифов, коносаменты) обсуждаются в автономном режиме между заинтересованными сторонами, а хэши цифровых версий этих контрактов на фрахт фиксируются в блокчейне для безопасного ведения журнала и целей аудита. В частности, соглашения об уровне обслуживания между заинтересованными сторонами записываются в смарт-контракты и развертываются в блокчейне.
3. Безопасная адаптация пограничных устройств . Как только безопасное пограничное устройство включается в первый раз, оно генерирует пару закрытый/открытый ключ в защищенном оборудовании и регистрирует открытый ключ в блокчейне посредством децентрализованного процесса подключения безопасного устройства. Затем зарегистрированный открытый ключ используется для проверки данных датчика в сети с помощью смарт-контрактов.
4. Отслеживание активов в режиме реального времени . Когда актив перемещается по сети грузовых перевозчиков, безопасное пограничное устройство фиксирует его статус в режиме реального времени (например, местоположение, температуру, влажность) и подписывает его с помощью закрытого ключа. В зависимости от местоположения актива подписанный статус актива затем отправляется в конкретный смарт-контракт для проверки SLA(соглашения об уровне обслуживания ).
5. Автоматический расчет штрафа . В случае нарушения SLA смарт-контракт генерирует специальное событие в блокчейне. Как только событие будет зафиксировано корпоративными сетями соответствующих заинтересованных сторон, штрафные санкции будут автоматически урегулированы между заинтересованными сторонами, участвующими в соглашении об уровне обслуживания.
6. Создание цепочки поставок . Заинтересованные стороны отправляют транзакции в блокчейн, когда актив находится у них на хранении. Каждая транзакция инкапсулирует стандартизированное событие EPCIS, описывающее, что произошло с активом. Все события EPCIS, которые записываются в блокчейн и передаются всем заинтересованным сторонам, устанавливают цепочку хранения актива в цепочке поставок.

На волне прошлых споров и настроения для

Шикарный лонгрид на 51 страницу с историей создания OwenVisuDialogs от Евгения Кислова.
https://ftp.owen.ru/CoDeSys3/98_Books/OwenVisuDialogsHistory.pdf

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

В нынешних условиях на рынок России заходят новые производители оборудования, что является интересным событием и дарует много опыта. Я сегодня сходил, познакомился, вот теперь со своей колокольни пересказываю. В центре повествования производитель из Израиля - 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 может работать и в экселе.