Область техники, к которой относится изобретение
Настоящее изобретение относится, в общем, к системе и способу управления промышленной сетью и, более конкретно, к системе и способу сбора данных от и/или направления данных в различные секторы энергосистемы, а также анализа собранных/направленных данных с целью управления этой энергосистемой.
Уровень техники
Энергосистема может включать один из или все следующие сегменты: генерацию электроэнергии, передачу электроэнергии и распределение электроэнергии. Электроэнергию можно генерировать с использованием генерирующих электростанций, таких как электростанции, работающие на угле, атомные электростанции и т.п. Из соображений эффективности напряжение генерируемого электрического тока повышают до уровня очень высокого напряжения (такого как 345 кВ) и передают энергию по линиям электропередач. Линии электропередач могут передавать энергию на большие расстояния, такие как через границы штатов или через границы между странами, к оптовому потребителю, который может представлять собой компанию, имеющую собственную локальную распределительную сеть. Линии электропередач могут оканчиваться передающими подстанциями, которые могут понижать очень высокое напряжение до уровня промежуточного напряжения (такого как 138 кВ). От такой передающей подстанции линии электропередач меньшей мощности (такие как распределительные подводящие линии) передают это промежуточное напряжение к распределительным подстанциям. На промежуточных подстанциях промежуточное напряжение может быть дополнительно понижено до уровня «среднего напряжения» (такого как от 4 кВ до 23 кВ). От распределительных подстанций могут исходить одна или несколько питающих линий. Например, от одной распределительной подстанции могут отходить от четырех до десяти питающих линий. Питающая линия представляет собой 3-фазную линию, содержащую 4 провода (три провода для каждой из 3 фаз и один провод для нейтрали). Питающие линии могут быть проложены либо над землей (на столбах), либо под землей. Напряжение питающих линий можно периодически ответвлять с использованием распределительных трансформаторов, которые понижают напряжение от указанного «среднего напряжения» до уровня потребительского напряжения (такого как 120 В). Потребительское напряжение может быть затем использовано конечным потребителем.
Энергосистемой могут управлять, включая устранение перебоев (отключений) и неисправностей, обслуживание и модификации, одна или несколько электроэнергетических компаний. Однако управление энергосистемой часто является неэффективным и дорогостоящим. Например, электроэнергетическая компания, управляющая локальной распределительной сетью, может устранять неисправности, возникающие в питающих линиях или в линиях, которые именуются боковыми линиями и ответвляются от питающих линий. Управление локальной распределительной сетью часто опирается на телефонные вызовы от потребителей, когда возникает какая-то неисправность или сбой в работе, или на линейных сотрудников, анализирующих работу локальной распределительной сети.
Электроэнергетические компании пытались усовершенствовать энергосистему с использованием цифровой технологии, иногда именуемой «интеллектуальные энергосистемы» ("smart grid"). Например, более разумные счетчики (иногда именуемые «интеллектуальные приборы учета») представляют собой усовершенствованные приборы учета, определяющие потребление энергии более детально, чем обычные счетчики. Такой интеллектуальный прибор учета может затем сообщать информацию через определенную сеть назад местной энергоснабжающей компании в целях контроля и выставления счетов (телеметрия).
Даже при наличии таких усовершенствований в энергосистеме задачи анализа функционирования и связи в такой энергосистеме остаются сложными. Электроэнергетическая компания может иметь несколько систем, таких как система управления энергоснабжением (которая может анализировать распределение нагрузки и отдавать соответствующие команды), система управления отключениями (которая может анализировать неисправности и отключения и отдавать соответствующие команды), система регулирования спроса, система выставления счетов и т.п. Эти несколько систем могут взаимодействовать между собой, усложняя управление энергосистемой. Далее, эти несколько систем могут действовать как несколько источников, передающих команды различным адресатам в энергосистеме. Эти несколько систем часто используют разные форматы для связи, что усложняет организацию связи в энергосистеме в целом. Поэтому имеет место необходимость лучше управлять аналитикой и связью нескольких систем в пределах энергосистемы.
Сущность изобретения
Предложен центр управления энергосистемой, такой как энергосистема общего пользования. Центр управления энергосистемой поддерживает связь с несколькими системами сбора и обработки данных учета и с несколькими терминальными системами, указанные системы сбора и обработки данных учета генерируют команды, а терминальные системы поддерживают связь с одним или несколькими счетчиками (такими как один или несколько интеллектуальных приборов учета). Одним из примеров архитектуры, включающей центр управления энергосистемой, который может управлять интеллектуальной энергосистемой, является новая опорная архитектура управления «интеллектуальными энергосетями» (Intelligent Network Data Enterprise (далее именуемая INDE) Reference Architecture).
Центр управления энергосистемой включает уровень шлюза и уровень ядра. Уровень шлюза содержит несколько входных соединительных процедур и несколько выходных соединительных процедур. Совокупность нескольких входных соединительных процедур, содержит по меньшей мере по одной отдельной входной соединительной процедуре для поддержания связи с каждой из нескольких систем-источников, передающих данные в центр управления энергосистемой (такой как системы сбора и обработки данных учета, передающие команды соединения/разъединения с центром управления энергосистемой). Совокупность нескольких выходных соединительных процедур, содержит по меньшей мере по одной отдельной выходной соединительной процедуре для поддержания связи с каждой из нескольких целевых систем, принимающих данные, переданные центром управления энергосистемой (такой как терминальные системы, принимающие команды соединения/разъединения с центром управления энергосистемой).
Уровень ядра в составе центра управления энергосистемой содержит несколько адаптеров ядра, так что эти адаптеры ядра осуществляют взаимно-однозначную трансляцию связи от нескольких систем сбора и обработки данных учета, генерирующих команды, к нескольким терминальным системам.
Другие системы, способы, признаки и преимущества настоящего изобретения будут или станут очевидны для специалиста в рассматриваемой области после изучения приведенных далее чертежей или подробного описания. Предполагается, что все такие дополнительные системы, способы, признаки и преимущества, которые могут быть включены в это описание, будут находиться в пределах объема настоящего изобретения и будут защищены прилагаемой формулой изобретения.
Краткое описание чертежей
Фиг.1 иллюстрирует пример архитектуры INDE верхнего уровня.
Фиг.2 иллюстрирует диаграмму обмена сигналами на верхнем уровне между системой MDM, ядром INDE и терминальными системами HeadEnd.
Фиг.3 представляет пример подробной диаграммы обмена сигналами для передачи команд разъединения/соединения.
Фиг.4 представляет пример подробной диаграммы обмена сигналами для периодического считывания показаний счетчиков.
Фиг.5 представляет пример подробной диаграммы обмена сигналами для передачи команды считывания показаний счетчиков по требованию.
Фиг.6А-С представляет блок-схему одного примера общей архитектуры энергосистемы.
Подробное описание изобретения
В порядке обзора, предпочтительные варианты, описанные ниже, относятся к способу и системе управления энергосистемой. Некоторые аспекты относятся к структурным и/или функциональным возможностям централизованного управления энергосистемой. Система управления «интеллектуальными энергосетями» (Intelligent Network Data Enterprise (INDE)) представляет собой интеграционную платформу интеллектуальной энергосистемы (Smart Grid), как описано в Заявке на выдачу патента США No. 12/378102 (опубликовано как Заявка на выдачу патента США No. 2009-0281674 А1), в Заявке на выдачу патента No. 12/378091 (опубликовано как Заявка на выдачу патента США No. 2009-0281673A1) и в Заявке на выдачу патента РСТ No. PCT/US2009/000888 (опубликовано как WO 2009/136975), эта система INDE предоставляет в высокой степени масштабируемое, конфигурируемое прикладное интеграционное решение и имеет встроенные в ядро бизнес-процессы интеллектуальной энергосистемы, такие как усовершенствованная инфраструктура учета (Advanced Metering Infrastructure), управление спросом (Demand Response), интеллектуальное управление устранением неисправностей и отключений (Fault & Outage Intelligence), аналитика подстанций (Substation Analytics) и т.п., которые могут широко использоваться энергоснабжающей компанией.
Архитектура INDE Architecture разделена на уровень ядра (Core) и уровень шлюза (Gateway), причем уровень ядра INDE Core предоставляет определенные сервисы, такие как интеллектуальное распределение услуг, синхронная и асинхронная передача вызовов, преобразование данных и аудиторские возможности, а вместе с уровнем шлюза INDE Gateway представляет услуги соединения приложений, которые могут иметь встроенные широко применяемые промышленные протоколы связи. Например, уровень шлюза INDE Gateway может включать несколько входных соединительных процедур и несколько выходных соединительных процедур, совокупность нескольких входных соединительных процедур, содержит по меньшей мере по одной отдельной входной соединительной процедуре для поддержания связи с каждой из нескольких систем сбора и обработки данных учета (Meter Data Management (MDM)), и совокупность нескольких выходных соединительных процедур, содержит по меньшей мере по одной отдельной выходной соединительной процедуре для поддержания связи с каждой из нескольких терминальных систем (HeadEnd Systems).
Разделение ядра INDE Core и шлюза INDE Gateway предоставляет ряд преимуществ, включая без ограничений, лучшую адаптацию архитектуры INDE Architecture к известным и неизвестньм системам, лучшую масштабируемость и улучшенную безопасность. Пример архитектуры 50 верхнего уровня показан на фиг.1. Как показано на фиг.1, ядро INDE Core 55 отделено от шлюза INDE Gateway 60. Далее, шлюз INDE Gateway 60 создает интерфейс между ядром INDE Core 55 с одной стороны и системами-источниками (такими, как система-источник 1 (65) и система-источник 2 (70)) и целевыми системами (такие как целевая система 1 (75) и целевая система 2 (80)). На фиг.1 показаны две системы-источники и две целевые системы. Однако возможно большее или меньшее число систем-источников и целевых систем. Как будет более подробно рассмотрено ниже, шлюз INDE Gateway включает уровень соединителей, обеспечивающий соединение различных систем-источников с целевыми системами.
Система-источник передает запрос на информацию или команду для выполнения действия, а целевая система отвечает на этот запрос на информацию или действует по команде. Один из примеров команды, которую может генерировать система MDM, может включать требование выполнить действие разъединения/соединения с прибором учета. Система MDM может иметь функциональные возможности для реализации одной или нескольких из следующих систем: системы сбора и передачи данных (включая автоматическое считывание показаний приборов учета (automated meter reading (AMR)) и усовершенствованную инфраструктуру учета (advanced metering infrastructure (AMI))); a также сбор и обработку данных учета и относящиеся к этому программные приложения. В типичной системе энергоснабжения могут быть несколько систем MDM, так что одна из этих нескольких различных систем MDM может действовать в качестве системы-источника. К примерам коммерческих систем MDM относятся системы LodeStar и Itron. Кроме того, различные системы MDM могут происходить от разных поставщиков и применять различные форматы. При таком подходе данные в команде могут содержать аналогичную информацию (такую как идентификационный номер ID# для интеллектуального прибора учета и команда соединения/разъединения), но в различных форматах.
Например, команда может быть передана на основе одного из нескольких различных сетевых протоколов, таких как протокол передачи файлов (file transfer protocol (FTP)), протокол интерфейса прикладных программ Java API для доступа к службам сообщений (Java message service (JMS)) и протокол передачи гипертекста (hypertext transfer protocol (HTTP)). Протокол FTP представляет собой стандартный сетевой протокол, который может быть использован для копирования файлов от одного главного компьютера к другому через сеть на основе протокола ТСРЛР, такую как Интернет. Протокол FTP построен на основе архитектуры клиент-сервер и используют раздельные соединения для управления и для передачи данных между приложениями клиента и сервера, что решает проблему различия конфигураций оконечных компьютеров (т.е. операционные системы, имена файлов). Протокол FTP используется в сочетании с аутентификацией пользователя посредством пароля или с анонимным доступом пользователя. Интерфейс прикладных программ JMS API представляет собой интерфейс прикладных программ на основе промежуточного программного обеспечения, ориентированного на службу передачи сообщений Java, (Java Message Oriented Middleware (MOM) API) для передачи сообщений между двумя или более клиентами. Интерфейс JMS представляет собой часть платформы для предприятий Java Platform, Enterprise Edition, и определен спецификацией, разработанной сообществом Java (Java Community Process) с обозначением JSR 914. Это стандарт обмена сообщениями, позволяющий компонентам приложений на основе платформы Java 2 Platform, Enterprise Edition (J2EE) создавать, передавать, принимать и читать сообщения. Этот стандарт позволяет сделать связь между различными компонентами распределенного приложения гибкой, надежной и асинхронной. Наконец, протокол HTTP представляет собой протокол уровня приложения для распределенных совместно работающих гипермедийных информационных систем.
Команда (переданная посредством одного из различных сетевых протоколов) может быть направлена в терминальную систему HeadEnd, которая передает требование выполнить разъединение/соединение прибору учета, установленному в домашней сети (home area network (HAN)). Здесь снова, в типичной системе энергоснабжения могут быть несколько терминальных систем HeadEnd, таких как Защита (Secure) или Ток (Current), так что одна из нескольких разных терминальных систем HeadEnd может действовать в качестве целевой системы.
Разные терминальные системы HeadEnd могут поддерживать связь с различными категориями счетчиков (приборов учета). Например, счетчики могут быть разбиты на различные категории по следующему принципу: промышленные приборы учета, домовые счетчики, квартирные счетчики, приборы учета для транспортных средств и т.п. С этими различными категориями приборов учета могут работать разные терминальные системы HeadEnd (такие как промышленная терминальная система HeadEnd, жилищная терминальная система HeadEnd и транспортная терминальная система HeadEnd). Команду передают в соответствующую терминальную систему HeadEnd, которая в свою очередь посылает команду соединения/разъединения интеллектуальному прибору учета.
Различные терминальные системы HeadEnd могут отличаться по нескольким аспектам, включая разные форматы, разные типы управляемой нагрузки (например, терминальные системы HeadEnd большой плотности в отличие от терминальных систем HeadEnd низкой плотности). Как более подробно рассмотрено ниже, в различных применяемых терминальных системах HeadEnd может насчитываться большое число выходных соединений.
Команда для прибора учета может быть «издана» в шине, такой как одна из шин, описанных на фиг.6А-С. Например, может быть один «издатель» ("publisher") и несколько «подписчиков» (subscriber), которые должны получить эту команду. В другом примере может быть несколько издателей и несколько подписчиков. В рассматриваемой конфигурации нет каких-либо ограничений типа «привязки» к какой-то конкретной технологии. При этом рассматриваемая конфигурация допускает адаптацию к какому-либо издателю или подписчику. Как обсуждается применительно к фиг.3, издателю и подписчику нет необходимости знать какой-то «общий формат». Вместо этого, шлюз INDE Gateway может адаптировать связь к каждому сочетанию издатель/подписчик, исключая тем самым необходимость в по меньшей мере в некоторой степени общем формате.
Далее, модель издатель-подписчик в современном варианте может функционировать различными способами. Например, модель издатель-подписчик может работать в режиме активной передачи ("push"), когда издатель передает («толкает», "pushes") данные (такие, как команды), а подписчик запрашивает и принимает («вытягивает», "pulls") эти данные. В качестве другого примера, модель издатель-подписчик позволяет активно передавать данные ("push") и активно запрашивать и принимать данные ("pull") обоим - и издателю, и подписчику. В частности один или несколько соединителей в составе шлюза INDE Gateway могут быть конфигурированы для активного запроса и приема ("pull") данных и/или для активной передачи ("push") данных. Например, GMS-соединитель (или FTP-соединитель) может быть конфигурирован для активного запроса ("pull") данных у системы-источника. Либо один из соединителей в составе шлюза INDE Gateway может быть конфигурирован в виде веб-сервиса, так что система-источник может обращаться к этому веб-сервису и активно передавать данные. Кроме того, оба соединителя - входной соединитель и выходной соединитель, могут поддерживать и режим активной передачи (push), и режим активного запроса (pull) одновременно.
Другой пример команды может содержать команду считывания показаний приборов учета по запросу (On-Demand Meter Read). Система MDM, такая как LodeStar или Itron, может передать запрос на получение информации от приборов учета в одну из нескольких разных терминальных систем HeadEnd, такую как Защита (Secure) или Ток (Current).
Система-источник может также передавать информацию в целевую систему. Один из примеров этого представляет собой периодическое считывание показаний приборов учета (Periodic Meter Read). Терминальная система HeadEnd, такая как Защита (Secure) или Ток (Current), может передавать данные приборов учета в одну или несколько систем MDM.
При таком подходе предлагаемая конфигурация может решить проблему, связанную с наличием большого числа систем-источников и большого числа целевых систем, что усложняет форматирование и маршрутизацию (направление) команд. Шлюз INDE Gateway, и благодаря отделению его от ядра INDE Core, и в силу его собственной конфигурации, позволяет осуществлять усложненную маршрутизацию/форматирование и позволяет адаптироваться к разнообразным системам-источникам или целевым системам. Для систем MDM, которые действуют в качестве систем-источников, и для терминальных систем HeadEnd, которые действуют в качестве целевых систем, шлюз INDE Gateway может соответствующим образом адаптировать соединители (такие как входные соединители, поддерживающие связь с каждой из нескольких систем-источников, и выходные соединители, поддерживающие связь с каждой из нескольких целевых систем). Для этого, шлюз INDE Gateway может содержать несколько входных соединителей для каждой из нескольких систем MDM и может содержать несколько выходных соединителей для каждой из нескольких терминальных систем HeadEnd, как обсуждается более подробно на фиг.3 и 5. Для терминальных систем HeadEnd, которые действуют в качестве систем-источников, и систем MDM, которые действуют в качестве целевых систем, шлюз INDE Gateway может соответствующим образом адаптировать соединители (такие как входные соединители, поддерживающие связь с каждой из нескольких систем-источников, и выходные соединители, поддерживающие связь с каждой из нескольких целевых систем). Для этого, шлюз INDE Gateway может содержать несколько входных соединителей для каждой из нескольких терминальных систем HeadEnd и может содержать несколько выходных соединителей для каждой из нескольких систем MDM, как обсуждается более подробно на фиг.4. Для системы, в которой часть времени система MDM действует в качестве системы-источника, а часть времени в качестве целевой системы, и в которой часть времени терминальная система HeadEnd действует в качестве системы-источника, а часть времени в качестве целевой системы, шлюз INDE Gateway может содержать соединители обоих типов - и показанные на фиг.3 и 5, и показанные на фиг.4. Более конкретно, шлюз INDE Gateway может содержать несколько входных соединителей и несколько выходных соединителей для каждой из нескольких систем MDM и может содержать несколько входных соединителей и несколько выходных соединителей для каждой из нескольких терминальных систем HeadEnd.
Ядро INDE Core может аналогичным образом адаптировать свои операции, например, настраивать свои адаптеры, как более подробно обсуждается ниже. Например, для случая систем MDM, действующих в качестве систем-источников, и терминальных систем HeadEnd, действующих в качестве целевых систем, ядро INDE Core может содержать адаптеры ядра, транслирующие данные от каждой системы MDM к каждой терминальной системе HeadEnd. Например, в системе, имеющей первую систему MDM и вторую систему MDM, а также первую терминальную систему HeadEnd и вторую терминальную систему HeadEnd, могут быть четыре адаптера ядра для осуществления взаимно-однозначной трансляции. В частности, здесь могут быть следующие адаптеры ядра: транслятор от первой системы MDM к первой терминальной системе HeadEnd; транслятор от первой системы MDM ко второй терминальной системе HeadEnd; транслятор от второй системы MDM к первой терминальной системе HeadEnd; и транслятор от второй системы MDM ко второй терминальной системе HeadEnd.
В качестве другого примера, для случая терминальных систем HeadEnd, действующих в качестве систем-источников, и систем MDM, действующих в качестве целевых системы, ядро INDE Core может содержать адаптеры ядра, транслирующие данные от каждой терминальной системы HeadEnd к каждой системе MDM. Например, в системе, имеющей первую терминальную систему HeadEnd и вторую терминальную систему HeadEnd, а также первую систему MDM и вторую систему MDM, могут быть четыре адаптера ядра для осуществления взаимно-однозначной трансляции. В частности, здесь могут быть следующие адаптеры ядра: транслятор от первой терминальной системы HeadEnd к первой системе MDM; транслятор от первой терминальной системы HeadEnd ко второй системе MDM; транслятор от второй терминальной системы HeadEnd к первой системе MDM; и транслятор от второй терминальной системы HeadEnd ко второй системе MDM.
Кроме того, в системе, в которой часть времени система MDM действует в качестве системы-источника, а часть времени в качестве целевой системы, и в которой часть времени терминальная система HeadEnd действует в качестве системы-источника, а часть времени в качестве целевой системы, шлюз INDE Gateway может содержать адаптеры обоих типов - и показанные на фиг.3 и 5, и показанные на фиг.4. Более конкретно, шлюз INDE Gateway может осуществлять как взаимно-однозначную трансляцию от каждой из нескольких систем MDM к каждой из нескольких терминальных систем HeadEnd, так и взаимно-однозначную трансляцию от каждой из нескольких терминальных систем HeadEnd к каждой из нескольких систем MDM.
На фиг.2 показана диаграмма обмена на верхнем уровне сигналами, относящимися к запросу разъединения или соединения. Система MDM передает запрос разъединения или соединения в ядро INDE Core. Это ядро INDE Core принимает запрос, трансформирует этот запрос и передает трансформированный запрос в одну из терминальных систем HeadEnd, как более подробно обсуждается ниже. Терминальная система HeadEnd принимает трансформированный запрос, выполняет запрошенное действие и передает подтверждающую квитанцию ядру INDE Core. Ядро INDE Core, в свою очередь, принимает эту квитанцию, трансформирует ее и передает трансформированную квитанцию в систему MDM.
На фиг.3 показана подробная диаграмма обмена сигналами для 7 уровней, относящихся к запросу разъединения или соединения. Для этого запроса разъединения/соединения исходной системой является система MDM. Как обсуждается выше, к коммерческим примерам системы MDM относятся, но не ограничивают список, системы LodeStar и Itron. Аналогично, для рассматриваемого запроса разъединения/соединения целевой системой является терминальная система HeadEnd. Как обсуждается выше, система энергоснабжения может иметь терминальную систему HeadEnd одного из нескольких типов, такую как Защита (Secure) или Ток (Current).
Уровень соединительных сервисов экспорта/импорта (Export/Import Connector Services) содержит соединители, которые соединяют одну или несколько систем-источников и одну или несколько целевых систем. Эти соединители могут быть созданы с использованием языка программирования любого типа для описания взаимодействий с веб-сервисами (такой как язык выполнения бизнес-процессов (Business Process Execution Language (BPEL))).
Как показано на фиг.3, уровень соединительных сервисов экспорта/импорта имеет входные соединители (такие как с IPConnectorl no IPConnector6) и выходные соединители (такие как с OPConnectorl no OPConnector6) для систем-источников и целевых систем соответственно. Объект IPC_DisconnectReconnect_LodeStar_FTP (показан для соединителя IPConnectorl) может быть использован для приема запроса из пункта нахождения FTP системы LodeStar и передачи этого запроса интерфейсу соединительных сервисов (Connector Services Interface) (ядро INDE Core). Объект IPC_DisconnectReconnect_LodeStar_HTTP (показан для соединителя IPConnector3) может быть использован для приема запроса согласно протоколу HTTP от системы LodeStar и передачи этого запроса интерфейсу соединительных сервисов (ядро INDE Core). Объект IPC_DisconnectReconnect_LodeStar_JMS (показан для соединителя IPConnector2) может быть использован для приема запроса из очереди JMS системы LodeStar и передачи этого запроса интерфейсу соединительных сервисов (ядро INDE Core). Аналогично, объект IPC_DisconnectReconnect_Itron_FTP (показан для соединителя IPConnector4) может быть использован для приема запроса из пункта нахождения FTP системы Itron и передачи этого запроса интерфейсу соединительных сервисов (ядро INDE Core). Объект IPC_DisconnectReconnect_Itron_HTTP (показан для соединителя IPConnector6) может быть использован для приема запроса согласно протоколу HTTP от системы Itron и передачи этого запроса интерфейсу соединительных сервисов (ядро INDE Core). Объект IPC_DiscoimectRecormect_Itron_JMS (показан для соединителя IPConnector5) может быть использован для приема запроса из очереди JMS системы Itron и передачи этого запроса интерфейсу соединительных сервисов (ядро INDE Core).
Объект OPC_DisconnectReconnect_Secure_FTP (показан для соединителя OPConnector2) принимает данные запроса на разъединение/соединение от соединительного сервиса OSB (OSB Connector Service) и передает эти данные в систему Защита (Secure) в конфигурированный пункт нахождения FTP. Объект OPC_DisconnectReconnect_Secure_HTTP (показан для соединителя OPConnectorl) принимает данные запроса на разъединение/соединение от соединительного сервиса OSB и передает эти данные в систему Защита (Secure) с применением протокола HTTP. Объект OPC_DisconnectReconnect_Secure_JMS (показан для соединителя OPConnector3) принимает данные запроса на разъединение/соединение от соединительного сервиса OSB и передает эти данные в систему Защита (Secure) в очереди протокола JMS. Аналогично, объект OPC_DisconnectReconnect_Current_FTP (показан для соединителя OPConnector5) принимает данные запроса на разъединение/соединение от соединительного сервиса OSB и передает эти данные в систему Ток (Current) в конфигурированный пункт нахождения FTP. Объект OPC_DisconnectReconnect_Current_HTTP (показан для соединителя OPConnector4) принимает данные запроса на разъединение/соединение от соединительного сервиса OSB и передает эти данные в систему Ток (Current) с применением протокола HTTP. Объект OPC_DisconnectReconnect_Current_JMS (показан для соединителя OPConnector6) принимает данные запроса на разъединение/соединение от соединительного сервиса OSB и передает эти данные в систему Ток (Current) в очереди протокола JMS.
Как показано на фиг.3, для каждой оконечной системы (включая системы обоих типов - систем-источников и целевых систем) уровень соединительных сервисов экспорта/импорта может создать несколько типов соединителей. Например, фиг.3 показывает, что уровень соединительных сервисов экспорта/импорта включает три разных соединителя, поддерживающих три разных протокола, а именно HTTP, FTP и JMS. В таком интерфейсе система MDM может передавать файл с использованием одного из нескольких разных протоколов. В примере, показанном на фиг.3, система MDM передает файл в соответствии с протоколом FTP. Здесь другие два соединителя показаны затененными. Кроме того, в примере, приведенном на фиг.3, целевая система (Целевая система 1 (Ток (Current))) ожидает данные в формате HTTP. Следовательно, OPCormector4, использующий протокол Http, выделен, а другие показаны затененными. Эти соединители способны проверять структуру принимаемых входных данных. В случае ошибки соединитель привлекает сервис устранения ошибок. Поскольку функциональные возможности уровня соединительных сервисов экспорта/импорта резидентны в шлюзе INDE Gateway и отделены от ядра INDE Core, этот уровень соединительных сервисов экспорта/импорта может быть конфигурирован или адаптирован одним из нескольких способов в зависимости от требований клиента.
Уровень интерфейса соединительных сервисов (ядро INDE Core) содержит компонент ядра, привлекающий сервис OSB (Oracle Service Bus). В случае ошибки компонент привлекает сервис устранения ошибок. Вследствие такой конфигурации (отделение компонентов ядра INDE Core от компонентов шлюза INDE Gateway), уровень интерфейса соединительных сервисов в ядре (INDE Core) нет необходимости модифицировать согласно требованиям клиента.
Уровень OSB (ядро INDE Core) обращается к файлу lookup.config, чтобы выбрать подходящую трансформацию на основе данных об оконечных системах. После трансформации уровень OSB INDE Core передает данные диспетчеру. Этот диспетчер асинхронно распределяет (диспетчирует) данные для передачи целевым системам. В случае ошибки он привлекает сервис устранения ошибок.
Уровень OSB (INDE Core) содержит OSB-компоненты ядра, в состав которых входит прокси-сервис для осуществления трансформации данных на основе формата сообщений в целевой системе. Объект PS_AMI_DisconnectReconnect может содержать имя прокси-сервиса, который принимает входные данные от интерфейса соединительных сервисов (ядро INDE Core) и устанавливает по меньшей мере один параметр маршрутизации (такой как заголовок маршрутизации входящего запроса на 'Разъединение/Соединение'). В случае прихода запроса, объект PS AMI_DisconnectReconnect далее передает параметр маршрутизации объекту PS_Foundation_TransformAndDispatch_Sync. В случае прихода запроса, объект PS_AMI_DisconnectReconnect передает параметр маршрутизации интерфейсу соединительных сервисов (INDE Core).
Объект PS_Foundation_TransformAndDispatch_Sync может содержать прокси-сервис, принимающий запрос от объекта PS_AMI_ConnectDisconnect и осуществляющий трансформацию на основе заголовка маршрутизации в запросе и файла AMI_Lookup.config. Эта трансформация может включать, например, преобразование от LodeStar к HeadEnd, от HeadEnd к Itron и т.п. Трансформированные данные могут быть переданы объекту PS_Foundation_SynchronousRouter вместе с одним или несколькими заголовками, такими как два заголовка viz. 'routingservice' и 'invokingoperation' для динамической маршрутизации в маршрутизаторе объекта Р S_Foundation_SynchronousRouter.
Объект PS_Foundation_SynchronousRouter вызывает имя 'routingservice' и имя 'invokingoperation' из группы заголовков пользователей, заданной в объекте PS_Foundation_TransformAndDispatch_Sync. Затем объект PS_Foundation_Synchronous_Router динамически направляет данные бизнес-сервису, указанному в заголовке routingservice.
Уровень OSB (INDE Core) включает один или несколько адаптеров ядра INDE. Как показано на фиг.3, эти адаптеры ядра INDE перечислены в списке трансформаций от различных систем-источников к различным целевым системам. В частности, фиг.3 иллюстрирует трансформацию XQuery от системы-источника 1 к целевой системе 1 в виде Srcl_to_tgtl.xq. Конкретную трансформацию XQuery выбирают на основе файла AMI_Lookup.config. Например, файл LodeStar_To_Secure.xq представляет трансформацию от формата LodeStar Request запроса к формату Secure Request запроса. Файл Secure_To_LodeStar.xq представляет трансформацию из формата Secure Response ответа к формату LodeStar Response ответа. Файл Itron_To_Secure.xq представляет трансформацию из формата Itron Request запроса к формату Secure Request запроса. Файл Secure_To_Itron.xq представляет трансформацию из формата Secure Response ответа к формату Itron Response ответа. Файл LodeStar_To_Current представляет трансформацию из формата LodeStar Request запроса к формату Current Request запроса. Файл Current_To_LodeStar представляет трансформацию из формата Current Response ответа к формату LodeStar Response ответа. Файл Itron_To_Current представляет трансформацию из формата Itron Request запроса к формату Current Request запроса. Файл Current_To_Itron.xq представляет трансформацию из формата Current Response ответа к формату Itron Response ответа. Помимо трансформаций от различных систем источников к различным целевым системам могут быть включены специализированные адаптеры ядра для дополнительных трансформаций помимо ядра INDE Core. Например, файл CustomXquery_Req.xq может содержать файл Xquery запроса, осуществляющий взаимнооднозначное преобразование от входных данных к выходным данным, и может быть разработан для уровня расширения INDE Extension. Файл CustomXquery_Res.xq может содержать файл Xquery ответа, осуществляющий взаимно-однозначное преобразование от входных данных к выходным данным, и может быть разработан для уровня расширения INDE Extension.
Уровень соединительных сервисов OSB (шлюз INDE Gateway) содержит бизнес-сервисы OSB. Этот уровень принимает данные от диспетчера и передает их выходным соединителям (таким как с OPConnectorl по OPConnector6). Как показано на фиг.3, имеются по одному бизнес-сервису на каждый выходной соединитель. Например, соединительные сервисы OSB (шлюз INDE Gateway) включают объект BS_AMI_DisconnectReconnect_Secure_FTP, который может содержать бизнес-сервис, принимающий вызов от диспетчера (в зависимости от заголовка сообщения) и вызывающий объект OPC_DisconnectReconnect_Secure_FTP (описан в соединительных сервисах экспорта/импорта (шлюз INDE Gateway)). Объект BS_AMI_DisconnectRecoimect_Secure_HTTP может содержать бизнес-сервис, принимающий вызов от диспетчера (в зависимости от заголовка сообщения) и вызывающий объект OPC_DisconnectReconnect_Secure_HTTP (описан в соединительных сервисах экспорта/импорта (шлюз INDE Gateway)). Объект BS_AMI_DisconnectReconnect_Secure_JMS представляет собой бизнес-сервис, принимающий вызов от диспетчера (в зависимости от заголовка сообщения) и вызывающий объект OPC_DisconnectReconnect_Secure_JMS (описан в соединительных сервисах экспорта/импорта (шлюз INDE Gateway)). Объект BS_AMI_DisconnectReconnect_Current_FTP представляет собой бизнес-сервис, принимающий вызов от диспетчера (в зависимости от заголовка сообщения) и вызывающий объект OPC_DisconnectReconnect_Current_FTP (описан в соединительных сервисах экспорта/импорта (шлюз INDE Gateway)). Объект BS_AMI_DisconnectReconnect_Current_HTTP представляет собой бизнес-сервис, принимающий вызов от диспетчера (в зависимости от заголовка сообщения) и вызывающий объект OPC_DisconnectReconnect_Current_HTTP (описан в соединительных сервисах экспорта/импорта (шлюз INDE Gateway)). Объект BS_AMI_DisconnectReconnect_Current_JMS представляет собой бизнес-сервис, принимающий вызов от диспетчера (в зависимости от заголовка сообщения) и вызывающий объект OPC_DisconnectReconnect_Current_JMS (описан в соединительных сервисах экспорта/импорта (шлюз INDE Gateway)). Наконец, объект BS_AMI_ DisconnectReconnect_Extn может вызывать выходной соединитель (такой как OPConnector 4) для удаленной базы данных (Remote Database (DB)), которая может быть базой данных уровня расширения.
Уровень OSB (расширение INDE Extension) обеспечивает специализированную трансформацию для оконечных систем с неизвестными форматами сообщений. Эту способность можно соединить с удаленной базой данных, как показано на фиг.3. Объект PS_AMI_DisconnectReconnect_Extn может содержать прокси-сервис из состава уровня OSB (расширение INDE Extension). Объект PS_AMI_DisconnectReconnect_Extn может применять несколько различных форм запросов, таких как две специализированных формы Xqueries запроса, рассчитанные на запрос собранных групп данных XML. Эти две специализированные формы Xqueries запроса могут быть предназначены для запроса и для ответа. Например, применяя форму Xquery запроса, объект PS_AMI_DiscoimectReconnect_Extn может передать трансформированный запрос бизнес-сервису уровня расширения, например, объекту BS_AMI_DisconnectReconnect_Extn.
Сервис устранения ошибок может содержать отдельный процесс, который может быть привлечен другими процессами на разных уровнях для обработки различных исключений.
На фиг.3 показан пример процесса обработки сигналов и данных. На этапе 1 соединительные сервисы экспорта/импорта (шлюз INDE Gateway) принимают запрос разъединения или соединения из системы MDM, такой как система-источник 1 или система-источник 2, с использованием протокола FTP. На этапе 2 соединитель IPConnector передает запрос интерфейсу соединительных сервисов (ядроПЖЕ Core). На этапе 3 интерфейс соединительных сервисов (ядро INDE Core) вызывает сервис OSB (ядро INDE Core). На этапе 4 этот сервис OSB (ядро INDE Core) осуществляет просмотр. На этапе 5 сервис OSB (ядро INDE Core) выполняет трансформацию, с использованием адаптеров ядра INDE, в соответствии с целевой системой HeadEnd. На этапе 6 сервис OSB (ядро INDE Core) диспетчирует запрос к соединительным сервисам OSB (шлюз INDE Gateway). На этапе 7 соединительные сервисы OSB осуществляют передачу к соединительным сервисам экспорта/импорта (шлюз INDE Gateway). На этапе 8 соединительные сервисы экспорта/импорта (INDE Gateway) передают запрос в терминальную систему HeadEnd, такую как Защита (Secure) или Ток (Current), с целью выполнения действия (такого как разъединение или соединение). После успешного завершения разъединения/соединения передают в обратном порядке (этапы с 7 по 1) ответ в систему MDM с использованием всех перечисленных выше процессов.
Фиг.4 представляет пример подробной диаграммы обмена сигналами для периодического считывания показаний счетчиков. В таком случае система-источник представляет собой одну из терминальных систем типа HeadEnd, такую как Ток (Current) или Защита (Secure), а целевая система представляет собой одну из систем MDM, такую как LodeStar или Itron.
Аналогично показанному на фиг.3, уровень соединительных сервисов экспорта/импорта (шлюз INDE Gateway) включает различные процедуры на входной стороне для разных типов систем-источников и разных форматов, такие как объекты IPC_PeriodicMeterRead_Secure_Http, IPC_PeriodicMeterRead_Secure_JMS, IPC_PeriodicMeterRead_Secure_FTP, IPC_PeriodicMeterRead_Current_Http, IPC_PeriodicMeterRead_Current_JMS и IPC_PeriodicMeterRead_Current_FTP. Далее, уровень соединительных сервисов экспорта/импорта (шлюз INDE Gateway) включает различные процедуры на выходной стороне для разных типов целевых систем и разных форматов, такие как объекты OPC_PeriodicMeterRead_LodeStar_Http, OPC_PeriodicMeterRead_LodeStar_JMS, OPC_PeriodicMeterRead_LodeStar_FTP, OPC_PeriodicMeterRead_Itron_Http, OPC_PeriodicMeterReadJtron_JMS и OPC_PeriodicMeterRead_Itron_FTP.
Уровень интерфейса соединительных сервисов (ядро INDE Core) принимает входные сигналы от уровня соединительных сервисов экспорта/импорта (шлюз INDE Gateway) и вызывает сервис OSB (ядро INDE Core). В частности, объект BP_AMI_PeriodicMeterRead вызывает сервис OSB и проверяет, установлен ли флаг синхронизации. Если флаг установлен, определяют, имеется ли дубликат идентификатора устройства (Device ID). Если такого идентификатора нет, обновляют базу данных INDE Database (DB) путем введения идентификатора Device ID в базу данных INDE DB.
Уровень OSB (ядро INDE Core) и соединительные сервисы OSB (шлюз INDE Gateway), показанные на фиг.4, действуют аналогично уровню OSB (ядро INDE Core) и соединительным сервисам OSB (шлюз INDE Gateway), обсуждаемым в связи с фиг.3.
Фиг.5 иллюстрирует пример подробной диаграммы обмена сигналами в процессе считывания показаний счетчиков по требованию (On Demand). В этом случае система-источник содержит одну из систем MDM, такую как LodeStar или Itron, а целевая система содержит одну из терминальных систем HeadEnd, такую как Ток (Current) или Защита (Secure).
Фиг.6А-С представляет блок-схему одного примера общей архитектуры для энергосистемы. Эта архитектура, включающая ядро INDE Core 55 в сочетании со шлюзом INDE Gateway 60, позволяет реализовать функциональные возможности, которые могут быть важны для интеллектуальной энергосистемы и среди которых могут быть: (1) процессы сбора данных; (2) процессы категоризации и постоянного сохранения данных; и (3) процессы наблюдаемости. Как более подробно обсуждается ниже, использование этих процессов позволяет «наблюдать» за энергосистемой, анализировать данные и получать информацию об энергосистеме.
Архитектура, показанная на фиг.6А-С, приведена только в качестве иллюстрации и может служить опорной моделью для сквозного сбора, передачи, хранения и управления данными в интеллектуальной энергосистеме; архитектура обеспечивает также аналитику и управление на основе результатов анализа, равно как интеграцию всего вышеизложенного в процессы и системы энергоснабжающей компании. Следовательно, предлагаемую архитектуру можно рассматривать в качестве архитектуры, действующей в пределах всего предприятия. Некоторые элементы, такие как оперативное управление и аспекты самой энергосистемы, более подробно осуждаются ниже.
Архитектура, показанная на фиг.6А-С, может включать до четырех шин передачи данных и интеграционных шин: (1) высокоскоростная шина 146 данных датчиков (сюда могут входить как оперативные, так и неоперативные данные); (2) специализированная шина 147 обработки событий (сюда могут входить данные событий); (3) шина 130 оперативного обслуживания (которая может служить для предоставления информации относительно интеллектуальной энергосистемы приложениям отдела оперативного учета и контроля энергоснабжающей компании); и (4) сервисная шина предприятия для IT систем отделов оперативного управления и учета (показана на фиг.6А-С в качестве интеграционной шины 114 среды предприятия для обслуживания систем IT 115 предприятия). Эти отдельные шины данных могут быть реализованы одним или несколькими способами. Например, две или более шины данных, такие как высокоскоростная шина 146 данных датчиков и шина 147 обработки событий, могут представлять собой разные сегменты одной и той же шины данных. В частности, эти шины могут иметь сегментированную структуру или платформу. Как будет подробнее обсуждаться ниже, для маршрутизации данных в разных сегментах шины данных могут быть использованы аппаратные и/или программные средства, такие как один или несколько переключателей.
В качестве другого примера, две или более шины данных могут быть реализованы в виде отдельных шин, таких как физически отдельные шины с точки зрения аппаратуры, необходимой для передачи данных в отдельных шинах. В частности, каждая из этих шин может содержать кабели, отдельные один от другого. Далее, некоторые или все такие отдельные шины могут быть одного и того же типа. Например, одна или несколько шин могут содержать локальную сеть связи (local area network (LAN)), такую как Ethernet®, использующую линии передачи в виде неэкранированных витых пар и Wi-Fi. Как более подробно обсуждается ниже, для маршрутизации данных из одной шины данных в разные физические шины могут быть использованы аппаратные и/или программные средства, такие как маршрутизатор.
В качестве еще одного примера, две или более шин могут быть реализованы в виде разных сегментов одной и той же структуры шин, а также одна или несколько шин могут быть реализованы в виде отдельных физических шин. В частности, высокоскоростная шина 146 данных датчиков и шина 147 обработки событий могут быть разными сегментами в одной и той же шине данных, тогда как интеграционная шина 114 среды предприятия может быть организована в виде физически отдельной шины.
Хотя на фиг.6А-С показаны четыре шины, для передачи четырех перечисленных типов данных могут быть использованы меньшее или большее число шин. Например, одна несегментированная шина данных может быть использована для передачи данных датчиков и данных обработки событий (в результате чего общее число шин становится равным трем), как обсуждается ниже. Кроме того, система может работать без шины 130 оперативного обслуживания и/или интеграционной шины 114 среды предприятия.
Среда IT может быть совместима с архитектурой SOA. Сервисно-ориентированная архитектура (Service Oriented Architecture (SOA)) представляет собой тип архитектуры компьютерной системы для создания и использования бизнес-процессов, упакованных в виде сервисов, в продолжение всего их срока действия. Архитектура SOA также определяет и создает инфраструктуру IT, чтобы различные приложения могли обмениваться данными и участвовать в бизнес-процессах. В то же время, использование архитектуры SOA и сервисной шины предприятия являются опциями.
Чертежи иллюстрируют различные элементы общей архитектуры, такие как: (1) ядро INDE Core 55; (2) подстанция INDE Substation 180; и (3) устройство INDE Device 188. Такое подразделение элементов в рамках общей архитектуры служит для иллюстрации. Могут быть использованы другие варианты подразделения элементов. Архитектура INDE может быть использована для поддержки обоих - распределенного и централизованного, подходов к обеспечению «интеллектуальности» энергосистемы и для создания механизмов, позволяющих работать в условия масштабирования в больших системах.
Опорная архитектура INDE (INDE Reference Architecture) является одним из примеров реализуемой технической архитектуры. Например, это может быть один из примеров метаархитектуры, используемой в качестве исходной точки для любого числа конкретных технических архитектур, по одной для каждого решения для энергоснабжающей компании, как будет обсуждаться ниже. Таким образом, конкретное решение для каждой отдельно взятой энергоснабжающей компании может включать один, некоторые или все элементы опорной архитектуры INDE. Кроме того, эта опорная архитектура INDE может служить стандартизованной исходной точкой для разработки соответствующих решений. Ниже обсуждается методика определения специфичной технической архитектуры для конкретной энергосистемы.
Опорная архитектура INDE Reference Architecture может быть архитектурой для всего предприятия. Она может быть предназначена для создания некоторой базовой структуры для сквозного управления данными сети, а также анализа и интеграции этих данных и результатов анализа в систему и процессы энергоснабжающей компании. Поскольку технология интеллектуальной энергосистемы влияет на каждый аспект бизнес-процессов энергоснабжающей компании, не следует забывать о воздействии этой технологии не только на уровне собственно энергосети, оперативном уровне и уровне объектов клиентов, но также на уровне отдела оперативного учета и контроля и уровне предприятия. Следовательно, опорная архитектура INDE Reference Architecture может создать и создает опорную структуру SOA на уровне предприятия, например, с целью поддержки среды SOA для реализации интерфейсов с другими системами. Это не следует понимать в качестве требования, что энергоснабжающая компания обязательно должна преобразовать свою существующую IT-среду в архитектуру SOA, прежде чем можно будет построить и использовать интеллектуальную энергосистему. Сервисная шина предприятия представляет собой полезный механизм, способствующий интеграции IT, но ее наличие не требуется для реализации остальной части решения интеллектуальной энергосистемы. Приведенное ниже обсуждение сосредоточено на различных компонентах элементов интеллектуальной энергосистемы INDE.
Группы компонентов INDE
Как указано выше, различные компоненты опорной архитектуры INDE Reference Architecture могут включать, например: (1) шлюз INDE Core 55; (2) подстанцию INDE Substation 180; и (3) устройство INDE Device 188.
Ядро INDE Core 55 представляет собой часть опорной архитектуры INDE Reference Architecture, которая может находиться в центре оперативного управления, как показано на фиг.6А-С. Ядро INDE Core 55 может содержать унифицированную архитектуру данных для хранения данных энергосистемы и схему интеграции для анализа и работы с этими данными. Эта архитектура данных может использовать общую информационную модель (модель CIM), созданную международной электротехнической комиссией (Electrotechnical Commission (IEC) Common Information Model (CIM)) в качестве схемы верхнего уровня. Модель IEC CIM представляет собой стандарт, разработанный для электроэнергетической отрасли и официально принятый IEC, с целью дать возможность прикладному программному обеспечению обмениваться информацией относительно конфигурации и состояния электрической сети.
Кроме того, эта архитектура данных может использовать объединяющее промежуточное программное обеспечение (Federation Middleware) 134 для соединения с данными других типов энергоснабжающей компании (такими как, например, данные приборов учета, оперативные данные и данные предыстории, файлы системных журналов и файлы событий), а также файлами соединений и файлами метаданных в единую архитектуру данных, которая может иметь единую точку входа для доступа посредством приложений высокого уровня, включая приложения предприятия. Системы реального времени могут также получать доступ к сохраняемым ключевым данным посредством высокоскоростной шины данных, а также некоторые хранилища данных могут принимать данные в реальном времени. По одной или нескольким шинам данных в интеллектуальной сети можно передавать данные различных типов. Как обсуждается ниже в разделе о подстанции INDE Substation 180, данные подстанции можно собирать и хранить локально, на этой подстанции. В частности, эти данные подстанции может сохранять база данных, ассоциированная с этой подстанцией и расположенная рядом с ней. Функции анализа, относящиеся к уровню подстанции, также могут выполнять компьютеры этой подстанции и сохранять результаты в базе данных подстанции, и кроме того, все или часть этих данных можно передавать в центр управления.
Передавать можно данные различных типов и в том числе, оперативные и неоперативные данные, события, данные о соединениях энергосистемы и данные о местонахождении в сети. Оперативные данные могут включать, не ограничиваясь, состояние переключателей, состояние фидеров, состояние конденсаторов, состояние секций, состояние приборов учета (счетчиков), состояние FCI, состояние линейных датчиков, напряжение, ток, действительную (активную) мощность, реактивную мощность и т.п. Неоперативные данные могут включать, не ограничиваясь, качество электроэнергии, надежность энергоснабжения, состояние активов, стресс-данные и т.п. Оперативные и неоперативные данные можно передавать с использованием шины 146 оперативных/неоперативных данных. Ответственности за передачу некоторых или всех этих данных в шину 146 оперативных/неоперативных данных могут нести приложения для сбора данных в секторах передачи электроэнергии и/или распределения электроэнергии в энергосистеме. При таком подходе, приложения, нуждающиеся в этой информации, могут получать эти данные путем подписки на такую информацию или путем привлечения сервисов, которые могут сделать эти данные доступными.
События могут включать сообщения и/или сигнализацию, исходящие от различных устройств и датчиков, которые являются частью интеллектуальной сети, как осуждается ниже. События могут быть генерированы непосредственно устройствами и датчиками в сети связи интеллектуальной энергосистемы, равно как такие события могут быть генерированы разнообразными аналитическими приложениями на основе данных результатов измерений от этих датчиков и устройств. Примерами таких событий могут быть отключения или неисправность приборов учета, срабатывание сигнализации приборов учета, отключение или неисправность трансформаторов и т.п. Данные событий, оперативные и неоперативные данные могут генерировать компоненты энергосистемы, такие как сетевые устройства (интеллектуальные датчики мощности (такие как датчик с встроенным процессором, который может быть запрограммирован для цифровой обработки данных), датчики температуры и т.п.), компоненты энергосистемы, включающие дополнительные встроенные средства обработки данных (удаленные терминалы (RTU) и т.п.), интеллектуальные сети приборов учета (счетчиков) (состояние исправности приборов учета, считывание показание приборов учета и т.п.) и устройства мобильных полевых бригад (события неисправностей и отключений, завершение работ по наряду и т.п.). Такие данные событий, генерируемые в интеллектуальной энергосистеме, могут быть переданы в шине 147 событий.
Данные о соединениях энергосистемы могут определять топологию местной энергоснабжающей сети. Это может быть базовая топология, которая определяет физическую топологию компонентов энергосистемы (подстанций, сегментов, фидеров, трансформаторов, переключателей, автоматов повторного включения, приборов учета, датчиков, электрических столбов) и соединений между ними при монтаже. Данные о соединениях энергосистемы могут изменяться на непрерывной основе в соответствии с событиями в энергосистеме (отказы компонентов, действия по техническому обслуживанию и т.п.). Как будет более подробно обсуждаться ниже, структура хранения данных, а также сочетание данных позволяют осуществить историческую реконструкцию топологии энергосистемы в различные моменты в прошлом. Данные о соединениях энергосистемы можно получать из географической информационной системы (Geographic Information System (GIS)) на периодической основе по мере того, как в местную энергоснабжающую сеть будут вноситься модификации, и соответствующая информация будет обновляться в приложениях GIS.
Данные о местонахождении в сети могут включать информацию о местонахождении компонентов энергосистемы в сети связи. Эта информация может быть использована для передачи сообщений и информации конкретному компоненту энергосистемы. Данные о местонахождении в сети могут быть введены вручную в базу данных интеллектуальной энергосистемы по мере установки новых компонентов этой интеллектуальной энергосистемы, либо получены из системы управления активами (объектами имущества) (Asset Management System), если эта информация хранится вовне.
Данные можно передавать от различных компонентов энергосистемы (таких как подстанция INDE Substation 180 и/или устройство INDE Device 188). Эти данные можно передавать в ядро INDE Core 55 по радио, по проводам или путем сочетания этих двух способов. Эти данные может принимать сеть 160 управления энергоснабжающей компании, которая может передавать данные устройству 190 маршрутизации. Устройство 190 маршрутизации может содержать программное обеспечение и/или аппаратуру для управления маршрутизацией данных в сегмент шины данных (когда шина данных имеет сегментированную структуру) или в отдельную шину данных. Устройство 190 маршрутизации может содержать сетевое устройство, программное обеспечение и аппаратура которого направляют и/или ретранслируют данные в одну или несколько шин данных. Например, устройство 190 маршрутизации может направлять оперативные и неоперативные данные в шину 146 оперативных/неоперативных данных. Маршрутизатор может также направлять данные событий в шину 147 событий.
Устройство 190 маршрутизации может определять, как направлять данные, одним или несколькими возможными способами. Например, устройство 190 маршрутизации может проанализировать один или несколько заголовков передаваемых данных, чтобы определить, нужно ли направить данные в сегмент для шины 146 оперативных/неоперативных данных или в сегмент для шины 147 событий. В частности, один или несколько заголовков данных могут указывать, являются ли данные оперативными/неоперативными данными (так что устройство 190 маршрутизации направляет эти данные в шину 146 оперативных/неоперативных данных) или данными событий (так что устройство 190 маршрутизации направляет эти данные в шину 147 событий). В альтернативном варианте устройство 190 маршрутизации может проанализировать полезную нагрузку данных, чтобы определить тип этих данных (например, устройство 190 маршрутизации может проанализировать формат данных, чтобы определить, являются ли рассматриваемые данные оперативными/неоперативными данными или данными событий).
Одно из хранилищ, такое как хранилище оперативных данных (не показано на фиг.6А-С), сохраняющее оперативные данные, может быть реализовано в виде истинно распределенной базы данных. Другие хранилища, исторические, могут быть реализованы в виде распределенной базы данных. Другие «концы» этих двух баз данных могут располагаться в группе подстанций INDE Substation 180. Далее, события могут быть сохранены непосредственно в любом из нескольких хранилищ данных, куда они могут поступить по комплексной шине обработки событий. В частности, события могут быть сохранены в журналах регистрации событий, которые могут быть хранилищем для всех событий, информация о которых может быть передана («опубликована») по шине 147 событий. Журнал регистрации событий может сохранять информацию об одном, некоторых или всех следующих параметрах событий: идентификатор события, тип события, источник события и время возникновения события. Шине 147 событий нет необходимости сохранять информацию о событии в течение продолжительного времени, поддерживая сохранение всех событий.
Способ хранения данных может быть таким, чтобы данные находились так близко к источнику, как это только возможно или практически удобно. В одном из вариантов, например, данные подстанции могут храниться на подстанции INDE Substation 180. Однако эти данные могут потребоваться для операций на уровне центра 116 оперативного управления, чтобы принимать решения различных видов, рассматривающие энергосистему на значительно более дробном уровне. В сочетании с подходом распределенного интеллектуального управления подход распределенного хранения данных может быть применен для облегчения доступа к данным на всех уровнях принятия решений с использованием связей базы данных и сервисов данных, где применимо. При таком подходе, решение для хранилища исторических данных (которые могут быть доступны на уровне центра 116 оперативного управления) может быть аналогично решению для хранилища оперативных данных. Данные могут храниться локально, на подстанции, а связи базы данных, конфигурированные для события сохранения в центре оперативного управления, обеспечивают доступ к данным на индивидуальных подстанциях. Аналитические процессы подстанции могут быть выполнены локально, на соответствующей подстанции с использованием местного хранилища данных. Исторический/совместный анализ может быть осуществлен на уровне центра 116 оперативного управления путем получения доступа к данным о локальных событиях на подстанциях с использованием связей базы данных. В альтернативном варианте данные могут храниться централизованно в ядре INDE Core 55. Однако учитывая объем данных, которые может потребоваться передать от устройств INDE Devices 188, сохранение данных в устройствах INDE Devices 188 может оказаться предпочтительным. В частности, если имеется несколько тысяч или десятков тысяч подстанций (что вполне может быть в энергосистеме), объем данных, который нужно передавать в ядро INDE Core 55, может вызвать ограничение пропускной способности каналов связи.
Наконец, ядро INDE Core 55 может программировать или управлять одним, несколькими или всеми подстанциями INDE Substation 180 или устройствами INDE Device 188 в энергосистеме. Например, ядро INDE Core 55 может модифицировать программирование (загрузить обновленную программу) или передать команду управления каким-либо аспектом подстанции INDE Substation 180 или устройства INDE Device 188 (такую как управление датчиками или аналитическими функциями). Другие элементы ядра INDE Core 55 могут включать разнообразные интеграционные элементы для поддержки этой логической архитектуры.
События могут быть отделены от оперативных/неоперативных данных и могут быть переданы по отдельной или выделенной шине. События обычно имеют более высокий приоритет, поскольку они, как правило, требуют каких-то немедленных действий с точки зрения перспектив работы энергоснабжающей компании (сообщения от неисправных приборов учета, трансформаторов и т.п.)
Указанная шина обработки событий (и соответствующий сервис корреляционной обработки событий, показанный на фиг.6А-С) может фильтровать потоки событий для
Прежде оперативные данные передавали прямо конкретному устройству (создавая тем самым проблему изоляции ("silo"), состоящую в том, что данные при этом не становятся доступными для других устройств или других приложений). Например, оперативные данные прежде передавали в систему SCADA (диспетчерское управление и сбор данных) для управления энергосистемой (мониторинг и управление энергосистемой). Однако при применении структуры шин оперативные данные могут быть также использованы балансирования нагрузки, использования/оптимизации активов (имущественных объектов), системного планирования и т.п.
Неоперативные данные прежде получали путем посылки
Как обсуждается в табл.1, шина 146 данных реального времени (которая передает оперативные и неоперативные данные) и шина 147 комплексной обработки событий в реальном времени (которая передает данные обработки событий) могут быть объединены в одной шине 346.
Как показано на фиг.6А-С, эти шины разделены для улучшения функционирования системы. В случае комплексной обработки событий (СЕР) для некоторых приложений, в которых могут передаваться очень большие пачки сообщений, может быть важной низкая задержка. Большинство потоков данных энергосистемы, с другой стороны, являются более или менее постоянными, за исключением файлов цифровой регистрации событий, но их могут обычно вызывать на управляемой основе, тогда как пачки событий являются асинхронными и случайными.
На фиг.6А-С, кроме того, показаны дополнительные элементы в центре 116 оперативного управления, отдельном от ядра INDE Core 55. В частности, на фиг.6А-С дополнительно показан(ы) терминал(ы) 153 сбора данных от приборов учета (Meter Data Collection Headend(s)), система, отвечающая за связь с приборами учета (такую как сбор данных от этих приборов и передача собранных данных энергоснабжающей компании). Система 154 управления спросом представляет собой систему, поддерживающую связь с оборудованием на одном или нескольких объектах клиентов, которое может управляться энергоснабжающей компанией. Система 155 управления отключениями представляет собой систему, помогающую энергоснабжающей компании в устранении отключений и других неисправностей путем отслеживания местонахождений этих отключений и неисправностей, управления диспетчированием и порядком устранения таких отключений и неисправностей. Система 156 управления энергоснабжением представляет собой систему управления на уровне системы передачи энергии, которая управляет устройствами на подстанциях (например) сети электропередач. Система 157 управления распределением представляет собой систему управления на уровне системы распределения энергии, которая управляет устройствами на подстанциях и фидерными устройствами (например) для распределительной сети. Сетевые IP-сервисы 158 представляют собой совокупность сервисов, поддерживающих связь IP-типа (такие как протоколы DHCP и FTP). Система 159 диспетчирования данных для мобильных устройств представляет собой систему передачи/приема сообщений к/от мобильных терминалов данных, находящихся вне центра управления энергосистемы (в «поле»). Инструменты 152 для анализа схем и потоков нагрузки, планирования, анализа воздействия атмосферных разрядов и моделирования энергосистемы представляют собой совокупность инструментов, используемых энергоснабжающей компанией при проектировании, анализе и планировании энергосистем. Системы 151 - интегрированная система ответа на голосовые обращения (IVR) и система управления и обработки вызовов клиентов представляют собой системы для работы с телефонными обращениями клиентов (автоматизированные или с участием операторов). Входящие телефонные вызовы относительно отключений и других неисправностей могут быть автоматически или вручную введены и направлены в систему 155 управления отключениями. Система 150 управления работами представляет собой систему мониторинга и управления нарядами на выполнение работ. Географическая информационная система 149 представляет собой базу данных, содержащую информацию о том, где имущественные объекты расположены географически и как эти объекты соединены один с другими. Если среда имеет сервисно-ориентированную архитектуру (SOA), система 148 оперативной поддержки SOA представляет собой совокупность сервисов, поддерживающих среду SOA.
Одна или несколько таких систем, резидентных в центре 116 оперативного управления, находящемся вне ядра INDE Core 55, представляют собой существующие, ранее разработанные продукты, которые энергоснабжающая компания уже может иметь. К примерам таких уже существующих систем относятся система 148 оперативной поддержки SOA, географическая информационная система 149, система 150 управления работами, система 151 управления и обработки вызовов клиентов, совокупность инструментов 152 для анализа схем и потоков нагрузки, планирования, анализа воздействия атмосферных разрядов и моделирования энергосистемы, терминал(ы) 153 сбора данных от приборов учета, система 154 управления спросом, система 155 управления отключениями, система 156 управления энергоснабжением, система 157 управления распределением, сетевые IP-сервисы 158 и система 159 диспетчирования данных для мобильных устройств. Однако эти известные существующие системы могут оказаться неспособными обрабатывать или вообще обращаться с данными, принимаемыми из интеллектуальной энергосистемы. Ядро INDE Core 55 может быть способно принимать данные из интеллектуальной энергосистемы, обрабатывать эти данные и передавать обработанные данные одной или нескольким существующим системам в такой форме, чтобы существующие системы могли эти данные использовать (например, осуществлять конкретное форматирование специально для существующей системы). При таком подходе ядро INDE Core 55 можно рассматривать в качестве промежуточной программной системы.
Центр 116 оперативного управления, содержащий ядро INDE Core 55, может поддерживать связь с системой 155 IT предприятия. Вообще говоря, функциональные возможности системы 115 IT предприятия включают операции отдела оперативного учета и контроля. В частности, система 115 IT предприятия может использовать интеграционную шину 114 среды предприятия для передачи данных различным системам в составе системы 115 IT предприятия, и в том числе хранилищу 104 бизнес-данных, интеллектуальным бизнес-приложениям 105, системе 106 планирования ресурсов предприятия, различным финансовым системам 107, информационной системе 108 для клиентов, системе 109 управления человеческими ресурсами, системе 110 управления активами (имущественными объектами), системе 111 поддержки SOA предприятия, системе 112 управления сетью связи и сервисам 113 обмена сообщениями на предприятии. Система 115 IT предприятия может дополнительно содержать портал 103 для связи с Интернет 101 через межсетевой экран 102.
Конкретные примеры функциональных возможностей ядра INDE Core
Как показано на фиг.6А-С, в ядро INDE Core 55 включены различные функциональные возможности (представленные прямоугольниками), две из которых могут содержать сервисы сбора и обработки данных учета, а также анализ данных учета и сервисы. Благодаря модульности архитектуры в нее могут быть встроены различные функциональные возможности, такие как сервисы сбора и обработки данных учета, а также анализ данных учета и сервисы.
Подстанция INDE Substation
Подстанция INDE Substation 180 может содержать элементы, которые реально находятся на подстанции 170 в помещении управления подстанции на одном или нескольких серверах, расположенных вместе с электронным оборудованием и системами подстанции.
В табл.2 ниже перечислены и описаны некоторые элементы из группы элементов подстанции INDE Substation 180. Сервисы 171 защиты данных могут быть частью среды подстанции; в альтернативном варианте они могут быть интегрированы в группы элементов подстанции INDE Substation 180.
Как описано выше, различные элементы в интеллектуальной энергосистеме могут иметь дополнительные функциональные возможности, включая дополнительные возможности обработки/анализа данных и ресурсы базы данных. Использование этих дополнительных функциональных возможностей в различных элементах интеллектуальной энергосистемы позволяет реализовать распределенные архитектуры с централизованным управлением и администрированием приложений и работы сети связи. Из соображений функциональных возможностей, характеристик и масштабируемости интеллектуальная энергосистема, включающая от тысяч до десятков тысяч подстанций INDE Substations 180 и от десятков тысяч до миллионов сетевых устройств, может иметь распределенные обработку сигналов и данных, управление данными и технологическую связь.
Подстанция INDE Substation 180 может содержать один или несколько процессоров и одно или несколько запоминающих устройств (таких как для хранения неоперативных данных 181 подстанции и оперативных данных 182 подстанции). Неоперативные данные 181 и оперативные данные 182 подстанции могут быть ассоциированы с этой подстанцией и располагаться рядом с ней, например, непосредственно на подстанции INDE Substation 180. Подстанция INDE Substation 180 может дополнительно включать компоненты интеллектуальной энергосистемы, отвечающие за возможность наблюдать и определять состояние интеллектуальной энергосистемы на уровне подстанции. Компоненты подстанции INDE Substation 180 могут осуществлять три основные функции: сбор оперативных данных и сохранение их в распределенном хранилище оперативных данных; сбор неоперативных данных и сохранение их в базе данных предыстории; и локальная аналитическая обработка полученных данных в реальном времени (например, за доли секунды). Обработка может содержать цифровую обработку сигнала в виде форм сигналов напряжения и тока, обнаружение и классификацию, включая обработку потоков событий, и передачу результатов такой обработки данных локальным системам и устройствам, равно как и центру 116 оперативного управления. Связь между подстанцией INDE Substation 180 и другими устройствами может осуществлять по проводам, по радио или посредством сочетаний радио и проводной связи. Например, передача данных от подстанции INDE Substation 180 в центр 116 оперативного управления может происходить по проводам. Подстанция INDE Substation 180 может передавать данные, такие как оперативные/неоперативные данные или данные событий, в центр 116 оперативного управления. Устройство 190 маршрутизации может направлять передаваемые данные в одну из шин - шину 146 оперативных/неоперативных данных или шину 147 событий.
Здесь можно также осуществлять оптимизацию регулирования спроса для управления потерями распределения. Эта архитектура согласована с обсуждавшимися ранее принципами архитектуры распределенных приложений.
Например, данные соединений могут быть дублированы на подстанции 170 и в центре 116 оперативного управления, что позволяет подстанции 170 работать независимо, даже если сеть передачи данных в центр 116 оперативного управления окажется неработоспособной. Когда такая информация (о соединениях) хранится локально, аналитические операции подстанции можно осуществлять на месте, даже если линия связи с центром 116 оперативного управления не работает.
Аналогично, оперативные данные могут быть дублированы в центре 116 оперативного управления и на подстанции 170. Данные от датчиков и устройств, связанных с конкретной подстанцией, могут быть собраны и самые последние результаты измерений могут быть сохранены в указанном хранилище данных на подстанции. Структуры данных в хранилище оперативных данных могут быть одинаковыми, вследствие чего связи базы данных могут быть использованы для обеспечения бесперебойного доступа к данным, находящимся на подстанции, через объект оперативных данных, сохраняемых в центре управления. Это создает ряд преимуществ, включая устранение копирования данных и возможность осуществлять анализ данных подстанции, который более чувствителен к фактору времени, непосредственно на месте, не рассчитывая на наличие связи с аппаратурой за пределами подстанции. Анализ данных в центре 116 оперативного управления может быть менее чувствителен к фактору времени (поскольку центр 116 оперативного управления может обычно анализировать данные предыстории для выявления структур, что имеет в большей степени прогнозирующее значение, чем реактивное) и потому может позволить решать проблемы сети связи, если таковые возникают.
Наконец, данные предыстории могут быть сохранены локально на подстанции, а копия этих данных может быть сохранена в центре управления. Либо на объекте данных в хранилище данных центра 116 оперативного управления могут быть конфигурированы связи базы данных, обеспечивая доступ из центра оперативного управления к данным на индивидуальной подстанции. Анализ данных подстанции может быть произведен локально, на подстанции 170 с использованием местного хранилища данных. В частности, использование дополнительных интеллектуальных возможностей и возможностей хранения данных на подстанции позволяет этой подстанции самой анализировать данные и самой вносить коррективы в работу без команды из центра управления. В альтернативном варианте, анализ предыстории/собранных данных может быть также выполнен в центре 116 оперативного управления путем доступа к данным в локальном хранилище подстанции с использованием связей базы данных.
Устройство INDE Device
Понятие «устройство INDE Device 188» может обозначать самые разнообразные датчики в интеллектуальной энергосистеме, такие как различные распределенные сетевые устройства 189 (например, линейные датчики в линиях электропередач), приборы 163 учета (счетчики) на объектах клиентов и т.п. Устройство INDE Device 188 может представлять собой устройство, добавляемое в энергосистему с конкретными функциями, (например, интеллектуальные удаленные терминалы (RTU), имеющие специализированное программирование) или может быть уже существующим устройством в энергосистеме с дополнительными функциями (таким как существующие терминалы RTU для установки на вершине столба в открытой архитектуре, которые уже установлены на месте в энергосистеме и могут быть запрограммированы для создания интеллектуального линейного датчика или интеллектуального сетевого устройства). Устройство INDE Device 188 также включать один или несколько процессоров и одно или несколько запоминающих устройств.
Существующие сетевые устройства могут не быть открытыми с точки зрения программного обеспечения и могут оказаться неспособными поддерживать многие из современных сетевых или программных сервисов. Существующие сетевые устройства могли быть спроектированы для получения и сохранения данных с тем, чтобы затем выгружать их от случая к случаю в некоторые другие устройства, такие как портативный компьютер, или для передачи командных файлов по линии телефонной сети общего пользования удаленному главному компьютеру по требованию. Эти устройства могут не быть рассчитаны на работу в цифровой сетевой среде в реальном времени. В таких случаях данные от этих сетевых устройств могут быть получены на уровне подстанции 170 или в центре 116 оперативного управления в зависимости от того, как построена существующая сеть связи. В сетях приборов учета данные обычно получают от устройства сбора данных учета, поскольку сети приборов учета обычно закрыты и к этим приборам учета невозможно адресоваться непосредственно. По мере развития таких сетей приборы учета и другие сетевые устройства могут стать индивидуально адресуемыми, так что данные можно будет передавать прямо туда, где они нужны, причем совсем не обязательно в центр 116 управления сетью, а в любое место в энергосистеме.
Устройства, такие как индикаторы неисправных цепей, могут быть оснащены картами сетевых интерфейсов для радиосвязи с целью соединения по сетям радиосвязи с умеренной скоростью передачи данных (такой как 100 кбит/с). Эти устройства могут сообщать о статусе методом исключения и выполнять фиксированные предварительно запрограммированные функции. Уровень «интеллектуальности» многих сетевых устройств может быть повышен путем использования локальных интеллектуальных удаленных терминалов RTU. Вместо использования устанавливаемых на вершине столба терминалов RTU, представляющих собой устройства с фиксированными функциями для закрытой архитектуры, можно применять терминалы RTU в качестве устройств для открытой архитектуры, которые могут быть запрограммированы третьими сторонами и служить устройствами INDE Device 188 в опорной архитектуре INDE Reference Architecture. Кроме того, приборы учета (счетчики) на объектах клиентов можно использовать в качестве датчиков. Например, эти приборы учета могут измерять энергопотребление (т.е. сколько получено энергии, чтобы выставить счет) и могут измерять напряжение (для оптимизации соотношения между напряжением и реактивной мощностью (В/ВАР)).
На фиг.6А-С дополнительно показан объект 179 клиента, на котором могут быть один или несколько интеллектуальных приборов 163 учета, «домашний» дисплей 165, один или несколько датчиков 166 и один или несколько органов 167 управления. На практике, датчики 166 могут регистрировать данные в одном или нескольких устройствах на объекте 179 клиента. Например, датчик 166 может регистрировать данные в различных крупных электроприборах на объекте 179 клиента, таких как печь, водонагреватель, кондиционер воздуха и т.п. Данные от этих одного или нескольких датчиков 166 могут быть переданы интеллектуальному прибору 163 учета, который может упаковать эти данные для передачи в центр 116 оперативного управления по сети 160 управления энергоснабжающей компании. Домашний дисплей 165 может предоставить клиенту на объекте этого клиента устройство вывода, чтобы просматривать в реальном времени данные, собранные от интеллектуального прибора 163 учета и от одного или нескольких датчиков 166. Кроме того, с домашним дисплеем 165 может быть связано устройство ввода (такое как клавиатура), так что клиент может поддерживать связь с центром 116 оперативного управления. В одном из вариантов домашний дисплей 165 может содержать компьютер, находящийся на объекте клиента.
На объекте клиента могут находиться также органы 167 управления, которые могут управлять одним или несколькими устройствами, расположенными на этом объекте 179 клиента. Кроме того, различными электроприборами, расположенными на объекте 179 клиента, такими как нагреватель, кондиционер воздуха и т.п., можно управлять в соответствии с командами от центра 116 оперативного управления.
Как показано на фиг.6А-С, объект 179 клиента может поддерживать связь различными способами, такими как через Интернет 168, телефонную сеть 169 общего пользования (PSTN) или по выделенной линии (такой как коллектор 164). Данные от одного или нескольких объектов 179 клиентов могут быть переданы по любому из перечисленных каналов связи. Как показано на фиг.6А-С, один или несколько объектов 179 клиентов могут иметь сеть 178 интеллектуальных приборов учета (содержащую несколько интеллектуальных приборов 163 учета), передающую данные в коллектор 164 для пересылки в центр 116 оперативного управления по сети 160 управления энергоснабжающей компанией. Кроме того, различные источники распределенной генерации/хранения 162 энергии (такие как солнечные батареи и т.п.) могут передавать данные устройству 161 управления и контроля для передачи в центр 116 оперативного управления по сети 160 управления энергоснабжающей компанией.
Как обсуждается выше, устройства в энергосистеме вне центра 116 оперативного управления могут иметь возможности обработки и/или хранения данных. Совокупность таких устройств может включать подстанцию INDE Substation 180 и устройство INDE Device 188. Помимо того, что индивидуальные устройства в энергосистеме имеют дополнительные интеллектуальные возможности, эти индивидуальные устройства могут поддерживать связь с другими устройствами в энергосистеме, чтобы обмениваться информацией (включая данные датчиков и/или данные анализа (такие как данные событий)) с целью анализа состояния энергосистемы (такого как обнаружение неисправностей) и с целью изменения состояния энергосистемы (такого как устранение неисправностей). В частности, индивидуальные устройства могут использовать следующее: (1) интеллектуальные возможности (такие как способность обработки данных); (2) память (такую как обсуждавшиеся выше распределенные хранилища информации); и (3) связь (такую как использование одной или нескольких шин данных, обсуждавшихся выше). При таком подходе индивидуальные устройства в энергосистеме могут поддерживать связь и работать совместно одни с другими без какого-либо надзора со стороны центра 116 оперативного управления.
Например, архитектура INDE, может содержать устройство, измеряющее по меньшей мере один параметр питающей линии. Это устройство может иметь также процессор, который контролирует измеряемый параметр питающей линии и анализирует этот параметр, чтобы определить состояние питающей линии. Например, анализ измеряемого параметра может содержать сравнение этого измеряемого параметра с заданным порогом и/или может содержать анализ тенденции изменения параметра. Процедура измерения такого параметра может содержать измерение формы тока и/или напряжения в системе, а анализ может определять, указывает ли измеренная форма на неисправность в питающей линии. Рассматриваемое устройство может далее поддерживать связь с одной или несколькими подстанциями. Например, конкретная подстанция может поставлять энергию в конкретную питающую линию. Устройство может воспринимать состояние этой конкретной питающей линии и определять, имеется ли в рассматриваемой питающей линии неисправность. Устройство может поддерживать связь с соответствующей подстанцией. Эта подстанция может анализировать неисправность, обнаруженную устройством, и предпринимать корректирующие действия в зависимости от характера неисправности (такие как снижение мощности, отдаваемой в питающую линию). В примере, где устройство передает данные, указывающие на неисправность (на основе анализа форм напряжения и/или тока), подстанция может изменять мощность, отдаваемую в питающую линию, без какого-либо входного сигнала из центра 116 оперативного управления. Либо подстанция может соединить данные, указывающие на неисправность, с информацией от других датчиков, чтобы еще лучше уточнить анализ неисправности. Кроме того, подстанция может связаться с центром 116 оперативного управления, например с интеллектуальным приложением для устранения отключений и/или интеллектуальным приложением для устранения неисправностей. Таким образом, центр 116 оперативного управления может определить масштабы отключения (такие как число домов, затронутых неисправностью). При таком подходе устройство, определяющее состояние питающей линии, может работать во взаимодействии с подстанцией с целью устранения потенциальных неисправностей, требуя при этом или не требуя вмешательства центра 116 оперативного управления.
В качестве другого примера, линейный датчик, имеющий дополнительные интеллектуальные возможности, использующие обработку данных и/или память, может генерировать данные о состоянии энергосистемы на участке этой энергосистемы (таком как питающая линия). Эти данные о состоянии энергосистемы могут быть использованы совместно с системой 155 регулирования спроса в центре 116 оперативного управления. Эта система 155 регулирования спроса может управлять одним или несколькими устройствами на объектах клиентов, соединенных с рассматриваемой питающей линией, в ответ на данные о состоянии энергосистемы от линейного датчика. В частности, система 155 регулирования спроса может передать команду в систему 156 управления энергоснабжением и/или систему 157 управления распределением, чтобы уменьшить нагрузку в питающей линии путем отключения электроприборов на объектах клиентов, соединенных с этой питающей линией, если линейный датчик сообщит об отключении в питающей линии. При таком подходе, линейный датчик в сочетании с системой 155 регулирования спроса может автоматически сдвигать нагрузку с неисправной питающей линии и затем изолировать неисправность.
Еще в одном примере, одно или несколько реле в энергосистеме могут быть соединены с микропроцессорами. Эти реле могут поддерживать связь с другими устройствами и/или базами данных, резидентными в энергосистеме с целью определения неисправности и/или управления энергосистемой.
Приведенные выше примеры сосредоточились на использовании в энергоснабжающих компаниях. Однако описанная архитектура INDE Architecture может быть с равным успехом применена в других отраслях. Например, рассматриваемая архитектура INDE Architecture может быть специализируемой и применяемой в одной или нескольких отраслях, включая без ограничений транспортную отрасль (такую как сеть воздушных сообщений, железнодорожную сеть, сеть автомобильных перевозок, сеть автобусных сообщений и т.п.), телекоммуникационные сети и добыча энергоносителей (такие как сеть нефтяных скважин, сеть скважин для добычи природного газа и т.п.).
Хотя настоящее изобретение было продемонстрировано и рассмотрено на конкретных примерах, очевидно, что в базовые признаки изобретения могут быть внесены некоторые изменения и модификации в дополнение к рассмотренным выше. Кроме того, имеется большое разнообразие различных типов компьютерного программного обеспечения и оборудования, которые могут быть использованы при практической реализации изобретения, а также настоящее изобретение не ограничивается приведенными выше примерами. Настоящее изобретение было описано со ссылками на действия и символические представления операций, выполняемых одним или несколькими электронными устройствами. Поэтому, должно быть понятно, что такие действия и операции включают манипуляции над представляющими данные в структурированной форме электрическими сигналами, выполняемые процессорным модулем в электронном устройстве. Эти манипуляции трансформируют данные или сохраняют их в позициях памяти электронного устройства, что приводит к реконфигурированию или изменению работы этого электронного устройства способом, хорошо понятным специалистам в рассматриваемой области. Структуры данных, где сохраняются эти данные, представляют собой физические позиции в памяти, имеющие конкретные свойства, определяемые форматом данных. Хотя настоящее изобретение описано в приведенном выше контексте, это не означает ограничений, поскольку специалисты в рассматриваемой области должны понимать, что действия и операции, описанные выше, могут быть реализованы аппаратно. Соответственно, целью Заявителей является защита всех вариаций и модификаций в рамках действительного объема настоящего изобретения. Предполагается, что настоящее изобретение определено следующей Формулой изобретения, включая все эквиваленты.
| название | год | авторы | номер документа |
|---|---|---|---|
| СИСТЕМА И СПОСОБ ДЛЯ УПРАВЛЕНИЯ ЭЛЕКТРОЭНЕРГЕТИЧЕСКОЙ СИСТЕМОЙ | 2009 |
|
RU2518178C2 |
| ИНТЕЛЛЕКТУАЛЬНАЯ СЕТЬ | 2011 |
|
RU2546320C2 |
| СИСТЕМА ФИЛЬТРА КОМАНД МЕСТНОЙ ЭЛЕКТРОРАСПРЕДЕЛИТЕЛЬНОЙ СЕТИ | 2011 |
|
RU2554540C2 |
| ОБНАРУЖЕНИЕ И АНАЛИЗ ЗЛОУМЫШЛЕННОЙ АТАКИ | 2011 |
|
RU2583703C2 |
| УПРАВЛЕНИЕ ПЕРЕРЫВАМИ ПОДАЧИ ЭНЕРГИИ И СОСТОЯНИЕМ НЕИСПРАВНОСТИ ЭЛЕКТРОЭНЕРГЕТИЧЕСКОЙ СИСТЕМЫ | 2009 |
|
RU2525859C2 |
| РАСПРЕДЕЛЕННЫЙ ИНТЕЛЛЕКТ ЭЛЕКТРИЧЕСКОГО ТРАНСПОРТНОГО СРЕДСТВА | 2013 |
|
RU2633407C2 |
| Способ интеллектуального управления напряжением и реактивной мощностью энергосистемы | 2022 |
|
RU2793231C1 |
| Сетевой шлюз и способ передачи данных из первой сети во вторую сеть | 2021 |
|
RU2770458C1 |
| Система и способ контроля доступа к данным | 2021 |
|
RU2790338C1 |
| ИНТЕЛЛЕКТУАЛЬНЫЕ ЭЛЕКТРОННЫЕ УСТРОЙСТВА ДЛЯ СИСТЕМЫ АВТОМАТИЗАЦИИ ПОДСТАНЦИИ И СПОСОБ ЕЕ РАЗРАБОТКИ И УПРАВЛЕНИЯ | 2009 |
|
RU2504913C2 |
Изобретение относится к средствам управления промышленной сетью. Техническим результатом является повышение надежности и быстродействия при управлении энергосистемой. Центр управления энергосистемой, предназначенный для системы типа системы энергоснабжения, поддерживает связь с несколькими системами сбора и обработке данных учета и с несколькими терминальными системами. Центр управления энергосистемой содержит уровень шлюза и уровень ядра. Уровень шлюза включает несколько входных соединительных процедур для связи с каждой из нескольких систем-источников и несколько выходных соединительных процедур для связи с каждой из нескольких целевых систем. Уровень ядра содержит несколько адаптеров ядра, так что эти адаптеры ядра осуществляют взаимно-однозначную трансляцию связи от нескольких систем сбора и обработке данных учета, генерирующих команды, к нескольким терминальным системам. 16 з.п. ф-лы, 2 табл., 8 ил.
1. Центр управления энергосистемой для управления по меньшей мере частью энергосистемы и для связи с несколькими системами сбора и обработки данных учета и с несколькими терминальными системами, так что системы сбора и обработки данных учета генерируют команды, а терминальные системы поддерживают связь с одним или несколькими приборами учета, указанный центр управления энергосистемой содержит:
уровень шлюза, содержащий несколько входных соединительных процедур и несколько выходных соединительных процедур, так что совокупность нескольких входных соединительных процедур содержит по меньшей мере по одной отдельной входной соединительной процедуре для связи с каждой из нескольких систем-источников, передающих данные в центр управления энергосистемой, совокупность этих систем-источников содержит несколько систем сбора и обработки данных учета или несколько терминальных систем, передающих данные в центр управления энергосистемой, совокупность нескольких выходных соединительных процедур содержит по меньшей мере по одной отдельной выходной соединительной процедуре для связи с каждой из нескольких целевых систем, совокупность этих целевых систем содержит несколько систем сбора и обработки данных учета или несколько терминальных систем, принимающих данные из центра управления энергосистемой; и
уровень ядра, имеющий связь с уровнем шлюза, так что уровень ядра содержит несколько адаптеров ядра, эти адаптеры ядра осуществляют взаимно-однозначную трансляцию связи от нескольких систем-источников к нескольким целевым системам.
2. Центр управления энергосистемой по п.1, отличающийся тем, что совокупность систем-источников содержит несколько систем сбора и обработки данных учета; и
отличающийся тем, что совокупность целевых систем содержит несколько терминальных систем.
3. Центр управления энергосистемой по п.2, отличающийся тем, что данные, передаваемые в центр управления энергосистемы, содержат команду соединения/разъединения, переданную несколькими системами сбора и обработки данных учета.
4. Центр управления энергосистемой по п.2, отличающийся тем, что данные, передаваемые в центр управления энергосистемы, содержат команду чтения показаний приборов учета по запросу, переданную несколькими системами сбора и обработки данных учета.
5. Центр управления энергосистемой по п.2, отличающийся тем, что совокупность нескольких входных соединительных процедур содержит несколько отдельных входных соединительных процедур для связи с несколькими системами сбора и обработки данных учета; и
отличающийся тем, что совокупность нескольких выходных соединительных процедур содержит несколько отдельных выходных соединительных процедур для связи с несколькими терминальными системами.
6. Центр управления энергосистемой по п.5, отличающийся тем, что каждая из систем сбора и обработки данных учета ассоциирована с несколькими отдельными входными соединительными процедурами; и
отличающийся тем, что каждая из терминальных систем ассоциирована с несколькими отдельными выходными соединительными процедурами.
7. Центр управления энергосистемой по п.6, отличающийся тем, что несколько отдельных входных соединительных процедур, ассоциированных с каждой из систем сбора и обработки данных учета, содержат разные сетевые протоколы связи.
8. Центр управления энергосистемой по п.7, отличающийся тем, что указанные разные сетевые протоколы выбраны из группы, содержащей протокол передачи файлов (FTP), протокол интерфейса прикладных программ Java API для доступа к службам сообщений (JMS), и протокол передачи гипертекста (HTTP).
9. Центр управления энергосистемой по п.5, отличающийся тем, что совокупность нескольких входных соединительных процедур содержит по меньшей мере по одной отдельной входной соединительной процедуре для связи с каждой из нескольких терминальных систем; и
отличающийся тем, что совокупность нескольких выходных соединительных процедур содержит по меньшей мере по одной отдельной выходной соединительной процедуре для связи с каждой из нескольких систем сбора и обработки данных учета.
10. Центр управления энергосистемой по п.9, отличающийся тем, что каждая из терминальных систем ассоциирована с несколькими отдельными входными соединительными процедурами; и
отличающийся тем, что каждая из систем сбора и обработки данных учета ассоциирована с несколькими отдельными выходными соединительными процедурами.
11. Центр управления энергосистемой по п.1, отличающийся тем, что совокупность систем-источников содержит несколько терминальных систем; и
отличающийся тем, что совокупность целевых систем содержит несколько систем сбора и обработки данных учета.
12. Центр управления энергосистемой по п.11, отличающийся тем, что данные, передаваемые в центр управления энергосистемы, содержат периодически считываемые показания приборов учета, передаваемые несколькими терминальными системами.
13. Центр управления энергосистемой по п.11, отличающийся тем, что совокупность нескольких входных соединительных процедур содержит несколько отдельных входных соединительных процедур для связи с несколькими терминальными системами; и
отличающийся тем, что совокупность нескольких выходных соединительных процедур содержит несколько отдельных выходных соединительных процедур для связи с несколькими системами сбора и обработки данных учета.
14. Центр управления энергосистемой по п.1, дополнительно содержащий уровень интерфейса соединительных сервисов для сопряжения между уровнем шлюза и уровнем ядра, этот уровень интерфейса соединительных сервисов привлекает уровень ядра в ответ на прием сообщений и команд уровнем шлюза.
15. Центр управления энергосистемой по п.1, отличающийся тем, что адаптеры ядра дополнительно конфигурированы для взаимно-однозначной трансляции связи от каждой из нескольких систем-источников к каждой из нескольких целевых систем.
16. Центр управления энергосистемой по п.15, отличающийся тем, что системы-источники содержат несколько систем сбора и обработки данных учета;
отличающийся тем, что совокупность целевых систем содержит несколько терминальных систем; и
отличающийся тем, что адаптеры ядра конфигурированы для взаимно-однозначной трансляции связи от каждой из нескольких систем сбора и обработки данных учета к каждой из нескольких терминальных систем.
17. Центр управления энергосистемой по п.16, отличающийся тем, что адаптеры ядра дополнительно конфигурированы для взаимно-однозначной трансляции связи от каждой из нескольких терминальных систем к каждой из нескольких систем сбора и обработки данных учета.
| WO 2009136975 A2, 12.11.2009 | |||
| РЕАГИРУЮЩАЯ ПОДСТАНЦИЯ ЭЛЕКТРОЭНЕРГЕТИЧЕСКОЙ СИСТЕМЫ | 2004 |
|
RU2338311C2 |
| МЕСТНАЯ ГОТОВАЯ ПРЕПАРАТИВНАЯ ФОРМА, СОДЕРЖАЩАЯ КЕТОПРОФЕН, СТАБИЛИЗИРОВАННЫЙ СУЛИСОБЕНЗОНОМ | 2003 |
|
RU2328281C2 |
| WO 2009030027 A1, 12.03.2009 | |||
