Новый день и новые ключевые моменты для масштабирования облачного развёртывания... Облачные решения, пока еще, как я могу судить из разговоров в чатиках, пугают специалистов, да и не очень то приживаются в OT крупных производственников. Из всей статьи, что по ссылке, стоит выделить очень хорошие моменты связанные с информационной безопасностью, так как это основной источник страха, что каналы во внешний мир послужат лазейками для совершения нападений на вашу инфраструктуру(а так и будет).
Тут появляется логичный вопрос, а вы уже пытались как-то взаимодействовать с облачными технологиями или пока не понятно что это и как с этим работать?
https://www.smartindustry.com/articles/2022/four-key-ways-manufacturers-should-scale-cloud-deployments/

Full Stack автоматизация или автоматизация абсолютного всего процесса производства от оператора до руководителей материнской компании не только в сфере технологической, но и программной. В статье прозвучала хорошая мысль, что промышленная автоматизация представляет из себе два клана: первые - радеют за аппаратное решение проблем, вторые - за программное. В итоге страдает комплексная автоматизация.
Разумеется там приводят доводы для внедрения full stack автоматизации, но правда не рассказывают что это за зверь, но из контекста становится понятно, что по мимо управления технологическим процессом, она включает в себя: интеллектуальные системы анализа информации, граничные вычисления, организация озера данных, а также гибкую систему предоставления этой информации.
https://www.controleng.com/articles/full-stack-automation-operational-workforce-benefits/

Новую неделю начинаем со слова Блокчейн, а также его применение в автоматизации. Надеюсь, все уже слышали про блокчейны в контексте криптовалют, если нет, то коротко: блокчейн - это распределенная база данных, которая состоит из блоков, блоки содержат в себе информацию о дате транзакций и различные данные, которые сложно скомпрометировать. Блокчейн является основой какой-либо P2P сети (ETH, TON и т.д). Это отдельный мир, прикладное применение которому в области промышленности затрагивала мой ум, но даже приблизительного применения я не смогу придумать, так как не придавал особое значение даже обычному хранению данных.
Где же нам предлагает использовать технологию блокчейн Muhammad Asim Niazi:
Связь между машинами (M2M) для мониторинга процессов
Процесс обмена данными между устройствами напрямую. Такая технология обладает большой устойчивостью к повреждению данных, а также их(данные) будет сложно скомпрометировать.
Из сложностей: Требуются специальные датчики или устройства, которые могут в работать в таких сетях. Далее потребуется еще минимальная архитектура сети, которая бы обсчитывала эти данные и вносила их в сеть.
Децентрализованные операции
А вот здесь предлагают использовать смарт-контракты для управления. Смарт-контракт - это функциональная особенность некоторых блокчейнов. По факту - это программа, которая выполняется при соблюдении условий.
Кибербезопасность промышленных систем управления
И тут тейк про то, что у нас опять таки есть цепочки и они все связаны и работают методы криптографии и можно безопасно передавать данные, а также при такой технологии каждый узел сети будет выполнять функции безопасности.
Значение для инженеров
- Инженеры должны владеть различными сетевыми технологиями
-Инженеры должны быть готовы исследовать и понимать технологии блокчейна, основу и структуру проекта
- Больше инженеров как в программном, так и в аппаратном обеспечении должны понимать и использовать инструменты разработки блокчейна, такие как Corda и Ethereum, и, возможно, другие в будущем.
- Инженеры также должны понимать распространенные языки программирования, такие как C++ и Python.

@wtfcontrolsengineer
https://control.com/technical-articles/blockchain-in-industrial-control-systems-and-implications-for-engineers/

А теперь мои пять копеек вот к этому.
1. Скорее всего придется использовать свою собственную сеть для таких приколов внутри предприятия. Почему? потому что готовые сети берут комиссии за транзакции. Ну валидаторам тоже надо зарабатывать.
2. Скорость исполнения всего этого. Существуют очень быстрые сети, а есть медленные. Разумеется если писать сеть для предприятий, то там вряд ли будет такая бешенная нагрузка
3. Криптография. Ее надо будет выучить. Все это ассиметричное шифрование с ключами построенные на простых числах.
4. Смарт-контракты. Ну вы пытались написать хотя бы один? Ну если брать Solidity то там еще по человечески понятно, но вот если брать FunC то я уже ничего не понимаю.
Подводя итог. Крутая технология в перспективе. В большой отдаленной перспективе. Это не для одного завода, а для групп заводов, нескольких материнских компаний, которые завязаны вместе на различных этапах технологического процесса. И вот в таком глобальном плане уже появляется смысл. Вот тут мы и можем хранить различные данные о производстве, хранить различные заказы, которые будут автоматом публиковаться благодаря смарт контрактам, где мы будем отслеживать всю цепочку производства, но это все, пока что, - фантастика.

