Каханков Андрей написал:

[q]

Тема плавно перетекает в пятничный треп, и тем не менее отвечу здесь, не считая себя великим специалистом в виноделии

[/q]

Она скорее перетекает в "Пикничок...".
Если интересно, можно перебраться туда и поговорить об изготовлении вин. Я, кстати, тоже винодел начинающий.
А заданный изначально в теме вопрос, кажется, нашел нормальный ответ...

Жульков Владимир написал:

[q]

Наксколько это критично?

[/q]

Для кого как.

Жульков Владимир написал:

[q]

Если на месячном, то плюс-минус час рассинхронизации дадут небаланс в 0,1%.

[/q]

Я не думаю, что систему сбора данных строят для того, чтобы раз в месяц "снять" помесячные значения Q и пр. Полезно хотя бы раз в день (несколько дней) считывать содержимое почасовых архивов за эти дни и анализировать именно его. И здесь "плюс-минус час" погубит всю идею.

Да и с чисто теоретической точки зрения система должна жить по единому времени - иначе она уже "не совсем система".


И вот еще на что хотелось бы обратить внимание интересующихся данной темой.

Существуют системы реального времени, где центральный сервер (диспетчерский пункт) периодически опрашивает некие датчики или контроллеры нижнего уровня, получая от них "мгновенные" значения измеряемых параметров, и на основании этих данных сам ведет "архив" (базу данных). Если в такой системе время опроса каждого датчика пренебрежимо мало по сравнению с "темпом процесса", то датчик вообще может не иметь своих часов. Скажем, в 15 часов 20 минут 30,0 секунд сервер послал запрос, в 15 часов 20 минут 30,5 секунды получил ответ - все ясно и понятно. Но если опрос занимает какое-то "заметное" или непредсказуемое время (например, до датчика или контроллера нужно "дозваниваться", связь плохая, идут повторные попытки и т.п.), то опрашиваемый уже просто обязан иметь свои часы, чтобы к посылаемым "в центр" данным добавлять метку времени. И его часы должны быть синхронизированы с часами "диспетчера": в противном случае возможны странные ситуации, когда, например, в 15.20 диспетчер получит от опрашиваемого данные за 15.22.

Но система сбора данных с теплосчетчиков - это вообще не система реального времени. Приходилось слышать рекламные тезисы некоторых разработчиков о том, что, мол, их система опрашивает счетчики ежеминутно, за счет чего обеспечивается он-лайн мониторинг, мгновенное реагирование на аварийные ситуации и т.п. Понятно, что все это чушь. Типичный теплосчетчик, работающий с импульсными преобразователями расхода, за минуту никаких новых данных нам не покажет. Это во-первых. Во-вторых, его так называемые "мгновенные" показания - это результат пересчета кол-ва импульсов, пришедших от преобразователей за некий предыдущий период. Алгоритм этого пересчета у разных вычислителей свой. Так что никакой измерительной информации в "мгновенных значениях" "импульсных" счетчиков нет - следовательно, считывать их нет смысла. Наконец (а может и не наконец) в-третьих при опросе через модемы и прочие "медленные" средства связи "мгновенное значение", которое мы хотели получить в момент запроса, в момент получения ответа уже принадлежит прошлому. Поэтому с теплосчетчиков считываются архивы, т.е. уже подготовленные самим прибором и им же "размеченные по времени" массивы информации. Эти архивы могут быть помесячными, посуточными, почасовыми, да хоть и получасовыми или пятиминутными. Но независимо от их "дискретности", независимо от того, для чего их данные будут использоваться в дальнейшем, независимо от того, какой процент чего-то там может получиться из-за из "разбега" - их время ОБЯЗАНО совпадать со временем сервера (диспетчера). Это ЗАКОН существования системы.


Так вот, зимнее ли время в счетчиках или летнее, московское или лондонское, соответствует оно местному часовому поясу - это, вообще-то, не суть важно. Главное, чтобы во всей системе оно было ЕДИНЫМ. В этом случае данные при любой обработке не "расползутся". А нам именно это и надо.

Жульков Владимир написал:

[q]

Насчет систем сбора информации ничего не скажу

[/q]

А в этой теме обсуждаются именно системы.

С необходимостью перевода часов в теплосчетчиках дважды в год на "зимнее" и "летнее" время вроде бы разобрались - большинство написавших в эту тему считают, что необходимость в этом отсутствует.
Попутно были затронуты несколько сопутствующих вопросов, а именно:
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 штуки раз в месяц. На эту тему пока нет никакой информации. Надо просто проанализировать разбежку в показаниях часов сервера и опрашиваемых приборов, небольшой массив таких данных есть, просто этим пока никто не занимался. А, похоже, что уже пора начинать...