O público obxectivo desta guía son as utilidades que planean despregar programas de resposta á demanda (DR) que utilizan OpenADR 2.0 para comunicar mensaxes relacionadas co evento DR entre a utilidade e as entidades descendentes e os fabricantes de equipos que facilitan ese intercambio de comunicación. Suponse que o lector ten unha comprensión conceptual básica tanto da resposta á demanda como de OpenADR 2.0 (referido simplemente como OpenADR a partir deste momento).

O OpenADR profile as especificacións definen claramente o comportamento esperado ao intercambiar información relacionada con eventos de DR, pero en OpenADR hai suficiente opción para que a implantación de servidores (VTN) na utilidade e clientes (VEN) nos sitios posteriores non sexa unha experiencia plug-n-play. As características de OpenADR, como os sinais de eventos, os formatos de informes e a orientación, deben especificarse programa por programa de DR.

Non existe un programa de DR estandarizado. Cada deseño do programa DR tende a ser único, axustándose aos requirimentos estruturais e regulamentarios da rexión xeográfica na que se desprega. Para cada programa DR hai numerosos escenarios de despregue posibles que inclúen unha variedade de actores.

A variabilidade nos deseños de programas de DR, os escenarios de implementación e as características de OpenADR son un inhibidor do despregamento expandido de DR e do uso de OpenADR. Esta variabilidade é na súa maior parte un reflexo da natureza fragmentada e complexa da rede intelixente.

As utilidades precisan exampficheiros de programas de DR típicos para que se poidan usar como modelos para as súas propias implementacións de programas de DR. Os fabricantes de equipos deben comprender os modelos de uso típicos do programa DR para que poidan validar a interoperabilidade como parte do proceso de desenvolvemento e non nunha base específica de implantación do programa DR. A intención desta guía é acadar estes dous obxectivos do seguinte xeito:

Defina un pequeno conxunto de modelos estándar de programas DR modelados segundo as características comúns dos programas DR máis populares implementados ata a data
Defina un pequeno conxunto de escenarios de despregamento modelados despois dos despregamentos do mundo real, con actores e roles claramente identificados

Defina recomendacións de mellores prácticas para as características de OpenADR específicas para cada un dos modelos do programa DR
Proporcione unha árbore de decisión que as utilidades poidan usar para identificar os modelos de programa de DR útiles e os escenarios de implantación en función das súas necesidades empresariais

O énfase desta guía estará en manter as cousas sinxelas proporcionando un pequeno conxunto de recomendacións claras que abordarán a maioría dos detalles necesarios para despregar un programa DR típico e permitir probas de interoperabilidade dos equipos despregados nos programas que utilizan as recomendacións deste. guía.

Referencias

OpenADR Profile Especificación e esquema – www.openadr.org

Termos e definicións

Neste documento úsanse os seguintes termos e definicións.

Resposta á demanda: Un mecanismo para xestionar a demanda de carga do cliente en resposta ás condicións de subministración, como prezos ou sinais de dispoñibilidade

Festa Agregadora - Este é un grupo que agrupa varios recursos e os presenta ao Partido do Programa DR como un único Recurso nos seus Programas DR.
Infraestrutura intermedia agregadora - Esta é a infraestrutura, separada da infraestrutura do lado da demanda, que é utilizada polo grupo intermediario agregador para interactuar tanto cos recursos como coas entidades do lado da rede.
Acordo: Un acordo contractual entre as partes que xogan un papel nun programa DR que describe as responsabilidades e a compensación

Activo - Un tipo de recurso que representa unha colección específica de cargas físicas. Os recursos poden estar compostos por activos e un activo pode ser un recurso, pero os activos non se poden descompoñer en varios activos ou recursos.
Asociado: Proporcionar unha asociación programática entre dúas entidades, mediante a configuración dun dispositivo de base de datos. Por exemplo, recursos asociados a un VEN
Liñas de base: O consumo (demanda) de enerxía calculado ou medido por unha peza de equipo ou un sitio antes do evento determinado por medio de enquisas, inspeccións e / ou medicións no lugar.

BMS - Este é o sistema de xestión de edificios que se pode usar para controlar os recursos. Ás veces chámase sistema de xestión de enerxía.
Recurso composto - Este é un tipo especial de recurso que é unha agregación de múltiples activos físicos que teñen cada un os seus propios medios de control de carga.
Incentivo ao cliente: Un incentivo proporcionado ao propietario / agregador de recursos do lado da demanda para a participación nun programa DR.

Demanda infraestrutura lateral - Esta é a infraestrutura que alberga os recursos inscritos nos programas DR
Lóxica DR: Algoritmos ou lóxica que converten os sinais DR en control de carga accionable. Teña en conta que DR Logic pode implementarse en moitos lugares diferentes e nalgún caso distribuírse entre varios subsistemas.
Festa do Programa DR - esta é a entidade responsable da infraestrutura da rede e, ademais, da xestión dos programas DR empregados para mitigar os problemas da rede. Normalmente trátase dunha utilidade ou ISO.

Inscrito: O propietario / agregador de recursos do lado da demanda elixe participar nun programa DR e pode proporcionar información sobre os recursos específicos que poden estar dirixidos a eventos DR
Período activo do evento: O é o período de tempo durante o cal se produce un cambio na carga profile está sendo solicitada como parte dun evento de DR
Restricións de eventos: Os períodos de tempo nos que o cliente pode esperar recibir eventos e restricións relacionadas, como non haber eventos os fins de semana ou días consecutivos

Días de eventos: Un día no que se produce un evento DR. A maioría dos programas teñen limitacións en canto ao número de días de evento permitidos nun determinado período de calendario
Descritor de eventos: Parte do obxecto de evento OpenADR que describe metadatos sobre o evento, como o nome do programa e a prioridade do evento
Duración do evento: A duración do evento. A maioría dos programas definen as restricións á duración dun evento, así como ás horas do día durante as que pode ocorrer o evento

Sinais de eventos: A información factible contida nun evento como o prezo da electricidade ou niveis específicos de carga solicitada que normalmente desencadean algún comportamento de carga previamente programado por parte do destinatario do evento. A definición do programa DR debería especificar os tipos de sinais de eventos empregados
Segmentación de eventos: A carga que elimina os recursos que son o destinatario previsto para o evento DR. Pode ser unha área xeográfica, unha clase particular de dispositivos, un identificador de grupo, ID de recurso ou outro identificador. A definición do programa DR debería especificar como se dirixirán os recursos específicos.
Eventos: Un evento é unha notificación da utilidade para esixir recursos secundarios que solicitan o lanzamento de carga a partir dunha hora específica, durante unha duración determinada, e pode incluír información de orientación designando recursos específicos que deberían participar no evento.

Facilitador de infraestruturas intermediarias - Esta é a infraestrutura, separada da infraestrutura do lado da demanda, que é utilizada polo Partido Intermediario facilitador para interactuar tanto cos recursos como coas entidades do lado da rede.
Facilitador: Un terceiro que xestiona parte ou a totalidade da execución do programa DR en nome da utilidade
Infraestrutura de rede - Esta é a infraestrutura propiedade ou xestionada polas partes do programa DR. Esta infraestrutura inclúe a implementación do OpenADR VTN que se usa para enviar sinais DR aos recursos inscritos nos programas DR

Partido Intermediario - Esta é unha festa que normalmente traballa en nome da Resource Party para facilitar a súa participación nos programas DR.
Control de carga – esta é a infraestrutura relacionada cun recurso que se encarga de controlar realmente o recurso e de producir unha carga específicafile.
Carga Profile Obxectivo: Esta motivación detrás de desenvolver un programa DR e emitir eventos. Como o desexo de afeitar picos de carga.

Notificación: Un período de tempo anterior á hora de inicio dun evento onde se notifica ao propietario do recurso do lado da demanda un evento pendente
Opt Comportamento: A resposta esperada do propietario do recurso ao lado da demanda ao recibir un evento. Esta resposta pode ter a forma de indicación de OptIn ou OptOut se o recurso participará ou non no evento
Opt Respostas: Se un programa específico debe requirir unha resposta dos recursos do lado da demanda en resposta a un evento e cales son normalmente esas respostas.

Opción Servizos: Programacións comunicadas a través de OpenADR para indicar cambios temporais na dispoñibilidade de recursos para participar en eventos.
Requisito previo: Criterios que deben cumprirse para que un propietario de recursos do lado da demanda poida inscribirse nun programa DR. Isto pode incluír a dispoñibilidade de reunións por intervalos ou algunha capacidade mínima de carga
Controladores primarios: A principal motivación da utilidade para crear o programa DR e emitir eventos. Como "Redución máxima da demanda e adecuación dos recursos"

Programas - Estes son os programas DR nos que están inscritos os recursos.
Descrición do programa: Unha descrición narrativa de como funciona un programa. Parte dos modelos do programa DR definidos neste documento
Cadro de tempo do programa: A época do ano ou as estacións durante un programa DR normalmente está activa

Deseño de taxas: As modificacións específicas da estrutura tarifaria ou os incentivos pagados para motivar aos propietarios de recursos do lado da demanda a participar no programa
Servizos de rexistro: Servizo utilizado polo protocolo OpenADR para establecer a interoperabilidade básica entre un VTN e un VEN e validar que o VEN está asociado á conta de clientes de servizos públicos.
Servizos de Informes: Servizo utilizado polo OpenADR para permitir aos VEN proporcionar informes aos VEN. O programa DR debe especificar os requisitos de informes para o programa.

Festa de recursos - Esta é a parte propietaria do lado da demanda Recursos que poden estar inscritos en programas DR
Recurso – Esta é a entidade que está inscrita nos programas de DR e é capaz de realizar algún tipo de cambio na súa carga profesionalfile en resposta á recepción dun sinal DR dun VTN.
Cliente obxectivo: O profile de recursos do lado da demanda que poden inscribirse nun programa específico de DR como residencial, industrial ou quizais baseado no nivel de consumo eléctrico.

Cargas obxectivo: Os recursos do lado da demanda cuxa carga debería modificarse ao recibir un
VEN - Este é o OpenADR Virtual End Node que se usa para interactuar coa VTN.
VTN - Este é o nodo superior virtual OpenADR que se usa para interactuar cos recursos inscritos nos programas DR.

Abreviaturas

BMS: Sistema de xestión de edificios
C&I: Comercial e industrial
Comm: Comunicacións entre dúas entidades
DR: Demanda de resposta
EMS: Sistema de xestión da enerxía
OpenADR: Resposta aberta á demanda automatizada
Programas: Referencia a un programa (s) de resposta á demanda
VEN: Nodo final virtual
VTN: Nodo superior virtual

Tipos de programas de resposta á demanda

Este documento contén modelos para os programas DR que se amosan a continuación.

1. Prezos máximos críticos: Estrutura de prezos e / ou prezos deseñada para fomentar o consumo reducido durante períodos de prezos elevados no mercado por xunto ou continxencias do sistema impoñendo unha taxa ou prezo elevado predeterminado durante un número limitado de días ou horas.

2. Programa de licitación de capacidade: Un programa que permite que un recurso de demanda nos mercados de venda polo miúdo e por xunto ofrece reducións de carga a un prezo ou identifica a cantidade de carga que está disposto a reducir a un prezo específico.

3. Programa de termostato residencial / control de carga directa: Unha actividade de resposta á demanda pola que o patrocinador do programa controla remotamente os equipos eléctricos dun cliente (por exemplo, o aire acondicionado) nun breve prazo. Estes programas ofrécense principalmente a clientes residenciais ou comerciais pequenos.

4. Programa de envío rápido / servizos auxiliares de DR: un programa de resposta á demanda que ofrece pagos de incentivos aos clientes para a resposta á carga durante un evento de resposta á demanda de emerxencia. Unha condición anormal do sistema (por exemplo,ample, restricións do sistema e limitacións de capacidade local) que requiren accións manuales automáticas ou inmediatas para previr ou limitar o fallo das instalacións de transmisión ou do abastecemento de xeración que poidan afectar negativamente á fiabilidade do sistema eléctrico a granel. Este tipo de programas ás veces pode denominarse "Servizos auxiliares".

5. Programa DR de vehículos eléctricos (EV): Unha actividade de resposta á demanda pola que se modifica o custo de cargar vehículos eléctricos para facer que os consumidores cambien os patróns de consumo.

6. Programa DR de Recursos Enerxéticos Distribuídos (DER): Unha actividade de resposta á demanda utilizada para suavizar a integración dos recursos enerxéticos distribuídos na rede intelixente.

Escenarios de implantación

A forma en que se desprega un programa DR é algo independente das características do propio programa DR. Os seguintes diagramas mostran unha variedade de formas en que se podería despregar un programa DR. A seguinte sección ofrece unha referencia cruzada entre os escenarios de implementación e os programas DR cos que é máis probable que se utilicen.

Os diagramas desta sección mostran as relacións entre as entidades nos distintos escenarios.

Directo 1

Este é un escenario sinxelo no que existe unha relación directa entre o Partido do programa DR e o Partido do recurso. A parte do recurso é responsable de rexistrar os seus propios recursos nos programas de DR e a infraestrutura de rede interactúa directamente cos recursos a través dun VEN que reside dentro da infraestrutura do lado da demanda. Ademais, o VEN é propiedade do Resource Party e está separado dos Resources e dos seus controladores. Cando o VEN recibe un sinal DR, normalmente non implementa ningunha lóxica de control de carga, senón que simplemente envía os sinais aos controladores de carga que toman a acción adecuada. ExampOs ficheiros deste escenario incluirían edificios C&I que poden instalar unha pasarela que conteña un VEN OpenADR e cando se recibe un sinal por esa pasarela, simplemente o traduce noutro protocolo e envía aos propios controladores de carga.

Directo 2

Isto é moi semellante ao escenario Direct 1. A principal diferenza está en como se crea o VEN e se facilitan as interaccións co VTN. O VEN está instanciado nunha entidade como un BMS centralizado que pode implementar a lóxica DR e interactuar con Compound Resource e os seus moitos controladores de carga diferentes desde unha localización máis centralizada. Exampos inclúen grandes edificios cun BMS que controlan moitas cargas diferentes nun edificio (por exemplo, iluminación, climatización, procesos industriais, etc.) para campusos que poden ter múltiples instalacións cun sistema de control centralizado.

Directo 3

Este escenario é moi semellante ao escenario Direct 1. A principal diferenza é que o VEN está instanciado directamente no recurso e no seu controlador de carga. Neste caso, os sinais DR son enviados directamente ao recurso e ao seu controlador de carga. O chamado escenario de "prezos aos dispositivos" entra nesta categoría. ExampOs ficheiros incluirían calquera tipo de controlador de carga, como HVAC (é dicir, termostato) que teña un VEN integrado que sexa capaz de interactuar directamente coas entidades do lado da rede VTN.

