Низовая автоматика что это

Проектирование автоматизации и диспетчеризации инженерных систем

Постановление Правительства РФ от 16.02.2008 г. № 87 (ред. от 07.07.2017 г.) «О составе разделов проектной документации и требованиях к их содержанию», пункт 19. Подраздел «Отопление, вентиляция и кондиционирование воздуха, тепловые сети» гласит, что в проекте должны быть указаны описания систем автоматизации и диспетчеризация процесса регулирования отопления, вентиляции и кондиционирования воздуха.

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

О проектировании собственной автоматики инженерных систем

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

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

Решения для автоматизации инженерных систем разрабатываются при проектировании данных систем и размещаются именно в этом проекте в виде схем и описаний.

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

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

Решения по автоматизации в проектах не содержат сведений о прокладке кабелей собственной автоматики

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

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

О проектировании сетей автоматизации и диспетчеризации

Дело в том, что в проектах инженерных систем внимание сконцентрировано на проектировании инженерного оборудования. Автоматика в данных проектах является одним из элементов создаваемой системы (занимает один из разделов проекта ОВК и ВК), а линии и кабели этой автоматики, тянущиеся по всему зданию — это, вообще, дело десятое. Часто эти слаботочные кабели прокладывают сами инженеры, которые занимаются автоматикой, пуском и наладкой инженерных систем на основании схем автоматизации оборудования из проектов.

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

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

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

Проект сети автоматизации и диспетчеризации ≠ проект системы управления

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

На заметку: без системы управления или в случае ее отказа (она же система «Умный дом») автоматика будет работать локально в каждой инженерной системе.

Если проекта сети автоматизации и диспетчеризации нет

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

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

Ключевые особенности проектирования автоматизации и диспетчеризации

Низовая автоматика может работать отдельно без верхнего уровня и системы управления, а вот если их объединить (к примеру, для управления использовать не локальные контроллеры инженерных систем Conductor Swegon, а главный контроллер AMX или Crestron), такого не произойдет. Если главный контроллер выйдет из строя, то управление нарушится во всех системах.

Особенность проектирования системы электроснабжения и освещения

Особенность проектирования сети автоматизации и диспетчеризации для системы электроснабжения и освещения заключается в необходимости учета коэффициента сложности, так как под схему «звезда» и «классическую» проекты существенным образом отличаются по объему работ.

В схеме «звезда» кабелей больше — проект сложнее

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

Схема «звезда» — для системы управления

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

Источник

Глава 4. УРОВЕНЬ НИЗОВОЙ АВТОМАТИЗАЦИИ

РАСПРЕДЕЛЕННЫХ СИСТЕМ УПРАВЛЕНИЯ

Классификация и аппаратные средства промышленных контроллеров.

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

к локальной сети (к АРМ оператора и другим контроллерам)

к датчикам и исполнительным механизмам

Рис. 4.1. Базовые функции промышленного контроллера.

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

Модульные контроллеры состоят из общей корзины (шасси), в которой располагаются модуль центрального процессора и сменные модули ввода-вывода. Состав модулей выбирается пользователем в зависимости от реальной задачи. Типовое число слотов для сменных модулей – от 8 до 32. В состав контроллера входят также модуль питания, коммуникационные модули, а также удаленные модули ввода-вывода в отдельных корпусах, которые подключаются к контроллеру по сети (обычно на основе интерфейса RS-485) и могут быть расположены на расстоянии до 1,2 км от процессорного модуля.

PC-base или РС-совместимые контроллеры составляют отдельный класс программируемых контроллеров, значение и роль которых с развитием Internet-технологий существенно возрастает, особенно в распределенных системах управления. К основным отличительным особенностям таких контроллеров можно отнести:

¾ наличие встроенной операционной системы (Windows 9x/NT/CE, MS DOS, Linux, Mini OS7, OS-9 и др.);

¾ возможность использования стандартного программного обеспечения SCADA-систем: TRACE MODE, Master SCADA, In Touch, Citect, GENESIS – 32, ISa GRAF, Си, Турбо СИ, Си ++ и др.;

¾ наличие коммуникационных стандартов;

¾ наличие ОРС-серверов и РС-совместимых функций.

PC-base контроллеры могут использовать программное обеспечение

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

