СПОСОБ И СИСТЕМА СЧИТЫВАНИЯ ДАННЫХ СЧЕТЧИКА КОММУНАЛЬНЫХ УСЛУГ ПО СЕТИ Российский патент 2013 года по МПК G01D4/00 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Настоящее изобретение относится к сетям коммунальных услуг, а конкретнее к системе и способу работы системы управления сетью коммунальных услуг для считывания счетчиков коммунальных услуг.

УРОВЕНЬ ТЕХНИКИ

C12.19 является стандартом ANSI для извлечения и систематизации данных электрического счетчика в табличной форме, и информации, организованной в специальном формате для облегчения дальнейшей обработки.

C12.18 является спецификацией протокола ANSI для сеанса транспортного уровня между сервером (идентифицированным как приложение считывания счетчика) и клиентом C12.19 - счетчиком коммунальных услуг, и включает в себя создание запросов и прием от счетчика C12.19 характерных особенностей данных, содержащихся в таблицах данных C12.19, сохраненных в счетчике.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Счетчик коммунальных услуг может считываться путем отправки запроса на считывание счетчика из приложения считывания счетчика, которое может располагаться на сервере коммунальных услуг или в точке доступа в сеть, к модулю связи, ассоциированному со счетчиком коммунальных услуг. Модуль связи начинает сеанс со счетчиком коммунальных услуг, создает запросы данных от ассоциированного счетчика коммунальных услуг, принимает ответы на запросы данных от счетчика коммунальных услуг, завершает сеанс после того, как принимаются все запрошенные данные. Затем он форматирует данные, принятые счетчиком коммунальных услуг, и передает отформатированный ответ в приложение считывания счетчика.

В одном предпочтительном варианте осуществления используются протоколы, использующие стандарты C12.18 и C12.19 ANSI. Модуль связи открывает сеанс C12.18 с ассоциированным счетчиком коммунальных услуг и создает запросы данных от счетчика, чтобы выполнить запрос на считывание счетчика из приложения считывания счетчика. Ассоциированный счетчик предоставляет данные модулю связи в соответствии со стандартом C12.19. Модуль связи форматирует принятые данные счетчика в ответ, предназначенный для приложения считывания счетчика, и передает отформатированный ответ в приложение считывания счетчика. Данные счетчика форматируются, чтобы позволить приложению считывания счетчика считать и интерпретировать данные, и форматируются в соответствии со стандартом C12.19.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Вышеупомянутые особенности и многие из сопутствующих преимуществ этого изобретения поясняются в нижеследующем подробном описании, иллюстрируемом прилагаемыми чертежами, на которых:

Фиг.1 - блок-схема, иллюстрирующая сеть коммунальных услуг, по которой может быть реализован процесс считывания счетчика, в соответствии с одним возможным вариантом осуществления.

Фиг.2 - блок-схема алгоритма процесса ответа на запрос считывания счетчика, в соответствии с одним возможным вариантом осуществления.

Фиг.3 - блок-схема алгоритма, иллюстрирующая поток информации во время считывания счетчика, в соответствии с одним возможным вариантом осуществления.

Фиг.4 - обобщенная блок-схема примера типичного запроса к серверу коммунальных услуг на данные счетчика C12.19 и аннотированного ответа от модуля связи, в соответствии с одним возможным вариантом осуществления.

ПОДРОБНОЕ ОПИСАНИЕ

Фиг.1 - обобщенная блок-схема, иллюстрирующая систему, где счетчик 110 коммунальных услуг может "считываться" удаленным устройством. Если не указано иное, термин "считывает" или "считывание" счетчика относится к сбору информации от счетчика, которая может включать в себя информацию о предмете потребления и счетчиках коммунальных услуг, или может включать в себя другую информацию, либо и то и другое. Счетчик 110 коммунальных услуг обычно включает в себя аппаратный интерфейс 140, к которому может быть подключен модем обычной телефонной сети, оптический элемент связи или некоторые другие последовательные устройства, типа модуля 120 связи. Модуль 120 связи может включать в себя интерфейс 160 к счетчику коммунальных услуг, РЧ-радиоприемник 170, запоминающее устройство 180 для хранения машиночитаемых команд и процессор 190 для обработки машиночитаемых команд. Счетчик коммунальных услуг измеряет, или замеряет, предмет потребления, предоставленный коммунальным предприятием, например электричество, газ, воду и т.д. В одном возможном варианте осуществления модуль 120 связи объединяется со счетчиком коммунальных услуг. В еще одном возможном варианте осуществления модуль связи является отдельным модулем, который взаимодействует со счетчиком коммунальных услуг. В предпочтительном в настоящее время варианте осуществления модуль связи включает в себя радиочастотное устройство радиосвязи, имеющее возможность связи с одним или несколькими удаленными устройствами, например удаленным сервером коммунальных услуг. Модуль связи может быть частью беспроводной сети, например локальной сети (LAN), и предпочтительно может иметь двустороннюю линию передачи данных с сервером сети коммунальных услуг через точку доступа (также называемую шлюзом), которая обеспечивает поддержку входа/выхода. Точка доступа или сервер 130 коммунальных услуг могут включать в себя приложение считывания счетчика и начинать сетевой сеанс (например, сеанс C12.18) со счетчиком посредством модуля связи. Сеанс происходит по последовательному межсоединению, по которому сеансы C12.18 могут проводиться между модулем связи и счетчиком C12.19. Модуль связи также может называться "устройством доступа к счетчику". В одном предпочтительном варианте осуществления модуль связи является сетевой интерфейсной платой (NIC), которая обеспечивает связь между ассоциированным счетчиком и сетью связи. Модуль связи также может называться узлом сети коммунальных услуг. Пока не указано иное, термин "узел сети коммунальных услуг " относится к объединенному модулю связи и ассоциированному счетчику коммунальных услуг, или может относиться к модулю связи без счетчика коммунальных услуг, когда это указано.

