SCADA *

Что такое безопасность технологического процесса или технической системы (устройства), что такое риск и вообще зачем все это?

По анализу рисков и функциональной безопасности написано бесконечное количество статей (большая часть в переводе), брошюр, методичек и разнообразных презентаций.

В большинстве случаев этот материал носит научно-популярный характер, с огромным количеством терминов, аббревиатур, сокращений до трех букв, абстрактных рассуждений вперемешку с теорией вероятности, и для нормального инженера выглядит как полный бред. И в большинстве случаев это и есть полный бред. Трудно понять, как этот псевдо-научный поток теоретических рассуждений можно связать с реальным технологическим объектом, техническими устройствами, реакторами, колоннами, компрессорами, насосами, печами и т.д. Многие инженеры приходят к справедливому выводу – никак. И дело не в методах, методиках, ГОСТ-ах по анализу риска и функциональной безопасности, а в специалистах, которые не понимая реального смысла и целей этих методов, решение реальных задач заменяют процессом и процедурами, с формальным соблюдением отдельных пунктов методик, с безумными выводами, и своими безграмотными действиями полностью дискредитировали саму идею функциональной безопасности, основанной на оценке риска.

Данная статья, это попытка техническим инженерным языком объяснить подход к построению систем безопасности технологических объектов (технических устройств) на основе анализа риска и функциональной безопасности. В основу статьи положен собственный опыт участия в процедурах анализа рисков и построения функциональной безопасности, определения уровня SIL для контуров безопасности, формирования требований к техническому обслуживанию и периодичности испытаний систем противоаварийной защиты для сложных технологических установок переработки нефти. Статья полностью написана самостоятельно и не является переводом с англоязычных источников. Поскольку это собственный опыт, не буду утверждать, что все изложенное абсолютно правильно и объективно, возможны ошибки, недопонимание основополагающих положений стандартов, и вообще поверхностный и однобокий подход. Прошу понять и простить.

Это краткая история о том, как за пару вечеров с помощью россыпи мелочевки с алиэкспресс, термопистолета и WAGO-вских клемм собрать демонстрационный чемодан к выставке.

Над созданием открытой шины данных АСУ ТП работают как российские, так и зарубежные разработчики. Причина понятна – уйти от проприетарных протоколов и решений и создать единую прозрачную среду передачи данных систем автоматики. Раскроем суть задач, стоящих перед разработчиками.

Представьте, что нужно заменить двигатель самолета прямо в полете. Примерно в такой ситуации мы оказались, когда взялись за локализацию производственных систем одного российского завода. Черный ящик вместо системы управления, запароленный доступ, отсутствие документации и невозможность останавливать производство — весь джентльменский набор подводных камней после 2022 года.

Я Иван Балашов, в интеграторе К2Тех руковожу направлением цифрового производства и внедряю цифровые решения в промышленности. В этом кейсе расскажу, как мы собирали пазл из обрывков информации о настройках систем, внедряли российскую SCADA взамен западной, мигрировали функционал MES, и все это без остановки производства.

Если вы когда-нибудь окажетесь перед задачей импортозамещения критически важных производственных систем, эта история может дать представление о типичных подводных камнях и способах их обхода.

SCADA-системы — это программно-аппаратные комплексы для мониторинга и управления промышленными процессами. При сбоях и авариях они формируют критические уведомления о перегревах, утечках, отказах оборудования и других опасных ситуациях. 

Отправлять такие оповещения в Telegram значит их гарантированно потерять. Поэтому мы решили сделать интеграцию с Exolve API для их автоматической отправки для мгновенного оповещения ответственных специалистов через SMS.

На основе 18-летнего опыта работы в сфере АСУ ТП и детального анализа рынка мы представили рейтинг отечественных решений, охватывающий: «Каскад Цифра», «Альфа Платформа», «МастерСКАДА 4D», REDKIT SCADA 2.0, «СимплСКАДА», «ИнтраСКАДА» и «РАПИД СКАДА».

В исследовании оценены функциональность, надежность, масштабируемость, совместимость с ОС (включая Astra Linux, РЕД ОС), поддержка промышленных протоколов (OPC UA, Modbus, МЭК 61850), интеграция с базами данных (PostgreSQL, InfluxDB, Oracle) и ERP-системами.

Всем привет! Недавно несколько российских компаний (и Positive Technologies в их числе) провели исследование, которое было посвящено перспективам развития рынка автоматизированных систем управления технологическим процессом в России. Как безопасники, мы, конечно же, сосредоточились на вопросах защиты автоматизированных систем управления с учетом современных вызовов и киберугроз. Особенностями отечественного рынка АСУ ТП и нашими рекомендациями по безопасной разработке делимся с вами в этой статье.

