Спасибо, изучу))

А чем WireShark не устраивает?

Или я неправильно понял задачу?

Я хотел узнать какими пользуются профессионалы, кроме скаута, инспектора и шарка.

Минус Wireshark в том, что он не умеет разбирать сетевой траффик в контексте SCL. И если проблема лежит глубже чем, например, инициализация RCB, где-то в самих данных, то для  выявления таких проблем лучше использовать специализированные инструменты, которые умеют сопоставлять траффик с  SCL файлом.

Каждой проблеме требуется свой инструмент для ее решения.

Как верно отмечено, Wireshark трудно накладывается на контекст  SCL и тот же скаут для этих целей гораздо удобнее.
Зато Wireshark незаменим, например, при поиске проблем на L2/L3/L4.
Равно как мультиметр и хорошее обжимное (или сварочник для оптики) хорош для решения проблем на L1.

А можно вопрос по корпоративному профилю ФСК? Там в RBDR сделали обязательным SrcRef. В результате невозможно сделать красиво чисто МЭКовский осциллограф, который может регистрировать дискретные входы терминала в "сыром" виде, т.к. их представления в модели нет.

Можно их вытащить в какой-нибудь системный GGIO, но это неправильно идеологически. Не регистрировать их (а регистрировать уже обработанные сигналы с учётом времени срабатывания/возврата) тоже плохо - не будет видно дребезжания сигнала.

А что мешает сделать описание в терминале дискретных входов/выходов в виде узлов GGIO? Без SrcRef не очень то и красиво, не наглядно. Или не прав?

Не совсем понятно как формальное представление входов может повлиять на логику и правильность регистрации дискретов с этих входов.

Появятся задержки срабатывания и возврата.

Соответственно исчезнет дребезг контактов.

логика работы устройства остается неизменной, добавляется лишь формальное описание/мапинг на мэк. или я чет не так понимаю? А задержки откуда возьмутся? дискрет как был, так и остался. В протокольной части мапинга работы (только лишь в файле SCD)  будут ссылки. У вас же физический сигнал 220, а не GOOSE. Или при добавлении в описание ИЭУ узлов GGIO и формальное описание SrcRef на эти узлы изменят логику работы устройства? Тогда требуется уточнение или понимание логики работы и реализации функции осциллографа и самого ИЭУ. Иначе сложно. О каком терминале речь?

Ну есть у вас физический сигнал блокировки защиты от некоего устройства. И эта блокировка "подрабатывает". На входе в наш терминал у сигнала есть время срабатывания и время возврата. DO работает с сигналом после выдержки времени и выдает на SPS сигнал блокировки уже очищенный. Если регистрировать его, то вот эту "подработку" мы не увидим.

Хорошо, ну тогда не регистрируйте его, регистрируйте тот, который нужно. Я так понял те самые GGIO уже есть, но логика работы существующих DO в данных LN включает предобработку. Но есть некие сигналы, которые Вы собираетесь регистрировать в виде "сырых", так? То есть есть возможность записать "сырой" сигнал, но без SrcRef, либо записать имеющийся DO, но с обработкой и SrcRef, верно? Если да, то можно же в этот GGIO, чисто формально, добавить еще один или несколько DO, которые будут мапиться на сырые сигналы. Или нельзя так?

Можно, но это костыль.

GGIO как раз только для этого и не хочется делать.

Ну почему же, если сырой сигнал в терминале есть, а ICD подразумевает мапинг "возможностей" ИЭУ на МЭК, то вроде как правильно.

Это и пользователи будут путаться и брать сигналы из GGIO, и в GGIO по идее тоже очищенный сигнал будет, чтобы в случае подписки на него не генерировать дребезг по GOOSE.

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