Хотя только один модуль связи и один счетчик коммунальных услуг иллюстрируются на фиг.1, дополнительные варианты осуществления могут иметь более одного модуля связи и более одного счетчика коммунальных услуг, и они могут быть организованы в несколько сетей и/или могут быть доступны через одну или несколько точек доступа. Более того, может существовать один или несколько серверов, доступных по одной или нескольким сетям.

Фиг.2 - обобщенная блок-схема алгоритма, иллюстрирующая процесс 200 ответа на запрос данных. На этапе 201 модуль связи, ассоциированный со счетчиком коммунальных услуг, принимает запрос от приложения считывания счетчика на сервере или точке доступа, чтобы считать счетчик коммунальных услуг ради данных. В ответ на запрос считывания данных из ассоциированного счетчика коммунальных услуг модуль связи инициализирует сеанс со счетчиком коммунальных услуг на этапе 202, который может происходить в любое время после того, как принимается запрос, и в соответствии с любыми временными сроками, установленными приложением считывания счетчика для приема ответа. На этапе 203 принимается подтверждение счетчика коммунальных услуг об установке сеанса. На этапе 204 модуль связи отправляет запрос считывания данных счетчику коммунальных услуг. На этапе 205 модуль связи принимает ответ счетчика коммунальных услуг на запрос считывания данных. Ответ может включать в себя запрошенные данные или может включать в себя одно или несколько сообщений, например сообщение об ошибке или некоторое другое сообщение. На этапе 206 модуль связи определяет, имеются ли дополнительные считывания данных. Если имеются дополнительные считывания данных, то процесс переходит к этапу 204, где запрос считывания данных отправляется ассоциированному счетчику коммунальных услуг. Если на этапе 206 определяется, что нет дополнительных считываний данных для выполнения, то процесс переходит к этапу 207. На этапе 207 модуль связи отправляет сообщение завершения сеанса ассоциированному счетчику коммунальных услуг. На этапе 208 подтверждение счетчика коммунальных услуг об окончании сеанса принимается модулем связи. На этапе 209 модуль связи форматирует ответ для приложения считывания счетчика. На этапе 210 модуль связи отвечает на запрос данных, принятый на этапе 201, путем отправки ответа на принятый запрос на считывание ассоциированного счетчика коммунальных услуг. В предпочтительном в настоящее время варианте осуществления ответ включает в себя информацию с подходящими аннотациями, чтобы позволить приложению считывания счетчика ассоциировать ответ с соответствующим запросом данных. Дополнительно или в качестве альтернативы ответ может включать в себя информацию, которая позволяет приложению считывания счетчика интерпретировать данные. Один пример возможного запроса и ответа подробнее обсуждается ниже применительно к фиг.4.

Типичным процессом приложения считывания счетчика на сервере коммунальных услуг, инициирующем сеанс C12.18 со счетчиком C12.19, является истощение сетевых ресурсов. Протокол C12.18 определяет непрерывный сетевой сеанс в течение всего процесса считывания счетчика, требующий поддержания транспортного соединения в течение всего сеанса. Сеанс начинается с сообщения инициализации процесса от серверного приложения считывания счетчика к счетчику через модуль связи. Модуль связи здесь действует просто как пассивный ретранслятор между приложением считывания счетчика и счетчиком. Когда команды продолжаются от сервера к модулю связи, модуль связи выполняет действие по сбору запрошенных данных со счетчиком. Процесс запроса и ответа продолжается, пока сеанс не завершается посредством сообщения завершения от сервера к модулю связи. В результате получения блоков информации счетчика по определенным запросам идентификации (std 0, std 63, std 64 и т.д.) сервер теперь может разбирать и анализировать информацию. Однако ценные сетевые ресурсы тратились бы вследствие поддержания сеанса открытым в течение всей длительности по сети. По мере того как численность счетчиков увеличивается в сети, эта особенность может стать очень дорогостоящей и ограничивающей.