Что такое универсальная система управления (UCS), и действительно ли она способна заменить распределённые системы управления (DCS) в будущих задачах по управлению технологическими процессами? Каковы основные преимущества UCS?

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

Летом 2023 года к к нам обратилось предприятие химической промышленности крупного Российского холдинга. На нем  много лет использовалась SCADA-система Wonderware InTouch. Из-за санкционных наложений, иностранный вендор расторг контракт на обслуживание и техподдержку. Более того, была предпринята попытка удаленно остановить производство путем отключения серверов SCADA. Последствия удалось минимизировать, изолировав промышленную сеть, однако функционал системы снизился на треть, а ее развитие и масштабирование оказалось невозможным. Нам было необходимо решить следующие проблемы:

1.     Отсутствие возможности обслуживания данной системы. Ввиду того, что данную SCADA систему разрабатывала и обслуживала иностранная компания, после начала СВО все контракты по обслуживанию и технической поддержке были расторгнуты. 

2.     Ограниченный функционал системы. После того как контракты были расторгнуты иностранная компания, имея удалённый доступ, попыталась дистанционно остановить производство путём отключения рабочих серверов. Заказчик, увидев странное в системе предпринял действия по изоляции своей производственной сети, однако иностранной организации всё-таки удалось  нарушить состав системы, тем самым снизив её функционал на треть.

Вот уже и 2025 г. Наша страна живёт в условиях большого количества санкций со стороны США и западного мира, которые затронули практически все отрасли хозяйства, в особенности высокотехнологические. Автоматизацию (АСУ ТП) это не обошло стороной.

Сборка макета для тестирования

Подготовка микрокомпьютеров и виртуального сервера

Установка утилиты mbpoll для тестирования датчиков

Установка InfluxDB

Установка Telegraf

Установка Grafana

Получаем данные от датчиков в Telegraf

Добавляем шаблон плагина датчика в конфигурацию Telegraf

Проверяем передачу данных в InfluxDB

Установка срока хранения данных в InfluxDB

Подключаем Grafana к InfluxDB

Тестирование Front Control Compact

Выводы

Полезные ссылки

Для сбора метрик с датчиков промышленного оборудования и умных домов используются самое разное оборудование, проводные и беспроводные сети, различные протоколы и стандарты.

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

Вы научитесь получать данные через протокол Modbus на примере датчиков XY-MD02 и PZEM-016, доступных на известных маркетплейсах. Первый из них измеряет температуру и влажность окружающей среды, а второй — параметры электрической сети, такие как напряжение, ток, мощность, потребляемая энергия и частота переменного тока. Используя полученные знания, можно будет подключать и другие аналогичные датчики.

Среди всех разновидностей протокола Modbus в этой статье будет использован Modbus RTU (Remote Terminal Unit), который применяется в промышленности для сбора данных через RS-485 или RS-232. Заметим, что длина линии RS-485 может достигать 1200 м.

Множество инженерных систем, работающих на поддержание комфортных, или требуемых условий (температура и влажность воздуха, содержание СО2 и примесей, уровень освещенности, температура воды), время от времени выходят из строя, требуют технического обслуживания. Раньше дежурный инженер несколько раз за смену обходил все оборудование и проверял его исправность и режимы работы. Кому-то стало жарко в помещении - потопал менять уставку температуры на установке за тридевять земель. И так каждый раз. Если что-то выходило из строя, то узнавали об этом либо в очередной обход, либо от пострадавших.

Разработали серийный корпус, плату, воткнули туда одноплаточник на Linux + Armbian, установили MasterSCADA4D и давай автоматизировать вентиляцию, освещение и другое инженерное оборудование.

Здравствуйте, пользователи сообщества Хабр.

Цель статьи: Описание способа передачи данных из закрытого контура АСУ ТП (промышленная технологическая сеть), в глобальную сеть интернет, 100% защита от взлома.

Невероятный подарок от Raspberry до нового года мы уже не ждали. Многие любители малинок из средней школы не поймут о чем речь, однако Raspberry CM5 это то что мы так ждали, так еще и в том же форм факторе что и CM4.

Доброго времени суток всем!