Directo 4

Esta é unha combinación de tipos de escenarios Direct 1 e Direct 2. A principal diferenza é que varios VEN están asociados a un único recurso composto que está composto por varios activos cos seus propios controladores de carga. Cada un dos controladores de carga que compoñen o recurso composto pode estar asociado a un VEN diferente. Teña en conta que todos os VEN estarían baixo o control da mesma parte do recurso que posúe o recurso composto. Este escenario existe para facilitar as infraestruturas do lado da demanda que teñen recursos compostos, pero non teñen un BMS centralizado como o escenario Direct 2. ExampOs ficheiros poden incluír edificios con controladores de carga diferentes en cada piso, pero sen BMS centralizado, ou camputiliza con diferentes controladores en cada edificio, pero non campcontrolador amplo dos Estados Unidos. Dado que desde a perspectiva do Partido do Programa DR só hai un único recurso inscrito no programa cando quere enviar un sinal DR ao recurso, pode simplemente enviar os mesmos sinais a cada un dos VEN designados que se asociaron co recurso.

Facilitador 1

Neste escenario hai un intermediario que facilita as interaccións entre o Partido do Programa DR e os Recursos. Normalmente, o Intermediario traballa en nome do Resource Party para axudalos a xestionar os seus Recursos. As partes de recursos teñen relacións directas coa parte do programa de DR e inscriben os seus propios recursos nos programas de DR. Así o Partido do Programa DR views cada parte do recurso como un recurso separado e pode interactuar con eles individualmente. O papel da parte intermediaria é actuar como intermediario para todas as interaccións relacionadas con OpenADR, polo que o VEN instátase dentro da infraestrutura intermediaria do facilitador. Tal infraestrutura adoita ser bases na nube e ofrécese ás partes do recurso como software como servizo (SaaS). Cando o sinal DR é recibido polo VEN do Facilitador pode ter lugar unha serie de accións diferentes, incluíndo reenviar o sinal DR ao recurso apropiado e posiblemente implementar algún tipo de lóxica DR e enviar comandos de control de carga ao controlador de carga de cada recurso. ExampOs ficheiros deste escenario inclúen:

Provedores que xestionan as instalacións de grandes cadeas comerciais como grandes venda polo miúdo.
Intermediarios de control industrial.
Empresas de servizos enerxéticos (ESCO)
Sistemas de xestión de dispositivos e dispositivos baseados na nube, como os provedores emerxentes de termostatos de comunicación intelixente.

Agregador 1

Este escenario é similar ao escenario do facilitador. A principal diferenza é que o Partido Agregador ten a relación co Partido do Programa DR fronte ás Partes de Recurso. A Aggregator Party agrega varios activos de clientes nun único recurso que inscribe nos programas DR. O Partido do Programa DR non ten visibilidade sobre os activos que xestiona o Agregador. Do mesmo xeito que co facilitador, o agregador ten a súa propia infraestrutura onde se instancia o VEN. A diferenza é que cando se recibe un sinal DR fai referencia a un único recurso e o Agregador implementa algún tipo de lóxica DR sobre todos os activos da súa carteira para acadar os obxectivos especificados no sinal DR.

Escenario de implantación e asignación de programas DR

A táboa seguinte ofrece os escenarios de despregue máis comúns para un programa DR específico.

	Escenario de implantación
Modelo DR	Directo 1, 2, 3, 4	Facilitador 1	Agregador 1
Programa CPP	∆	∆
Programa de licitación de capacidade			∆
Termostato residencial Programa		∆
Envío rápido de DR			∆
Programa DR de vehículos eléctricos (EV)	∆	∆
Programa DR de Recursos Enerxéticos Distribuídos (DER)	∆	∆

Seleccionando un modelo de programa DR

A continuación móstranse un conxunto de preguntas que son relevantes para calquera utilidade a piques de implementar un novo programa DR. Non se pretende que sexa exhaustivo, senón que representa algúns dos temas máis pertinentes. A intención destas preguntas é axudar a guiar as utilidades cara a un conxunto adecuado de modelos de programa DR.

P: Por que queres facer DR? Que condición de rede ou problema operativo estás a tratar de mitigar con DR?

Esta é, de lonxe, a pregunta máis importante e constitúe a base para os requisitos e obxectivos xerais para o que se supón que o programa de DR debe acadar. A resposta a esta pregunta define como se carga a demanda profile suponse que está configurado polo programa DR. Todos os demais requisitos derivan da resposta a esta pregunta.

¿Estás intentando afeitar picos?
¿Queres encher a barriga do pato?
¿Intenta cubrir o prezo spot da electricidade?
¿Preocúpalle a fiabilidade da rede?
¿Estás intentando preservar os activos da rede?
Etc. etc.

A táboa seguinte ofrece un contexto adicional para as motivacións detrás de querer desenvolver un programa DR

Fiabilidade e seguridade da rede	Frecuencia e Voltage Estabilidade
	Adecuación de recursos
	Capacidade máxima
	Ramping
	Contingencia
Adquisición de enerxía	Prezos Spot Market
Adquisición de enerxía	Arbitraxe de prezos
Xestión de activos	Prevención de danos
	Redución do mantemento
	Extensión de por vida
Xestión da capacidade	Beneficios económicos
Xestión da capacidade	Xestión de emerxencias
Ambiental	Negavatio
Ambiental	Enerxía Limpa

P: ¿Xa existe algún programa ou tarifa DR para este programa?

Moitas veces as regras do programa explícanse explícitamente nunha tarifa.

P: A que segmento de mercado lateral da demanda está dirixido con este programa?

Isto pode axudar a determinar a orientación dos recursos no evento e o tipo de sinal.

Residencial
C&I grande
C&I pequeno
Agricultura
Xestión da auga
Vehículos eléctricos
Etc, etc, etc

P: ¿Está intentando orientar tipos específicos de cargas?

Termostatos
Vehículos eléctricos
Bombas de AG
etc.

P: Cal é o seu modelo de implantación?

A resposta a esta pregunta pode influír na definición dos recursos dentro do programa e determinar como se orientan eses recursos dentro dos eventos.

Directo aos clientes
A través de intermediarios como agregadores ou facilitadores
Cliente responsable de adquirir e despregar o seu propio equipo VEN?
etc.

P: En que nivel de especificidade quere interactuar coas cargas do lado da demanda?

Esta pregunta está algo relacionada co modelo de implementación e determina como se definen e orientan os recursos do programa. É unha das preguntas máis importantes e posiblemente complexas.

Interactúa con cada recurso individual
Interactúa a través dun facilitador ou agregador sen especificar os recursos que hai detrás
Interactúa a través dun facilitador ou agregador E especifica que recursos detrás deles deben enviarse
Use a localización como atributo para especificar recursos
Use algún tipo de mecanismo de agrupamento definido por utilidade para especificar recursos
Oriente a activos individuais como termostatos
Interactúa sen recursos e transmite eventos DR
etc.

P: Que patrón de interacción queres empregar para influír na carga dos teus clientesfiles?

Esta pregunta determina o tipo de sinais DR que se enviarán aos participantes nun programa.

Incentivos (por exemplo, prezos dinámicos)
Despachos de carga (por exemplo, servizos auxiliares)
Control directo de carga
Sinal de evento xenérico
etc.

P: Cales son os atributos xerais de programación de recursos do programa?

Datas e horas en que se poden convocar eventos
Frecuencia dos acontecementos
Duración dos eventos
Latencias permitidas para a propagación de eventos
etc.

P: Como se determina a dispoñibilidade de recursos no programa?

Por regras estritas do programa
Como parte dalgún proceso de candidatura ou licitación feito polo recurso
Permitir a opción In / Out?
etc.

P: Que tipo de visibilidade precisa para o rendemento do recurso?

Esta é unha pregunta moi ampla e determina que tipo de información se retroalimenta dos recursos do programa DR. En xeral, isto determina o tipo de informes que se requiren.

En liña / fóra de liña
Uso (actual e / ou histórico)
Potencial de resposta de carga
Dispoñibilidade de carga
Estado de carga / activo (actual e / ou histórico)
Etc, etc. etc.

Modelos do programa de resposta á demanda

Programa de prezos máximos críticos (CPP)

Características do programa CPP DR


Carga Profile Obxectivo	-Redución máxima da demanda
Controladores primarios	-Redución dos gastos de capital e redución dos custos enerxéticos
Descrición do programa	Cando os servizos públicos observan ou anticipan altos prezos do mercado por xunto ou condicións de emerxencia do sistema eléctrico, poden chamar a eventos críticos durante un período de tempo especificado (por exemplo, de 3:6 a XNUMX:XNUMX nun día quente na semana de verán), o prezo da electricidade nestes períodos de tempo é substancialmente levantado.
Incentivo ao cliente	Aos clientes pódeselles ofrecer prezos descontados da enerxía durante as horas non punta como incentivo para participar no programa.
Deseño de taxas	O CPP é un programa de prezos con taxas que aumentan durante os picos críticos do consumo de enerxía. Normalmente as taxas de CPP son un sumador ou multiplicador a tarifas planas, por niveis ou TOU base.
Cliente obxectivo	-Residencial ou C&I
Carga obxectivo	-Calquera
Requisito previo	-O cliente debe ter medición de intervalos -Os clientes de C&I poden ter que cumprir un criterio de demanda
Cadro de tempo do programa	-Típicamente abarca os meses do ano onde se produce o consumo máximo de enerxía, aínda que pode ser durante todo o ano nalgúns casos.
Restricións de eventos	-Tipicamente de luns a venres, excluídos os festivos, con eventos consecutivos normalmente permitidos
Días de eventos	-Típicamente de 9 a 15 por ano
Duración do evento	-Tipicamente durante un período de tempo fixo para todos os eventos que van de 4 a 6 horas durante os momentos de maior consumo do día.
Notificación	-Típicamente o día por diante
Opt Comportamento	-Tipicamente os clientes non están obrigados a participar en eventos
Certificación Eventos	-Tipicamente ningunha

Características de OpenADR para programas CPP

Sinais de eventos	–Un sinal SIMPLE cos niveis 1 a 3 mapeados ao impacto no prezo do evento CPP. Se un programa CPP ten un único compoñente de prezos, debería mapearse ao nivel 1. Para os programas CPP con varios compoñentes de prezos, o compoñente de prezo máis pequeno debería mapearse ao nivel 1, cos outros compoñentes de prezo mapeados aos niveis 2 e 3 en grao crecente. de impacto no prezo. -Se o despregamento admite B profile VEN, ademais do sinal SIMPLE, pódese incluír un sinal de ELECTRICITY_PRICE na carga útil cun tipo de prezo Relativo, prezoAbsoluto ou prezoMultiplicador segundo a natureza do programa. Vexa o anexo A para o exemploamples.
Opt Respostas	-VTNs que envían eventos debería definir o elemento oadrResponseRequired a "sempre", requirindo que o VEN responda cun optIn ou optOut -Como a participación nun programa CPP é un exercicio de "mellor esforzo", non hai un significado formal de optIn ou optOut máis alá dunha indicación de dispoñibilidade de cortesía de intención de participar. Recomendámolo Os VEN responden con optIn a menos que houbese algunha acción de anulación específica tomada polo cliente. -A carga útil de oadrCreateOpt normalmente non se usaría para cualificar os recursos que participan en eventos.
Descritor de eventos	-O evento a prioridade debe establecerse en 1 a non ser que as regras do programa ou a configuración de VTN especifiquen o contrario –Normalmente non se usan eventos de proba con programas CPP. Non obstante, se se permiten, o elemento testEvent debería establecerse en "true" para indicar o evento da proba. Se se precisa información adicional parametrizada neste elemento, pode seguir "verdadeiro" separado por un espazo con esta información adicional.
Período activo do evento	– eiRampArriba, eiRecovery, os elementos de tolerancia normalmente non se usan
Liñas de base	–As liñas de base normalmente non se inclúen na carga útil do evento
Segmentación de eventos	-Os programas CPP normalmente non diferencian os recursos para un determinado cliente. A orientación normalmente especifica o venID, indicando que deberían participar todos os recursos asociados ao VEN, ou unha lista de todos os ID de recursos asociado a VEN.
Servizos de Informes	–Normalmente non se emprega o informe de telemetría xa que non é absolutamente necesario para os programas CPP. Consulte o anexo B para o examparquivos de informes de pilotos de servizos públicos que poden ser aplicables a este tipo de programas.

Opción Servizos	–Uso do servizo Opt para comunicar horarios de dispoñibilidade temporal normalmente non se usaría como parte dun programa CPP. Non obstante, algúns despregamentos poderían usar este servizo para preservar os días de evento dispoñibles para os clientes que indican falta de dispoñibilidade.
Servizos de rexistro	Intervalos de votación solicitado pola VTN para os programas típicos de CPP con antelación Non é necesario que sexan máis frecuentes que unha vez por hora. Non obstante, o uso de sondaxes para a detección de latidos do corazón pode requirir sondaxes máis frecuentes.

Programa de licitación de capacidade

Características do programa DR de licitación de capacidade

Carga Profile Obxectivo	-Redución máxima da demanda e adecuación dos recursos
Controladores primarios	-Redución dos gastos de capital e redución dos custos enerxéticos
Descrición do programa	O programa de ofertas de capacidade é empregado polas ISO / utilidades para obter capacidade de carga previamente comprometida de agregadores ou clientes autoagregados. Esta capacidade de vertido de carga comprometida é utilizada polas ISO / utilidades cando observan ou anticipan altos prezos do mercado por xunto, condicións de emerxencia do sistema de enerxía ou como parte da utilización normal dos recursos enerxéticos chamando a eventos DR durante un período de tempo especificado. Teña en conta que cada agregador é normalmente responsable de deseñar o seu propio programa de resposta á demanda, así como a adquisición de clientes e a notificación de eventos para cumprir os compromisos de capacidade adquiridos como parte deste programa.
Incentivo ao cliente	Os agregadores / clientes reciben dous tipos de incentivos. En primeiro lugar, reciben un pago por capacidade por manter unha cantidade específica de capacidade de carga dispoñible para eventos DR durante unha futura ventá temporal. En segundo lugar, se se convoca un evento durante a futura ventá temporal, pódese facer un pagamento de enerxía pola carga vertida durante a duración do evento.
Deseño de taxas	Os participantes no programa fan unha oferta de "nomeamento de capacidade" indicando a capacidade de carga que están dispostos a manter dispoñible durante unha futura ventá temporal. A oferta tamén pode incluír o incentivo que o agregador / cliente está disposto a aceptar para unha carga derramada por baixo do valor inicial. Nos mercados de servizos públicos o compromiso de capacidade adoita ser para o próximo mes natural, aínda que se utilizan marcos de tempo moito máis longos nos mercados ISO. Como parte do nomeamento de capacidade, o cliente pode elixir entre unha serie de características, incluíndo o día antes ou o día de notificación e a xanela de duración do evento (como 1-4 horas, 2-6 horas, ...). O cliente prégase un pago de capacidade por este compromiso previa aínda que non haxa eventos convocados durante a xanela de tempo. Se se chama un evento durante a ventá de tempo, o cliente pode recibir un pagamento enerxético pola nave de carga en relación a unha liña de base, con todo pódense aplicar sancións se se entrega menos da capacidade de nave de carga comprometida no momento da convocatoria do evento.
Cliente obxectivo	-Agregadores e clientes de C&I autoagregados
Cargas obxectivo	- Calquera

