1. Обязательно представиться на русском языке кириллицей (заполнить поле "Имя").
  2. Фиктивные имена мы не приветствуем. Ивановых и Пупкиных здесь уже достаточно.
  3. Не писать свой вопрос в первую попавшуюся тему - вместо этого создать новую тему.
  4. За поиск, предложение и обсуждение пиратского ПО и средств взлома - бан без предупреждения.
  5. Рекламу и частные объявления "куплю/продам/есть халтура" мы не размещаем ни на каких условиях.
  6. Перед тем как что-то написать - читать здесь и здесь, а студентам - обязательно здесь.
  7. Не надо писать в ЛС администраторам свои технические вопросы. Администраторы форума отлично знают как работает форум, а не все-все контроллеры, о которых тут пишут.

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

Обсуждение вопросов, не относящихся ни к одному из других подразделов

Модератор: kirillio

Ответить
Аватара пользователя

Автор темы
servo85
специалист по B&R
специалист по B&R
Сообщения: 157
Зарегистрирован: 15 фев 2014, 23:37
Имя: Волоснов Сергей
Страна: Казахстан
город/регион: Актобе
Благодарил (а): 18 раз
Поблагодарили: 11 раз

РСУ/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.
Последний раз редактировалось servo85 10 сен 2018, 10:46, всего редактировалось 1 раз.
Автоматизация бардака порождает только автоматизированный бардак

Ryzhij
почётный участник форума
почётный участник форума
Сообщения: 5620
Зарегистрирован: 07 окт 2011, 09:12
Имя: Гаско Вячеслав Эриевич
Страна: Россия
город/регион: Рязань
Благодарил (а): 544 раза
Поблагодарили: 706 раз

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

Сообщение Ryzhij »

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

Автор темы
servo85
специалист по B&R
специалист по B&R
Сообщения: 157
Зарегистрирован: 15 фев 2014, 23:37
Имя: Волоснов Сергей
Страна: Казахстан
город/регион: Актобе
Благодарил (а): 18 раз
Поблагодарили: 11 раз

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

Сообщение servo85 »

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

aranea
знаток Eplan
знаток Eplan
Сообщения: 1136
Зарегистрирован: 21 сен 2012, 22:45
Имя: aranea
Благодарил (а): 27 раз
Поблагодарили: 155 раз

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

Сообщение aranea »

servo85 писал(а): 10 сен 2018, 08:46цикл опроса у DCS как правило близок к 1 секунде, и быстротекущие процессы она контролировать может по определению
- пропущено не может
servo85 писал(а): 10 сен 2018, 08:46Foxboro A/I
- вроде Foxboro I/A, если про тот же термин. нынче зовутся Foxboro Evo
Изображение
Аватара пользователя

Автор темы
servo85
специалист по B&R
специалист по B&R
Сообщения: 157
Зарегистрирован: 15 фев 2014, 23:37
Имя: Волоснов Сергей
Страна: Казахстан
город/регион: Актобе
Благодарил (а): 18 раз
Поблагодарили: 11 раз

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

Сообщение servo85 »

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

Ryzhij
почётный участник форума
почётный участник форума
Сообщения: 5620
Зарегистрирован: 07 окт 2011, 09:12
Имя: Гаско Вячеслав Эриевич
Страна: Россия
город/регион: Рязань
Благодарил (а): 544 раза
Поблагодарили: 706 раз

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

Сообщение Ryzhij »

servo85 писал(а): 10 сен 2018, 10:34 Хотя PCS7 и PlantPAx вроде позиционируются производителями как DCS (я не про архитектуру, а про нишу рынка автоматизации).
А я как раз про архитектуру.
Например, в жизни 90% SCADA-софта не разворачиваются как SCADA, а ограничиваются функционалом HMI.
Вот с пакетами софта DCS тоже самое. Даже в своей сетевой конфигурации они редко разворачиваются именно как DCS.
Это как с автомобилями. Мерседес это не всегда лимузин, чаще автобус, грузовик или седан.
---------------------------------------------------
«У человека в душе дыра размером с Бога, и каждый заполняет её как может.» (Жан-Поль Сартр)
"Ту пустоту, которая остаётся в душе, когда в ней нет Бога, и весь мир не может заполнить." (святитель Николай Сербский)
Аватара пользователя

Автор темы
servo85
специалист по B&R
специалист по B&R
Сообщения: 157
Зарегистрирован: 15 фев 2014, 23:37
Имя: Волоснов Сергей
Страна: Казахстан
город/регион: Актобе
Благодарил (а): 18 раз
Поблагодарили: 11 раз

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

Сообщение servo85 »

Ryzhij писал(а): 10 сен 2018, 11:02 Вот с пакетами софта DCS тоже самое. Даже в своей сетевой конфигурации они редко разворачиваются именно как DCS.
Это понятно, что редко. Но впринципе возможно? Или производители PCS7 и PlantPAx лукавят?

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