Адаптация типичного подхода считывания счетчика, раскрытого в этом документе, включает в себя взаимодействие по протоколу более высокого уровня между приложением считывания счетчика и счетчиком, оборудованным сетевым модулем связи. Подход по адаптации, раскрытый в этом документе, описывается на фиг.3. Модуль связи принимает запросы по протоколу высокого уровня и затем, через посредника, проводит сеанс C12.18 со счетчиком. Результаты сеанса C12.18 используются для составления ответа на запрос по протоколу более высокого уровня. Чтобы облегчить это, модуль связи конфигурируется, чтобы быть больше чем простым устройством сквозной передачи байтов. Он конфигурируется, чтобы быть и серверной стороной протокола высокого уровня, и клиентской стороной протокола C12.18. Этот протокол высокого уровня определяет множество базовых элементов, которые являются прямой ретрансляцией простых базовых элементов C12.18 считывания. Более того, протокол определяет операции более высокого уровня, которые включают в себя последовательность запросов по протоколу C12.18 от своего имени. Ответ модуля связи на запрос по протоколу высокого уровня является набором данных C12.19 с дополнительными вставленными в начало данными. Данные C12.19 не являются описывающими себя и могут интерпретироваться только с помощью сведений о запросах по протоколу C12.18, используемых для их получения. Таким образом, приложение считывания счетчика на сервере требует дополнительную информацию, чтобы интерпретировать необработанные данные C12.19. Эти дополнительные "аннотации" разрабатываются и включаются в ответ модуля связи серверу коммунальных услуг.

В конце сеанса C12.18 по сбору данных приложение считывания счетчика может проанализировать данные C12.19 и выполнить любые действия, которые необходимы.

Запрос информации от счетчика коммунальных услуг может быть выполнен с использованием одного или нескольких протоколов. В одном предпочтительном в настоящее время варианте осуществления запрос и соответствующий ответ могут быть выполнены с использованием стандартов C12.18 и C12.19 ANSI. Возможные варианты осуществления, где запрос и соответствующий ответ используют C12.18 и C12.19, описываются в Примере А ниже на схеме потока информации, показанной на фиг. 3, и в примере ответа, показанном на фиг.4.

Пример А

Счетчик, работающий в соответствии со стандартом C12.19, ассоциируется с модулем связи. Модуль связи форматирует ответ приложению считывания счетчика в соответствии со стандартом C12.19. Как описано выше применительно к фиг.2, модуль связи может принимать запрос считывания счетчика, чтобы считать данные из ассоциированного счетчика коммунальных услуг. Модуль связи открывает сеанс C12.18 с ассоциированным счетчиком коммунальных услуг. Модуль связи отправляет запросы чтения таблицы счетчику коммунальных услуг. Счетчик коммунальных услуг отвечает информацией, отформатированной в соответствии со стандартом C12.19, которая принимается модулем связи. В одном предпочтительном варианте осуществления модуль связи создает все (или несколько) запросы считывания данных к ассоциированному счетчику и принимает соответствующие ответы от счетчика коммунальных услуг, отформатированные в соответствии с C12.19 перед ответом на запрос считывания счетчика. В таком варианте осуществления информация из ответов, принятых от счетчика, включается в один ответ на запрос считывания счетчика, причем один ответ отправляется приложению считывания счетчика, расположенному на сервере коммунальных услуг или точке доступа. Один ответ на запрос считывания счетчика форматируется в соответствии со стандартом C12.19 и включает в себя информацию, позволяющую приложению считывания счетчика ассоциировать ответ с соответствующим запросом считывания счетчика. Предпочтительно, чтобы ответ также включал в себя информацию, которая позволит приложению считывания счетчика интерпретировать данные.