Requisito previo	-O cliente debe ter medición de intervalos -Os clientes de C&I poden ter que cumprir un criterio de demanda ou oferta
Cadro de tempo do programa	-En calquera momento
Restricións de eventos	-Tipicamente de luns a venres, excluídos os festivos, con eventos consecutivos normalmente permitidos
Días de eventos	-Típicamente un máximo de 30 horas ao mes
Duración do evento	-Tipicamente durante unha ventá de tempo fixa para todos os eventos durante os momentos de maior consumo de enerxía do día.). A duración do evento varía segundo o compromiso da capacidade do cliente con preferencias que van de 1 a 8 horas ou segundo o especificado no deseño do programa
Notificación	-Día con antelación ou día dependendo das preferencias de compromiso da capacidade do cliente ou do deseño do programa
Opt Comportamento	-Normalmente, os clientes optarían por participar en eventos dado que, xa que teñen unha capacidade comprimida previamente.
Certificación Eventos	-Tipicamente dous ao ano (proba)

Características de OpenADR para programas de licitación de capacidade

Sinais de eventos	–Un sinal sinxelo cos niveis 1 a 3 mapeados á cantidade de carga vertida. Se o programa só admite un único nivel de descarga de carga, debería mapearse ao nivel 1. Para os programas con varios niveis de carga derramada, o menor cambio do funcionamento normal debería mapearse ao nivel 1, cos valores de liberación de carga asignados a niveis 2 e 3 en grao crecente de vertedura de carga. -Se o despregamento admite B profile VEN, ademais do sinal SIMPLE, pódese incluír un sinal BID_LOAD e / ou BID_PRICE na carga útil con tipos de sinal de consigna e prezo, e unidades de powerReal e currencyPerKW respectivamente. O BID_LOAD reflectiría a carga solicitada acumulada ata o importe da capacidade ofertada polo agregador / cliente e o BID_PRICE reflectiría a oferta incentivada polo agregador / cliente. Vexa o anexo A para o exemploamples.
Opt Respostas	-VTNs que envían eventos debería definir o elemento oadrResponseRequired a "sempre", requirindo que o VEN responda cun optIn ou optOut -Como agregadores / clientes teñen capacidade comprometida previamente Os VEN deben responder con optIn. Pódese enviar unha exclusión en resposta ao evento, pero esta é unha indicación de dispoñibilidade informal, non unha exclusión formal do evento. -O normalmente non se usaría a carga útil de oadrCreateOpt para cualificar os recursos que participan en eventos como normalmente a carga é unha única entidade agregada.
Descritor de eventos	-O evento a prioridade debe establecerse en 1 a non ser que as regras do programa ou a configuración de VTN especifiquen o contrario –Pódense usar eventos de proba con programas de licitación de capacidade. Se se permiten, o elemento testEvent debería establecerse en "true" para indicar o evento da proba. Se se precisa información adicional parametrizada neste elemento, pode seguir "verdadeiro" separado por un espazo con esta información adicional.
Período activo do evento	– eiRampArriba, eiRecovery, os elementos de tolerancia normalmente non se usan
Liñas de base	–As liñas de base normalmente non se inclúen na carga útil do evento xa que estes datos normalmente non están dispoñibles no momento en que se inicia o evento. Non obstante, tanto as utilidades como os agregadores/clientes faríano view a inclusión de información de referencia nos eventos como útil.
Segmentación de eventos	-Os programas de oferta de capacidade normalmente non diferencian os recursos para un determinado cliente. A orientación normalmente especifica o venID, indicando que deberían participar todos os recursos asociados ao VEN, ou inclúe un ID de recurso representativo da carga agregada asociado a VEN.
Servizos de Informes	Os programas de oferta de capacidade ISO normalmente requiren informes TELEMETRY_USAGE con puntos de datos powerReal. Ver exampno anexo A. Normalmente non se requiren informes de telemetría para a utilidade Capacity Bidding. Teña en conta que os informes de telemetría requiren B profile VENs. Consulte o anexo B para o examparquivos de informes de pilotos de servizos públicos que poden ser aplicables a este tipo de programas.
Opción Servizos	–Uso do servizo Opt para comunicar horarios de dispoñibilidade temporal normalmente non se usaría como parte dun programa de ofertas de capacidade xa que os clientes comprometeron previamente a súa dispoñibilidade. Non obstante, este servizo pode ser útil como un xeito informal para que os participantes indiquen a falta de dispoñibilidade por motivos atenuantes como o fallo do equipo.
Servizos de rexistro	Intervalos de votación solicitado pola VTN para programas típicos de día con antelación Non é necesario que sexan máis frecuentes que unha vez por hora. Non obstante, o uso de sondaxes para a detección de latidos do corazón ou programas de día pode requirir sondaxes máis frecuentes.

Programa de termostatos residenciais

Este programa é representativo do Control de carga directa (DLC), onde o sinal de resposta á demanda modifica directamente o comportamento dos recursos de liberación de carga, sen que haxa unha capa de abstracción entre a recepción do sinal e a acción específica de eliminación de carga.

Características do programa de termostato residencial DR

Carga Profile Obxectivo	-Redución máxima da demanda
Controladores primarios	-Redución dos gastos de capital e redución dos custos enerxéticos
Descrición do programa	-Cando as empresas de servizos públicos observan ou anticipan altos prezos do mercado por xunto ou as condicións de emerxencia do sistema de enerxía, poden iniciar un evento que modifique o comportamento do termóstato de comunicación programable (PCT) do cliente durante un período de tempo especificado (por exemplo, de 3:6 a XNUMX:XNUMX nun quente). día da semana estival) co fin de reducir o consumo de enerxía. -O cambio no comportamento do PCT en resposta ao evento pode ser un simple cambio no punto de consigna de temperatura durante a duración do evento ou un conxunto máis complexo de cambios, incluído o refrixeración previa, que minimizan o impacto do evento na comodidade do cliente. nivel.
Incentivo ao cliente	-Os incentivos adoptan dúas formas xerais. En primeiro lugar, os clientes poden recibir un PCT gratuíto ou ofrecer descontos / descontos nos PCT comprados por clientes como incentivo para inscribirse no programa DR. En segundo lugar, os clientes poden recibir un estipendio anual continuo por continuar a inscrición no programa. Menos comúns serían os incentivos continuos pagados aos clientes en función da redución real de enerxía durante os eventos.
Deseño de taxas	-Principalmente un programa de incentivos, onde os clientes reciben descontos ou PCT gratuítos por inscribirse no programa DR. Algúns programas poden pagar un estipendio periódico ou pagos de incentivos baseados na redución de enerxía durante os eventos.
Cliente obxectivo	-Residencial
Carga obxectivo	-CVAC
Requisito previo	-Tipicamente ningún, xa que os clientes reciben un PCT como parte da inscrición no programa
Cadro de tempo do programa	-Típicamente abarca os meses do ano onde se produce o consumo máximo de enerxía, aínda que pode ser durante todo o ano nalgúns casos.
Restricións de eventos	-Tipicamente de luns a venres, excluídos os festivos, con eventos consecutivos normalmente permitidos.
Días de eventos	-Típicamente de 9 a 15 por ano
Duración do evento	-Os eventos poden ocorrer en calquera momento, con duracións que oscilan entre as 2 e as 4 horas, aínda que normalmente os acontecementos ocorren durante os momentos máis altos de consumo de enerxía do día.
Notificación	-Típicamente o día antes, aínda que algúns programas poden ter notificacións tan curtas como 10 minutos.
Opt Comportamento	-Os clientes non están obrigados a participar en eventos, non obstante, serán automaticamente opcionados a eventos a menos que tomen medidas para anular o evento ou facer axustes manuais de temperatura durante o evento.
Certificación Eventos	-Tipicamente ningunha

Características de OpenADR para programas de termostatos residenciais

Sinais de eventos	–Un sinal SIMPLE con niveis do 1 ao 3 asignado ao cambio nos desfases do punto de consigna de temperatura PCT ou ao porcentaxe de ciclo termostáticotage . Se un programa de termostato residencial ten un único compoñente de desplazamento / ciclismo, debería mapearse ao nivel 1. Para os programas con compoñentes de compensación / ciclismo múltiples, o menor cambio do funcionamento normal debería mapearse ao nivel 1, cos outros valores de compensación / ciclismo. mapeado aos niveis 2 e 3 en grao crecente de impacto na vertedura de carga. -Se o despregamento admite B profile VEN, ademais do sinal SIMPLE, pódese incluír un sinal LOAD_CONTROL na carga útil cun tipo de x-loadControlLevelOffset ou x-loadControlCapacity para especificar a compensación do punto de consigna de temperatura ou o porcentaxe de ciclo termostático desexadotage respectivamente. Recoméndase que a tipo de unidade de "temperatura" empregado en cargas útiles utilizando o x-loadControlLevelOffset signalType para indicar Celsius ou Fahrenheit para a compensación. Vexa o anexo A para o exemploamples.
Opt Respostas	-VTNs que envían eventos debería definir o elemento oadrResponseRequired a "sempre", requirindo que o VEN responda cun optIn ou optOut – Os VEN deberían responder con optIn a menos que houbese algunha acción de anulación específica tomada polo cliente. -O A carga útil oadrCreateOpt pode ser empregada polos VEN para cualificar a participación de recursos nun evento. Por exemplo, un evento pode dirixirse aos ID de recursos de dous termostatos que controlan sistemas HVAC separados. Se o cliente decide que só un dos sistemas de climatización pode participar no evento, comunicaríase á VTN mediante a carga útil oadrCreateOpt. Teña en conta que a carga útil oadrCreateOpt só é compatible con B profile VENs
Descritor de eventos	-O evento a prioridade debe establecerse en 1 a non ser que as regras do programa ou a configuración de VTN especifiquen o contrario –Normalmente non se usan eventos de proba con programas de termostatos residenciais. Non obstante, se se permiten, o elemento testEvent debería establecerse en "true" para indicar o evento da proba. Se se precisa información adicional parametrizada neste elemento, pode seguir "verdadeiro" separado por un espazo con esta información adicional.
Período activo do evento	–A aleatorización úsase normalmente para eventos de termostatos residenciais que utilizan o elemento de tolerancia – eiRampOs elementos Up e eiRecovery normalmente non se usan
Liñas de base	–As liñas de base normalmente non se inclúen na carga útil do evento
Segmentación de eventos	-Os programas de termostato residencial diríxense aos recursos de climatización controlados polos PCT. A orientación normalmente especifica os ID de recursos dos sistemas HVAC (é dicir, o termostato) asociados a VEN ou o venID co obxectivo de clase de dispositivo de sinal de evento definido como Termostato
Servizos de Informes	–Normalmente non se emprega o informe de telemetría xa que non é absolutamente necesario para os programas de termostatos residenciais Consulte o anexo B para o examparquivos de informes de pilotos de servizos públicos que poden ser aplicables a este tipo de programas.
Opción Servizos	–Uso do servizo Opt para comunicar horarios de dispoñibilidade temporal normalmente non se usaría como parte dun programa CPP.
Servizos de rexistro	Intervalos de votación solicitado pola VTN para programas típicos de termostatos residenciais con antelación Non é necesario que sexan máis frecuentes que unha vez por hora. Non obstante, o uso de sondaxes para a detección de latidos do corazón pode requirir sondaxes máis frecuentes, como farían os programas de termostatos residenciais con tempos de notificación substancialmente máis curtos.

Envío rápido de DR

Características do programa de envío rápido DR

Carga Profile Obxectivo	-Enviar recursos para lograr a resposta de carga en "tempo real"
Controladores primarios	-Fiabilidade da rede e servizos auxiliares
Descrición do programa	O ISO / utilitarios utiliza o DR rápido para obter resposta de carga comprometida previamente en "tempo real". Esta resposta de carga comprometida é utilizada polas ISO / utilidades cando observan condicións que requiren unha acción inmediata para manter a estabilidade e integridade da rede. En tempo real significa que os recursos normalmente se envían cunha latencia que vai desde os 10 minutos para os recursos que se utilizan como reservas ata os 2 segundos para os recursos que se utilizan con fins de regulación. O tamaño da resposta de carga debe ser o suficientemente grande como para marcar a diferenza na mitigación da condición da rede e, polo tanto, os recursos son normalmente moi grandes e a miúdo xestionados polos agregadores como parte dun recurso agregado. Os tamaños mínimos para a resposta de carga para un recurso para cualificar para participar en servizos auxiliares normalmente roldan os 500 kW, pero poden ser tan baixos como 100 kW para algúns programas. Teña en conta que se o recurso se usa como reserva normalmente chamarase a diminuír (é dicir, lanzar) a carga, pero se se usa para fins de regulación pódese enviar para aumentar ou diminuír a carga.
Incentivo ao cliente	Os agregadores / clientes normalmente reciben dous tipos de incentivos. En primeiro lugar, reciben un pago por comprometer e poñer a disposición unha cantidade específica de resposta de carga dispoñible para eventos DR durante unha futura fiestra de tempo. O agregador / cliente establece normalmente a cantidade de resposta de carga, a xanela de dispoñibilidade e a cantidade a pagar. En segundo lugar, se se chama un evento durante a futura ventá temporal, realizarase un pago baseado na cantidade de resposta de carga durante a duración do evento.
Deseño de taxas	Os participantes no programa presentan unha oferta indicando a resposta á carga que están dispostos a ofrecer durante unha futura ventá temporal. Normalmente, a oferta tamén inclúe o pago que o agregador / cliente está disposto a aceptar pola resposta de carga. Nos mercados de servizos públicos/ISO, a oferta preséntase normalmente o día seguinte ou o día do período de tempo para o que se asumiu o compromiso. Como parte da súa cualificación e rexistro nos mercados, asócianse varios parámetros de rendemento ao recurso, como ramp taxa e límites de funcionamento mínimo e máximo. Estes parámetros rexen como se enviará. Se se acepta a oferta dun participante, pódese facer un pago ao cliente polo seu compromiso previo aínda que non se convoque ningún evento durante o período de tempo. Se se convoca un evento durante o período de tempo, o cliente pode recibir pagos adicionais pola súa actuación durante o evento. Estes pagos baseados no rendemento poden basearse nunha serie de factores, incluíndo a cantidade de enerxía, a potencia, o que segue o recurso as instrucións de envío e un pago por "quilometraxe" que reflicte a cantidade de carga profile tivo que cambiar durante o evento. Algúns destes parámetros, como enerxía e potencia, poden estar con respecto a unha liña de base.
Cliente obxectivo	-Agregadores e clientes de C&I autoagregados
Cargas obxectivo	- Os que poden responder a despachos en tempo real.