Приветствую всех читающих и интересующихся. В последнее время появилась проблема с нетворкингом в общем, а в большей степени обмен и накопление знаний и живая коммуникация в сфере OT и слияние OT и IT. Да есть чаты, но там в основном АСУТП и очень немного из программирования ПЛК и еще меньше про симбиоз OT и IT
Какое есть предложение. Если вдруг у вас есть какие-то идеи или вопросы связанные с OT и слияние с IT или есть статья или информация который вы хотели бы поделиться, или быть может у вас появилась тема для обсуждения то давайте вы ее скинете на info@engcore.ru и мы постараемся все организовать.
В нашем распоряжении есть как обсуждение под постами, так еще мы можем организовать дискуссионные комнаты и стримы, если уже будет что-то совсем интересное.

Человек может учиться на своем опыте, на чужом опыте и на рассказе о чужом опыте. Так что сегодня предлагаю перенять опыт зарубежных коллег в плане найма и обучения инженеров и техников по автоматизации.
1. Инженеры по управлению/автоматизации/OT откуда же они берутся?
В нашей стране вроде как на это учат, но я не в курсе. Из тех вещей которые я видел то переходили из КИПа, электрике, электротехники, просто люди, которые что-то понимали. В конечном итоге мы имеем две большие группы: группа с фундаментальными знаниями и со знаниями в промышленной автоматизации.
2. Процесс обучения инженеров на рабочем месте. Вот это везде увлекательное действо. Основной прием, который используют в компаниях - наставничество. Тебе, юному специалисту, прикрепляют уже опытного специалиста, который как-то рассказывает что надо будет делать и контролирует процесс твоего обучения, не имея опыта в обучении. А если вам повезет разрываться между несколькими наставниками, то есть большая вероятность, что знания полученные от них могут быть противоречивыми. К тому же время опытных инженеров очень дорого.
3. Для увеличения количества специалистов определенных направлений, а современное образование просто не в силах угнаться за требованиями реальности, работодатель должен производить обучение по конкретным ролям.
4. Необходимость расширения кадрового резерва. Очередная сложность. Потому что инженеры-программисты АСУТП не всегда взаимозаменяемы. Разные среды разработки, разные ПЛК, разные языки для программирования ПЛК, разный набор задач. К примеру, я не рисую схемы и не собираю монтажные панели, но у меня есть опыт программирования на языках высокого уровня.
5. Сосредоточиться на отношении и способностях инженера. Вот это очень хорошая вещь. Если кандидат не знает ваш стек технологий, то это не значит, что он не сможет на нем работать или изучить его за короткое время. В плане найма всегда стоит отталкиваться от каких-то общих способностей. Плюс стоит прорабатывать софт скилы инженеров, так как огромный пласт работы инженера в автоматизации - общение.
6. Построение системы обучения, а именно четки план и метрики. Регламент обучения по каждому пункту плана и чек листы. Очень много скучной бумажной работы, но в конечном итоге получается система, в которой можно выявлять слабые места и дорабатывать. Плюс включите автоматизацию в обучении.
@wtfcontrolsengineer

https://www.controleng.com/articles/how-to-hire-engineers-other-companies-dont-know-about/