По числу каналов ввода-вывода контроллеры делятся на следующие группы [72]:

¾ нано-контроллеры, менее 16-ти каналов;

¾ микроконтроллеры, от 16-ти до 100 каналов;

¾ средние контроллеры, от 100 до 500 каналов;

¾ большие контроллеры, более 500 каналов.

По конструктивному исполнению и способу крепления контроллеры делятся:

¾ панельные, для монтажа на панель или дверцу шкафа;

¾ для монтажа на DIN-рейку внутри шкафа;

¾ для крепления на стене;

¾ стоечные, для монтажа в стойке;

¾ бескорпусные (обычно одноплатные) для применения в специализированных конструктивах производителей оборудования (ОЕМ-контроллеры).

По области применения контроллеры делятся:

¾ для управления роботами;

¾ для управления позиционированием и перемещением;

По способу программирования контроллеры делятся:

¾ программируемые с лицевой панели контроллера;

¾ программируемые переносным программатором;

¾ программируемые с помощью дисплея, мышки и клавиатуры;

¾ программируемые с помощью персонального компьютера.

Контроллеры могут программироваться на языках МЭК 61131-3,

используются также языки С, С++, Visual Basic.

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

Рис. 4.2. Аппаратные средства промышленных контроллеров.

Рис. 4.3. Аппаратные средства промышленного контроллера Win Con-8000.

Контроллер поддерживает все модули ввода-вывода сигналов, как с параллельным, так и с последовательным интерфейсом семейства I-8000 и, кроме того, может работать с удаленными модулями ввода-вывода серии I-7000. Все модули обладают удобными съемными клеммными соединителями с винтовой фиксацией внешних проводов.

В отличие от контроллеров I-8000контроллеры серии Win Con-8000 имеют не только интерфейсы RS-232 и RS-485, но и интерфейсы USB и Ethernet, а также интерфейсы VGA PS/2 для подключения клавиатуры, мыши и монитора. Контроллер приобрел функциональность персонального компьютера, что значительно облегчает его программирование и расширяет сферу применения. Отладку и редактирование управляющей программы можно осуществлять непосредственно на контроллере. Кроме того, за счет наличия интерфейсов клавиатуры и монитора, Win Con может совмещать в себе функции контроллера и операторской станции. Достаточно лишь установить SCADA-систему, например TRACE MODE, и контроллер может взять на себя функции современного операторского интерфейса. Контроллер имеет встроенную операционную систему Microsoft Windows CE. NET, которая характеризуется операционной системой реального времени. Интерфейс операционной системы позволяет воспользоваться любыми средствами, предназначенными для создания программы в этой среде, например Visual Basic NET, Visual C#, Embeddtl Visual C++. Контроллер имеет библиотеку программ, в которой реализованы функции работы со всеми внутренними и внешними устройствами контроллера (внутренняя шина, таймер, внешние интерфейсы, модули ввода-вывода и прочее). Имеется подробная инструкция по программированию, имеются примеры программ, написанных на различных языках программирования. Контроллер имеет слот для установки карты памяти формата Compact Flash, на которой сохраняются пользовательские программы. Это значительно упрощает работу. Пользователь может подобрать карту памяти, исходя из своих потребностей в объеме накопителя.

Конфигурация сети на базе промышленного контроллера Win Con-8000 (WinРАС) представлена на рис. 4.4.

Промышленный контроллер Winkon – 8000 (WinРАС).

Источник

Высоконагруженная распределенная система управления современной АЭС

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

Поэтому давайте разбираться, что там есть, как оно все устроено, где основные архитектурные сложности и где в АЭС можно применить модные технологии ML и VR.

Атомная электростанция это:

О спикере: Вадим Подольный (electrovenic) представляет Московский завод Физприбор. Это не просто завод — это прежде всего инжиниринговое бюро, в котором разрабатывается как аппаратное, так и программное обеспечение. Название является данью истории предприятия, которое существует с 1942 года. Это не очень модно, но очень надежно – вот что хотели им сказать.

IIoT на АЭС

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

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

Мы разрабатываем программное обеспечение, которое устанавливается на эти контроллеры, на шлюзовое оборудование. Дальше также, как и везде, у нас есть ЦОДы, локальное облако, в котором происходит обсчет, обработка, принятие решения, прогнозирование и все, что необходимо для того, чтобы функционировал объект управления.

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

