SCADA *

Решил немного рассказать про систему визуализации от Siemens под названием WinCC OA. Эта SCADA на рынке России распространена гораздо меньше классических версий WinCC (и tia-портальных тоже), знаний по ней в открытом доступе достаточно мало, знаниями делятся неохотно. В ряде моментов WinCC OA радикально отличается от обычных распространенных SCADA, поэтому для начала необходимо усвоить базис.

Перед усвоением этого базиса я рекомендую в общем ознакомиться с архитектурой построения WinCC OA. Лучший способ такого ознакомления — найти в Интернете записи вебинаров и выступлений эксперта по WinCC OA Кондрашкина Андрея. Андрей Геннадьевич — очень мощный специалист и прекрасный докладчик. Настоящий цикл заметок, собственно говоря, и основан на его двухдневном вводном обучении. Рекомендую эту запись.

Можно углубиться в изучении вопроса и дальше, например — ознакомиться с аддонами SmartSCADA или Preactor, но это выходит очень далеко за рамки базового понимания системы. Самое главное, что необходимо вынести из этого ролика — это понимание архитектуры WinCC OA. Например, то, что система состоит из отдельных законченных функциональных единиц, которые называются «менеджерами». Менеджер выполняет строго свою заданную роль. Центральным звеном всей системы является менеджер событий (event manager или EV). Есть менеджер визуализации, User Interface или ui. Есть драйвера, например — s7. Есть менеджер для выполнения скриптов, control. Все менеджеры общаются друг с другом посредством центрального EV по стандартному протоколу TCP/IP, вне зависимости от того, находятся они на одном физическом ПК, или разнесены на несколько.

Вторая важная отличительная черта, которую необходимо понять. OA — это система событийная. В ней почти отсутствует постоянный polling данных. Изменение показаний на экране оператора произойдет только в случае изменения значения соответсвующей переменной в контроллере.

Третье. Все или почти все реализовано скриптами (»Что нельзя запрограммировать на Ассемблере, можно спаять» (с) ) и текстовыми файлами. Необходимо зажечь лампочку на мнемосхеме? Скрипт. Причем скрипт, который подвязывается к изменению переменной и выполняющий определенные действия только по этому изменению автоматически.

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

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

Для наглядности разберем пример с торговым центром. Чтобы привлечь как можно больше посетителей, руководство ТЦ старается сделать их шоппинг максимально комфортным и, как следствие, ТЦ оборудован десятками сложных систем: свет, вентиляция, кондиционирование, теплоснабжение, водоотведение и многие другие, которые скрыты от глаз посетителей.

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

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

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

Как же нам быстро убедится что наша система это именно то что мы проектируем, полетит ли или поплывет ли, наша конструкция? А если полетит то как высоко? А если поплывет, то как глубоко?

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

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

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

Для настройки регуляторов существует большое количество средств, методик и обеспечивающих оптимизацию законов регулирования. Если мы используем средства моделирования (типа Matlab Simulink), то можно сразу посмотреть на процесс оптимального управления непосредственно «вживую», на графиках. Возникает вопрос, если у нас есть метод для оптимизации параметров системы управления, можно ли оптимизировать не коэффициенты ПИД регулятора, а сам объект управления? Другими словами, не подбирать регуляторы для явно неудачной системы, а подобрать параметры самой системы. Ведь для компьютерной модели что коэффициенты ПИД, что размеры конструкции – это просто переменные, которые можно менять.