Ну и на последок "6 советов по эффективному наставничеству"
1. Начните с перечисления навыков, которыми должен обладать «полноценный» инженер/техник. Это руководство для остальной части процесса и простой способ держать всех на одной волне.
2. Запланируйте окончание официального наставничества. Список навыков очень поможет здесь. Убедитесь, что люди знают, когда «новый парень» уже не «новый парень». Это может быть просто объявление на собрании компании, изменение названия или любой другой публичный жест, который соответствует культуре вашей компании. Если корпоративная культура сосредоточена на утилитарных дискуссиях (как это делают инженеры), это тоже нормально. Частью нашего обряда посвящения является объявление, что человек «X» теперь готов взять на себя срочную работу для клиентов, что часто не дает места для участия наставника.
3. Если наставник посещает обучение, то отправьте с ним подопечного. Хорошо, когда сотрудники со временем поддерживают друг друга как равные, а не как наставники-подопечные навсегда. Совместные тренировки дают им возможность развить эту динамику.
4. Сообщите наставнику и подопечным, что ошибки являются частью процесса обучения и не являются признаком неудачи. Наставляемый будет учиться и работать лучше, если не будет бояться за работу, а наставник с меньшей вероятностью отдалится от подопечного, если будут допущены ошибки.
5. Ежемесячно связывайтесь с наставником и подопечным по отдельности, чтобы узнать, как идут дела. Вы узнаете много нового о программе наставничества, о том, насколько хорошо она работает и что нужно этим конкретным людям для достижения успеха.
6. Держите подопечного вовлеченным в процесс. Позвольте им высказаться в своих собственных целях обучения, темпе и выборе наставника настолько, насколько это разумно.
------------
От себя могу добавить, что стоит быть менее токсичными в плане обучения и ответов на вопросы как новых специалистов в автоматизации так и опытных специалистов. Все всегда с чего-то начинают, часто приходится изучать новые предметные области. Разумеется есть вопросы, которые решаются чтением документации, но есть вопросы, в которых ответ уже опытного специалиста поможет сориентироваться быстрее, а иногда требуется очень большая оперативность. Создание хорошего сообщетсва и взращивнаие здоровой конкуренции делает нас сильнее как профессионалов.

Теперь немного о программировании ПЛК. Я тут немного начал на стримах писать проект совмещая FactoryIO и Codesys 3.5, пытаясь углубиться в ООП. В репозитории буду хранить изменения в проекте. На данном этапе там всего лишь один интерфейс и функциональный блок , реализующий данный интерфейс, плюс реализации нескольких методов и обработка сигналов с кнопок.
https://github.com/sudak-91/CodesysOOP-FactoryIO

Словосочетание дня - Corner case ну или граничный случай. Ситуация, которая возникает за пределами нормальных условий. Из всего делаем два вывода: 1) Использовать в программе цикл While Do следует очень осторожно. 2) Стоит убедиться, что цикл закончится до того как отработает сторожевой таймер. А теперь ситуация. Требовалось мне число с плавающей точкой привести в удобочитаемый вид - экспоненциальный. И первую половину дня все было хорошо. Во вторую половину дня один из датчиков немного взбрыкнул и отвалился. Система записала в регистр 0.0 и пожелала мне хорошего пути. сколько бы времени я 0.0 не умножал на 10 значение больше единицы я так и не увидел, а сторожевой таймер ПЛК раз в 30 секунд начинал цикл сначала.
Как выйти из такой ситуации, ибо ПЛК уходит в бесконечный цикл, перезагружается раз в 30 секунд и не отвечает ни на один внешний запрос с любого порта(если что это ПЛК210 от ОВЕН). Дождитесь начала загрузки проекта в плк. Об этом будет свидетельствовать мигающая лампочка проекта на плк. В этот момент переведите переключатель в режим СТОП и перезагрузите путем зажимания кнопки СБРОС более чем на 3 секунды. После перезагрузки ПЛК загрузится, но не запустит проект. Что позволит вам прогрузить новую версию прошивки, или сделать откат на старую.
Как я могу избежать подобную ситуацию? 1) Подумать больше чуть больше 5 минут над условиями. 2) Провести юнит тесты. В целом взять за практику писать юнит тесты всегда.
Из этого вопросы. Знаете вы то такое Юнит тесты? Пишите ли юнит тесты? Хотели бы узнать про юнит тесты и написание тестируемого кода?

Еще немного кода. https://github.com/DanaEng/DNEUnitLib
Это библиотека, разрабатываемая мной, которая непосредственно и используется в проектах. Так что если есть желание можете ознакомится, также накидать вопросов ну и указать на недостатки, недочеты и рассказать как бы вы сделали.
P.S. Там нет ООП(пока еще)