Requisito previo	-O cliente debe ter medición de intervalos -Debe cumprir os requisitos de tamaño mínimo para a resposta de carga -Debe ser capaz de responder aos envíos en tempo real -Tipicamente ten que subministrar telemetría en tempo real que mostre a resposta de carga actual
Cadro de tempo do programa	-En calquera momento
Restricións de eventos	-ningunha
Días de eventos	-ningunha
Duración do evento	-Tipicamente curto (menos de 30 minutos), pero en calquera caso nunca excederá a xanela de tempo na que o participante puxo o recurso á disposición cando presentou a súa oferta.
Notificación	-ningunha
Opt Comportamento	-Os clientes optan por defecto aos eventos dado que teñen unha resposta de carga comprometida previamente
Certificación Eventos	-Tipicamente un por ano (proba)

Características de OpenADR para programas de licitación de capacidade

Sinais de eventos	–Un sinal SIMPLE cos niveis 1 a 3 mapeados á cantidade de resposta de carga. Se o programa só admite un único nivel de resposta de carga, debería mapearse ao nivel 1. Para os programas con niveis múltiples de resposta de carga, o menor cambio do funcionamento normal debería mapearse ao nivel 1, cos valores de liberación de carga mapeados a niveis 2 e 3 en grao crecente de resposta de carga. -Se o despregamento admite B profile VEN, ademais do sinal SIMPLE, pódese incluír un envío en forma de sinal LOAD_DISPATCH na carga útil con tipos de sinal de consigna ou delta e unidades de potencia real. Este sinal representa o "punto de operación" desexado da carga e pódese expresar como unha cantidade absoluta de mW (é dicir, punto de consigna) ou como un número relativo de mW (é dicir, delta) do punto de operación actual dos recursos. Vexa o anexo A para o exemploamples.
Opt Respostas	-VTNs que envían eventos debería definir o elemento oadrResponseRequired a "sempre", requirindo que o VEN responda cun optIn ou optOut -Como agregadores / clientes teñen capacidade comprometida previamente Os VEN deben responder con optIn. Pódese enviar unha exclusión en resposta ao evento, pero esta é unha indicación de dispoñibilidade informal, non unha exclusión formal do evento. -O normalmente non se usaría a carga útil de oadrCreateOpt para cualificar os recursos que participan en eventos como normalmente a carga é unha única entidade agregada.
Descritor de eventos	-O evento a prioridade debe establecerse en 1 a non ser que as regras do programa ou a configuración de VTN especifiquen o contrario –Pódense usar eventos de proba, especialmente durante o rexistro e cualificación dun recurso. Se se permiten, o elemento testEvent debería establecerse en "true" para indicar o evento da proba. Se se precisa información adicional parametrizada neste elemento, pode seguir "verdadeiro" separado por un espazo con esta información adicional.
Período activo do evento	– Non se usan elementos de tolerancia. O eiRampOs períodos de up e eiRecovery normalmente forman parte dos parámetros dun recurso cando se rexistran e pódense usar. Debido á natureza dos envíos, poden ser abertos e, polo tanto, pode que non haxa hora de finalización do evento.
Liñas de base	–As liñas de base normalmente non se inclúen na carga útil do evento xa que estes datos normalmente non están dispoñibles no momento en que se inicia o evento. Non obstante, tanto as utilidades como os agregadores/clientes faríano view a inclusión de información de referencia nos eventos como útil.
Segmentación de eventos	-Os programas de oferta de capacidade normalmente non diferencian os recursos para un determinado cliente. A orientación normalmente especifica o venID, indicando que deberían participar todos os recursos asociados ao VEN, ou inclúe un ID de recurso representativo da carga agregada asociado a VEN.
Servizos de Informes	Os programas de DR rápido normalmente requiren informes TELEMETRY_USAGE con puntos de datos powerReal. O informe de uso describe o punto operativo actual dos recursos e utilízano a Utility / ISO para determinar a medida que o recurso segue a instrución de envío que se enviou. Nalgúns casos, a telemetría pode incluír outros puntos de datos como o voltage lecturas e estado de carga (é dicir, enerxía) no caso de que o recurso sexa algunha forma de almacenamento. Nalgúns casos, a frecuencia dos informes pode chegar a ser cada 2 segundos. Teña en conta que os informes de telemetría requiren B profile VENs. Vexa o anexo A para o exemploamples. Consulte tamén o anexo B para o examparquivos de informes de pilotos de servizos públicos que poden ser aplicables a este tipo de programas.
Opción Servizos	–Uso do servizo Opt para comunicar a dispoñibilidade temporal horarios normalmente non se usaría xa que os clientes comprometeron previamente a súa dispoñibilidade. Non obstante, este servizo pode ser útil como un xeito informal para que os participantes indiquen a falta de dispoñibilidade por motivos atenuantes como o fallo do equipo.
Servizos de rexistro	Debido aos poucos requirimentos de latencia dos despachos en tempo real só se usan patróns de interacción push.

Programa de tempo de uso (TOU) de vehículos eléctricos residenciais (EV)

Características do programa EV TOU residencial

Carga Profile Obxectivo	Unha estrutura tarifaria pola que se modifica o custo de cargar vehículos eléctricos para facer que os consumidores cambien os patróns de consumo.
Controladores primarios	O consumo de enerxía residencial ten o máximo á noite. Dado que a carga EV leva de 4 a 8 horas, pódese atrasar un par de horas para cambiar os picos de carga.
Descrición do programa	Os clientes que teñan un vehículo eléctrico poden rexistrarse nunha tarifa de tempo de uso do vehículo eléctrico (EV-TOU) e recibir tarifas máis baixas por cargar o seu vehículo en horas baixas, como entre a media noite e as 5 da mañá. ofrécese para animar aos clientes a limitar o uso diurno de electricidade, cando a demanda de electricidade é maior.
Incentivo ao cliente	Carga menos cara dos vehículos eléctricos.
Deseño de taxas	TOU con pico a media xornada, mañá e noite a media punta e de 12:5 a XNUMX:XNUMX pico
Cliente obxectivo	Propietario de EV cun profesional de cargafile que alcanza o pico á noite.
Cargas obxectivo	Cargadores EV
Requisito previo	O cliente debe ter un contador intelixente e EV
Cadro de tempo do programa	Todo o ano
Restricións de eventos	Ningún
Días de eventos	Todos os días ou só entre semana
Duración do evento	5-8 horas
Notificación	O cliente recibe unha notificación dos niveis de prezo nas súas facturas mensuais e as VTN envían sinais de eventos día antes.
Opt Comportamento	Os contribuíntes poden cambiar o seu plan de tarifas como farían normalmente cunha utilidade.
Certificación Eventos

Características de OpenADR para programas residenciais EV TOU

Sinais de eventos	Sinais de ELECTRICITY_PRICE con niveis de prezo reais, así como sinais SIMPLES para permitir a participación de VEN de 2.0a Vexa o anexo A para o exemploamples.
Opt Respostas	Optar sempre por VEN
Descritor de eventos	Un evento á semana, con intervalos de eventos para cada nivel de prezo
Período activo do evento	Debe utilizarse como mínimo unha notificación 24 horas. Cada intervalo de eventos debería capturar o nivel de taxa TOU
Liñas de base	N/A
Segmentación de eventos	Non se precisa orientación avanzada, só segmentación a nivel VEN.
Servizos de Informes	Non se precisan informes, todos os datos poden proceder do medidor. Consulte o anexo B para o examparquivos de informes de pilotos de servizos públicos que poden ser aplicables a este tipo de programas.
Opción Servizos	Os servizos Opt non serían relevantes para este tipo de programa.
Servizos de rexistro	Os consumidores fornecerían previamente o seu VEN coa utilidade para recibir sinais de prezos.

Programa de prezos en tempo real de vehículos eléctricos da estación pública (EV)

Características do programa RTP de estación pública EV

Carga Profile Obxectivo	Unha actividade de resposta á demanda pola que se modifica o custo de cargar vehículos eléctricos para trasladar a realidade do prezo máximo aos consumidores.
Controladores primarios	O prezo da electricidade é variable ao longo dun día. Este programa pretende facer coincidir de forma máis eficiente o prezo da carga co custo da electricidade.
Descrición do programa	Os cargadores públicos poden existir nos lugares de traballo, nos aparcamentos públicos e nas tendas de venda polo miúdo. Este programa transmite os prezos en tempo real a potenciais cargadores antes de conectalos, para que poidan tomar unha decisión informada sobre se cargar ou non o seu coche.
Incentivo ao cliente	Carga menos cara en horarios baixos.
Deseño de taxas	Os prezos poden cambiarurly, pero unha vez que un cliente elixe conectar o seu coche, a tarifa establécese para a duración da carga.
Cliente obxectivo	Calquera persoa cun EV que precise cargar fóra de casa.
Cargas obxectivo	Cargadores públicos de EV
Requisito previo	Os cargadores EV deben estar conectados a Internet e certificados OpenADR2.0b, ou conectados a unha pasarela OpenADR2.0b VEN.
Cadro de tempo do programa	Todo o ano
Restricións de eventos	Ningún
Días de eventos	Todos os días ou só entre semana
Duración do evento	1 hora ou máis
Notificación	O cliente recibe a notificación da tarifa vixente cando elixe conectar o seu coche.
Opt Comportamento	Os clientes poden optar por non decidir cobrar.
Certificación Eventos

Características de OpenADR para programas RTP de estación pública EV

Sinais de eventos	Sinais de ELECTRICITY_PRICE con prezos. Vexa o anexo A para o exemploamples.
Opt Respostas	Optar sempre por VEN
Descritor de eventos	Os eventos deben ser contiguos e conter un intervalo.
Período activo do evento	Debe utilizarse polo menos unha hora de notificación, pero as utilidades poden optar por usar a notificación con antelación.
Liñas de base	N/A
Segmentación de eventos	Non se precisa orientación avanzada, pero a orientación pódese usar para enviar prezos a transformadores específicos, alimentadores ou áreas xeográficas.
Servizos de Informes	Non se precisa informe, pero pódese usar se o desexa. Consulte o anexo B para o examparquivos de informes de pilotos de servizos públicos que poden ser aplicables a este tipo de programas.
Opción Servizos	Os servizos Opt non serían relevantes para este tipo de programa.
Servizos de rexistro	Un provedor de estación de carga subministraría aos seus dispositivos o VTN dunha utilidade.

Programa DR de Recursos Enerxéticos Distribuídos (DER)

A seguinte descrición do programa é hipotética e baséase nun traballo de investigación (referencia do artigo de Rish) que describe como os clientes dos servizos públicos poden utilizar recursos de almacenamento DER para participar en programas DR como programas de prezos en tempo real (RTP).

Características do programa de Recursos Enerxéticos Distribuídos (DER)

Carga Profile Obxectivo	Unha actividade de resposta á demanda utilizada para suavizar a integración dos recursos enerxéticos distribuídos na rede intelixente.
Controladores primarios	-Redución dos gastos de capital e redución dos custos enerxéticos
Descrición do programa	Os clientes con recursos DER que poden coller enerxía e almacenala poden minimizar o custo da compra de electricidade na rede durante períodos de prezo elevados empregando primeiro os recursos enerxéticos almacenados, seguido da implementación de estratexias de vertido de carga
Incentivo ao cliente	Capacidade para controlar os custos en momentos de altos prezos da electricidade aproveitando a enerxía almacenada xerada a través de PV ou outros medios e implementando estratexias de eliminación de carga
Deseño de taxas	As taxas de electricidade varían cos prezos do mercado por xunto ou cunha tarifa que varía en función da hora do día, da estación ou da temperatura
Cliente obxectivo	Clientes con recursos de almacenamento de enerxía
Cargas obxectivo	Calquera
Requisito previo	Recursos de almacenamento de enerxía
Cadro de tempo do programa	En calquera momento
Restricións de eventos	Ningún
Días de eventos	Todos os días
Duración do evento	24 horas
Notificación	Día por diante
Opt Comportamento	N / A: un programa de mellor esforzo
Certificación Eventos	Ningún

Características de OpenADR para recursos enerxéticos distribuídos (DER)

Sinais de eventos	Sinais ELECTRICITY_PRICE con intervalos de prezos de 24 horas durante un período de 24 horas. Este sinal precisará do B profile. Este programa non se presta á sinalización SIMPLE para A profile VENs. Vexa o anexo A para o exemploamples.
Opt Respostas	-VTNs que envían eventos debería establecer o elemento oadrResponseRequired en "nunca", evitando que os VEN respondan.
Descritor de eventos	-O evento a prioridade debe establecerse en 1 a non ser que as regras do programa ou a configuración de VTN especifiquen o contrario
Período activo do evento	24 horas con intervalos de 1 hora con notificación do día antes
Liñas de base	N/A
Segmentación de eventos	Non se precisa ningunha orientación avanzada que non sexa o venID
Servizos de Informes	Non fai falta ningún informe Consulte o anexo B para o examparquivos de informes de pilotos de servizos públicos que poden ser aplicables a este tipo de programas.
Opción Servizos	Non usado
Servizos de rexistro	Intervalos de votación solicitado pola VTN para programas típicos de día con antelación Non é necesario que sexan máis frecuentes que unha vez por hora. Non obstante, o uso de sondaxes para a detección de latidos do corazón pode requirir sondaxes máis frecuentes, como farían os programas de termostatos residenciais con tempos de notificación substancialmente máis curtos.

– Sample Modelos de datos e carga útil

As seguintes táboas e carga útil XMLampos proporcionarán aos implementadores ex. tanxiblesampde como se deben implementar os modelos DR neste documento. Os seguintes prefixos de espazo de nomes utilízanse na carga útil, por exemploamples:

xmlns: oadr = "http://openadr.org/oadr-2.0b/2012/07"
xmlns: pyld = ”http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
xmlns: ei = "http://docs.oasis-open.org/ns/energyinterop/201110"
xmlns: scale = "http://docs.oasis-open.org/ns/emix/2011/06/siscale"
xmlns: emix = "http://docs.oasis-open.org/ns/emix/2011/06"
xmlns: strm = ”urn: ietf: params: xml: ns: icalendar-2.0: stream”
xmlns: xcal = ”urn: ietf: params: xml: ns: icalendar-2.0 ″
xmlns: power = "http://docs.oasis-open.org/ns/emix/2011/06/power"

Programa de prezos máximos críticos (CPP)

Escenario CPP 1: caso de uso sinxelo, A ou B Profile

Evento
- Notificación: día antes do evento
- Hora de inicio: 1pm
- Duración: 4 horas
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 1
- Nome do sinal: SIMPLE
  - Tipo de sinal: nivel
  - Unidades: N / A
  - Número de intervalos 1
  - Duración (s) do intervalo: 4 horas
  - Valor (s) de intervalo típico (s): 1
  - Obxectivo do sinal: N / A
- Obxectivo (s) do evento: venID_1234
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Ningún

Escenario CPP 2: caso de uso típico, B profile

Evento
- Notificación: día antes do evento
- Hora de inicio: 1:XNUMX
- Duración: 4 horas
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 2
- Nome do sinal: sinxelo
  - Tipo de sinal: nivel
  - Unidades: nivel 0, 1, 2, 3
  - Número de intervalos 1
  - Duración (s) do intervalo: 4 horas
  - Valor (s) de intervalo típico (s): 1 ou 2
  - Obxectivo do sinal: ningún
- Nome do sinal: ELECTRICITY_PRICE
  - Tipo de sinal: prezo
  - Unidades: USD por Kwh
  - Número de intervalos 1
  - Duración (s) do intervalo: 4 horas
  - Valor (s) de intervalo típico: 0.10 $ a 1.00 $
  - Obxectivo do sinal: ningún
- Obxectivos do evento: venID_1234
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Ningún

CPP Escenario 3 - Caso de uso complexo

Evento
- Notificación: día antes do evento
- Hora de inicio: 2pm
- Duración: 6 horas
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 2
- Nome do sinal: sinxelo
  - Tipo de sinal: nivel
  - Unidades: Nivel 0,1, 2, 3)
  - Número de intervalos 3
  - Duración (s) do intervalo: 1 hora, 4 horas, 1 hora
  - Valor (s) de intervalo típico (s): 1, 2, 1 (para cada intervalo respectivamente)
  - Obxectivo do sinal: ningún
- Nome do sinal: ELECTRICITY_PRICE
  - Tipo de sinal: prezo
  - Unidades: USD por Kwh
  - Número de intervalos 3
  - Duración (s) do intervalo: 1 hora, 4 horas, 1 hora
  - Valor (s) de intervalo típico: 0.50 $, 0.75 $, 0.50 $ (para cada intervalo respectivamente)
  - Obxectivo do sinal: ningún
- Obxectivos do evento: Recurso_1, Recurso_2, Recurso_3
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Ningún

CPP SampCarga útil de eventos - Típico B Profile Caso de uso

OadrDisReq091214_043740_513

TH_VTN

Evento091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

lonxe

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT4H

PT24H

PT4H

2.0

SINXELO

nivel

SIG_01

0.0

PT4H

0.75

PREZO_ELECTRICIDADE

prezo

SIG_02

currencyPerKWh

USD

ningunha

0.0

venID_1234

sempre

Programa de ofertas de capacidade (CBP)

Escenario CBP 1: caso de uso sinxelo, A ou B Profile

Evento
- Notificación: día antes do evento
- Hora de inicio: 1pm
- Duración: 4 horas
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 1
- Nome do sinal: SIMPLE
  - Tipo de sinal: nivel
  - Unidades: N / A
  - Número de intervalos 1
  - Duración (s) do intervalo: 4 horas
  - Valor (s) de intervalo típico (s): 1
  - Obxectivo do sinal: N / A
- Obxectivo (s) do evento: venID_1234
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Ningún

Escenario CBP 2: caso de uso típico, B profile

Evento
- Notificación: día antes do evento
- Hora de inicio: 1:XNUMX
- Duración: 4 horas
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 2
- Nome do sinal: sinxelo
  - Tipo de sinal: nivel
  - Unidades: Nivel 0,1, 2, 3
  - Número de intervalos 1
  - Duración (s) do intervalo: 4 horas
  - Valor (s) de intervalo típico (s): 1 ou 2
  - Obxectivo do sinal: ningún
- Nome do sinal: BID_LOAD
  - Tipo de sinal: punto de consigna
  - Unidades: powerReal
  - Número de intervalos 1
  - Duración (s) do intervalo: 4 horas
  - Valor (s) de intervalo típico: 20kW a 100kW
  - Obxectivo do sinal: ningún
- Obxectivos do evento: venID_1234
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Ningún

CBP Escenario 3 - Caso de uso complexo

Evento
- Notificación: día do evento (cantas horas?)
- Hora de inicio: 1pm
- Duración: 6 horas
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 3
- Nome do sinal: sinxelo
  - Tipo de sinal: nivel
  - Unidades: Nivel 0,1, 2, 3)
  - Número de intervalos: 2
  - Duración (s) do intervalo: 3 horas, 3 horas
  - Valor (s) de intervalo típico (s): 1, 2 (por cada intervalo respectivamente)
  - Obxectivo do sinal: ningún
- Nome do sinal: BID_LOAD
  - Tipo de sinal: punto de consigna
  - Unidades: powerReal
  - Número de intervalos 2
  - Duración (s) do intervalo: 3 horas, 3 horas
  - Valor (s) de intervalo típico (s): 40kW, 80kW (para cada intervalo respectivamente)
  - Obxectivo do sinal: ningún
- Nome do sinal: BID_PRICE
  - Tipo de sinal: prezo
  - Unidades: currencyPerKW
  - Número de intervalos 1
  - Duración (s) do intervalo: 6 horas
  - Valor (s) de intervalo típico: 3.10 $
  - Obxectivo do sinal: ningún
- Obxectivos do evento: Recurso_1, Recurso_2, Recurso_3
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informe (s)
- Nome do informe: TELEMETRY_USAGE
- Tipo de informe: uso
- Unidades: powerReal
- Tipo de lectura: lectura directa
- Frecuencia do informe: cada 1 hora

CBP SampCarga útil de eventos - Típico B Profile Caso de uso

OadrDisReq091214_043740_513

TH_VTN

Evento091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

lonxe

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT4H

PT24H

PT4H

2.0

SINXELO

nivel

SIG_01

0.0

PT4H

80.0

BID_LOAD

punto de set

SIG_02

RealPower

60.0

<power:voltage>220.0tage>

certo

0.0

venID_1234

sempre

Programa de termostatos residenciais

Termostato residencial Escenario 1: caso de uso sinxelo, A ou B Profile

Evento
- Notificación: día antes do evento
- Hora de inicio: 1pm
- Duración: 4 horas
- Aleatorización: 10 minutos
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 1
- Nome do sinal: SIMPLE
  - Tipo de sinal: nivel
  - Unidades: N / A
  - Número de intervalos 1
  - Duración (s) do intervalo: 4 horas
  - Valor (s) de intervalo típico (s): 1
  - Obxectivo do sinal: N / A
- Obxectivo (s) do evento: Recurso_1
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Ningún

Termostato residencial Escenario 2: caso de uso típico, B profile

Evento
- Notificación: día antes do evento
- Hora de inicio: 1:XNUMX
- Duración: 4 horas
- Aleatorización: 10 minutos
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 2
- Nome do sinal: sinxelo
  - Tipo de sinal: nivel
  - Unidades: Nivel 0,1, 2, 3
  - Número de intervalos 1
  - Duración (s) do intervalo: 4 horas
  - Valor (s) de intervalo típico (s): 1 ou 2
  - Obxectivo do sinal: ningún
- Nome do sinal: LOAD_CONTROL
  - Tipo de sinal: x-loadControlLevelOffset
  - Unidades: temperatura
  - Número de intervalos 1
  - Duración (s) do intervalo: 4 horas
  - Valor (s) de intervalo típico: 2 a 6 graos Fahrenheit
  - Obxectivo do sinal: ningún
- Obxectivos do evento: Recurso_1, Recurso_2
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn, Possible outOut (oadrCreateOpt)
Informes
- Ningún

Termostato residencial Escenario 3 - Caso de uso complexo

Evento
- Notificación: día do evento
- Hora de inicio: 1pm
- Duración: 6 horas
- Aleatorización: 10 minutos
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 3
- Nome do sinal: sinxelo
  - Tipo de sinal: nivel
  - Unidades: Nivel 0,1, 2, 3)
  - Número de intervalos: 2
  - Duración (s) do intervalo: 3 horas, 3 horas
  - Valor (s) de intervalo típico (s): 1, 2 (por cada intervalo respectivamente)
  - Obxectivo do sinal: ningún
- Nome do sinal: BID_LOAD
  - Tipo de sinal: x-loadControlCapacity
  - Unidades: ningunha
  - Número de intervalos 2
  - Duración (s) do intervalo: 3 horas, 3 horas
  - Valor (s) de intervalo típico (s): 0.9, 0.8 (por cada intervalo respectivamente)
  - Obxectivo do sinal: ningún
- Obxectivos do evento: Recurso_1, Recurso_2, Recurso_3
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn, Possible outOut (oadrCreateOpt)
Informe (s)
- Ningún

Termostato residencial SampCarga útil de eventos - Típico B Profile Caso de uso

OadrDisReq091214_043740_513

TH_VTN

Evento091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

lonxe

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT4H

PT10M

PT24H

PT4H

2.0

SINXELO

nivel

SIG_01

0.0

PT4H

6.0

LOAD_CONTROL

x-loadControlLevelOffset

SIG_02

temperatura

fahrenheit

ningunha

0.0

recurso_1

recurso_2

sempre

Envío rápido de DR

Fast DR Escenario 1: caso de uso sinxelo, A ou B Profile

Evento
- Notificación: 10 minutos
- Hora de inicio: 1pm
- Duración: 0 (aberto)
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 1
- Nome do sinal: SIMPLE
  - Tipo de sinal: nivel
  - Unidades: N / A
  - Número de intervalos 1
  - Duración (s) do intervalo: 0 (final aberto)
  - Valor (s) de intervalo típico (s): 1
  - Obxectivo do sinal: N / A
- Obxectivo (s) do evento: venID_1234
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Ningún

Fast DR Escenario 2: caso de uso típico, B profile

Evento
- Notificación: 10 minutos
- Hora de inicio: 1:XNUMX
- Duración: 30 minutos
- Aleatorización: ningunha
- Ramp Arriba: 5 minutos
- Recuperación: 5 minutos
- Número de sinais: 2
- Nome do sinal: sinxelo
  - Tipo de sinal: nivel
  - Unidades: Nivel 0,1, 2, 3
  - Número de intervalos 1
  - Duración (s) do intervalo: 30 minutos
  - Valor (s) de intervalo típico (s): 1 ou 2
  - Obxectivo do sinal: ningún
- Nome do sinal: LOAD_DISPATCH
  - Tipo de sinal: delta
  - Unidades: powerReal
  - Número de intervalos 1
  - Duración (s) do intervalo: 30 minutos
  - Valor (s) de intervalo típico: 500 kW a 2 mW
  - Obxectivo do sinal: ningún
- Obxectivos do evento: venID_1234
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Nome do informe: TELEMETRY_USAGE
- Tipo de informe: uso
- Unidades: powerReal
- Tipo de lectura: lectura directa
- Frecuencia do informe: cada 1 minuto

Escenario rápido de DR 3: caso de uso complexo

Evento
- Notificación: 10 minutos
- Hora de inicio: 1pm
- Duración: 30 minutos
- Aleatorización: ningunha
- Ramp Arriba: 5 minutos
- Recuperación: 5 minutos
- Número de sinais: 2
- Nome do sinal: sinxelo
  - Tipo de sinal: nivel
  - Unidades: Nivel 0,1, 2, 3)
  - Número de intervalos: 2
  - Duración (s) do intervalo: 15 minutos, 15 minutos
  - Valor (s) de intervalo típico (s): 1, 2 (por cada intervalo respectivamente)
  - Obxectivo do sinal: ningún
- Nome do sinal: LOAD_DISPATCH
  - Tipo de sinal: punto de consigna
  - Unidades: powerReal
  - Número de intervalos 2
  - Duración (s) do intervalo: 15 minutos, 15 minutos
  - Valor (s) de intervalo típico (s): 800kW, 900kW (para cada intervalo respectivamente)
  - Obxectivo do sinal: ningún
- Obxectivos do evento: Recurso_1
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informe (s)
- Nome do informe: TELEMETRY_USAGE
- Tipo de informe: uso
- Unidades: powerReal e voltage
- Tipo de lectura: lectura directa
- Frecuencia do informe: cada 5 segundos

Rápido DR SampCarga útil de eventos - Típico B Profile Caso de uso

OadrDisReq091214_043740_513

TH_VTN

Evento091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

lonxe

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT10M

<ei:x-eiRampArriba>

PT5M

</ei:x-eiRampArriba>

PT5M

PT10M

2.0

SINXELO

nivel

SIG_01

0.0

PT10M

500.0

LOAD_DISPATCH

delta

SIG_02

RealPower

60.0

<power:voltage>220.0tage>

certo

0.0

venID_1234

sempre

Rápido DR Sample Carga útil de metadatos do informe – Típico B Profile Caso de uso

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

recurso1

uso

RealEnergy

Lectura directa

http: // MarketContext1

<oadr:oadrSamplingRate>

PT1M

PT10M

falso

</oadr:oadrSamplingRate>

ReportSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

<ei:createdDateTime>2015-06-12T19:25:12Z</ei:createdDateTime>

ec27de207837e1048fd3

Rápido DR SampCarga útil de solicitude de informe – Típico B Profile Caso de uso

ReportReqID130615_192625_230

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

PT1M

<xcal:date-time>2015-06-14T13:00:00Z</xcal:date-time>

PT10M

rID120615_122512_981_0

x-notAplicable

VEN130615_192312_582

Rápido DR SampCarga útil de datos do informe: típico B Profile Caso de uso

ReportUpdReqID130615_192730_445

<xcal:date-time>2015-06-14T02:27:29Z</xcal:date-time>

rID120615_122512_981_0

100

0.0

500.0

Calidade boa - non específica

RP_54321

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

TELEMETRÍA_USAXE

<ei:createdDateTime>2015-06-14T02:27:29Z</ei:createdDateTime>

VEN130615_192312_582

Programa de tempo de uso (TOU) de vehículos eléctricos residenciais (EV)

Teña en conta que a medida que o programa comunica os niveis de taxa de forma bastante estruturada só se amosan os casos de uso sinxelos e típicos

