Не могу найти еще одну статейку про Индустрию 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

Всем спасибо кто был на тестовом спонтанном стриме. Очень непонятно как настроить коммуникацию со зрителями. Плюс получилось сохранить только звук, а я думаю он в этой ситуации был не очень нужен. В любом случае конечный итог будет оформлен в текстовом лонгриде, а процесс по возможности я буду стримить. Всем спасибо

Если кто-то не знал, то я тут не просто перевожу новости на интересные темы вокруг OT, но еще иногда катаю статейки, который можно почитать в блоге
Там можно найти ускоренный курс введения в ООП для ПЛК. Есть разбор работы таких типов как BIT и BOOL или рассказ о ссылках и указателях. И что-то еще по мелочи.
Для связи можно воспользоваться почтой: info@engcore.ru и туда можно засылать вопросы, предложения, возможно интересные новости(бота мы допишем чуть позжэе) или просто вы хотите поделиться и пообщаться на профессиональные и около темы.

Так как сегодня суббота, то думаю можно немного поспамить. На просторах reddit наткнулся на интересный пост, который назывался: "ПЛОХИЕ ПРАКТИКИ СИСИТЕМНОГО ИНТЕГРАТОРА"
И вот что он пишет:
-Нет производства стандартных библиотек, каждый раз приходится что-то переписывать с нуля.
-Очень плохой шаблон ПО
-Очень плохой дизайн HMI и отсутствие шаблона, поэтому каждый раз с нуля и каждый раз чего-то не хватает.
-Очень плохая документация (какой-то дерьмовый ворд файл, лол).
-Плохое знание физики и механики
-Каждый проект не может быть выполнен одним человеком, всегда приходится менять человека из-за других работ и нехватки времени.
-Плохой контроль версий
-Нет знаний в области ИТ
С чем-то я согласен, с чем-то нет. В прошлом году я уже писал о проблемах в АСУТП, на мой взгляд. Теперь могу поделиться плохими практиками от себя, с чем я сталкивался, а что иногда и сам делаю(простите), а также предлагаю вам в комментариях поделиться
1)Документация не всегда соответствует реальности. И если про всякие руководства я беспокоюсь в последний момент, так как их все равно переписывать после ПНР, то вот электрические принципиальные схемы, которые отличаются от реальности создают много проблем.
2)Отсутствие пункта про рабочее место на территории заказчика в договорах. (Ага, это про стул, стол, свет и минимальные удобства)
3)Наименование объектов в коде соответствует наименованию в проекте. Конечно HL1 - это здорово, но RedLamp - это чуть более понятно.
4)Бесполезные комментарии. Опасность комментариев заключается в том, что они не всегда изменяются с изменением логики. Так что комментировать каждую строчку с условием и циклом - перебор, а вот в паре строчек указать что делает эта функция полностью - норм.
5)Отсутствие переговоров и совещаний. Раньше сам не любил эти процессы, считая, что они только забирают время, мол в почте все проще и быстрее. Переговоры и совещания действительно забирают много времени, если их правильно не организовать, указав время, продолжительности и цели к которым надо прийти к концу этого совещания.
6)Отсутствие общего ТЗ на СУ. Оно всегда требуется. ВСЕГДА. Именно в нем указывать что надо сделать, а если заказчик говорит, что не надо, то указывайте в ТЗ, что это делать не надо.
7)Дизайн рисуют программиста. Давайте признаемся, что мы не умеем рисовать дизайн. И ни какие 101 нам не помогут.
8)Отсутствие бюджетов и сроков для разработки библиотеки СУ для всего парка устройств.
9)Цифровые двойники или макеты. Ох, сколько же нервов это могло сэкономить. Отладка большей части логики управления в спокойных условиях.
10)Плохая структурная организация проекта в среде разработки. Это когда мы все накидали в рандомные папки с какой-то непонятной структурой. Сначала у меня в одной папке были данные в другой FB, но без экземпляров в третьей Экемпляры FB и их вызовы. Потом я как-то еще пересобирал структуры проектов, пока не дошел до структуры, которая уже понятна для меня с каким-то постоянными названиями.

Кто-нибудь будет на этом мероприятии?
https://www.elektro-expo.ru/