Платформа, которая этим управляет – это платформа IoT, про которые многие слышали. Их сейчас немалое количество, наша – очень жестко привязана к реальному времени.

Поверх этого всего строятся механизмы сквозной верификации и валидации, чтобы обеспечить проверку совместимости и надежности. Туда же входит нагрузочное тестирование, регрессионное тестирование, модульное тестирование – все, что вы знаете. Только это делается вместе с железом, которое нами спроектировано и разработано, и ПО, которое работает с этим железом. Решаются вопросы кибербезопасности ( secure by design и т.д.).

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

Система безопасности

Любая АСУ ТП на АЭС резервируется в виде системы безопасности. Энергоблок АЭС рассчитан на то, что на него может упасть самолет. Система безопасности должна обеспечить аварийное расхолаживание реактора, для того чтобы вследствие остаточного тепловыделения, которое возникает из-за бета-распада, он не расплавился, как это произошло на АЭС Фукусима. Там не было системы безопасности, волной смыло резервные дизель-генераторы, и случилось то, что случилось. На наших АЭС такое невозможно, потому что там стоят наши системы безопасности.

Основа систем безопасности – это жесткая логика.

Фактически мы отлаживаем один или несколько алгоритмов управления, которые могут объединяться в функционально-групповой алгоритм, и всю эту историю распаиваем прямо на плату без микропроцессора, то есть получаем жесткую логику. Если когда-нибудь какой-то элемент оборудования нужно будет заменить, у него изменятся уставки или параметры, и потребуется внести изменения в алгоритм его работы – да, придется вынуть плату, на которой распаян алгоритм, и поставить новую. Но зато это безопасно – дорого, но безопасно.

Ниже пример троированной системы диверсной защиты, на которой выполняется алгоритм решения одной задачи системы безопасности в варианте исполнения два из трех. Бывают три из четырёх – это как RAID.

Технологическое разнообразие

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

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

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

Про железо поговорили, перейдем к тому, что всем интереснее – к софту.

Программное обеспечение. Вершок и Корешок

Так выглядит система мониторинга как раз этих шкафов.

Система верхнего уровня (после низовой автоматики) обеспечивает надежный сбор, обработку, доставку информации оператору и другим интересующимся службам. Она должна прежде всего решать главную задачу – в момент пиковых нагрузок уметь все разруливать, поэтому в режиме нормальной эксплуатации система может быть загружена на 5-10%. Остальные мощности фактически работают вхолостую и предназначены для того, чтобы в случае нештатной ситуации все перегрузки мы смогли бы балансировать, распределять, обрабатывать.

Самый характерный пример – турбина. Она дает больше всего информации, и если начинает работать нестабильно, фактически случается DDoS, потому что вся информационная система забивается диагностической информацией с этой турбины. В случае, если QoS плохо отработает, могут возникнуть серьезные проблемы: оператор просто не увидит часть важной информации.

На самом деле все не так страшно. Оператор может проработать на физическом реактиметре 2 часа, но потерять при этом какое-то оборудование. Для того, чтобы этого не происходило, мы разрабатываем нашу новую программную платформу. Предыдущая версия сейчас обслуживает 15 энергоблоков, которые построены в России и за рубежом.

Программная платформа – это кроссплатформенная микросервисная архитектура, которая состоит из нескольких слоев:

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

Свою систему мы назвали Вершок, а ядро системы Корешок – понятно, почему.

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

Иногда бывает так, что датчики приходится тарировать. Со временем показания плывут, мы знаем, по какому графику во времени они изменят свои показания, и вместо того, чтобы эти датчики менять, уточняем данные и делаем поправки – это называется тарировка датчиков.

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

Кроме того, у нас есть вычислительное ядро. Мы подключаем язык сценариев, умеем работать с Lua, с Python (например, библиотекой PyPy), с JavaScript и TypeScript для решения задач с пользовательскими интерфейсами. Эти задачи мы можем одинаково хорошо выполнять как внутри облака, так и на граничных узлах. Каждый микросервис может запускаться на процессоре абсолютно любого объема памяти и любой мощности. Просто он будет обрабатывать тот объём информации, который возможно на текущих мощностях. Но система одинаково работает абсолютно на любом узле. Она же подходит для размещения на простых IoT устройствах.

