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

Стандарт (7-3/7-2) чётко определяет, что при q.detailQual.OldData = True q.validity = questionable. Никаких good.
Главы предлагается редактировать?

Хм... Получается, что operatorBlocked автоматом не может быть good.

А про соответствие обработки q.validity = questionable к q.validity = invalid : есть мнение, что лучше отработать защиту ложно, чем не отработать вовсе.

С q.validity = questionable и с "гибким подходом (в зависимости от положения пяток разработчика рза) количество реально ложных срабатываний может неоправданно возрасти. М?

Да

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

Вообще интересны корни этого обсуждения, у кого-нибудь в ПАСе validity=questionable сейчас уже выставляется?

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

В терминале реализовано. Т.к. если для паса это относительно внятно, то для подписчика вообще не ясно что с этим делать. А, например, формулировка questionable  почти good очень хороша и перспективна, но сомнительна.

Учитывая нынешние пожелания ФСК в плане резервирования, questionable с определенными флагами можно расценивать как good при отсутствии альтернативного good. Если дифференциальные токи от такого SV может быть опасно вычислять и использовать (и если что, то ПАС вас предупредил), то фазные - в большинстве случаев вполне можно использовать.
Надо ФСК предложить разработать методические указания по выставлению и  использованию качества.
Вообще условия выставления флагов должны быть четко расписаны в 61850. А не то, что флаги есть, а как их выставлять и что они точно значат в каких случаях - это дело производителя.
То же и AddCause в принципе - частично в стандарте описано некорректно, а вот в попавшейся на просторах google books "iec61850 demystified" сильно похоже на то зачем их придумали, но опять же частично кажется правильнее в стандарте. И кому верить?
А потом на сертификации инженер начинает рассказывать свое видение каких-то явно не описанных моментов и апеллировать некуда.

ПРИВЕТ ✌️

Коллеги, причастные к профилю ФСК, хочу спросить :
Откуда и для чего возникла дискретность токов в SV со значением 0,1 мА?
Напомню, что в LE и в 61869-9 установлено 1 мА, и это первичные (!!!) токи.
Это полное нарушение совместимости что - заградительные меры?

Больше похоже на опечатку

Нет принял Главный метролог Фск Большаков Олег , с точки зрения калибровки которая должна выполняться устройством в 4 раза точнее, для нас получаемых максимальных значений токов  КЗ хватает

Я тоже на это надеялся. Чуть-чуть... :(

Нельзя такую важную характеристику отдавать на рассмотрение одному человеку. Пусть и метрологу.

9-2LE не с бухты барахты толпа людей обсуждала, писала и принимала.

Вот здесь предпосылки к такому решению были изложены. С моей точки зрения предпосылки ложные...

Ознакамливался в свое время с данной статьёй. Всё что я для себя вынес оттуда -  цена младшего бита для токовых значений <измерительных> SV-потоков должна быть 0,1 мА.

Для измерительных.
Допустим.

Причём тут тогда <релейные>?
Мне кажется, не причём, им такая точность излишняя.

Стоит просто разделить <измеренческие> (счётчики) и <релейные> (РЗА) SV-потоки со своими младшими битами для тока и напряжения (при необходимости).

Корпоративный профиль ведь планируется дополнить, корректировать? Может и это стоит учесть?

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