Escenario 1 de EV residencial: caso de uso sinxelo, A ou B Profile

Evento
- Notificación: día antes do evento
- Hora de inicio: 1pm
- Duración: 24 horas
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 1
- Nome do sinal: SIMPLE
  - Tipo de sinal: nivel
  - Unidades: N / A
  - Número de intervalos; Cambios de nivel de TOU iguais en 24 horas (2 - 6)
  - Duración (s) de intervalo: marco de tempo activo de nivel TOU (é dicir, 6 horas)
  - Valor (s) de intervalo típico (s): 0 - 4 mapeado a TU Tiers
  - Obxectivo do sinal: N / A
- Obxectivo (s) do evento: venID_1234
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Ningún

Escenario de EV residencial 2: caso de uso típico, B profile

Evento
- Notificación: día antes do evento
- Hora de inicio: medianoite
- Duración: 24 horas
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 2
- Nome do sinal: sinxelo
  - Tipo de sinal: nivel
  - Unidades: nivel 0, 1, 2, 3
  - Número de intervalos: igual TOU Cambio de nivel en 24 horas (2 - 6)
  - Duración (s) de intervalo: marco de tempo activo de nivel TOU (é dicir, 6 horas)
  - Valor (s) de intervalo típico (s): 0-4 mapeado a niveles TOU (0 - nivel máis barato)
  - Obxectivo do sinal: ningún
- Nome do sinal: ELECTRICITY_PRICE
  - Tipo de sinal: prezo
  - Unidades: USD por Kwh
  - Número de intervalos: cambios de nivel TOU iguais en 24 horas (2 - 6)
  - Duración (s) de intervalo: marco de tempo activo de nivel TOU (é dicir, 6 horas)
  - Valor (s) de intervalo típico: 0.10 $ a 1.00 $ (taxa actual de nivel)
  - Obxectivo do sinal: ningún
- Obxectivos do evento: venID_1234
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Ningún

EV residencial SampCarga útil de eventos - Típico B Profile Caso de uso

OadrDisReq091214_043740_513

TH_VTN

Evento091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

lonxe

<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>

PT24H

PT5H

0.0

PT7H

1.0

PT47H

2.0

PT5H

1.0

SINXELO

nivel

SIG_01

0.0

PT5H

0.35

PT7H

0.55

PT7H

0.75

PT5H

0.55

PREZO_ELECTRICIDADE

prezo

SIG_02

currencyPerKWh

USD

ningunha

0.0

venID_1234

sempre

Programa de prezos en tempo real de vehículos eléctricos da estación pública (EV)

Teña en conta que, como este é un programa de prezos en tempo real, realmente non hai diferenciación entre un caso de uso simple, típico e complexo. Polo tanto sampOs datos do ficheiro só se mostrarán para un caso de uso típico.

Estación pública EV Escenario 1: caso de uso típico, B profile

Evento
- Notificación: 1 hora antes
- Hora de inicio: 1:XNUMX
- Duración: 1 horas
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 1
- Nome do sinal: ELECTRICITY_PRICE
  - Tipo de sinal: prezo
  - Unidades: USD por Kwh
  - Número de intervalos 1
  - Duración (s) do intervalo: 1 horas
  - Valor (s) de intervalo típico: 0.10 $ a 1.00 $
  - Obxectivo do sinal: ningún
- Obxectivos do evento: venID_1234
- Prioridade: 1
- Requírese resposta VEN: sempre
- VEN Resposta esperada: optIn
Informes
- Ningún

Estación Pública EV SampCarga útil de eventos - Típico B Profile Caso de uso

OadrDisReq091214_043740_513

TH_VTN

Evento091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

lonxe

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT1H

0.75

PREZO_ELECTRICIDADE

prezo

SIG_01

currencyPerKWh

USD

ningunha

0.0

venID_1234

sempre

Programa DR de Recursos Enerxéticos Distribuídos (DER)

Estación pública EV Escenario 1: caso de uso típico, B profile

Evento
- Notificación: día adiante
- Hora de inicio: medianoite
- Duración: 24 horas
- Aleatorización: ningunha
- Ramp Arriba: Ningún
- Recuperación: ningunha
- Número de sinais: 24
- Nome do sinal: ELECTRICITY_PRICE
  - Tipo de sinal: prezo
  - Unidades: USD por Kwh
  - Número de intervalos 1
  - Duración (s) do intervalo: 1 horas
  - Valor (s) de intervalo típico: 0.10 $ a 1.00 $
  - Obxectivo do sinal: ningún
- Obxectivos do evento: venID_1234
- Prioridade: 1
- Requírese resposta VEN: nunca
- VEN Resposta esperada: n / a
Informes
- Ningún

Estación Pública EV SampCarga útil de eventos - Típico B Profile Caso de uso

OadrDisReq091214_043740_513

TH_VTN

Evento091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

lonxe

<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>

PT24H

PT1H

0.75

PT1H

0.80

PREZO_ELECTRICIDADE

prezo

SIG_01

currencyPerKWh

USD

ningunha

0.0

venID_1234

nunca

– Example Informes de Utility Pilots

Os membros da OpenADR Alliance proporcionaron o seguinte B Profile oadrUpdateReport carga útil samparquivos de programas piloto de servizos públicos nos que se despregaran os seus VEN. As seguintes notas acompañaron as tres cargas útiles samples proporcionadas:

Obxectivo de carga útil do termostato:

Debe coñecer o estado do termostato (temperatura, puntos de consigna, ventilador e estados de modo)
Se está activado, se o cliente cambiou ou non a configuración do termostato (mensaxes de anulación manual)

Obxectivo de carga útil de M&V para descontos:

Estado dos recursos e anulación manual no caso de optar
Datos de intervalo dun contador de pulsos KYZ ou monitor de enerxía para a enerxía total en KWH e a demanda instantánea en KW

Obxectivo de carga útil de datos de intervalos intelixentes / AMI:

O intervalo de lectura do medidor AMI é de aproximadamente 15 minutos a 1 hora. Aínda que útil, non suficientemente granulado para estimacións de facturación case en tempo real
Enerxía total en KWH, enerxía delta en KWH, demanda instantánea en KW

Os seguintes prefixos de espazo de nomes utilízanse na carga útil, por exemploamples:

xmlns: oadr = "http://openadr.org/oadr-2.0b/2012/07"
xmlns: pyld = ”http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
xmlns: ei = "http://docs.oasis-open.org/ns/energyinterop/201110"
xmlns: scale = "http://docs.oasis-open.org/ns/emix/2011/06/siscale"
xmlns: emix = "http://docs.oasis-open.org/ns/emix/2011/06"
xmlns: strm = ”urn: ietf: params: xml: ns: icalendar-2.0: stream”
xmlns: xcal = ”urn: ietf: params: xml: ns: icalendar-2.0 ″
xmlns: power = "http://docs.oasis-open.org/ns/emix/2011/06/power"

Informe de termostato carga útil Sample

RUP-18

<xcal:date-time>2014-03-21T02:25:03Z</xcal:date-time>

PT1M

<xcal:date-time>2014-03-21T02:25:03Z</xcal:date-time>

PT1M

Estado

certo

falso

Sen valor novo: valor anterior usado

Temp actual

77.000000

Sen valor novo: valor anterior usado

Axuste de temperatura de calor

64.000000

Sen valor novo: valor anterior usado

Axuste de temperatura fresca

86.000000

Sen valor novo: valor anterior usado

Configuración do modo HVAC

Sen valor novo: valor anterior usado

Modo actual de climatización

0.000000

Sen calidade - sen valor

Configuración do modo de ventilador

Sen valor novo: valor anterior usado

Modo de espera actual

Sen valor novo: valor anterior usado

Modo fóra actual

Sen valor novo: valor anterior usado

Humidade actual

0.000000

Sen calidade - sen valor

RP21

REQ: RReq: 1395368583267

0013A20040980FAE

TELEMETRY_STATUS

<ei:createdDateTime>2014-03-21T02:26:04Z</ei:createdDateTime>

VEN.ID:1395090780716

M&Vfor Rebates Report Payload Sample

RUP-10

<xcal:date-time>2015-08-21T17:41:14Z</xcal:date-time>

PT30S

<xcal:date-time>2015-08-21T17:41:14Z</xcal:date-time>

PT30S

Estado

certo

falso

Calidade boa - non específica

Reconto de pulsos

34750.000000

Calidade boa - non específica

Enerxía

33985.500000

Calidade boa - non específica

Potencia

1.26

Calidade boa - non específica

RP15

REQ: RReq: 10453335019195698

0000000000522613 60

TELEMETRÍA_USAXE

<ei:createdDateTime>2015-08-21T17:41:50Z</ei:createdDateTime>

VEN.ID:1439831430142

Carga útil do informe de datos de intervalo de contador intelixente/AMI Sample

RUP-4096

<xcal:date-time>2014-09-10T06:26:52Z</xcal:date-time>

PT1M

<xcal:date-time>2014-09-10T06:26:52Z</xcal:date-time>

PT15S

demanda instantánea

6.167000

Sen valor novo: valor anterior usado

intervalDataDelivered

0.051000

Sen valor novo: valor anterior usado

currSumDelivered

12172.052000

Sen valor novo: valor anterior usado

<xcal:date-time>2014-09-10T06:27:07Z</xcal:date-time>

PT15S

demanda instantánea

6.114000

Sen valor novo: valor anterior usado

intervalDataDelivered

0.051000

Sen valor novo: valor anterior usado

currSumDelivered

12172.052000

Sen valor novo: valor anterior usado

<xcal:date-time>2014-09-10T06:27:22Z</xcal:date-time>

PT15S

demanda instantánea

6.113000

Sen valor novo: valor anterior usado

intervalDataDelivered

0.051000

Sen valor novo: valor anterior usado

currSumDelivered

12172.142000

Sen valor novo: valor anterior usado

<xcal:date-time>2014-09-10T06:27:37Z</xcal:date-time>

PT15S

demanda instantánea

6.112000

Sen valor novo: valor anterior usado

intervalDataDelivered

0.051000

Sen valor novo: valor anterior usado

currSumDelivered

12172.142000

Sen valor novo: valor anterior usado

RP4101

<ei:reportRequestID>d5f88bf0-1a8d-0132-eab3-0a5317f1edaa</ei:reportRequestID>

<ei:reportSpecifierID>00:21:b9:00:f2:a9</ei:reportSpecifierID>

TELEMETRÍA_USAXE

<ei:createdDateTime>2014-09-10T06:27:53Z</ei:createdDateTime>

<ei:venID>2b2159c0-19cd-0132-eaa3-0a5317f1edaa</ei:venID>

- Servizos

Open ADR admite os seguintes servizos:

Servizo EiEvent – Usado polas VTN para enviar eventos de resposta á demanda aos VEN e usado polas VEN para indicar se os recursos van participar no evento. O único servizo compatible con A profile é EiEvent
Servizo EiReport - Usado por VEN e VTN para intercambiar informes históricos, de telemetría e de previsión
Servizo EiOpt - Usado por VEN para comunicar o horario de dispoñibilidade temporal ás VTN ou para cualificar os recursos que participan nun evento
Servizo EiRegisterParty - Iniciado polo VEN e usado tanto polo VEN como polo VTN para intercambiar a información necesaria para garantir o intercambio interoperable de cargas útiles
Servizo OadrPoll - Usado polos VEN para examinar a rede virtual de rede de carga útil de calquera dos outros servizos

A e B profile as operacións de servizo defínense polo elemento raíz de cada carga útil, excluíndo os envoltorios oadrPayload e oadrSignedObject utilizados en todos os B profile cargas útiles.

- Definicións de carga útil

Cargas útiles de EiEvent

oadrRequestEvent – Utilizado nun modelo de intercambio de atracción polo VEN para recuperar todos os eventos relevantes do VTN. Usado como mecanismo de votación principal para A profile VEN, pero só se usa en VEN B para sincronizar co VTN.
oadrDistributeEvent - Usado pola VTN para entregar eventos de resposta á demanda ao VEN
oadrCreatedEvent - Usado polo VEN para comunicar se ten a intención de participar nun evento optando por ou non
oadrResponse - Usado pola VTN para confirmar a recepción do optIn ou optOut do VEN

EiReport cargas útiles

Teña en conta que tanto os VEN como os VTN son capaces de ser produtores de informes e solicitantes de informes, polo que calquera das partes pode iniciar todas as cargas útiles a continuación.

oadrRegisterReport - Usado para publicar as súas capacidades de informes nun informe de metadatos
oadrRegisteredReport -Agradecer a recepción de oadrRegisterReport, solicitar opcionalmente un dos informes ofrecidos
oadrCrear Informe - Utilízase para solicitar un informe que xa foi ofrecido polo VEN ou VTN
oadrCreatedInforme - Confirmar a recepción dunha solicitude de informe
oadrInforme de actualización -Enviar un informe solicitado que conteña datos de intervalo
oadrInforme actualizado - Confirmar a recepción dun informe entregado
oadrCancelInforme - Cancelar un informe periódico solicitado previamente
oadrInforme cancelado - Recoñecer a cancelación dun informe periódico
oadrResponse - Utilízase como resposta de marcador de posición nalgúns patróns de intercambio de extracción cando se entrega unha resposta de capa de aplicación nunha solicitude de capa de transporte.

Cargas útiles EiOpt

oadrCrearOpt - Utilízase para dous propósitos claramente diferentes
- Para que o VEN comunique un calendario de dispoñibilidade temporal á VTN en canto á súa capacidade para participar en eventos de DR
- Para que o VEN cualifique os recursos que participan nun evento
oadrCreatedOpt - Recoñecer a recepción da carga útil de oadrCreateOpt
oadrCancelOpt -Cancela un horario de dispoñibilidade temporal
oadrCanceledOpt - Recoñecer a cancelación dun informe de dispoñibilidade temporal

Cargas útiles de EiRegisterParty

oadrQueryRegistration - Un xeito de que o VEN poida consultar a información de rexistro de VTN sen rexistrarse realmente.
oadrCreatePartyRegistration - Unha solicitude da VEN á VTN para rexistrarse. Contén información sobre as capacidades de VEN.
oadrCreatedPartyRegistration - Resposta a oadrQueryRegistration ou a oadrCreatePartyRegistration. Contén capacidades VTN e información de rexistro necesarias para que o VEN poida interoperar
oadrCancelPartyRististration - Usado por VEN ou VTN para cancelar o rexistro
oadrCanceledPartyRegistration - Resposta a un rexistro oadrCancelParty. Recoñece a recepción da cancelación do rexistro
oadrRequestReregistration - Esta carga útil é utilizada por un VTN nun modelo de intercambio de tracción para sinalizar ao VEN para reiniciar a secuencia de rexistro
oadrResponse - Utilízase como resposta de marcador de posición nalgúns patróns de intercambio de extracción cando se entrega unha resposta de capa de aplicación nunha solicitude de capa de transporte.

