РСУ/DCS - суть явления

[servo85]

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

Распределенные системы управления (Distributed Control System, РСУ/DCS) предназначены для автоматизации крупных производств непрерывного цикла, в связи с чем к ним предъявляются высокие требования по масштабируемости и отказоустойчивости. Они имеют высокую степень интеграции аппаратных средств и программного обеспечения, и предоставляют инструменты, облегчающие процесс разработки систем управления, такие как готовые библиотеки алгоритмов управления различным технологическим оборудованием и соответствующие элементы операторского интерфейса – графические шаблоны и панели управления (фейсплейты).

[+]

Например, для однонаправленного насоса в библиотеке имеется FBD блок с входами «Пуск», «Стоп», выходами «Запущен», «Остановлен», и фейсплейт с соответствующими виртуальными кнопками и индикаторами. Для насоса с реверсом FBD блок помимо этого будет иметь входы/выходы для задания/отображения направления вращения «Прямое», «Обратное», такие же кнопки и соответствующая индикация будут и на его фейсплейте. Для двух насосов, работающих поочередно, FBD блок будет содержать еще и счетчик наработки часов каждого насоса, а фейсплейт соответствующие индикаторы. Кроме того, функциональные блоки и фейсплейты насосов могут содержать элементы для контроля – давления на выходе насоса, вибрации, температуры подшипников и обмоток его электродвигателя, защиту от «сухого хода» и т.д. Пример с насосом приведен как самый распространенный, реальные библиотеки из комплектов РСУ содержат множество готовых алгоритмов, для управления разным оборудованием в различных отраслях промышленности (нефтянка, горное дело, металлургия, энергетика и т.д).

Такая степень интеграции подразумевает использование и контроллеров, и ПО визуализации одного производителя. Однако отсутствие зоопарка в системах управления – это скорее плюс для предприятия, а в купе с ускорением инжиниринговых работ за счет готовых библиотек и средств визуализации, плюс большой. Это сокращает время разработки системы (а значит и удешевляет ее), так как не требуется дважды настраивать обмен данными между управляющей программой, исполняемой контроллерами и графикой на ЧМИ. В случае же применения связки ПЛК + SCADA, потребовалось бы настраивать сигнатуры сигналов (теги/адреса) для протокола обмена данными сначала на ПЛК, затем в SCADA. А в случае применения между ними ОРС сервера, вообще трижды.

При этом, применение ПЛК любых производителей для локального управления отдельно взятой установкой – абсолютно нормальная практика. Особенно с учетом того что цикл опроса у DCS как правило близок к 1 секунде, и быстротекущие процессы она контролировать не может по определению. Этого от РСУ и не требуется, в подобных случаях процессом управляет быстродействующий ПЛК у которого цикл опроса запросто может составлять 10 мс, а уставки для него будут формироваться в РСУ в режиме каскадного управления.

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

В эпоху медленных процессоров, дорогой памяти, и медленных сетей, передавать весь объем данных контроллеров на сервер, обрабатывать их согласно программе, а затем посылать команды обратно на контроллеры, с приемлемой скоростью было технически не выполнимо. Поэтому обработку данных оставили на локальных контроллерах, без передачи всего их объема «на верх» (на АРМ-ы передается лишь малая часть параметров и с совсем другими требования по быстродействию).

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

Со временем, когда технологические ограничения для построения централизованных систем управления производством исчезли, аргумент отказоустойчивости стал краеугольным, для производителей истинно распределенных DCS. Примером такой РСУ может служить Foxboro I/A (ранее Invensys, ныне Schneider) в которой все данные всех контроллеров по умолчанию доступны другим контроллерам и АРМ-ам системы как глобальные переменные, но некий «центральный сервер» отсутствует в принципе. Это повышает надежность, но требует больших трудозатрат при внесении изменений.

Вторые же, появились в эпоху высокоскоростных сетей, быстрых процессоров и недорогой памяти, и технических причин отказываться от централизованной архитектуры у их производителей не было. Зато, как правило, в их арсенале уже имелись готовые ПЛК и SCADA. И если в DCS истинно распределенного типа, программа управления может быть распределена между несколькими контроллерами, то в централизованных контроллеры выступают в роли удаленного ввода-вывода, а управляющая программа выполняется на сервере. Это создает единую точку отказа, но применение современных средств резервирования (RAID-ы, резервные серверы и каналы связи, и т.д.) снижает вероятность отказа, а удобство управления системой из-за наличия централизованной архитектуры заметно выше по сравнению с истинно распределенной.

