Версия для печати
- Форум Теплопункта https://teplopunkt.ru/forum/
-- Учет тепла, воды, газа, пара https://teplopunkt.ru/forum//index.php?f=2
--- Система сбора данных и перевод часов https://teplopunkt.ru/forum//index.php?t=994
-- Каханков Андрей написал 1 октября 2010 9:00
Коллеги подскажите. Сталкивался кто-либо с проблемами, связаннными с переводом часов ТС на "летнее" время и обратно, при диспетчеризации УУ. Представляется, что при опросах ТС в ночные часы (близкие к полуночи), при достаточно большом количестве УУ, могут возникнуть непонятки во время перевода стрелок. Можно установить для всех ТС единое "зимнее" время, или я просто что-то выдумываю?
-- Дмитрий Анисимов написал 1 октября 2010 9:06
Вопрос не совсем понятен. Известные мне тепловычислители переводят свои часы на летнее/зимнее время автоматически. Разумеется, в сутки перехода в почасовом архиве оказывается либо 23, либо 25 записей. Это и есть "непонятки"?
А вообще - по идее - теплосчетчики, используемые в составе систем сбора данных, должны обеспечивать возможность установки (синхронизации) часов по внешнему сигналу. Иначе часы, сутки и месяцы у всех могут заканчиваться не в одно и то же время, и общий анализ данных будет не вполне корректен.
-- Дмитрий Анисимов написал 1 октября 2010 10:20
Случай вспомнил недавний. Звонят из Сыктывкара и спрашивают: а вы не могли бы в вычислителях, которые нам отправляете, время ставить наше (московское)? А то у нас они все по вашему (уральскому) работают. А сами, говорю, разве не можете его переставить? 
А что, отвечают, разве можно? 
-- Aндрей Чигинев написал 1 октября 2010 13:42
Попробую изложить вопрос по своему. При массовой диспетчеризации узлов учета, которая у нас сейчас происходит, мы обсуждали заодно проблему перевода таймеров теплосчетчиков на зимнее и летнее время. В итоге пришли к выводу, что нечего ерундой заниматься, и пусть теплосчетчики всегда работают в одном времени - в зимнем, т.к. бОльшая часть отопительного сезона проходит именно в нем. Вопрос скорее носит локальный характер, т.е. если и мы, и потребители будем согласны с этим, то вполне можем принять подобное решение. В чем же состоит вопрос - кто-то из участников форума с подобной проблемой сталкивался и решал ли ее каким-то образом?
-- Гном написал 1 октября 2010 14:52
надо посмотреть.. по моему большинство телосчетчиков автоматически время переводят... поэтому кто бы не был с кем то согласен они все равно переведут как ни крути...
-- Каханков Андрей написал 1 октября 2010 16:52
Не, в большинстве счетчиков есть опция "автоматический перевод часов на "летнее" время". Т.е. можно перевод делать автоматом (по "флажку"), можно вручную, а можно вообще не переводить стрелки. Но вопрос-то конкретизировать достаточно затруднительно (нет исходников для вопроса). А в общем виде Андрей Викторович сформулировал, попробую и я переделать свой вопрос: " У кого-нибудь, когда-нибудь, всплывали-ли подводные камни, в системах сбора данных с узлов учета, связанные с переводом стрелок часов на "летнее" время и обратно?" Дмитрий Леонидович отметил, вполне справедливо, 23 строчки в весеннем отчете и 25 в осеннем, ну тут ничего страшного вроде бы нет?
-- Дмитрий Анисимов написал 1 октября 2010 17:28
Время - это вообще такая штука... Вон я в теме ПОДВАЛ-5 (http://teplopunkt.ru/forum/index.php?t=804&&st=40) архив выложил. В нем в одной строке (выделено желтым) наработка за час - 1,02 часа! Ага, скажет пытливый читатель: глючит ваш вычислитель! Ан нет - это я часы в приборе подводил. 
-- Aндрей Чигинев написал 2 октября 2010 6:41
У нас уже много лет (более 15) работает система технологической диспетчеризации в режиме близком к режиму реального времени. Но это наша внутренняя система и почти никаких приборов учета к ней не подключено - исключительно наши тенологические объекты - ЦТП, НС, узлы сетей и проч. Сервера этой системы и АРМ пользователей синхронизированы по какому-то мировому времени (кажется, через Интернет) и сами следят за состоянием своих часов, подправляют их показания, переводят на летнее-зимнее время и т.д. Что же получается в дни перевода? Никакого 25 часа в день перевода осенью в архиве на сервере не появляется, просто в этот час архивное значение, например, расхода (или любого параметра, где ведется интегрирование) оказывается в примерно два раза больше, чем следует - т.к. реально он накапливается не час, а два. Весной же в день перевода времени, когда в сутках 23 часа, один час оказывается с "пустыми" нулевыми архивными значениями. Если затем так или иначе выполнять автоматизированный анализ часовых архивов, то эти удвоенные и пустые ячейки дадут пусть и небольшое, но все равно никому не нужное искажение результатов.
-- Дмитрий Анисимов написал 2 октября 2010 7:26
Если серверы синхронизируются по времени, а данные с приборов (нижнего уровня) они собирают в режиме on-line, то система работает нормально. Но теплосчетчики по запросу "сверху" обычно выдают "готовые" архивы, выстроенные по часам самих теплосчетчиков.
Поэтому, если часы теплосчетчиков рассинхронизированы (у одного идут точно, у другого - отстали на 5 минут, в третьем и вовсе оказалось время "не того пояса" - недоглядели), то сведение их данных на верхнем уровне получится некорректным. Баланс, как говорится, не сойдется.
Это - основная проблема. А автоматический переход на летнее/зимнее время усугубит ее только тогда, когда в разных теплосчетчиках (например, когда в систему включены приборы разных производителей) он осуществляется по разным "правилам". Ну, например, у одного в сутках стало 25 часов, а у другого - в один из часов "вписаны" данные за два часа.
Любой теплосчетчик (расходомер и пр.), работающий в составе системы, обязательно должен "управляться по времени" извне - с диспетчерского пункта, центрального сервера и т.п. В этом случае и часы у всех всегда будут идти секунда в секунду, и любые переводы времени будут осуществляться по единым для всей системы правилам. А если правила едины и известны, то в чем может быть проблема?
-- Aндрей Чигинев написал 2 октября 2010 7:45
При опросе теплосчетчика кроме архивов запрашиваем и его текущее время, затем сравниваем его с точным временем на сервере и делаем вывод - отклонение находится в допустимых рамках или нет. Если нет, то:
1) либо шлем теплосчетчику команду подвести часы,
2) либо записываем в протокол сервера инфу о том, что у такого-то теплосчетчика сбит таймер, чтобы в ближайшее время подвести эти часы вручную.
Понятно, что лучше первый вариант, осталось только разобраться, можно ли дистанционно через порт теплосчетчика подводить в нем часы.
Осталось еще определиться с допустимыми рамками отклонения локального времени на теплосчетчике от точного времени на сервере.
А что касается изначально заданного вопроса - то по моему надо сделать так: выставить на всех теплосчетчиках "зимнее" время, запретить его перевод в автоматическом режиме, и дело с концом.
-- Дмитрий Анисимов написал 2 октября 2010 8:00
Андрей Чигинев написал:[q]
Осталось еще определиться с допустимыми рамками отклонения локального времени на теплосчетчике от точного времени на сервере.[/q]
Отклонение должно быть таким, чтобы при "подводке" часов в почасовом архиве не получались наработки больше или меньше часа (с учетом того кол-ва знаков после запятой, которое используется в данной системе). Например, в архиве, на который я сослался где-то выше, в результате ручной "подстройки" времени в одной из часовых записей появилась наработка в 1,02 часа. Выглядит, как глюк вычислителя, ведь никакой отметки о подстройке часов в архиве нет. Так и в системе - если при округлении до 2 знаков после запятой допускать отклонение локального времени теплосчетчиков от времени сервера более чем на 0,01 часа - есть шанс получать в почасовых архивах более чем часовые наработки.
А в случае с системой сбора данных, в которой все счетчики синхронизируются извне, лучше зайти с другой стороны. У каждого теплосчетчика точность хода часов нормирована. Берем самый "слабый" с этой точки зрения прибор в системе (если используются приборы разных марок) и, исходя из его "погрешности измерения времени", определяем, через какие интервалы центральный сервер должен посылать своим "абонентам" сигналы точного времени.
-- Каханков Андрей написал 2 октября 2010 8:01
Вообще то, сколько ни придумывай возможных некорректных ситуаций, наверняка, какая-нибудь "фишка" вылезет. Чтобы избежать этих, неизвестных сейчас "фишек", конечно желательно работать в одном времени, естественно и теплосчетчикам, и серверу. При этом желательно (обязательно?) сервером, регулярно (скажем каждый понедельник, либо раз в декаду или в месяц) корректировать часы ТС по часам сервера. И тут согласен с Андреем Викторовичем, возможно ли программно - дистанционно корректировать часы теплосчетчиков? Вопрос к программистам или ко мне?
-- Дмитрий Анисимов написал 2 октября 2010 8:03
Андрей Чигинев написал:[q]
А что касается изначально заданного вопроса - то по моему надо сделать так: выставить на всех теплосчетчиках "зимнее" время, запретить его перевод в автоматическом режиме, и дело с концом. [/q]
Единственный "микронюанс": если летом будете анализировать распределение потребления по часам суток, то статистика будет сдвинута относительно зимы. Т.е. пики и провалы потребления (например, воды) зимой и летом будут приходиться на разные часы суток. Если этот фактор несущественен - тогда проблем нет.
-- Aндрей Чигинев написал 2 октября 2010 8:23
Каханков Андрей написал:[q]
возможно ли программно - дистанционно корректировать часы теплосчетчиков? Вопрос к программистам или ко мне? [/q]
В нашей службе КИПиА полным-полно программистов, которые в т.ч. занимаются и этой самой системой сбора данных. Поэтому я задаю вопрос Вам, а уж Вы там как-нибудь разберитесь - сами будете решать этот вопрос или поручите кому. Но спрашивать я буду точно не у программистов...
Дмитрий Анисимов написал:[q]
Единственный "микронюанс": если летом будете анализировать распределение потребления по часам суток, то статистика будет сдвинута относительно зимы. Т.е. пики и провалы потребления (например, воды) зимой и летом будут приходиться на разные часы суток. Если этот фактор несущественен - тогда проблем нет.[/q]
Пики и провалы потребления в часовых архивах дают неплохую возможность при корреляционном анализе данных выявлять как неисправность приборов, так и несанкционированное потребление или утечки. Сдвиг архивов на час существенно подпортит результаты такого анализа. Но решение достаточно простое - надо иметь не один эталон для сравнения, а два - для зимнего и летнего времени. Поэтому можно считать этот фактор несущественным.
-- Дмитрий Анисимов написал 2 октября 2010 8:37
Андрей Чигинев написал:[q]
В нашей службе КИПиА полным-полно программистов, которые в т.ч. занимаются и этой самой системой сбора данных.[/q]
Да хоть всех программистов мира соберите, но если в теплосчетчике "внешняя" синхронизация по времени не предусмотрена, то эти программисты часы этого теплосчетчика дистанционно не переведут. 
-- Каханков Андрей написал 2 октября 2010 8:44
Хм, так получается, [q]
если в теплосчетчике "внешняя" синхронизация по времени не предусмотрена[/q]
, в схемотехнику надо залезать, а это корректно? Скорей всего нет.
-- Дмитрий Анисимов написал 2 октября 2010 9:34
Не в схемотехнику, а в резидентное программное обеспечение (firmware).
Проще новый теплосчетчик разработать. Опираясь на труды классиков (http://teplopunkt.ru/articles/0005_adl_mod.html) 
-- Каханков Андрей написал 2 октября 2010 11:22
Согласен, можно в программу залезть, а можно и схемотехнически вопрос решить. Ежели есть кнопочка на ТС, с которой производится установка часов, значит вопрос решается и схемно, а не только программно.
-- Дмитрий Анисимов написал 2 октября 2010 11:44
Каханков Андрей написал:[q]
Ежели есть кнопочка на ТС, с которой производится установка часов, значит вопрос решается и схемно, а не только программно. [/q]
XXI век на дворе, Андрей Евгеньевич. Все нажатия "кнопочек на ТС" обрабатываются программно. 
-- Aндрей Чигинев написал 2 октября 2010 14:02
Дмитрий Анисимов написал:[q]
Андрей Чигинев написал:
[q]
В нашей службе КИПиА полным-полно программистов, которые в т.ч. занимаются и этой самой системой сбора данных.
[/q]
Да хоть всех программистов мира соберите, но если в теплосчетчике "внешняя" синхронизация по времени не предусмотрена, то эти программисты часы этого теплосчетчика дистанционно не переведут. [/q]
Согласен и не спорил с этим никогда. А о программистах нашей службы КИПиА речь шла о другом - они или Андрей Евгеньевич будут разбираться с возможностью дистанционного принудительного перевода часов тепловычислителей? Вопрос риторический, поэтому отвечаю - разбираться с этой возможностью будут программисты и некоторые иные отдельно взятые инженеры, а докладывать о результатах - Андрей Евгеньевич. Ни о каких взломах - аппаратных или софтверных даже речи идти не может - если внешняя синхронизация времени не предусмотрена, просто будем переводить таймер теплосчетчика вручную, на месте.
А если где-то предусмотрена - то дистанционно, командой с сервера.
-- Дмитрий Анисимов написал 2 октября 2010 14:08
А-а-а, понял: это у вас тут производственное совещание!
Андрей Чигинев написал:[q]
если внешняя синхронизация времени не предусмотрена, просто будем переводить таймер теплосчетчика вручную, на месте.[/q]
А можно разработать и изготовить некие маленькие дистанционно управляемые манипуляторы, которые по команде сервера будут нажимать кнопки на вычислителях, чтобы установить правильное время, вот.
-- Aндрей Чигинев написал 2 октября 2010 14:16
Дмитрий Анисимов написал:[q]
А можно разработать и изготовить некие маленькие дистанционно управляемые манипуляторы, которые по команде сервера будут нажимать кнопки на вычислителях, чтобы установить правильное время, вот. [/q]
Что же, а это идея! Как мы сразу не додумались до такого? Реализовать это в принципе несложно... С меня бутылка... Нет..., банка... Трехлитровая!!!
-- Дмитрий Анисимов написал 2 октября 2010 14:24
-- Aндрей Чигинев написал 2 октября 2010 15:07
Вот-вот, именно так!... И еще трехлитровая банка тому, кто предложит конкретные варианты связи (разрыв - пунктирная линия на рисунке). Диал-ап (в т.ч. GSM), GPRS, Ethernet и прочие TCP/IP уже охвачены - не предлагать...
-- Дмитрий Анисимов написал 2 октября 2010 17:19
-- Каханков Андрей написал 2 октября 2010 22:16
АДЛ написал:[q]
Проще новый теплосчетчик разработать. Опираясь на труды классиков
[/q]
Читал, хорошая статья. Помнится в году так 99-ом или 2000-ном, молодой человек, если мне память не изменяет, Анисимов Дмитрий Леонидович, на Лачковской конференции, бухтел чтой-то про концепцию, подходы к учету, даже слово "интерфейс" звучало в докладе , я ещё тогда отметил это выступление и Чигиневу говорил, что вот мол на Урале толковые идеи рождаются. Только сдаётся мне, что во время того доклада, все как один производители теплосчетчиков находились в курилке 
-- Каханков Андрей написал 2 октября 2010 22:27
Чигинев написал:[q]
И еще трехлитровая банка тому, кто предложит конкретные варианты связи[/q]
. Андрей Викторович, ты трехлитровыми банками не слишком-то размахивайся, я так понял винограда в этом году не шибко много было
-- написал 2 октября 2010 23:16
-- Дмитрий Анисимов написал 3 октября 2010 8:27
Каханков Андрей написал:[q]
Только сдаётся мне, что во время того доклада, все как один производители теплосчетчиков находились в курилке [/q]
Да, тогда меня не слушали, ибо был молод, теперь не слушают, потому как я всего лишь продавец, только и умеющий, что восхвалять свой товар (так, кажется, было однажды сказано). Ну, может хоть после смерти признают... хоть какие-нибудь заслуги.
-- Aндрей Чигинев написал 3 октября 2010 9:00
Каханков Андрей написал:[q]
Андрей Викторович, ты трехлитровыми банками не слишком-то размахивайся, я так понял винограда в этом году не шибко много было [/q]
То, что должно получиться из винограда, созреет более или менее не раньше Пасхи, а банок трехлитровых и сейчас хоть отбавляй 
-- Каханков Андрей написал 4 октября 2010 8:58
Тема плавно перетекает в пятничный треп, и тем не менее отвечу здесь, не считая себя великим специалистом в виноделии, сдается мне, что месяца три-четыре вполне достаточно для полного сбраживания виноградного сока. Считаем - сентябрь, октябрь, ноябрь, декабрь, ну захватим еще январь, все равно до Пасхи далековато
-- Aндрей Чигинев написал 5 октября 2010 6:58
Каханков Андрей написал:[q]
Тема плавно перетекает в пятничный треп, и тем не менее отвечу здесь, не считая себя великим специалистом в виноделии[/q]
Она скорее перетекает в "Пикничок...".
Если интересно, можно перебраться туда и поговорить об изготовлении вин. Я, кстати, тоже винодел начинающий.
А заданный изначально в теме вопрос, кажется, нашел нормальный ответ...
-- Жульков Владимир написал 5 октября 2010 8:25
Дмитрий Анисимов написал:[q]
Поэтому, если часы теплосчетчиков рассинхронизированы (у одного идут точно, у другого - отстали на 5 минут, в третьем и вовсе оказалось время "не того пояса" - недоглядели), то сведение их данных на верхнем уровне получится некорректным. Баланс, как говорится, не сойдется.[/q]
Баланс не сойдется на каком интервале?
Если на месячном, то плюс-минус час рассинхронизации дадут небаланс в 0,1%. И что дальше?
Наксколько это критично?
-- Дмитрий Анисимов написал 5 октября 2010 11:20
Жульков Владимир написал:[q]
Наксколько это критично? [/q]
Для кого как.
-- Каханков Андрей написал 5 октября 2010 16:22
И что?
-- Дмитрий Анисимов написал 5 октября 2010 17:15
Жульков Владимир написал:[q]
Если на месячном, то плюс-минус час рассинхронизации дадут небаланс в 0,1%.[/q]
Я не думаю, что систему сбора данных строят для того, чтобы раз в месяц "снять" помесячные значения Q и пр. Полезно хотя бы раз в день (несколько дней) считывать содержимое почасовых архивов за эти дни и анализировать именно его. И здесь "плюс-минус час" погубит всю идею.
Да и с чисто теоретической точки зрения система должна жить по единому времени - иначе она уже "не совсем система".
И вот еще на что хотелось бы обратить внимание интересующихся данной темой.
Существуют системы реального времени, где центральный сервер (диспетчерский пункт) периодически опрашивает некие датчики или контроллеры нижнего уровня, получая от них "мгновенные" значения измеряемых параметров, и на основании этих данных сам ведет "архив" (базу данных). Если в такой системе время опроса каждого датчика пренебрежимо мало по сравнению с "темпом процесса", то датчик вообще может не иметь своих часов. Скажем, в 15 часов 20 минут 30,0 секунд сервер послал запрос, в 15 часов 20 минут 30,5 секунды получил ответ - все ясно и понятно. Но если опрос занимает какое-то "заметное" или непредсказуемое время (например, до датчика или контроллера нужно "дозваниваться", связь плохая, идут повторные попытки и т.п.), то опрашиваемый уже просто обязан иметь свои часы, чтобы к посылаемым "в центр" данным добавлять метку времени. И его часы должны быть синхронизированы с часами "диспетчера": в противном случае возможны странные ситуации, когда, например, в 15.20 диспетчер получит от опрашиваемого данные за 15.22.
Но система сбора данных с теплосчетчиков - это вообще не система реального времени. Приходилось слышать рекламные тезисы некоторых разработчиков о том, что, мол, их система опрашивает счетчики ежеминутно, за счет чего обеспечивается он-лайн мониторинг, мгновенное реагирование на аварийные ситуации и т.п. Понятно, что все это чушь. Типичный теплосчетчик, работающий с импульсными преобразователями расхода, за минуту никаких новых данных нам не покажет. Это во-первых. Во-вторых, его так называемые "мгновенные" показания - это результат пересчета кол-ва импульсов, пришедших от преобразователей за некий предыдущий период. Алгоритм этого пересчета у разных вычислителей свой. Так что никакой измерительной информации в "мгновенных значениях" "импульсных" счетчиков нет - следовательно, считывать их нет смысла. Наконец (а может и не наконец) в-третьих при опросе через модемы и прочие "медленные" средства связи "мгновенное значение", которое мы хотели получить в момент запроса, в момент получения ответа уже принадлежит прошлому. Поэтому с теплосчетчиков считываются архивы, т.е. уже подготовленные самим прибором и им же "размеченные по времени" массивы информации. Эти архивы могут быть помесячными, посуточными, почасовыми, да хоть и получасовыми или пятиминутными. Но независимо от их "дискретности", независимо от того, для чего их данные будут использоваться в дальнейшем, независимо от того, какой процент чего-то там может получиться из-за из "разбега" - их время ОБЯЗАНО совпадать со временем сервера (диспетчера). Это ЗАКОН существования системы.
Так вот, зимнее ли время в счетчиках или летнее, московское или лондонское, соответствует оно местному часовому поясу - это, вообще-то, не суть важно. Главное, чтобы во всей системе оно было ЕДИНЫМ. В этом случае данные при любой обработке не "расползутся". А нам именно это и надо.
-- Жульков Владимир написал 6 октября 2010 7:10
Дмитрий Анисимов написал:[q]
Я не думаю, что систему сбора данных строят для того, чтобы раз в месяц "снять" помесячные значения Q и пр.[/q]
Насчет систем сбора информации ничего не скажу, но теплосчетчик, как это не банально звучит, предназначен именно для расчета Q, М и t. И ни к чему дополнительные функции.
В этом случае плюс-минус час не важен.
Если надо анализировать поведение системы по часовым архивам, то чем отличается анализ за период, например, с 10 до 22 часов от анализа с 11 до 23 часов?
-- Дмитрий Анисимов написал 6 октября 2010 9:23
Жульков Владимир написал:[q]
Насчет систем сбора информации ничего не скажу[/q]
А в этой теме обсуждаются именно системы.
-- Serg58 написал 6 октября 2010 18:43
Мне представляется одним из правильных такой подход к синхронизации времени в системе:
1. Часы изначально устанавливаются в отдельных теплосчетчиках более или менее правильно.
2. Синхронизация времени от системы производится подгонкой не времени, а хода часов в пределах допустимой погрешности. ПУТЭ 95 допускают погрешность измерения времени 0.1% - это 3.6 секунды в час. Таким образом, если в теплосчетчике предусмотрены команды управления с заданием ускорения или замедления хода часов в этих пределах, система может подстроить все счетчики под единое время посылая, скажем, раз в сутки команды с заданием отклонения темпа хода часов.
При таком алгоритме не будет переводов часов вызывающих показания учета большие или меньшие чем час (за время нормальной работы), все полные часы работы будут равны 3600 секунд.
На зимнее и летнее время (мое мнение) не надо вообще переводить. Может быть его скоро и отменят вообще? Счетчики работающие в зимнем и летнем времени в одной системе, мне кажется, легко свести для анализа на уровне самой системы, т.к. смещение кратно дискретности архивов.
А по поводу мгновенных значений - есть теплосчетчики не имеющие в составе расходомеров с импульсными выходами, а передающие измеренные значения в вычислитель в цифровом виде. В результате всегда имеются практически "мгновенные" значения всех измеряемых величин (например практически среднее значение расхода за предыдущую секунду показывается в текущей секунде).
-- Aндрей Чигинев написал 7 октября 2010 9:39
С необходимостью перевода часов в теплосчетчиках дважды в год на "зимнее" и "летнее" время вроде бы разобрались - большинство написавших в эту тему считают, что необходимость в этом отсутствует.
Попутно были затронуты несколько сопутствующих вопросов, а именно:
1. Технология подстройки часов в теплосчетчиках,
2. Допустимая величина разбежки часов теплосчетчиков, объединенных в большую информационно-измерительную систему.
Попробую изложить свое мнение в этой части.
Что можно сказать по первому вопросу. Я почему-то уверен, что в большинстве используемых у нас тепловычислителей возможность подстройки часов внешней командой через порт теплосчетчика, откуда снимаются архивы, отсутствует. Либо является недокументированной/секретной/специально-сервисной функцией, широкое оглашение и применение которой недопустимо. По крайней мере пока наши программисты и киповцы утверждают, что в известных им теплосчетчиках эта функция отсутствует, но поиски и исследования на эту тему пока не прекращены. Если такой возможности действительно нет, то остается только один способ - делать это вручную на объекте, что, естественно, требует значительных затрат и не обеспечивает синхронности и точности перевода.
Таким образом, мы выходим на второй вопрос - о допустимой разбежке в показаниях часов у большого количества теплосчетчиков, объединенных в информационную систему.
Пока мне ясна только одна цель, для которой необходимо синхронизировать часы теплосчетчиков - сведение баланса по всей информационной системе, либо по ее части. Для исключения влияния разбежки часов на точность сведения баланса величина этой разбежки должна быть пренебрежимо мала по сравнению с интервалом времени, за который подводится баланс, например, первое к второму должно относиться как 0,1%.
За какие же интервалы времени интересно (актуально) подведение баланса по показаниям множества приборов, объединенных в систему?
- За месяц - почти наверняка, т.к. это расчетный период времени, за который производятся платежи, ведется бухгалтерия и экономика. 0,1% от месяца это (30х24х60)/1000 = 43 минуты. Понятно, что синхронизировать вручную несколько сотен теплосчетчиков с такой точностью вполне реально. Каждый, конечно, решает это для себя сам из наличия имеющихся ресурсов, но для нашей организации, думаю, это вполне подъемная задача.
- За неделю - не уверен в актуальности этого баланса, но, может быть, кому-то и он будет интересен. 0,1% от месяца это (7*24*60)/1000=10 минут. В принципе не превышение такой разбежки часов при их ручной подстройке кажется тоже вполне реальным.
- За сутки - сведение баланса по большой (сотни теплосчетчиков) системе в целом вряд ли актуально. По небольшой (например, приборы на ЦТП и на нескольких домах, подключенных к этому ЦТП) - может быть в чем то и интересно. Но в последнем случае синхронизировать часы нескольких (не более
10) теплосчетчиков в пределах примерно 1,5 минут (0,1% от суток) тоже вполне реализуемо.
Понятно, что объем работы при ручной настройке часов теплосчетчиков будет сильно зависеть от того, насколько сильно они бегут вперед или отстают - то ли каждый день подводить по 100 штук, то ли 1-2 штуки раз в месяц. На эту тему пока нет никакой информации. Надо просто проанализировать разбежку в показаниях часов сервера и опрашиваемых приборов, небольшой массив таких данных есть, просто этим пока никто не занимался. А, похоже, что уже пора начинать...
-- Дмитрий Анисимов написал 7 октября 2010 10:05
Дмитрий Анисимов написал:[q]
Отклонение должно быть таким, чтобы при "подводке" часов в почасовом архиве не получались наработки больше или меньше часа (с учетом того кол-ва знаков после запятой, которое используется в данной системе). Например, в архиве, на который я сослался где-то выше, в результате ручной "подстройки" времени в одной из часовых записей появилась наработка в 1,02 часа. Выглядит, как глюк вычислителя, ведь никакой отметки о подстройке часов в архиве нет. Так и в системе - если при округлении до 2 знаков после запятой допускать отклонение локального времени теплосчетчиков от времени сервера более чем на 0,01 часа - есть шанс получать в почасовых архивах более чем часовые наработки.
А в случае с системой сбора данных, в которой все счетчики синхронизируются извне, лучше зайти с другой стороны. У каждого теплосчетчика точность хода часов нормирована. Берем самый "слабый" с этой точки зрения прибор в системе (если используются приборы разных марок) и, исходя из его "погрешности измерения времени", определяем, через какие интервалы центральный сервер должен посылать своим "абонентам" сигналы точного времени.[/q]
-- Aндрей Чигинев написал 7 октября 2010 11:43
Андрей Чигинев написал:[q]
насколько сильно они бегут вперед или отстают - то ли каждый день подводить по 100 штук, то ли 1-2 штуки раз в месяц.[/q]
Взял данные для двух первых попавшихся теплосчетчиков - показания их собственных часов и часов сервера в момент опроса за две разные даты, разнесенные на 61 день - за 06.08.2010 и за 06.10.2010.
Оказалось, что часы на обоих теплосчетчиках "спешат", причем убегание за два месяца составило на одном 1 мин 22 сек, на втором 1 мин 36 сек. Т.е. в рамках сделанных в предыдущем моем посте предположений разбежка их часов с точным временем за 2 месяца составила примерно величину, критичную только для подведения суточного баланса. Конечно, два прибора из большой массы (сегодня к системе подключено примерно 50 теплосчетчиков, а очень скоро будет более 200 штук) - это совсем не статистика. Теперь дело за малым - надо доработать ПО для анализа этого разбегания и соответствующей своевременной индикации объектов, где эти разбежки приближаются к некоторой критической отметке - пусть для начала это будет 1,5 мин.
-- Serg58 написал 7 октября 2010 18:38
Андрей Чигинев написал:[q]
Я почему-то уверен, что в большинстве используемых у нас тепловычислителей возможность подстройки часов внешней командой через порт теплосчетчика, откуда снимаются архивы, отсутствует.[/q]
Хорошо, назову теплосчетчик, в котором синхронизация от диспетчерской есть - МКТС. Она сделана по описанной мною методике несколько лет назад. Причем для защиты от недоброжелательной критики по поводу влияния на время - это опция включаемая или выключаемая при настройке и отображаемая в меню и нужное состояние закрывается аппаратной защитой и пломбой. Можно посмотреть меню счетчика на его имитаторе (см. раздел "программное обеспечение" этого форума) и убедиться в наличии этой функции. Сделана эта функция была в результате настойчивых просьб компании соседнего с вами региона - фирмы Прософт-системы, т.к. они утверждали, что необходимо одинаковое системное время для их диспетчерской для ЖКХ. В систему включены и многие другие счетчики (список можно посмотреть на их сайте), которые, возможно, также имеют функции поддержания единого времени. По крайней мере слышал, что КМ-5 (уже без нас) тоже был доработан (если не путаю с каким нибудь другим). Так что если, кто имеет связь с этой фирмой, он мог бы рассказать о синхронизации больше узнав о ее опыте (положительном или отрицательном) в этом деле.
-- написал 7 октября 2010 21:28
-- Лев написал 8 октября 2010 5:56
Уважаемый СН, в UTC - это как? Расшифруйте, пжл.
-- Serg58 написал 8 октября 2010 7:43
Всеми́рное координи́рованное вре́мя, UTC (англ. бэкроним Universal Time Coordinated) — основа гражданского времени, отличающегося на целое количество секунд от атомного времени и на дробное количество секунд от UT1.
Это из википедиии http://ru.wikipedia.org/wiki/UTC (http://ru.wikipedia.org/wiki/UTC)
-- написал 8 октября 2010 11:15
-- Лев написал 8 октября 2010 16:59
Спасибо за разъяснения. И сразу на душе полегчало...
-- Каханков Андрей написал 8 октября 2010 17:01
Коллеги, нормальная дискуссия, и все-таки никто на написал, хотя бы в общих чертах, про свою систему сбора данных?
-- Aндрей Чигинев написал 8 октября 2010 19:31
Каханков Андрей написал:[q]
и все-таки никто на написал, хотя бы в общих чертах, про свою систему сбора данных? [/q]
Дык, об этом и вопрос никто не задавал... Мы тут всё об относительности времени рассуждаем...
А о системах сбора данных - Новый вопрос - новая тема ((С) - Администратор)
-- koluhas написал 6 ноября 2011 20:57
Подскажите пожалуйста как можно выставить правильное время и дату на МАГИКЕ, видимо села батарейка внутреннего питания и при аварийном отключении 220 произошел сброс текущих показаний времени.
-- Дмитрий Анисимов написал 7 ноября 2011 9:14
Новый вопрос - новая тема.
http://teplopunkt.ru/forum/index.php?t=734 (http://teplopunkt.ru/forum/index.php?t=734)
2008-2022, Дмитрий Анисимов
Этот форум работает на скрипте Intellect Board
© 2004-2007, 4X_Pro, Объединенный Открытый Проект