Cargas útiles de OadrPoll

oadrPoll – Un mecanismo xenérico de poling para o B profile que devolve a carga útil para calquera outro servizo que sexa novo ou que fose actualizado.
oadrResponse - Utilízase para indicar que non hai cargas útiles novas ou actualizadas dispoñibles

- Glosario de elementos de carga útil do esquema

A continuación móstrase unha lista alfabética de elementos do esquema utilizados nas cargas útiles de OpenADR 2.0. A narración describe o seu uso en canto a OpenADR e o seu uso en cargas útiles. Cando a definición dun elemento cambia en función da carga útil que está contida ou do seu contexto de uso, isto notarase na narrativa. Excluíronse as definicións de carga útil de raíz tal e como se definen no anexo C.

ac - Un valor booleano que indica se o produto eléctrico é corrente alterna
precisión - O número está nas mesmas unidades que a variable de carga útil para un intervalo. Cando está presente con confianza, indica a probable variabilidade da predición. Cando está presente con ReadingType, indica un probable erro de Reading.
aggregatedPnode - Un nodo de prezos agregados é un tipo especializado de nodo de prezos usado para modelar elementos como a zona do sistema, a zona de prezos predeterminada, a zona de prezos personalizada, a área de control, a xeración agregada, a carga participativa agregada, a carga non participativa agregada, o centro de negociación, a zona DCA.
dispoñible - Un obxecto que conteña unha data e hora e duración para un horario de dispoñibilidade de EiOpt
ID de referencia - Identificador único para unha liña de base específica
baselineName - Nome descritivo da liña de base
compoñentes –
confianza - Unha probabilidade estatística de que un punto de datos reportado sexa preciso
createdDateTime - A data e hora na que se creou a carga útil
moeda –
moeda por kW –
moeda por kWh –
moeda por tm –
actual –
Valor actual - O valor payloadFloat do intervalo de eventos que se está executando actualmente.
Unidade personalizada - Utilízase para definir unha unidade de medida personalizada para informes personalizados
data-hora –
dtstart - A hora de inicio da actividade, os datos ou o cambio de estado
duración - Un período de tempo para un evento, reportaxe ou intervalo de tempo dispoñible
duración - A duración da actividade, datos ou estado
eiActivePeriod - Cadros de tempo relevantes para o evento xeral
eiCreatedEvent - Responde a un evento DR con optIn ou optOut
eiEvento -Un obxecto que contén toda a información para un único evento
eiEventBaseline - B profile
eiEventSignal - Un obxecto que contén toda a información dun único sinal nun evento
eiEventSignals - Datos de intervalo para un ou máis sinais de eventos e / ou liñas base
eiMarketContext - Un URI que identifica de xeito único un programa de resposta á demanda
eiReportID - ID de referencia dun informe
eiRequestEvent - Solicita un evento desde unha VTN en modo pull
eiResponse - Indique se a carga útil recibida é aceptable
eiTarget - Identifica os recursos asociados á interface VEN lóxica. Para os eventos, os valores especificados son o destino do evento
endDeviceAsset - Os EndDeviceAssets son o dispositivo ou dispositivos físicos que poden ser medidores ou outro tipo de dispositivos que poden ser de interese
energyApparent - Enerxía aparente, medida en voltiosampantes de horas (VAh)
enerxíaItem –
energyReactive - Enerxía reactiva, voltiosamphoras reactivas (VARh)
energyReal - Enerxía real, vatios horas (Wh)
eventDescriptor - Información sobre o evento
ID do evento - Un valor de identificación que identifica unha instancia de evento DR específica.
eventResponse - Un obxecto que contén respostas VENs a unha solicitude de participación nun evento
eventResponses - respostas optIn ou optOut para eventos recibidos
Estado do evento - O estado actual dun evento (afastado, próximo, activo, etc.)
FeatureCollection / location / Polygon / exterior / LinearRing
frecuencia –
granularidade – Este é o intervalo de tempo entre o sampdatos liderados nunha solicitude de informe.
ID do grupo -Este tipo de destino úsase para eventos, informes e programacións de opcións. O valor normalmente sería asignado pola utilidade durante a inscrición nun programa DR
nome do grupo - Este tipo de destino úsase para eventos, informes e programacións de opcións. O valor normalmente sería asignado pola utilidade durante a inscrición nun programa DR
hercios –
intervalo - Un obxecto que conteña tempo e / ou duración dos datos e un valor accionable no caso dun evento ou datos no caso dun informe
intervalos - Un ou máis intervalos de tempo nos que o evento DR está activo ou están dispoñibles os datos do informe
itemDescription - Unha descrición dunha unidade de medida do informe
itemUnits - A unidade de medida base dun punto de datos do informe
marketContext - Un URI que identifica un programa DR
meterAsset - O MeterAsset é o dispositivo ou dispositivos físicos que desempeñan o papel do medidor
modificationDateTime - Cando se modifica un evento
númeroModificación - Incrementado cada vez que se modifica un evento.
modificationReason - Por que se modificou un evento
mrid - O mRID identifica o dispositivo físico que pode ser un CustomerMeter ou outro tipo de dispositivos finais.
nodo - O nodo é un lugar onde algo cambia (a miúdo de propiedade) ou conecta na rede. Moitos nodos están asociados a contadores, pero non todos o son.
numDataSources –
oadrCapacidade –
oadrActual –
oadrDataQuality –
oadrDeviceClass - Obxectivo de clase de dispositivo: use só endDeviceAsset.
oadrEvent - Un obxecto que contén un evento de resposta á demanda
oadrExtensión –
oadrExtensionName -
oadrExtensions –
oadrHttpPullModel - Un booleano que indica se os VEN queren usar un modelo de intercambio pull
oadrInfo - Un par de valores clave de información de rexistro específica do servizo
oadrKey –
oadrLevelOffset –
oadrLoadControlState –
oadrManualOverride - Se é verdadeiro, anulouse manualmente o control da carga
oadrMáx –
oadrMaxPeriod - Máximo sampperíodo ling
oadrMin –
oadrMinPeriod - Mínimo sampperíodo ling
oadrNormal –
oadrOnChange - Se é verdadeiro, os datos rexistraranse cando cambien, pero sen unha frecuencia superior á especificada por minPeriod.
oadrOnline - Se é verdadeiro, o recurso / activo está en liña, se é falso, fóra de liña.
oadrPayload –
oadrPayloadResourceStatus - Información actual sobre o estado dos recursos
oadrPendingReports - Unha lista de informes periódicos aínda activos
oadrPercentOffset –
oadrProfile – Profile soportado por VEN o VTN
oadrProfileNome - OpenADR profile nome como 2.0a ou 2.0b.
oadrProfiles – OpenADR profiles apoiado pola implementación
oadrInforme -Un obxecto que conteña toda a información para un único informe
oadrReportDescription - Descrición das características do informe ofrecidas polo produtor do informe. Contido nun informe de metadatos
oadrReportOnly - ReportOnlyDeviceFlag
oadrReportPayload - Valores de puntos de datos para informes
oadrRequestedOadrPollFreq - O VEN enviará unha carga útil de oadrPoll ao VTN como máximo unha vez por cada duración especificada por este elemento
oadrResponseRequired - Controla cando se precisa unha resposta optIn / optOut. Pode ser sempre ou nunca
oadrSamplingRate - Samptaxa de ling para datos de tipo telemetría
oadrService –
oadrServiceName - Este tipo de destino úsase para eventos, informes e programacións de opcións. O valor normalmente sería asignado pola utilidade durante a inscrición nun programa DR
oadrServiceSpecificInfo - Información de rexistro específica do servizo
oadrSetPoint –
oadrSignedObject –
oadrTransporte - Un nome de transporte soportado por un VEN ou VTN
oadrTransportAddress - Enderezo raíz usado para comunicarse con outra parte. Debe incluír o porto se é necesario
oadrTransportName - Nome de transporte OpenADR como simpleHttp ou xmpp
oadrTransports - Os transportes OpenADR soportados pola implementación
oadrUpdatedReport - Confirmar a recepción dun informe
oadrUpdateReport - Enviar un informe solicitado previamente
oadrValue –
oadrVenName - Nome VEN. Pode usarse en VTN GUI
oadrXmlSignature - A implementación admite a sinatura XML
optID - Identificador para unha interacción opt
optReason - Valor enumerado polo motivo de optación, como x-schedule
optType - optIn ou optOut dun evento, ou usado para indicar o tipo de programación opt definida no vavailablityObject para o servizo EiOpt
ID da festa - Este tipo de destino úsase para eventos, informes e programacións de opcións. O valor normalmente sería asignado pola utilidade durante a inscrición nun programa DR
payloadFloat - Valor do punto de datos para sinais de eventos ou para informar de valores actuais ou históricos.
pnode - Un nodo de prezos está directamente asociado a un nodo de conectividade. É un lugar de prezos para o que os participantes no mercado presentan as súas ofertas, ofrecen, compran / venden CRR e liquidan.
punto de entrega –
pointOfReceipt –
posList –
powerApparent - Potencia aparente medida en voltiosamperes (VA)
Atributos de potencia
powerItem
powerReactive - Potencia reactiva, medida en voltiosamperes reactivo (VAR)
powerReal - Potencia real medida en vatios (W) ou Joules / segundo (J / s)
prioridade - A prioridade do evento en relación con outros eventos (canto menor sexa a prioridade. Un valor de cero (0) non indica ningunha prioridade, que é a prioridade máis baixa por defecto).
propiedades –
conta de pulsos - Un punto de datos de informes
pulseFactor - kWh por reconto
IDEvento cualificado - Unha identificación única para un evento
readingType - Metadatos sobre as lecturas, como a media ou a derivada
ID de rexistro - Identificador para a transacción de rexistro. Non se inclúe en resposta ao rexistro da consulta a menos que xa estea rexistrado
respostaLímite - O número máximo de eventos que se devolverán nunha carga útil de oadrDistributeEvent
reportBackDuration - Informe de novo co informe actualizado para cada paso desta duración.
reportDataSource - Fontes dos datos deste informe. Exampos inclúen metros ou submetros. Por exampSe un medidor é capaz de proporcionar dous tipos diferentes de medicións, entón cada fluxo de medición identificaríase por separado.
reportInterval - Este é o período global de presentación de informes.
reportName - Nome opcional para un informe.
reportRequestID - Identificador para unha solicitude de informe particular
reportSpecifier - Especifique os puntos de datos desexados nunha instancia de informe concreta
reportSpecifierID - Identificador para unha especificación de informe de metadatos en particular
reportSubject - Obxectivo de clase de dispositivo: use só endDeviceAsset.
reportToFollow - Indica se se devolverá o informe (en forma de UpdateReport) tras a cancelación do informe
tipo de informe - O tipo de informe como o uso ou o prezo
requestID - Un ID usado para combinar unha solicitude e resposta de transacción lóxicas
ID de recurso - Este tipo de destino úsase para eventos, informes e programacións de opcións. O valor normalmente sería asignado pola utilidade durante a inscrición nun programa DR
resposta –
responseCode - Un código de resposta de 3 díxitos
responseDescription - Descrición narrativa do estado da resposta
respostas –
RID - ID de referencia para este punto de datos
Área de servizo - Este tipo de destino úsase para eventos, informes e programacións de opcións. O valor normalmente sería asignado pola utilidade durante a inscrición nun programa DR
serviceDeliveryPoint - Punto lóxico da rede onde a propiedade do servizo cambia de mans. É un dos moitos puntos de servizo dentro dun ServiceLocation, que ofrece servizo de acordo cun acordo de cliente. Utilízase no lugar onde se pode instalar un contador.
serviceLocation - Un Customer ServiceLocation ten un ou máis ServiceDeliveryPoint (s), que á súa vez están relacionados con Medidores. A situación pode ser un punto ou un polígono, dependendo das circunstancias específicas. Para a distribución, ServiceLocation adoita ser a localización da premisa do cliente da utilidade.
ID de sinal - identificador único para un sinal de evento específico
nomeSinal - O nome dun sinal como SIMPLE
signalPayload - Valores de sinal para eventos e liñas base
siScaleCode - Un factor de escala para a unidade de medida base dun informe
especificador de carga útil - Un aberto
máis adiante - Ventá de aleatorización para o inicio do evento
statusDateTime - Data e hora de referencia deste artefacto.
temperatura –
testEvent - Calquera cousa que non sexa falsa indica un evento de proba
texto –
Therm –
tolerancia - Un subobxecto que contén os requisitos de aleatorización para un evento
tolerar - Un obxecto que conteña os requisitos de aleatorización para un evento
transportInterface - A interface de transporte delinea os bordos en cada extremo dun segmento de transporte.
uid - Utilízase como índice para identificar intervalos. Identificador único
valor –
dispoñibilidade - Un horario que reflicte a dispoñibilidade do dispositivo para participar en eventos DR
venID - Un identificador único para un VEN
voltage –
vtnComment - Calquera texto
vtnID - Un identificador único para un VTN
x-ei Notificación - O VEN debería recibir a carga útil do evento DR antes de dtstart menos esta duración.
x-EIRampArriba - Unha duración antes ou despois do inicio do evento durante o cal debería transitar a nave de carga.
x-eiRecovery - Unha duración antes ou despois do tempo de finalización do evento durante o cal debería transitar a nave de carga.

Glosario de valores enumerados

Estado do evento

activo - O evento iniciouse e está activo actualmente.
cancelado - O evento foi cancelado.
completado - O evento completouse.
lonxe - Evento pendente no futuro. A definición exacta do alcance no futuro depende do contexto do mercado, pero normalmente significa ao día seguinte.
preto – Evento pendente nun futuro próximo. A definición exacta de ata que punto está activo o evento pendente no futuro depende do contexto do mercado. .Inicia concorrente co inicio efectivo do evento x-eiRampTempo de arriba. Se x-eiRampUp non está definido para o evento, este estado non se utilizará para o evento.
ningún - Non hai ningún evento pendente

Elementos Unidades

Moeda
- USD - Dólares dos Estados Unidos
- Para moitos enumerar aquí, consulte o esquema
poder real
- J/s - Joule-segundo
- W - Vatios
temperatura
- Celsius –
- fahrenheit –

oadrDataQuality

