SV
По моему это Рза должно делать. Алгоритму виднее что куда откидывать, это в уставках учитывается.
Size: a a a
2020 November 03
AA
Возник вопрос: а при насыщении трансформаторов или превышении рабочего диапазона должен ли ПАС выставлять какие-то флаги в качество? OutOfRange, inaccurate, overflow? С одной стороны, было бы хорошо проиндицировать нештатную работу, с другой - все начнут откидывать сигнал как плохой.
Если ПАС может какие-то метки осмысленно выдать, то он должен их выдать :) вопрос в сценариях дальнейшего использования этой информации и правильном описании этого в документации... ну и за одно и возможности отключить выставление этой метки если что.
Например, overflow — вполне может ставить, но это не описанный вами случай скорее, это если значение в отведенный размер не влезло... ситуация довольно маловероятная вроде бы.
OutOfRange — в принципе, возможно, если у вас для соответствующего входа какой-то диапазон определен и вне этого диапазона что-то может быть не так.
А вот с Inaccurate надо быть аккуратным — насколько я знаю, все погрешности у нас считаются относительно действующих, а не мгновенных значений, но я не метролог, так что лучше может коллеги прокомментируют.
Например, overflow — вполне может ставить, но это не описанный вами случай скорее, это если значение в отведенный размер не влезло... ситуация довольно маловероятная вроде бы.
OutOfRange — в принципе, возможно, если у вас для соответствующего входа какой-то диапазон определен и вне этого диапазона что-то может быть не так.
А вот с Inaccurate надо быть аккуратным — насколько я знаю, все погрешности у нас считаются относительно действующих, а не мгновенных значений, но я не метролог, так что лучше может коллеги прокомментируют.
AA
Sergei Voronov
По моему это Рза должно делать. Алгоритму виднее что куда откидывать, это в уставках учитывается.
РЗА должно корректно воспринимать информацию о том, что у нас тут проблемы и мы измеряем как можем. Т.е. действующее значение выше уставки точно, но уже может быть меньше реального, т.к. амплитудное не лезет.
Rg
Судя по пункту 6.903.9 61899-9 OutOfRange делать по мгновенному значению? Но тогда в пределах периода часть значений будут "Out" , а часть нет?
AA
Если ПАС может какие-то метки осмысленно выдать, то он должен их выдать :) вопрос в сценариях дальнейшего использования этой информации и правильном описании этого в документации... ну и за одно и возможности отключить выставление этой метки если что.
Например, overflow — вполне может ставить, но это не описанный вами случай скорее, это если значение в отведенный размер не влезло... ситуация довольно маловероятная вроде бы.
OutOfRange — в принципе, возможно, если у вас для соответствующего входа какой-то диапазон определен и вне этого диапазона что-то может быть не так.
А вот с Inaccurate надо быть аккуратным — насколько я знаю, все погрешности у нас считаются относительно действующих, а не мгновенных значений, но я не метролог, так что лучше может коллеги прокомментируют.
Например, overflow — вполне может ставить, но это не описанный вами случай скорее, это если значение в отведенный размер не влезло... ситуация довольно маловероятная вроде бы.
OutOfRange — в принципе, возможно, если у вас для соответствующего входа какой-то диапазон определен и вне этого диапазона что-то может быть не так.
А вот с Inaccurate надо быть аккуратным — насколько я знаю, все погрешности у нас считаются относительно действующих, а не мгновенных значений, но я не метролог, так что лучше может коллеги прокомментируют.
При переполнении мгновенных значений однозначно вылезет погрешность в действующих.
Rg
Идея с указанными флагами логичная. Но пока даже для публикатора она описана в стандартах не достаточно подробно. Не говоря уже о подписчиках потока.
AA
Судя по пункту 6.903.9 61899-9 OutOfRange делать по мгновенному значению? Но тогда в пределах периода часть значений будут "Out" , а часть нет?
Да. И тут начинает разваливаться идея о том, что надо принимать данные только с качеством good.
AA
При переполнении мгновенных значений однозначно вылезет погрешность в действующих.
Нуу... не знаю-не знаю. Если 2 значения из 80 будут иметь погрешность, то из этого не обязательно вытекает, что погрешность действующего значения выйдет за допустимые пределы... по крайней мере, мне так кажется
AA
При переполнении мгновенных значений однозначно вылезет погрешность в действующих.
Хотя невнимательно прочитал - вы написали "при переполнении". При переполнении — скорее всего да. Но, если мне память не изменяет - overflow => invalid. То есть эти данные однозначно в обработку брать нельзя. а вот OutOfRange может быть и на Questionable замеплен и тут вопросы возникают )
AA
А вот если не брать - у нас защита будет работать неправильно.
AA
Если не брать OutOfRange вы имеете в виду?
AA
Да, если OutOfRange не брать
AA
Ну вы у себя "галочку" поставьте в настройках, что делать если OutOfRange и дайте наладчику/проектировщику решить )
АВ
Не там галка стоит
Rg
Subscriber applications shall individually
choose how to use values marked questionable.
choose how to use values marked questionable.
B
Хотя невнимательно прочитал - вы написали "при переполнении". При переполнении — скорее всего да. Но, если мне память не изменяет - overflow => invalid. То есть эти данные однозначно в обработку брать нельзя. а вот OutOfRange может быть и на Questionable замеплен и тут вопросы возникают )
Решили же что questionable=invalid