Я не знаю как давно это у МТС, но тоже здорово. Они даже DIY Kit продают, чтоб ты мог попробовать себя в роли Embedded разработчика и соприкоснуться с миром MQTT и облаков. Вроде уже все обзавелись подобными решениями из коробки. И они имеют право на жизнь, ибо настроить с нуля брокер MQTT, а по стандарту все начинют с Mosquito то еще развлечение. Если вдруг кто-то уже затестил - расскажите.
https://asutp.ru/news/2022/06/02/mts-zapustila-platformu-dlya-razrabotki-iot-reshenij/

В тему модульного тестирования, они же Unit тесты.
К концу сегодняшнего стрима у меня таки получилось заставить работать всю эту машину. С огромным количеством детских ошибок, где-то захардкодил то, что надо исправлять, но в целом сие как-то работает.
Ссылка на запись стрима: https://youtu.be/GmvQM0WnUrc (Последние минут 10 быстро рассказываю что сделано)

Чтение вам на выходные. Библиотека для проведения Unit тестов для Codesys, написанная мной.Небольшой разбор того что под капотом. Много наследования и работы с указателями. Все ссылки в статьей(На библиотеку и проект с библиотекой, а также плейлист со стримами).
Как всегда замечания, предложения, идеи и вопросы в комментарии.
https://blog.engcore.ru/2022/06/11/codesys_unittest_plc/

Новую рабочую неделю начнем с визуального контента, а именно: "Миграция SCADA и HMI: что изменить, а что оставить"
Со времен появления HMI, когда ПК стал массово доступны, прошло много времени и представление об интерфейсах в промышленности менялось. Вначале было много данных, выводили абсолютно все, потому что могли, после стали управлять тревогами и появилась ситуационная осведомленность. Сейчас проблема современных интерфейсов в том, что у нас очень много данных, но пока мало информации, также технический прогресс не стоит на месте и для использования новых технологий необходимо использовать новые HMI и SCADA системы.
Существует две основных концепции обновления интерфейсов:
1) Сохранит дизайн прежним, но перенести на новое аппаратное и программное обеспечение
2)Перепроектировать HMI, чтобы решить известные проблемы и использовать более совершенные конструкции и современные технологии
Оба подхода имеют свою аргументацию, но как говорит автор статьи: "зачем вам пользоваться раскладушкой, когда есть смартфон"
Пока выделяют следующие современные подходы к организации HMI и SCADA:
- Мобильность - управление с мобильного устройства. Каждому работнику лишь нужные данные
- Демонстрационный щит(Табло) - все аварии и неисправности по участкам просто выведены в отдельное табло. Что позволяет не искать по экранам где произошла авария
- Замена бумаги - все механизмы отслеживания данных на бумаге должны быть в электронном виде
- Диспетчерские - из-за уменьшения рабочей силы и увеличения автоматизированного оборудования диспетчерские позволяют лучше контролировать большое количество установок
- Ситуационная осведомленность - кодирование состояния цветом, когда преобладают градации серого. Изменяю фокус с "я здесь" на "Мне надо быть тут"
- Управление аварийными сигналами - оператора не должно перегружать сообщениями системы
Стандартизируйте свои интерфейсы. Определите графический набор и цветовое кодирование, определите расположение одинаковых навигационных элементов на всех экранах, логика взаимодействия с однотипными элементами должна быть одинаковой
Выделяют три преимущества стандартизированных интерфейсов:
1) Повышение производительности
2) Низкий порог вхождения
3) Экономическая эффективность
И для улучшения рабочего процесса рекомендуют применять следующие четыре подхода:
1) Стандартные операционные процедуры - упорядочить и отправить последовательные сообщения о том, как все должно быть сделано
2) Изменения и настройка - отслеживайте критические запланированные события простоя и предоставляйте обратную связь для повышения эффективности, когда она не используется.
3) Доступ к справочной информации и документации - предоставляйте доступ к документации на рабочих местах, там где она необходима.
4) Устранение неисправностей - предоставьте процедуры устранения неполадок, связанных с остановками машин, проблемами качества и отклонениями в производительности.
@wtfcontrolsengineer

Товарищи автоматизаторы, кто ломает большие ПЛК и не очень. Расскажите пожалуйста какие ПЛК вы чаще всего программируете, интересует среда разработки, используете ли вы сиситему контроля версий или как вы контролируете версии?

Статья является презентацией серии продуктов от товарищей из positive technologies. Эти ребята одни из немногих, кто занимается темой кибербезопасности именно АСУТП. Рекомендую, как легкое чтиво на вечер с налетом рекламы продукции)))
https://habr.com/ru/company/pt/blog/671656/