Ryzhij
почётный участник форума
почётный участник форума
Сообщения: 5620
Зарегистрирован: 07 окт 2011, 09:12
Имя: Гаско Вячеслав Эриевич
Страна: Россия
город/регион: Рязань
Благодарил (а): 544 раза
Поблагодарили: 706 раз

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

Сообщение Ryzhij »

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

Отправлено спустя 59 минут 56 секунд:
servo85 писал(а): 10 сен 2018, 11:44 Это понятно, что редко. Но впринципе возможно? Или производители PCS7 и PlantPAx лукавят?
Возможно. Только централизация тут не при чём.
---------------------------------------------------
«У человека в душе дыра размером с Бога, и каждый заполняет её как может.» (Жан-Поль Сартр)
"Ту пустоту, которая остаётся в душе, когда в ней нет Бога, и весь мир не может заполнить." (святитель Николай Сербский)
Аватара пользователя

Автор темы
servo85
специалист по B&R
специалист по B&R
Сообщения: 157
Зарегистрирован: 15 фев 2014, 23:37
Имя: Волоснов Сергей
Страна: Казахстан
город/регион: Актобе
Благодарил (а): 18 раз
Поблагодарили: 11 раз

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

Сообщение servo85 »

Ryzhij писал(а): 10 сен 2018, 12:56 Возможно. Только централизация тут не при чём.
В случае с PlantPAx контроллеры могут обмениваться данными "по горизонтали", без участия сервера?
Автоматизация бардака порождает только автоматизированный бардак

Ryzhij
почётный участник форума
почётный участник форума
Сообщения: 5620
Зарегистрирован: 07 окт 2011, 09:12
Имя: Гаско Вячеслав Эриевич
Страна: Россия
город/регион: Рязань
Благодарил (а): 544 раза
Поблагодарили: 706 раз

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

Сообщение Ryzhij »

servo85 писал(а): 10 сен 2018, 14:08 В случае с PlantPAx контроллеры могут обмениваться данными "по горизонтали", без участия сервера?
Могут. Как запрограммируете, так и будет. Контроллеры вообще "на другом этаже" системы живут.
Помимо прочего, PlantPAx предоставляет удобные средства для реконфигурации новых версий контроллеров "на лету".
---------------------------------------------------
«У человека в душе дыра размером с Бога, и каждый заполняет её как может.» (Жан-Поль Сартр)
"Ту пустоту, которая остаётся в душе, когда в ней нет Бога, и весь мир не может заполнить." (святитель Николай Сербский)
Аватара пользователя

Автор темы
servo85
специалист по B&R
специалист по B&R
Сообщения: 157
Зарегистрирован: 15 фев 2014, 23:37
Имя: Волоснов Сергей
Страна: Казахстан
город/регион: Актобе
Благодарил (а): 18 раз
Поблагодарили: 11 раз

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

Сообщение servo85 »

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

VADR
администратор
администратор
Сообщения: 4711
Зарегистрирован: 25 июл 2008, 07:12
Имя: Диев Александр Васильевич
Страна: Россия
город/регион: г. Сегежа, Карелия
Благодарил (а): 192 раза
Поблагодарили: 336 раз

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

Сообщение VADR »

servo85 писал(а): 10 сен 2018, 15:11 Отлично. Осталось получить отзыв на этот счет от специалиста по PCS7. Ну или по любой другой аналогичной системе.
Я не есть большой специалист по Симатикам вообще и по PCS7 в частности, но насколько мне известно, PCS7 работает на 400-й серии симатиков. А она умеет общаться "по горизонтали", причём в разных вариантах (впрочем, как и 300-я, 1200-я, 1500-я, насчёт 200-й не уверен).
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
Аватара пользователя

Автор темы
servo85
специалист по B&R
специалист по B&R
Сообщения: 157
Зарегистрирован: 15 фев 2014, 23:37
Имя: Волоснов Сергей
Страна: Казахстан
город/регион: Актобе
Благодарил (а): 18 раз
Поблагодарили: 11 раз

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

Сообщение servo85 »

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

Автор темы
servo85
специалист по B&R
специалист по B&R
Сообщения: 157
Зарегистрирован: 15 фев 2014, 23:37
Имя: Волоснов Сергей
Страна: Казахстан
город/регион: Актобе
Благодарил (а): 18 раз
Поблагодарили: 11 раз

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

Сообщение servo85 »

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

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

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


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

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

Jackson
администратор
администратор
Сообщения: 17471
Зарегистрирован: 17 июн 2008, 16:01
Имя: Евгений свет Брониславович
Страна: Россия
город/регион: Санкт-Петербург
Благодарил (а): 749 раз
Поблагодарили: 1277 раз

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

Сообщение Jackson »

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

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

Alexey_BH
здесь недавно
здесь недавно
Сообщения: 22
Зарегистрирован: 16 дек 2022, 10:13
Имя: Алексей
Благодарил (а): 3 раза
Поблагодарили: 2 раза

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

Сообщение 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.
Ответить

Вернуться в «Общие вопросы»