Один предпочтительный вариант осуществления изобретения описывается ниже. Приложение считывания счетчика может размещаться на обслуживающем сервере или в точке доступа беспроводной сети, в которой расположены все счетчики C12.19 коммунальных услуг и подключены к сети через отдельные модули связи. Модуль связи располагается в каждом из расположений счетчика C12.19, чтобы предоставлять возможность сетевого подключения, а также сетевой интерфейс со счетчиком. Приложение считывания счетчика на сервере или точке доступа создает запросы считывания счетчика к модулю связи по сети. Запрос поступает в виде информационного сообщения, предпочтительно в виде пакетов IPv6 или IPv4. Однако другие типы пакетных протоколов в равной степени применимы к изобретению, раскрытому в этом документе. Этот запрос приглашает модуль связи начать один сеанс C12.18, в котором проводится много базовых операций C12.18 для сбора запрошенных данных. Модуль связи затем переупаковывает данные вместе с объяснениями, аннотациями и т.д., чтобы помочь приложению считывания счетчика на сетевом сервере интерпретировать данные должным образом. Запрошенные данные передаются по беспроводной сети обслуживающему серверу в виде группы пакетов IPv4 или IPv6 с подходящими заголовками и полями данных.

Фиг.3 описывает синхронный обмен между приложением считывания счетчика и счетчиком через модуль связи, который выполняет функции согласования и посреднические функции. Приложение считывания счетчика на сервере отправляет главный запрос C12.19 данных счетчика целевому модулю связи в сообщении 301. Это обычно будет происходить в виде пакета (пакетов) IPv4 или IPv6, но не только. Эти типы запросов могут перемежаться сервером запросами, которые он может создавать к другим модулям связи, или другими сообщениями сетевых операций. Это модуль связи, который начинает "несетевой" сеанс C12.18 считывания счетчика со счетчиком, чтобы выполнить запросы, созданные сервером. Модуль связи может выполнять несколько запросов считывания данных счетчика в одном или нескольких сеансах C12.18 со счетчиком и собирать все или часть данных перед ответом серверу. Соответственно, модуль связи действует в качестве посредника для сервера коммунальных услуг. Сеанс C12.18 сам по себе похож на традиционный сеанс C12.18, описанный в стандартах C12.18, с последовательным двусторонним обменом сообщениями запрос-ответ, пока сеанс не завершается и не подтверждается. Сеанс C12.18 в примере, показанном на фиг.3, описывается в сообщениях с 302 по 311. После того как завершается сеанс, модуль связи компонует данные C12.19 счетчика вместе с подходящими аннотациями, вставленными в начало, и передает сообщение 312 с данными серверу в виде пакетов одного из IPv4, IPv6 или других протоколов. Нужно снова отметить, что сервер может запрашивать несколько считываний счетчика в его сообщении к модулю связи, и модуль связи может отвечать одним или несколькими сообщениями после получения всех запрошенных данных. Основное требование состоит в том, что модуль связи обязан комментировать данные C12.19, чтобы сервер распознавал формы данных и соответственно их обрабатывал.

Фиг.4 предоставляет пример запроса (данных C12.19 считывания счетчика) и аннотированного ответа от модуля связи. Эта связь происходит по протоколу более высокого уровня, так как информационные сообщения обычно находятся в виде IP-пакетов. Типичный запрос считывания счетчика от сервера коммунальных услуг представляется в сообщении 410. Сервер предоставляет преамбулу начала запроса 411, снабженного необходимыми данными идентификации. Специальный запрос чтения таблицы (таблица данных C12.19) показан ссылочной позицией 412. Запрос, относящийся к операции "Считывание профиля нагрузки (LP)", описывается по ссылке 413. Может быть несколько сообщений типа 410, которые узел сети коммунальных услуг может принимать от сервера коммунальных услуг. Затем он проведет один или несколько сеансов C12.18, чтобы получить данные от счетчика посредством запроса от сервера коммунальных услуг. Узел сети коммунальных услуг затем готовит аннотированный ответ 420 и отправляет его серверу коммунальных услуг. Ответ сопровождает один или несколько запросов. В представленном в этом документе примере ссылка 420 представляет типичный ответ на один запрос. Преамбула начала ответа 421 сопровождает начало преамбулы запроса. Данные в операции 422 чтения таблицы сопровождают запрос и упорядочивают данные в последовательность, запрошенную приложением считывания счетчика на сервере коммунальных услуг. Аналогичным образом, сообщение 423 операции считывания LP сопровождает запрос 413 и упорядочивает данные профиля нагрузки в порядке, запрошенном в 413. Этот отформатированный ответ 420 поможет серверу коммунальных услуг обработать информацию считывания счетчика эффективно и правильно.

В конце сбора данных приложение считывания счетчика на сервере может проанализировать дополненные данные C12.19 и выполнить любые действия, которые необходимы.

ОПЕРАЦИИ И ФОРМАТ ДАННЫХ В СПОСОБЕ АДАПТАЦИИ

