СПОСОБ И СИСТЕМА СЧИТЫВАНИЯ ДАННЫХ СЧЕТЧИКА КОММУНАЛЬНЫХ УСЛУГ ПО СЕТИ

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

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

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

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 с источником данных, который в этом предпочтительном варианте осуществления является электрическим счетчиком.

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