Статья является презентацией серии продуктов от товарищей из 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

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

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