Sen valor novo: valor anterior usado –
Sen calidade - sen valor –
Calidade deficiente: fallo na comunicación –
Calidade incorrecta: erro de configuración –
Calidade incorrecta: fallo do dispositivo –
Calidade mala: último valor coñecido –
Calidade mala - non específica –
Calidade incorrecta: non está conectado –
Calidade mala - Fóra de servizo –
Calidade deficiente: fallo do sensor –
Calidade boa: anulación local –
Calidade boa - non específica –
Límite de calidade: campo / constante –
Límite de calidade: campo / alto –
Límite de calidade: campo / baixo –
Límite de calidade: campo / non –
Calidade incerta: superáronse as unidades da UE –
Calidade incerta: último valor utilizable –
Calidade incerta - non específica –
Calidade incerta: o sensor non é preciso –
Calidade incerta - Sub Normal –

oadrResponseRequired

sempre - Envía sempre unha resposta por cada evento recibido.
nunca - Nunca respondes.

optReason

Motivos enumerados para optar.

económico –
emerxencia –
debe Correr –
nonParticipando –
outageRunStatus –
overrideStatus –
participando –
x-horario –

oadrTransportName

simpleHttp –
xmpp –

OptType

optIn - Unha indicación de que o VEN participará nun evento ou, no caso do servizo EiOpt, un tipo de horario que indique que o recurso estará dispoñible
opt-out - Unha indicación de que o VEN non participará nun evento ou no caso do servizo EiOpt un tipo de horario que indique que o recurso non estará dispoñible

lecturaTipo

Asignado - O contador abrangue varios [recursos] e o uso infírese mediante algún tipo de cálculo de datos pro.
Contrato - Indica que a lectura é pro forma, é dicir, que se informa ás tarifas acordadas
Derivado - O uso infírese a través do coñecemento do tempo de execución, funcionamento normal, etc.
Lectura directa - A lectura lese desde un dispositivo que aumenta monotónicamente e o uso debe calcularse a partir de pares de lecturas de inicio e parada.
Estimado - Utilízase cando unha lectura está ausente nunha serie na que están presentes a maioría das lecturas.
Híbrido - Se se agrega, refírese a diferentes tipos de lectura no número agregado.
Media - A lectura é o valor medio durante o período indicado en Granularidade
Rede - Medidor ou [recurso] prepara o seu propio cálculo do uso total ao longo do tempo.
Pico - A lectura é o valor máximo (máximo) durante o período indicado en granularidade. Para algunhas medidas, pode ter máis sentido como o valor máis baixo. Pode non ser coherente coas lecturas agregadas. Válido só para as Bases de Ítems de caudal, é dicir, a enerxía non a enerxía.
Proxectado - Indica que a lectura está no futuro e aínda non se mediu.
Resumido - Varios metros xuntos proporcionan a lectura deste [recurso]. Isto é específicamente diferente ao agregado, que se refire a varios [recursos] na mesma carga útil. Vexa tamén Híbrido.
x-notAplicable - Non aplicable
x-RMS - Praza media raíz

nome do informe

HISTORY_GREENBUTTON - Un informe que contén datos de botón verde nunha estrutura de esquema de alimentación de átomos
HISTORIA_USO - Un informe que conteña datos de uso histórico da enerxía
BOTÓN METADATA_HISTORY_GREENBUTTON - Un informe de metadatos que define as capacidades de informes para os informes HISTORY_GREENBUTTON
METADATA_HISTORY_USAGE - Un informe de metadatos que define as capacidades de informes para os informes HISTORY_USAGE
METADATA_TELEMETRY_STATUS - Un informe de metadatos que define as capacidades de informes para os informes TELEMETRY_STATUS
METADATA_TELEMETRY_USAGE - Un informe de metadatos que define as capacidades de informes para os informes TELEMETRY_USAGE
TELEMETRY_STATUS - Un informe que contén información sobre o estado dos recursos en tempo real, como o estado en liña
TELEMETRÍA_USAXE - Un informe que contén información de uso de enerxía en tempo real

tipo de informe

Un valor enumerado que proporciona o tipo de informe que se proporciona.

Almacenamento Enerxético dispoñible - Capacidade dispoñible para máis almacenamento de enerxía, quizais para chegar ao almacenamento de enerxía obxectivo
demanda media - Uso medio durante a duración indicada pola granularidade. Vexa a demanda de máis información.
uso medio - Uso medio durante a duración indicada pola granularidade. Consulte o uso para obter máis información.
liña de base - Pode ser demanda ou uso, como indica ItemBase. Indica cal sería a [medición] se non fose polo evento ou a regulación. O informe ten o formato Baseline.
deltaDemand - Cambio na demanda en comparación coa liña de base. Vexa a demanda de máis información
deltaSetPoint - Cambios no punto de referencia respecto á programación anterior.
uso delta - Cambio no uso en comparación coa liña de base. Consulte o uso para obter máis información
demanda - O informe indica unha cantidade de unidades (denominadas en ItemBase ou no produto EMIX). O tipo de carga útil é Cantidade. Un ItemBase típico é o poder real.
desviación - Diferenza entre algunha instrución e estado real.
downRegulationCapacityDispoñible - Capacidade de regulación descendente dispoñible para o envío, expresada en EMIX Real Power. A carga útil sempre se expresa como Cantidade positiva.
nivel - Nivel sinxelo do mercado en cada intervalo.
Estado operativo - Estado xeneralizado dun recurso como acendido / apagado, ocupación do edificio, etc. Non hai ningunha ItemBase relevante. Require unha extensión de carga útil específica da aplicación.
por cento Demanda – Porcentaxetage de demanda
por cento Uso – Porcentaxetage de uso
factor de potencia - Factor de potencia para o recurso
prezo - Prezo por ItemBase en cada intervalo
lectura - O informe indica unha lectura, como a dun metro. As lecturas son momentos nos que os cambios de tempo poden calcularse a partir da diferenza entre lecturas sucesivas. O tipo de carga útil é flotante
regulaciónSetpoint - Punto de referencia da regulación como se indica como parte dos servizos de regulación
punto de set - O informe indica o importe (denominado en ItemBase ou no produto EMIX) configurado actualmente. Pode ser unha confirmación / devolución do valor de control do punto de referencia enviado desde a VTN. O tipo de carga útil é Cantidade. Un ItemBase típico é o poder real.
Enerxía almacenada - A enerxía almacenada exprésase como enerxía real e a carga útil exprésase como unha cantidade.
targetEnergyStorage - A enerxía obxectivo exprésase como enerxía real e a carga útil exprésase como unha cantidade.
upRegulationCapacityDispoñible - Up Capacidade de regulación dispoñible para o envío, expresada en EMIX Real Power. A carga útil sempre se expresa como Cantidade positiva.
uso - O informe indica unha cantidade de unidades (denominadas en ItemBase ou no produto EMIX) durante un período. O tipo de carga útil é Cantidade. Un ItemBase típico é RealEnergy
x-resourceStatus – Porcentaxetage de demanda

código de escala

p - Pico 10 ** - 12
n - Nano 10 ** - 9
micro - Micro 10 ** - 6
m - Milli 10 ** - 3
c - Centi 10 ** - 2
d - Deci 10 ** - 1
k - Kilo 10 ** 3
M - Mega 10 ** 6
G - Giga 10 ** 9
T - Tera 10 ** 12
ningún - Escala nativa

nomeSinal

BID_ENERGY - Esta é a cantidade de enerxía dun recurso que se puxo nun programa
BID_LOAD - Esta é a cantidade de carga que un recurso puxo nun programa
BID_PRICE - Este é o prezo que licitou o recurso
CHARGE_STATE - Estado do recurso de almacenamento de enerxía
DEMAND_CHARGE - Este é o cargo por demanda
PREZO_ELECTRICIDADE - Este é o custo da electricidade
PREZO_ENERXÍA - Este é o custo da enerxía
LOAD_CONTROL -Configura a saída de carga en valores relativos
LOAD_DISPATCH - Úsase para enviar carga
sinxelo – depreciado – para compatibilidade con versións anteriores con A profile
SIMPLE - Niveis simples (compatible con OpenADR 2.0a)

tipo de sinal

Un valor enumerado que describe o tipo de sinal como o nivel ou o prezo

delta - O sinal indica a cantidade que se cambiaría do que se usaría sen o sinal.
nivel - O sinal indica un nivel de programa.
multiplicarr - O sinal indica un multiplicador aplicado á taxa de entrega ou uso actual do que se usaría sen o sinal.
prezo - O sinal indica o prezo.
prezo Multiplicarr - O sinal indica o multiplicador de prezos. O prezo ampliado é o valor do prezo calculado multiplicado polo número de unidades.
prezoRelativo - O sinal indica o prezo relativo.
punto de set - O sinal indica unha cantidade obxectivo de unidades.
x-loadControlCapacity – Esta é unha instrución para que o controlador de carga funcione a un nivel que é un porcentaxetage da súa capacidade máxima de consumo de carga. Isto pódese asignar a controladores de carga específicos para facer cousas como o ciclo de traballo. Teña en conta que 1.0 refírese ao 100 % de consumo. No caso de dispositivos simples do tipo ON/OFF entón 0 = OFF e 1 = ON.
x-loadControlLevelOffset - Niveis de números enteiros discretos relativos ás operacións normais onde 0 é operacións normais.
x-loadControlPercentOffset – Porcentaxetage cambio das operacións normais de control de carga.
x-loadControlSetpoint - Puntos de consigna do controlador de carga.

– OpenADR A e B Profile Diferenzas

O único servizo compatible con A profile é o servizo EiEvent. O obxecto EiEvent simplifícase no A profile coas seguintes limitacións:

Só se permite un sinal por evento e ese sinal debe ser o coñecido sinal OpenADR SIMPLE.
Hai unha segmentación de eventos limitada só con venID, groupID, resourceID e partyID. (EiEvent: eiTarget).
Non se admite a orientación a nivel de sinal con clases de dispositivos (eiEventSignal: eiTarget: endDeviceAsset).
Non se admiten as liñas de base (eiEvent: eiEventSignals: eiEventBaseline).
modificationDateTime e modificationReason non son compatibles.
O punto final URL para HTTP simple en 2.0b é:
- https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>

Algúns elementos de carga útil que se requirían no A profile agora son opcionais no B profile, incluíndo:

Valor actual

- Certificados de seguridade OpenADR

As regras de conformidade OpenADR requiren o seguinte:

A versión 1.2 de TLS úsase para o intercambio de certificados X.509
As VTN deben ter certificados SHA256 ECC e RSA
Os VEN poden soportar certificados SHA256 ECC e RSA e poden admitir ambos
Tanto as VTN como as VEN deben estar configuradas para solicitar certificados de cliente se van desempeñar o papel dun servidor de transporte (é dicir, responder ás solicitudes da outra parte)
Tanto as VTN como as VEN deben proporcionar un certificado de cliente cando a outra parte o solicite como parte do proceso de negociación de TLS.

Os certificados proporcionados por NetworkFX serán específicos para RSA ou ECC. A creación destes certificados pode producirse como resultado de cubrir formularios no NetworkFX web sitio para solicitar certificados de proba ou pode ser o resultado de solicitar certificados de produción mediante unha solicitude de sinatura de certificado (CSR). Independentemente do método, o seguinte fileproporcionaranse s (exampmóstranse os ficheiros):

Certificado raíz
Certificado de raíz intermedio
Certificado do dispositivo
Chave privada

En xeral, a clave privada úsase para cifrar as cargas útiles enviadas por un VEN ou VTN. O certificado de dispositivo é un conxunto de información de identificación única sobre un VEN ou VTN que foi creado por unha autoridade de certificación e cifrado mediante a chave privada. A raíz e o intermedio files úsanse para descifrar o certificado do dispositivo e validar que o certificado procede dunha autoridade de confianza.

Nun ambiente Java que utiliza JSSE, hai dúas tendas de certificados. Un chámase Trust Store e úsase para ter o certificado raíz. O segundo chámase almacén de claves e úsase para almacenar unha cadea de certificados que consiste no certificado intermedio do certificado do dispositivo, así como a clave privada

Ten en conta que cando se usa un transporte XMPP, o VEN está a comunicarse co servidor XMPP e NON directamente co VTN. Polo tanto, a configuración dos certificados no servidor XMPP DEBE ser equivalente á dun VTN. A comunicación entre a propia VTN e o servidor XMPP é transparente para a VEN e é esencialmente unha ligazón privada. Non obstante, a maioría dos vendedores empregaron un conxunto de certificados VEN na VTN cando se comunicaban co servidor XMPP.

Se está a usar OpenFire como servidor XMPP, hai outra restrición que debe ter en conta. OpenFire require que o nome CN empregado nos certificados do dispositivo cliente coincida co nome de usuario XMPP dos dispositivos configurado no servidor XMPP. Isto pode producir algúns nomes de clientes estraños xa que se usa un enderezo MAC como nome CN nos certificados VEN (parte dos Requisitos de seguridade de OpenADR)

Finalmente, a maioría dos VEN e VTN cando desempeñan o papel de cliente de transporte intentarán validar que o campo CN do certificado proporcionado polo servidor de transporte ten un nome CN que coincida co nome de host da entidade que proporcionou o certificado. Esta pode ser outra fonte de problemas de interoperabilidade cando se intercambian certificados. A verificación de nome de host normalmente pódese desactivar por programación para illar este tipo de problemas.

Guía do programa de resposta á demanda OpenADR 2.0 - Descargar [optimizado]
Guía do programa de resposta á demanda OpenADR 2.0 - Descargar

Referencias

Manual de usuario

Introdución

Referencias

Termos e definicións

Abreviaturas

Tipos de programas de resposta á demanda

Escenarios de implantación

Directo 1

Directo 2

Directo 3

Directo 4

Facilitador 1

Agregador 1

Escenario de implantación e asignación de programas DR

Seleccionando un modelo de programa DR

Modelos do programa de resposta á demanda

Programa de prezos máximos críticos (CPP)

Características do programa CPP DR

Características de OpenADR para programas CPP

Programa de licitación de capacidade

Características do programa DR de licitación de capacidade

Características de OpenADR para programas de licitación de capacidade

Programa de termostatos residenciais

Características do programa de termostato residencial DR

Características de OpenADR para programas de termostatos residenciais

Envío rápido de DR

Características do programa de envío rápido DR

Características de OpenADR para programas de licitación de capacidade

Programa de tempo de uso (TOU) de vehículos eléctricos residenciais (EV)

Características do programa EV TOU residencial

Características de OpenADR para programas residenciais EV TOU

Programa de prezos en tempo real de vehículos eléctricos da estación pública (EV)

Características do programa RTP de estación pública EV

Características de OpenADR para programas RTP de estación pública EV

Programa DR de Recursos Enerxéticos Distribuídos (DER)

Características do programa de Recursos Enerxéticos Distribuídos (DER)

Características de OpenADR para recursos enerxéticos distribuídos (DER)

Referencias

Deixa un comentario

Cancelar resposta