Вот и настал очередной этап рассказать о моем проекте и куда в итоге он меня привел. Предыдущие мио публикации по данной теме можно найти в моем профиле. С момента последней публикации прошло 7 лет, за это время произошло очень много всего, как вокруг моей разработки, так и того, чему она стала инициатором. После выпуска 2-й версии системы в 2017-м году, она достаточно успешно показала себя в нескольких крупных внедрениях. Объем поддержки и разработки системы ощутимо вырос и стал достаточно много требовать моего личного времени. Кроме того – меня пригласил один крупный холдинг создать им некую отраслевую скада—систему, поэтому времени на свое хобби, в рамках которого так и продолжал развиваться мой проект, стало не очень много. Поэтому в 2020-м году я объявил в кругах АСУТП, что буду не против дать проекту возможность встать на коммерческие рельсы. Неспешно пошли предложения, и также не спешно шел процесс их обсуждений и анализа продукта заинтересованными сторонами. В конечном итоге, на меня вышла группа ИТ-компаний, которые очень заинтересовались продуктом и возможностью диверсифицировать с его помощью бизнес еще и на рынок АСУТП. Так в июле 2022-го года родилась компания-вендор, в основу которой вошла интеллектуальная база проекта с исходным кодом 2-й версии моей разработки. Я вошел в состав ее учредителей и сейчас занимаю должность технического директора компании. За полтора года была сформирована отличная команда: разработчиков, инженеров и менеджеров. Первоочередной задачей, которая была поставлена перед нами – было создание новой версии скады, которая бы удовлетворяла текущим тенденциям и ситуациям, которые происходили в это самое время. А события, как вы понимаете, в этот период сыпались как из рога изобилия, и с каждым из них мы всей командой все больше понимали, что именно сейчас мы делаем то, что нужно нашему рынку автоматизации и это то, что нужно уже сейчас. Насколько у нас это получилось – теперь можно будет оценить, ведь буквально в начале февраля этого года мы выпустили официальный первый релиз нашего нового продукта: SCADA+ 3.0! И выпущен он уже компанией-вендором, которая теперь специализируется на его разработке, поддержке и сопровождении.

Для отладки ППО на ПЛК потребовалось настроить симуляцию устройства, которое опрашивается по протоколу Modbus RTU. Все ниже перечисленные программы и действия произведены в ОС Windows.

Продолжаем образовательные истории быдлокодера, который никак не может стать миллионером. Сейчас будет трогательная и крайне поучительная история, как мы начали импортозамещать MATLAB в авиации, когда нас об этом никто не просил, и еще до того, как это стало модно, и молодежно!

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

Как я уже рассказывал, американская коррупция превратила физика-ядерщика в былдокодера, но далеко от ядерных реакторов у меня оторваться сразу не получилось, несмотря на всю мою оторванность. Поэтому первые коммерчески успешные проекты у нашей копании были связанны технологиями «говна и пара», как на флоте называют ядерный реактор атомных подводных лодок. Не спрашивайте почему реактор ядерный, а подлодка атомная, это науке не известно. Но в итоге наше ПО начало применяться для проектирования систем управления АПЛ: сначала в качестве системы моделирования, потом для автоматической генерации управляющего ПО, дальше – больше, и уже наш код стоит непосредственно в системе управления.

Технология программируемых логических контроллеров совершенно точно достигла зрелости – ей уже 60 лет. В связи с чем возникает вопрос: станут ли нынешние ПЛК «пенсионерами» и сойдут ли их будущие версии в могилу? Такое предположение кажется уместным, учитывая быстрое, а порой экспоненциальное развитие компьютерного оборудования, программного обеспечения, искусственного интеллекта, облачных сервисов и средств связи. Благодаря этим достижениям информационные технологии постепенно проникли в ранее изолированную сферу операционных технологий.

В свете этих событий приводим статью Джеффа Пейна, опубликованную в журнале Control Engineering о будущем контроллеров и приложений промышленной автоматизации на фоне происходящей в последние десятилетия эволюции ПЛК.

Отладка систем управления вместе с моделью объекта. 

В данной статье рассмотрены примеры использования графических языков программирования в жизненном цикле модельно-ориентированного проектирования для систем управления сложными техническими объектами. А также продемонстрировано, как графические языки программирования делают жизнь проще, но интересней. И чтобы читатель не заскучал, мы рассмотрим противостояние программистов и технологов. Это как Монтекки и Капулетти, физики и лирики, красное и белое.  Разберемся кто из них главный, а кто лишний.

Все события выдуманы, все совпадения случайны.

Определение:

Технологи - специалисты в конкретной предметной области: физики, электрики, конструктора и проектанты разных сложных объектов. Технолог знает, как работает его сложный технический объект, что и когда включать или что и когда выключать, чтобы не было потом мучительно больно.

Программисты - специалисты в написании программ, умеют закодировать любой бред, который напишут в техническом задании, а также знают, как работает аппаратура управления, и что нужно написать в коде, чтобы получить данные с АЦП в программу, и наоборот отправить из программы в ЦАП.

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