SCADA *

Поделюсь одним интересным кейсом, как мы сделали пилотный проект системы контроля освещением и что из этого получилось.

Клиент: крупный логистический центр в Московской Области, с которым мы работаем с 2016 года. За это время мы провели уже много работ по диспетчеризации инженерных систем, вывели в единую BMS вентиляцию, котельную, энергетику, отопление, энергоучет и много чего еще. А в этом году решили добавить еще и диспетчеризацию освещения в общую систему.

Внутренности, скрывающиеся под измочаленными за последние годы стараниями маркетологов словами "умный дом" могут быть очень сильно разные. Как, например, под словом «печь» может подразумеваться и печь-буржуйка, так и доменная печь.

И если в предыдущей статье мы писали о построении вентиляции в историческом здании (Храме Спас-на-Крови), то в этот раз хочется рассказать о особенностях умного дома в большом особняке. А также о проблемах, которые приходилось решать при создании и автоматизации климатики в этом современном здании. Площадью под 3000 квадратов, с бассейном и СПА зоной.

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

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

В том году я уже писал статью об интерфейсах систем диспетчеризации, она получилась большая, и в ней все рассказано в общих чертах, здесь же я хочу рассказать более конкретно о своих наработках и своем опыте. Буду придерживаться в первую очередь системам вентиляции, так как они чаще всего встречаются на объектах и по нима больше кейсов. Так же, будут примеры с разных устройств, панелей 7 дюймов и мониторов около 27 дюймов. Ну что, поехали.

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

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

В этой статье я бы хотел рассказать о том, что Windows проекты на Delphi возможно перевести на Linux в разумные сроки и с разумными трудозатратами. Что такое SCADA-система, рассказывать не буду, а перейду сразу к делу.

Runtime ядро SCADA работает под Windows в качестве сервиса. Функции стандартные «как у всех»: сбор, обработка, архивирование данных, передача данных в другие SCADA-системы по стандартным протоколам обмена. Визуализация только через Web. Runtime ядро SCADA написано на Delphi. Решено было адаптировать исходный код под  FreePascal/Lazarus, так чтобы код под Windows компилировался и в FreePascal и в Delphi, вторым этапом было допиливание проекта непосредственно на Linux машине и переделка его в демон. В FreePascal привлекала возможность компиляции как для x64, так и для плат Raspberry pi (архитектуры ARMv7, ARM64 (aarch64)).

Конфигуратор работает под Windows в виде графического приложения. Пока решено не переводить его на Linux, в крайнем случае можно запустить под Wine.

Теперь перейдем к Runtime и будем говорить о нём. В нём применяются разнообразные компоненты:

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

Не буду лукавить и приводить кучу доказательств и обоснований того почему сделано так как сделано (а с учетом ценников на пром автоматику, система получилась копеечная, <150$ против самой дешевой дельты с ограниченным функционалом за 300$), так как давным-давно меня заинтересовал симбиоз RasberyPi и программного комплекса промышленной автоматизации Codesys и хотелось проверить на реально необходимом проекте. И только поэтому был выбран данный «Hardware», хоть и сомнение в стабильной работе не покидали до последнего момента.

Скачивая недавно с сайта winccoa.com установщик последнего патча версии 3.17, с некоторым удивлением, постепенно перешедшим в ликование, обнаружил, что список поддерживаемых дистрибутивов Linux расширился и до Debian. Дело в том, что посмотреть на работу системы в ОС, отличной от Windows, мне хотелось давно, но из всех дистрибутивов Linux я более-менее понимаю только Debian, а привыкать к новому ради баловства откровенно не хотелось. Собственно, и под Debian установка проходит не сильно гладко.

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

Итак, надоело! Даже, не так, ДОСТАЛО! А точнее, за.... Впрочем, не буду прибегать к ненормативной лексике. Квартира, купленная 2.5 года назад - это не квартира, а какое-то вечное испытание. Да такое, что Форт Баярд отдыхает. Кроме того, в конце игры Баярда можно нехило поднять золотишка, а чем тут все закончится - я еще не знаю. Недостаточная (ниже норм, утвержденных Правительством РФ, а эти нормы, скажем так, разрабатывались моржами) температура воздуха в помещении, отсутствие горячей воды по утрам, а ежедневное принятие душа превращается в соревнование "кто быстрей", ибо вода неожиданно может стать кипятком. Или, наоборот, льдом. Бездействие управляющей компании, сбор инициативной группы, объявления по подъездам, коллективная жалоба... это и многие другие веселые подробности останутся за рамками повествования.

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

