YY
Vladimir A
В общем опросе нет метки времени
Выставить недостоверность метки
Size: a a a
2019 July 04
VA
Yuriy Yaranskiy
Выставить недостоверность метки
Её вообще нет. Вы не можете даже предположить когда этот сигнал изменился. Может час назад, а может год назад
YY
Vladimir A
Её вообще нет. Вы не можете даже предположить когда этот сигнал изменился. Может час назад, а может год назад
Если стоит признак недостоверности метки времени, ей уже не стоит доверять
VA
Yuriy Yaranskiy
Если стоит признак недостоверности метки времени, ей уже не стоит доверять
А какую метку вы хотите поставить? Как вы различите метку времени от устройства с отсутствующей синхронизацией от вашей "выдуманной" метки?
YY
Vladimir A
А какую метку вы хотите поставить? Как вы различите метку времени от устройства с отсутствующей синхронизацией от вашей "выдуманной" метки?
Время общего опроса с признаком недостоверности. И метка времени общего опроса, и устройства с отсутствующей синхронизацией в этом случае будут недостоверны.
Хорошо Владимир, я с вами соглашусь что будет лучше, если сохранять причину.
Хорошо Владимир, я с вами соглашусь что будет лучше, если сохранять причину.
VA
Yuriy Yaranskiy
Время общего опроса с признаком недостоверности. И метка времени общего опроса, и устройства с отсутствующей синхронизацией в этом случае будут недостоверны.
Хорошо Владимир, я с вами соглашусь что будет лучше, если сохранять причину.
Хорошо Владимир, я с вами соглашусь что будет лучше, если сохранять причину.
Ну не со мной а с составителями СТО )
АБ
не то что бы не соглашусь, но выскажу свою точку зрения - ТСы, приходящие по общему опросу, вообще незачем сохранять в базу, или генерировать по ним какие то события
АБ
нет никакого смысла сохранять ТС, у которого нет временной метки
YY
Vladimir A
Ну не со мной а с составителями СТО )
Я соглашаюсь вашими доводами, составители СТО не уточняли для чего сохранять причину передачи )
VA
не то что бы не соглашусь, но выскажу свою точку зрения - ТСы, приходящие по общему опросу, вообще незачем сохранять в базу, или генерировать по ним какие то события
У тебя сохранилось значение 0. Через какое-то время связь разорвалась. При новом установлении связи по общему опросу прилетело значение 1 без метки времени.
Что его выкинуть?
Что его выкинуть?
АБ
нет, не выкинуть. показать на схеме Скады, передать в ЦУС, но событие по нему генерить - неправильно
АБ
потому что нормальные источники данных при разрыве связи буферизуют ТСы, и после установления коннекта передают их с меткой
АБ
и это тоже требование
VA
потому что нормальные источники данных при разрыве связи буферизуют ТСы, и после установления коннекта передают их с меткой
Буфера не безграничны.
АБ
это решаемая проблема. по нормальному буфер должен быть индивидуально для каждого ТСа, чтобы они не затирали друг друга.
VA
это решаемая проблема. по нормальному буфер должен быть индивидуально для каждого ТСа, чтобы они не затирали друг друга.
Я смутно припоминаю буфер на 1000 событий, без конкретизации что это по каждому ТС. Так что один дребезжащий ТС может забить буфер легко и непринуждённо. Понимаю что притянуто за уши.
VA
Даже в 61850 оговаривается размер памяти для буферизированного отчёта (или всех отчётов в устройстве), и он тоже конечный. Но там сделано более правильно. Там введён признак переполнения буфера для отслеживания "возможной потери информации"
АБ
ну и буфер там работает по другому принципу
VA
ну и буфер там работает по другому принципу
Будем считать что буфер из 86150 это логичное развитие идей из 60870
АБ
GI без временной метки в МЭК-104 при старте - это зло. Вполне можно реализовать и другую прикладную логику, когда КП МЭК-104 обязано после старта послать свой срез данных с правильными временными метками, когда события реально происходили.