Типовые операции и формат данных способа адаптации предоставляются в этом документе для описания сущности высокоуровневого протокола и уровня разметки данных C12.19. Предоставленные в этом документе подробности предназначены только для облегчения понимания высокоуровневых протоколов, а также возможных структур данных, используемых для реализации пакетов запроса и ответа. Пример не предназначен быть всесторонним и по существу не ограничивается именно этой реализацией.

Операция запроса:

Первой частью всех запросов является заголовок "Начало запроса". Он имеет вид:

- 32 разряда данных, которые могут быть заданы пользователем (отражается обратно запрашивающей стороне)

- 32 разряда длины (длина всего запроса меньше этого заголовка)

Этот раздел описывает структуры данных, которые могут использоваться в запросе или ответе. В заголовке, таком как этот (и другие ниже), длина данных непосредственно после заголовка должна быть известна, чтобы мог происходить разбор данных. "32 разряда длины" являются предпочтительным количеством байт, которые должны следовать за этим заголовком.

Каждая операция запроса имеет общую часть заголовка и специфичную для операции часть. Общая часть заголовка имеет вид:

- 32 разряда идентификации операции

Примерные операции протокола и их специфичные для операций заголовки запросов выглядят следующим образом:

- прямая ретрансляция C12.18

- чтение таблицы

- 16 разрядов идентификации таблицы

- 16 разрядов заполнения

- чтение смещения таблицы

- 16 разрядов идентификации таблицы

- 16 разрядов длины

- 32 разряда смещения

- чтение регистров

- нет специфичного для операции заголовка

- чтение регистров предыдущего периода

- 32 разряда отметки времени (UNIX GMT)

- чтение регистров предыдущего требования

- 32 разряда отметки времени (UNIX GMT)

- чтение регистров самостоятельного считывания

- 32 разряда № начальной последовательности

- чтение профиля нагрузки

- 32 разряда № начального блока

- 32 разряда № начальной последовательности

- 32 разряда № конечного блока

- 32 разряда № конечной последовательности

- чтение журнала событий

- 32 разряда № начальной последовательности

- 32 разряда № конечной последовательности

Операции могут быть сгруппированы вместе в один запрос. Например, можно выполнить операцию чтения таблицы вместе с операцией чтения регистра. Когда каждый запрос предпочтительно выполняется в одном сеансе C12.18, операции чтения таблицы и чтения регистра будут одновременными.

Ответ:

Первой частью ответа является заголовок "Начало ответа". Он предпочтительно имеет вид:

- 32 разряда данных, которые могут быть заданы пользователем (из запроса)

- 32 разряда состояния запроса

- 32 разряда длины (длина всего ответа меньше этого заголовка)

Операция ответа может иметь общую часть заголовка и специфичную для операции часть.

Примерная общая часть заголовка имеет вид:

- 32 разряда идентификации операции

- 32 разряда состояния запроса

- 32 разряда длины (длина ответа операции меньше этого заголовка)

Примерные операции протокола, специфичные для операций заголовки ответов и запрошенные данные могут выглядеть следующим образом:

- прямая ретрансляция C12.18

- чтение таблицы

- 16 разрядов идентификации таблицы

- 16 разрядов заполнения

- данные C12.19 таблицы

- чтение смещения таблицы

- 16 разрядов идентификации таблицы

- 16 разрядов длины

- 32 разряда смещения

- данные C12.19 таблицы

- чтение регистров

- данные C12.19 таблицы (std 23)

- чтение регистров предыдущего периода

- 32 разряда запрошенной отметки времени (UNIX GMT)

- данные C12.19 таблицы (std 24)

- чтение регистров предыдущего требования

- 32 разряда запрошенной отметки времени (UNIX GMT)

- данные C12.19 таблицы (std 25)

- чтение регистров самостоятельного считывания

- 32 разряда запрошенного № начальной последовательности

- 32 разряда количества записей самостоятельного считывания

- данные C12.19 таблицы (std 26)

- чтение профиля нагрузки

- 32 разряда запрошенного № начального блока

- 32 разряда запрошенного № начальной последовательности

- 32 разряда запрошенного № конечного блока

- 32 разряда запрошенного № конечной последовательности

- 32 разряда № блока

- данные C12.19 таблицы (std 64 / заголовок блока)

- 32 разряда № начальной последовательности

- 32 разряда № конечной последовательности

- 32 разряда длины

- данные C12.19 таблицы (std 64 / данные профиля нагрузки)

(Эта часть повторяется при необходимости, чтобы выполнить запрос)

- чтение журнала событий

- 32 разряда № начальной последовательности

- 32 разряда № конечной последовательности

- 32 разряда количества записей журнала событий

- данные C12.19 таблицы

Операция "Считывание снова":

