Так как сегодня суббота, то думаю можно немного поспамить. На просторах 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/

Сегодня пятница

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

Безопасного вторника всем. И сегодня у нас Управление внешними подключениями к среде операционных технологий (OT)
И если пересказать очень кратко, то используйте для обеспечения кибербезопасности конкретные руководства и приказы. А в голове всегда держите 5 советов:
1) Прежде всего, внедрите выделенный шлюз VPN или узел перехода в демилитаризованной зоне предприятия. Это должна быть единственная точка доступа к среде предприятия для удаленных пользователей, и удаленный доступ никогда не должен быть включен по умолчанию.
2) Внедрите политику доступа по умолчанию «запретить всем» на границе внешней и внутренней связи (от уровня 4 до любого более низкого уровня модели Purdue).
3) По возможности установите многофакторную аутентификацию удаленного доступа (MFA). В противном случае рассмотрите альтернативные технические средства управления, такие как jump-host с усиленным ведением журнала и мониторингом.
4) Внедрите улучшенное ведение журналов и мониторинг на границе ИТ и ОТ, а также для любых особо важных активов в среде ОТ. Это может помочь вам идентифицировать и подтвердить разрешенный сетевой трафик от мошеннических устройств, которые могли получить доступ к сети OT.
5) Внедрить микросегментацию сети. Например, создайте отдельные VLAN (виртуальные локальные сети) для отдельных групп активов. Микросегментация также упрощает и улучшает видимость вокруг групп критически важных ресурсов и обеспечивает гибкость при разработке политик доступа к сети.
@wtfcontrolsengineer

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