Сейчас в эту платформу попадает информация из нескольких подсистем: уровня физической защиты, системы контроля управлением доступом, информация с видеокамер, данные пожарной безопасности, АСУ ТП, IT-инфраструктуры, события информационной безопасности.

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

Выше примеры оборудования, на котором все это работает, и его параметры:

Наши сервисы работают в режиме Multi-Master, нет единой точки отказа, все это кроссплатформенное. Узлы самоопределяются, можно делать Hot Swap, за счет чего можно добавлять и менять оборудование, и нет зависимости от выхода из строя одного или нескольких элементов.

Есть такое понятие, как деградация системы. До определенной степени оператор не должен замечать, что с системой что-то происходит не так: сгорел процессорный модуль, или пропало питание на сервере и он отключился; канал связи перегрузился, потому что не справляется система. Эти и подобные проблемы решается за счет резервирования всех компонентов и сети. Сейчас у нас работают топология «двойная звезда» и mesh. Если какой-то узел выходит из строя, то топология системы позволяет продолжить нормальную работу.

Это сравнения параметров Supermicro (сверху) и нашего контроллера (внизу), которые мы получаем по апдейтам на базе данных реального времени. Цифры 4 и 8 – это количество реплик, то есть база данных поддерживает актуальное состояние всех узлов в реальном масштабе времени – это multicast и real-time. В тестовой конфигурации примерно 10 млн тэгов, то есть источников изменения сигналов.

Supermicro показывает в среднем 7 M/c или 5 М/с, при увеличении числа реплик. Мы боремся, чтобы не терять мощность системы, с ростом числа узлов. К сожалению, когда возникает необходимость обработки уставок и других параметров, мы теряем скорость с увеличением количества узлов, но чем больше узлов, тем потери меньше.

На нашем контроллере (на Atom) параметры на целый порядок меньше.

Пользователю для построения тренда выводится набор тэгов. Ниже touch-ориентированный интерфейс для оператора, в котором он может выбрать параметры. На каждом клиентском узле есть копия базы данных. Разработчик клиентского приложения работает с локальной памятью и не думает о синхронизации данных по сети, просто делает Get, Set через API.

Разработка клиентского интерфейса АСУ ТП не сложнее, чем разработка сайта. Раньше мы боролись за real-time на клиенте, использовали C++, Qt. Сейчас мы от этого отказались и сделали все на Angular. Современные процессоры позволяют поддерживать надежность работы таких приложений. Веб уже достаточно надежен, хотя память, конечно, плывет.

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

Тревога

Тревога – это единственный динамический объект, который появляется в системе. После того, как система запускается, все дерево объектов фиксируется, удалить оттуда ничего нельзя. То есть модель CRUD не работает, можно только сделать пометку «mark as deleted». Если необходимо удалить тэг, он просто помечается и прячется от всех, но не удаляется, потому что операция delete сложная и может повредить состояние системы, ее целостность.

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

Первый вопрос, который возникает, когда случается тревога, кому показывать сообщение о ней. Показывать тревогу двум операторам? Но наша система универсальная, операторов может быть больше. На АЭС “чуть-чуть” отличаются базы данных у турбиниста и у реакторщика, потому что оборудование разное. Понятно, конечно, если уровень сигнала вышел за рамки в реакторном отделении, то это увидит ведущий инженер управления реактором, в турбинном – турбиной.

Но представим, что операторов много. Тогда тревогу всем показывать нельзя. Или если ее кто-то берет под квитирование, ее нужно немедленно блокировать для квитирования на всех остальных узлах. Это real-time операция, и когда два оператора возьмутся квитировать одну и ту же тревогу, они тут же начнут управлять оборудованием и алгоритмами. Все это связано с сетевым многопоточным программированием и может привести к серьезным системным конфликтам. Поэтому любой динамический объект нужно показывать, давать возможность им управлять и “гасить” тревогу только одному оператору.

Более того, все тревоги друг от друга зависят. Какое-нибудь оборудование начинает “глючить” – тысяча тревог выскакивает. На самом деле, чтобы их все погасить, нужно найти только одну из них, ее квитировать, и тогда пропадает “дерево” остальных тревог. Это отдельная наука и мы как раз работаем над тем, как такие тревоги представлять. Единого мнения пока нет: либо дерево, либо прятать как вложенное. Сейчас модуль тревоги выглядит так, с вложенными данными.

