Каким должен быть регистратор аварийных событий для цифровых подстанций?
Все мнения, представленные в данной статье – личные мнения каждого специалиста в частности, и никак не отражают позиций компании
В одном из реализуемых проектов (где использовался МЭК 61850-8-1 в части GOOSE и MMS, без МЭК 61850-9-2LE) возникла следующая ситуация: появились ограничения по количеству сигналов, которые можно было выводить с терминалов РЗА для автономного РАС посредством дискретных выходов. Автономный РАС, который использовался на объекте, поддерживал GOOSE (ровно, как и терминалы) и было предложено передавать недостающие сигналы в него по этому протоколу. С другой стороны, возможен и другой вариант передачи недостающих данных в РАС – посредством отчетов (MMS). Возникает вопрос о том, как должен быть реализован сбор сигналов на РАС для такой гибридной конфигурации (передача дискретных сигналов по меди и по цифре в рамках одного энергообъекта):
- Как передавать сигналы в РАС – по GOOSE или посредством отчетов (MMS)? Или комбинировать два способа?
- Если по GOOSE, следует использовать «рабочие сообщения», которые используются терминалами при информационном обмене для выполнения прикладных функций или создавать отдельные сообщения для РАС с теми же сигналами?
- Если по отчетам, использовать буферизируемые/не буферизируемые отчеты?
- Какие требования должны быть предъявлены к набору данных GOOSE/отчетов (количество сигналов в одной посылке (если отдельный GOOSE для РАС), наличие метки времени для самого сигнала, признака качества)?
Вторая часть вопроса касается видоизменения РАС на полноценной цифровой подстанции:
- Как должен изменится функционал РАС на ЦПС с МЭК 61850-8-1 и 9-2?
- Должна ли изменится архитектура (сохранение автономного РАС/использование функций РАС в терминалах/другое)?
- Как должен производиться сбор данных (изменения относительно сбора данных в гибридной конфигурации по первой части вопросов) с учетом наличия измерений в формате МЭК 61850-9-2?
Эти вопросы мы задали специалистам – представителям различных энергетических компаний России, Республики Беларусь и Казахстана.
Максим ГрибковПАО «МОЭСК»Регистратор аварийных событий должен быть независимым устройством, получающим самую объективную информацию с присвоенными метками времени и синхронизированными сигналами. Поэтому на ЦПС с использованием оптических ТТ и ТН передача сигналов в РАС должна осуществляться по GOOSE, в случае применения MU регистратор должен подключаться к аналоговым цепям в шкафу, где установлен MU.
Для обеспечения достоверности данных следует использовать «рабочие сообщения» и при необходимости создавать отдельные сообщения для РАС.
При использовании отдельных GOOSE для РАС, должна быть обеспечена сохранность каждого сигнала, наличие метки времени для самого сигнала, признака качества.
При применении на ЦПС МЭК 61850-8-1 и 9-2 функционал РАС может быть изменен только в сторону повышения информативности. Как упомянуто ранее, на ЦПС с использованием оптических ТТ и ТН передача сигналов в РАС должна осуществляться по GOOSE, в случае применения MU регистратор должен подключаться к аналоговым цепям в шкафу, где установлен MU.
При этом на полноценной ЦПС РАС должен оставаться автономным. Использование функций РАС в терминалах РЗиА возможно только как дополнительная информация. РАС должен быть независимым устройством, имеющим самую объективную информацию с присвоенными метками времени и синхронизированными сигналами, позволяющим выполнить анализ работы как первичного, так и вторичного оборудования.
Регистрация всех сигналов должна осуществляться по всем каналам одновременно и синхронно, независимо от того, какой канал был пусковым.
Андрей ШеметовПАО «ФСК ЕЭС»Вопросы заданные по способам функционирования и функциям РАС для «ЦПС» крайне актуальны. В настоящее время начали реализовываться первые РАС принимающие потоки SV и GOOSE сообщения. Но перед тем как ответить на вопрос как получать информацию в РАС я хотел бы переосмыслить весь подход к РАС, который не менялся с эпохи светолучевых осциллографов.
Задача узнать параметры аварийного режима появилась сразу при появлении релейной защиты для проверки правильности её работы. Для этих задач и для задач ОМП были созданы стрелочные фиксаторы тока 3I0 – АИ2 потом появились ФИП, но этого явно было недостаточно.
Первыми РАС были НО 11 светолучевые осциллографы сохранявшие параметры токов и напряжений на фотоплёнку потом появились НО 13, писавшие на фотобумагу. Апофеозом стали НО 22, писавшие на магнитный барабан токи и напряжения и переводящие потом на бумагу благодаря чему стала возможна запись предаварийного режима небольшой длительности. Все эти устройства были созданы для одного: зафиксировать процесс КЗ, который ранее не фиксировался нигде.
В 90 –х годах 20 столетия начали появляться первые микропроцессорные устройства РАС. Без идеологии со стороны эксплуатации они вылились в различные варианты от «Черного ящика» с 8 аналоговыми входами и распределённой системой установки периферийных блоков до единых систем АУРА с 128 аналоговыми входами, заведёнными в один шкаф. Наличие дискретных входов в устройствах РАС позволяло заводить контакты выходных и указательных реле. Появились указательные реле РУ 21 с герконом на катушке, позволявшие заводить сигнал в РАС. К новым устройствам привыкли быстро, ведь они имели огромные преимущества: нет необходимости закупать фото бумагу и реактивы (к тому времени они стали дефицитны), не нужно делать достаточно сложное техобслуживание, скорость передачи информации по электронным каналам возросла. При появлении микропроцессорных терминалов РЗА с функциями РАС от отдельных РАС не отказались по одной простой причине – новые терминалы были не опробованы и опыт эксплуатации отсутствовал. Так появились решения, где МП терминалы устанавливались рядом с РАС. При этом смотреть осциллограмму терминала РЗА нужно было для понятия процессов терминала, а осциллограмму РАС – для проверки.
Спорность данного решения очевидна. Была нарушена цель создания РАС – зафиксировать процесс, ранее не фиксировавшийся. В настоящее время при расследовании КЗ мы можем оперировать 5-ю и более осциллограммами: три терминала – РЗА, РАС, ОМП. И все фиксируют одно и тоже. Для повторной фиксации тянуться километры кабелей, ставятся шкафы, увеличивается потребление собственных нужд и человеко/часы на обслуживание. Выявить неисправность терминала, можно по осциллограмме второго и третьего терминала, тогда почему РАС остаётся востребованным на современных ПС с переизбытком информации. Основная роль РАС в настоящее время – это расследование аварии по синхронным параметрам токов и напряжений, где возможно одновременно посмотреть токи, напряжения и дискретные сигналы нескольких присоединений привязанные к одному времени, располагая их на одном экране.
Давайте проанализируем, что же представляет из себя «Цифровая ПС» и какой РАС нужен эксплуатации. Нужно отметить что «ЦПС» имеет явный избыток и фиксацию всех параметров работы МП терминалов РЗА. Токи и напряжения поступают от одного дублированного источника по цифре, все дискретные сигналы передаются GOOSE сообщениями и фиксируются в памяти терминала, синхронизация времени улучшилась с 1 мс до 4 мкс. Приём информации на дискретные входы и выдача управляющих воздействий уменьшилась до минимума (положения КА и их исправность, механические защиты маслонаполненного оборудования, управление КА и РПН). При этом все сигналы, передающиеся медными проводами продублированы. Мы имеем терминалы защит, подписанные на два SV потока с возможностью перехода между ними, имеем фиксацию отправки GOOSE—сообщения на терминале РЗА выступающем сервером и имеем фиксацию GOOSE – сообщения на клиенте, то есть фиксация с контролем. С одной стороны уже имеются попытки создать РАС для «ЦПС» – сервер, подписанный на SV потоки и GOOSE—сообщения, записывающий гигабайты информации и выстраивающий все сигналы в одну осциллограмму. С точки зрения традиционных методов РАС всё нормально, тем более что вопрос с ёмкостью жестких дисков давно отпал. Но для анализа технологического нарушения более важно и нужна информация непосредственно с устройств, выдающих управляющие воздействия.
Как я вижу РАС «ЦПС»:
Это программно-аппаратный комплекс выполняющий функцию автоматического скачивания аналоговой и дискретной информации со всех устройств РЗА и сводящий с помощью меток времени в единую осциллограмму. Аналоговые сигналы должны быть представлены без дублирования одних и тех же токов и напряжений одного присоединения с разных устройств. При получении осциллограмм система автоматически должна быть проведена проверка на соответствие однотипных аналоговых сигналов, друг другу, поступивших с разных устройств. При несоответствии аналоговых сигналов должны быть показаны отличия. Дискретные сигналы должны отображаться на осциллограмме с метками времени ухода GOOSE сообщения от терминала РЗА выступающего в роли сервера и приёма сигнала клиентом. При этом необходимо показать время прихода GOOSE сообщения к каждому клиенту. Должна быть подгружена информация о неисправностях и отклонениях в работе терминала РЗ посредством отчетов.
Система РАС должна стать программой, которая берёт информацию из первоисточников (оптических ТТ, электронных ТН, AMU, DMU, терминалов РЗА и т.д.) и сводит её в единую осциллограмму с учётом загруженного SCD файла «ЦПС».
Система РАС должна проверять параметры работы ЦПС: время доставки SV пакетов до клиента, время доставки GOOSE сообщения до клиентов, достоверность параметров SV пакетов и GOOSE сообщений, работу системы синхронизации времени, исправность локальной сети.
С помощью пуска встроенных осциллографов и записи срабатывания пусковых органов защит (МТЗ, ДЗ, ТНЗНП) система должна проверять правильность функционирования терминалов РЗА и построение схемы потокораспределения для проверки функционирования первичных датчиков аналоговых сигналов «ЦПС» и правильности расчёта токов КЗ в ПО «АРМ РЗА».
Действия для создания РАС:
- Создать ТЗ на РАС «ЦПС».
- Выработать новые требования к терминалам защит с учётом требований РАС.
- Создать опытную «ЦПС» и проверить функционирование системы.
Наверняка найдутся противники данной концепции, которые будут утверждать о необходимости дублирования информации, о независимой записи всего и вся. Но я считаю, что потеря какой-то информации крайне маловероятна, так как практически все серверы (источники информации) продублированы.
Исходя из вышесказанного, можно сделать вывод, что система РАС для «ЦПС» должна строится как система для воссоздания последовательности событий в единой осциллограмме и контроля исправности защит.
Евгений РябцевООО «СВЕЙ»При правильной работе всех аппаратных и программных элементов оборудования можно ожидать отсутствия практической разницы между использованием MMS и GOOSE для целей регистрации. Использование GOOSE будет давать некоторое преимущество в доказательной силе, так как при этом регистратор видит те же данные и в то же время, что и все остальные подписчики GOOSE, снимая некоторые потенциальные возможности для разночтений.В свете сказанного выше, лучше всего максимально использовать «рабочие сообщения» и создавать отдельные сообщения для РАС только в той мере, в которой «рабочие сообщения» не обеспечивают полноты информации.
Так как сообщение GOOSE отправляется сразу же после изменения дискретного сигнала, без каких-либо дополнительных задержек, общая метка времени сообщения GOOSE представляется вполне пригодной аппроксимацией момента изменения всех изменившихся с прошлого сообщения сигналов (нам было бы интересно посмотреть на случаи, когда это не так). Признак качества – более интересный вопрос. К сожалению, не вполне понятно что с ним делать. Места в стандартном COMTRADE для него не предусмотрено, а возможные нестандартные расширения именно нестандартны. Я думаю, тут ещё предстоит выработать некий консенсус.
В целом функционал должен остаться тем же, возможно, с некоторыми дополнительными функциями оценки состояния каналов передачи и достоверности поступающей информации.
Использования функций РАС в терминалах не может быть достаточно для полноценной замены автономного РАС без реализации функций одновременного пуска на запись и автоматического «склеивания» полученных осциллограмм. Если эти функции реализованы, то результат это по сути распределённый РАС, который может быть использован вместе с автономным или вместо него, в зависимости от того, кого Заказчик хочет видеть «сторожащим сторожей».
Что касается видоизменения РАС на полноценной цифровой подстанции – то можно говорить только о количественных изменениях вычислительной мощности и пропускной способности интерфейсов; пассивном получении потоков GOOSE и SV.
Максим МальцевПАО «РусГидро»Сигнализация в РАС должна поступать по GOOSE, если сама функция РАС реализована на уровне шины процесса (а это будет правильно).
Целесообразно регистрировать информацию непрерывно, выделяя ее часть по факту наступления аварийного события. Функция РАС должна слушать из сети текущий информационный обмен, отдельные сообщения от терминалов защит в РАС создавать не следует, должны использоваться рабочие сообщения, с метками времени и признаками качества.
Полагаю, что функция РАС останется в виде независимого осциллографа шины процесса. Испытания на Нижегородском полигоне показали необходимость такого осциллографа, непрерывно записывающего потоки 9-2 в шине процесса.
Михаил ШевалдинГПО «Белэнерго»Регистратор аварийных событий (далее – РАС) является одним из камней преткновения в современных реалиях релейной защиты и автоматики (далее – РЗА). Некоторые специалисты активно доказывают, что уже нет никакой необходимости в автономных РАС, так как все требуемые функции уже встроены в цифровые терминалы РЗА, в том числе функции определения места повреждения (ОМП). Другие специалисты, а особенно те, кто уже столкнулся с неправильной работой устройств РЗА, в связи с определенными программными или аппаратными сбоями цифровых устройств, категорически настаивают на обязательной установке именно независимых РАС.
В частности, на одной из ТЭЦ в городе Минске (Беларусь) произошёл аппаратный сбой терминала РЗА ЛЭП 110 кВ, производства одной из ведущих фирм-производителей устройств и аппаратуры РЗА. Микропроцессорный терминал посчитал, что в первичной цепи протекает ток трехфазного короткого замыкания и в соответствии с заданными уставками и алгоритмом работы выдал сигнал на отключение выключателя 110 кВ. Команда на выключатель ушла, и выключатель данного присоединения даже отключился… Но из-за аппаратного сбоя данного терминала устройство продолжило считать, что ток в первичной цепи всё равно есть и могло даже выдать команду УРОВ. Была зима, от шин 110 кВ данной ТЭЦ отходят несколько десятков линий 110 кВ… Трудно даже представить, какие тяжелые последствия имела бы авария в данном случае. Но, благо, УРОВ в Республике Беларусь, на присоединениях 110 кВ выполнен преимущественно централизовано на терминалах ДЗШ, и развития указанной аварии удалось избежать.
Через несколько секунд ток короткого замыкания «исчез» и терминал далее функционировал правильно. Никаких отклонений в его работе послеаварийная проверка не выявила. И если бы не автономный РАС, мы бы не смогли доказать производителю устройства РЗА неправильность работы его устройства. Это лишь один из примеров. Также РАС необходим в процессе анализа крупных аварий с большим числом отключений на одном объекте для правильной оценки работы РЗА. Ещё одной из востребованных функций РАС является наличие функции ОМП, результаты работы которой «релейщики» могут выдать непосредственно дежурному персоналу. А вот разрешать «лезть» в терминалы РЗА за данной информацией для современного оперативного персонала пока рано, в том числе из-за относительно низкой производственной квалификации при их работе с микропроцессорными устройствами РЗА.
Вопрос же от журнала «Цифровая подстанция» стоит немного другой – нужен или нет РАС на новых «цифровых подстанциях»? Тут уже надо принимать во внимание, как организованы аналоговые цепи – с помощью оптических трансформаторов тока и напряжения, или же сигналы от традиционных ТТ и ТН «оцифровываются» с помощью специальных устройств сопряжения. В первом случае, на мой взгляд, организовать отдельные автономные РАС не представляется возможным. РАС всё равно будут подключены к общей шине процесса и будут получать оттуда всю необходимую информацию. Т.е. ни о какой автономности речи уже не идёт, следовательно, наличие отдельного РАС выглядит уже бессмысленным и неоправданным.
Во втором случае, установить РАС можно до условного места преобразования сигнала в «цифровой вид» с помощью специальных устройств сопряжения. В такой ситуации сбор сигналов целесообразно делать в специальном устройстве, установленным непосредственно на ОРУ, а уже с указанного устройства передать данные на общий сервер или центральный модуль. Однако это частный случай (без оптических ТТ и ТН) построения «цифровой подстанции», который, правда, на мой взгляд, будет использоваться еще некоторое время на объектах электроэнергетики Белоруссии и России.
Т.е. уже сама архитектура полноценной «цифровой подстанции» не предполагает наличие автономных РАС. И рассуждать об их наличии/отсутствии представляется, на мой взгляд, довольно непродуктивной задачей.
В процессе анализа аварийных событий необходима точность временных измерений как минимум 1 мс.
Еще хотелось бы прокомментировать вопрос о возможности передачи аналоговых сигналов в РАС посредством отчетов MMS. В процессе анализа аварийных событий необходима точность временных измерений как минимум 1 мс. В то же время, насколько мне известно, общие выборки отчетов MMS формируются с большими периодами дискретизации. Следовательно, получить достоверную информацию для РАС с точностью до 1 мс с помощью сигналов MMS не представляется возможным. Что же касается, так называемых «буферизируемых» отчетов MMS, которые могут «затеряться», если их накопится больше, чем предусмотрена память терминала РЗА, то в таком случае достоверность такой информации вообще ставится под сомнение.
Юрий ИвановООО «Прософт-Системы»Если исходить из того, что смысл работы системы РАС – восстановить фактическую последовательность событий во время аварийного процесса, то необходимо использовать GOOSE—сообщения, поскольку посредством MMS мы можем восстановить (с помощью точных меток времени) только логическую последовательность событий: какие сигналы и в какие времена были сформированы терминалами. Вместе с тем необходимо понимать, что время формирования сигнала отличается от фактического времени его появления в шине процесса и от фактического времени его доставки адресату (времени задержки сети). Фактическую последовательность событий мы можем восстановить только с помощью GOOSE—сообщений и только при наличии нескольких условий. Как показали наши исследования, время задержки сети для двух разных получателей одного и того же GOOSE—сообщения может отличаться самым существенным образом. Если при проектировании шины процесса этот момент (детерминированность времени доставки одного и того же GOOSE—сообщения всем адресатам) не учитывался, то фактические времена приема GOOSE—сообщения регистратором и терминалом будут существенно отличаться. Отсюда вывод: при проектировании шины процесса необходимо учитывать такую сугубо практическую особенность цифровой подстанции, как детерминированность времени получения GOOSE-сообщения всеми адресатами, а также потребности системы РАС.Естественным образом, система РАС должна мониторить «рабочие сообщения». Если терминал будет формировать два РАЗНЫХ сигнала: «рабочее» и для РАС, – то сама система РАС теряет смысл.
Если использовать в системе РАС данные MMS, то этот вопрос становится непринципиальным. Если и делать выбор между буферизируемыми и небуферизируемыми отчетами, то только по соображениям, далеким от задач, решаемых системой РАС.
По нашему мнению, все GOOSE-сообщения должны содержать максимум информации. Неизвестно, что в будущем может понадобиться для анализа аварийного процесса.
Что касается полностью цифровых подстанций, мы считаем, что функционал РАС должен измениться самым существенным образом, и в первую очередь это связано с тем, что в рамках цифровой подстанции появляется такой ключевой элемент, как шина процесса (сеть), которая имеет свои технические характеристики и которые нужно мониторить.
Независимая система РАС должна быть обязательно, мало того, по нашему мнению, ее роль на цифровой подстанции возрастает многократно.
Между гибридной и полностью цифровой конфигурацией нет никакой разницы. Если говорить о применении МЭК 61850-9-2, то в любом случае необходима точная синхронизация времени.
Игорь ВагнерАО «KEGOC»Для передачи сигналов в РАС применимы оба способа в любых сочетаниях, но должны соблюдаться следующие требования: наличие меток времени, минимальная нагрузка на шины передачи данных в момент возникновения аварийного события, архивирование событий в одном файле.
С целью обеспечения абсолютной достоверности данных и снижения нагрузки на шины передачи данных, следует использовать «рабочие сообщения».
При использовании MMS отчеты должны быть буферизируемые.
В случае использования отдельных GOOSE для РАС, несколько сигналов может быть сгруппировано в одну посылку, только при обеспечении сохранности для каждого сигнала собственной метки времени и признака качества.
Функционал классического РАС должен полностью сохраниться, если мы говорим о его использовании на энергообъектах с полноценной шиной процесса.
РАС, а по сути сервер РАС, должен быть «автономным», что обеспечит автоматический сбор сигналов и осциллограмм, их обработку с выдачей отчёта, а также возможность удаленного доступа для ограниченного круга специалистов с целью диагностики, конфигурирования и т.п.
При «пуске» РАС, должны «записываться» все сигналы РАС, независимо от того, изменялись они или нет в заданный период времени.
Алексей ШевелевИЦ «Бреслер»Я считаю, что сигналы в РАС должны передаваться по средством GOOSE—сообщений.Создавать по всей видимости лучше «отдельные сообщения», но в случае, если достаточно «рабочего сообщения», то можно использовать и его. В общем, это вопрос проектный.
Что же касается требований, предъявляемых к набору данных GOOSE, то я думаю, что наличие сигнала и метки времени является обязательным, в отличие от признака качества.
Скорее всего функционал РАС на ЦПС с МЭК 61850-8-1 и 9-2 принципиально никак не изменится. Но это должен быть «монстровый» терминал. Могут быть добавлены новые функции, связанные с ЦПС—решениями.
Что до архитектуры, то вообще – это решение заказчика, но если говорить об автономном РАС, то всё таки неплохо было бы его иметь.
По-моему мнению приём потока SV с учетом наличия измерений в формате МЭК 61850-9-2 должен производиться по отдельным портам.
Основная задача РАС – анализ работы защит. Что может повлиять на работу защит в случае ЦПС? Да теперь, помимо работоспособности самого устройства РЗА, это огромная масса дополнительных факторов, поскольку мы имеем дело с шиной процесса! Если в традиционной ПС после комплексной проверки РЗА на 99.9% ни у кого не возникало вопросов к работоспособности и живучести “каналов передачи сигналов” (что может произойти с сухим контактом и медным кабелем?), то в цифровой ПС эти “каналы” необходимо обязательно контролировать. Какая информация заложена в рабочих GOOSE сообщениях на ЦПС? Пуск УРОВ и АПВ, блокировка АПВ, сигналы телеускорений и телеотключений, команды включения и отключения ну и ещё что-нибудь о первичном оборудовании. Этой информаци далеко не достаточно для оценки работы РЗА. Никуда не исчезли переключатели задания режимов, ввода/вывода защит, испытательные блоки состояние которых нужно контролировать. Есть и другие факторы приводящие к блокировке защит, состояния которых нет в рабочих GOOSE сообщениях (например блокировка функции по какой либо причине, или неисправность самого усторйства). А наличие сформированного GOOSE сообщения в шине процесса врядли скажет о появлении и реакции на него на приёмном устройстве. Помимо отсутствия связи с приёмным устройством, может быть не нулевым флаг качества, да и много чего ещё. Создавать же отдельные GOOSE сообщения для РАС мне кажется неправильным, поскольку увеличится нагрузка на сеть. Вся необходимая информация есть в MMS. Причём отчёты можно получать не только по изменению самого события, но и по изменению качества и метки времени, и эта информация при диагностике работы защит может иметь решающую роль. Для полноты информации нужно иметь в РАС и MMS и GOOSE.
Есть и другие факторы, которые могут повлиять на работу шины просесса и как следствие работу защит. Это состояние коммутаторов. Конечно информация с коммутаторов может быть выведена в АСУТП, но поделится ли ей “дружественная” служба? И вообще диагностики коммутаторов шины процесса может не быть. Релейщик должени иметь возможность контролировать состояние любой составляющей своего комплекса без участия сторонних служб, здесь ему и поможет система РАС, которую теперь можно нагрузить и диагностикой всей системы в целом, включая шину процесса.
Подключать ли РАС напрямую к традиционным кернам ТТ? Если заказчик захочет, то почему бы и нет, поскольку для такого варианта системы РАС существуют уже давно, останется только всю остальную дискретную информацию собрать сухими контактами))). А вот диагностировать неправильную работу MU или шины процесса в части SV в таком варианте не предоставится возможным, поскольку этот “кусок” шины процесса останется для РАС недоступным.
Что касается сетевых коммуникаций для РАС. Считаю, что появление системы РАС ни коим образом не должно повлиять на топологию шины процесса. Конечно же подключение РАС в шину процесса не может производится единственным портом, на который придётся направить весь траффик, но не должно появляться и нового сетевого оборудования, чтобы не усложнять и так теперь не простую эксплуатацию релейщикам. Да и достоверность данных полученных с отдельного сетевого оборудования системы РАС будет под вопросом.
С появлением полноценных ЦПС, появляется необходимость регистрировать не только сами аварийные события, но и шину процесса. Это позволит получить больше информации о её поведении, а следовательно более углублённый опыт эксплуатации ЦПС. И чтобы не создавать новых систем, целесообразно передать все эти функции системе РАС.
Сергей, “А вот диагностировать неправильную работу MU или шины процесса в части SV в таком варианте не предоставится возможным”
При наличии системы РАС с соответствующими интерфейсами и каналами ее можно подключить как к традиционным кернам ТТ, так и к шине процесса, что и позволит контролировать MU и шину.
Даниил, почти полностью с Вами согласен. Если мы будем иметь систему способную отслеживать один и тот же ток как в аналоговом виде так и в SV-потоке, это будет прекрасная диагностика работы MU. Но это потребует больших аппаратных вложений. Одно дело системный блок подключенный в шину процесса и шину станции, а другое дело выносной блок с АЦП на каждое присоединение с длинными каналами связи либо опять длинномеры по токовым цепям по всему ОРУ.
В свете данного обсуждения мне импонирует позиция Шеметова А.C. Система, которую он описывает, с определенными уточнениями, способна решать целый спектр задач. Например, тот же вариант проверки работоспособности MU – через кросс-проверку измерений с резервных комплектов MU и РЗА. Такой комплексный взгляд на систему позволит уйти от необходимости подключать РАС к цепям переменного тока и напряжения, цепям дискретных входов-выходов. И многое другое.