Операции считывания вплоть до этого момента могут принимать пару параметров, разграничивающих начальные и конечные порядковые номера в последовательностях данных. Обслуживающая система со временем может собрать все выборки в массив данных. Это предпочтительно выполняется путем многократного считывания счетчика, чтобы получить последние последовательные данные, доступные с момента, когда произошло предыдущее считывание. Для каждого считывания в итерации знание порядкового номера последнего считывания используются затем для создания запроса считывания новых данных. Оптимизация, которая исключает необходимость у обслуживающей системы поддерживать порядковые номера последнего считывания, заключает в себе хранение порядковых номеров последнего считывания от любых предыдущих операций "считывания снова" на NIC. Обслуживающая система может тогда обеспечить только операции "считывания снова", чтобы получить все новые данные. Эта операция считывания может обращаться ко всем хронологическим данным на счетчике. Запрос "считывания снова" не принимает никаких специфичных для операции входных параметров. В произвольном порядке ответ является последовательностью последовательно кодированных участков. Поскольку эта операция используется для получения новых данных, любое конкретное TLV может быть исключено из ответа. Каждый участок может иметь заголовок, который описывает тип данных и длину части данных непосредственно после заголовка.

Каждое TLV (тип, длина, значение) описывается ниже:

- Регистры предыдущего периода

- 32 разряда типа

- 32 разряда длины

- 32 разряда времени чтения регистров предыдущего периода

- данные C12.19 таблицы

- Регистры предыдущего требования

- 32 разряда типа

- 32 разряда длины

- 32 разряда времени чтения регистров предыдущего требования

- данные C12.19 таблицы

- Регистры самостоятельного считывания

- 32 разряда типа

- 32 разряда длины

- 32 разряда количества записей самостоятельного считывания

- данные C12.19 таблицы

- Профиль нагрузки

- 32 разряда типа

- 32 разряда длины

- 32 разряда количества блоков

- 32 разряда № начального блока

- 32 разряда № начальной последовательности

- 32 разряда № конечного блока

- 32 разряда № конечной последовательности

- 32 разряда № блока

- данные C12.19 таблицы (std 64 / заголовок блока)

- 32 разряда № начальной последовательности

- 32 разряда № конечной последовательности

- 32 разряда длины

- данные C12.19 таблицы (std 64 / данные профиля нагрузки)

(Последняя группировка данных повторяется при необходимости, чтобы собрать все заново считываемые данные).

- Журнал событий

- 32 разряда типа

- 32 разряда длины

- 32 разряда количества записей журнала событий

- данные C12.19 таблицы

Для специалистов в данной области техники будет очевидно, что способ из раскрытого изобретения применим к другим видам способов и протоколов сбора данных, которые требуют непрерывного поддержания сетевого сеанса. Посредник по сбору данных, который в предпочтительном варианте осуществления является NIC, может быть оснащен способностью проводить связь по протоколу более высокого уровня с сервером, а также сохраняет возможность проводить сеансово-ориентированный протокол C12.18 с источником данных, который в этом предпочтительном варианте осуществления является электрическим счетчиком.

Представленные в этом документе варианты осуществления объединяют подсистемы и функциональные возможности, чтобы проиллюстрировать предпочтительные в настоящее время варианты осуществления. Альтернативные варианты осуществления могут включать в себя меньше или дополнительные подсистемы, процессы или функциональные особенности, либо могут использоваться с другими подсистемами, процессами или функциональными особенностями, в зависимости от нужной реализации. Различные признаки и преимущества настоящего изобретения излагаются в нижеследующей формуле изобретения.

Изобретение относится к области приборостроения и может найти применение в системах дистанционного учета коммунальных услуг для считывания показаний счетчика. Технический результат - расширение функциональных возможностей. Для этого показания счетчика коммунальных услуг считываются путем отправки запроса на считывание показаний счетчика из соответствующего приложения считывания счетчика, которое может располагаться на сервере коммунальных услуг или в точке доступа к сети и к модулю связи, ассоциированному с конкретным счетчиком коммунальных услуг. При этом модуль связи начинает сеанс со счетчиком коммунальных услуг, создает запросы данных от ассоциированного счетчика коммунальных услуг, принимает ответы на запросы данных от счетчика коммунальных услуг и завершает сеанс после приема всех запрошенных данных от счетчика. Затем модуль связи форматирует ответы с данными, принятыми от счетчика коммунальных услуг, и передает отформатированный ответ в соответствующее приложение считывания счетчика. 3 н. и 23 з.п. ф-лы, 4 ил.