Привожу примеры видеокадров, которые видит оператор, для общего представления.

У нас на заводе сделан стенд. Примерно так выглядят дашборды на панели, у оператора примерно то же самое.

Конфигурация системы

Мы предоставляем достаточно универсальный режим работы с базой данных.

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

Видеокадры – это элементы пользовательских интерфейсов, с которыми больше всего проблем. Каждый производитель SCADA/HMI пытается сделать свой редактор, а потом, когда увольняются разработчики, концов не найдешь – появляются баги, все падает, этим невозможно управлять. Нам это надоело, поэтому мы решили: «Делайте, на чем хотите! Хоть на Illustrator, хоть в Sketch – в любой программе, которая выдаст канонический SVG». Мы даём возможность открыть SVG и прицепить его к тегам БДРВ. Если примитивы в редакторе правильно называть, то больше ничего не нужно и все будет нормально работать сразу.

Создание пользовательского интерфейса в АСУ ТП или платформы выглядит не сложнее, чем создание сайта. Мы даем все необходимые API, чтобы это было так. Ни одна другая система, которая сейчас используется на подобных объектах, так не работает, везде есть свои сложные редакторы и убогие интерфейсы. Представляю, каково операторам, которые смотрят на них каждый день. Конечно, многие думают, что не так важно, как это выглядит, главное – безопасность. Но мы хотим, чтобы и выглядело это красиво, потому что, на наш взгляд, это важно.

Как везде, у нас есть система разграничения доступа. Мы поддерживаем несколько режимов, чтобы было надежно и дешево. Кроме контейнерной и обычной виртуализации мы даем возможность сделать Data Lake. Тогда все помещаются в одну большую оперативную память, а режим multitenancy обеспечивает возможность разделения доступа к элементам дерева (объектам, данным). Поэтому можно держать несколько проектов фактически на достаточно недорогом железе.

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

Более того, следует отметить один момент: в режиме реального времени и большого количества объектов в памяти мы не можем работать с кэшем процессора. Он превратился в тыкву, потому что когда нужно обеспечивать навигацию и поиск по 10 или 100 млн объектов, то кэша нет – всё руками.

Прогнозирование

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

Справа график изменения мощности реактора при движении органов регулирования системы управления защитой — стержней регулирования. Вообще реактор регулируется концентрацией борной кислоты в воде, но когда производятся маневры мощности, то используются стержни. Каждое движение стержней – это пережоги топлива, а топливо достаточно дорогое: загрузка современного реактора ВВЭР-1200 примерно 10 тонн диоксида урана.

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

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

В основном есть два метода:

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

Пульт управления

Обычный блочный пульт управления выглядит так.

Слева – Нововоронежская АЭС, справа – Калининская АЭС и модель.

Но мы пошли дальше. Блочный пульт управления – это очень дорогая история. Есть много разработчиков, которые производят и оборудование, и ПО, которое туда сводится – это десятки и сотни компаний. Мы сделали VR-операторскую, загрузили в нее нашу систему.

Надеваешь очки, и получаешь такую же картину, как и на блоке, только без щита. Раньше был БЩУ (блочный щит управления) — оператор шел, крутил какие-то штуки. Потом ему поставили компьютер, он в него смотрел, но все равно вставал к щиту и крутил. Потом мы сделали возможность управления с монитора — БПУ (блочный пульт управления), а теперь – ВПУ (виртуальный пульт управления), за которым будущее.

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

Уже сейчас реализуется такой проект ITER. Сама станция находится в городе Кадараш во Франции, а пульт управления – в Японии в городе Рокасё. Это сделано, чтобы отладить технологии, используется квантовая связь и квантовая криптография. Можно сказать, будущее уже здесь!

Больший уклон в разработку программного и аппаратного обеспечения для интернета вещей мы сделаем на InoThings Conf 4 апреля. В прошлом году были доклады и про IIoT, и про электроэнергию. В этом году планируем сделать программу еще более насыщенной. Пишите заявки, если готовы нам в этом помочь.

Источник