SCADA *

Компания 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. От практики к теории.

Как и все поколения будущих инженеров, в ВУЗе я делал лабораторные и курсовые, что-то рассчитывал, чертил годографы и казалось, что понимал теорию и был готов применять ее на практике. По окончанию университета, попав инженером АСУТП на нефтеперерабатывающий завод, увидев реальную установку, контроллеры, датчики, клапаны, я был в некотором недоумении: как связать теорию САР с поддержанием в колонне уровня скворчащей горячей жидкости при посредстве дрожащего буйкового уровнемера и гудящего замазученного клапана. Да и описание регулятора в документации на ПЛК сильно отличалось от схемы в лекциях по САУ. Со временем, поняв опытным путем и процессы в колоннах и аппаратах, и подходы к практическому построению контуров регулирования, освежив в памяти теорию удалось более осознано связать теорию САР с реальным процессом. Но каждое следующее поколение инженеров, попадая после ВУЗа на реальное производство, задавалось теми же вопросами.

Почитав еще раз лекции и пересмотрев множество материалов по «практической реализации ПИД-регуляторов», я не нашел грамотного и доступного для понимания описания как самого ПИД-регулятора, так и процесса регулирования. Поэтому решил написать свою статью «про велосипед автоматизации».

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

В настоящей заметке речь идет про массовую выгрузку / загрузку настроек точек данных.

Организация аварийных и технологических защит на примере технологической печи

В статье приведен пример организации защит для технологической печи. Данный подход к построению защит был неоднократно реализован на объектах нефтепереработки и нефтехимии с применением различных ПЛК.

Материал в первую очередь ориентирован на инженеров АСУТП, разрабатывающих и реализующих аварийные и технологические защиты. Предложенный подход построения защит является типовым для зарубежных проектов и несколько адаптирован под российскую действительность. Все решения подробно поясняются. Статья призвана помочь инженерам разобраться в сложных моментах при реализации ПАЗ технологических объектов.

Предложенный подход основан на личном опыте автора, автор не претендует на истинность.

SCADA (Supervisory Control And Data Acquisition) – вариант человеко-машинного интерфейса (ЧМИ), если перевести почти дословно – диспетчеризация, управление и обработка данных.

История развития ЧМИ.

Обзор решений SCADA.

Варианты реализации функций модификации прикладной программы без отключения контроллера (сохранения состояния выходов) и останова технологического процесса (в большинстве вариантов это не on-line модификация, как это заявляет изготовитель ПЛК):

Программируемый Логический Контроллер (ПЛК) для технологических процессов – разнообразие форм и размеров.

Из прошлой статьи:

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

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

Типовая система автоматизации состоит из: измерительных приборов для контроля параметров технологического процесса (датчики, сигнализаторы, сенсоры и т.д.), промышленного контроллера, исполнительных устройств (клапаны, приводы, частотно-регулируемые преобразователи, пуско-регулирующая аппаратура) и человеко-машинного интерфейса. В системе автоматизации выделяют контуры регулирования (непрерывного управления)  и контуры защиты. Контур – логически организованная последовательность элементов, выполняющая отдельную функцию автоматизации. Например, контур регулирования уровня в емкости будет включать уровнемер, ввод/вывод и ПИД-регулятор в контроллере, регулирующий клапан. Контуры могут быть локальными (независимыми) или связанными (многоконтурное регулирование).

Основные понятия РСУ (DSC), PLC (ПЛК), ESD (ПАЗ) и различие между ними.

Когда «молодой специалист» сталкивается с современной терминологией систем промышленной автоматизации, то такие термины как DCS, РСУ, PLC (ПЛК), ESD, SCADA, СБиПАЗ вызывают некоторое недоумение, так как объективно существует несоответствие между термином и оборудованием. А если послушать объяснение менеджеров-продавцов систем автоматизации или их компонентов, почитать форумы, путаницы становится еще больше.

На самом деле термины сложились на «заре автоматизации» и тогда они логично соответствовали текущей ситуации и оборудованию, с тех времен оборудование и принципы построения систем автоматизации значительно изменились, но терминология остается, как «исторически сложившаяся».

Привет! Я Дмитрий Даренский, руководитель практики промышленной кибербезопасности в Positive Technologies. Уже более 15 лет я занимаюсь построением технологических сетей и систем связи, а также помогаю создавать комплексные системы безопасности для промышленных предприятий. В этой статье я расскажу о современных подходах к информационной безопасности и недопустимых событиях в электроэнергетике. Возможно, вы удивитесь, но подобные инциденты уже случались. Например, в 2019 году в Венесуэле резкий сброс мощности в энергосистеме привел к тому, что 80% страны осталось без света на пять суток, а каскадное отключение электросетей в Индии годом позже затронуло транспортную инфраструктуру страны, вызвав значительные нарушения в работе систем управления поездами и дорожным движением.