| |
Система сбора данных и перевод часов
Каханков Андрей
Долгожитель форума
Откуда: Тольятти Всего сообщений: 1517 СсылкаДата регистрации на форуме: 6 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 1 октября 2010 9:00
Коллеги подскажите. Сталкивался кто-либо с проблемами, связаннными с переводом часов ТС на "летнее" время и обратно, при диспетчеризации УУ. Представляется, что при опросах ТС в ночные часы (близкие к полуночи), при достаточно большом количестве УУ, могут возникнуть непонятки во время перевода стрелок. Можно установить для всех ТС единое "зимнее" время, или я просто что-то выдумываю? | | |
Дмитрий Анисимов
Администратор
Откуда: Верхняя Салда Всего сообщений: 8269 СсылкаДата регистрации на форуме: 1 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 1 октября 2010 9:06
Вопрос не совсем понятен. Известные мне тепловычислители переводят свои часы на летнее/зимнее время автоматически. Разумеется, в сутки перехода в почасовом архиве оказывается либо 23, либо 25 записей. Это и есть "непонятки"?
А вообще - по идее - теплосчетчики, используемые в составе систем сбора данных, должны обеспечивать возможность установки (синхронизации) часов по внешнему сигналу. Иначе часы, сутки и месяцы у всех могут заканчиваться не в одно и то же время, и общий анализ данных будет не вполне корректен. | | |
Дмитрий Анисимов
Администратор
Откуда: Верхняя Салда Всего сообщений: 8269 СсылкаДата регистрации на форуме: 1 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 1 октября 2010 10:20
Случай вспомнил недавний. Звонят из Сыктывкара и спрашивают: а вы не могли бы в вычислителях, которые нам отправляете, время ставить наше (московское)? А то у нас они все по вашему (уральскому) работают. А сами, говорю, разве не можете его переставить? А что, отвечают, разве можно? | | |
Aндрей Чигинев
Долгожитель форума
Откуда: Тольятти Всего сообщений: 1055 СсылкаДата регистрации на форуме: 5 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 1 октября 2010 13:42
Попробую изложить вопрос по своему. При массовой диспетчеризации узлов учета, которая у нас сейчас происходит, мы обсуждали заодно проблему перевода таймеров теплосчетчиков на зимнее и летнее время. В итоге пришли к выводу, что нечего ерундой заниматься, и пусть теплосчетчики всегда работают в одном времени - в зимнем, т.к. бОльшая часть отопительного сезона проходит именно в нем. Вопрос скорее носит локальный характер, т.е. если и мы, и потребители будем согласны с этим, то вполне можем принять подобное решение. В чем же состоит вопрос - кто-то из участников форума с подобной проблемой сталкивался и решал ли ее каким-то образом? | | |
Гном
Долгожитель форума
Откуда: г. Уфа Всего сообщений: 425 СсылкаДата регистрации на форуме: 31 окт. 2009
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 1 октября 2010 14:52
надо посмотреть.. по моему большинство телосчетчиков автоматически время переводят... поэтому кто бы не был с кем то согласен они все равно переведут как ни крути... | | |
Каханков Андрей
Долгожитель форума
Откуда: Тольятти Всего сообщений: 1517 СсылкаДата регистрации на форуме: 6 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 1 октября 2010 16:52
Не, в большинстве счетчиков есть опция "автоматический перевод часов на "летнее" время". Т.е. можно перевод делать автоматом (по "флажку"), можно вручную, а можно вообще не переводить стрелки. Но вопрос-то конкретизировать достаточно затруднительно (нет исходников для вопроса). А в общем виде Андрей Викторович сформулировал, попробую и я переделать свой вопрос: " У кого-нибудь, когда-нибудь, всплывали-ли подводные камни, в системах сбора данных с узлов учета, связанные с переводом стрелок часов на "летнее" время и обратно?" Дмитрий Леонидович отметил, вполне справедливо, 23 строчки в весеннем отчете и 25 в осеннем, ну тут ничего страшного вроде бы нет? | | |
Дмитрий Анисимов
Администратор
Откуда: Верхняя Салда Всего сообщений: 8269 СсылкаДата регистрации на форуме: 1 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 1 октября 2010 17:28
Время - это вообще такая штука... Вон я в теме ПОДВАЛ-5 архив выложил. В нем в одной строке (выделено желтым) наработка за час - 1,02 часа! Ага, скажет пытливый читатель: глючит ваш вычислитель! Ан нет - это я часы в приборе подводил. | | |
Aндрей Чигинев
Долгожитель форума
Откуда: Тольятти Всего сообщений: 1055 СсылкаДата регистрации на форуме: 5 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 2 октября 2010 6:41
У нас уже много лет (более 15) работает система технологической диспетчеризации в режиме близком к режиму реального времени. Но это наша внутренняя система и почти никаких приборов учета к ней не подключено - исключительно наши тенологические объекты - ЦТП, НС, узлы сетей и проч. Сервера этой системы и АРМ пользователей синхронизированы по какому-то мировому времени (кажется, через Интернет) и сами следят за состоянием своих часов, подправляют их показания, переводят на летнее-зимнее время и т.д. Что же получается в дни перевода? Никакого 25 часа в день перевода осенью в архиве на сервере не появляется, просто в этот час архивное значение, например, расхода (или любого параметра, где ведется интегрирование) оказывается в примерно два раза больше, чем следует - т.к. реально он накапливается не час, а два. Весной же в день перевода времени, когда в сутках 23 часа, один час оказывается с "пустыми" нулевыми архивными значениями. Если затем так или иначе выполнять автоматизированный анализ часовых архивов, то эти удвоенные и пустые ячейки дадут пусть и небольшое, но все равно никому не нужное искажение результатов. | | |
Дмитрий Анисимов
Администратор
Откуда: Верхняя Салда Всего сообщений: 8269 СсылкаДата регистрации на форуме: 1 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 2 октября 2010 7:26
Если серверы синхронизируются по времени, а данные с приборов (нижнего уровня) они собирают в режиме on-line, то система работает нормально. Но теплосчетчики по запросу "сверху" обычно выдают "готовые" архивы, выстроенные по часам самих теплосчетчиков.
Поэтому, если часы теплосчетчиков рассинхронизированы (у одного идут точно, у другого - отстали на 5 минут, в третьем и вовсе оказалось время "не того пояса" - недоглядели), то сведение их данных на верхнем уровне получится некорректным. Баланс, как говорится, не сойдется.
Это - основная проблема. А автоматический переход на летнее/зимнее время усугубит ее только тогда, когда в разных теплосчетчиках (например, когда в систему включены приборы разных производителей) он осуществляется по разным "правилам". Ну, например, у одного в сутках стало 25 часов, а у другого - в один из часов "вписаны" данные за два часа.
Любой теплосчетчик (расходомер и пр.), работающий в составе системы, обязательно должен "управляться по времени" извне - с диспетчерского пункта, центрального сервера и т.п. В этом случае и часы у всех всегда будут идти секунда в секунду, и любые переводы времени будут осуществляться по единым для всей системы правилам. А если правила едины и известны, то в чем может быть проблема? | | |
Aндрей Чигинев
Долгожитель форума
Откуда: Тольятти Всего сообщений: 1055 СсылкаДата регистрации на форуме: 5 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 2 октября 2010 7:45
При опросе теплосчетчика кроме архивов запрашиваем и его текущее время, затем сравниваем его с точным временем на сервере и делаем вывод - отклонение находится в допустимых рамках или нет. Если нет, то: 1) либо шлем теплосчетчику команду подвести часы, 2) либо записываем в протокол сервера инфу о том, что у такого-то теплосчетчика сбит таймер, чтобы в ближайшее время подвести эти часы вручную.
Понятно, что лучше первый вариант, осталось только разобраться, можно ли дистанционно через порт теплосчетчика подводить в нем часы.
Осталось еще определиться с допустимыми рамками отклонения локального времени на теплосчетчике от точного времени на сервере.
А что касается изначально заданного вопроса - то по моему надо сделать так: выставить на всех теплосчетчиках "зимнее" время, запретить его перевод в автоматическом режиме, и дело с концом. | | |
|
Время выполнения скрипта: 0.0652. Количество выполненных запросов: 17, время выполнения запросов 0.0407
|