Сегодня для вас 7 СОВЕТОВ ПРОГРАММИСТУ ПЛК.
ВНЕДРИТЕ МОДУЛЬНУЮ СТРУКТУРУ ПРОГРАММЫ.
Программы ПЛК должны быть организованы осмысленно, например, путем выделения каждого из устройств и использования структуры, которую можно использовать повторно и легко понять. При использовании модульной структуры программист может вносить изменения во все устройства одного типа, а не вносить изменения в каждое отдельное устройство.
Тут мне добавить нечего. Действительно очень здорово делить код на функции и функциональные блоки, но это очень непростая задача, когда мы говорим о каких-то условиях управления. Вот функциональный блок насоса должен обрабатывать команду от оператора на включения или это должен сделать сторонний блок, котоый потом просто изменит состояние?
СТРУКТУРИРУЙТЕ КОД КАК УКАЗАНО КЛИЕНТОМ.
Конечный пользователь должен указать среду программирования для ПЛК, чтобы она соответствовала типу оборудования на объекте, обеспечивая правильную работу всех функций и функций. На этапе разработки проекта программист должен повторно использовать любые стандартные блоки кода или другой код, который уже был разработан для существующих интерфейсов. Хотя программисту может потребоваться немного больше времени, чтобы освоить эти блоки кода, персонал конечного пользователя уже знаком с ним и может поддерживать его легче, чем изучение нового интерфейса.
Спорный момент. Особенно при использовании наработок персонала. Другой момент это конечно через библиотечки обменяться интерфейсами, что не всегда возможно.
«ПРАВИЛЬНЫЙ» ЯЗЫК НЕ ВСЕГДА ЯВЛЯЕТСЯ «ЛУЧШИМ».
Программисты не всегда могут использовать «лучший» язык для приложения; они должны следовать тому, что указывает конечный пользователь. Как упоминалось выше, команда заказчика будет ежедневно обращаться с оборудованием на заводе, и если они не знакомы с используемым языком программирования и не могут его поддерживать, программист получит Звонок в 2 часа ночи, когда оборудование выходит из строя.
Наверно стоит научиться создавать правильные черные ящики. Все же внутрь функционального блока с какой-то логикой технологического процесса лучше не лезть. Какие-то крупные элементы можно написать на “правильном” в конкретной ситуации языке, но все же диагностика и изменения тех.процесса должны быть доступны с панели. Так же как и перевод системы в изначальное стартовое или безопасное состояние.
ПОНИМАНИЕ ПОТРЕБНОСТЕЙ ОБРАБОТКИ ДАННЫХ
Если у пользователя есть системы управления рецептами, основным средством анализа данных должен быть ПК, а не ПЛК, в зависимости от размера рецептов. Если есть прерывистые процедуры поиска или процедуры с высокой нагрузкой, они могут увеличить время сканирования и могут пропустить датчики. Эти ситуации могут сильно повлиять на работу ПЛК.
Дааааа. Отдайте ПЛК работу ПЛК. Хватит вешать на него миллионы ненужного функционала.
УБЕДИТЕСЬ ЧТО КОД ХОРОШО ПРОКОММЕНТИРОВАН.
Убедитесь, что код хорошо прокомментирован. Очевидно, что программист понимает детали и тонкости кода, когда он пишется, но код уже не будет свеж в памяти пользователя, когда его вызовут для устранения неполадок на сайте через несколько недель или месяцев. Если в коде есть необычные разделы, выходящие за рамки обычных, дополнительные комментарии помогут следующему программисту понять, почему код выглядит не так, как ожидалось. Это может помешать будущим программистам вносить изменения, чтобы «исправить» код, что может привести к ухудшению ситуации.
Бомба замедленного действия. Давайте писать самокомментируемый код, а если вы пишите комментарий, то пускай он будет действительно важным, а не просто объясняет что делает строчка. Опишите в комментарии что делает функциональный блок или какая-то функция, н избегайте комментариев из серии //сравниваем два числа и если меньше то…
Продолжение

СТАНДАРТИЗИРУЙТЕ СООБЩЕНИЯ ОБ ОШИБКАХ
При программировании системы убедитесь, что все сообщения об ошибках являются целевыми и стандартными для устройств одного типа. Если датчик может выйти из строя определенным образом, убедитесь, что неисправность сконфигурирована одинаково для всех датчиков в этой системе. Точно так же камеры или устройства любого типа, подключенные к ПЛК, будут иметь определенные режимы отказа. Спросите конечного пользователя, с какими режимами отказа он столкнулся, и запланируйте также действия в таких непредвиденных ситуациях.
А вот в эту магию я не могу. Если у кого есть хорошие примеры, то поделитесь пожалуйста.
СОПОСТАВЬТЕ ПРОГРАММНУЮ СРЕДУ С БРЕНДОМ
Чтобы обеспечить максимальную стабильность и избежать непредвиденных проблем, по возможности используйте среду, рекомендованную производителем ПЛК. Это позволит сделать код и работу с приложением максимально бесшовными.
Ага, чтоб потом не задавать вопросы, а какой средой программируется конкретный плк.
Еще больше новостей: https://t.me/wtfcontrolsengineer
Источник: https://www.controleng.com/articles/7-tips-every-plc-programmer-should-know/