1. Система для считывания данных счетчика коммунальных услуг по сети, содержащая:
множество счетчиков коммунальных услуг, выполненных с возможностью считывания информации счетчика предмета потребления;
множество узлов сети коммунальных услуг, организованных в сеть коммунальных услуг и выполненных с возможностью взаимодействия со счетчиками коммунальных услуг и приема информации счетчика предмета потребления от счетчиков коммунальных услуг и передачи этой информации на предварительно заданный сетевой адрес;
при этом, по меньшей мере, один из узлов коммунальных услуг, в ответ на прием запроса считывания счетчика от программы считывания счетчика, в соответствии с первым протоколом передачи данных:
инициирует сеанс с, по меньшей мере, одним счетчиком коммунальных услуг в соответствии с вторым протоколом передачи данных, отличающимся от первого протокола передачи данных, причем упомянутый сеанс содержит последовательный двусторонний обмен множеством пар сообщений между, по меньшей мере, одним узлом коммунальных услуг и, по меньшей мере, одним счетчиком коммунальных услуг, где каждая пара сообщений содержит (i) запрос данных счетчика, который посылается к, по меньшей мере, одному счетчику коммунальных услуг от, по меньшей мере, одного узла коммунальных услуг, и (ii) ответ на запрос данных счетчика, который посылается на, по меньшей мере, один узел коммунальных услуг от, по меньшей мере, одного счетчика коммунальных услуг и в ответ на запрос считывания счетчика, так что, по меньшей мере, один узел коммунальных услуг принимает от, по меньшей мере, одного счетчика коммунальных услуг множество ответов по отдельности в ответ на множество отдельных запросов данных счетчика соответственно,
по завершении сеанса форматирует множество принятых ответов на запросы данных счетчика в ответ на запрос считывания счетчика, который содержит указание соответствия между каждым отдельным принятым ответом и отдельным запросом данных счетчика, на который отвечает этот принятый ответ, соответственно; и
передает сформатированный ответ на запрос считывания счетчика на предварительно заданный сетевой адрес, ассоциированный с запросом считывания счетчика, принятым от программы считывания счетчика.

2. Система по п.1, в которой узел сети коммунальных услуг содержит аппаратный интерфейс, с которым может соединяться модем обычной телефонной сети (POTS) и который конфигурирован для взаимодействия со счетчиком коммунальных услуг, с которым он ассоциирован, в несетевом или сетевом сеансе, включающем в себя двусторонний обмен сообщениями запроса/ответа в соответствии с предварительно назначенным форматом второго протокола передачи данных.

3. Система по п.1, в которой формат ответа на запрос считывания счетчика основан на одном из ANSI C12.19 и С12.18.

4. Система по п.1, в которой протокол, используемый сетью коммунальных услуг в сеансе со счетчиком коммунальных услуг, работающем в формате C12.19, основан на формате ANSI 12.18 протокола.

5. Система по п.4, в которой первый протокол передачи данных, используемый сервером коммунальных услуг и узлом коммунальных услуг в обмене сообщениями касательно запросов считывания счетчика, включает в себя определение набора базовых элементов, которые являются простой ретрансляцией базовых элементов считывания формата С12.18 протокола.

6. Система по п.5, в которой указание в сформатированном ответе на запрос считывания счетчика включает в себя информацию аннотации для использования в интерпретации информации счетчика предмета потребления, включенной в переданный ответ на запрос считывания счетчика.

7. Система по п.5, в которой сообщение с запросом данных считывания счетчика, отправленным сервером узлу сети коммунальных услуг в соответствии с первым протоколом передачи данных, может быть в форме одного из IPv4 или IPv6.

8. Система по п.5, в которой сообщение с ответом на запрос считывания счетчика, отправленным узлом сети коммунальных услуг серверу в соответствии с первым протоколом передачи данных, может быть в форме одного из IPv4 или IPv6.

9. Система по п.5, в которой предварительно заданный сетевой адрес, ассоциированный с принятым запросом считывания счетчика, соответствует серверу коммунальных услуг.

10. Система по п.5, в которой предварительно заданный сетевой адрес, ассоциированный с принятым запросом считывания счетчика, соответствует точке доступа к сети коммунальных услуг, причем программа считывания счетчика постоянно хранится в точке доступа, ассоциированной с сетевым адресом.

11. Система по п.5, в которой данные, собранные узлом сети коммунальных услуг посредством одного или нескольких сеансов С12.18 со счетчиком предмета потребления, основываются на наборе значений TLV (время, длина, значение) элементов данных.

12. Система по п.11, в которой ответное сообщение от узла сети коммунальных услуг серверу коммунальных услуг включает в себя запрошенные данные в виде последовательности кодированных по длинам серий участков с возможностью исключения конкретного TLV из ответа и включает в себя заголовок, который описывает тип данных и длину части данных непосредственно после заголовка.

