Comparaison des protocoles de communication de réponse à la

 COMPARAISON DES PROTOCOLES DE COMMUNICATION DE RÉPONSE À LA DEMANDE Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM Mars 2011 COMPARAISON DES PROTOCOLES DE COMMUNICATION DE RÉPONSE À LA DEMANDE Préparé par : Scott Coe, Ph.D., vice‐président UISOL UNE COMPAGNIE ALSTOM Présenté à : CanmetÉNERGIE, Centre de recherches de Varennes Date Mars 2011
Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM Mars 2011 CITATION Scott Coe; Comparaison des protocoles de communication de réponse à la demande, CanmetÉNERGIE, Rapport 2011‐061 (RP‐TEC) 411‐DERCOM , 16 pages AVIS Le présent rapport est diffusé uniquement à titre documentaire. Il ne reflète pas nécessairement l’opinion du Gouvernement du Canada et ne constitue pas une recommandation à l’égard d’aucun produit commercial ni d’aucune personne. Ni le Gouvernement du Canada, ni ses ministres, agents, employés ou mandataires ne donnent de garantie à l’égard du présent rapport et n’assument aucune responsabilité liée à son utilisation. AUTEURS Le Dr Scott Coe, vice‐président d’UISOL, possède 15 ans d’expérience dans les marchés de l’électricité en gros, dans des domaines allant de la conception technique à l’amélioration des processus. Depuis plusieurs années, M. Coe met l’accent sur la mise en œuvre de solutions de gestion de la réponse à la demande et sur l’avancement des normes liées à la réponse à la demande. De manière plus particulière, M. Coe aide le Conseil des EIR/OTR (ISO/RTO Council – IRC) à élaborer des normes pour diverses initiatives, y compris des normes de mesure et de vérification de la réponse à la demande au North American Energy Standards Board (NAESB) et des normes de communication entre applications au Conseil international des grands réseaux électriques (CIGRÉ). M. Coe a passé du temps chez de nombreux exploitants indépendants de réseau (EIR) et de nombreuses organisations de transport régionales (OTR) au fil des ans, ayant travaillé à des projets avec l’EIR New England, PJM, l’EIR de Californie, l’EIR du Midwest et l’Alberta Electricity System Operator. M. Coe siège au NAESB et dirige le laboratoire d’intégration de la réponse à la demande d’UISOL. M. Coe est titulaire d’une maîtrise ès sciences en génie physique du Rensselaer Polytechnic Institute de même qu’un doctorat en physique de l’Université de Yale. Rapport Technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ i ‐ Mars 2011 TABLE DES MATIÈRES 1
Survol d’OpenADR .................................................................................................................................. 2
1.1
1.2
2
Survol des protocoles PAP09 du NIST .................................................................................................... 4
2.1
2.2
2.3
2.4
3
Contexte ......................................................................................................................................................4
Normes de réponse à la demande en gros ..................................................................................................4
Normes de réponse à la demande au détail................................................................................................5
Rapprochement de l’électricité en gros et au détail ...................................................................................5
Comparaison d’OpenADR et des normes de détail du NAESB ............................................................... 7
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
4
Contexte ......................................................................................................................................................2
Le point central d’OpenADR ........................................................................................................................2
Introduction .................................................................................................................................................7
Traitement de l’événement .........................................................................................................................7
Gérer les clients ...........................................................................................................................................8
Soumission...................................................................................................................................................8
Fonctions de niveau plus élevé d’OpenADR ................................................................................................8
Mesure et vérification ...............................................................................................................................10
Résumé des opérations entre le participant et le client............................................................................11
Interface entre le service public et l’EIR ....................................................................................................12
Survol des autres acteurs en matière de signalisation en RD .............................................................. 13
4.1
4.2
Interopération en énergie de l’Oasis .........................................................................................................13
L’OpenADR Alliance ...................................................................................................................................14
5 Conclusions........................................................................................................................................... 15
ANNEXE A Diagramme des relations entre les entités de RD..................................................................... 16
Rapport Technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ ii ‐ Mars 2011 ORGANISATION DU DOCUMENT Le présent document est divisé en fonction des sections suivantes : 1. Survol d’OpenADR 2. Survol des protocoles PAP09 du NIST 3. Comparaison des versions commerciales d’OpenADR et du NAESB. 4. Survol des autres acteurs en matière de signalisation en réponse à la demande (RD) La Section 3 comprend la majorité des résultats d’analyse, avec une comparaison fonction par fonction des deux normes pertinentes présentées aux sections 1 et 2. La Section 4 fournit des renseignements supplémentaires sur certains travaux récents et en cours qui ajoutent d’autres couches importantes à l’image d’ensemble. Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 1 ‐ Mars 2011 1
SURVOL D’OPENADR 1.1
Contexte La recherche sur OpenADR a commencé en 2002, financée par la California Energy Commission. Appelée à l’origine Automated Demand Response (AutoDR), la spécification a été rebaptisée OpenADR (Open Automated Demand Response) lorsqu’elle est devenue publiquement utilisée. Le Lawrence Berkeley National Laboratory (LBNL) a publié la spécification OpenADR version 1.0 sur son site Web en 2009. 1.2
Le point central d’OpenADR Le protocole OpenADR est centré sur le serveur d’automatisation de la réponse à la demande (Demand Response Automation Server – DRAS). D’un côté du DRAS se trouve le service public : définir les programmes, vérifier la capacité, lancer des événements, et ainsi de suite. De l’autre côté se trouve le participant/client : opter d’adhérer aux programmes ou de s’en retirer, recueillir des renseignements sur les événements, et ainsi de suite. Service
Public
OpenADR
Serveur
d’automatisation de
la réponse à la
demande
OpenADR
Participant
&
Client
Figure 1 : Voie de communication d’OpenADR Chaque fonction d’OpenADR est classée d’un côté du processus : Service public ou Participant/client. Dans nombre de cas, il existe des fonctions connexes des deux côtés; par exemple, un client peut présenter une soumission (qui fait partie de la catégorie « Automatiser les soumissions ») alors que le service public peut extraire toutes les soumissions après la clôture de la période de soumission (qui fait également partie de la catégorie « Automatiser les soumissions »). Catégorie Catégorie Service public Participant/Client Configurer le DRAS Configurer le DRAS Surveiller les activités liées au DRAS Surveiller les activités liées au DRAS Automatiser les soumissions Automatiser les soumissions Traiter les événements de RD Recevoir les renseignements sur les événements de RD ‐ Option d’adhésion ou de retrait à l’égard des événements de RD ‐ Aviser l’exploitant ‐ Présenter une rétroaction Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 2 ‐ Mars 2011 À titre de spécification de messagerie, OpenADR n’impose aucun détail sur la mise en œuvre ou le rendement du DRAS même. Par exemple, il n’y a aucune directive en ce qui concerne les écrans qui peuvent exister du côté du client ou du service public. Et il n’existe aucune exigence ni aucun indicateur sur la manière dont les données sont stockées à l’intérieur du DRAS. Cela laisse le champ libre aux développeurs de logiciels pour créer leur propre version de différentes mises en œuvre du DRAS, la seule exigence clé étant que les messages appropriés d’OpenADR soient communiqués convenablement. On doit remarquer que les mises en œuvre de DRAS acceptent aussi souvent un nombre d’interfaces limité. Selon la conception du programme de service public, certains messages ne seront pas nécessaires. Les fonctions les plus utilisées sont les suivantes : 1. Créer/modifier/supprimer/extraire le client du DRAS 2. Extraire les renseignements sur l’événement de RD 3. Créer/supprimer/extraire l’état de l’option de retrait 4. Fournir/extraire une rétroaction sur l’événement En fait, en présumant que les renseignements sur le participant sont recueillis par d’autres moyens, presque tout programme de réponse à la demande pourrait être automatisé au moyen de ce simple sous‐ensemble de fonctions. Et même avec ce sous‐ensemble de fonctions souvent utilisées, Les troisième et quatrième fonctions peuvent également être considérées comme facultatives. La réussite d’OpenADR peut être perçue comme un sous‐produit de cette simplicité. Par exemple, des membres du laboratoire d’intégration de la réponse à la demande d’UISOL ont fait la démonstration d’une connectivité de base avec OpenADR après seulement quelques jours de développement et de mise à l’essai pour charger le nouveau logiciel sur un appareil de contrôle Internet et interroger le DRAS pour obtenir des renseignements sur l’événement. En règle générale, la plupart des mises en œuvre d’OpenADR utilisent l’interrogation plutôt que de pousser les événements sur l’appareil pour éliminer les problèmes de sécurité Internet du côté du client. Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 3 ‐ Mars 2011 2
SURVOL DES PROTOCOLES PAP09 DU NIST 2.1
Contexte Parallèlement aux efforts d’élaboration d’OpenADR, le gouvernement des États‐Unis a lancé un projet connexe, mais d’une portée beaucoup plus large, de corrélation du développement d’un accord de l’industrie sur les normes d’interopérabilité des réseaux intelligents. Tel qu’indiqué dans l’Energy Independence and Security Act (EISA) de 2007, le National Institute of Standards and Technology (NIST) a été désigné « premier responsable de la coordination de l’élaboration d’un cadre comprenant des protocoles et des normes modèles de gestion de l’information pour réaliser l’interopérabilité des dispositifs et des systèmes de réseaux intelligents » [traduction]. Au milieu de 2010, le NIST avait préparé 15 plans d’action prioritaires (Priority Action Plans – PAP) liés à différents aspects du réseau intelligent, dont le Plan d’action prioritaire #9 (PAP09), intitulé « signaux standards de RD et de RED », est le plus pertinent pour la communauté de la réponse à la demande. Pour exécuter le mandat du PAP09, le NIST a fait appel au North American Energy Standards Board (NAESB) pour faciliter les discussions au sein de l’industrie et pour documenter les exigences en matière de protocoles de communication de la réponse à la demande. Le NAESB est divisé en quatre quadrants, soit l’électricité en gros (QEG), l’électricité au détail (QED), le gaz en gros (QGG) et le gaz au détail (QGD) – les deux premiers quadrants ayant des mesures à prendre dans leur plan annuel touchant la satisfaction des exigences liées au protocole de communication de la RD. 2.2
Normes de réponse à la demande en gros Même si les groupes de l’électricité en gros et de l’électricité au détail du NAESB ont travaillé en étroite collaboration, les points de départ des deux normes provenaient de perspectives très différentes. Les normes QEG étaient fondées en grande partie sur les travaux présentés par l’ISO/RTO Council (IRC). D’un point de vue canadien, l’exploitant indépendant de système électrique de l’Ontario (Ontario Independent Electricity System Operator – IESO), l’Alberta Electric System Operator (AESO) et l’Exploitant de réseau du Nouveau‐Brunswick (ERNB) ont tous contribué. Les normes ratifiées sont disponibles sans frais pour les membres du NAESB ou moyennant un frais pour les parties intéressées. 1 Les dix Exploitants Indépendants de Réseaux (EIR) et les Organisations de Transport Régionales (OTR) d’Amérique du Nord utilisent divers systèmes et diverses technologies pour communiquer les signaux de réponse à la demande, allant de protocoles internet à des réseaux spécialisés communiquant par DNP3. Les normes QEG du NAESB renferment des exigences pour tous les flux de renseignements, de l’inscription à l’évaluation du rendement des ressources de la demande, y compris le déploiement, soit 33 échanges au total. Les EIR membres ont mis au point un cadre souple destiné à couvrir les variations 1
La version provisoire est disponible à l’adresse http://www.naesb.org/pdf4/weq_2010_ap_6c_rec.doc Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 4 ‐ Mars 2011 locales dans les règles du marché, tout en normalisant les charges de renseignement dans ces échanges au fil du temps. 2.3
Normes de réponse à la demande au détail Comme le processus QEG, les membres du QED ont apporté différentes idées jusqu’à ce qu’un ensemble de normes soit finalement ratifié pour l’électricité au détail. Alors que le groupe de l’électricité en gros a choisi de modeler le processus fonctionnel et de cerner les interactions entre les « acteurs », le groupe de l’électricité au détail a choisi de documenter des cas d’utilisation au moyen du langage de modélisation unifié (Unified Modeling Language – UML), cas qui ont été divisés en cinq catégories majeures : 1. Administrer le programme de RD 2. Administrer la RD du client 3. Administrer la ressource de RD 4. Exécuter l’événement de RD 5. Afficher la gestion de l’événement de RD Encore une fois, les normes finales sont disponibles gratuitement pour les membres ou moyennant des frais pour ceux qui ne sont pas membres. 2 2.4
Rapprochement de l’électricité en gros et au détail Une des principales différences entre les approches de l’électricité en gros et de l’électricité au détail est le « niveau » des ressources. Habituellement, les exploitants du marché de gros n’utilisent que des ressources ayant une capacité de réduction minimale de 100 kW. Toutefois, les protocoles de détail mettent souvent l’accent sur des bâtiments ou des foyers particuliers, et même des appareils particuliers de l’autre côté du compteur. D’un point de vue abstrait, on peut traiter de la même façon les rapports avec les ressources de toute taille, par exemple demander à une ressource de se réduire à la quantité offerte; toutefois, les détails relatifs à l’adhésion, à la qualification, à la capacité d’offre et à la mesure du rendement peuvent être très différents. Pour cette raison, une des premières réalisations du groupe conjoint en gros‐au détail a été de bâtir un modèle d’objet capable de traiter différents niveaux de réponse à la demande. En particulier, il y a les Ressources (qui représentent les entités modulables (dispachable) au niveau du gros, le plus souvent sous forme groupée), les Emplacements de service (qui représentent les bâtiments matériels qui exécutent la réponse à la demande – parfois appelés Installations) et les Points de prestation de service (qui représentent tout objet dans l’Installation capable de réduire la consommation – parfois appelés Appareils terminaux). Cette compréhension 2
La version provisoire est disponible à l’adresse http://www.naesb.org/pdf4/retail_2010_ap_9c_rec_101510.doc Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 5 ‐ Mars 2011 commune, illustrée sous forme de diagramme de relation entre les entités, est incluse en annexe dans chaque document PAP09 du NAESB (voir l’annexe A : Diagramme des relations entre les entités de RD) Dans les mises en œuvre les plus générales des programmes de réponse à la demande, le diagramme des relations entre les entités est réduit à un modèle plus petit, comme le montre le diagramme suivant : Rôles des Participants
Objets de ressource
Objects Auxiliaires
Ressource
Zone
Fournisseur de service (FS)
Entité d’ordonnancement (EO)
Entité d’acheminement désignée (EAD)
Fournisseur de service Nœud‐P
de transmission ou de distribution (FSTD)
Emplacement de Service
Entité de service de charge (ESC)
Mesure
Point de prestation de service
Point de prestation de service
Figure 2 : Modèle des relations entre les entités du NAESB (cas simple) Après la ratification des documents énonçant les exigences du QEG et du QED, le groupe de travail s’est lancé dans une étape d’exigences plus détaillées concernant les données. À cette étape du processus, les groupes de l’électricité en gros et de l’électricité au détail avaient rapproché les processus et alignés leurs modèles et l’équipe a pu livrer un ensemble d’exigences commun. Le produit final est un document qui couvre les 290 éléments de données nécessaires pour bâtir les 33 flux de renseignements du QEG et appuyer les 31 cas d’utilisation du QED, avec des indicateurs d’applicabilité aux marchés de gros et de détail pour chaque élément. 3 3
La version provisoire est disponible à l’adresse http://www.naesb.org/pdf4/weq_2010_ap6_rec_101510.doc Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 6 ‐ Mars 2011 3
COMPARAISON D’OPENADR ET DES NORMES DE DÉTAIL DU NAESB 3.1
Introduction Pour les services publics qui commencent un programme de réponse à la demande et qui souhaitent adopter un protocole de communication constituant la norme de l’industrie, l’une des principales décisions à prendre est de choisir entre la norme de fait qu’est OpenADR, ayant de multiples mises en œuvre réussies à son actif, et les normes QED PAP09 du NAESB, jouissant d’une plus grande visibilité mais ne possédant pas d’historique de mise en œuvre dans le monde réel. On doit d’abord remarquer que les normes QED PAP09 du NAESB contiennent un ensemble de pratiques et d’exigences fonctionnelles. Si détaillés que soient les documents, les normes du NAESB n’offrent ni un modèle de renseignements complet, ni des profils de message pouvant être mis en œuvre en pratique. Cela s’applique également aux QEG. Le Comité technique d’interopération en énergie de l’Organization for the Advancement of Structured Information Standards (OASIS) bâtit, aussi bien pour les QED que les QEG, un modèle et les profils afférents en fonction de ces exigences. 3.2
Traitement de l’événement Le message clé dans OpenADR pour communiquer les détails d’un déploiement de réponse à la demande est Extraire les renseignements sur l’événement de RD en configuration d’interrogation (ou Envoyer les renseignements sur l’événement de RD en configuration de diffusion). Le concept parallèle dans les exigences du NAESB est Exécuter/mettre à jour/annuler l’événement de RD. Dans les exigences du NAESB, quatre cas d’utilisation doivent être supportés : 1. Notification d’avance (pour les transferts de renseignements préalables à l’événement) 2. Déploiement dynamique axé sur le prix (appelé « Exécution de la RD – établissement du prix en temps réel (EPTR) ») 3. Déploiement axé sur la notification (appelé « Exécution de la RD – Axé sur la notification ») 4. Contrôle Direct de Charge(CDC) Dans OpenADR, la confirmation du client du DRAS est communiquée au moyen de la fonction Fournir/extraire une rétroaction sur l’événement de RD. Le parallèle dans les exigences du NAESB est la fonction Surveiller l’événement de RD (Actif de RD) ou la fonction Surveiller l’événement de RD (Ressource de RD), selon le « niveau » de ressource de demande concerné. Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 7 ‐ Mars 2011 3.3
Gérer les clients Avant de pouvoir communiquer un événement, le client lui‐même doit toutefois être inscrit. Dans OpenADR, on le fait au moyen des fonctions Créer/extraire/modifier/supprimer le client du DRAS. Les fonctions parallèles dans les exigences du NAESB sont Inscrire/mettre à jour/enlever l’actif de RD et Inscrire/mettre à jour/enlever la ressource de RD, encore une fois en fonction du « niveau » de ressource de demande concerné. OpenADR prévoit également l’inscription des participants au moyen de la fonction Extraire/modifier les comptes de participant, ce que l’on estime être à l’extérieur de la portée du groupe de travail du NAESB. Une des fonctions couramment utilisées dans OpenADR est la fonction Créer/extraire/supprimer l’état de l’option de retrait, utilisée par le participant pour exclure temporairement un client de la participation à un événement de réponse à la demande. Même si cette fonction n’est pas supportée de manière explicite dans les exigences du NAESB à titre de fonction autonome, la variable Statut de l’engagement de l’offre des fonctions d’inscription peut être activée ou désactivée pour obtenir le même effet. 3.4
Soumission La soumission automatisée est une composante importante d’OpenADR. Les fonctions Fournir/extraire une soumission sont utilisées pour établir de manière dynamique le niveau auquel le client du DRAS devient économique. On peut également employer des soumissions permanentes au moyen des fonctions Fournir/extraire/supprimer une soumission permanente. Les exigences du NAESB utilisent elles aussi des soumissions, mais sous une forme quelque peu différente, axée davantage sur un marché de type « vente aux enchères » plutôt que sur le concept du « prix seuil fixé par le client » employé dans OpenADR. Il y a deux fonctions, l’une pour fournir des services de réponse à la demande (Soumission d’offre de RD) et l’autre pour obtenir des services de réponse à la demande (Soumission d’achat de RD). C’est le côté offre de la vente aux enchères qui correspond le mieux à OpenADR, mais sans le concept de soumission permanente. 3.5
Fonctions de niveau plus élevé d’OpenADR Une autre caractéristique d’OpenADR est la capacité de saisir des contraintes liées au programme, par exemple la durée maximale d’un événement, les dates ou les heures d’interruption et le nombre maximal de répétitions consécutives d’un événement. Les contraintes sont propres à un programme donné et peuvent être fixées pour des clients individuels du DRAS ou au niveau du participant, c.‐à‐d. pour tous les clients du DRAS d’un participant donné. Les fonctions connexes suivantes ne sont pas incluses dans les exigences du NAESB : Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 8 ‐ Mars 2011 Gérer les contraintes de programme 
Fixer/extraire/supprimer des contraintes de programme pour le participant 
Fixer/extraire/supprimer des contraintes de programme pour le client du DRAS OpenADR offre la possibilité de gérer les calendriers de réponse. Les calendriers de réponse sont des collections de conditions pouvant être utilisées pour influer sur un client de DRAS donné, c.‐à‐d. changer son statut de réponse en fonction de variables simples comme le prix dynamique par rapport à une valeur de soumission ou d’offre. Chaque statut opérationnel doit être défini dans le programme, p. ex. Délestage fort/moyen/normal, et peut être déterminé en interrogeant le DRAS afin d’obtenir des renseignements sur le programme. Les fonctions connexes suivantes ne sont pas incluses dans les exigences du NAESB : Gérer les calendriers de réponse 
Extraire les renseignements sur le programme 
Créer/extraire/supprimer un calendrier de réponse Le DRAS, au moyen d’OpenADR, peut interroger tout client au sujet de son statut, ses fichiers journaux et ses alertes. Les fonctions connexes suivantes ne sont pas incluses dans les exigences du NAESB : Surveiller les activités du DRAS 
Extraire le statut des communications du client du DRAS 
Extraire les transactions du DRAS 
Extraire les alertes des clients du DRAS OpenADR permet également la mise à l’essai du client du DRAS. On utilise d’abord une fonction de mode d’essai pour activer ou désactiver le mode correct du client du DRAS, puis on peut utiliser une fonction séparée pour forcer le client à entrer dans un état de réponse précis. En mode d’essai, les commandes normales de réponse à la demande sont ignorées. Les fonctions connexes suivantes ne sont pas incluses dans les exigences du NAESB : Installation et mise à l’essai 
Activer le mode d’essai 
Déterminer/extraire le statut de mode d’essai Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 9 ‐ Mars 2011 3.6
Mesure et vérification Mesure et vérification, le processus consistant à comparer les données de mesure recueillies pendant un événement soit aux niveaux avant l’événement, soit aux schémas d’utilisation historiques, est couvert dans les exigences du NAESB. Du point de vue des communications, les fonctions comprennent la présentation des renseignements sur les mesures et la réception des renseignements sur les paiements. Aucun traitement des données après l’événement n’est inclus dans OpenADR, mais les exigences du NAESB comprennent des cas d’utilisation définis, l’un pour l’interaction conventionnelle entre le service public et le client (appelé « Pas de concurrence au détail ») et l’autre avec une concurrence au détail (appelé « Concurrence au détail »). La différence logique est l’insertion d’une entité de service de charge entre le participant et le service public dans le cas de la concurrence au détail. Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 10 ‐ Mars 2011 3.7
Résumé des opérations entre le participant et le client Le tableau suivant résume le mappage entre les fonctions d’OpenADR et de l’exigence PAP09 QED du NAESB liées aux opérations dans l’interface participant/client : Opérations participant/client Fonction OpenADR PAP09 QED du NAESB Extraire/envoyer les renseignements sur l'événement Exécuter/mettre à jour/annuler l'événement de de RD RD Traiter l'événement Gérer les clients Fournir/extraire une rétroaction sur l'événement
Surveiller l'événement de RD (Actif/ressource de RD) Créer/extraire/modifier/supprimer le client du DRAS
Inscrire/mettre à jour/enlever l'actif/la ressource de RD Créer/extraire/supprimer l'état de l'option de retrait Extraire/modifier les comptes des participants Fournir/extraire une soumission Soumission d'offre de RD Soumission Soumission d'achat de RD Fournir/extraire/supprimer une soumission permanente
Fixer/extraire/supprimer des contraintes de programme pour le participant
Gérer les contraintes Fixer/extraire/supprimer des contraintes de programme pour le client du DRAS
Extraire les renseignements sur le programme Calendriers de réponse Créer/extraire/supprimer un calendrier de réponse Surveiller les clients Extraire le statut des communications du client/les transactions/ les alertes du DRAS
Activer le mode d'essai Installation et mise à l'essai Mesure et vérification Déterminer/extraire le statut de mode d'essai M et V de l'événement de RD/Règlement (Détail ouvert oui/non) Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 11 ‐ Mars 2011 3.8
Interface entre le service public et l’EIR Le groupe de travail du NAESB a mis l’accent sur les communications uniformes à l’extérieur des communications de l’entreprise, par conséquent tout le côté service public/EIR du DRAS est jugé être hors de la portée des exigences du NAESB. Le tableau suivant résume le mappage entre les fonctions d’OpenADR et de l’exigence PAP09 QED du NAESB liées aux opérations sur l’interface du service public : Opérations du service public Fonction OpenADR PAP09 QED du NAESB Lancer/modifier un événement de RD Extraire la rétroaction des participants Traiter l'événement Ajuster les participants à l'événement de RD Extraire les renseignements sur l'événement de RD
Fixer/extraire les contraintes de l'événement
Fournir/extraire les soumissions courantes Soumission Fermer les soumissions Déterminer l'état des soumissions Gérer les programmes et les comptes Créer/extraire/modifier/supprimer le programme
Créer/extraire/modifier/supprimer les comptes des participants
Ajuster les participants au programme Établir les groupes Surveiller les clients Extraire le statut des communications du client/les transactions/ les alertes du DRAS
Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 12 ‐ Mars 2011 4
SURVOL DES AUTRES ACTEURS EN MATIÈRE DE SIGNALISATION EN RD 4.1
Interopération en énergie de l’Oasis L’Organization for the Advancement of Structured Information Standards (OASIS) a formé le Comité technique d’interopération en énergie 4 en 2010 afin de transformer les exigences du NAESB en un modèle de renseignements pleinement développé à l’intention du NIST afin de finaliser l’ensemble des produits à livrer du PAP09. Comme l’a illustré la section précédente, plusieurs composants de la spécification OpenADR ne sont pas incorporés dans les exigences PAP09 du NAESB. Le Comité technique de l’OASIS, va toutefois plus loin que les exigences du NAESB, élargissant les fonctions de manière à mieux correspondre à OpenADR. En plus d’élargir la portée du modèle, le groupe a également incorporé plusieurs modèles logiques dans ses travaux. Le premier modèle a été utilisé pour décrire la relation entre les multiples niveaux de ressources de la demande qui utilisent et refondent le concept de Contrôleur d’énergie de ressource (Resource Energy Controller – REC) – Nœud terminal virtuel (Virtual End Node – VEN) de l’EPRI. 5 Le deuxième modèle était l’Energy Market Information Exchange 6 , qui superpose le commerce financier aux concepts fondamentaux de la réponse à la demande. Il est à noter que le Comité technique de l’OASIS travaille toujours sur sa spécification, alors les renseignements fournis maintenant doivent être considérés comme provisoires. Le tableau suivant illustre le mappage de niveau supérieur des concepts d’OpenADR par rapport à la spécification d’interopération en énergie : 4
http://www.oasis‐open.org/committees/tc_home.php?wg_abbrev=energyinterop (en anglais seulement) http://my.epri.com/portal/server.pt?Abstract_id=000000000001020432 (en anglais seulement) 6
http://docs.oasis‐open.org/emix/emix/v1.0/csprd01/emix‐v1.0‐csprd01.doc (en anglais seulement) 5
Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 13 ‐ Mars 2011 OpenADR – Mappage d’IE de l’Oasis OpenADR Interopération en énergie de l'OASIS Participant Partie à l'IE Client du DRAS Inscription à l'IE Événement de RD Événement d'IE État de l'option de retrait Option de retrait de l'IE Rétroaction sur l'événement de RD Rétroaction sur l'IE Estimation de l'IE Soumission Soumission d'IE Contrat d'IE Programme Programme d'IE Contraintes de programme Contrainte de l'IE Utilisation de l'IE 4.2
L’OpenADR Alliance À la fin de 2010, un groupe de membres de l’industrie a créé, avec le soutien du Lawrence Berkeley National Laboratory, l’OpenADR Alliance. L’OpenADR Alliance entend favoriser « le développement, l’adoption et le respect de la norme Open Automated Demand Response (OpenADR) par la collaboration, l’éducation, la formation, la mise à l’essai et la certification » [traduction] 7 . L’OpenADR Alliance indique qu’elle travaillera avec le NAESB et l’OASIS, de même qu’avec les groupes ayant des mandats connexes, y compris l’Utilities Communications Architecture International User’s Group (UCAIug), la Wi‐Fi Alliance™ et la Zigbee Alliance™. 7
http://openadr.org/getattachment/Home/OpenADR‐Alliance‐Launch‐102710.pdf Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 14 ‐ Mars 2011 5
CONCLUSIONS La spécification des exigences du NAESB concernant les signaux standards de RD au détail offre moins de fonctions qu’OpenADR. Toutefois, beaucoup de mises en œuvre d’OpenADR n’utilisent qu’une petite fraction des capacités complètes d’OpenADR – une fraction qui correspond à ce qu’incluent les documents du NAESB. De plus, le groupe de travail sur l’interopérabilité en énergie de l’OASIS doit présenter sous peu des normes pouvant être mises en œuvre. Puisque des personnes s’intéressant à l’OpenADR participent à ce forum, il y a de fortes chances que l’extrant de l’OASIS soit facile à mettre en correspondance avec la spécification OpenADR 2 à venir. Dans tous les cas, pour la première fois, les principaux acteurs en réponse à la demande, y compris les exploitants du marché du gros, les concepteurs de programmes de services publics, les fournisseurs de services de réponse à la demande et les développeurs de logiciels, sont tous en communication. Une terminologie commune émerge et à long terme, cela devrait mener à une convergence. Les spécifications du NAESB sont conçues pour s’appliquer dans l’ensemble de l’Amérique du Nord. De nombreuses compagnies œuvrant en réponse à la demande, aussi bien du côté de l’électricité en gros que de l’électricité au détail, ont participé au groupe de travail sur le réseau intelligent (Smart Grid) du NAESB; toutefois, la participation des compagnies canadiennes en général s’est avérée minime. Compte tenu de l’incidence que ces normes peuvent avoir sur l’industrie, il serait profitable pour les consommateurs d’électricité canadiens que leurs services publics et leurs fournisseurs de services en électricité prennent une part plus active au processus. Nous espérons que le présent rapport offre un bon résumé à ceux qui envisageaient déjà, ou qui envisagent maintenant, de le faire. Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 15 ‐ Mars 2011 ANNEXE A DIAGRAMME DES RELATIONS ENTRE LES ENTITÉS DE RD Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 16 ‐ Mars 2011 ANNEXE A : DIAGRAMME DES RELATIONS ENTRE LES ENTITÉS DE RD 1 . Regulators
2. Business Entities
1.1
Federal
2.1
System Operator
(SO)
1.2
Reliability
1.3 Environmental
1.4
State
1.5 Municipal, Cooperative, or other utility Authority
3. Participant Roles
3.1
Service P rovider (SP ) 3. 3
Scheduling Entity (SE)
2.2
Market Participant
(MP)
Takes on
one or mo re
Participant ro les
Note:
Bu siness Entities f or Retail Use Cases utilize 2. 3 (Utility D istribution Oper ator) in pla ce of 2.1 and 2. 4 (Utility Cu stomer) in plac e of 2.2
Exactly One
4 .1
Resource
4 .2
Asset Group
4 .4
Asset
3. 5
Transm ission/
Distribution Service P rovider (TDSP )
5.3
Market Enr ollment
5.4
Zone
5.6
P‐Node
4 .3
Service Location
3. 2
Load Serving Entity
(LSE)
3. 6
Meter A uthority (MA)
5.Supporting Objects
5.5 Comm unication Method
3. 4
Designated Dispatch Entity (DDE)
One or More
Zero or One
4. Resource Objects
5.2
Control
4 .5
Service Delivery Point
5.1
Measurement
Zero or More
Rapport technique – 2011‐061 (RP‐TEC) 411‐DERCOM ‐ 17 ‐ Mars 2011