Здравствуйте! Столкнулся при разработке отчета с различиями в данных по времени неработы (на примере ТСРВ024М или М+) для параметров StopWorkTime и тех данных, что мы имеем в параметре DeviceEventDuration.
Сделал отчет, в котором вывел поле DeviceEventDuration.
Как мы видим из картинок и первый вопрос, который бросается в глаза, почему данные в StopWorkTime (на 27.10.2014) = 9.00 часа отличается от показателя по НС 0 (Отключение питания) = 8.8167 часа ?? (Если это некое округление, то это недопустимо!). Никаких других НС на данную дату нет.
Второй вопрос - почему отличаются данные по НС из общего архива - пропажа питания = 8.8019 и НС 0 (сбой по электропитанию) = 8.8167 ?
Точно такие же вопросы на 10.12.2014 ? 15.50 это не 15.6833… Хотя суммарно мы имеем 24.50 + 1032 = 1056.50, что соответствует показателю из StopWorkTime
Дальше еще интереснее! теперь возьмем промежуток времени немного уменьшим, разницу в показаниях вы сами видите (опять же 15.50 это не 15.6833).
Третий вопрос связан с архивом режимов работы (Работа, Наладка) - почему время из DeviceEventDuration = 0.00000 ??? (Архив режимов - 5)
Почему показания по НС 0 = 8.1667 совпали в данном случае с StopWorkTime ?
Отсюда сумма равна 9.383 = 8.1667 + 1.2167 - верно!
В маленькой нижней таблице в Итого я использовал параметр [PeriodLength - длительность действия НС (часы)] из архива Рассчитанные значения.Потребления за время действия НС, но как видно этот параметр насчитывает пустые ячейки зачем то (с 01.10.2014 по 15.10.14 = 360 часов) + 16.93. Какой параметр способен вывести только 16.93 за период без лишних пустых данных (данные не опрошены)?
Еще один пример, непонятно что и как и почему так.
На 26.11 - по НС №6 отключения нет (не участвует), а №5 и 11 = 0.0000???
Хотя на 07.12 - №11 дает нам заветные 0.0167
На 28.11.14 сумма 11 и 26ой дает заветную цифру 4.633, как мы видим №6 не причем.
Чтобы разобраться с проблемой экспортируйте и приложите отчетную форму, а также файлы с экcпортированными суточными данными потребления, показаниями интеграторов и архивом событий для:
устройства № 103484 за период с 24.11.2014 по 25.12.2014,
устройства № 1204469 за период с 01.10.2014 по 02.11.2014,
устройства № 1207637 за период с 27.10.2014 по 12.12.2014.
Вычислитель ТСРВ024М(+) настраивается с учетом отключений ТС по следующим НС:
Из архива по ТВ:
0 - сбой по электропитанию
1 - g>max
4 - отказ ПР
5(11) - отказ датчика давления для ТР1/2
26 - дельта температуры
Из архива смены режима работы:
N - режим наладки
Из архива общего:
1 - пропажа питания; отказ по питанию
Как известно, в архиве ТСРВ024М - 32 флага-поля НС для каждой из 3-х ТС, а так же 4 поля с счетчиками времени для одной или групп НС и отказов (Тпр[n]1,Тпр[n]2,Тпр[n]3,Тпр[n]4, n=1…3) и поле НС с условным обозначением 32 НС (отмечены знаком X в позиции справа-налево начиная с кода 0).
В архиве ТСРВ024М+ количество флагов-полей НС сокращено до 15.
Тпр11 - период действия НС №0 (архив по ТВ) или флаг Ткнс1_0 (для ТСРВ024М)
Тпр12 - период действия следующих НС - №1 или 2 или 4 (архив по ТВ) или соответствующие флаги Ткнс (для ТСРВ024М)
Вот здесь стоит отметить следующий алгоритм (нами он был отработан на Взлет СП в свое время):
В единицу времени возможны сочетания флагов 1 и 4, 2 и 4 (при наличии флага № 4 - все остальные флаги в учет не идут, при отсутствии 4ки - учитывается тот флаг, период действия которого >0 - или 1 или 2, одновременно они не идут никогда)
Наличие g>max(№1) подтверждалось наличием X в поле НС в позиции 2 (------------------------------X-) и период действия получался из поля Тпр12 (для ТСРВ024М+) или Ткнс1_1 (для ТСРВ024М)
Наличие g<min(№2) подтверждалось наличием X в поле НС в позиции 3 (------------------------------X-) и период действия получался из поля Тпр12 (для ТСРВ024М+) или Ткнс1_2 (для ТСРВ024М)
Наличие g<min(№4) подтверждалось наличием Ткнс1_4
Тпр13 - период действия НС №26 (архив по ТВ) или флаг Ткнс1_26
Тпр14 - период действия режима Наладка/Работа (архив смены режимов)
В поле DeviceEventDurations для каждого типа и кода события фиксируется его длительность.
В архиве событий устройства № 1207637 за 27.10.2014 зафиксированы четыре события.
Их них три с кодом 0 относятся к событию типа 1 (по тепловому вводу) и начинаются в 15:11:00.
И одно событие с кодом 1 относится к событию типа 0 (общий системный) и начинается в 15:11:53.
В ЛЭРС УЧЕТ события группируются по типу и коду, поэтому эти четыре события будут сгруппированы в два события.
Первое начинается в 15:11:00 и заканчивается в 24:00:00
Второе начинается в 15:11:53 и заканчивается в 24:00:00
Разница в длительности этих событий равна 53 секундам.
Если взять длительности из DeviceEventDurations, то получим (8.8167 - 8.8019)*3600 = 53.28 сек.
Аналогично для 10.12.2014.
Поле StopWorkTime добавлено в редактор отчетов только для того, чтобы не создавать для него вычисляемого поля.
StopWorkTime = 24 - WorkTime. Это поле никак не связано с длительностями событий устройства.
Чтобы получить длительности перебоев питания для разных типов и кодов событий придется писать соответствующий скрипт, учитывающий специфику работы устройства.
В маленькой нижней таблице в Итого я использовал параметр [PeriodLength - длительность действия НС (часы)] из архива Рассчитанные значения.Потребления за время действия НС, но как видно этот параметр насчитывает пустые ячейки зачем то (с 01.10.2014 по 15.10.14 = 360 часов) + 16.93. Какой параметр способен вывести только 16.93 за период без лишних пустых данных (данные не опрошены)?
Такого параметра нет. Но его легко получить в скрипте. В вашей форме все для этого уже есть.
Во вложении ваша отчетная форма с расчетом суммарного времени остановки счета (см. строки скрипта: 39-40, 87, 207-209). test_stopworktime.lersreport (545 KB)
Благодарю за первую часть ответа, уточню еще раз:
StopWorkTime (на 27.10.2014) = 9.00 часа отличается от показателя по НС 0 (Отключение питания) = 8.8167 часа
Каким образом мне получить адекватность данных, я понял что в данный момент WorkTime по времени не будут соответствовать DeviceEventDurations: 24 - 15 = 9, а показание по НС 0 = 8.8167, где 0.1833 ?? :ne_vi_del:
15.50 это не 15.6833 (а вот здесь эти 0.1833!!) Если я выведу отчет, сузив промежуток времени, получится что мне никак не обосновать время отключения 15.6833 взамен 15.50 в StopWorkTime, а если взамен StopWorkTime использовать сумму значений из DeviceEventDurations , то у меня WorkTime тогда не будет действительным или тогда придется его заменять на 24 - Sum(DeviceEventDurations), все очень усложнено!
WorkTime - это время работы прибора считанное из его архива, поэтому и StopWorkTime жестко связана с этим параметром (StopWorkTime = 24 - WorkTime). Какое время хранится в архиве прибора, такое и будет в поле WorkTime.
Получение данных по событиям устройства надо реализовывать через скрипты. Да сложно, но создать универсальный алгоритм обработки событий пригодный для всех типов поддерживаемых приборов еще сложнее.
Здравствуйте! А удалось разобраться с остальными вопросами?
Ведем разработку приложения интеграции ЛЭРС с программой для ЭнергоСбыта, это несколько тормозит работу.
Для каждого интервала метки времени и каждого сочетания тип-код события алгоритм заполнения поля DeviceEventDurations следующий:
Все события группируются по типу и коду, а затем сортируются по времени их возникновения.
Если в архиве событий есть его длительность, то берется ее значение.
Если длительности нет, ищутся признаки начала и окончания события и по разности их времени возникновения рассчитывается длительность события.
Если признака начала события нет, то длительность считается равной 0.
Согласно присланного вами файла с архивами событий по прибору №1204469 за период с 01.10.2014 по 01.11.2014 для событий Работа и Наладка 22.10.2014 проставлен признак только окончания события, а признака начала этих событий в этом периоде нет.
Поэтому длительность этих событий не определена и проставлена равной 0.
Тогда смотрите, что получается 8.717 - 1.2167 = 7.5 - вопрос какая НС приходится на этот период времени? Ни один код и время в DeviceEventDuration на 22.10 не отражает наличие НС с таким временем действия…
С вашего разрешения будем писать официальный запрос на переработку системы учета НС. Как уже говорил программа интеграции, которые наша организация делает для ЭнергоСбыта подразумевает передачу не только данных потребления, но и должна отражать полную картину по НС, с четким и точным временем работы или не работы вычислителя, для возможности исходя из новой методики вычисления проводить доборы и прочие расчеты на месте. Пока текущее положение вводит в ступор. Поэтому предлагаю совместными усилиями разобраться с вопросом по обработке НС.
Здравствуйте! Обратились к данным во Взлет СП, по этому адресу оказалось еще более интересно. Давайте разберемся, привожу ответ, данные за период и часовые за 22.10.2014.
По суточным данным:
на 21.10.14 / 15,83333 (Tнар) + 8, 16667 (НС №0 из Архива по ТВ, Tпр11) = 24 часа - все прекрасно
на 22.10.14 / 15,283333 (Tнар) + 0,416667 (Режим Наладки из архива смены режимов, Tпр14) + 0,4 (Tпр12 отражает наличие НС 5(11) - Отказ датчика давления) = 16.1, до 24 часов нам не хватает 7.9 часа. НС №0 (Tпр11) = 10.25, получается что вычислитель насчитал и сохранил в архив еще 2,35 часа (???) - встречали такое в работе ТСРВ024М+ несколько раз!
По часовым данным на 22.10.14:
Tнар = 15,28333
На 8:00 / 0,283333+0,616667+0,1 = 1 час - все верно
Смотрим на 7:00 / 0,4 (НС №5(11)) + 0,316667 = 0,716667, до 1 часа работы не хватает 0,283333
Лишние 2,35 насчитаны и суммированы на 7:00
Подтверждаю наличие времени смены режима Работа-Наладка = 0,416667 часа sp.xls (105 KB) sp_hour.xls (58 KB) volkova3-sp.pdf (334 KB)
Здравствуйте! Немного обдумав, пришел к выводу что ваша команда в любом случае будет перерабатывать систему обработки и хранения НС, что уже обсуждалось в теме Интеграторы по времени остановки счета (ВОС), расчетные интеграторы ВОС и ВНР. Вы согласны?
По возможности перезвоню сегодня вам, как “проснусь” и выйду на работу (буквально через 5 часов)
