С каждым новым объектом стараюсь дорабатывать и улучшать интерфейсы инженерных систем, опираясь на уже наработанный опыт. Сейчас под будущий проект доработал интерфейсы на вентиляцию до стадии, когда все нравится и уже не хочется больше ничего менять и я хочу поделиться им с вами и процессом его создания.
Я, как любой другой любитель «поковыряться» в различных железках, связанных с датчиками, микроконтроллерами и сопутствующих штуках, несколько лет назад столкнулся с необходимостью связать очередную микроконтроллерную историю с ПК, а именно, мне нужно было выводить в реальном времени значения различных сигналов с микроконтроллера на дисплей компьютера в виде различных графиков, прогресс‑баров, а также, с помощью кнопок и ползунков управлять моим «железом».
Имея достаточный опыт работы с промышленными SCADA‑системами было принято написать свою! Да такую, чтобы с ней справился совсем уж начинающий программист.
Рад поделиться своими наработками и буду вдвойне рад если это пригодится еще кому‑то еще кроме меня!
Нас окружают умные устройства. Внутри каждого — микросхемы и прошивки с программным кодом, который содержит уязвимости. Представьте, что в руки исследователя безопасности попадает устройство с недокументированным сетевым протоколом. Возникают задачи: разобрать протокол, научиться общаться с устройством и найти слабые места — уязвимости. Для исследования нужна прошивка. Но что делать, если прошивку невозможно достать?
В статье я расскажу об опыте исследования ПЛК FX5U компании Mitsubishi без использования прошивки. Поделюсь, как собирал информацию и восстанавливал протокол на основе: документации родственных протоколов, утилиты производителя, симулятора ПЛК, кодов ошибок, полного перебора и собственных наработок. Покажу, что знание протокола - сила, и как это помогло нам с коллегами выявить 15 уязвимостей, среди которых CVE-2022-25161 и CVE-2022-25162. Опишу, как работают две эти уязвимости и как они влияют на технологические процессы, на примере демонстрационных стендов.
Всем привет!
На HABRе есть интересная статья (даже две) про RTO, которая тесно связана с СУУТП, но нет ни одной статьи про саму СУУТП. Не порядок. Надо исправляться.
Вдохновившись статьёй моего друга про печальность интерфейсов в промышленном секторе (АРМ), я решил сделать свою версию того же самого, но с немного другим уклоном.
В том посте были комментарии из серии «всё везде регламентировано, раз так сделано — значит умные люди подумали», но если в условном Газпроме за АРМ наблюдает инженер или техник, который отличает на схеме трехходовой клапан от обратного, то в гражданских системах часто за этим следят те же диспетчера, что следят за пожаркой, диспетчеризацией лифтов и прочих систем, диспетчера часто меняются, новые могут не знать чего то, а для того же ТЦ быстрота фиксации и ликвидации аварии могут спасти много денег.
Этим я хотел показать, что удобно и красиво вовсе не значит анимации на каждый переход + тени и градиенты. Ну Хабр тому доказательство, как бы.
Расскажу длинный кейс, как мы за 5 лет сделали диспетчеризацию торгового центра, вывели все инженерные системы на 3 монитора и сделали для них красивые интерфейсы.
Интерфейсы разные нужны, интерфейсы разные важны. Я довольно давно уже топлю за качественные интерфейсы и за то, что им нужно уделять время и их нужно прорабатывать. Конечно, нужно делать все по сетке, подбирать цвета, отступы, иконки, кнопки и лампы. Очень здорово делать сразу два интерфейса темный и светлый и делать автоматический переход между ними по времени суток. Но еще я прекрасно понимаю, что времени на это очень часто просто нет, да и бюджет не резиновый, чтобы каждый раз привлекать дизайнера. Но что-то делать с этим нужно.
Я возьму рандомную мнемосхему из интернета и пошагово покажу, как минимальными усилиями можно привести в порядок интерфейс, чтобы он стал приятнее для глаз и удобнее для эксплуатации.
Компания Siemens в версии 17 TIA Portal Step7 для FW ≥4.5 (S7-1200) и FW ≥2.9 (S7-1500) встала на путь легкого принуждения к повышению уровня информационной безопасности. Теперь TIA Portal мягко предлагает задать пароль на хранилище сертификатов CPU, пароль на чтение/запись программы CPU, пароль на обмен с HMI и, конечно же, шифрованный обмен с применением сертификата. Все это, конечно, отключаемо, но зачем отключать то, что предлагается «из коробки»? События этого века показали всю важность инфобеза систем промышленной автоматики, а так же показали, что происходит при защите систем «от честного человека» (я про stuxnet, да). Основная причина, по которой, как мне кажется, шифрование не применяется - непонимание принципов работы и инерционность мышления (наши деды ни про какой TLS не слышали, и мы тоже не будем). В рамках одного проекта TIA Portal все еще более-менее ясно, а как быть с подключением «непортальных» систем? Рассмотрим такое подключение на примере S7-1500 FW2.9 и WinCC OA 3.18.
Продолжаем разбирать коммуникационные возможности системы WinCC OA. Но этот раз рассмотрим подключение к контроллеру «гражданской» автоматизации (AKA автоматизация зданий) Siemens PXC12 по протоколу Bacnet, который и был разработан аккурат для автоматизации зданий.
Моя Родина – АСУ ТП — смертельно больна
Если вы отправитесь на любой тематический АСУ ТП-форум или группу, вы к сожалению не найдете обсуждения стандартов, архитектуры РСУ, лучших практик для ISA101, ISA88, ISA95.
В лучшем случае вы найдете дискуссии на тему «являются ли АСУ-шники настоящими программистами когда пишут код на LAD/FBD» или «обязан ли монтажник/программист знать технологический процесс объекта на котором работает» и т.п.
Проще говоря – сообщество и особенно ИТ-сообщество разработчиков в сфере АСУ ТП отсутствует в принципе.
Рис. с сайта FIELDCOMM GROUP https://www.fieldcommgroup.org/
Хотя до этого я писал только про встроенное ПО, сегодня речь пойдет немного о другом. Я хочу рассказать о языке Electronic Device Description Language (EDDL) и его применении. Общаясь с разработчиками полевых устройств, я выяснил, что в РФ не так много специалистов в этом сегменте, слышал даже такое мнение, что в России всего 3 разработчика на этом языке, и одного из них я знаю лично.
Статья носит обзорный характер и не изобилует особыми деталями, но надеюсь вам будет интересно узнать про столь специфичный язык и вообще технологию интеграции полевых устройств в хост системы управления.
Большинство драйверов промышленных протоколов, будь то S7 / S7Plus, Modbus, IEC-101 / 104 и т.д. настраиваются и работают как в версии под управлением Windows, так и Linux. Исключения, разумеется, есть. В первую очередь - это классический OPC. Обратите внимание, именно OPC, а не современный мультиплатформенный OPC UA. Надеюсь, что многие еще помнят, что аббревиатура OPC раскрывалась изначально, как OLE for Proccess Control. Ну, а анекдотов про Open Proccess Communication насочиняли уже позже. Технология OLE относится к механизмам OC Windows и несовместима с Linux. Вторым исключением является драйвер Cerberus (пожаро-охранная система).
Рассмотрим настройку связи с контроллером Simatic S7-1500 при помощи драйвера S7Plus в версии под Debian 10. Этот драйвер предназначен для опроса ПЛК серии S7-1200/1500 с использованием символьной адресации.
Несмотря на солидный список поддерживаемых «из коробки» протоколов, применение классического OPC-сервера все еще сохраняет свою актуальность, даже принимая во внимание возможность разработки кастомного драйвера.
Для обеспечения связи с оборудованием при использовании сервера OPC нам так же необходимо добавлять в систему драйвер. Рассмотрим на примере драйвера OPC DA (data access, простой обмен данными). В качестве сервера OPC в данном примере используется широко известный Lectus, который по протоколу Modbus TCP будет связываться с локальным программным сервером Modbus TCP. Напоминаю, что сервер - это тот, кто отвечает на запросы. Клиент эти самые запросы генерирует.
Итого, в этой связке у нас получается по 2 клиента и по 2 сервера:
• драйвер OPC DA является клиентом OPC для сервера Lectus
• Lectus является сервером OPC для драйвера и одновременно клиентом Modbus TCP для внешнего устройства, с которым мы организовываем связь
• сервером протокола Modbus выступает отдельная прогамма, установленная локально
Проект уже создан, версия 3.18.
История началась с того, что потребовалось создать демонстрационный проект SCADA на 50 000 тегов (точек или каналов) для потенциального клиента. Целью проекта было показать, что программный продукт SCADA достаточно производителен и удовлетворяет требованиям заказчика.
Хороший повод попробовать для демопроекта новое поколение SCADA-системы, одним из разработчиков которой является автор. Когда до демонстрации оставалось несколько дней, и неизбежность выполнения задачи стала очевидной, создаём новый проект. Добавляем в проект 1000 виртуальных устройств-симуляторов, генерирующих данные, создаём 50К+ каналов для хранения значений, запускаем… и на веб-клиенте созерцаем данные, которые обновляются один раз в несколько минут в неочевидной последовательности. О том, что было дальше, написана эта статья.
Аббревиатура SCADA достаточно известна и не требует расшифровки, при необходимости справочную информацию можно найти по ссылке.
SIMATIC WinCC Open Architecture – это SCADA система разработки ETM(Siemens). В последние годы стала достаточно популярна в России в определенных кругах.
Поскольку в интернете информации о данном продукте не очень много, а на обучениях даются достаточно поверхностные знания и многие моменты не затрагиваются, появилась идея попробовать написать серию статей с интересными на мой взгляд темами.
В WinCC OA встроен C/C++ подобный скриптовый язык CONTROL. О его возможностях сегодня и поговорим.
Данная статья написана для тех кто на начальном уровне знает Python и немного разбирается в АСУ ТП. Задача достаточно распространенная, надо взять данные со старого, со своей специфичной реализацией протокола оборудования и перевести ее в такой вид, что бы ее можно было легко достать (MQTT сервер) и обрабатывать (SCADA или любое ПО, которое умеет работать с MQTT).
Мир развивается, а «велосипед» остается.
На сегодня ПИД-регуляторы являются самым распространенным средством для управления непрерывными технологическими процессами на производстве. Объясняется это не только исторически сложившимся подходом к построению контуров управления. ПИД-регулятор это очень простое устройство, которое легко реализуется на любой аппаратной платформе: механической, пневматической, на аналоговой электронике или на цифровых устройствах.
В большинстве случаев ПИД-регулятор полностью справляется со своей задачей и обеспечивает регулирование технологических параметров с требуемым качеством. Подход к настройке на технологических процессах, метод подбора коэффициентов, универсален и не зависит от объекта автоматизации: подаешь возмущение ступенчатым изменением уставки, смотришь по трендам реакцию контура и подбираешь коэффициенты, чтобы получить нужный «горбик» и сходимый переходной процесс. В большинстве случаев этого достаточно. Такому подходу легко обучить не только инженеров АСУТП, но и специалистов с небольшой инженерной подготовкой, прибористов, слесарей КИП, операторов.
Часть 3. Реализация регулятора – вот теперь регулятор.
продолжение практической реализации ПИД-регулятора
Реализация регулятора в ПЛК
Все, что будет написано ниже про реализацию ПИД-регулятора в ПЛК, не является чем-то новым и революционным. Практически всю эту информацию можно найти в документации на ПЛК серьезных производителей. Если вы инженер АСУТП со стажем и добросовестно изучали документацию на ПЛК, то все это вам известно. Но в текущей реалии есть каста молодых инженеров и студентов, которая все знания черпает из роликов на ютубе. Заставив себя посмотреть несколько самых популярных роликов про реализацию ПИД-регулятора, я был огорчен качеством излагаемого материала: объяснение работы ПИД-регулятора уж очень «колхозное», а реализация сводится к 15 строкам кода на С++, что порождает
упрощенное и ошибочное понимание предмета. Вот для касты ютуб специалистов в
первую очередь и предназначено это описание.
Часть 1. От практики к теории.
Как и все поколения будущих инженеров, в ВУЗе я делал лабораторные и курсовые, что-то рассчитывал, чертил годографы и казалось, что понимал теорию и был готов применять ее на практике. По окончанию университета, попав инженером АСУТП на нефтеперерабатывающий завод, увидев реальную установку, контроллеры, датчики, клапаны, я был в некотором недоумении: как связать теорию САР с поддержанием в колонне уровня скворчащей горячей жидкости при посредстве дрожащего буйкового уровнемера и гудящего замазученного клапана. Да и описание регулятора в документации на ПЛК сильно отличалось от схемы в лекциях по САУ. Со временем, поняв опытным путем и процессы в колоннах и аппаратах, и подходы к практическому построению контуров регулирования, освежив в памяти теорию удалось более осознано связать теорию САР с реальным процессом. Но каждое следующее поколение инженеров, попадая после ВУЗа на реальное производство, задавалось теми же вопросами.
Почитав еще раз лекции и пересмотрев множество материалов по «практической реализации ПИД-регуляторов», я не нашел грамотного и доступного для понимания описания как самого ПИД-регулятора, так и процесса регулирования. Поэтому решил написать свою статью «про велосипед автоматизации».