Если вы устали скучать на эксплуатации или стоит как-то убить время, ожидая приход ПЛК, то вот материал.
Как неконтролируемое машинное обучение приносит пользу промышленной автоматизации
Неконтролируемое машинное обучение предназначено для работы с немаркированными данными с использованием алгоритмов, которые превосходно выявляют шаблоны и аномалии в данных, начиная от мониторинга состояния и тестирования производительности и заканчивая кибербезопасностью и управлением активами.
Статья написана при поддержке A3
Нам предлагают познакомится с такой вещью, как обучение без учителя, немного про алгоритмы такого обучения и где это можно применить.
1)Кластеризация
Как следует из названия, кластеризация включает в себя анализ наборов данных для выявления общих характеристик среди данных и группировки похожих экземпляров вместе. Поскольку кластеризация — это неконтролируемый метод машинного обучения, алгоритм, а не человек, определяет критерии сортировки.
И примеры использования кластеризации:
-Клиентская аналитика для OEM производителей, которые мониторят свои парки
-Операция обработки изображения
-Подготовка данных перед контролируемым обучением
2)Обнаружение аномалий
Обнаружение аномалий может иметь решающее значение для различных вариантов использования, от обнаружения дефектов до мониторинга состояния и кибербезопасности. Это ключевая задача в неконтролируемом машинном обучении.
И тут список применения увеличился в размерах и по значимости:
-Профилактическое обслуживание.
-Обеспечение качество/проверка
-Идентификация аномалий изображения
-Анализ тестовых данных.
3)Снижение размерности
Это может помочь идентифицировать подмножества данных, которые ортогональны друг другу, т. е. их можно удалить из набора данных, не влияя на основной анализ.
В самой статье еще чуть подробнее за алгоритмы, но общими словами, а также ряд вопрос для понимания, а надо ли это тебе.
https://www.controleng.com/articles/how-unsupervised-machine-learning-benefits-industrial-automation/

@wtfcontrolsengineer

Если честно, то очень не хватает хотя бы каких-нибудь CI инструментов, которые бы помогали в ПНР. В связи с этим вопрос. Как вы прогружаете ПЛК при удаленном ПНР и как собираете баг репорты?

Не могу найти еще одну статейку про Индустрию 5.0, где говорилось, что на базе индустрии 4.0 можно будет сделать очень легкую кастомизацию для конечных пользователей путем развитой 3D печати и хорошей логистики производства. Но тут уже размышляют на тему непрерывных процессов. Отличие непрерывных процессов от производства штучных продуктов заключается в использовании более сложных формул для расчетов и очень разнообразной рецептуры. Выдавить заготовку по шаблону будет отличаться от автоклавное выщелачивания.
О чем нам предлагают подумать. Это о взаимодействии людей, роботов и интеллектуальных систем, где большую часть монотонных работ надо делегировать роботам. А человек будет отвечать за творчество и решение нестандартных ситуаций.
Отличие 5.0 и 4.0 заключается в том, что 4.0 фокусируется на взаимодействия машины с машиной. IIoT, различные озера данных, интеллектуальные системы с предсказательной аналитикой или экспертные системы, граничные вычисления и облачные вычисления, которые должны предоставить оптимальные режимы работ для машин на основании данных от машин. А если нам взглянуть на взаимодействия ИИ и людей, то можно заметить, что такой симбиоз позволяет быстрее выходить новому продукту на рынок.
В конечном итоге это все должно как-то прийти у интеллектуальному управлению производства. Вот такой вот материальчик для почитать.
Разумеется это все еще очень фантастические размышления, так как требуется преодоление как технологических проблем, так и технических проблем. Налаживания связей внутри производства и между производствами. Проблема в сборе и обработке данных, проблема сбора и передачи человеческого опыта. И определение места человека в этой прекрасной индустрии будущего.
А пока можем просто фантазировать.
https://www.controleng.com/articles/industry-5-0s-role-in-process-manufacturings-evolution/

Я принес вам немного новой поисковой системы, которая заточена на поиск именно кода и около программистских тем.
https://code.you.com