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

Если кто-то не знал, то я тут не просто перевожу новости на интересные темы вокруг 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/

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

Эту неделю прям требуется закончить интересным материалом о 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