Примерами такого подхода, когда на базе имеющихся ПЛК и SCADA создавались централизованные DCS могут послужить Siemens PCS7 и Rockwell PlantPAx. В первом случае были объединены возможности SCADA WinCC и ПЛК серии S7-400 (т.к. вычислительные мощности контроллеров предыдущих серий недостаточны для использования в составе DCS), а во втором SCADA Factory Talk View и ПЛК ControlLogix. РСУ Aprol от B&R так же централизованная, но изначально создавалась не как SCADA, а как программная DSC на базе существующих ПЛК B&R.

[Ryzhij]

Должен огорчить автора: опус "мимо кассы".
Выражение "централизованная DCS(РСУ)" это оксюморон.
Что-то одно - или система управления "централизованная", или она "распределённая".
Информация к размышлению:
1) Наличие удалённой периферии ещё не делает систему распределённой;
2) Интеграция сред разработки (IDE) систем визуализации на АРМ и логической обработки данных в PLC/PAC не является класифицирующим признаком DCS(РСУ).

[servo85]

Ну собственно именно эту мысль я и пытался описать подробно. Видимо не вышло...
Хотя PCS7 и PlantPAx вроде позиционируются производителями как DCS (я не про архитектуру, а про нишу рынка автоматизации).

[aranea]

цикл опроса у DCS как правило близок к 1 секунде, и быстротекущие процессы она контролировать может по определению

- пропущено не может

Foxboro A/I

- вроде Foxboro I/A, если про тот же термин. нынче зовутся Foxboro Evo

[servo85]

Спасибо, исправил.

[Ryzhij]

Хотя PCS7 и PlantPAx вроде позиционируются производителями как DCS (я не про архитектуру, а про нишу рынка автоматизации).

А я как раз про архитектуру.
Например, в жизни 90% SCADA-софта не разворачиваются как SCADA, а ограничиваются функционалом HMI.
Вот с пакетами софта DCS тоже самое. Даже в своей сетевой конфигурации они редко разворачиваются именно как DCS.
Это как с автомобилями. Мерседес это не всегда лимузин, чаще автобус, грузовик или седан.

[servo85]

Вот с пакетами софта DCS тоже самое. Даже в своей сетевой конфигурации они редко разворачиваются именно как DCS.

Это понятно, что редко. Но впринципе возможно? Или производители PCS7 и PlantPAx лукавят?

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

[Ryzhij]

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

Отправлено спустя 59 минут 56 секунд:

Это понятно, что редко. Но впринципе возможно? Или производители PCS7 и PlantPAx лукавят?

Возможно. Только централизация тут не при чём.

[servo85]

Возможно. Только централизация тут не при чём.

В случае с PlantPAx контроллеры могут обмениваться данными "по горизонтали", без участия сервера?

[Ryzhij]

В случае с PlantPAx контроллеры могут обмениваться данными "по горизонтали", без участия сервера?

Могут. Как запрограммируете, так и будет. Контроллеры вообще "на другом этаже" системы живут.
Помимо прочего, PlantPAx предоставляет удобные средства для реконфигурации новых версий контроллеров "на лету".

[servo85]

Отлично. Осталось получить отзыв на этот счет от специалиста по PCS7. Ну или по любой другой аналогичной системе.

[VADR]

Отлично. Осталось получить отзыв на этот счет от специалиста по PCS7. Ну или по любой другой аналогичной системе.

Я не есть большой специалист по Симатикам вообще и по PCS7 в частности, но насколько мне известно, PCS7 работает на 400-й серии симатиков. А она умеет общаться "по горизонтали", причём в разных вариантах (впрочем, как и 300-я, 1200-я, 1500-я, насчёт 200-й не уверен).

[servo85]

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

[servo85]

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

С развитием микроэлектроники СКАДА системы в составе гибридных систем стали претендовать на место РСУ в управлении технологическими процессами.

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

Федоров Ю.Н. - Справочник инженера по АСУТП. Проектирование и разработка 2008 г.
1.22. Номенклатура современных систем управления и защиты, стр. 85-86

Системы, которые я не удачно назвал "централизованными", на самом деле - гибридные.

[Jackson]

В целом, текст правильный, а вот частности могут быть разные.

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

[Alexey_BH]

