OpenADR 2.0
მოთხოვნის რეაგირების პროგრამის სახელმძღვანელო
გადასინჯვის ნომერი: 0.92
დოკუმენტის სტატუსი: სამუშაო ტექსტი
დოკუმენტის ნომერი: 20140701
საავტორო უფლებები © OpenADR Alliance (2014/15). Ყველა უფლება დაცულია. ამ დოკუმენტის ინფორმაცია OpenADR ალიანსის საკუთრებაა და მისი გამოყენება და გამჟღავნება იზღუდება.
სარჩევი
5 მოთხოვნაზე რეაგირების პროგრამის ტიპები 9
7 განლაგების სცენარი და DR პროგრამის შედგენა 16
8 DR პროგრამის შაბლონის შერჩევა 18
9 მოთხოვნაზე რეაგირების პროგრამის შაბლონები 21
9.1 კრიტიკული პიკური ფასების პროგრამა (CPP) 21
9.1.1 CPP DR პროგრამის მახასიათებლები 21
9.1.2 OpenADR მახასიათებლები CPP პროგრამებისთვის 22
9.2 შესაძლებლობების სატენდერო პროგრამა 24
9.2.1 შესაძლებლობების სატენდერო წინადადებების DR პროგრამის მახასიათებლები 24
9.2.2 OpenADR მახასიათებლები შესაძლებლობების სატენდერო პროგრამებისათვის 25
9.3 საცხოვრებელი თერმოსტატის პროგრამა 27
9.3.1 საცხოვრებელი თერმოსტატი DR პროგრამის მახასიათებლები 27
9.3.2 OpenADR მახასიათებლები საცხოვრებელი თერმოსტატული პროგრამებისათვის 28
9.4 სწრაფი DR დისპეტჩერიზაცია 29
9.4.1 სწრაფი DR დისპეტჩერიზაციის პროგრამის მახასიათებლები 29
9.4.2 OpenADR მახასიათებლები შესაძლებლობების სატენდერო პროგრამებისათვის 31
9.5 საცხოვრებელი ელექტრო მანქანა (EV) გამოყენების დრო (TOU) პროგრამა 33
9.5.1 საცხოვრებელი EV TOU პროგრამის მახასიათებლები 33
9.5.2 OpenADR მახასიათებლები საცხოვრებელი EV TOU პროგრამებისთვის 33
9.6 საზოგადოებრივი სადგურის ელექტრომანქანა (EV) ფასების რეალურ დროში პროგრამა 34
9.6.1 საზოგადოებრივი სადგურის EV RTP პროგრამის მახასიათებლები 34
9.6.2 OpenADR მახასიათებლები საზოგადოებრივი სადგურის EV RTP პროგრამებისთვის 34
9.7 განაწილებული ენერგიის რესურსები (DER) DR პროგრამა 35
9.7.1 განაწილებული ენერგორესურსების (DER) პროგრამის მახასიათებლები 35
9.7.2 OpenADR მახასიათებლები განაწილებული ენერგიის რესურსებისთვის (DER) 35
დანართი A – სample მონაცემთა და დატვირთვის შაბლონები 36
A.1 კრიტიკული პიკური ფასების პროგრამა (CPP) 36
A.1.1 CPP სცენარი 1 – მარტივი გამოყენების შემთხვევა, A ან B Profile 36
A.1.2 CPP სცენარი 2 – ტიპიური გამოყენების შემთხვევა, B პროfile 36
A.1.3 CPP სცენარი 3 - კომპლექსური გამოყენების შემთხვევა 37
A.1.4 CPP Sample Event Payload – Typical B Profile გამოიყენეთ შემთხვევა 37
A.2 შესაძლებლობების სატენდერო პროგრამა (CBP) 39
A.2.1 CBP სცენარი 1 – მარტივი გამოყენების შემთხვევა, A ან B Profile 39
A.2.2 CBP სცენარი 2 – ტიპიური გამოყენების შემთხვევა, B პროfile 39
A.2.3 CBP სცენარი 3 - კომპლექსური გამოყენების შემთხვევა 40
A.2.4 CBP Sample Event Payload – Typical B Profile გამოიყენეთ შემთხვევა 40
A.3 საცხოვრებელი თერმოსტატის პროგრამა 42
A.3.1 საცხოვრებელი თერმოსტატის სცენარი 1 – მარტივი გამოყენების შემთხვევაში, A ან B Profile 42
A.3.2 საცხოვრებელი თერმოსტატის სცენარი 2 – ტიპიური გამოყენების შემთხვევა, B profile 42
A.3.3 საცხოვრებელი თერმოსტატის სცენარი 3 - კომპლექსური გამოყენების შემთხვევა 43
A.3.4 საცხოვრებელი თერმოსტატი Sample Event Payload – Typical B Profile გამოიყენეთ შემთხვევა 43
A.4 სწრაფი DR დისპეტჩერიზაცია 45
A.4.1 სწრაფი DR სცენარი 1 – მარტივი გამოყენების შემთხვევა, A ან B Profile 45
A.4.2 სწრაფი DR სცენარი 2 – ტიპიური გამოყენების შემთხვევა, B პროfile 45
A.4.3 სწრაფი DR სცენარი 3 - კომპლექსური გამოყენების შემთხვევა 46
A.4.4 სწრაფი DR Sample Event Payload – Typical B Profile გამოიყენეთ შემთხვევა 46
A.4.5 სწრაფი DR Sampმოხსენება მეტამონაცემების დატვირთვა – ტიპიური B Profile გამოიყენეთ შემთხვევა 48
A.4.6 სწრაფი DR Sample ანგარიშის მოთხოვნის დატვირთვა – ტიპიური B Profile გამოიყენეთ შემთხვევა 48
A.4.7 სწრაფი DR Sample Report Data Payload – Typical B Profile გამოიყენეთ შემთხვევა 49
A.5 საცხოვრებელი ელექტრო მანქანა (EV) გამოყენების დრო (TOU) პროგრამა 49
A.5.1 საცხოვრებელი EV სცენარი 1 – მარტივი გამოყენების შემთხვევა, A ან B Profile 49
A.5.2 საცხოვრებელი EV სცენარი 2 – ტიპიური გამოყენების შემთხვევა, B პროfile 50
A.5.3 საცხოვრებელი EV Sample Event Payload – Typical B Profile გამოიყენეთ შემთხვევა 50
A.6 საზოგადოებრივი სადგურის ელექტრომანქანების (EV) რეალური საფასო პროგრამა 53
A.6.1 საჯარო სადგური EV სცენარი 1 – ტიპიური გამოყენების შემთხვევა, B პროfile 53
A.6.2 საჯარო სადგური EV Sample Event Payload – Typical B Profile გამოიყენეთ შემთხვევა 53
A.7 განაწილებული ენერგიის რესურსები (DER) DR პროგრამა 54
დანართი B - მომსახურების და ტვირთის დატვირთვის განსაზღვრებები 55
B.1 Open ADR მხარს უჭერს შემდეგ სერვისებს: 55
დანართი C - მომსახურების და ტვირთის დატვირთვის განმარტებები 56
C.4 EiRegisterParty დატვირთვები 57
დანართი D - სქემა დატვირთვის ელემენტების ტერმინების 58
დანართი E ჩამოთვლილი მნიშვნელობების ტერმინები 65
დანართი F – OpenADR A and B Profile განსხვავებები 70
დანართი G - OpenADR უსაფრთხოების სერთიფიკატები
შესავალი
ამ სახელმძღვანელოს სამიზნე აუდიტორიაა კომუნალური პროგრამები, რომლებიც გეგმავენ მოთხოვნის რეაგირების (DR) პროგრამების განთავსებას, რომლებიც იყენებენ OpenADR 2.0-ს კომერციულ და ქვედა დინების ობიექტებს შორის DR ღონისძიებაზე დაკავშირებული შეტყობინებების კომუნიკაციისთვის და აღჭურვილობის მწარმოებლებისთვის, რომლებიც კომუნიკაციის გაცვლას უწყობენ ხელს. ივარაუდება, რომ მკითხველს აქვს ძირითადი კონცეპტუალური გაგება როგორც მოთხოვნის რეაგირების, ისე OpenADR 2.0 – ის შესახებ (ამ მომენტიდან უბრალოდ მოიხსენიება როგორც OpenADR).
OpenADR პროfile სპეციფიკაციები ნათლად განსაზღვრავს მოსალოდნელ ქცევას DR მოვლენებთან დაკავშირებული ინფორმაციის გაცვლისას, თუმცა OpenADR-ში არის საკმარისი არჩევითი შესაძლებლობა, რომ სერვერების (VTN) განლაგება კომუნალურ სერვისში და კლიენტების (VENs) დაქვემდებარებულ საიტებზე არ იყოს plug-n-play გამოცდილება. OpenADR მახასიათებლები, როგორიცაა მოვლენის სიგნალები, მოხსენების ფორმატები და დამიზნება უნდა იყოს მითითებული DR პროგრამის მიხედვით.
სტანდარტიზებული DR პროგრამა არ არსებობს. თითოეული DR პროგრამის დიზაინი უნიკალურია, რაც შეესაბამება გეოგრაფიული რეგიონის სტრუქტურულ და მარეგულირებელ მოთხოვნებს. თითოეული DR პროგრამისთვის არსებობს მრავალი შესაძლო გამოყენების სცენარი, რომელშიც მონაწილეობენ სხვადასხვა მსახიობები.
DR პროგრამის დიზაინის, განლაგების სცენარების და OpenADR მახასიათებლების ცვალებადობა არის ინჰიბიტორი DR– ის გაფართოებული დანერგვისა და OpenADR– ის გამოყენებისა. ეს ცვალებადობა უმეტესწილად არის ჭკვიანი ქსელის დაქუცმაცებული და რთული ბუნების ასახვა.
კომუნალურებს სჭირდებათ ყოფილიampტიპიური DR პროგრამები, რათა ისინი გამოიყენონ როგორც მოდელები საკუთარი DR პროგრამის განხორციელებისთვის. აღჭურვილობის მწარმოებლებმა უნდა გაიგონ DR პროგრამის გამოყენების ტიპიური მოდელები, რათა მათ შეძლონ ურთიერთთანამშრომლობის დადასტურება, როგორც განვითარების პროცესის ნაწილი, ვიდრე DR პროგრამის განლაგების კონკრეტულ საფუძველზე. ამ სახელმძღვანელოს მიზანია ორივე ამ მიზნის მიღწევა შემდეგნაირად:
- განსაზღვრეთ სტანდარტული DR პროგრამის შაბლონების მცირე ნაკრები, რომლებიც მოდელირებულია ყველაზე პოპულარული DR პროგრამების საერთო მახასიათებლების შესაბამისად, რომლებიც დანერგულია დღემდე
- განისაზღვროს განლაგების მცირე სცენარი, რომელიც შექმნილია რეალურ სამყაროში განლაგების შემდეგ, მკაფიოდ განსაზღვრული მსახიობები და როლები
- განსაზღვრეთ საუკეთესო პრაქტიკის რეკომენდაციები OpenADR მახასიათებლებისთვის, რომლებიც სპეციფიკურია DR პროგრამის თითოეული შაბლონისთვის
- მიეცით გადაწყვეტილების ხე, რომლის საშუალებითაც კომუნალური საშუალებები შეძლებენ DR პროგრამის სასარგებლო შაბლონების იდენტიფიცირებას და მათი ბიზნესის საჭიროებიდან გამომდინარე, სცენარების განლაგებას
ამ სახელმძღვანელოში აქცენტი გაკეთდება უბრალო საკითხებზე, მცირე მკაფიო რეკომენდაციების მითითებით, რომლებიც შეეხება DR– ის ტიპიური პროგრამის განსახორციელებლად საჭირო დეტალების უმრავლესობას და პროგრამებში განლაგებული აღჭურვილობის ურთიერთქმედების ტესტირების შესაძლებლობას. სახელმძღვანელო.
ცნობები
- OpenADR Profile სპეციფიკაცია და სქემა – www.openadr.org
ტერმინები და განმარტებები
ამ დოკუმენტში გამოიყენება შემდეგი ტერმინები და განმარტებები.
- მოთხოვნაზე პასუხი: მომხმარებლის დატვირთვის მოთხოვნის მართვის მექანიზმი მიწოდების პირობების შესაბამისად, როგორიცაა ფასები ან ხელმისაწვდომობის სიგნალები
- აგრეგატორი პარტია - ეს არის მხარე, რომელიც აგროვებს მრავალრიცხოვან რესურსებს ერთად და წარუდგენს მათ DR პროგრამის პარტიას, როგორც ერთი რესურსი მათ DR პროგრამებში.
- აგრეგატორის შუამავალი ინფრასტრუქტურა - ეს არის მოთხოვნა მხარის ინფრასტრუქტურისაგან დამოუკიდებელი ინფრასტრუქტურა, რომელსაც იყენებს Aggregator შუამავალი მხარე, როგორც რესურსებთან, ასევე ქსელის გვერდით მყოფ პირებთან ურთიერთობისთვის.
- შეთანხმება: ხელშეკრულების ხელშეკრულება მხარეებს შორის, რომლებიც თამაშობენ როლს DR პროგრამაში, რომელშიც აღწერილია პასუხისმგებლობა და კომპენსაცია
- აქტივი - რესურსის ტიპი, რომელიც წარმოადგენს ფიზიკური დატვირთვის სპეციფიკურ კოლექციას. რესურსები შეიძლება შედგებოდეს აქტივებისგან, ხოლო აქტივი შეიძლება იყოს რესურსი, მაგრამ აქტივების შემდგომი დაშლა მრავალ აქტივში ან რესურსებში შეუძლებელია.
- ასოცირებული: უზრუნველყოს პროგრამულ ასოციაციას ორ სუბიექტს შორის, მონაცემთა ბაზის მოწყობილობის კონფიგურაციის საშუალებით. მაგალითად, ასოცირებული რესურსები VEN– თან
- საბაზისო ხაზები: ღონისძიების დაწყებამდე მოწყობილობის ან საიტის მიერ გათვლილი ან გაზომული ენერგიის გამოყენება (მოთხოვნა) განისაზღვრება გამოკვლევების, ინსპექტირების ან / და გაზომვის საშუალებით.
- BMS - ეს არის შენობის მართვის სისტემა, რომელიც შეიძლება გამოყენებულ იქნას რესურსების კონტროლისთვის. ეს ზოგჯერ მოიხსენიება როგორც ენერგიის მართვის სისტემა.
- რთული რესურსი - ეს არის სპეციალური ტიპის რესურსი, რომელიც წარმოადგენს მრავალრიცხოვანი ფიზიკური აქტივების გაერთიანებას, რომლებსაც თითოეულს აქვს დატვირთვის კონტროლის საკუთარი საშუალება.
- მომხმარებლის წახალისება: მოთხოვნა მხარის რესურსის მფლობელის / აგრეგატორისთვის, რომელიც მიეწოდება DR პროგრამაში მონაწილეობას.
- მოთხოვნა გვერდითი ინფრასტრუქტურა - ეს არის ინფრასტრუქტურა, სადაც განთავსებულია რესურსები, რომლებიც რეგისტრირებულია DR პროგრამებში
- DR ლოგიკა: ალგორითმები ან ლოგიკა, რომლებიც გარდაქმნიან DR სიგნალებს მოქმედი დატვირთვის კონტროლად. გაითვალისწინეთ, რომ DR Logic შეიძლება განხორციელდეს სხვადასხვა ადგილას და ზოგ შემთხვევაში გადანაწილდეს მრავალ ქვესისტემას შორის.
- DR პროგრამის პარტია - ეს არის სუბიექტი, რომელიც პასუხისმგებელია ქსელის ინფრასტრუქტურაზე და უფრო მეტიც, DR პროგრამების მართვაზე, რომლებიც გამოიყენება ქსელის პრობლემების შესამსუბუქებლად. ეს ჩვეულებრივ არის პროგრამა ან ISO.
- ჩაირიცხა: მოთხოვნის მხარეების რესურსების მფლობელი / აგრეგატორი ირჩევს DR პროგრამაში მონაწილეობას და შეუძლია მოგვაწოდოს ინფორმაცია კონკრეტული რესურსების შესახებ, რომლებიც შეიძლება მიზნად ისახავდეს DR ღონისძიებებისთვის.
- ღონისძიების აქტიური პერიოდი: არის პერიოდი იმ დროის განმავლობაში, რომლის დროსაც იცვლება დატვირთვის პროfile მოთხოვნილია, როგორც DR ღონისძიების ნაწილი
- ღონისძიების შეზღუდვები: ვადები, რომლის განმავლობაშიც მომხმარებელს შეუძლია მიიღოს მოვლენები და მასთან დაკავშირებული შეზღუდვები, როგორიცაა შაბათ-კვირის ან ზედიზედ დღეების გარეშე ღონისძიებები.
- ღონისძიების დღეები: დღე, როდესაც ხდება DR მოვლენა. პროგრამების უმეტესობას აქვს შეზღუდვები ღონისძიების დღეების რაოდენობის შესახებ, რომლებიც დასაშვებია მოცემულ კალენდარულ პერიოდში
- ღონისძიების აღწერილი: OpenADR ღონისძიების ობიექტის ნაწილი, რომელიც აღწერს მოვლენის შესახებ მეტამონაცემებს, როგორიცაა პროგრამის სახელი და ღონისძიების პრიორიტეტი
- ღონისძიების ხანგრძლივობა: ღონისძიების ხანგრძლივობა. პროგრამების უმეტესობა განსაზღვრავს ღონისძიების ხანგრძლივობის შეზღუდვას, ისევე როგორც დღის საათებს, რომელთა დროსაც შეიძლება მოხდეს მოვლენა
- ღონისძიების სიგნალები: მოთხოვნადი ინფორმაცია, რომელიც შეიცავს ღონისძიებას, როგორიცაა ელექტროენერგიის ფასი ან კონკრეტული დონის დატვირთვა, რაც ჩვეულებრივ იწვევს წინასწარ დაპროგრამებულ დატვირთვის დაღვრის ქცევას ღონისძიების მიმღების მიერ. DR პროგრამის განმარტება უნდა მიუთითოს გამოყენებული მოვლენის სიგნალების ტიპები
- ღონისძიებების დამიზნება: დატვირთვის დასაშლელი რესურსები, რომლებიც განკუთვნილია DR მოვლენისთვის. ეს შეიძლება იყოს გეოგრაფიული არეალი, მოწყობილობების კონკრეტული კლასი, ჯგუფის იდენტიფიკატორი, რესურსის ID ან სხვა იდენტიფიკატორი. DR პროგრამის განსაზღვრებაში უნდა იყოს მითითებული, თუ როგორ უნდა იყოს გათვლილი კონკრეტული რესურსები.
- მოვლენები: ღონისძიება არის შეტყობინება საწარმოსგან, რომ მოითხოვონ გვერდითი რესურსები, რომლებიც ითხოვენ დატვირთვის შემცირებას კონკრეტულ დროში, განსაზღვრულ ვადაში და შეიძლება შეიცავდეს ინფორმაციას სამიზნე კონკრეტული რესურსების განსაზღვრისთვის, რომლებიც მონაწილეობენ ღონისძიებაში
- ფასილიტატორის შუამავალი ინფრასტრუქტურა - ეს არის მოთხოვნა მხარის ინფრასტრუქტურისაგან დამოუკიდებელი ინფრასტრუქტურა, რომელსაც იყენებს შუამავალი მხარის ფასილიტატორი, როგორც რესურსებთან, ასევე ქსელის გვერდით ობიექტებთან ურთიერთობისთვის.
- ფასილიტატორი: მესამე მხარე, რომელიც ახორციელებს DR პროგრამის ზოგიერთი ან მთლიანად შესრულებას კომუნალური პროგრამის სახელით
- ქსელის ინფრასტრუქტურა - ეს არის ინფრასტრუქტურა, რომელსაც ფლობენ ან მართავენ DR პროგრამის მონაწილე მხარეები. ეს ინფრასტრუქტურა მოიცავს OpenADR VTN– ის დანერგვას, რომელიც გამოიყენება DR პროგრამებში ჩარიცხულ რესურსებში DR სიგნალების გაგზავნისთვის.
- შუამავალი მხარე - ეს არის მხარე, რომელიც, როგორც წესი, მუშაობს რესურსის მხარის სახელით, DR პროგრამებში მათი მონაწილეობის ხელშესაწყობად.
- დატვირთვის კონტროლი – ეს არის ინფრასტრუქტურა, რომელიც დაკავშირებულია რესურსთან, რომელიც პასუხისმგებელია რესურსის რეალურად კონტროლზე და კონკრეტული დატვირთვის პროფესიონალის წარმოებაზეfile.
- ჩატვირთეთ პროfile ობიექტური: ეს მოტივაცია DR პროგრამის შემუშავებისა და ღონისძიებების გაცემის უკან დგას. როგორიცაა პიკური დატვირთვების გაპარსვის სურვილი.
- შეტყობინება: ღონისძიების დაწყების დროამდე გარკვეული პერიოდი, როდესაც მოთხოვნის მხარის რესურსის მფლობელს ეცნობება მომლოდინე მოვლენის შესახებ
- აირჩიე ქცევა: მოვლენის მიღებისთანავე მოთხოვნადი რესურსის მფლობელის მხრიდან მოსალოდნელი პასუხი. ამ პასუხმა შეიძლება მიიღოს და OptIn ან OptOut ფორმა მიუთითოს, მონაწილეობს თუ არა რესურსი ღონისძიებაში
- უარი პასუხებს: მოითხოვს თუ არა კონკრეტულ პროგრამას რეაგირება მოთხოვნის მხრიდან რესურსებისგან მოვლენის საპასუხოდ და როგორია ეს პასუხები.
- ოპტ სერვისები: OpenADR– ის საშუალებით განსახორციელებელი გრაფიკები ღონისძიებებში მონაწილეობის მისაღებად რესურსების დროებითი ცვლილებების მითითების მიზნით.
- წინაპირობა: კრიტერიუმები, რომლებიც უნდა დაკმაყოფილდეს მოთხოვნის მხარის რესურსის მფლობელისთვის DR პროგრამაში ჩარიცხვის მიზნით. ეს შეიძლება შეიცავდეს ინტერვალის შეხვედრის ან დატვირთვის დატვირთვის მინიმალურ შესაძლებლობებს
- ძირითადი დრაივერები: კომუნალური პროგრამის ძირითადი მოტივაცია DR პროგრამის შექმნისა და ღონისძიებების გაცემისთვის. მაგალითად, ”პიკის მოთხოვნის შემცირება და რესურსების ადეკვატურობა”
- პროგრამები - ეს არის DR პროგრამები, რომელშიც რესურსები ირიცხება.
- პროგრამის აღწერა: პროგრამის მუშაობის თხრობითი აღწერა. ამ დოკუმენტში განსაზღვრული DR პროგრამის შაბლონების ნაწილი
- პროგრამის დროის ჩარჩო: DR პროგრამის განმავლობაში წლის ან სეზონების დრო, როგორც წესი, აქტიურია
- შეაფასეთ დიზაინი: კურსის სტრუქტურის სპეციფიკური ცვლილებები ან სტიმულები, რომლებიც გადახდილია მოთხოვნის მხარის რესურსების მფლობელებისთვის პროგრამაში მონაწილეობის მისაღებად
- სარეგისტრაციო მომსახურება: მომსახურება, რომელსაც OpenADR პროტოკოლი იყენებს VTN და VEN– ს შორის ძირითადი ურთიერთქმედების დასადგენად და იმის დასადასტურებლად, რომ VEN ასოცირდება კომუნალური მომხმარებლების ანგარიშთან.
- ანგარიშგების სერვისები: სერვისი, რომელსაც OpenADR იყენებს VEN– ებს, რათა უზრუნველყონ VEN– ების ანგარიშგება. DR პროგრამამ უნდა განსაზღვროს პროგრამისთვის საანგარიშგებო მოთხოვნები.
- რესურსების მხარე - ეს არის მხარე, რომელიც ფლობს მოთხოვნის მხარეს რესურსებს, რომლებიც შეიძლება ჩაირიცხოს DR პროგრამებში
- რესურსი – ეს არის სუბიექტი, რომელიც დარეგისტრირებულია DR პროგრამებში და შეუძლია რაიმე სახის ცვლილება შეიტანოს მათ load pro-შიfile VTN-დან DR სიგნალის მიღების საპასუხოდ.
- სამიზნე მომხმარებელი: Პროფესიონალიfile მოთხოვნის მხარის რესურსები, რომლებიც შეიძლება ჩაერთონ კონკრეტულ DR პროგრამებში, როგორიცაა საცხოვრებელი, სამრეწველო, ან შესაძლოა ელექტროენერგიის მოხმარების დონის მიხედვით.
- სამიზნე დატვირთვები: მოთხოვნის გვერდითი რესურსები, რომელთა დატვირთვა უნდა შეიცვალოს ა
- ვენი - ეს არის OpenADR ვირტუალური დასასრული კვანძი, რომელიც გამოიყენება VTN– თან ურთიერთქმედებისათვის.
- VTN - ეს არის OpenADR ვირტუალური ტოპ კვანძი, რომელიც გამოიყენება DR პროგრამებში ჩარიცხულ რესურსებთან ურთიერთქმედებისათვის.
აბრევიატურები
- BMS: შენობის მართვის სისტემა
- C&I: კომერციული და სამრეწველო
- კომკომუნიკაცია ორ სუბიექტს შორის
- DR: მოთხოვნა რეაგირება
- EMS: ენერგიის მართვის სისტემა
- OpenADR: გახსენით ავტომატური მოთხოვნის პასუხი
- პროგრამები: მითითება მოთხოვნაზე რეაგირების პროგრამებზე
- ვენი: ვირტუალური დასასრული კვანძი
- VTN: ვირტუალური ტოპ კვანძი
მოთხოვნაზე რეაგირების პროგრამის ტიპები
ეს დოკუმენტი შეიცავს ქვემოთ მოცემულ DR პროგრამების შაბლონებს.
1. კრიტიკული პიკის ფასები: განაკვეთი და / ან ფასების სტრუქტურა, რომელიც მიზნად ისახავს შემცირებული მოხმარების შემცირებას მაღალი საბითუმო ბაზრის ფასების ან სისტემის გაუთვალისწინებელი პერიოდის განმავლობაში, წინასწარ განსაზღვრული მაღალი კურსის ან ფასის დაწესებით, შეზღუდული რაოდენობის დღეებისა და საათების განმავლობაში.
2. შესაძლებლობების სატენდერო პროგრამა: პროგრამა, რომელიც საშუალებას აძლევს საცალო და საბითუმო ბაზრებზე მოთხოვნილ რესურსს შესთავაზოს დატვირთვის შემცირება ფასად, ან განსაზღვროს რამდენი დატვირთვის შემცირება სურს კონკრეტულ ფასად.
3. საცხოვრებელი თერმოსტატის პროგრამა / პირდაპირი დატვირთვის კონტროლი: მოთხოვნაზე რეაგირების აქტივობა, რომლის საშუალებითაც პროგრამის სპონსორი დისტანციურად აკონტროლებს მომხმარებლის ელექტრო მოწყობილობას (მაგ. კონდიციონერი) მოკლე დროში. ეს პროგრამები ძირითადად სთავაზობენ საცხოვრებელ ან მცირე კომერციულ მომხმარებლებს.
4. სწრაფი DR დისპეტჩერიზაციის / დამხმარე მომსახურების პროგრამა: მოთხოვნაზე რეაგირების პროგრამა, რომელიც უზრუნველყოფს მომხმარებელთა წამახალისებელ გადახდებს დატვირთვაზე რეაგირებისთვის გადაუდებელი მოთხოვნის რეაგირების ღონისძიების დროს. სისტემის არანორმალური მდგომარეობა (მაგample, სისტემის შეზღუდვები და ადგილობრივი სიმძლავრის შეზღუდვები), რომელიც მოითხოვს ავტომატურ ან დაუყოვნებელ მექანიკურ მოქმედებას, რათა თავიდან აიცილოს ან შეზღუდოს გადამცემი საშუალებების ან წარმოების მიწოდების უკმარისობა, რამაც შეიძლება უარყოფითად იმოქმედოს ნაყარი ელექტროსისტემის საიმედოობაზე. ამ ტიპის პროგრამებს ზოგჯერ შეიძლება ეწოდოს "დამხმარე სერვისები".
5. ელექტროძრავის (EV) DR პროგრამა: მოთხოვნაზე რეაგირების აქტივობა, რომლის საშუალებითაც ხდება ელექტრომობილების დატენვის საფასურის შეცვლა, რომ მომხმარებლებმა მოხმარების წესები გადაიტანონ.
6. განაწილებული ენერგიის რესურსები (DER) DR პროგრამა: მოთხოვნაზე რეაგირების აქტივობა, რომელიც გამოიყენება ენერგორესურსების გადანაწილების ინტეგრირებაზე ჭკვიან ქსელში.
განლაგების სცენარები
DR პროგრამის გამოყენების გზა გარკვეულწილად დამოუკიდებელია თავად DR პროგრამის მახასიათებლებისგან. შემდეგ დიაგრამებზე ნაჩვენებია მრავალფეროვანი გზა, რომლის საშუალებითაც შეიძლება DR პროგრამის გამოყენება. შემდეგ ნაწილში მოცემულია ჯვარედინი მითითება განლაგების სცენარებსა და DR პროგრამებს შორის, რომელთა გამოყენებაც, სავარაუდოდ, შესაძლებელია.
ამ განყოფილების დიაგრამები აჩვენებს სუბიექტებს შორის არსებულ ურთიერთობებს სხვადასხვა სცენარში.
პირდაპირი 1
ეს არის მარტივი სცენარი, რომელშიც არის პირდაპირი ურთიერთობა DR პროგრამის პარტიასა და რესურს პარტიას შორის. რესურსის მხარე პასუხისმგებელია საკუთარი რესურსების DR პროგრამებში ჩარიცხვაზე და ქსელის ინფრასტრუქტურა უშუალოდ ურთიერთქმედებს რესურსებთან VEN-ის მეშვეობით, რომელიც მოთხოვნის მხარის ინფრასტრუქტურაშია. გარდა ამისა, VEN ეკუთვნის რესურს მხარეს და არის ცალკე რესურსებისა და მათი კონტროლერებისგან. როდესაც DR სიგნალი მიიღება VEN-ის მიერ, ის ჩვეულებრივ არ ახორციელებს დატვირთვის კონტროლის ლოგიკას, მაგრამ უბრალოდ გადასცემს სიგნალებს დატვირთვის კონტროლერებს, რომლებიც იღებენ შესაბამის ზომებს. მაგampამ სცენარის ნაწილი მოიცავს C&I შენობებს, რომლებსაც შეუძლიათ დააინსტალირონ კარიბჭე, რომელიც შეიცავს OpenADR VEN-ს და როდესაც სიგნალი მიიღება ამ კარიბჭის მიერ, ის უბრალოდ თარგმნის მას სხვა პროტოკოლში და გადასცემს თავად დატვირთვის კონტროლერებს.
პირდაპირი 2
ეს ძალიან ჰგავს Direct 1 სცენარს. მთავარი განსხვავება ისაა, თუ როგორ ხდება VEN ინსტალაციით და VTN-თან ურთიერთქმედებით. VEN ინსტალირებულია ისეთ ერთეულში, როგორიცაა ცენტრალიზებული BMS, რომელსაც შეუძლია განახორციელოს DR ლოგიკა და ურთიერთქმედება Compound Resource-თან და მათ მრავალ სხვადასხვა დატვირთვის კონტროლერებთან უფრო ცენტრალიზებული მდებარეობიდან. მაგampეს მოიცავს დიდ შენობებს BMS-ით, რომლებიც აკონტროლებენ შენობაში მრავალ სხვადასხვა დატვირთვას (მაგ. განათება, HVAC, სამრეწველო პროცესები და ა.შ.)ampგამოყენება, რომელსაც შეიძლება ჰქონდეს მრავალი ობიექტი ცენტრალიზებული კონტროლის სისტემით.
პირდაპირი 3
ეს სცენარი ძალიან ჰგავს Direct 1 სცენარს. მთავარი განსხვავება ისაა, რომ VEN არის უშუალოდ რესურსში და მის დატვირთვის კონტროლერში. ამ შემთხვევაში DR სიგნალები პირდაპირ იგზავნება რესურსზე და მის დატვირთვის კონტროლერზე. ეგრეთ წოდებული "ფასები მოწყობილობებზე" სცენარი მიეკუთვნება ამ კატეგორიას. მაგampეს მოიცავს ნებისმიერი სახის დატვირთვის კონტროლერს, როგორიცაა HVAC (ანუ თერმოსტატი), რომელსაც აქვს ჩაშენებული VEN, რომელსაც შეუძლია უშუალოდ დაუკავშირდეს ქსელის გვერდით ერთეულებთან VTN.
პირდაპირი 4
ეს არის პირდაპირი 1 და პირდაპირი 2 სცენარების ერთობლიობა. მთავარი განსხვავება ისაა, რომ მრავალი VEN ასოცირდება ერთ კომპონენტ რესურსთან, რომელიც შედგება მრავალი აქტივისგან საკუთარი დატვირთვის კონტროლერებით. თითოეული დატვირთვის კონტროლერი, რომელიც შეიცავს კომპონენტ რესურსს, შეიძლება ასოცირებული იყოს სხვადასხვა VEN-თან. გაითვალისწინეთ, რომ ყველა VEN იქნება იმავე რესურს მხარის კონტროლის ქვეშ, რომელიც ფლობს კომპონენტ რესურსს. ეს სცენარი არსებობს იმისათვის, რომ ხელი შეუწყოს მოთხოვნის მხარის ინფრასტრუქტურებს, რომლებსაც აქვთ რთული რესურსები, მაგრამ არ გააჩნიათ ცენტრალიზებული BMS, როგორიცაა პირდაპირი 2 სცენარი. მაგampეს შეიძლება შეიცავდეს შენობებს, რომლებსაც აქვთ სხვადასხვა დატვირთვის კონტროლერი თითოეულ სართულზე, მაგრამ არა ცენტრალიზებული BMS, ან გampიყენებს სხვადასხვა კონტროლერებს თითოეულ შენობაში, მაგრამ არა გampჩვენ ფართო კონტროლერი. ვინაიდან DR პროგრამის მხარის პერსპექტივიდან არის მხოლოდ ერთი რესურსი ჩართული პროგრამაში, როდესაც მას სურს DR სიგნალის გაგზავნა რესურსზე, მას შეუძლია უბრალოდ გაუგზავნოს იგივე სიგნალები თითოეულ დანიშნულ VEN-ს, რომელიც დაკავშირებულია რესურსთან.
ფასილიტატორი 1
ამ სცენარში არის შუამავალი, რომელიც ხელს უწყობს DR პროგრამის მხარესა და რესურსებს შორის ურთიერთქმედებას. როგორც წესი, შუამავალი მხარე მუშაობს რესურს მხარის სახელით, რათა დაეხმაროს მათ რესურსების მართვაში. რესურს მხარეებს აქვთ პირდაპირი ურთიერთობა DR პროგრამის პარტიასთან და ისინი რიცხავენ საკუთარ რესურსებს DR პროგრამებში. ამრიგად, DR პროგრამის პარტია viewთითოეული რესურსის მხარე არის ცალკე რესურსი და შეუძლია მათთან ინდივიდუალურად ურთიერთქმედება. შუამავალი მხარის როლი არის იმოქმედოს როგორც გზამკვლევი ყველა OpenADR-თან დაკავშირებული ურთიერთქმედებისთვის, ამდენად, VEN ინსტალირებულია ფასილიტატორის შუამავალ ინფრასტრუქტურაში. ასეთი ინფრასტრუქტურა ხშირად არის ღრუბლოვანი ბაზები და სთავაზობენ რესურს მხარეებს როგორც პროგრამული უზრუნველყოფა როგორც სერვისი (SaaS). როდესაც DR სიგნალი მიიღება ფასილიტატორის VEN-ის მიერ, შეიძლება განხორციელდეს რამდენიმე განსხვავებული მოქმედება, მათ შორის DR სიგნალის შესაბამის რესურსზე გადაგზავნა და შესაძლოა რაიმე სახის DR ლოგიკის განხორციელება და დატვირთვის კონტროლის ბრძანებების გაგზავნა თითოეული რესურსის დატვირთვის კონტროლერზე. მაგampამ სცენარში შედის:
- გამყიდველები, რომლებიც მართავენ ობიექტებს მსხვილი კომერციული ქსელებისათვის, როგორიცაა დიდი ყუთების საცალო ვაჭრობა.
- სამრეწველო კონტროლის შუამავლები.
- ენერგეტიკული მომსახურების კომპანიები (ESCO)
- ღრუბელზე დაფუძნებული ხელსაწყოებისა და მოწყობილობების მართვის სისტემები, როგორიცაა განვითარებული ჭკვიანი კომუნიკაციური თერმოსტატის გამყიდველები.
აგრეგატორი 1
ეს სცენარი ჰგავს ფასილიტატორის სცენარს. მთავარი განსხვავება იმაშია, რომ აგრეგატორ პარტიას ურთიერთობა აქვს DR პროგრამის პარტიასთან, რესურსის მხარეებისგან განსხვავებით. აგრეგატორი მხარე აერთიანებს მრავალრიცხოვან მომხმარებელთა აქტივებს ერთ რესურსში, რომელსაც იწერს DR პროგრამებში. DR პროგრამის პარტიას არ აქვს ხილვადობა ინდივიდუალური აქტივების შესახებ, რომელსაც აგრეგატორი მართავს. როგორც ფასილიტატორთან, აგრეგატორსაც აქვს საკუთარი ინფრასტრუქტურა, სადაც VEN არის ინსტალირებული. განსხვავება იმაშია, რომ DR სიგნალის მიღებისას იგი მიუთითებს ერთ რესურსზე და აგრეგატორი ახორციელებს გარკვეულ DR ლოგიკას ყველა აქტივზე თავიანთ პორტფელში, DR სიგნალში მითითებული მიზნების მისაღწევად.
განლაგების სცენარი და DR პროგრამის შედგენა
ქვემოთ მოცემულ ცხრილში მოცემულია, თუ რომელი სცენარებია გავრცელებული კონკრეტული DR პროგრამისთვის.
| განლაგების სცენარი | |||
| DR თარგი | პირდაპირი 1, 2, 3, 4 | ფასილიტატორი 1 | აგრეგატორი 1 |
| CPP პროგრამა | ∆ | ∆ | |
| შესაძლებლობების სატენდერო პროგრამა | ∆ | ||
| საცხოვრებელი თერმოსტატი
პროგრამა |
∆ | ||
| სწრაფი DR დისპეტჩერიზაცია | ∆ | ||
| ელექტროძრავის (EV) DR პროგრამა | ∆ | ∆ | |
| განაწილებული ენერგიის რესურსები (DER) DR პროგრამა | ∆ | ∆ | |
DR პროგრამის შაბლონის შერჩევა
ქვემოთ მოცემულია შეკითხვების ნაკრები, რომლებიც შესაბამისია ნებისმიერი უტილიტისთვის, რომელიც შეეხება ახალი DR პროგრამის განხორციელებას. ეს არ უნდა იყოს ყოვლისმომცველი, მაგრამ წარმოადგენს ზოგიერთ უფრო შესაბამის საკითხს. ამ კითხვების მიზანია დაეხმაროს კომუნალური მენეჯმენტს DR პროგრამის შაბლონების შესაბამისი ნაკრებისკენ.
Q: რატომ გსურთ DR- ის გაკეთება? ქსელის რა მდგომარეობის ან ოპერაციული საკითხის შესამცირებლად ცდილობთ DR- ით?
ეს არის ყველაზე მნიშვნელოვანი კითხვა და აყალიბებს საფუძველს საერთო მოთხოვნებისა და მიზნებისთვის, თუ რას უნდა მიაღწიოს DR პროგრამამ. ამ კითხვაზე პასუხი განსაზღვრავს, თუ როგორ იტვირთება მოთხოვნის მხარე პროfile სავარაუდოდ ჩამოყალიბებული უნდა იყოს DR პროგრამით. ყველა სხვა მოთხოვნა ამ კითხვაზე პასუხიდან გამომდინარეობს.
- ცდილობ მწვერვალების გაპარსვას?
- გინდა იხვის მუცელი შეავსო?
- ცდილობთ ელექტროენერგიის ადგილზე ფასის დაცვას?
- შეშფოთებული ხართ ქსელის საიმედოობით?
- ცდილობთ ქსელის აქტივების შენარჩუნებას?
- და ა.შ. და ა.შ.
ქვემოთ მოყვანილი ცხრილი გთავაზობთ დამატებით კონტექსტს DR პროგრამის შემუშავების მოტივაციის უკან
| ქსელის საიმედოობა და უსაფრთხოება | სიხშირე და მოცულობაtage სტაბილურობა |
| რესურსების ადეკვატურობა | |
| პიკის მოცულობა | |
| Rampინგ | |
| შემთხვევითობა | |
| ენერგიის შესყიდვა | ადგილზე ბაზრის ფასები |
| ფასის საარბიტრაჟო | |
| აქტივების მენეჯმენტი | დაზიანების პრევენცია |
| მოვლის შემცირება | |
| სიცოცხლის გაგრძელება | |
| შესაძლებლობების მართვა | ეკონომიკური სარგებელი |
| გადაუდებელი დახმარების მენეჯმენტი | |
| გარემოსდაცვითი | ნეგავატი |
| სუფთა ენერგია |
Q: არსებობს თუ არა არსებული DR პროგრამა ან ტარიფი ამ პროგრამისთვის?
- ხშირად პროგრამის წესები პირდაპირ ტარიფშია გაწერილი.
Q: რომელი მოთხოვნის საბაზრო სეგმენტზე ხართ გათვლილი ამ პროგრამით?
ეს ხელს შეუწყობს ღონისძიებების რესურსების დამიზნების და სიგნალის ტიპის განსაზღვრას.
- საცხოვრებელი
- დიდი C&I
- მცირე C&I
- სოფლის მეურნეობა
- წყლის მართვა
- ელექტრო მანქანები
- და ა.შ. და ა.შ
Q: ცდილობთ კონკრეტული ტიპის დატვირთვების გათვლას?
- თერმოსტატები
- ელექტრო მანქანები
- Ag ტუმბოები
- და ა.შ.
Q: როგორია თქვენი განლაგების მოდელი?
ამ კითხვაზე პასუხმა შეიძლება გავლენა მოახდინოს პროგრამის მიხედვით რესურსების განსაზღვრაზე და განსაზღვროს თუ როგორ ხდება მათი მიზნების განსაზღვრა ღონისძიებებში.
- პირდაპირ მომხმარებლებს
- შუამავლების საშუალებით, როგორიცაა აგრეგატორი ან ფასილიტატორი
- მომხმარებელი პასუხისმგებელია საკუთარი VEN აღჭურვილობის შეძენასა და განთავსებაზე?
- და ა.შ.
Q: სპეციფიკის რომელ დონეზე გსურთ ურთიერთქმედება მოთხოვნის მხარის დატვირთვებთან?
ეს კითხვა გარკვეულწილად უკავშირდება განლაგების მოდელს და განსაზღვრავს, თუ როგორ არის განსაზღვრული და მიზნობრივი პროგრამაში არსებული რესურსები. ეს არის ერთ-ერთი ყველაზე მნიშვნელოვანი და შესაძლოა რთული საკითხი.
- ურთიერთქმედება თითოეულ ინდივიდუალურ რესურსთან
- ურთიერთქმედით ფასილიტატორის ან აგრეგატორის მეშვეობით, მათ უკან მითითებული რესურსების გარეშე
- ურთიერთქმედით ფასილიტატორის ან აგრეგატორის მეშვეობით და მიუთითეთ რომელი რესურსი უნდა გაიგზავნოს მათ უკან
- გამოიყენეთ ადგილმდებარეობა ატრიბუტად, რესურსების დასაზუსტებლად
- რესურსების დასაზუსტებლად გამოიყენეთ კომუნალური დადგენილი ჯგუფების მექანიზმი
- სამიზნე ინდივიდუალური აქტივები, როგორიცაა თერმოსტატები
- ურთიერთქმედეთ რესურსების გარეშე და უბრალოდ გადადეთ DR მოვლენები
- და ა.შ.
კითხვა: რა ურთიერთქმედების ნიმუში გსურთ გამოიყენოთ, რომ გავლენა მოახდინოს თქვენს მომხმარებელთა დატვირთვაზეfiles?
ეს კითხვა განსაზღვრავს DR სიგნალის ტიპს, რომელიც გადაეგზავნება პროგრამის მონაწილეებს.
- წახალისება (მაგ. დინამიური ფასები)
- დატვირთვის გაგზავნა (მაგ. დამხმარე მომსახურება)
- დატვირთვის პირდაპირი კონტროლი
- მოვლენის ზოგადი სიგნალი
- და ა.შ.
Q: რა არის პროგრამის ზოგადი რესურსების დაგეგმვის ატრიბუტები?
- თარიღები და დრო, რომ მოვლენები შეიძლება ეწოდოს
- მოვლენების სიხშირე
- ღონისძიებების ხანგრძლივობა
- დასაშვები შეყოვნება მოვლენების გავრცელებისთვის
- და ა.შ.
Q: როგორ განისაზღვრება პროგრამაში რესურსების ხელმისაწვდომობა?
- პროგრამის მკაცრი წესებით
- რესურსის მიერ შესრულებული ნომინაციების ან სატენდერო წინადადებების ნაწილი
- დაშვება / გამოსვლა დაშვებულია?
- და ა.შ.
Q: რა ტიპის ხილვადობა გჭირდებათ რესურსის მუშაობაში?
ეს ძალიან ფართო კითხვაა და განსაზღვრავს, თუ რა ტიპის ინფორმაციას იღებენ DR პროგრამის რესურსებიდან. ზოგადად, ეს განსაზღვრავს საჭირო ანგარიშების ტიპს.
- ონლაინ / ოფლაინ
- გამოყენება (მიმდინარე და / ან ისტორიული)
- დატვირთვის რეაგირების პოტენციალი
- დატვირთვის ხელმისაწვდომობა
- დატვირთვის / აქტივის მდგომარეობა (მიმდინარე და / ან ისტორიული)
- და ა.შ. და ა.შ.
მოთხოვნის რეაგირების პროგრამის შაბლონები
კრიტიკული პიკური ფასების პროგრამა (CPP)
CPP DR პროგრამის მახასიათებლები
| ჩატვირთეთ პროfile ობიექტური | - პიკის მოთხოვნის შემცირება |
| ძირითადი დრაივერები | - შემცირდა კაპიტალური ხარჯები და შემცირდა ენერგიის ხარჯები |
| პროგრამის აღწერა | როდესაც კომუნალური კომპანიები აკვირდებიან ან ელოდებათ საბითუმო ბაზრის მაღალ ფასებს ან ელექტროენერგეტიკული სისტემის საგანგებო პირობებს, მათ შეიძლება კრიტიკული მოვლენები უწოდეს განსაზღვრულ პერიოდში (მაგ., საღამოს 3 საათიდან საღამოს 6 საათამდე), ამ პერიოდების განმავლობაში ელექტროენერგიის ფასი არსებითად არის გაზრდილი. |
| მომხმარებლის წახალისება | მომხმარებელს შეიძლება შემოთავაზდეს ფასდაკლებული ენერგიის ფასები არა პიკის დროში, როგორც პროგრამაში მონაწილეობის სტიმული. |
| შეაფასეთ დიზაინი | CPP არის ფასების პროგრამა, რომლის ტემპები იზრდება ენერგიის მოხმარების კრიტიკული პიკის დროს. როგორც წესი, CPP განაკვეთები არის ბრტყელი, იატაკიანი ან TOU საბაზისო განაკვეთების დამატება ან გამრავლება. |
| სამიზნე მომხმარებელი | -ბინაური ან C&I |
| სამიზნე დატვირთვა | -ერთი |
| წინაპირობა | -მომხმარებელს უნდა ჰქონდეს ინტერვალის გაზომვა
-C & I მომხმარებლებს შეიძლება მოთხოვნის კრიტერიუმის შესრულება მოუწიონ |
| პროგრამის დროის ჩარჩო | ჩვეულებრივ მოიცავს წლის თვეებს, სადაც ხდება ენერგიის მაქსიმალური მოხმარება, თუმცა ზოგიერთ შემთხვევაში შეიძლება მთელი წლის განმავლობაში იყოს. |
| ღონისძიების შეზღუდვები | როგორც წესი, ორშაბათიდან პარასკევის ჩათვლით, შვებულების გამოკლებით, როგორც წესი, ნებადართულია ზედიზედ ჩატარებული დღის ღონისძიებები |
| ღონისძიების დღეები | - როგორც წესი, წელიწადში 9 – დან 15 – მდე |
| ღონისძიების ხანგრძლივობა | როგორც წესი, ფიქსირებული დროის განმავლობაში ყველა მოვლენისთვის, 4-დან 6 საათამდე, ენერგიის ყველაზე მაღალი მოხმარების დროს. |
| შეტყობინება | -როგორც დღეს წინა დღე |
| აირჩიე ქცევა | - როგორც წესი, მომხმარებელს არ სჭირდება ღონისძიებებში მონაწილეობა |
| სერტიფიცირება
მოვლენები |
-როგორც არავინ |
OpenADR მახასიათებლები CPP პროგრამებისთვის
| ღონისძიების სიგნალები | –მარტივი სიგნალი 1-დან 3 დონემდე, რომელიც შეესაბამება CPP მოვლენის ფასების გავლენას. თუ CPP პროგრამას აქვს ერთი საფასო კომპონენტი, ის უნდა დანიშნოს დონის 1-ზე. CPP პროგრამებისთვის, რომელსაც გააჩნია მრავალი ფასების კომპონენტი, ყველაზე მცირე ფასის კომპონენტი უნდა იყოს გამოსახული 1 დონეზე, ხოლო სხვა ფასის კომპონენტები 2 და 3 დონეზე იზრდება ფასების გავლენის.
-თუ განლაგება მხარს უჭერს B profile ვენები, SIMPLE სიგნალის გარდა, შეიძლება შეიტანოს ELECTRICITY_PRICE სიგნალი დატვირთვისას ტიპის ფასით ფარდობითი, ფასი აბსოლუტური ან ფასის მულტიპლიკატორი პროგრამის ხასიათიდან გამომდინარე. იხილეთ დანართი A მაგamples. |
| უარი პასუხებს | -VTN გზავნილებს oadrResponseR Required ელემენტი უნდა დააყენოთ "ყოველთვის", VEN– ს მოითხოვს optIn ან optOut რეაგირება
- როგორც CPP პროგრამაში მონაწილეობა არის "საუკეთესო ძალისხმევა", არ არსებობს ფორმალური მნიშვნელობა ოპტიმიზაციის ან არჩევის მიღმა თავაზიანობის ხელმისაწვდომობის მითითებით, მონაწილეობის განზრახვის მითითებით. ჩვენ გირჩევთ ამას VEN რეაგირებს optIn– ით, თუ მომხმარებლის მხრიდან რაიმე განსაკუთრებული მოქმედება არ განხორციელებულა. OadrCreateOpt დატვირთვა, როგორც წესი, არ იქნება გამოყენებული ღონისძიებებში მონაწილე რესურსების დასაკმაყოფილებლად. |
| ღონისძიების აღწერილი | -Მოვლენა პრიორიტეტი უნდა განისაზღვროს 1-ზე თუ პროგრამის წესებმა ან VTN კონფიგურაციამ სხვა რამ არ განსაზღვრეს
–როგორც წესი, ტესტის მოვლენები არ გამოიყენება CPP პროგრამებით. ამასთან, თუ მათ ნება დართეს, ტესტის ღონისძიების ელემენტი უნდა იყოს მითითებული „ნამდვილზე“, ტესტის მოვლენის მითითების მიზნით. თუ ამ ელემენტში საჭიროა დამატებითი პარამეტრიზებული ინფორმაცია, მას შეუძლია მიჰყვეს „ნამდვილს“, რომელიც გამოყოფილია ამ დამატებითი ინფორმაციის მქონე სივრცით. |
| ღონისძიების აქტიური პერიოდი | – eiRampUp, eiRecovery, ტოლერანტობის ელემენტები, როგორც წესი, არ გამოიყენება |
| საბაზისო ხაზები | –საბაზისო ხაზები, როგორც წესი, არ შედის ღონისძიების დატვირთვაში |
| ღონისძიებების დამიზნება | -CPP პროგრამები, როგორც წესი, არ ასხვავებენ მოცემული მომხმარებლის რესურსებს. დამიზნება ჩვეულებრივ განსაზღვრავს venID- ს, მითითებით, რომ VEN– თან დაკავშირებული ყველა რესურსი უნდა მონაწილეობდეს, ან ყველა რესურსის ID- ის სია ასოცირდება VEN- თან. |
| ანგარიშგების სერვისები | –ტელემეტრიული რეპორტაჟი, როგორც წესი, არ გამოიყენება რადგან ეს არ არის აუცილებელი CPP პროგრამებისთვის.
იხილეთ დანართი B მაგალითისათვისampანგარიშები კომუნალური პროგრამის პილოტებისგან, რომლებიც შეიძლება გამოყენებულ იქნას ამ ტიპის პროგრამაში. |
| ოპტ სერვისები | –Opt სერვისის გამოყენება დროებითი გრაფიკის კომუნიკაციისთვის როგორც წესი, არ იქნება გამოყენებული როგორც CPP პროგრამის ნაწილი. ამასთან, ზოგიერთმა განლაგებამ შეიძლება გამოიყენოს ეს სერვისი, რათა შეინარჩუნოს ღონისძიების დღეები მომხმარებლისთვის, რომლებიც მიუთითებენ ხელმისაწვდომობის ნაკლებობაზე. |
| სარეგისტრაციო მომსახურება | კენჭისყრის ინტერვალი ითხოვს VTN– ს ტიპიური CPP პროგრამებისთვის არ არის საჭირო უფრო ხშირი, ვიდრე საათში ერთხელ. ამასთან, გულისცემის გამოვლენისთვის გამოკითხვის გამოყენებას შეიძლება უფრო ხშირი გამოკითხვა დასჭირდეს. |
შესაძლებლობების სატენდერო პროგრამა
შესაძლებლობების სატენდერო წინადადებების DR პროგრამის მახასიათებლები
| ჩატვირთეთ პროfile ობიექტური | - პიკის მოთხოვნის შემცირება და რესურსების ადეკვატურობა |
| ძირითადი დრაივერები | - შემცირდა კაპიტალური ხარჯები და შემცირდა ენერგიის ხარჯები |
| პროგრამის აღწერა | სიმძლავრის სატენდერო პროგრამა გამოიყენება ISO / კომუნალური საშუალებების მიერ წინასწარ დატვირთული დატვირთვის დატვირთვის სიმძლავრის მისაღებად აგრეგატორებისგან ან თვითრეგირებული მომხმარებლებისგან. წინასწარ დატვირთული დატვირთვის დატვირთვის სიმძლავრე გამოიყენება ISO / კომუნალური საშუალებების მიერ, როდესაც ისინი აკვირდებიან ან პროგნოზირებენ მაღალ საბითუმო ფასებს, ელექტროენერგეტიკული სისტემის საგანგებო პირობებს, ან ენერგიის რესურსების ნორმალური გამოყენების ნაწილად, DR მოვლენების მითითებით განსაზღვრულ პერიოდში.
გაითვალისწინეთ, რომ თითოეული აგრეგატორი პასუხისმგებელია საკუთარი მოთხოვნილების საპასუხო პროგრამის, ასევე მომხმარებლის შეძენისა და მოვლენის შესახებ, რათა შეასრულოს ამ პროგრამის ფარგლებში აღებული შესაძლებლობები. |
| მომხმარებლის წახალისება | აგრეგატორები / მომხმარებლები იღებენ ორი ტიპის წახალისებას. პირველ რიგში, ისინი იღებენ სიმძლავრის გადასახადს მომავალი დროის ფანჯრის განმავლობაში DR– ის ღონისძიებებისთვის დატვირთული დატვირთვის დატვირთვის სიმძლავრის შესანარჩუნებლად. მეორე, თუ ღონისძიება იძახება მომავალი დროის ფანჯარაში, ენერგიის გადახდა შეიძლება განხორციელდეს ღონისძიების ხანგრძლივობის დროს დატვირთული დატვირთვისთვის. |
| შეაფასეთ დიზაინი | პროგრამის მონაწილეები ადგენენ "შესაძლებლობების წარდგენის" ტენდერს, რაც მიუთითებს დატვირთვის დატვირთვის სიმძლავრეზე, რომელსაც ისინი აპირებენ შეინარჩუნონ, როგორც მომავალი დროის მონაკვეთში. სატენდერო წინადადება შეიძლება ასევე მოიცავდეს წახალისებას, რომელსაც აგრეგატორი / მომხმარებელი აპირებს მიიღოს საბაზისო მნიშვნელობის ქვემოთ დატვირთული დატვირთვისთვის.
სასარგებლო ბაზრებზე სიმძლავრის ვალდებულება, როგორც წესი, შემდეგი კალენდარული თვისთვის არის, თუმცა ISO– ს ბაზრებზე გაცილებით გრძელი ვადები გამოიყენება. სიმძლავრის ნომინაციის ფარგლებში, მომხმარებელს შეეძლება აარჩიოს რიგი მახასიათებლების ჩათვლით შეტყობინების წინა დღის ან დღისა და ღონისძიების ხანგრძლივობის ფანჯრის (მაგალითად, 1-4 საათი, 2-6 საათი, between). შესაძლებლობების გადახდა ხდება მომხმარებლისთვის ამ წინასწარი ვალდებულებისათვის, მაშინაც კი, თუ დროის ფანჯარაში არ ხდება მოვლენების გამოძახება. თუ ღონისძიება დარეკილია დროის ფანჯარაში, მომხმარებელს შეუძლია მიიღოს ენერგია ანაზღაურება დატვირთვის დასაფარად საბაზისო ხაზთან მიმართებაში, თუმცა შეიძლება დაწესდეს ჯარიმები, თუ ღონისძიების გამოძახების დროს წინასწარ შესრულებული დატვირთვის დატვირთვის მოცულობაზე ნაკლები იქნება. |
| სამიზნე მომხმარებელი | - აგრეგატორები და თვითრეგულირებული C&I მომხმარებლები |
| სამიზნე დატვირთვები | - ნებისმიერი |
| წინაპირობა | -მომხმარებელს უნდა ჰქონდეს ინტერვალის გაზომვა
-C & I მომხმარებლებს შეიძლება მოუხდეს მოთხოვნის ან ტენდერის კრიტერიუმის დაკმაყოფილება |
| პროგრამის დროის ჩარჩო | -ყოველ დროს |
| ღონისძიების შეზღუდვები | როგორც წესი, ორშაბათიდან პარასკევის ჩათვლით, შვებულების გამოკლებით, როგორც წესი, ნებადართულია ზედიზედ ჩატარებული დღის ღონისძიებები |
| ღონისძიების დღეები | - როგორც წესი, მაქსიმუმ 30 საათი თვეში |
| ღონისძიების ხანგრძლივობა | - როგორც წესი, ფიქსირებული დროის ფანჯარაში ყველა მოვლენისთვის დღის განმავლობაში ყველაზე მაღალი ენერგიის მოხმარების დროს.) ღონისძიების ხანგრძლივობა იცვლება მომხმარებელთა შესაძლებლობების შესაბამისად, შეღავათებით 1-დან 8 საათამდე ან პროგრამის დიზაინის მიხედვით განსაზღვრული |
| შეტყობინება | -დღეს წინ ან დღეში დამოკიდებულია მომხმარებლის შესაძლებლობებისადმი ვალდებულებების შეღავათებზე ან პროგრამის დიზაინზე |
| აირჩიე ქცევა | - როგორც წესი, მომხმარებლები თავს იკავებენ მოვლენებზე, რადგან მათ წინასწარ აქვთ დატვირთული დატვირთვის ტევადობა. |
| სერტიფიცირება
მოვლენები |
- როგორც წესი, წელიწადში ორი (ტესტი) |
OpenADR მახასიათებლები შესაძლებლობების სატენდერო პროგრამებისთვის
| ღონისძიების სიგნალები | –მარტივი სიგნალი 1-დან 3 დონემდე ასახულია დატვირთული თანხის ოდენობაზე. თუ პროგრამა მხარს უჭერს დატვირთვის დაღვრის მხოლოდ ერთ დონეს, ეს უნდა დანიშნოს დონემდე 1. დატვირთული დატვირთვის მრავალ დონის პროგრამებისთვის, ყველაზე მცირე ცვლილება ნორმალური მუშაობიდან უნდა იქნას ასახული დონის 1-ზე, დატვირთვის შემცირების მნიშვნელობებით 2 და 3 დონე დატვირთვის შემცირების ხარისხში.
-თუ განლაგება მხარს უჭერს B profile ვენები, SIMPLE სიგნალის გარდა, შეიძლება იყოს BID_LOAD და / ან BID_PRICE სიგნალი დატვირთვისას მითითებული წერტილისა და ფასის სიგნალის ტიპებით, შესაბამისად დენის ერთეულით რეალური და ვალუტის PerKW. BID_LOAD ასახავს მოთხოვნილ დატვირთვას, აგრეგატორის / მომხმარებლის მიერ დატვირთვის მოცულობის ოდენობაზე, ხოლო BID_PRICE ასახავს აგრეგატორის / მომხმარებლის წახალისების წინადადებას. იხილეთ დანართი A მაგamples. |
| უარი პასუხებს | -VTN გზავნილებს oadrResponseR Required ელემენტი უნდა დააყენოთ "ყოველთვის", VEN– ს მოითხოვს optIn ან optOut რეაგირება
-როგორც აგრეგატორებს / მომხმარებლებს აქვთ წინასწარ შესრულებული შესაძლებლობები VEN– ებმა უნდა უპასუხონ optIn– ით. უარის თქმა შეიძლება გაიგზავნოს ღონისძიების საპასუხოდ, მაგრამ ეს არის არაფორმალური ხელმისაწვდომობის მითითება და არა ღონისძიების ოფიციალური უარის თქმა. - oadrCreateOpt დატვირთვა ჩვეულებრივ არ იქნება გამოყენებული ღონისძიებებში მონაწილე რესურსების კვალიფიკაციას, როგორც წესი, დატვირთვა წარმოადგენს ერთ აგრეგირებულ ერთეულს. |
| ღონისძიების აღწერილი | -Მოვლენა პრიორიტეტი უნდა განისაზღვროს 1-ზე თუ პროგრამის წესებმა ან VTN კონფიგურაციამ სხვა რამ არ განსაზღვრეს
–შეიძლება გამოყენებულ იქნას ტესტის მოვლენები შესაძლებლობების სატენდერო პროგრამებით. თუ ისინი დაშვებულია, ტესტის ღონისძიების ელემენტი უნდა დაყენდეს "ნამდვილზე", ტესტის მოვლენის მითითებით. თუ ამ ელემენტში საჭიროა დამატებითი პარამეტრიზებული ინფორმაცია, მას შეუძლია მიჰყვეს „ნამდვილს“, რომელიც გამოყოფილია ამ დამატებითი ინფორმაციის მქონე სივრცით. |
| ღონისძიების აქტიური პერიოდი | – eiRampUp, eiRecovery, ტოლერანტობის ელემენტები, როგორც წესი, არ გამოიყენება |
| საბაზისო ხაზები | –საბაზისო ხაზები, როგორც წესი, არ შედის ღონისძიების დატვირთვაში რადგან ეს მონაცემები, როგორც წესი, არ არის ხელმისაწვდომი ღონისძიების დაწყების დროს. თუმცა, როგორც კომუნალური, ისე აგრეგატორები/მომხმარებლები view საბაზისო ინფორმაციის ჩართვა მოვლენებში, როგორც სასარგებლო. |
| ღონისძიებების დამიზნება | - შესაძლებლობების სატენდერო პროგრამები, როგორც წესი, არ ასხვავებენ მოცემული მომხმარებლის რესურსებს. დამიზნება ჩვეულებრივ განსაზღვრავს venID- ს, მითითებით, რომ VEN– თან დაკავშირებული ყველა რესურსი უნდა მონაწილეობდეს, ან მოიცავს აგრეგირებული დატვირთვის რესურს ID– ს წარმომადგენელს ასოცირდება VEN- თან. |
| ანგარიშგების სერვისები | ISO შესაძლებლობების სატენდერო პროგრამებში, როგორც წესი, საჭიროა TELEMETRY_USAGE ანგარიშები powerReal მონაცემთა წერტილებით. იხampდანართში A.
როგორც წესი, ტელემეტრიის შესახებ კომუნალური შესაძლებლობების სატენდერო წინადადება არ არის საჭირო. გაითვალისწინეთ, რომ ტელემეტრიის მოხსენება მოითხოვს B profile ვენები. იხილეთ დანართი B მაგალითისათვისampანგარიშები კომუნალური პროგრამის პილოტებისგან, რომლებიც შეიძლება გამოყენებულ იქნას ამ ტიპის პროგრამაში. |
| ოპტ სერვისები | –Opt სერვისის გამოყენება დროებითი გრაფიკის კომუნიკაციისთვის როგორც წესი, არ იქნება გამოყენებული როგორც შესაძლებლობების სატენდერო პროგრამის ნაწილი, რადგან მომხმარებლებმა წინასწარ მიიღეს თავიანთი ხელმისაწვდომობა. ამასთან, ეს სერვისი შეიძლება სასარგებლო იყოს, როგორც არაფორმალური გზა მონაწილეთაათვის, რომ მიუთითონ ხელმისაწვდომობის ნაკლებობა შემსუბუქების მიზეზების გამო, როგორიცაა აღჭურვილობის უკმარისობა. |
| სარეგისტრაციო მომსახურება | კენჭისყრის ინტერვალი ითხოვს VTN– ს ტიპიური დღის წინა პროგრამებისთვის არ არის საჭირო უფრო ხშირი, ვიდრე საათში ერთხელ. ამასთან, გულისცემის გამოვლენის ან დღის პროგრამების გამოკითხვის გამოყენება შეიძლება უფრო ხშირ გამოკითხვას მოითხოვს. |
საცხოვრებელი თერმოსტატის პროგრამა
ეს პროგრამა წარმოადგენს პირდაპირი დატვირთვის კონტროლის (DLC) წარმომადგენელს, სადაც მოთხოვნის რეაგირების სიგნალი პირდაპირ შეცვლის დატვირთვის შემცირების რესურსების ქცევას, სიგნალის მიღებისა და დატვირთვის შემცირების სპეციფიკურ მოქმედებას შორის აბსტრაქციის ფენის გარეშე.
საცხოვრებელი თერმოსტატი DR პროგრამის მახასიათებლები
| ჩატვირთეთ პროfile ობიექტური | - პიკის მოთხოვნის შემცირება |
| ძირითადი დრაივერები | - შემცირდა კაპიტალური ხარჯები და შემცირდა ენერგიის ხარჯები |
| პროგრამის აღწერა | როდესაც კომუნალური კომპანიები აკვირდებიან ან წინასწარ განიხილავენ საბითუმო ბაზრის მაღალ ფასებს ან ელექტროენერგეტიკული სისტემის საგანგებო პირობებს, მათ შეიძლება შექმნან მოვლენა, რომელიც შეცვლის მომხმარებლის პროგრამირებადი კომუნიკაციური თერმოსტატის (PCT) ქცევას განსაზღვრულ ვადებში (მაგ., 3 საათიდან საღამოს 6 საათამდე ზაფხულის კვირის დღე) ენერგიის მოხმარების შემცირების მიზნით.
PCT ქცევის შეცვლა ღონისძიების საპასუხოდ შეიძლება იყოს ტემპერატურის მარტივი წერტილის შეცვლა ღონისძიების ხანგრძლივობისთვის ან უფრო რთული ცვლილებები, მათ შორის წინასწარი გაგრილება, რაც ამცირებს მოვლენის გავლენას მომხმარებლის კომფორტზე. დონის |
| მომხმარებლის წახალისება | -აქტივები ორ ზოგად ფორმას იღებს. პირველ რიგში, მომხმარებელს შეიძლება მიეწოდოს უფასო PCT ან შესთავაზოს ფასდაკლება / ფასდაკლებით მომხმარებელზე შეძენილი PCT- ს, როგორც DR პროგრამაში ჩარიცხვის სტიმული. მეორე, მომხმარებელს შეუძლია მიიღოს ყოველწლიური სტიპენდია პროგრამაში ჩარიცხვის გასაგრძელებლად. ნაკლებად გავრცელებული იქნება მომხმარებლებისთვის მიმდინარე წახალისება, ღონისძიებების დროს ენერგიის შემცირების საფუძველზე. |
| შეაფასეთ დიზაინი | - პირველ რიგში, წამახალისებელი პროგრამა, სადაც მომხმარებლები იღებენ ფასდაკლებულ ან უფასო PCT- ს DR პროგრამაში ჩარიცხვისთვის. ზოგიერთ პროგრამას შეუძლია გადაიხადოს პერიოდული სტიპენდია ან წამახალისებელი გადასახადი მოვლენების დროს ენერგიის შემცირების საფუძველზე.
|
| სამიზნე მომხმარებელი | -საცხოვრებელი |
| სამიზნე დატვირთვა | -HVAC |
| წინაპირობა | - როგორც წესი, არცერთი, რადგან მომხმარებელი იღებს პროგრამის ჩარიცხვის ნაწილს PCT- ს
|
| პროგრამის დროის ჩარჩო | ჩვეულებრივ მოიცავს წლის თვეებს, სადაც ხდება ენერგიის მაქსიმალური მოხმარება, თუმცა ზოგიერთ შემთხვევაში შეიძლება მთელი წლის განმავლობაში იყოს. |
| ღონისძიების შეზღუდვები | როგორც წესი, ორშაბათიდან პარასკევის ჩათვლით, შვებულების გამოკლებით, როგორც წესი, ნებადართულია ზედიზედ ჩატარებული დღის ღონისძიებები. |
| ღონისძიების დღეები | - როგორც წესი, წელიწადში 9 – დან 15 – მდე |
| ღონისძიების ხანგრძლივობა | - მოვლენები შეიძლება მოხდეს ნებისმიერ დროს, ხანგრძლივობა 2-დან 4 საათამდე, თუმცა, როგორც წესი, მოვლენები ხდება ენერგიის ყველაზე მაღალი მოხმარების დროს დღის განმავლობაში. |
| შეტყობინება | - როგორც წესი, ერთი დღით ადრე, თუმცა ზოგიერთ პროგრამას შეიძლება ჰქონდეს შეტყობინების დრო, ვიდრე 10 წუთი. |
| აირჩიე ქცევა | -მომხმარებლებს არ მოეთხოვებათ მონაწილეობა მიიღონ ღონისძიებებში, თუმცა ისინი ავტომატურად აირჩევენ ღონისძიებებს, თუ ისინი არ იმოქმედებენ ღონისძიების გადასალახად ან ღონისძიების დროს ტემპერატურის ხელით შესწორებით. |
| სერტიფიცირება
მოვლენები |
-როგორც არავინ |
OpenADR მახასიათებლები საცხოვრებელი თერმოსტატის პროგრამებისთვის
| ღონისძიების სიგნალები | –მარტივი სიგნალი 1-დან 3-მდე დონეებით, რომელიც დაკავშირებულია PCT ტემპერატურის დაყენების მნიშვნელობის შეცვლასთან ან თერმოსტატული ციკლის პროცენტთანtagე . თუ საცხოვრებელი თერმოსტატის პროგრამას აქვს ერთი კომპენსაცია / ველოსიპედის კომპონენტი, იგი უნდა დანიშნოს დონემდე 1. მრავალპროფილიანი ოფსეტური / ველოსიპედის კომპონენტის მქონე პროგრამებისთვის, ნორმალური მუშაობისგან ყველაზე მცირე ცვლილება უნდა იქნას ასახული დონის 1-ზე, სხვა კომპენსაციის / ველოსიპედის მნიშვნელობებით. დანიშნულია 2 და 3 დონეზე დატვირთვის შემცირების ზემოქმედების ხარისხში.
-თუ განლაგება მხარს უჭერს B profile ვენები, SIMPLE სიგნალის გარდა, LOAD_CONTROL სიგნალის დამატება შეიძლება დატვირთვაში ტიპის x-loadControlLevelOffset ან x-loadControlCapacity სასურველი ტემპერატურის დაყენების წერტილის ოფსეტის ან თერმოსტატული ციკლის პროცენტის დასაზუსტებლადtagე შესაბამისად. განახლებულია, რომ ა "ტემპერატურის" ერთეულის ტიპი, რომელიც გამოიყენება ტვირთის დატვირთვაში x-loadControlLevelOffset სიგნალის გამოყენებით კომპენსაციისთვის ცელსიუსის ან ფარენჰეიტის მითითებით. იხილეთ დანართი A მაგamples. |
| უარი პასუხებს | -VTN გზავნილებს oadrResponseR Required ელემენტი უნდა დააყენოთ "ყოველთვის", VEN– ს მოითხოვს optIn ან optOut რეაგირება
– VEN– ებმა უნდა უპასუხონ optIn– ით, თუ არ განხორციელებულა რაიმე კონკრეტული მოქმედება, რომელიც მომხმარებელმა მიიღო. - oadrCreateOpt დატვირთვა შეიძლება გამოყენებულ იქნას VEN- ების მიერ ღონისძიებაში რესურსების მონაწილეობის კვალიფიკაცია. მაგალითად, მოვლენის მიზანია ორი თერმოსტატის რესურსის ID, რომლებიც აკონტროლებენ ცალკეულ HVAC სისტემებს. თუ მომხმარებელი გადაწყვეტს, რომ HVAC სისტემებიდან მხოლოდ ერთს შეუძლია მიიღოს მონაწილეობა ღონისძიებაში, ეს დაუკავშირდება VTN– ს oadrCreateOpt ტვირთის გამოყენებით. გაითვალისწინეთ, რომ oadrCreateOpt payload მხარდაჭერილია მხოლოდ B pro-ს მიერfile ვენები |
| ღონისძიების აღწერილი | -Მოვლენა პრიორიტეტი უნდა განისაზღვროს 1-ზე თუ პროგრამის წესებმა ან VTN კონფიგურაციამ სხვა რამ არ განსაზღვრეს
–როგორც წესი, ტესტის მოვლენები არ გამოიყენება საცხოვრებელი თერმოსტატის პროგრამებით. ამასთან, თუ მათ ნება დართეს, ტესტის ღონისძიების ელემენტი უნდა იყოს მითითებული „ნამდვილზე“, ტესტის მოვლენის მითითების მიზნით. თუ ამ ელემენტში საჭიროა დამატებითი პარამეტრიზებული ინფორმაცია, მას შეუძლია მიჰყვეს „ნამდვილს“, რომელიც გამოყოფილია ამ დამატებითი ინფორმაციის მქონე სივრცით. |
| ღონისძიების აქტიური პერიოდი | –რანდომიზაცია ჩვეულებრივ გამოიყენება საცხოვრებელი თერმოსტატის მოვლენების დროს ტოლერანტობის ელემენტის გამოყენებით
– eiRampUp და eiRecovery ელემენტები, როგორც წესი, არ გამოიყენება |
| საბაზისო ხაზები | –საბაზისო ხაზები, როგორც წესი, არ შედის ღონისძიების დატვირთვაში |
| ღონისძიებების დამიზნება | საცხოვრებელი თერმოსტატის პროგრამები მიზნად ისახავს HVAC რესურსებს, რომლებიც კონტროლდება PCT- ებით. დამიზნება ჩვეულებრივ განსაზღვრავს რესურსის ID- ებს HVAC სისტემების (ე.ი. თერმოსტატი) VEN– თან ასოცირებული ან venID ღონისძიების სიგნალის მოწყობილობის კლასის სამიზნეზე მითითებულია თერმოსტატი |
| ანგარიშგების სერვისები | –ტელემეტრიული რეპორტაჟი, როგორც წესი, არ გამოიყენება რადგან აბსოლუტურად არ არის საჭირო საცხოვრებელი თერმოსტატის პროგრამებისთვის
იხილეთ დანართი B მაგალითისათვისampანგარიშები კომუნალური პროგრამის პილოტებისგან, რომლებიც შეიძლება გამოყენებულ იქნას ამ ტიპის პროგრამაში. |
| ოპტ სერვისები | –Opt სერვისის გამოყენება დროებითი გრაფიკის კომუნიკაციისთვის როგორც წესი, არ იქნება გამოყენებული როგორც CPP პროგრამის ნაწილი. |
| სარეგისტრაციო მომსახურება | კენჭისყრის ინტერვალი VTN ითხოვს საცხოვრებელი თერმოსტატის ერთი დღით ადრე გადაცემული პროგრამებისთვის არ არის საჭირო უფრო ხშირი, ვიდრე საათში ერთხელ. ამასთან, გულისცემის გამოვლენისთვის კენჭისყრის გამოყენებას შეიძლება დასჭირდეს უფრო ხშირი კენჭისყრა, ისევე როგორც საცხოვრებელი თერმოსტატის პროგრამები, მნიშვნელოვნად უფრო მოკლე შეტყობინების დროებით. |
სწრაფი DR დისპეტჩერიზაცია
სწრაფი DR დისპეტჩერიზაციის პროგრამის მახასიათებლები
| ჩატვირთეთ პროfile ობიექტური | რესურსების გაგზავნა „რეალურ დროში“ დატვირთვის რეაგირების მისაღწევად |
| ძირითადი დრაივერები | - ქსელის საიმედოობა და დამხმარე მომსახურება |
| პროგრამის აღწერა | Fast DR გამოიყენება ISO / კომუნალური საშუალებების მიერ წინასწარ დატვირთული დატვირთვის რეაგირების მისაღებად "რეალურ დროში". წინასწარ დატვირთული დატვირთვის პასუხს იყენებენ ISO / კომუნალური საშუალებები, როდესაც ისინი აკვირდებიან პირობებს, რომლებიც მოითხოვს დაუყოვნებლივ მოქმედებას ქსელის სტაბილურობისა და მთლიანობის შესანარჩუნებლად. რეალურ დროში ნიშნავს, რომ რესურსები ჩვეულებრივ იგზავნება შეყოვნებით, დაწყებული 10 წუთიდან რესურსებისთვის, რომლებიც გამოიყენება რეზერვად, 2 წამამდე, რესურსებისთვის, რომლებიც რეგულირების მიზნით გამოიყენება.
დატვირთვის რეაგირების ზომა უნდა იყოს საკმარისად დიდი, რომ შეიტანოს ცვლილება ქსელის მდგომარეობის შემსუბუქებაში და, შესაბამისად, რესურსები, როგორც წესი, ძალიან დიდია და მათ ხშირად მართავენ აგრეგატორები, როგორც აგრეგირებული რესურსის ნაწილი. დამხმარე სერვისებში მონაწილეობის მისაღებად რესურსის დატვირთვის რეაგირების მინიმალური ზომა დაახლოებით 500 კვტ-ია, მაგრამ ზოგიერთი პროგრამისთვის შეიძლება იყოს 100 კვტ-მდეც. გაითვალისწინეთ, რომ თუ რესურსი გამოიყენება როგორც რეზერვი, მას ჩვეულებრივ მოუწოდებენ შეამცირონ (ე.ი. დაიღვარა) დატვირთვა, მაგრამ თუ ის გამოიყენება რეგულირების მიზნით, ის შეიძლება გაგზავნილი იყოს დატვირთვის გაზრდის ან შემცირებისთვის. |
| მომხმარებლის წახალისება | აგრეგატორები / მომხმარებლები, როგორც წესი, იღებენ ორი ტიპის წახალისებას. პირველ რიგში, ისინი იღებენ გადასახადს იმისთვის, რომ ჩაიდინონ და დატვირთვის რეაგირების კონკრეტული ოდენობა ხელმისაწვდომი გახადონ DR მოვლენებისათვის მომავალი დროის ფანჯარაში. დატვირთვის რეაგირების ოდენობა, ხელმისაწვდომობის დროის ფანჯარა და გადასახდელი თანხა, როგორც წესი, ადგენს აგრეგატორს / მომხმარებელს. მეორე, თუ ღონისძიებას ეძახიან მომავალი დროის ფანჯარაში, გადახდა ხდება მოვლენის ხანგრძლივობის დატვირთვის რეაგირების საფუძველზე. |
| შეაფასეთ დიზაინი | პროგრამის მონაწილეები წარმოადგენენ სატენდერო წინადადებას, რომელშიც მითითებულია დატვირთვის პასუხი, რომლის მომზადებასაც ისინი აპირებენ მომავალი დროის ფანჯარაში. ჩვეულებრივ, შეთავაზებაში ასევე შედის გადახდა, რომლის აგრეგატორი / მომხმარებელი მზად არის მიიღოს დატვირთვის საპასუხოდ.
კომუნალური/ISO ბაზრებზე შეთავაზება, როგორც წესი, წარდგენილია ან წინა დღეს ან იმ პერიოდის დღეს, რომლისთვისაც ხდება ვალდებულება. როგორც მათი კვალიფიკაციისა და ბაზრებზე რეგისტრაციის ნაწილი, შესრულების სხვადასხვა პარამეტრი ასოცირდება რესურსთან, როგორიცაა r.amp განაკვეთი და მინიმალური და მაქსიმალური საოპერაციო ლიმიტები. ასეთი პარამეტრები განსაზღვრავს, თუ როგორ მოხდება მისი გაგზავნა. თუ მონაწილის სატენდერო წინადადება მიიღება, გადახდა შეიძლება განხორციელდეს მომხმარებლისთვის წინასწარი ვალდებულებისთვის, მაშინაც კი, თუ არ არის გამოცხადებული მოვლენები დროის ფანჯარაში. თუ ღონისძიება გამოძახებულია დროის ფანჯრის დროს, მომხმარებელს შეუძლია მიიღოს დამატებითი გადახდები ღონისძიების განმავლობაში მათი შესრულებისთვის. შესრულებაზე დაფუძნებული ასეთი გადახდები შეიძლება დაფუძნდეს უამრავ ფაქტორზე, მათ შორის ენერგიის რაოდენობაზე, სიმძლავრეზე, რამდენად მჭიდროდ მიჰყვება რესურსი დისპეტჩერიზაციის ინსტრუქციებს და გადახდის „გარბენი“, რომელიც ასახავს მათი დატვირთვის ხარისხს.file საჭირო იყო ღონისძიების დროს შეცვლა. ზოგიერთი პარამეტრი, როგორიცაა ენერგია და სიმძლავრე, შეიძლება იყოს საბაზისო ხაზის მიმართ. |
| სამიზნე მომხმარებელი | - აგრეგატორები და თვითრეგულირებული C&I მომხმარებლები |
| სამიზნე დატვირთვები | - მათ, ვისაც შეუძლია რეაგირება რეალურ დროში გაგზავნებზე. |
| წინაპირობა | -მომხმარებელს უნდა ჰქონდეს ინტერვალის გაზომვა
- უნდა დააკმაყოფილოს მინიმალური ზომის მოთხოვნები დატვირთვის რეაგირებისთვის -უნდა შეეძლოს რეალურ დროში გაგზავნაზე პასუხის გაცემა -როგორ უნდა მოვაწოდოთ რეალურ დროში ტელემეტრია, რომელიც აჩვენებს მიმდინარე დატვირთვის რეაგირებას |
| პროგრამის დროის ჩარჩო | -ყოველ დროს |
| ღონისძიების შეზღუდვები | - არცერთი |
| ღონისძიების დღეები | - არცერთი |
| ღონისძიების ხანგრძლივობა | - როგორც წესი, მოკლე (30 წუთზე ნაკლები), მაგრამ ნებისმიერ შემთხვევაში არასოდეს გადააჭარბებს იმ დროის ფანჯარას, რომელსაც მონაწილემ რესურსი გააცნო, როდესაც მათ განაცხადეს. |
| შეტყობინება | - არცერთი |
| აირჩიე ქცევა | -მომხმარებლებს უნიშნავენ მოვლენებს სტანდარტულად იმის გათვალისწინებით, რომ მათ წინასწარ აქვთ დატვირთული რეაგირება |
| სერტიფიცირება
მოვლენები |
- როგორც წესი, წელიწადში ერთი (ტესტი) |
OpenADR მახასიათებლები შესაძლებლობების სატენდერო პროგრამებისთვის
| ღონისძიების სიგნალები | –მარტივი სიგნალი 1-დან 3 დონემდე დატვირთულია დატვირთვის რეაგირების ოდენობით. თუ პროგრამა მხარს უჭერს დატვირთვის რეაგირების მხოლოდ ერთ დონეს, ეს უნდა დანიშნოს დონის 1-ზე. დატვირთვაზე რეაგირების მრავალფეროვანი დონის მქონე პროგრამებისთვის, ყველაზე მცირე ცვლილება ნორმალური მუშაობიდან უნდა იყოს 1 დონეზე, დატვირთვის შემცირების მნიშვნელობებზე 2 და 3 დონე დატვირთვის რეაგირების ხარისხში.
-თუ განლაგება მხარს უჭერს B profile ვენები, SIMPLE სიგნალის გარდა, შეიძლება მოთავსდეს დისპეტჩერიზაცია LOAD_DISPATCH სიგნალის სახით დატვირთვაში ტვირთის დაყენების წერტილის ან დელტის სიგნალის ტიპებით და სიმძლავრის ერთეულით რეალური. ეს სიგნალი წარმოადგენს დატვირთვის სასურველ "საექსპლუატაციო წერტილს" და მისი გამოხატვა შესაძლებელია როგორც მგვტ – ის აბსოლუტური ოდენობა (ე.ი. დაყენების წერტილი) ან მგვტ – ის გარკვეული ფარდობითი რიცხვი (ე.ი. დელტა) რესურსების მოქმედი წერტილიდან. იხილეთ დანართი A მაგamples. |
| უარი პასუხებს | -VTN გზავნილებს oadrResponseR Required ელემენტი უნდა დააყენოთ "ყოველთვის", VEN– ს მოითხოვს optIn ან optOut რეაგირება
-როგორც აგრეგატორებს / მომხმარებლებს აქვთ წინასწარ შესრულებული შესაძლებლობები VEN– ებმა უნდა უპასუხონ optIn– ით. უარის თქმა შეიძლება გაიგზავნოს ღონისძიების საპასუხოდ, მაგრამ ეს არის არაფორმალური ხელმისაწვდომობის მითითება და არა ღონისძიების ოფიციალური უარის თქმა. - oadrCreateOpt დატვირთვა ჩვეულებრივ არ იქნება გამოყენებული ღონისძიებებში მონაწილე რესურსების კვალიფიკაციას, როგორც წესი, დატვირთვა წარმოადგენს ერთ აგრეგირებულ ერთეულს. |
| ღონისძიების აღწერილი | -Მოვლენა პრიორიტეტი უნდა განისაზღვროს 1-ზე თუ პროგრამის წესებმა ან VTN კონფიგურაციამ სხვა რამ არ განსაზღვრეს
–შეიძლება გამოყენებულ იქნას ტესტის მოვლენებიგანსაკუთრებით რესურსის რეგისტრაციისა და კვალიფიკაციის დროს. თუ ისინი დაშვებულია, ტესტის ღონისძიების ელემენტი უნდა დაყენდეს "ნამდვილზე", ტესტის მოვლენის მითითებით. თუ ამ ელემენტში საჭიროა დამატებითი პარამეტრიზებული ინფორმაცია, მას შეუძლია მიჰყვეს „ნამდვილს“, რომელიც გამოყოფილია ამ დამატებითი ინფორმაციის მქონე სივრცით. |
| ღონისძიების აქტიური პერიოდი | – არ გამოიყენება ტოლერანტობის ელემენტები. eiRampUp და eiRecovery პერიოდები, როგორც წესი, არის რესურსის პარამეტრების ნაწილი, როდესაც ისინი დარეგისტრირდებიან და შეიძლება გამოყენებულ იქნას. დისპეტჩერების ბუნების გამო, ისინი შეიძლება იყოს ღია და, შესაბამისად, არ იყოს ღონისძიების დასრულების დრო. |
| საბაზისო ხაზები | –საბაზისო ხაზები, როგორც წესი, არ შედის ღონისძიების დატვირთვაში რადგან ეს მონაცემები, როგორც წესი, არ არის ხელმისაწვდომი ღონისძიების დაწყების დროს. თუმცა, როგორც კომუნალური, ისე აგრეგატორები/მომხმარებლები view საბაზისო ინფორმაციის ჩართვა მოვლენებში, როგორც სასარგებლო. |
| ღონისძიებების დამიზნება | - შესაძლებლობების სატენდერო პროგრამები, როგორც წესი, არ ასხვავებენ მოცემული მომხმარებლის რესურსებს. დამიზნება ჩვეულებრივ განსაზღვრავს venID- ს, მითითებით, რომ VEN– თან დაკავშირებული ყველა რესურსი უნდა მონაწილეობდეს, ან მოიცავს აგრეგირებული დატვირთვის რესურს ID– ს წარმომადგენელს ასოცირდება VEN- თან. |
| ანგარიშგების სერვისები | როგორც წესი, სწრაფი DR პროგრამები საჭიროებს TELEMETRY_USAGE ანგარიშს ენერგიით რეალური მონაცემების წერტილებით. გამოყენების ანგარიში ასახავს რესურსების მიმდინარე საექსპლუატაციო წერტილს და მას უტილიტა / ISO იყენებს იმის დასადგენად, თუ რამდენად უყურებს რესურსი გაგზავნილ ინსტრუქციას.
ზოგიერთ შემთხვევაში ტელემეტრია შეიძლება მოიცავდეს სხვა მონაცემთა წერტილებს, როგორიცაა ტtage წაკითხვები და დამუხტვის მდგომარეობა (ე.ი. ენერგია) იმ შემთხვევაში, როდესაც რესურსები არის შენახვის გარკვეული ფორმა. ზოგიერთ შემთხვევაში მოხსენების სიხშირე შეიძლება იყოს ყოველ 2 წამში ერთხელ. გაითვალისწინეთ, რომ ტელემეტრიის მოხსენება მოითხოვს B profile ვენები. იხილეთ დანართი A მაგamples. ასევე იხილეთ დანართი B მაგალითისათვისampანგარიშები კომუნალური პროგრამის პილოტებისგან, რომლებიც შეიძლება გამოყენებულ იქნას ამ ტიპის პროგრამაში. |
| ოპტ სერვისები | –დროებითი ხელმისაწვდომობის კომუნიკაციისთვის Opt მომსახურების გამოყენება განრიგი როგორც წესი, არ იქნება გამოყენებული რადგან მომხმარებლებმა წინასწარ მიიღეს თავიანთი ხელმისაწვდომობა ამასთან, ეს სერვისი შეიძლება სასარგებლო იყოს, როგორც არაფორმალური გზა მონაწილეთაათვის იმის აღნიშვნაზე, რომ არ არსებობს ხელმისაწვდომობა იმ შემსუბუქების მიზეზების გამო, როგორიცაა აღჭურვილობის უკმარისობა. |
| სარეგისტრაციო მომსახურება | რეალურ დროში გაგზავნის შეყოვნების დაბალი მოთხოვნების გამო გამოიყენება მხოლოდ ბიძგების ურთიერთქმედების შაბლონები. |
საცხოვრებელი ელექტრო მანქანა (EV) გამოყენების დრო (TOU) პროგრამა
საცხოვრებელი EV TOU პროგრამის მახასიათებლები
| ჩატვირთეთ პროfile ობიექტური | სიჩქარის სტრუქტურა, რომლის მიხედვითაც ხდება ელექტრომობილების დატენვის საფასურის შეცვლა, რომ მომხმარებლებმა მოხმარების წესები შეცვალონ. |
| ძირითადი დრაივერები | საცხოვრებელი ენერგიის გამოყენება პიკს აღწევს საღამოს. ვინაიდან EV დატენვას 4-8 საათი სჭირდება, შეიძლება დაყოვნდეს ორი საათის განმავლობაში დატვირთვის პიკის გადატანაზე. |
| პროგრამის აღწერა | მომხმარებლებს, რომლებსაც აქვთ ელექტრო მანქანა, შეუძლიათ დარეგისტრირდნენ ელექტროენერგიის გამოყენების დროზე (EV-TOU) ტარიფზე და მიიღონ დაბალი ტარიფები ავტომობილის დატენვისთვის პიკის საათებში, მაგალითად შუაღამისა და დილის 5 საათამდე EV-TOU ტარიფები შესთავაზა მომხმარებლებს წაახალისონ ელექტროენერგიის დღის განმავლობაში გამოყენება, როდესაც ელექტროენერგიაზე მოთხოვნა ყველაზე მაღალია. |
| მომხმარებლის წახალისება | ნაკლებად ძვირი დატენვა ელექტრონული მოწყობილობებისთვის. |
| შეაფასეთ დიზაინი | TOU შუა დღის მწვერვალთან, დილისა და საღამოს პიკის პირას, ხოლო მწვერვალიდან 12 – დან 5 საათამდე |
| სამიზნე მომხმარებელი | EV მფლობელი load profile რომ საღამოს პიკს აღწევს. |
| სამიზნე დატვირთვები | EV დამტენები |
| წინაპირობა | მომხმარებელს უნდა ჰქონდეს ჭკვიანი მრიცხველი და ელექტრონული განათება |
| პროგრამის დროის ჩარჩო | Მთელი წელი |
| ღონისძიების შეზღუდვები | არცერთი |
| ღონისძიების დღეები | მხოლოდ ყოველდღე, ან სამუშაო დღეებში |
| ღონისძიების ხანგრძლივობა | 5-8 საათი |
| შეტყობინება | მომხმარებელს ეცნობება ფასების საფეხურის შესახებ ყოველთვიური გადასახადები და VTN აგზავნის ღონისძიების სიგნალებს ერთი დღით ადრე. |
| აირჩიე ქცევა | გადამხდელებმა შეიძლება შეცვალონ განაკვეთის გეგმა, როგორც ჩვეულებრივ აკეთებდნენ კომუნალური პროგრამით. |
| სერტიფიცირება
მოვლენები |
OpenADR მახასიათებლები საცხოვრებელი EV TOU პროგრამებისთვის
| ღონისძიების სიგნალები | ELECTRICITY_PRICE სიგნალები ფასების რეალური დონით, ისევე როგორც SIMPLE სიგნალები 2.0a VEN– ით მონაწილეობის მისაღებად.
იხილეთ დანართი A მაგamples. |
| უარი პასუხებს | ყოველთვის აირჩიე VENs– ით |
| ღონისძიების აღწერილი | კვირაში ერთი ღონისძიება, ფასების თითოეული საფეხურის ღონისძიებების ინტერვალებით |
| ღონისძიების აქტიური პერიოდი | მინიმუმ 24 საათიანი შეტყობინება უნდა იქნას გამოყენებული. ყოველი ღონისძიების ინტერვალი უნდა აღბეჭდეს TOU მაჩვენებლის დონეს |
| საბაზისო ხაზები | N/A |
| ღონისძიებების დამიზნება | არ არის საჭირო წინასწარი დამიზნება, მხოლოდ VEN დონის დამიზნება. |
| ანგარიშგების სერვისები | ამის გაკეთება საჭირო არ არის, ყველა მონაცემი შეიძლება მოპოვდეს მრიცხველისგან.
იხილეთ დანართი B მაგალითისათვისampანგარიშები კომუნალური პროგრამის პილოტებისგან, რომლებიც შეიძლება გამოყენებულ იქნას ამ ტიპის პროგრამაში. |
| ოპტ სერვისები | ოპტის სერვისები არ იქნებოდა შესაბამისი ამ ტიპის პროგრამისთვის. |
| სარეგისტრაციო მომსახურება | მომხმარებლები წინასწარ უზრუნველყოფენ თავიანთ VEN პროგრამას, რომ მიიღონ ფასების სიგნალები. |
საზოგადოებრივი სადგურის ელექტრომანქანების (EV) რეალური საფასო პროგრამა
საზოგადოებრივი სადგურის EV RTP პროგრამის მახასიათებლები
| ჩატვირთეთ პროfile ობიექტური | მოთხოვნაზე რეაგირების აქტივობა, რომლითაც ელექტრომობილების დატენვის ღირებულება შეცვლილია პიკური ფასების რეალობის გადატანაზე მომხმარებლებზე. |
| ძირითადი დრაივერები | ელექტროენერგიის ფასი ცვალებადია დღეში. ეს პროგრამა მიზნად ისახავს დატენვის ფასის უფრო ეფექტურად შესაბამისობას ელექტროენერგიის ხარჯთან. |
| პროგრამის აღწერა | საზოგადოებრივ დამტენებს შეუძლიათ არსებობა სამუშაო ადგილებზე, საზოგადოებრივ სადგომებზე და საცალო მაღაზიებში. ეს პროგრამა რეალურ დროში აწვდის ფასებს პოტენციურ დამტენებს, სანამ ისინი ჩართავენ, რათა მათ მიიღონ ინფორმირებული გადაწყვეტილება, დააკისრონ თუ არა მანქანა. |
| მომხმარებლის წახალისება | ნაკლებად ძვირადღირებული დატენვა მწვერვალ პერიოდში. |
| შეაფასეთ დიზაინი | ფასები შეიძლება შეიცვალოსurly, მაგრამ მას შემდეგ რაც მომხმარებელი აირჩევს მანქანის ჩართვას, ტარიფს ადგენენ დატენვის ხანგრძლივობისთვის. |
| სამიზნე მომხმარებელი | ყველას, ვისაც აქვს EV, დატენვა უნდა სახლიდან შორს. |
| სამიზნე დატვირთვები | საზოგადოებრივი EV დამტენები |
| წინაპირობა | EV დამტენები უნდა იყოს ინტერნეტთან დაკავშირებული და OpenADR2.0b სერტიფიცირებული, ან დაკავშირებული იყოს OpenADR2.0b VEN კარიბჭეზე. |
| პროგრამის დროის ჩარჩო | Მთელი წელი |
| ღონისძიების შეზღუდვები | არცერთი |
| ღონისძიების დღეები | მხოლოდ ყოველდღე, ან სამუშაო დღეებში |
| ღონისძიების ხანგრძლივობა | 1 საათით ან მეტხანს |
| შეტყობინება | მომხმარებელს ეცნობება გაბატონებული განაკვეთის შესახებ, როდესაც აირჩევს მანქანაში ჩართვას. |
| აირჩიე ქცევა | მომხმარებელს შეუძლია უარი თქვას, თუ არ დააკისრებს გადასახადს. |
| სერტიფიცირება
მოვლენები |
OpenADR მახასიათებლები საზოგადოებრივი სადგურის EV RTP პროგრამებისთვის
| ღონისძიების სიგნალები | ELECTRICITY_PRICE სიგნალები ფასებით.
იხილეთ დანართი A მაგamples. |
| უარი პასუხებს | ყოველთვის აირჩიე VENs– ით |
| ღონისძიების აღწერილი | ღონისძიებები უნდა იყოს მომიჯნავე და შეიცავდეს ერთ ინტერვალს. |
| ღონისძიების აქტიური პერიოდი | გამოყენებული უნდა იყოს მინიმუმ 1 საათიანი შეტყობინება, თუმცა კომუნალური საშუალებები შეიძლება აირჩიონ წინა დღის შეტყობინების გამოყენება. |
| საბაზისო ხაზები | N/A |
| ღონისძიებების დამიზნება | არ არის საჭირო წინასწარი დამიზნება, მაგრამ სამიზნე შეიძლება გამოყენებულ იქნას კონკრეტული ტრანსფორმატორების, მიმწოდებლების ან გეოგრაფიული ტერიტორიების ფასების გასაგზავნად. |
| ანგარიშგების სერვისები | არ არის საჭირო ანგარიშგების გაკეთება, მაგრამ მისი გამოყენება შესაძლებელია სურვილისამებრ.
იხილეთ დანართი B მაგალითისათვისampანგარიშები კომუნალური პროგრამის პილოტებისგან, რომლებიც შეიძლება გამოყენებულ იქნას ამ ტიპის პროგრამაში. |
| ოპტ სერვისები | ოპტის სერვისები არ იქნებოდა შესაბამისი ამ ტიპის პროგრამისთვის. |
| სარეგისტრაციო მომსახურება | დატენვის სადგურის გამყიდველი უზრუნველყოფს მათ მოწყობილობებს კომუნალური VTN– ით. |
განაწილებული ენერგიის რესურსები (DER) DR პროგრამა
შემდეგი პროგრამის აღწერა ჰიპოთეტურია და ემყარება კვლევით დოკუმენტს (მითითება რიშის ნაშრომს), სადაც აღწერილია, თუ როგორ შეუძლიათ მომხმარებლებს გამოიყენონ DER შენახვის რესურსები DR პროგრამებში მონაწილეობის მისაღებად, როგორიცაა რეალურ დროში ფასწარმოქმნის პროგრამები (RTP).
განაწილებული ენერგიის რესურსების (DER) პროგრამის მახასიათებლები
| ჩატვირთეთ პროfile ობიექტური | მოთხოვნაზე რეაგირების აქტივობა გამოიყენება განაწილებული ენერგორესურსების ინტეგრირებაზე ჭკვიან ქსელში. |
| ძირითადი დრაივერები | - შემცირდა კაპიტალური ხარჯები და შემცირდა ენერგიის ხარჯები |
| პროგრამის აღწერა | DER რესურსების მქონე მომხმარებლებს, რომლებსაც შეუძლიათ ენერგიის მოპოვება და შენახვა, შეუძლიათ შეამცირონ ელექტროენერგიის შეძენის ღირებულება მაღალი ფასების პერიოდის განმავლობაში ქსელში, პირველ რიგში, შენახული ენერგიის გამოყენებით, შემდეგ კი დატვირთვის შემცირების სტრატეგიების გამოყენებით. |
| მომხმარებლის წახალისება | ელექტროენერგიის მაღალი ფასების დროს ხარჯების კონტროლის უნარი PV ან სხვა საშუალებით წარმოქმნილი შენახული ენერგიის გამოყენებით და დატვირთვის შემცირების სტრატეგიების გამოყენებით |
| შეაფასეთ დიზაინი | ელექტროენერგიის მაჩვენებლები იცვლება საბითუმო საბაზრო ფასებზე ან ტარიფზე, რომელიც იცვლება დღის, სეზონის ან ტემპერატურის მიხედვით |
| სამიზნე მომხმარებელი | ენერგიის შესანახი რესურსების მქონე მომხმარებლები |
| სამიზნე დატვირთვები | ნებისმიერი |
| წინაპირობა | ენერგიის შენახვის რესურსები |
| პროგრამის დროის ჩარჩო | ნებისმიერ დროს |
| ღონისძიების შეზღუდვები | არცერთი |
| ღონისძიების დღეები | ყოველ დღე |
| ღონისძიების ხანგრძლივობა | 24 საათი |
| შეტყობინება | დღის წინ |
| აირჩიე ქცევა | N / A - საუკეთესო ძალისხმევის პროგრამა |
| სერტიფიცირება
მოვლენები |
არცერთი |
განაწილებული ენერგიის რესურსების OpenADR მახასიათებლები (DER)
| ღონისძიების სიგნალები | ELECTRICITY_PRICE სიგნალები ფასების 24 ერთსაათიანი ინტერვალით 24 საათის განმავლობაში. ამ სიგნალს დასჭირდება B პროfile. ეს პროგრამა არ ექვემდებარება მარტივ სიგნალიზაციას A-სთვისfile ვენები.
იხილეთ დანართი A მაგamples. |
|
| უარი პასუხებს | -VTN გზავნილებს oadrResponseR Required ელემენტი უნდა დააყენოთ "არასოდეს", ხელს უშლის VEN– ების რეაგირებას. | |
| ღონისძიების აღწერილი | -Მოვლენა პრიორიტეტი უნდა განისაზღვროს 1-ზე თუ პროგრამის წესებმა ან VTN კონფიგურაციამ სხვა რამ არ განსაზღვრეს | |
| ღონისძიების აქტიური პერიოდი | 24 საათიანი 1 საათიანი ინტერვალით, დღის წინა შეტყობინებით | |
| საბაზისო ხაზები | N/A | |
| ღონისძიებების დამიზნება | მოწინავე დამიზნებას არ საჭიროებს სხვა venID | |
| ანგარიშგების სერვისები | არ არის საჭირო რეპორტის გაკეთება
იხილეთ დანართი B მაგალითისათვისampანგარიშები კომუნალური პროგრამის პილოტებისგან, რომლებიც შეიძლება გამოყენებულ იქნას ამ ტიპის პროგრამაში. |
|
| ოპტ სერვისები | არ გამოიყენება | |
| სარეგისტრაციო მომსახურება | კენჭისყრის ინტერვალი ითხოვს VTN– ს ტიპიური დღის წინა პროგრამებისთვის არ არის საჭირო უფრო ხშირი, ვიდრე საათში ერთხელ. ამასთან, გულისცემის გამოვლენისთვის კენჭისყრის გამოყენებას შეიძლება დასჭირდეს უფრო ხშირი კენჭისყრა, ისევე როგორც საცხოვრებელი თერმოსტატის პროგრამები, მნიშვნელოვნად უფრო მოკლე შეტყობინების დროებით. |
– სampმონაცემთა და დატვირთვის შაბლონები
შემდეგი ცხრილები და XML payload samples უზრუნველყოფს განმახორციელებლებს ხელშესახები ყოფილიampიმის შესახებ, თუ როგორ უნდა განხორციელდეს ამ დოკუმენტის DR შაბლონები. შემდეგი სახელთა სივრცის პრეფიქსები გამოყენებულია payload-ში examples:
- 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: ნაკადი”
- xmlns: xcal = ”urn: ietf: params: xml: ns: icalendar-2.0
- xmlns: power = ”http://docs.oasis-open.org/ns/emix/2011/06/power”
კრიტიკული პიკური ფასების პროგრამა (CPP)
CPP სცენარი 1 – მარტივი გამოყენების შემთხვევა, A ან B Profile
- ღონისძიება
- შეტყობინება: ღონისძიებამდე ერთი დღით ადრე
- დაწყების დრო: 1:XNUMX
- ხანგრძლივობა: 4 საათი
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 1
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: N / A
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 4 საათი
- ტიპიური ინტერვალი (ები): 1
- სიგნალის მიზანი: N / A
- ღონისძიების სამიზნე (ებ) ი: venID_1234
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- არცერთი
CPP სცენარი 2 – ტიპიური გამოყენების შემთხვევა, B პროfile
- ღონისძიება
- შეტყობინება: ღონისძიებამდე ერთი დღით ადრე
- დაწყების დრო: 1 სთ
- ხანგრძლივობა: 4 საათი
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 2
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: დონე 0, 1, 2, 3
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 4 საათი
- ტიპიური ინტერვალი (ები): 1 ან 2
- სიგნალის სამიზნე: არცერთი
- სიგნალის სახელი: ELECTRICITY_PRICE
- სიგნალის ტიპი: ფასი
- ერთეულები: აშშ დოლარი კვტ.სთ.
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 4 საათი
- ტიპიური ინტერვალი (ები): 0.10 დოლარიდან 1.00 დოლარამდე
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: venID_1234
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- არცერთი
CPP სცენარი 3 - კომპლექსური გამოყენების შემთხვევა
- ღონისძიება
- შეტყობინება: ღონისძიებამდე ერთი დღით ადრე
- დაწყების დრო: 2:XNUMX
- ხანგრძლივობა: 6 საათი
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 2
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: დონე 0,1, 2, 3)
- ინტერვალების რაოდენობა 3
- ინტერვალის ხანგრძლივობა (ები): 1 საათი, 4 საათი, 1 საათი
- ტიპიური ინტერვალი (s): 1, 2, 1 (შესაბამისად თითოეული ინტერვალისთვის)
- სიგნალის სამიზნე: არცერთი
- სიგნალის სახელი: ELECTRICITY_PRICE
- სიგნალის ტიპი: ფასი
- ერთეულები: აშშ დოლარი კვტ.სთ.
- ინტერვალების რაოდენობა 3
- ინტერვალის ხანგრძლივობა (ები): 1 საათი, 4 საათი, 1 საათი
- ტიპიური ინტერვალის ღირებულება: $ 0.50, $ 0.75, $ 0.50 (შესაბამისად თითოეული ინტერვალისთვის)
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: რესურსი_1, რესურსი_2, რესურსი_3
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- არცერთი
CPP Sample Event Payload – Typical B Profile გამოიყენეთ საქმე
OadrDisReq091214_043740_513
TH_VTN
ღონისძიება 091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
შორს
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT24H
PT4H
0
2.0
მარტივი
დონის
SIG_01
0.0
PT4H
0
0.75
ELECTRICITY_PRICE
ფასი
SIG_02
ვალუტაPerKWh
აშშ დოლარი
არცერთი
0.0
venID_1234
ყოველთვის
შესაძლებლობების სატენდერო პროგრამა (CBP)
CBP სცენარი 1 – მარტივი გამოყენების შემთხვევა, A ან B Profile
- ღონისძიება
- შეტყობინება: ღონისძიებამდე ერთი დღით ადრე
- დაწყების დრო: 1:XNUMX
- ხანგრძლივობა: 4 საათი
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 1
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: N / A
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 4 საათი
- ტიპიური ინტერვალი (ები): 1
- სიგნალის მიზანი: N / A
- ღონისძიების სამიზნე (ებ) ი: venID_1234
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- არცერთი
CBP სცენარი 2 – ტიპიური გამოყენების შემთხვევა, B პროfile
- ღონისძიება
- შეტყობინება: ღონისძიებამდე ერთი დღით ადრე
- დაწყების დრო: 1 სთ
- ხანგრძლივობა: 4 საათი
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 2
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: დონე 0,1, 2, 3
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 4 საათი
- ტიპიური ინტერვალი (ები): 1 ან 2
- სიგნალის სამიზნე: არცერთი
- სიგნალის სახელი: BID_LOAD
- სიგნალის ტიპი: მითითებული წერტილი
- ერთეულები: powerReal
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 4 საათი
- ტიპიური ინტერვალი (ები): 20 კვტ – დან 100 კვტ – მდე
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: venID_1234
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- არცერთი
CBP სცენარი 3 - კომპლექსური გამოყენების შემთხვევა
- ღონისძიება
- შეტყობინება: ღონისძიების დღე (რამდენი საათია)
- დაწყების დრო: 1:XNUMX
- ხანგრძლივობა: 6 საათი
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 3
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: დონე 0,1, 2, 3)
- ინტერვალების რაოდენობა: 2
- ინტერვალის ხანგრძლივობა (ები): 3 საათი, 3 საათი
- ტიპიური ინტერვალის მნიშვნელობა: 1, 2 (შესაბამისად თითოეული ინტერვალისთვის)
- სიგნალის სამიზნე: არცერთი
- სიგნალის სახელი: BID_LOAD
- სიგნალის ტიპი: მითითებული წერტილი
- ერთეულები: powerReal
- ინტერვალების რაოდენობა 2
- ინტერვალის ხანგრძლივობა (ები): 3 საათი, 3 საათი
- ტიპიური ინტერვალის მნიშვნელობა: 40 კვტ, 80 კვტ (შესაბამისად თითოეული ინტერვალისთვის)
- სიგნალის სამიზნე: არცერთი
- სიგნალის სახელი: BID_PRICE
- სიგნალის ტიპი: ფასი
- ერთეულები: currencyPerKW
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 6 საათი
- ტიპიური ინტერვალის ღირებულება: $ 3.10
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: რესურსი_1, რესურსი_2, რესურსი_3
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიში (ებ) ი
- მოხსენების სახელი: TELEMETRY_USAGE
- ანგარიშის ტიპი: გამოყენება
- ერთეულები: powerReal
- წაკითხვის ტიპი: პირდაპირი წაკითხვა
- მოხსენების სიხშირე: ყოველ 1 საათში ერთხელ
CBP სample Event Payload – Typical B Profile გამოიყენეთ საქმე
OadrDisReq091214_043740_513
TH_VTN
ღონისძიება 091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
შორს
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT24H
PT4H
0
2.0
მარტივი
დონის
SIG_01
0.0
PT4H
0
80.0
BID_LOAD
მითითებული წერტილი
SIG_02
რეალური ძალა
ვ
კ
60.0
<power:voltage>220.0tage>
მართალია
0.0
venID_1234
ყოველთვის
საცხოვრებელი თერმოსტატის პროგრამა
საცხოვრებელი თერმოსტატის სცენარი 1 – მარტივი გამოყენების შემთხვევაში, A ან B Profile
- ღონისძიება
- შეტყობინება: ღონისძიებამდე ერთი დღით ადრე
- დაწყების დრო: 1:XNUMX
- ხანგრძლივობა: 4 საათი
- შემთხვევითი: 10 წუთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 1
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: N / A
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 4 საათი
- ტიპიური ინტერვალი (ები): 1
- სიგნალის მიზანი: N / A
- ღონისძიების სამიზნე (ებ) ი: Resource_1
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- არცერთი
საცხოვრებელი თერმოსტატის სცენარი 2 – ტიპიური გამოყენების შემთხვევა, B პროfile
- ღონისძიება
- შეტყობინება: ღონისძიებამდე ერთი დღით ადრე
- დაწყების დრო: 1 სთ
- ხანგრძლივობა: 4 საათი
- შემთხვევითი: 10 წუთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 2
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: დონე 0,1, 2, 3
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 4 საათი
- ტიპიური ინტერვალი (ები): 1 ან 2
- სიგნალის სამიზნე: არცერთი
- სიგნალის სახელი: LOAD_CONTROL
- სიგნალის ტიპი: x-loadControlLevelOffset
- ერთეულები: ტემპერატურა
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 4 საათი
- ტიპიური ინტერვალი (ები): ფარენგეიტიდან 2-დან 6 გრადუსამდე
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: რესურსი_1, რესურსი_2
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn, Poot Out Out (oadrCreateOpt)
- ანგარიშები
- არცერთი
საცხოვრებელი თერმოსტატის სცენარი 3 - კომპლექსური გამოყენების შემთხვევა
- ღონისძიება
- შეტყობინება: ღონისძიების დღე
- დაწყების დრო: 1:XNUMX
- ხანგრძლივობა: 6 საათი
- შემთხვევითი: 10 წუთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 3
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: დონე 0,1, 2, 3)
- ინტერვალების რაოდენობა: 2
- ინტერვალის ხანგრძლივობა (ები): 3 საათი, 3 საათი
- ტიპიური ინტერვალის მნიშვნელობა: 1, 2 (შესაბამისად თითოეული ინტერვალისთვის)
- სიგნალის სამიზნე: არცერთი
- სიგნალის სახელი: BID_LOAD
- სიგნალის ტიპი: x-loadControlCapacity
- ერთეულები: არცერთი
- ინტერვალების რაოდენობა 2
- ინტერვალის ხანგრძლივობა (ები): 3 საათი, 3 საათი
- ტიპიური ინტერვალის მნიშვნელობა: 0.9, 0.8 (შესაბამისად თითოეული ინტერვალისთვის)
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: რესურსი_1, რესურსი_2, რესურსი_3
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn, Poot Out Out (oadrCreateOpt)
- ანგარიში (ებ) ი
- არცერთი
საცხოვრებელი თერმოსტატი სample Event Payload – Typical B Profile გამოიყენეთ საქმე
OadrDisReq091214_043740_513
TH_VTN
ღონისძიება 091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
შორს
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT10M
PT24H
PT4H
0
2.0
მარტივი
დონის
SIG_01
0.0
PT4H
0
6.0
LOAD_CONTROL
x-loadControlLevelOffset
SIG_02
ტემპერატურა
ფარენგეიტი
არცერთი
0.0
რესურსი_1
რესურსი_2
ყოველთვის
სწრაფი DR სცენარი 1 – მარტივი გამოყენების შემთხვევა, A ან B Profile
- ღონისძიება
- შეტყობინება: 10 წუთი
- დაწყების დრო: 1:XNUMX
- ხანგრძლივობა: 0 (ღია დასრულდა)
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 1
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: N / A
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა: 0 (ღია დასრულდა)
- ტიპიური ინტერვალი (ები): 1
- სიგნალის მიზანი: N / A
- ღონისძიების სამიზნე (ებ) ი: venID_1234
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- არცერთი
სწრაფი DR სცენარი 2 – ტიპიური გამოყენების შემთხვევა, B პროfile
- ღონისძიება
- შეტყობინება: 10 წუთი
- დაწყების დრო: 1 სთ
- ხანგრძლივობა: 30 წუთი
- შემთხვევითი: არცერთი
- Ramp ზევით: 5 წუთი
- აღდგენა: 5 წუთი
- სიგნალების რაოდენობა: 2
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: დონე 0,1, 2, 3
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 30 წუთი
- ტიპიური ინტერვალი (ები): 1 ან 2
- სიგნალის სამიზნე: არცერთი
- სიგნალის სახელი: LOAD_DISPATCH
- სიგნალის ტიპი: დელტა
- ერთეულები: powerReal
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 30 წუთი
- ტიპიური ინტერვალის ღირებულება: 500 კვტ – დან 2 მგვტ – მდე
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: venID_1234
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- მოხსენების სახელი: TELEMETRY_USAGE
- ანგარიშის ტიპი: გამოყენება
- ერთეულები: powerReal
- წაკითხვის ტიპი: პირდაპირი წაკითხვა
- მოხსენების სიხშირე: ყოველ 1 წუთში ერთხელ
სწრაფი DR სცენარი 3 - კომპლექსური გამოყენების შემთხვევა
- ღონისძიება
- შეტყობინება: 10 წუთი
- დაწყების დრო: 1:XNUMX
- ხანგრძლივობა: 30 წუთი
- შემთხვევითი: არცერთი
- Ramp ზევით: 5 წუთი
- აღდგენა: 5 წუთი
- სიგნალების რაოდენობა: 2
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: დონე 0,1, 2, 3)
- ინტერვალების რაოდენობა: 2
- ინტერვალის ხანგრძლივობა (ები): 15 წუთი, 15 წუთი
- ტიპიური ინტერვალის მნიშვნელობა: 1, 2 (შესაბამისად თითოეული ინტერვალისთვის)
- სიგნალის სამიზნე: არცერთი
- სიგნალის სახელი: LOAD_DISPATCH
- სიგნალის ტიპი: მითითებული წერტილი
- ერთეულები: powerReal
- ინტერვალების რაოდენობა 2
- ინტერვალის ხანგრძლივობა (ები): 15 წუთი, 15 წუთი
- ტიპიური ინტერვალის მნიშვნელობა: 800 კვტ, 900 კვტ (შესაბამისად თითოეული ინტერვალისთვის)
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: რესურსი_1
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიში (ებ) ი
- მოხსენების სახელი: TELEMETRY_USAGE
- ანგარიშის ტიპი: გამოყენება
- ერთეულები: powerReal და voltage
- წაკითხვის ტიპი: პირდაპირი წაკითხვა
- მოხსენების სიხშირე: ყოველ 5 წამში
სწრაფი DR სample Event Payload – Typical B Profile გამოიყენეთ საქმე
OadrDisReq091214_043740_513
TH_VTN
ღონისძიება 091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
შორს
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT10M
PT10M
<ei:x-eiRampზემოთ>
PT5M
</ei:x-eiRampზემოთ>
PT5M
PT10M
0
2.0
მარტივი
დონის
SIG_01
0.0
PT10M
0
500.0
LOAD_DISPATCH
დელტა
SIG_02
რეალური ძალა
ვ
კ
60.0
<power:voltage>220.0tage>
მართალია
0.0
venID_1234
ყოველთვის
სწრაფი DR სampმოხსენება მეტამონაცემების დატვირთვა – ტიპიური B Profile გამოიყენეთ საქმე
RegReq120615_122508_975
PT10M
rID120615_122512_981_0
რესურსი 1
გამოყენება
RealEnergy
ვინ
კ
პირდაპირი წაკითხვა
http: // MarketContext1
<oadr:oadrSamplingRate>
PT1M
PT10M
ყალბი
</oadr:oadrSamplingRate>
0
ReportSpecID120615_122512_481_2
METADATA_TELEMETRY_USAGE
<ei:createdDateTime>2015-06-12T19:25:12Z</ei:createdDateTime>
ec27de207837e1048fd3
სწრაფი DR სample ანგარიშის მოთხოვნის დატვირთვა – ტიპიური B Profile გამოიყენეთ საქმე
ReportReqID130615_192625_230
ReportReqID130615_192625_730
ReportSpecID120615_122512_481_2
PT1M
PT1M
<xcal:date-time>2015-06-14T13:00:00Z</xcal:date-time>
PT10M
rID120615_122512_981_0
x- არ არის გამოყენებული
VEN130615_192312_582
სწრაფი DR სample Report Data Payload – Typical B Profile გამოიყენეთ საქმე
ReportUpdReqID130615_192730_445
<xcal:date-time>2015-06-14T02:27:29Z</xcal:date-time>
<xcal:date-time>2015-06-14T02:27:29Z</xcal:date-time>
rID120615_122512_981_0
100
0.0
500.0
ხარისხი კარგი - არა სპეციფიკური
RP_54321
ReportReqID130615_192625_730
ReportSpecID120615_122512_481_2
TELEMETRY_USAGE
<ei:createdDateTime>2015-06-14T02:27:29Z</ei:createdDateTime>
VEN130615_192312_582
საცხოვრებელი ელექტრო მანქანა (EV) გამოყენების დრო (TOU) პროგრამა
გაითვალისწინეთ, რომ პროგრამის თანაფარდობა განაკვეთის საფეხურზე საკმაოდ სტრუქტურირებული ფორმით ნაჩვენებია მხოლოდ მარტივი და ტიპიური გამოყენების შემთხვევები
საცხოვრებელი EV სცენარი 1 – მარტივი გამოყენების შემთხვევა, A ან B Profile
- ღონისძიება
- შეტყობინება: ღონისძიებამდე ერთი დღით ადრე
- დაწყების დრო: 1:XNUMX
- ხანგრძლივობა: 24 საათი
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 1
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: N / A
- ინტერვალების რაოდენობა; თანაბარი TOU იარუსის ცვლილებები 24 საათში (2 - 6)
- ინტერვალის ხანგრძლივობა (ებ) ი: TOU იარუსის აქტიური ვადა (მაგ. 6 საათი)
- ტიპიური ინტერვალი (s): 0 - 4 ასახულია TOU Tiers- ზე
- სიგნალის მიზანი: N / A
- ღონისძიების სამიზნე (ებ) ი: venID_1234
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- არცერთი
საცხოვრებელი EV სცენარი 2 – ტიპიური გამოყენების შემთხვევა, B პროfile
- ღონისძიება
- შეტყობინება: ღონისძიებამდე ერთი დღით ადრე
- დაწყების დრო: შუაღამე
- ხანგრძლივობა: 24 საათი
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 2
- სიგნალის სახელი: მარტივი
- სიგნალის ტიპი: დონე
- ერთეულები: დონე 0, 1, 2, 3
- ინტერვალების რაოდენობა: თანაბარი TOU იარუსის შეცვლა 24 საათში (2 - 6)
- ინტერვალის ხანგრძლივობა (ებ) ი: TOU იარუსის აქტიური ვადა (მაგ. 6 საათი)
- ტიპიური ინტერვალი (ები): 0 - 4 ასახულია TOU Tiers- ზე (0 - ყველაზე იაფი რიგი)
- სიგნალის სამიზნე: არცერთი
- სიგნალის სახელი: ELECTRICITY_PRICE
- სიგნალის ტიპი: ფასი
- ერთეულები: აშშ დოლარი კვტ.სთ.
- ინტერვალების რაოდენობა: თანაბარი TOU იარუსის ცვლილებები 24 საათში (2 - 6)
- ინტერვალის ხანგრძლივობა (ებ) ი: TOU იარუსის აქტიური ვადა (მაგ. 6 საათი)
- ტიპიური ინტერვალის ღირებულება: $ 0.10-დან $ 1.00-მდე (მიმდინარე დონის კურსი)
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: venID_1234
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- არცერთი
საცხოვრებელი EV Sample Event Payload – Typical B Profile გამოიყენეთ საქმე
OadrDisReq091214_043740_513
TH_VTN
ღონისძიება 091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
შორს
<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>
PT24H
PT24H
PT5H
0
0.0
PT7H
1
1.0
PT47H
2
2.0
PT5H
3
1.0
მარტივი
დონის
SIG_01
0.0
PT5H
0
0.35
PT7H
1
0.55
PT7H
2
0.75
PT5H
3
0.55
ELECTRICITY_PRICE
ფასი
SIG_02
ვალუტაPerKWh
აშშ დოლარი
არცერთი
0.0
venID_1234
ყოველთვის
საზოგადოებრივი სადგურის ელექტრომანქანების (EV) რეალური საფასო პროგრამა
გაითვალისწინეთ, რომ რადგან ეს არის რეალურ დროში ფასების პროგრამა, ნამდვილად არ არსებობს დიფერენცირება მარტივი, ტიპიური და რთული გამოყენების შემთხვევაში. ამიტომ სampმონაცემები ნაჩვენები იქნება მხოლოდ ტიპიური გამოყენების შემთხვევისთვის.
საზოგადოებრივი სადგურის EV სცენარი 1 – ტიპიური გამოყენების შემთხვევა, B პროfile
- ღონისძიება
- შეტყობინება: 1 საათით ადრე
- დაწყების დრო: 1 სთ
- ხანგრძლივობა: 1 საათი
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 1
- სიგნალის სახელი: ELECTRICITY_PRICE
- სიგნალის ტიპი: ფასი
- ერთეულები: აშშ დოლარი კვტ.სთ.
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 1 საათი
- ტიპიური ინტერვალი (ები): 0.10 დოლარიდან 1.00 დოლარამდე
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: venID_1234
- პრიორიტეტი: 1
- საჭიროა VEN რეაგირება: ყოველთვის
- VEN მოსალოდნელი პასუხი: optIn
- ანგარიშები
- არცერთი
საზოგადოებრივი სადგური EV Sample Event Payload – Typical B Profile გამოიყენეთ საქმე
OadrDisReq091214_043740_513
TH_VTN
ღონისძიება 091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
შორს
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT1H
PT1H
PT1H
0
0.75
ELECTRICITY_PRICE
ფასი
SIG_01
ვალუტაPerKWh
აშშ დოლარი
არცერთი
0.0
venID_1234
ყოველთვის
განაწილებული ენერგიის რესურსები (DER) DR პროგრამა
გაითვალისწინეთ, რომ რადგან ეს არის რეალურ დროში ფასების პროგრამა, ნამდვილად არ არსებობს დიფერენცირება მარტივი, ტიპიური და რთული გამოყენების შემთხვევაში. ამიტომ სampმონაცემები ნაჩვენები იქნება მხოლოდ ტიპიური გამოყენების შემთხვევისთვის.
საზოგადოებრივი სადგურის EV სცენარი 1 – ტიპიური გამოყენების შემთხვევა, B პროfile
- ღონისძიება
- შეტყობინება: წინა დღეს
- დაწყების დრო: შუაღამე
- ხანგრძლივობა: 24 საათი
- შემთხვევითი: არცერთი
- Ramp ზევით: არცერთი
- აღდგენა: არცერთი
- სიგნალების რაოდენობა: 24
- სიგნალის სახელი: ELECTRICITY_PRICE
- სიგნალის ტიპი: ფასი
- ერთეულები: აშშ დოლარი კვტ.სთ.
- ინტერვალების რაოდენობა 1
- ინტერვალის ხანგრძლივობა (ები): 1 საათი
- ტიპიური ინტერვალი (ები): 0.10 დოლარიდან 1.00 დოლარამდე
- სიგნალის სამიზნე: არცერთი
- ღონისძიების მიზნები: venID_1234
- პრიორიტეტი: 1
- საჭიროა VEN– ის პასუხი: არასოდეს
- VEN მოსალოდნელი პასუხი: N / a
- ანგარიშები
- არცერთი
საზოგადოებრივი სადგური EV Sample Event Payload – Typical B Profile გამოიყენეთ საქმე
OadrDisReq091214_043740_513
TH_VTN
ღონისძიება 091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
შორს
<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>
PT24H
PT24H
PT1H
0
0.75
PT1H
1
0.80
ELECTRICITY_PRICE
ფასი
SIG_01
ვალუტაPerKWh
აშშ დოლარი
არცერთი
0.0
venID_1234
არასოდეს
– მაგample ანგარიშები Utility Pilots-ისგან
OpenADR ალიანსის წევრებმა მოგვაწოდეს შემდეგი B Profile oadrUpdateReport payload sampნაკლები კომუნალური საპილოტე პროგრამებიდან, სადაც მათი VEN იყო განლაგებული. შემდეგი შენიშვნები თან ახლდა სამი ტვირთის სampგათვალისწინებულია:
თერმოსტატის დატვირთვის მიზანი:
- უნდა იცოდეთ თერმოსტატის სტატუსი (ტემპერატურა, მითითებული წერტილები, გულშემატკივართა და რეჟიმების მდგომარეობა)
- თუ ის შეირჩა, შეცვალა თუ არა მომხმარებელმა თერმოსტატის პარამეტრები (ხელით უგულებელყოფს შეტყობინებებს)
M&V დატვირთვების დატვირთვის მიზანი:
- რესურსების სტატუსი და სახელმძღვანელოს უგულებელყოფა უარის თქმის შემთხვევაში
- შუალედური მონაცემები KYZ პულსის მრიცხველის ან ენერგიის მონიტორისგან KWH– ში მთლიანი ენერგიის და KW– ში მყისიერი მოთხოვნილების შესახებ
ჭკვიანი მრიცხველი / AMI ინტერვალის მონაცემები დატვირთვის მიზანი:
- AMI მეტრის კითხვის ინტერვალია 15 წუთიდან 1 საათამდე. მართალია, სასარგებლოა, მაგრამ არ არის საკმარისი მარცვლოვანი ბილინგის რეალურ დროში შეფასებისთვის
- მთლიანი ენერგია KWH- ში, დელტა ენერგია KWH- ში, მყისიერი მოთხოვნა KW- ში
შემდეგი სახელთა სივრცის პრეფიქსები გამოყენებულია payload-ში examples:
- 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: ნაკადი”
- xmlns: xcal = ”urn: ietf: params: xml: ns: icalendar-2.0
- xmlns: power = ”http://docs.oasis-open.org/ns/emix/2011/06/power”
თერმოსტატის ანგარიში დატვირთვის 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
სტატუსი
მართალია
ყალბი
0
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
მიმდინარე ტემპი
77.000000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
სითბოს ტემპერატურის დაყენება
64.000000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
მაგარი ტემპის პარამეტრი
86.000000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
HVAC რეჟიმის დაყენება
3
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
მიმდინარე HVAC რეჟიმი
0.000000
არ არის ხარისხი - არ აქვს მნიშვნელობა
გულშემატკივართა რეჟიმის დაყენება
2
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
მიმდინარე გამართვის რეჟიმი
2
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
მიმდინარე მოშორების რეჟიმი
0
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
მიმდინარე ტენიანობა
0.000000
არ არის ხარისხი - არ აქვს მნიშვნელობა
RP21
REQ: RReq: 1395368583267
0013A20040980FAE
TELEMETRY_STATUS
<ei:createdDateTime>2014-03-21T02:26:04Z</ei:createdDateTime>
VEN.ID:1395090780716
M&Vfor ფასდაკლების ანგარიში 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
სტატუსი
მართალია
ყალბი
ხარისხი კარგი - არა სპეციფიკური
პულსის რაოდენობა
34750.000000
ხარისხი კარგი - არა სპეციფიკური
ენერგია
33985.500000
ხარისხი კარგი - არა სპეციფიკური
Ძალა
1.26
ხარისხი კარგი - არა სპეციფიკური
RP15
REQ: RReq: 10453335019195698
0000000000522613 60
TELEMETRY_USAGE
<ei:createdDateTime>2015-08-21T17:41:50Z</ei:createdDateTime>
VEN.ID:1439831430142
Smart Meter/AMI ინტერვალის მონაცემების ანგარიში Payload 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
მყისიერი მოთხოვნა
6.167000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
intervalDataDelivered
0.051000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
currSumDelivered
12172.052000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
<xcal:date-time>2014-09-10T06:27:07Z</xcal:date-time>
PT15S
მყისიერი მოთხოვნა
6.114000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
intervalDataDelivered
0.051000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
currSumDelivered
12172.052000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
<xcal:date-time>2014-09-10T06:27:22Z</xcal:date-time>
PT15S
მყისიერი მოთხოვნა
6.113000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
intervalDataDelivered
0.051000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
currSumDelivered
12172.142000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
<xcal:date-time>2014-09-10T06:27:37Z</xcal:date-time>
PT15S
მყისიერი მოთხოვნა
6.112000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
intervalDataDelivered
0.051000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
currSumDelivered
12172.142000
ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა
RP4101
<ei:reportRequestID>d5f88bf0-1a8d-0132-eab3-0a5317f1edaa</ei:reportRequestID>
<ei:reportSpecifierID>00:21:b9:00:f2:a9</ei:reportSpecifierID>
TELEMETRY_USAGE
<ei:createdDateTime>2014-09-10T06:27:53Z</ei:createdDateTime>
<ei:venID>2b2159c0-19cd-0132-eaa3-0a5317f1edaa</ei:venID>
Open ADR მხარს უჭერს შემდეგ სერვისებს:
- EiEvent სერვისი – გამოიყენება VTN–ების მიერ VEN–ებისთვის მოთხოვნის პასუხების მოვლენების გასაგზავნად და გამოიყენება VEN–ების მიერ იმის დასადგენად, აპირებენ თუ არა რესურსები ღონისძიებაში მონაწილეობას. ერთადერთი სერვისი, რომელსაც მხარს უჭერს A პროfile არის EiEvent
- EiReport სერვისი - გამოიყენება VENs და VTNs ისტორიული, ტელემეტრიული და პროგნოზირებული ანგარიშების სანაცვლოდ
- EiOpt სერვისი - იყენებს VEN– ს VTN– ებს დროებითი ხელმისაწვდომობის გრაფიკის დასაზვერად ან ღონისძიებაში მონაწილე რესურსების დასაკმაყოფილებლად
- EiRegisterParty მომსახურება - VEN– ის ინიციატივით, და გამოიყენება როგორც VEN– ის, ასევე VTN– ს მიერ ინფორმაციის გადასაზიდად, რაც საჭიროა ტვირთის ტვირთის ურთიერთოპერაციული გაცვლის უზრუნველსაყოფად.
- OadrPoll სერვისი - გამოიყენება VEN- ების მიერ VTN- ს გამოსაკითხად, ნებისმიერი სხვა სერვისის დატვირთვისთვის
A და B პროfile სერვისის ოპერაციები განისაზღვრება თითოეული დატვირთვის ძირეული ელემენტით, გამოკლებით oadrPayload და oadrSignedObject wrapper-ები, რომლებიც გამოიყენება ყველა B pro-ზე.file ტვირთამწეობა.
- oadrRequestEvent – გამოიყენება VEN-ის მიერ მოზიდვის გაცვლის მოდელში VTN-დან ყველა შესაბამისი მოვლენის მოსაძიებლად. გამოიყენება როგორც პირველადი კენჭისყრის მექანიზმი A პრო-სთვისfile VEN, მაგრამ გამოიყენება მხოლოდ B VEN-ებზე VTN-თან სინქრონიზაციისთვის.
- oadrDistributeEvent - გამოიყენება VTN VEN– ზე მოთხოვნაზე რეაგირების ღონისძიებების მისაცემად
- oadrCreatedEvent - იყენებს VEN– ს კომუნიკაციისთვის, აპირებს თუ არა მონაწილეობას ღონისძიებაში მონაწილეობით ან ჩართვით
- oadrResponse - გამოიყენება VTN– ს მიერ VEN– დან optIn– ის ან optOut– ის მიღების დასადასტურებლად
გაითვალისწინეთ, რომ როგორც VEN- ებს, ასევე VTN- ებს შეუძლიათ იყვნენ როგორც ანგარიშის შემქმნელი, ისე ანგარიშის მომთხოვნი, ამიტომ ქვემოთ მოცემული ყველა დატვირთვის დაწყება შეიძლება ორივე მხარის მიერ.
- oadrRegisterReport - გამოიყენება მათი საანგარიშო შესაძლებლობების მეტამონაცემების ანგარიშში გამოსაქვეყნებლად
- oadrRegisteredReport - დაადასტურეთ oadrRegisterReport- ის მიღება, სურვილისამებრ მოითხოვეთ ერთ-ერთი შემოთავაზებული ანგარიში
- oadrCreateReport - გამოიყენება ანგარიშის მოსათხოვად, რომელიც ადრე შემოთავაზებული იყო VEN ან VTN
- oadrCreatedReport - აღიარეთ საანგარიშო თხოვნის მიღება
- oadrUpdateReport -მიგზავნეთ მოთხოვნილი ანგარიში, რომელიც შეიცავს ინტერვალის მონაცემებს
- oadr განახლებული ანგარიში - ვაღიარებთ ჩაბარებული ანგარიშის მიღებას
- oadr გაუქმება ანგარიში - გააუქმეთ ადრე მოთხოვნილი პერიოდული ანგარიში
- oadr გაუქმებული ანგარიში - აღიარეთ პერიოდული მოხსენების გაუქმება
- oadrResponse - გამოიყენება როგორც მიმწოდებლის საპასუხო რეაგირების ზოგიერთი გაცვლის ნიმუში, როდესაც განაცხადის ფენის პასუხი გადაეცემა სატრანსპორტო ფენის მოთხოვნით.
- oadrCreateOpt - გამოიყენება ორი მკაფიოდ განსხვავებული მიზნისთვის
- VEN– მა VTN– ს უნდა დაუკავშირდეს დროებითი ხელმისაწვდომობის გრაფიკს DR ღონისძიებებში მონაწილეობის შესაძლებლობის გათვალისწინებით
- VEN– ს შეუძლია ღონისძიებაში მონაწილე რესურსების კვალიფიკაცია
- oadrCreatedOpt - დაადასტურეთ oadrCreateOpt ტვირთის მიღება
- oadr გაუქმება -გაუქმეთ დროებითი ხელმისაწვდომობის გრაფიკი
- oadr გაუქმებულია - აღიარეთ დროებითი ხელმისაწვდომობის ანგარიშის გაუქმება
- oadrQuery რეგისტრაცია - გზა VEN– სთვის VTN– ების სარეგისტრაციო ინფორმაციის მოთხოვნის ფაქტიურად რეგისტრაციის გარეშე.
- oadrCreatePartyრეგისტრაცია - თხოვნა VEN– დან VTN– სკენ დარეგისტრირების შესახებ. შეიცავს ინფორმაციას VEN- ების შესაძლებლობების შესახებ.
- oadrCreatedPartyრეგისტრაცია - oadrQueryRegistration ან oadrCreatePartyRegistration პასუხი. შეიცავს VTN შესაძლებლობებს და სარეგისტრაციო ინფორმაციას, რომელიც საჭიროა VEN– ის ურთიერთქმედებისათვის
- oadrCancelPartyრეგისტრაცია - გამოიყენება VEN ან VTN მიერ რეგისტრაციის გაუქმების მიზნით
- oadrCancledPartyRegistration - პასუხი oadr– ზე გაუქმება PartyRegistration– ზე. აცხადებს რეგისტრაციის გაუქმების მიღებას
- oadrRequestრეგისტრაცია - ამ დატვირთვას იყენებს VTN Pull გაცვლის მოდელში VEN სიგნალისთვის, რეგისტრაციის თანმიმდევრობის თავიდან დასაწყებად
- oadrResponse - გამოიყენება როგორც მიმწოდებლის საპასუხო რეაგირების ზოგიერთი გაცვლის ნიმუში, როდესაც განაცხადის ფენის პასუხი გადაეცემა სატრანსპორტო ფენის მოთხოვნით.
- oadrPoll – ზოგადი პოლონური მექანიზმი B pro-სთვისfile რომელიც აბრუნებს დატვირთვას ნებისმიერი სხვა სერვისისთვის, რომელიც არის ახალი ან განახლებული.
- oadrResponse - გამოიყენება იმის ნიშნად, რომ ახალი ან განახლებული დატვირთვები არ არის ხელმისაწვდომი
- სქემის დატვირთვის ელემენტების ტერმინების განმარტება
ქვემოთ მოცემულია სქემა ელემენტების ანბანური სია, რომლებიც გამოიყენება OpenADR 2.0 დატვირთვაში. ნარატივი აღწერს მათ გამოყენებას, რადგან ის ეხება OpenADR– ს და მათი გამოყენება ტვირთის დატვირთვაში. როდესაც ელემენტის განმარტება შეიცვლება მისი დატვირთვის შესაბამისად, რომელიც მას შეიცავს ან მისი გამოყენების კონტექსტში, ეს აღინიშნება თხრობაში. ფესვების დატვირთვის განსაზღვრება გამორიცხულია, რადგან ეს განსაზღვრულია დანართში C.
- ac - ლოგიკური მნიშვნელობა, რომელიც მიუთითებს არის თუ არა ენერგეტიკული პროდუქტი ალტერნატიული მიმდინარეობა
- სიზუსტე - რიცხვი იმავე ერთეულებშია, რაც დატვირთვის ცვლადი ინტერვალისთვის. ნდობის შემთხვევაში, მიუთითებს პროგნოზის სავარაუდო ცვალებადობაზე. როდესაც ეს არის ReadingType, მიუთითებს კითხვის სავარაუდო შეცდომაზე.
- aggregatedPnode - აგრეგირებული ფასების კვანძი არის სპეციალიზირებული ფასწარმოქმნის კვანძი, რომელიც გამოიყენება ისეთი ნივთების მოდელირებისთვის, როგორიცაა სისტემის ზონა, ნაგულისხმევი ფასის ზონა, საბაჟო ფასების ზონა, საკონტროლო არე, აგრეგირებული თაობა, მთლიანი მონაწილე დატვირთვა, აგრეგირებული არამონაწილებული დატვირთვა, სავაჭრო ცენტრი, DCA ზონა
- ხელმისაწვდომი - ობიექტი, რომელიც შეიცავს თარიღის დროსა და ხანგრძლივობას EiOpt– ის ხელმისაწვდომობის გრაფიკისთვის
- baselineID - უნიკალური ID კონკრეტული საბაზისო ხაზისთვის
- საბაზისო სახელი - საბაზისო ხაზის აღწერითი სახელი
- კომპონენტები –
- ნდობა - სტატისტიკური ალბათობა იმისა, რომ დაზუსტებული მონაცემების წერტილი ზუსტია
- createdDateTime - შეიქმნა დატვირთვის თარიღი
- ვალუტა –
- ვალუტაPerKW –
- ვალუტაPerKWh –
- ვალუტაPerThm –
- მიმდინარე –
- მიმდინარე ღირებულება - PayloadFloat მნიშვნელობას ახორციელებს ღონისძიების ინტერვალი.
- საბაჟო ერთეული - გამოიყენება მორგებული ანგარიშების ზომის ინდივიდუალური ერთეულის დასადგენად
- თარიღი-დრო –
- dtstart - საქმიანობის, მონაცემების ან მდგომარეობის შეცვლის საწყისი დრო
- ხანგრძლივობა - მოვლენის, ანგარიშგების ან ხელმისაწვდომი დროის ინტერვალის დრო
- ხანგრძლივობა - საქმიანობის ხანგრძლივობა, მონაცემები ან მდგომარეობა
- eiActivePeriod - დროის ღონისძიებები, რომლებიც ეხება საერთო მოვლენას
- eiCreatedEvent - უპასუხეთ DR ღონისძიებაზე optIn ან optOut
- eiEvent - ობიექტი, რომელიც შეიცავს ყველა ინფორმაციას ერთი მოვლენისთვის
- eiEventBaseline - B პროfile
- eiEventSignal - ობიექტი, რომელიც შეიცავს ყველა ინფორმაციას მოვლენის ერთი სიგნალისთვის
- eiEventSignals - ინტერვალის მონაცემები ერთი ან მეტი მოვლენის სიგნალისთვის და / ან საბაზისო ხაზისთვის
- eiMarketContext - URI ცალსახად განსაზღვრავს მოთხოვნის რეაგირების პროგრამას
- eiReportID - მითითების ID ანგარიშისთვის
- eiRequestEvent - მოითხოვეთ ღონისძიება VTN– დან pull რეჟიმში
- eiResponse - მიუთითეთ მისაღებია თუ არა მიღებული დატვირთვა
- eiTarget - ამოიცნობს რესურსებს, რომლებიც დაკავშირებულია ლოგიკურ VEN ინტერფეისთან. მოვლენებისათვის, მითითებული მნიშვნელობები არის ღონისძიების მიზანი
- endDeviceAsset - EndDeviceAssets არის ფიზიკური მოწყობილობა ან მოწყობილობები, რომლებიც შეიძლება იყოს მრიცხველები ან სხვა ტიპის მოწყობილობები, რომლებიც შეიძლება საინტერესო იყოს
- ენერგია აშკარა - მოჩვენებითი ენერგია, გაზომილი ვოლტებშიampწინა საათი (VAh)
- ენერგია –
- ენერგია რეაქტიული - რეაქტიული ენერგია, ვოლტ-ampრეაქტიული საათები (VARh)
- ენერგია რეალური - რეალური ენერგია, ვატის საათები (Wh)
- eventDescriptor - ინფორმაცია ღონისძიების შესახებ
- eventID - ID მნიშვნელობა, რომელიც განსაზღვრავს DR მოვლენის კონკრეტულ მაგალითს.
- ღონისძიებაპასუხი - ობიექტის შემცველი ობიექტი, რომელიც პასუხობს ღონისძიებაში მონაწილეობის მოთხოვნას
- ღონისძიებაპასუხები - მიღებული მოვლენების optIn ან optOut პასუხები
- ღონისძიების სტატუსი - ღონისძიების მიმდინარე სტატუსი (შორეული, ახლო, აქტიური და ა.შ.)
- მხატვრული კოლექცია / ადგილმდებარეობა / პოლიგონი / ექსტერიერი / LinearRing
- სიხშირე –
- მარცვლიანობა – ეს არის დროის ინტერვალი სampled მონაცემები მოხსენების მოთხოვნაში.
- ჯგუფი ID - ამ ტიპის სამიზნე გამოიყენება მოვლენების, რეპორტებისა და ოპტის განრიგისთვის. ჩვეულებრივ, მნიშვნელობას ანიჭებს კომუნალური საშუალებები DR პროგრამაში ჩარიცხვის დროს
- ჯგუფის სახელი - ამ ტიპის სამიზნე გამოიყენება მოვლენების, რეპორტებისა და ოპტის განრიგისთვის. ჩვეულებრივ, მნიშვნელობას ანიჭებს კომუნალური საშუალებები DR პროგრამაში ჩარიცხვის დროს
- ჰერცი –
- ინტერვალი - ობიექტი, რომელიც შეიცავს მონაცემთა დროს და / ან ხანგრძლივობას, და მოქმედი მნიშვნელობა მოვლენის ან მონაცემების შემთხვევაში ანგარიშის შემთხვევაში.
- ინტერვალი - ერთი ან მეტი დროის ინტერვალით, რომლის დროსაც DR ღონისძიება აქტიურია ან ხელმისაწვდომია ანგარიშის მონაცემები
- საქონლის აღწერა - ანგარიშის ღონისძიების ერთეულის აღწერა
- ერთეული - ანგარიშის მონაცემთა ერთეულის ძირითადი საზომი ერთეული
- marketContext - URI, რომელიც განსაზღვრავს DR პროგრამას
- მეტრი Asset - MeterAsset არის ფიზიკური მოწყობილობა ან მოწყობილობები, რომლებიც ასრულებენ მრიცხველის როლს
- modificationDateTime - როდესაც მოვლენა შეცვლილია
- მოდიფიკაცია ნომერი - ღონისძიების შეცვლისას ყოველ ჯერზე იმატებს.
- მოდიფიკაცია მიზეზი - რატომ შეიცვალა ღონისძიება
- ბადე - MRID განსაზღვრავს ფიზიკურ მოწყობილობას, რომელიც შეიძლება იყოს CustomerMeter ან სხვა სახის EndDevices.
- კვანძი - კვანძი არის ადგილი, სადაც რაღაც იცვლება (ხშირად საკუთრებაში) ან ქსელში აკავშირებს. ბევრი კვანძი ასოცირდება მრიცხველთან, მაგრამ ყველა არაა.
- numDataSources –
- მოცულობა –
- oadr მიმდინარე –
- oadrDataQuality –
- oadrDeviceClass - მოწყობილობის კლასის სამიზნე - გამოიყენეთ მხოლოდ endDeviceAsset.
- oadr მოვლენა - ობიექტი, რომელიც შეიცავს მოთხოვნის რეაგირების ღონისძიებას
- oadr გაფართოება –
- oadrExtensionName -
- oadr გაფართოებები –
- oadrHttpPullModel - ლოგიკური მითითებით, სურს თუ არა VEN– ს გამკაცრების გაცვლის მოდელის გამოყენება
- oadrInfo - საკვანძო მნიშვნელობის წყვილი მომსახურების სპეციფიკური რეგისტრაციის ინფორმაცია
- oadrKey –
- oadrLevelOffset –
- oadrLoadControlState –
- oadrManualOverride - თუ სიმართლეა, დატვირთვის კონტროლი ხელით გადალახულია
- oadrMax –
- oadrMaxPeriod - მაქსიმალური სampხანგრძლივობის პერიოდი
- oadrMin –
- oadrMinPeriod - მინიმალური sampხანგრძლივობის პერიოდი
- ნორმალური –
- oadrOnChange - თუ სიმართლეა, მონაცემები ჩაიწერება მისი შეცვლისას, მაგრამ არაუმეტეს სიხშირეზე, ვიდრე მითითებულია minPeriod- ით.
- oadr Online - თუ სიმართლეა, მაშინ რესურსი / აქტივი ონლაინ რეჟიმშია, თუ მცდარია, ოფლაინშია.
- oadrPayload –
- oadrPayloadResourceStatus - მიმდინარე ინფორმაცია რესურსების სტატუსის შესახებ
- oadrPendingReports - პერიოდული ანგარიშების ჩამონათვალი კვლავ აქტიურია
- oadrPercentOffset –
- oadrProfile - პროfile მხარს უჭერს VEN ან VTN
- oadrProfileსახელი - OpenADR პროfile სახელი, როგორიცაა 2.0a ან 2.0b.
- oadrProfiles – OpenADR პროfileმხარდაჭერილია განხორციელებით
- oadr ანგარიში - ობიექტი, რომელიც შეიცავს ყველა ინფორმაციას ერთი დასკვნისთვის
- oadrReportDescription - ანგარიშის მწარმოებლის მიერ შემოთავაზებული ანგარიშის მახასიათებლების აღწერა. შეიცავს მეტამონაცემების ანგარიშში
- oadrReportOnly - ReportOnlyDeviceFlag
- oadrReportPayload - მონაცემთა წერტილის მნიშვნელობები ანგარიშებისთვის
- oadr მოითხოვა OadrPollFreq - VEN გაგზავნის oadrPoll დატვირთვას VTN მაქსიმუმ ერთხელ ამ ელემენტის მიერ განსაზღვრული თითოეული ხანგრძლივობისთვის
- oadrResponseRequired - აკონტროლებს, როდესაც საჭიროა optIn / optOut რეაგირება. შეიძლება იყოს ყოველთვის ან არასდროს
- oadrSamplingRate - Sampლინგის სიჩქარე ტელემეტრიის ტიპის მონაცემებისთვის
- oadrService –
- oadrServiceName - ამ ტიპის სამიზნე გამოიყენება მოვლენების, რეპორტებისა და ოპტის განრიგისთვის. ჩვეულებრივ, მნიშვნელობას ანიჭებს კომუნალური საშუალებები DR პროგრამაში ჩარიცხვის დროს
- oadrServiceSpecificInfo - მომსახურების სპეციფიკური ინფორმაცია რეგისტრაციის შესახებ
- oadrSetPoint –
- oadrSignedObject –
- oadr ტრანსპორტი - ტრანსპორტის სახელი, რომელსაც მხარს უჭერს VEN ან VTN
- oadrTransportAddress - ფესვის მისამართი, რომელიც გამოიყენება მეორე მხარესთან კომუნიკაციისთვის. საჭიროების შემთხვევაში უნდა შეიცავდეს პორტს
- oadrTransportName - OpenADR ტრანსპორტის სახელი, როგორიცაა simpleHttp ან xmpp
- oadr ტრანსპორტი - OpenADR ტრანსპორტი ახორციელებს განხორციელებას
- oadrUpdatedReport - აღიარეთ ანგარიშის მიღება
- oadrUpdateReport - გაგზავნეთ ადრე მოთხოვნილი ანგარიში
- oadrValue –
- oadrVenName - VEN სახელი. შეიძლება გამოყენებულ იქნას VTN GUI– ში
- oadrXml ხელმოწერა - განხორციელება მხარს უჭერს XML ხელმოწერას
- optID - იდენტიფიკატორი ოპტ – ინტერაქციისთვის
- optReason - ჩამოთვლილი მნიშვნელობა ოპტის მიზეზით, როგორიცაა x- გრაფიკი
- optType - optIn ან optOut მოვლენისთვის, ან გამოიყენება EiOpt სერვისისთვის vavailablityObject- ში განსაზღვრული opt გრაფიკის ტიპის მითითებისათვის
- პარტიის ID - ამ ტიპის სამიზნე გამოიყენება მოვლენების, რეპორტებისა და ოპტის განრიგისთვის. ჩვეულებრივ, მნიშვნელობას ანიჭებს კომუნალური საშუალებები DR პროგრამაში ჩარიცხვის დროს
- payloadFloat - მონაცემთა წერტილის მნიშვნელობა მოვლენის სიგნალებისთვის ან მიმდინარე ან ისტორიული მნიშვნელობების შესახებ.
- პნოდ - ფასების კვანძი პირდაპირ უკავშირდება კავშირის კვანძს. ეს არის ფასების ადგილმდებარეობა, რომლისთვისაც ბაზრის მონაწილეები წარმოადგენენ წინადადებებს, შეთავაზებებს, ყიდულობენ / ყიდიან CRR- ებს და მორიგდებიან.
- მიწოდების წერტილი –
- პუნქტი მიმღები –
- posList –
- ძალაუფლებისა - აშკარა სიმძლავრე, რომელიც იზომება ვოლტებში -amperes (VA)
- ენერგიის ატრიბუტები
- ძალა
- ძალა რეაქტიული - რეაქტიული სიმძლავრე, გაზომილი ვოლტ-ampრეაქტიული (VAR)
- powerReal - რეალური სიმძლავრე იზომება Watts (W) ან Joules / second (J / s)
- პრიორიტეტი - ღონისძიების პრიორიტეტი სხვა მოვლენებთან მიმართებაში (რაც უფრო დაბალია პრიორიტეტული რიცხვი. ნულის მნიშვნელობა (0) მიუთითებს პრიორიტეტს, რაც სტანდარტულად ყველაზე დაბალი პრიორიტეტია).
- თვისებები –
- პულსი - საანგარიშო მონაცემების წერტილი
- პულსი ფაქტორი - კვტ / სთ თითო რაოდენობაზე
- კვალიფიციური EventID - უნიკალური პირადობის მოწმობა ღონისძიებისთვის
- კითხვის ტიპი - მეტამონაცემები კითხვასთან დაკავშირებით, მაგალითად საშუალო ან მიღებული
- რეგისტრაცია ID - საიდენტიფიკაციო სარეგისტრაციო ოპერაციისთვის. არ შედის მოთხოვნის რეგისტრაციის საპასუხოდ, თუ ეს უკვე არ არის რეგისტრირებული
- პასუხი Limit - მოვლენების მაქსიმალური რაოდენობა დასაბრუნებლად oadrDistributeEvent დატვირთვაში
- reportBackDuration - შეატყობინეთ მოხსენებასთან ერთად თარიღი, ამ ხანგრძლივობის ყოველი გავლისთვის.
- reportDataSource - ამ მოხსენებაში მოცემული მონაცემების წყაროები. მაგampეს მოიცავს მეტრებს ან ქვემეტრებს. მაგampმაგალითად, თუ მრიცხველს შეუძლია უზრუნველყოს ორი განსხვავებული ტიპის გაზომვები, მაშინ თითოეული გაზომვის ნაკადი ცალკე იქნება იდენტიფიცირებული.
- reportInterval - ეს არის ანგარიშგების საერთო პერიოდი.
- reportName - ანგარიშის არჩევითი სახელი.
- reportRequestID - კონკრეტული ანგარიშის მოთხოვნის იდენტიფიკატორი
- reportSpecifier - მიუთითეთ სასურველი წერტილები კონკრეტულ ანგარიშში
- reportSpecifierID - კონკრეტული მეტამონაცემების ანგარიშის სპეციფიკაციის იდენტიფიკატორი
- ანგარიში თემა - მოწყობილობის კლასის სამიზნე - გამოიყენეთ მხოლოდ endDeviceAsset.
- reportToFollow - მიუთითებს, თუ ანგარიში (UpdateReport– ის სახით) უნდა დაბრუნდეს ანგარიშის გაუქმების შემდეგ
- ანგარიშის ტიპი - ანგარიშის ტიპი, როგორიცაა გამოყენება ან ფასი
- მოთხოვნა ID - ID გამოიყენება ლოგიკური გარიგების მოთხოვნისა და პასუხის გასაცემად
- რესურსი - ამ ტიპის სამიზნე გამოიყენება მოვლენების, რეპორტებისა და ოპტის განრიგისთვის. ჩვეულებრივ, მნიშვნელობას ანიჭებს კომუნალური საშუალებები DR პროგრამაში ჩარიცხვის დროს
- პასუხი –
- საპასუხო კოდი - 3 ციფრიანი საპასუხო კოდი
- პასუხი აღწერა - პასუხის სტატუსის თხრობითი აღწერა
- პასუხები –
- RID - ReferenceID ამ მონაცემთა წერტილისთვის
- მომსახურება - ამ ტიპის სამიზნე გამოიყენება მოვლენების, რეპორტებისა და ოპტის განრიგისთვის. ჩვეულებრივ, მნიშვნელობას ანიჭებს კომუნალური საშუალებები DR პროგრამაში ჩარიცხვის დროს
- serviceDeliveryPoint - ლოგიკური წერტილი ქსელში, სადაც სერვისის მფლობელობა იცვლება ხელში. ეს არის ერთ – ერთი პოტენციური სერვისული პუნქტი ServiceLocation– ში, რომელიც უზრუნველყოფს მომსახურებას CustomerAg შეთანხმების შესაბამისად. გამოიყენება იმ ადგილას, სადაც შესაძლებელია მრიცხველის დაყენება.
- მომსახურებაადგილობა - მომხმარებელთა ServiceLocation– ს აქვს ერთი ან მეტი ServiceDeliveryPoint (წერტილები), რომლებიც, თავის მხრივ, ეხება მრიცხველებს. მდებარეობა შეიძლება იყოს წერტილი ან მრავალკუთხედი, რაც დამოკიდებულია კონკრეტულ გარემოებებზე. განაწილებისთვის, ServiceLocation, როგორც წესი, არის კომუნალური მომხმარებლის შენობის ადგილმდებარეობა.
- სიგნალი ID - კონკრეტული ღონისძიების სიგნალის უნიკალური იდენტიფიკატორი
- სიგნალი სახელი - სიგნალის სახელი, როგორიცაა SIMPLE
- სიგნალის გადახდა - სიგნალის მნიშვნელობები ღონისძიებებისა და საბაზისო ხაზებისთვის
- siScaleCode - შეფასების ძირითადი საზომი ერთეულის მასშტაბური ფაქტორი
- specifierPayload - ღია
- დაწყებული - ღონისძიების დასაწყებად რანდომიზაციის ფანჯარა
- statusDateTime - ამ artifact– ის მითითება თარიღი და დრო.
- ტემპერატურა –
- testEvent - ყალბი გარდა სხვა რამ მიუთითებს სატესტო ღონისძიებაზე
- ტექსტი –
- თერმი –
- ტოლერანტობა - ქვე-ობიექტი, რომელიც შეიცავს მოვლენის რანდომიზაციის მოთხოვნებს
- მოითმენს - ობიექტი, რომელიც შეიცავს მოვლენის რანდომიზაციის მოთხოვნებს
- transportInterface - სატრანსპორტო ინტერფეისი გამოკვეთს კიდეებს სატრანსპორტო სეგმენტის ორივე ბოლოს.
- uid - გამოიყენება, როგორც ინდექსი, ინტერვალების დასადგენად. უნიკალური იდენტიფიკატორი
- ღირებულება –
- ხელმისაწვდომობა - გრაფიკი, რომელიც ასახავს მოწყობილობის ხელმისაწვდომობას DR ღონისძიებებში მონაწილეობისთვის
- venID - უნიკალური იდენტიფიკატორი VEN– სთვის
- ტtage –
- vtn კომენტარი - ნებისმიერი ტექსტი
- vtnID - უნიკალური იდენტიფიკატორი VTN
- x-ei შეტყობინება - VEN– მა უნდა მიიღოს DR მოვლენის დატვირთვა dtstart– მდე ამ ხანგრძლივობის გამოკლებით.
- x-eiRampზევით - ხანგრძლივობა ღონისძიების დაწყების დაწყებამდე ან მის შემდეგ, რომლის დროსაც დატვირთული დატვირთვა უნდა მოხდეს.
- x-ei აღდგენა - ხანგრძლივობა მოვლენის დასრულებამდე ან მის შემდეგ, რომლის დროსაც დატვირთული დატვირთვა უნდა მოხდეს.
ჩამოთვლილი მნიშვნელობების ტერმინები
- აქტიური - ღონისძიება დაიწყო და ამჟამად აქტიურია.
- გაუქმდა - ღონისძიება გაუქმებულია.
- დასრულდა - ღონისძიება დასრულებულია.
- შორს - შორეულ მომავალში გაიმართება ღონისძიება. იმის ზუსტი განმარტება, თუ რამდენად შორს იქნება ეს მომავალში, დამოკიდებულია ბაზრის კონტექსტზე, მაგრამ, როგორც წესი, ნიშნავს მეორე დღეს.
- ახლოს - ღონისძიება უახლოეს მომავალში. ზუსტი განსაზღვრება იმისა, თუ რამდენად ახლოს იქნება მომავალში მომლოდინე ღონისძიება, დამოკიდებულია ბაზრის კონტექსტზე. .იწყება x-eiR მოვლენის ეფექტური დაწყების პარალელურადampᲓროთა განმავლობაში. თუ x-eiRampUp არ არის განსაზღვრული ღონისძიებისთვის, ეს სტატუსი არ იქნება გამოყენებული ღონისძიებისთვის.
- არცერთი - არანაირი ღონისძიება არ ელოდება
- ვალუტა
- აშშ დოლარი - შეერთებული შტატების დოლარები
- ბევრისთვის, რომ ჩამოთვალოთ აქ, იხილეთ სქემა
- ძალაუფლება
- ჯ/ს - ჯოულ-წამი
- W - უოტსი
- ტემპერატურა
- ცელსიუსს –
- ფარენჰეიტი –
- ახალი მნიშვნელობა არ არის - გამოყენებულია წინა მნიშვნელობა –
- არ არის ხარისხი - არ აქვს მნიშვნელობა –
- ხარისხის ცუდი - Comm მარცხი –
- ხარისხის ცუდი - კონფიგურაციის შეცდომა –
- ხარისხის ცუდი - მოწყობილობის უკმარისობა –
- ხარისხის ცუდი - ბოლო ცნობილი მნიშვნელობა –
- ხარისხის ცუდი - არა სპეციფიკური –
- ხარისხის ცუდი - არ არის დაკავშირებული –
- ხარისხის ცუდი - სამსახურიდან გამოსული –
- ხარისხის ცუდი - სენსორის უკმარისობა –
- ხარისხი კარგი - ადგილობრივი გადალახვა –
- ხარისხი კარგი - არა სპეციფიკური –
- ხარისხის ლიმიტი - ველი / მუდმივი –
- ხარისხის ლიმიტი - ველი / მაღალი –
- ხარისხის ლიმიტი - ველი / დაბალი –
- ხარისხის ლიმიტი - ველი / არა –
- ხარისხი გაურკვეველია - ევროკავშირის ერთეულებმა გადააჭარბა –
- ხარისხის გაურკვეველი - ბოლო გამოსაყენებელი მნიშვნელობა –
- ხარისხი გაურკვეველია - არა სპეციფიკური –
- ხარისხი გაურკვეველია - სენსორი არ არის ზუსტი –
- ხარისხის გაურკვეველი - ქვე ნორმალური –
- ყოველთვის - ყოველთვის გაგზავნეთ პასუხი მიღებულ ყველა ღონისძიებაზე.
- არასოდეს - არასდროს უპასუხო.
ჩამოთვლილი მიზეზების არჩევა.
- ეკონომიკური –
- სასწრაფო –
- უნდა გაუშვა –
- არ მონაწილეობს –
- outageRunStatus –
- გადააჭარბა Status –
- მონაწილეობს –
- x- გრაფიკი –
- მარტივი Http –
- xmpp –
- ოპტიმიზაცია - მითითება, რომ VEN მიიღებს მონაწილეობას ღონისძიებაში, ან EiOpt სერვისის შემთხვევაში, ტიპის გრაფიკი, რომელიც მიუთითებს, რომ რესურსი ხელმისაწვდომი იქნება.
- უარის თქმა - მითითება, რომ VEN არ მიიღებს მონაწილეობას ღონისძიებაში, ან EiOpt სერვისის შემთხვევაში გრაფიკის ტიპი, რომელიც მიუთითებს, რომ რესურსი არ იქნება ხელმისაწვდომი
- გამოყოფილი - მეტრი მოიცავს რამდენიმე [რესურსს] და გამოყენება ხდება გარკვეული მონაცემების გამოთვლის საშუალებით.
- კონტრაქტი - მიუთითებს, რომ კითხვა არის ფორმალური, ანუ იტყობინება შეთანხმებული ტარიფებით
- მიღებული - გამოყენების შესახებ ვლინდება სამუშაო დროის, ნორმალური მუშაობის და ა.შ.
- პირდაპირი წაკითხვა - კითხვა იკითხება აპარატიდან, რომელიც იზრდება ერთფეროვნად და გამოყენება უნდა გამოითვალოს დაწყებული და შეჩერებული კითხვების წყვილიდან.
- სავარაუდო - გამოიყენება, როდესაც კითხვა არ არის იმ სერიებში, რომელშიც ყველაზე მეტი კითხვაა წარმოდგენილი.
- ჰიბრიდული - თუ არის აგრეგირებული, ეხება სხვადასხვა კითხვის ტიპებს მთლიანი რიცხვის მიხედვით.
- საშუალო - კითხვა არის საშუალო მნიშვნელობა გრანულარულობაში მითითებული პერიოდის განმავლობაში
- წმინდა - მეტრი ან [რესურსი] ამზადებს მთლიანი მოხმარების საკუთარ გაანგარიშებას დროთა განმავლობაში.
- პიკი - კითხვა არის პიკური (ყველაზე მაღალი) მნიშვნელობა მარცვლოვნებაში მითითებული პერიოდის განმავლობაში. ზოგიერთ გაზომვას შეიძლება უფრო აზრი ჰქონდეს, როგორც ყველაზე დაბალი მნიშვნელობა. შეიძლება არ შეესაბამებოდეს საერთო კითხვებს. ძალაშია მხოლოდ ნაკადის სიჩქარის ერთეულის ბაზებზე, მაგ. ენერგია არა ენერგია.
- დაპროექტებული - მიუთითებს კითხვა მომავალში და ჯერ არ არის გაზომული.
- შეაჯამა - რამდენიმე მეტრი ერთად უზრუნველყოფს ამ [რესურსის] კითხვას. ეს კონკრეტულად განსხვავებულია, ვიდრე აგრეგირებული, რომელიც ეხება მრავალ [რესურსს] ერთ დატვირთვაში. აგრეთვე ჰიბრიდული.
- x- არ არის გამოყენებული - Არ მიესადაგება
- x-RMS - Root Mean Square
- ისტორია_მწვანე ღილაკი - ანგარიში, რომელიც შეიცავს მწვანე ღილაკის მონაცემებს ატომის კვების სქემის სტრუქტურაში
- HISTORY_USAGE - ანგარიში, რომელიც შეიცავს ჰისტორიული ენერგიის გამოყენების მონაცემებს
- METADATA_HISTORY_GREENBUTTON - მეტამონაცემების ანგარიში, რომელიც განსაზღვრავს HISTORY_GREENBUTTON ანგარიშების ანგარიშგების შესაძლებლობებს
- METADATA_HISTORY_USAGE - მეტამონაცემების ანგარიში, რომელიც განსაზღვრავს HISTORY_USAGE ანგარიშების ანგარიშგების შესაძლებლობებს
- METADATA_TELEMETRY_STATUS - მეტამონაცემების ანგარიში, რომელიც განსაზღვრავს TELEMETRY_STATUS ანგარიშების ანგარიშგების შესაძლებლობებს
- METADATA_TELEMETRY_USAGE - მეტამონაცემების ანგარიში, რომელიც განსაზღვრავს TELEMETRY_USAGE ანგარიშების ანგარიშგების შესაძლებლობებს
- TELEMETRY_STATUS - ანგარიში, რომელიც შეიცავს რეალურ დროში რესურსების სტატუსის შესახებ ინფორმაციას, როგორიცაა ონლაინ სახელმწიფო
- TELEMETRY_USAGE - ანგარიში, რომელიც შეიცავს რეალურ დროში ენერგიის გამოყენების ინფორმაციას
ჩამოთვლილი მნიშვნელობა, რომელიც იძლევა მოწოდებული ანგარიშის ტიპს.
- ხელმისაწვდომია EnergyStorage - შესაძლებლობები ენერგიის შემდგომი შენახვისთვის, შესაძლოა მიზნობრივი ენერგიის შენახვაში მისასვლელად
- avg მოთხოვნა - საშუალო გამოყენება გრანულარულობით მითითებულ ხანგრძლივობაზე. დამატებითი ინფორმაციისთვის იხილეთ მოთხოვნა.
- საშუალო გამოყენება - საშუალო გამოყენება გრანულარულობით მითითებულ ხანგრძლივობაზე. დამატებითი ინფორმაციისთვის იხილეთ გამოყენება.
- საბაზისო - შეიძლება იყოს მოთხოვნა ან გამოყენება, როგორც მითითებულია ItemBase. მიუთითებს რა იქნებოდა [გაზომვა], რომ არა ღონისძიება ან რეგულაცია. ანგარიში ფორმატის საწყისი ხაზია.
- deltaDemand - მოთხოვნის ცვლილება საბაზისო ხაზთან შედარებით. დამატებითი ინფორმაციისთვის იხილეთ მოთხოვნა
- deltaSetPoint - ცვლილებები მითითებულ პუნქტში წინა გრაფიკიდან.
- დელტა - გამოყენების შეცვლა საბაზისო ხაზთან შედარებით. დამატებითი ინფორმაციისთვის იხილეთ გამოყენება
- მოთხოვნა - ანგარიში მიუთითებს ერთეულების ოდენობაზე (დასახელებულია ItemBase ან EMIX პროდუქტში). დატვირთვის ტიპი არის რაოდენობა. ტიპიური ItemBase არის რეალური ენერგია.
- გადახრა - განსხვავება ზოგიერთ ინსტრუქციასა და რეალურ მდგომარეობას შორის.
- downRegulationCapacity ხელმისაწვდომი - დისპეტჩერიზაციის რეგულირების მოცულობა, რომელიც გამოხატულია EMIX Real Power– ით. დატვირთვა ყოველთვის გამოიხატება როგორც პოზიტიური რაოდენობა.
- დონე - მარტივი დონე ბაზრიდან თითოეული ინტერვალისთვის.
- ოპერაციული სახელმწიფო - რესურსის განზოგადებული მდგომარეობა, როგორიცაა ჩართვა / გამორთვა, შენობის დატვირთვა და ა.შ. მოითხოვს განაცხადის სპეციფიკურ დატვირთვის გაფართოებას.
- პროცენტი მოთხოვნა - პროცენტიtagმოთხოვნის ე
- პროცენტული გამოყენება - პროცენტიtagე გამოყენება
- ძალაუფლების ფაქტორი - ენერგიის ფაქტორი რესურსისთვის
- ფასი - თითო საქონლის ბაზის ფასი თითოეულ ინტერვალზე
- კითხვა - ანგარიში მიუთითებს კითხვას, როგორც მეტრიდან. საკითხავები დროის მომენტებია, დროთა განმავლობაში ცვლილებები შეიძლება გამოითვალოს თანმიმდევრობით კითხვას შორის არსებული სხვაობიდან. დატვირთვის ტიპი არის float
- რეგულირება პუნქტი - რეგულაციის მითითებული პუნქტი, როგორც ინსტრუქციას იძლევა, როგორც მარეგულირებელი მომსახურების ნაწილი
- setPoint - მოხსენებაში მითითებულია ამჟამად მითითებული თანხა (დასახელებულია ItemBase- ში ან EMIX პროდუქტში). ეს შეიძლება იყოს VTN– დან გაგზავნილი მითითებული წერტილის კონტროლის მნიშვნელობის დადასტურება / დაბრუნება. დატვირთვის ტიპი არის რაოდენობა. ტიპიური ItemBase არის რეალური ენერგია.
- შენახული ენერგია - შენახული ენერგია გამოხატულია როგორც რეალური ენერგია, ხოლო დატვირთვა გამოხატულია როგორც რაოდენობა.
- targetEnergyStorage - სამიზნე ენერგია გამოხატულია როგორც რეალური ენერგია, ხოლო დატვირთვა გამოხატულია როგორც რაოდენობა.
- upRegulationCapacity ხელმისაწვდომი - დისპეტჩერიზაციის რეგულირების მოცულობა, გამოხატული EMIX Real Power– ით. დატვირთვა ყოველთვის გამოიხატება როგორც პოზიტიური რაოდენობა.
- გამოყენება - ანგარიში მიუთითებს ერთეულების ოდენობაზე (დასახელებულია ItemBase- ში ან EMIX პროდუქტში) გარკვეული პერიოდის განმავლობაში. დატვირთვის ტიპი არის რაოდენობა. ტიპიური ItemBase არის RealEnergy
- x- რესურსი სტატუსი - პროცენტიtagმოთხოვნის ე
- p - პიკო 10 ** - 12
- n - ნანო 10 ** - 9
- მიკრო - მიკრო 10 ** - 6
- m - მილი 10 ** - 3
- c - ცენტი 10 ** - 2
- d - 10 დეკემბერი ** - 1
- k - კილო 10 ** 3
- M - მეგა 10 ** 6
- G - გიგა 10 ** 9
- T - ტერა 10 ** 12
- არცერთი - მშობლიური მასშტაბი
- BID_ENERGY - ეს არის ენერგიის რაოდენობა იმ რესურსიდან, რომელიც პროგრამაში იქნა შეტანილი
- BID_LOAD - ეს არის დატვირთვის ოდენობა, რომელიც რესურსმა შეიტანა პროგრამაში
- BID_PRICE - ეს არის ფასი, რომელსაც რესურსი სთავაზობდა
- CHARGE_STATE - ენერგიის შემნახველი რესურსის მდგომარეობა
- DEMAND_CHARGE - ეს არის მოთხოვნის გადასახადი
- ELECTRICITY_PRICE - ეს არის ელექტროენერგიის ღირებულება
- ENERGY_PRICE - ეს არის ენერგიის ღირებულება
- LOAD_CONTROL დატვირთვის გამოსწორება ნათესავი მნიშვნელობებით
- LOAD_DISPATCH - ეს გამოიყენება დატვირთვის გასაგზავნად
- მარტივი – ამორტიზებული – A pro-სთან უკუღმა თავსებადობისთვისfile
- მარტივი - მარტივი დონეები (შეესაბამება OpenADR 2.0a)
ჩამოთვლილი მნიშვნელობა, რომელიც აღწერს სიგნალის ტიპს, როგორიცაა დონე ან ფასი
- დელტა - სიგნალი მიუთითებს ოდენობის შესაცვლელად, ვიდრე ის გამოიყენებოდა სიგნალის გარეშე.
- დონე - სიგნალი მიუთითებს პროგრამის დონეზე.
- გამრავლებაr - სიგნალი მიუთითებს მიწოდების ან გამოყენების მიმდინარე სიჩქარეზე გამოყენებული მულტიპლიკატორისგან, რაც გამოიყენებოდა სიგნალის გარეშე.
- ფასი - სიგნალი მიუთითებს ფასზე.
- ფასი მულტიპლიუსიr - სიგნალი მიუთითებს ფასის მულტიპლიკატორზე. გახანგრძლივებული ფასი არის გამოთვლილი ფასის ღირებულება გამრავლებული ერთეულების რაოდენობაზე.
- შედარებითი - სიგნალი მიუთითებს ფარდობით ფასზე.
- მითითებული წერტილი - სიგნალი მიუთითებს ერთეულების მიზნობრივ რაოდენობაზე.
- x-loadControlCapacity – ეს არის ინსტრუქცია დატვირთვის კონტროლერისთვის, რომ იმუშაოს გარკვეულ პროცენტულ დონეზეtage მისი მაქსიმალური დატვირთვის მოხმარების სიმძლავრე. ეს შეიძლება დაფიქსირდეს დატვირთვის კონკრეტულ კონტროლერებზე, რათა გააკეთონ ისეთი რამ, როგორიცაა ველოსიპედით მოძრაობა. გაითვალისწინეთ, რომ 1.0 ეხება 100% მოხმარებას. მარტივი ON/OFF ტიპის მოწყობილობების შემთხვევაში, მაშინ 0 = OFF და 1 = ON.
- x-loadControlLevelOffset - დისკრეტული მთელი რიცხვების დონეები, რომლებიც შედარებით არის ნორმალური მოქმედებები, სადაც 0 არის ნორმალური მოქმედებები.
- x-loadControlPercentOffset - პროცენტიtage ცვლილება ნორმალური დატვირთვის კონტროლის ოპერაციებიდან.
- x-loadControlSetpoint - დატვირთვის კონტროლერის მითითებული წერტილები.
– OpenADR A and B Profile განსხვავებები
ერთადერთი სერვისი, რომელსაც მხარს უჭერს A პროfile არის EiEvent სერვისი. EiEvent ობიექტი გამარტივებულია A pro-შიfile შემდეგი შეზღუდვებით:
- დასაშვებია მხოლოდ ერთი სიგნალი თითო ღონისძიებაზე და ეს სიგნალი უნდა იყოს OpenADR კარგად ცნობილი სიგნალი SIMPLE.
- შეზღუდული ღონისძიების მიზანმიმართვა ხორციელდება მხოლოდ venID, groupID, resourceID და partyID მხარდაჭერით. (EiEvent: eiTarget).
- მოწყობილობის კლასებით სიგნალის დონეზე დამიზნება არ არის მხარდაჭერილი (eiEventSignal: eiTarget: endDeviceAsset).
- საბაზისო ხაზები მხარდაჭერილი არ არის (eiEvent: eiEventSignals: eiEventBaseline).
- modificationDateTime და modificationReason არ არის მხარდაჭერილი.
- საბოლოო წერტილი URL მარტივი HTTP- ისთვის 2.0b- ში არის:
- https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>
გარკვეული დატვირთვის ელემენტები, რომლებიც საჭირო იყო A პრო-შიfile ახლა არჩევითია B პროშიfile, მათ შორის:
- მიმდინარე ღირებულება
- OpenADR უსაფრთხოების სერთიფიკატები
OpenADR შესაბამისობის წესები მოითხოვს შემდეგს:
- TLS ვერსია 1.2 გამოიყენება X.509 სერთიფიკატების გაცვლისთვის
- VTN– ს უნდა ჰქონდეს SHA256 ECC და RSA სერთიფიკატები
- VEN- ებს შეუძლიათ მხარი დაუჭირონ SHA256 ECC და RSA სერთიფიკატებს და ორივე მხარი დაუჭირონ
- ორივე VTN და VEN უნდა იყოს კონფიგურირებული, რომ მოითხოვონ კლიენტის სერთიფიკატები, თუ ისინი აპირებენ შეასრულონ სატრანსპორტო სერვერის როლი (ე.ი. პასუხობენ მეორე მხარის მოთხოვნებს)
- ორივე VTN– მა და VEN– მა უნდა უზრუნველყონ კლიენტის სერთიფიკატი, როდესაც მეორე მხარე ითხოვს TLS– ის მოლაპარაკებების პროცესში.
NetworkFX-ის მიერ მოწოდებული სერთიფიკატები იქნება სპეციფიკური RSA ან ECC. ამ სერთიფიკატების შექმნა შეიძლება მოხდეს NetworkFX-ზე ფორმების შევსების შედეგად web საიტი, რათა მოითხოვოს სატესტო სერთიფიკატები ან შეიძლება იყოს წარმოების სერთიფიკატების მოთხოვნის შედეგი სერტიფიკატის ხელმოწერის მოთხოვნის (CSR) მეშვეობით. მეთოდის მიუხედავად, შემდეგი fileუზრუნველყოფილი იქნება (მაგampნაჩვენებია):
- ძირეული სერთიფიკატი
- შუალედური ფესვის სერტიფიკატი
- მოწყობილობის სერთიფიკატი
- პირადი გასაღები
ზოგადად, პირადი გასაღები გამოიყენება VEN ან VTN-ის მიერ გაგზავნილი ტვირთის დაშიფვრისთვის. მოწყობილობის სერთიფიკატი არის უნიკალური საიდენტიფიკაციო ინფორმაციის ნაკრები VEN ან VTN-ის შესახებ, რომელიც შექმნილია სერტიფიკატის ორგანოს მიერ და დაშიფრულია პირადი გასაღების გამოყენებით. ფესვი და შუალედური files გამოიყენება მოწყობილობის სერთიფიკატის გასაშიფრად და იმის დასადასტურებლად, რომ სერტიფიკატი მოვიდა სანდო ორგანოსგან.
Java გარემოში, რომელიც იყენებს JSSE– ს, არსებობს ორი სერთიფიკატის მაღაზია. ერთს Trust Store ჰქვია და გამოიყენება Root სერთიფიკატის დასადგენად. მეორეს Key Store ეწოდება და ის გამოიყენება სერთიფიკატების ჯაჭვის შესანახად, რომელიც შედგება მოწყობილობის სერთიფიკატის შუალედური სერთიფიკატისგან, ასევე პირადი გასაღებისაგან.
გთხოვთ გაითვალისწინოთ, რომ XMPP ტრანსპორტის გამოყენებისას VEN ურთიერთობა აქვს XMPP სერვერთან და არა უშუალოდ VTN. ასე რომ, სერტიფიკატების კონფიგურაცია XMPP სერვერში უნდა იყოს VTN– ს ეკვივალენტური. VTN– სა და XMPP სერვერს შორის კომუნიკაცია VEN– სთვის გამჭვირვალეა და არსებითად პირადი რგოლია. ამის მიუხედავად, მოვაჭრეების უმეტესობამ გამოიყენა VEN სერტიფიკატების ნაკრები VTN– ში XMPP სერვერთან კომუნიკაციისას.
თუ იყენებთ OpenFire- ს, როგორც თქვენს XMPP სერვერს, არსებობს კიდევ ერთი შეზღუდვა, რომელიც უნდა გაითვალისწინოთ. OpenFire მოითხოვს, რომ კლიენტის მოწყობილობის სერთიფიკატებში გამოყენებული CN სახელი ემთხვეოდეს XMPP სერვერზე კონფიგურირებულ XMPP მომხმარებლის სახელის მოწყობილობებს. ამან შეიძლება გამოიწვიოს ზოგიერთი უცნაური კლიენტის სახელი, ვინაიდან VEN სერთიფიკატებზე CN- ის სახელისთვის გამოიყენება MAC მსგავსი მისამართი (OpenADR უსაფრთხოების მოთხოვნების ნაწილი)
დაბოლოს, VEN– ებისა და VTN– ების უმეტესობა სატრანსპორტო კლიენტის როლის შესრულებისას შეეცდება დაადასტუროს, რომ სატრანსპორტო სერვერის მიერ მოწოდებული სერტიფიკატის CN ველს აქვს CN სახელი, რომელიც ემთხვევა სერტიფიკატის მიმწოდებელი პირის მასპინძელ სახელს. ეს შეიძლება იყოს ურთიერთქმედების პრობლემების კიდევ ერთი წყარო სერთიფიკატების გაცვლისას. მასპინძლის სახელის გადამოწმება, როგორც წესი, შეიძლება პროგრამულად გამორთული იყოს, ამ ტიპის პრობლემების გამოსაყოფად.
OpenADR 2.0 მოთხოვნაზე რეაგირების პროგრამის სახელმძღვანელო - ჩამოტვირთვა [ოპტიმიზირებული]
OpenADR 2.0 მოთხოვნაზე რეაგირების პროგრამის სახელმძღვანელო - ჩამოტვირთვა