В рамках базового курса в системе WinCC OA используются только внутренние переменные системы. Никаких внешних подключений не предполагается. Однако, слушатели базового курса всегда под завершение учебы просят продемонстрировать, как же считать переменную с «настоящего живого ПЛК». Поскольку WinCC OA относится к продуктам компании Siemens, то логичным будет продемонстрировать подключение к контроллеру компании Siemens и чтению с него нескольких переменных. В нашем случае будем подключаться к PLC серии S7-1200.

Набор драйверов WinCC OA включает в себя два вида драйверов для контроллеров Simatic — это s7 и s7plus. Разница в них следующая: s7 предназначен для связи с ПЛК классической серии S7-300 / S7-400, а s7plus — для современной линейки S7-1200 / S7-1500. Драйвер s7plus указывается при установке отдельно. Он может отсутствовать в вашей системе, если вы его не устанавливали. Вне зависимости от того, какой используется драйвер (хоть iec104), общие принципы сохраняются. Необходимо в консоли добавить соответствующий драйвер. Далее сконфигурировать соединение с устройством и задать этому соединению номер добавленного драйвера, активировать. Так же требуется на DPE навесить конфиг Periphery Address и выполнить настройки, указав корректный адрес переменной.

Для начала необходимо прописать в консоли драйвер. Технически добавление драйвера в систему не отличается от добавления менеджера. Откроем консоль, нажмем в ней Append a new manager

В процессе создания модели поведения клапанов мы создали (и в прошлой части модифицировали его) скрипт Model, в котором было несколько вызовов dpConnect и несколько callback-функций. Тогда я писал, что это «быстрый, но неправильный способ». Эта пауза была необходима, чтобы предварительно ознакомиться с функцией dpQuery. Предлагаю вернуться немного назад и реализовать модель медленно и очень занудно правильно, теперь при помощи функций семейства dpQueryConnect. Откроем наш скрипт Model.

Оживим уже созданную (но пустую) панель Trends графиком изменения переменной во времени. Однако, перед тем, как смотреть на тренды, их необходимо сконфигурировать и каким-то образом задать значения, чтобы они скопились в базе данных. Необходимо, чтобы в системе была переменная, которая меняла свое значение. Необходимо повесить соответствующий конфиг на эту переменную, чтобы значения складывались в архив. Для типа точек данных Flap у нас есть DPE с названием Flow (расход) и типом int. Этот DPE и будем использовать для ознакомления с трендами. Для имитации поведения системы у нас уже есть созданный control-скрипт Model. Предлагаю его и использовать для иммитации расхода. Откроем скрипт Model

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

Создаем панель Main, в которую будем встраивать остальные компоненты. Ее размер делаем больше размера панели Flaps.

До настоящего момента весь наш прикладной проект состоял, фактически, из одной экранной формы — Flaps (панель Flap можно уже не рассматривать, она неактуальна, а Flap_ref является шаблоном). Реальные «боевые» проекты содержат, как правильно, (значительно) больше одной мнемосхемы, отображающие целую картину, отдельные технологические участки, настройки, тренды, алармы и т.д. Рассмотрим, каким образом в системе WinCC OA возможно осуществлять переход между экранами.

Создадим еще одну панель в проекте и назовем ее Trends (на будущее), сделаем ее размер сопоставимым с размером панели Flaps и поместим на нее что-нибудь читаемое. Например — надпись «Это тренды», чтобы быть уверенным наверняка.

(* Начиная с этой части я перешел на версию WinCC OA 3.17. Никаких отличий в масштабах базового курса не будет. Изменятся лишь надписи на скриншотах.*)

В предыдущей части мы завершили создание визуализиции задвижки и создали простейший скрипт, имитирующий ее поведение.

У нас есть одна панель под названием Flap, которая отображает и шлет команды для одной задвижки — Flap1. Именно такая точка данных указана во всех скриптах этой панели. Возникает закономерный вопрос — что делать, если задвижек не одна? И даже не две. А несколько десятков, сотен и даже тысяч (для распределенной системы WinCC OA и несколько миллионов сигналов не помеха, смотрим на Большой Андронный Коллайдер,

Запрограммированое в предыдущей части поведение задвижки… нелогично. В обработчике нажатия кнопки «Открыть» или «Закрыть» мы непосредственно задавали значение элемента под названием Position. При том, что в самом DPT у нас уже предусмотрены команды «Открыть» и «Закрыть».

В прошлый раз мы закончили на создании типа точки данных (DPT Flap) и трех экземпляров точки данных (DPs Flap1, Flap2, Flap3). Пора переходить к визуальной составляющей операторского интерфейса. Открываем модуль gedi. В gedi мы видим название нашего проекта в дереве и его составные части. Нас сейчас интересуют «панели», поэтому разворачиваем их.