Внесу некоторые корректировки в сообщение автора.

К сожалению, в России постоянно происходит путаница с термином DCS. Под ним часто российские вендоры (и некоторые западные - такие как B&R) понимают интегрированную среду разработки и визуализации уровня контроллеров и верхнего уровня. Однако это совсем не так - подобные системы на Западе называются PCS (Process Control System). Типичные представители этого класса - это PCS7 от Siemens, APROL от B&R и Альфа-платформа от Атомик-Софт. Ни одна из этих систем не является РСУ.

DCS (РСУ) - это распределенная система управления непрерывными процессами, ориентированная на потребности таких процессов. Очевидно что требования к любой системе управления полностью определяются управляемым технологическим процессом.

У любой РСУ две очень характерные черты, от которых идут все их особенности:

1) Любой ценой не дать незапланированно остановить непрерывный процесс (особенно за счет сбоя самой РСУ).
2) Время для внедрения или модернизации РСУ ограничено коротким временем капремонта (обычно проводится раз в 5 лет).

Что такое цена незапланированной остановки непрерывного процесса? В моей практике из-за дефекта оборудования одного европейского вендора произошла сработка контура противоаварийной защиты одного из крупнейших НПЗ в России. Остановилась одна из технологических установок, а так как они практически все связаны непрерывным технологическим циклом, встал по цепочке весь завод. Тонны промежуточных продуктов переработки улетают на факел НПЗ, ущерб от таких остановов составляет десятки и сотни миллионов рублей. В данном случае были серьезные разборки с поставщиком, вендором и заводом, вендор выплатил колоссальный штраф, полностью убрал эту линейку продукции, плюс вендор попал в черный список у EPC и ген. подрядчика по автоматизации - его решения более не применялись не только на заводах этого заказчика, но более нигде не применялись на десятках заводов по всему миру.

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

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

То есть это довольно крупные с точки зрения физических сигналов проекты, довольно типичные по сигналам ввода-вывода. Здесь же имеет огромную популярность HART и все РСУ его поддерживают - HART ориентирован на диагностику и обслуживание КИП (PRM) с той целью - не допустить сбоя непрерывного процесса.

Отсюда идут все особенности РСУ:

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

2. Тот же ПАЗ, помимо требований к функциональной безопасности, так же одновременно должен обеспечивать соответствующую доступность - именно поэтому ПАЗ от того же &R, который сертифицирован на SIL3, не может применяться в контурах ПАЗ НПЗ, требующих подобный уровень.

3. Отсюда идет интегрированная среда разработки и оператора - максимально быстрое типовое внедрение, минимум человеческого фактора. Вплоть до генерации 90% кода контроллеров из базы данных сигналов (а остальные 10% нестандартных допиливается руками).

4. Гибкость к изменениям походу проекта и ввиду этого, а так же количества сигналов отдельное внимание уделяется кроссировке. На это заложены и аппаратные решения - начиная от системных кабелей (мордочка модуля ввода-вывода контроллеров РСУ традиционно имеет разьем, а не клеммник, к которому подключается готовый кабель, оканчивающийся таким же разъемом, втыкающимся, допустим, в релейную плату) и заканчивая электронным маршаллингом (наборные поканально модули ввода-вывода).

5. Ну и собственно распределенность - одна технологическая установка это порядка десятка тысяч физических сигналов которые надо обрабатывать в единой системе.

6. Специфичная диспетчеризация, мало что общего имеющая с классическими скадами - кто работал с каким-нибудь CentumVP, поймет о чем я. Здесь же встроенные средства управления тысячами алармов, которые идут как цунами при любой аварии, пакеты работы с КИП (через HART), ну и до кучи всякие APC, тренажеры и т.д.

Эти требования диаметрально противоположны тому, что нужно для периодических процессов, именно поэтому PCS не находят особого отклика в этих сферах (там рулят ПЛК и скады), как и в непрерывных процессах (РСУ). Хотя довольно активно применяется в смешанных так как оптимальным образом подходят под них.

Исторически (в 75, кажется, когда появились первые РСУ у Йоки и Ханивела) эти понятия были более разделены. Сейчас разрбаотка контроллеров очень сильно отличается от того что было в 75 - часть того, что ранее было в РСУ, в видоизмененном виде мигрировало в ПЛК (например, распределенный ввод-вывод), что в итоге и привело к появлению продуктов класса PCS.