13. Способ считывания данных счетчика коммунальных услуг по сети, содержащий этапы, на которых:
принимают, в соответствии с первым протоколом передачи данных, запрос считывания счетчика от приложения считывания счетчика с помощью модуля связи, ассоциированного со счетчиком коммунальных услуг;
инициируют сеанс со счетчиком коммунальных услуг в соответствии с вторым протоколом передачи данных, отличающимся от первого протокола передачи данных, причем сеанс осуществляется между модулем связи и счетчиком коммунальных услуг, при этом сеанс содержит этапы, на которых:
выполняют множество запросов данных к счетчику коммунальных услуг посредством модуля связи;
принимают в модуле связи множество ответов от счетчика коммунальных услуг, которые являются ответными на запрос данных счетчика, так что модуль связи принимает от счетчика коммунальных услуг множество ответов по отдельности в ответ на множество запросов данных соответственно;
при завершении сеанса форматируют ответ на запрос считывания счетчика от приложения считывания счетчика посредством модуля связи, причем ответ содержит принятые ответы, сформатированные с указанием соответствия между каждым отдельным принятым ответом и отдельным запросом данных счетчика, на который отвечает этот принятый ответ, соответственно; и передают сформатированный ответ приложению считывания счетчика.

14. Способ по п.13, в котором принятый запрос считывания счетчика от приложения считывания счетчика совместим с С12.18.

15. Способ по п.14, в котором счетчик коммунальных услуг является совместимым с С12.19 счетчиком коммунальных услуг и в котором множество запросов данных к совместимому с С12.19 счетчику коммунальных услуг являются совместимыми с С12.18.

16. Способ по п.15, в котором модуль связи имеет возможность проведения автономного сеанса С12.18 с совместимым с С12.19 счетчиком коммунальных услуг.

17. Способ по п.15, в котором сформатированный ответ на приложение считывания счетчика включает в себя информацию аннотации, которая описывает содержание сформатированного ответа для использования приложением считывания счетчика в интерпретации ответа.

18. Модуль связи для использования в сети коммунальных услуг, содержащий:
интерфейс к счетчику коммунальных услуг;
запоминающее устройство для хранения команд;
процессор для обработки команд и
радиочастотное устройство радиосвязи для взаимодействия с приложением считывания счетчика с использованием радиочастотной сети в соответствии с первым протоколом передачи данных,
при этом процессор выполняет команды:
инициирования, в соответствии с вторым протоколом передачи данных, отличающимся от первого протокола передачи данных, сеанса со счетчиком коммунальных услуг в ответ на принятый запрос считывания счетчика, переданный от приложения считывания счетчика в соответствии с первым протоколом передачи данных, причем сеанс содержит выполнение множества запросов данных к счетчику коммунальных услуг и прием множества ответов от счетчика коммунальных услуг, которые являются ответом на запрос данных счетчика, так что модуль связи принимает от счетчика коммунальных услуг множество ответов по отдельности в ответ на множество запросов данных соответственно, по завершении сеанса форматирования ответа на запрос считывания счетчика от приложения считывания счетчика посредством модуля связи, причем ответ содержит принятые ответы, сформатированные с указанием соответствия между каждым ответом модулю связи и отдельным запросом данных счетчика, выполненным модулем связи, на который отвечает этот принятый ответ, соответственно; и передачи сформатированного ответа приложению считывания счетчика.

19. Модуль связи по п.18, в котором принятый запрос считывания счетчика от приложения считывания счетчика совместим с форматом С12.18.

20. Модуль связи по п.19, в котором счетчик коммунальных услуг является совместимым с форматом С12.19 счетчиком коммунальных услуг и в котором множество запросов данных к совместимому с форматом С12.19 счетчику коммунальных услуг являются совместимыми с форматом С12.18.

21. Модуль связи по п.20, причем модуль связи выполнен с возможностью проведения автономного сеанса С12.18 с совместимым с форматом С12.19 счетчиком коммунальных услуг.

22. Модуль связи по п.20, в котором сформатированный ответ приложению считывания счетчика включает в себя информацию аннотации, которая описывает содержание сформатированного ответа для использования приложением считывания счетчика в интерпретации ответа.

23. Модуль связи по п.20, в котором радиочастотное устройство радиосвязи передает сообщения с использованием основанных на IP протоколов.

24. Модуль связи по п.20, в котором основанные на IP протоколы включают в себя, по меньшей мере, один из протоколов IPv6 или IPv4.

25. Модуль связи по п.20, в котором радиочастотное устройство радиосвязи принимает запросы данных считывания счетчика от приложения считывания счетчика в формате IP-протокола.

26. Модуль связи по п.20, в котором основанные на IP протоколы включают в себя, по меньшей мере, один из протоколов IPv6 и IPv4.