Global research

2026 оны 10 сарын 14 | Хувилбар 1.6

#01Шийдвэрийн хураангуй

Монгол Улсын төлөвлөлтийн суурь: нийт 1,000,000 цахилгааны тоолуур. Энэ нь захиалагчийн өгсөн тооцооны таамаглал бөгөөд албан ёсны тооллогын баталгаажсан статистик биш. PowerGrid-ийн улсын хэмжээний зорилтот хамрах хүрээг энэ тоогоор тооцно. Нийт тоолуурын тоо нь хэрэглэгчийн тоо, одоо алсаас уншигдах тоолуурын тоо, шинээр худалдан авах төхөөрөмжийн тоотой заавал тэнцэхгүй.

PowerGrid-ийг үндэсний хэмжээнд өргөжүүлэх боломжтой хэмжилтийн өгөгдлийн платформ болгон хөгжүүлэхийг санал болгож байна. Эхний хөрөнгө оруулалтыг бодит заалт цуглуулах, өгөгдлийн чанар, тоолуурын бүртгэл, сүлжээний холбоос, баланс, командын баталгаажуулалтад төвлөрүүлнэ. Төлбөр болон хэрэглэгчийн үйлчилгээг эдгээр баталгаатай өгөгдөл дээр нэмнэ.

Олон улсын сайн жишиг нэг бүтээгдэхүүнд төвлөрдөггүй. Финландын өгөгдөл солилцоо, Австралийн заалтын чанар ба хувилбарын түүх, Францын өгөгдөлд хандах зохицуулалт, АНУ-ын тасралтын хяналт, Японы байнгын ашиглалт, Энэтхэгийн хэрэглэгчийн хамгаалалт нь PowerGrid-ийн өөр өөр шаардлагыг тодорхойлж өгнө.

Судалгааны хамрах хүрээ: Узбекистан болон дэлхийн өөр есөн улсын туршлага. 1.3 хувилбарт ЕХ-ны «My Energy Data» тайлан, 2023/1162 хэрэгжүүлэх журам, Данийн DataHub, Европын зах зээлийн үүргийн загвар, Их Британийн DNO нууцлалын шаардлага, IEC CIM болон IEC 62351-8-д тулгуурласан өгөгдөлд хандах эрхийн бүлгийг нэмэв. Үндэсний систем, нэг том операторын хэрэгжилт, олон төслийн нийлбэр тайланг тус тусын хамрах хүрээнд үнэлэв. Төлөвлөгөө, суурилуулсан тоо, холбогдсон тоо, ашиглалтад зөв ажиллаж буй тоог хооронд нь адилтгаагүй.

Баримтаар тогтоосон дүгнэлтүүдэд [S01] хэлбэрийн эх сурвалж хавсаргав. PowerGrid-ийн архитектур, босго үзүүлэлт, хугацаа, төсөв боловсруулах загвар нь энэ тайлангийн санал бөгөөд батлагдсан гэрээний шаардлага биш.

#021 Судалгааны арга ба системийн хамрах хүрээ

Зорилго нь дэлхийд хамгийн олон тоолууртай системийг эрэмбэлэх бус, PowerGrid-ийн хөгжүүлэлтийн эрсдэлийг бууруулах хэрэгжихүйц шаардлага гаргах юм. Үндсэн эх сурвалж нь оператор, зохицуулагч, төрийн байгууллага, хөгжлийн банк, албан ёсны программын репозиторийн мэдээлэл болно.

#Нотолгоог ашигласан зарчим

Операторын тайлан нь тухайн байгууллагын өөрийн мэдээлэл; аудитын тайлан нь хөндлөнгийн үнэлгээ; тендер болон хөтөлбөрийн зорилт нь хүссэн үр дүнг илэрхийлнэ. Эдгээрийг ялгаж уншина. Хуучин хэрэгжилтийн тайланг тогтвортой архитектурын сургамжид ашигласан бөгөөд түүний тоон үзүүлэлтийг 2026 оны бодит төлөв гэж тайлбарлаагүй.

#Үндэсний хэмжээний гэдгийг хэрхэн ойлгох вэ

Нэгдсэн таних дугаар, нийтлэг өгөгдлийн гэрээ, байгууллага хоорондын эрх, ашиглалтын хариуцлагыг улс даяар ижил болгоно. Бүх тоолуурын харилцааг нэг процесс, нэг серверт төвлөрүүлэх шаардлагагүй. Холболтын адаптеруудыг бүсээр байрлуулж, өгөгдлийг нэгдсэн дүрмээр нэгтгэж болно.

Хэмжилтийн интервал, серверт ирэх давтамж, хэрэглэгчид харагдах саатал нь гурван өөр үзүүлэлт. Жишээлбэл 15 минутын хэмжилт хадгалдаг тоолуурын мэдээлэл өдөрт нэг удаа ирдэг байж болно. PowerGrid-ийн дэлгэц сүүлийн хэмжилтийн цаг болон сүүлийн хүлээн авсан цагийг тусад нь харуулах ёстой.

#Тайланг ашиглах дараалал

2 дугаар бүлгийн матрицаас сонголтоо харж, 3–7 дугаар бүлгийн кейсээр үндэслэлийг уншина. 8–12 дугаар бүлэг нь архитектур, өгөгдөл, аюулгүй байдал, одоогийн кодод хийх өөрчлөлтийг тайлбарлана. 13–16 дугаар бүлэг нь туршилтын босго, багтаамж, эдийн засаг, хэрэгжүүлэх ажлын дараалал болно. 17 дугаар бүлэг нь хэн ямар өгөгдлийг ямар үндэслэлээр харах, засаг захиргаа болон бусад бүлгээр шүүх системийг хэрхэн тусад нь барих эрхийн загварыг тайлбарлана. 18 дугаар бүлэг нь зорилтын эрэмбэ болон Монголын нөхцөлд гаргасан шийдвэрүүд (урсгалын хяналт, гар утсаар төлөх, prepaid) болно.

#032 Олон улсын туршлагын харьцуулалт

Доорх хүснэгтийн эрэмбэ нь чансаа биш. “Нэн түрүүнд” гэдэг нь PowerGrid-ийн одоогийн хэрэгцээнд шууд хамаатай, “дараагийн шат” гэдэг нь үндсэн өгөгдөл баталгаажсаны дараа хэрэгжүүлэх боломжийг илэрхийлнэ.

#Шууд хуулбарлахгүй зүйлс

Австралийн 5 минутын зах зээлийн тооцоог Монголын тарифын заавал биелүүлэх шаардлага гэж үзэхгүй. Энэтхэгийн prepaid болон Францын өгөгдөл хадгалах нөхцөлийг Монголд шууд хэрэглэхгүй. PowerGrid эдгээрийг тохируулж болох чадвар хэлбэрээр дэмжиж, дотоодын батлагдсан тариф, хэрэглэгчийн гэрээ, зохицуулалтын шаардлагаар идэвхжүүлнэ.

Гадаадын төслийн зардал буурсан хувь эсвэл орлого өссөн дүнг PowerGrid-ийн бизнес тооцоонд шууд шилжүүлэхгүй. Суурь алдагдал, тариф, хөдөлмөрийн өртөг, холбооны нөхцөл, тоолуурын насжилт өөр тул үр дүнг өөрийн туршилтаар хэмжинэ.

#043 Финланд ба Австралийн өгөгдлийн загвар

#Финландын Fingrid Datahub

Fingrid-ийн мэдээллээр Datahub нь ойролцоогоор 4 сая цахилгаан хэрэглээний цэгийн мэдээллийг нэгтгэж, 80 орчим түгээлтийн оператор, 80 нийлүүлэгч, 60 үйлчилгээ үзүүлэгчид эрхийн дагуу өгөгдөл солилцох боломж олгодог. Хэрэглэгч өөрийн цэгийн мэдээлэлд порталаар хандана. Энэ нь бүх тоолууртай шууд харилцах систем гэхээсээ жижиглэнгийн зах зээлийн өгөгдөл солилцооны давхарга юм. [S01]

Хэрэглэгчийн тайлбарт хэмжилт ихэвчлэн дараагийн өдөр харагддаг, холбоо тасарвал тооцоолсон утга ирж болдог гэжээ. Татах файл дахь 15 минут эсвэл цагийн нарийвчлал нь операторын нийлүүлсэн өгөгдлөөс хамаарна. Нээлттэй өгөгдөл нь нэг хэрэглэгчийн заалт бус, нэгтгэсэн мэдээлэл байна. [S02]

PowerGrid-д авах санал: meter_id, service_point_id, customer_id, contract_id-г тусад нь хадгална. Тоолуур солигдоход service_point_id өөрчлөгдөхгүй, харин mounting-ийн хүчинтэй хугацаа шинэчлэгдэнэ. Нийлүүлэгч, оператор, хэрэглэгч бүр зөвхөн өөрийн эрхийн хүрээний өгөгдөл авна. Тайлан татах API нь заалтын чанарын төлөв болон хувилбарыг хамт буцаана.

Хүлээн авах туршилт: нэг цэг дээр тоолуур сольж, хуучин ба шинэ төхөөрөмжийн заалтыг зөв хугацаанд хуваарилах; хэрэглэгч солигдоход өмнөх хэрэглэгчийн хувийн мэдээллийг шинэ хэрэглэгчид задруулахгүй байх; эрх цуцлагдмагц гуравдагч талын хандалт зогсохыг шалгана.

#Австралийн AEMO

Австралийн NEM зах зээл 2021 оны 10 сарын 1-нээс 5 минутын settlement-д шилжсэн. AEMO-ийн хэмжилтийн үр дүнгийн загвар нь бодит A, тооцоолсон E, орлуулсан S, эцэслэсэн орлуулалт F төлөвийг ялгаж, тухайн бичлэг одоогийнх уу эсвэл өмнөх түүх үү гэдгийг хадгалдаг. [S03–04]

PowerGrid-д авах санал: интервалын уртыг тогтмол 15 минут гэж кодлохгүй. 5, 15, 30, 60 минутын эх өгөгдлийг утгыг нь алдагдуулахгүй хадгална. Түүхий заалтыг дарж засахгүй; засварын шинэ хувилбар, шалтгаан, хэрэглэсэн дүрэм, гүйцэтгэсэн этгээдийг бүртгэнэ. Тарифын тооцоо аль хувилбарыг хэрэглэснийг тогтоох холбоостой байна.

30 минутын утгыг 5 минутын зургаан хэсэгт хуваасан бол түүнийг 5 минутын бодит хэмжилт гэж тэмдэглэхгүй. Төлбөр хаасны дараа хоцорсон бодит заалт ирвэл хуучин нэхэмжлэхийг чимээгүй өөрчлөхийн оронд засварын баримт үүсгэнэ.

Хүлээн авах туршилт: ижил хэмжилтийг дахин илгээхэд давхардахгүй; шинэ хувилбар нь хуучныг түүхэнд үлдээнэ; хэмжилтийн цаг ба хүлээн авсан цаг ялгаатай хадгалагдана; эх хугацааны бүс тодорхойгүй өгөгдөл автоматаар төлбөрт орохгүй.

#054 Франц ба Италийн хэрэглэгч төвтэй хэмжилт

#Францын Enedis Linky

Enedis-ийн 2024 оны тайланд оны эцэст ойролцоогоор 37.7 сая Linky тоолуур суурилуулсан гэж мэдээлсэн. Энэ нь Enedis-ийн хамрах хүрээний хэмжүүр бөгөөд бүх улсын бүх төрлийн тоолуурын ижил хэмжүүр биш. [S05]

Enedis-ийн өгөгдлийн бодлогод төлбөрийн индекс, хэрэглээний муруй, гуравдагч талд дамжуулах мэдээллийг өөр зориулалт, эрх зүйн үндэслэл, хадгалалтын хугацаагаар ялгадаг. Ялангуяа хэрэглээний муруйг нийлүүлэгч эсвэл гуравдагч талд дамжуулахад зөвшөөрлийн нөхцөл тусгасан. [S06]

PowerGrid-д авах санал: өгөгдөл цуглуулах эрх болон гуравдагч талд ашиглуулах эрхийг тусад нь бүртгэнэ. Зөвшөөрөл бүр өгөгдлийн төрөл, цэг, хугацаа, хүлээн авагч, зорилго, цуцалсан цагтай байна. Монголд хэрэглэх хадгалалтын бодлогыг дотоодын шаардлагаар тогтооно; Францын хугацааг шууд хуулбарлахгүй.

Хэрэглэгчийн портал заалтын эх сурвалж, шинэчлэгдсэн цаг, төлбөрийн задаргааг тайлбарлана. Нэгтгэсэн статистикийг гадагш гаргахдаа цөөн хэрэглэгчтэй бүлгээр нэг өрхийн хэрэглээг таах боломж үүсэх эсэхийг шалгана (босгыг 17.8-д үзнэ). Эрхийг UI дээр нуухаас гадна API, экспорт, тайлан дээр ижил мөрдүүлнэ.

#Италийн E Distribuzione Open Meter

E-Distribuzione-ийн Open Meter хуудсанд 30 саяас олон хоёрдугаар үеийн тоолуур идэвхтэй гэж мэдээлсэн. Chain 2 нь PLC-C сувгаар тоолуурыг хэрэглэгчийн төхөөрөмжтэй холбож, нийцсэн төхөөрөмжөөр хэрэглээг шуурхай хянах боломж олгодог. Үйлчилгээ нь тохирох 2G тоолуур, хангамжийн төрөл, баталгаажсан хэрэглэгчийн төхөөрөмжөөс хамаарна. [S07–08]

PowerGrid-д авах санал: төлбөрийн баталгаатай өгөгдөл болон хэрэглэгчийн шуурхай хяналтын өгөгдлийг эх үүсвэр, зориулалтаар нь ялгана. Төхөөрөмж бүрийн боломжийг capability profile-д хадгалж, реле, импорт/экспорт, тарифын регистр, цагийн синхрончлол, локал интерфэйс байгаа эсэхийг ил тод болгоно.

Шинэ төхөөрөмж эсвэл firmware хувилбарыг зөвхөн протоколын нэрээр дэмжигдсэн гэж зарлахгүй. Нийцлийн хүснэгтэд үйлдвэрлэгч, загвар, firmware, authentication mode, OBIS mapping, туршилтын огноо, дэмжигдсэн үйлдэл орно. Нэг төрлийн туршилтад тэнцсэн нь бүх төхөөрөмж нийцнэ гэсэн баталгаа болохгүй.

Хүлээн авах туршилт: зөвхөн унших чадвартай төхөөрөмжид таслах товч идэвхжихгүй; хэрэглэгчийн шуурхай хяналтын утга төлбөрийн баталгаатай утгыг дарж өөрчлөхгүй; тоолуурын профайл өөрчлөгдвөл туршилтын статус шинэчлэгдэнэ.

#065 Их Британи ба АНУ ын ашиглалтын сургамж

#Их Британийн Smart DCC

DCC-ийн 2024–2025 оны тайланд 35.0 сая холбогдсон тоолуурын 20.7 сая нь цахилгаан, 14.3 сая нь хий гэж тусгаж, үйлчилгээний бэлэн байдлыг 99.97 хувь гэж мэдээлсэн. Энэ нь DCC-ийн тайлагнасан үйлчилгээний KPI бөгөөд тоолуур бүрийн заалт амжилттай ирэх магадлалтай адил биш. [S09]

Их Британийн Үндэсний аудитын газрын 2023 оны тайланд тухайн оны 3 сарын эцэст ойролцоогоор 3 сая буюу суурилуулсан smart meter-ийн 9 хувь нь smart mode-д ажиллахгүй байсныг дурдсан. Энэ бол 2023 оны төлөв; өнөөдрийн хувь гэж хэрэглэхгүй. [S10]

PowerGrid-д авах санал: registered, installed, commissioned, communicating, billing-ready гэсэн үе шатыг тусад нь бүртгэнэ. Сервер ажиллаж байгаа нь төхөөрөмжийн үйлчилгээ хэвийн гэсэн дүгнэлт болохгүй. Adapter availability, уншилтын амжилт, өгөгдлийн бүрэн байдал, командын баталгаажилт тус бүр өөр dashboard болон хариуцагчтай байна.

Ашиглалтын гэрээнд холбооны үйлчилгээ тасарсан, төхөөрөмж эвдэрсэн, түлхүүр буруу, эх өгөгдөл алдаатай гэсэн шалтгаануудыг ялгана. Хэрэглэгч нэг алдааг олон байгууллагаар дамжуулан тайлбарлуулах шаардлагагүйгээр операторын нэг тасалбарын дугаараар мөрдөнө.

#АНУ ын Smart Grid Investment Grant туршлага

АНУ-ын Эрчим хүчний яамны 2016 оны SGIG тайланд AMI-ийн цахилгаан тасарсан last gasp, тэжээл сэргэсний мэдэгдэл, алсын ping-ийг OMS болон GIS-тэй холбосон жишээнүүд бий. Том тасралтыг зассан ч үлдсэн жижиг тасралтыг илрүүлэхэд тоолуурын төлөв тусалдаг. Их хэмжээний ослын үед дохиолол олшрох нь ажиллагааг хүндрүүлдэг тул урсгалыг зохицуулах шаардлагыг мөн тэмдэглэсэн. [S11]

PowerGrid-д авах санал: нэг фидерийн олон тоолуурын дохиоллыг нэг incident-д бүлэглэнэ. Тасралтын сэжиг, баталгаажсан тасралт, засварын ажил, сэргэлтийн баталгааг ялгана. Холбоо алга болсон нь дангаараа цахилгаан тасарсны нотолгоо биш; хөрш тоолуур, концентратор, фидерийн мэдээлэлтэй тулгана.

Засварчин ажлаа дуусгасан гэж тэмдэглэсний дараа нөлөөлсөн цэгүүдээс төлөөлөх багцын төлөвийг шалгана. Баталгаажаагүй үлдсэн хэрэглэгчийг тусдаа дараалалд үлдээж, incident-ийг бүрэн хаасан гэж харагдуулахгүй. Last gasp болон ping нь төхөөрөмж, холбооны сүлжээ дэмжсэн үед л боломжтой.

Хүлээн авах туршилт: олон тоолуурын нэгэн зэрэг дохиолол системийг унагахгүй; давхардсан мэдэгдэл incident-ийг олшруулахгүй; холбооны тасалдалд хэрэглэгчид цахилгаан тасарсан гэсэн буруу мэдэгдэл автоматаар очихгүй.

#076 Япон ба Сингапурын үйлчилгээний туршлага

#Японы TEPCO Power Grid

TEPCO өөрийн үйлчилгээний бүсэд FY2020 он гэхэд солиход хүндрэлтэй зарим байршлаас бусад ойролцоогоор 28.4 сая smart meter суурилуулах төслөө хэрэгжүүлсэн гэж мэдээлдэг. Тоолуурын хуримтлагдсан хэрэглээг 30 минут тутам дамжуулж, боловсруулна. 2015 оны 7 сард аюулгүй байдал, ашиглалт, засвар үйлчилгээг хянах Smart Meter Operations Center байгуулсан. Энэ нь Японы бүх улсын статистик биш. [S12]

Тус компанийн худалдан авалтын мэдээлэлд нээлттэй техникийн тодорхойлолт, стандартчилал, өрсөлдөөнт худалдан авалтыг онцолсон. [S13]

PowerGrid-д авах санал: тоолуурын холболтын гэрээ, өгөгдлийн хэлбэр, error code, firmware нийцэл, түлхүүр солих үйлдлийг нийлүүлэгчээс баримттай авна. Системийг зөвхөн хөгжүүлэгч баг ажиллуулдаг байдлаас гаргаж, өдөр тутмын хяналт, жижүүр, ослын үед хийх дараалал, нийлүүлэгч рүү шилжүүлэх нөхцөлийг тодорхой болгоно.

Коммуникацийн түлхүүрийн алдаа, удааширсан backfill, дараалал дүүрэх, бүрэн бус архив, олон төхөөрөмж нэгэн зэрэг offline болох зэрэгт тусдаа ажиллагааны заавар гаргана. Шинэ release-ийг цөөн төхөөрөмжид эхэлж нэвтрүүлж, KPI муудвал өмнөх хувилбарт буцаах боломжийг шалгана.

#Сингапурын EMA ба SP Group

EMA-ийн тайлбараар advanced electricity meter нь хэрэглээг хагас цагийн интервалаар бүртгэдэг бөгөөд 2026 он гэхэд улс даяар суурилуулах зорилттой. Энэ зорилтыг бүрэн дууссан үр дүн гэж үзэхгүй. SP Group-ийн FY2022–2023 тайланд хэрэглэгчид SP app-аар хагас цагийн хэрэглээгээ харах боломжтойг дурдсан. [S14–15]

PowerGrid-д авах санал: хэрэглэгчийн дэлгэцэд өнөөдрийн хэрэглээ, тооцоолсон төлбөр, өмнөх ижил хугацаатай харьцуулалт, мэдээлэл шинэчлэгдсэн цагийг эхэлж харуулна. Хэрэглээний таамгийг батлагдсан нэхэмжлэхээс ялгаж тэмдэглэнэ. Хагас цагийн өгөгдлийг “яг одоо” гэсэн буруу тайлбартай үзүүлэхгүй.

Аппын хэрэглээний график ба операторын архив нэг баталгаажсан эх үүсвэртэй байна. Хэрэглэгч графикаас нэг интервалыг сонгоход утга, нэгж, чанарын төлөв, тухайн үед хэрэглэсэн тарифыг тайлбарлана. Дутуу өгөгдлийг тэг хэрэглээ болгож зурахгүй, сул холбоотой гар утсанд сарын хураангуйг түрүүлж ачаална.

Хүлээн авах туршилт: серверийн тооцоо, хэрэглэгчийн харагдац, экспортын дүн ижил байх; хоцорсон өгөгдөл ирсний дараах өөрчлөлт тайлбартай байх; хэрэглээний kWh ба чадлын kW-г интерфэйс дээр холихгүй байх.

#087 Энэтхэг ба Узбекистаны өргөн нэвтрүүлэлт

#Энэтхэгийн RDSS

Энэтхэгийн Эрчим хүчний яамны 2025 оны 12 сарын 11-ний мэдээллээр улсын хэмжээнд 4.93 crore буюу 49.3 сая smart meter суурилуулснаас 16 сая нь prepaid горимд ажиллаж байв. RDSS-ийн хүрээнд баталсан нийт 203.3 сая тоолуурт хэрэглэгч, фидер, түгээх трансформаторын тоолуур орсон. Баталсан хамрах хүрээ нь суурилуулж дууссан тоо биш. [S16]

Тус эх сурвалжид үлдэгдлийн урьдчилсан мэдэгдэл, emergency credit, бага дүнгээр цэнэглэх, хэрэглээ хянах апп, хуучин өрийг хэсэгчлэн төлөх болон тоолуурын үнэн зөв байдалд итгэл төрүүлэх check meter-ийн арга хэмжээг дурдсан. Хэрэглэгчийн ойлголт дутмаг байдал нэвтрүүлэлтэд хүндрэл үүсгэснийг мөн хүлээн зөвшөөрсөн. [S16]

PowerGrid-д авах санал: prepaid-ийг тусдаа бодлого болгон хөгжүүлнэ. Үлдэгдэл багассан мэдэгдэл, төлбөр орсон ч тулгалт хүлээж байгаа төлөв, grace period, emergency credit-ийн хэмжээ, хамгаалагдсан хэрэглэгчийн ангиллыг тохируулах боломжтой байна. Эдгээр нөхцөлийг Монголын үйлчилгээний дүрмээр баталсны дараа хэрэгжүүлнэ.

#Узбекистаны CAS ба HET Billing

ADB-ийн 2022 оны хаалтын тайланд олон үйлдвэрлэгчийн тоолуурыг холбох CAS, трансформаторын балансын тоолуур, байгууллагын өөрийн billing системтэй интеграцчилсан бүтэц, тоолуурын туршилтын лабораторийг дурдсан. Эдгээр нь PowerGrid-ийн төхөөрөмжийн нийцэл, баланс, төлбөрийн заагт хамаатай жишээ юм. [S17]

2024 оны 8 сарын 9-нд Эрчим хүчний яам шинэ HET Billing-ийн техникийн ажлын үеэр зарим хэрэглэгч буруу өртэй харагдаж байгааг мэдэгдэж, ийм хэрэглэгчийг таслахгүй гэж тайлбарласан. HET-ийн хэрэглэгчийн апп нь заалт, төлбөр, өр, хүсэлтийн үйлчилгээг нэгтгэдэг. [S18–19]

PowerGrid-д авах санал: TEAMI-аас татсан хэмжилт, billing-ийн тооцоо, төлбөрийн ledger-ийг эх сурвалж ба хувилбараар мөрдөнө. Шилжилтийн үед хуучин ба шинэ системийг зэрэгцүүлэн тооцоолж, зөрүүг шийдэж дуустал шинэ системийн автомат таслалтыг идэвхжүүлэхгүй.

#Нийтлэг хүлээн авах шалгуур

Нэг төлбөрийн webhook олон удаа ирэхэд данс нэг удаа цэнэглэгдэх; хожуу ирсэн төлбөр, буцаалт, хуучин өрийн хуваарилалт зөв байх; мэдээлэл зөрүүтэй үед таслах хүсэлт зогсох; хэрэглэгч тооцоог эсэргүүцэх болон залруулах хүсэлтээ мөрдөх боломжтой байхыг шалгана.

#098 PowerGrid ийн санал болгож буй архитектур

Эхний хувилбарт одоогийн Go backend-ийг үүргээр нь салгасан модуль бүхий нэг үндсэн апп хэлбэрээр хадгална. Төхөөрөмжийн харилцааг тусдаа worker-оор ажиллуулж, UI хүсэлтээс хамааралгүй дараалалд гүйцэтгэнэ. Олон microservice-ийг эхнээс нь нэвтрүүлэхээс өмнө ачаалал, багийн ашиглалтын чадварыг хэмжинэ.

#Өгөгдлийн хоёр урсгал

Заалтын урсгал: тоолуур эсвэл TEAMI → адаптер → түүхий хадгалалт → VEE → баталгаажсан архив → баланс ба billing → портал. Алдаатай өгөгдөл нь quarantine дараалалд орж, төлбөрт автоматаар ашиглагдахгүй. Түүхий өгөгдлийг хадгалснаар дүрэм өөрчлөгдөхөд дахин боловсруулах боломжтой.

Командын урсгал: оператор эсвэл зөвшөөрөгдсөн дүрэм → эрх ба бодлогын шалгалт → командын дараалал → адаптер → төхөөрөмж → хариу → төлөв дахин унших → audit. Телеметр хүлээн авдаг API-г шууд реле удирдах эрхтэй болгохгүй.

#Байгууллага хоорондын зааг

Улсын нэгдсэн харагдац нь байгууллага, бүс, дэд станцын нийлбэр үзүүлэлтийг харуулна. Дэлгэрэнгүй хэрэглэгчийн өгөгдөлд эрхийн хүрээний дагуу нэвтэрнэ. Tenant болон operator-ийн заагийг сервер, өгөгдлийн хүсэлт, background job, экспортод ижил мөрдүүлнэ. Эрхийн дэлгэрэнгүй загвар, засаг захиргааны харагдацыг Core системээс салгах шийдлийг 17 дугаар бүлэгт тайлбарлав. Бүсийн холбоо тасарвал локал буфер хадгалж, дараа нь хугацааны дарааллаар нөхөж дамжуулна.

SCADA болон хамгаалалтын реле нь цахилгаан сүлжээний тусдаа хариуцлагатай систем хэвээр байна. PowerGrid эхний шатанд хэмжилт, тайлан, зөвшөөрөгдсөн тоолуурын командын хүрээнд ажиллаж, хурдан хамгаалалтын шийдвэрийг өөр дээрээ шилжүүлэхгүй.

#109 Өгөгдлийн чанар ба балансын шаардлага

#Заалтын заавал хадгалах талбарууд

Туршилтын өгөгдлийг quality төлөвт найдаж ялгахгүй, орчны болон эх үүсвэрийн түвшинд тусгаарлана. Production billing нь simulator эх үүсвэртэй заалтыг хэрэглэж болохгүй. Хуримтлагдсан kWh индекс, интервалын kWh, агшин зуурын kW нь өөр хэмжигдэхүүн тул хөрвүүлэлтийн дүрэм нь ил тод байна.

#VEE шалгалтын санал

Давхардсан мөр, хугацааны давхцал, тасарсан интервал, боломжит хүрээнээс гарсан утга, гэнэт буурсан хуримтлагдсан индекс, тоолуур солилт, counter rollover, цагийн зөрүү, нэгж болон коэффициентийн өөрчлөлтийг шалгана. Экспортын энерги дэмждэг төхөөрөмжид сөрөг утгыг шууд алдаа гэж ангилахгүй. Шалгалтын дүрэм төхөөрөмжийн профайл болон хэмжилтийн төрлөөс хамаарна.

Орлуулсан утгын эх үүсвэр, алгоритм, хүчинтэй хугацаа хадгалагдана. Бодит заалт хожуу ирвэл шинэ хувилбар үүсгэж, түүнээс хамаарсан баланс, тайлан, billing-ийн дахин тооцох жагсаалтыг гаргана. Тооцоолсон утгыг бодит заалтын KPI-д оруулахгүй.

#Балансын зөв тайлбар

Ижил хугацаа ба ижил сүлжээний заагт: зөрүү = нийт оролт − нийт гаралт − зөвшөөрөгдсөн тоолуургүй хэрэглээ. Сүлжээнд нийлүүлсэн нарны энерги, трансформаторын туслах хэрэглээ, тоолуурын коэффициент болон цагийн зөрүүг тооцно. Зөрүүний хувь = зөрүү / нийт оролт × 100; оролт тэг эсвэл баталгаагүй үед хувийг тооцохгүй.

Зөрүү нь техникийн алдагдал, арилжааны алдагдал, дутуу мэдээлэл, буруу topology-ийн нийлбэр байж болно. Dashboard нь зөрүүний хамт хэмжилтийн бүрэн байдал, estimated эзлэх хувь, хамрагдсан цэгийн тоо, topology хувилбарыг харуулна. Бүрэн бус хэмжилттэй бүлгийг баталгаатай алдагдлын чансаанд оруулахгүй.

Жишээ: трансформаторын оролт 10,000 kWh, хэрэглэгчдийн баталгаатай нийлбэр 9,200 kWh бол эхний зөрүү 800 kWh буюу 8 хувь. Гэхдээ хоёр цэгийн өгөгдөл дутуу бол энэ 8 хувийг хулгай эсвэл цэвэр техникийн алдагдал гэж дүгнэж болохгүй. Энэ нь тооцооны жишээ бөгөөд бодит суурилуулалтын үзүүлэлт биш.

#1110 Төлбөр ба төхөөрөмжийн командын шаардлага

#Billing ийн тооцоог дахин гаргах боломж

Тариф бүр хүчинтэй эхлэх, дуусах хугацаа, хэрэглэгчийн ангилал, цагийн бүс, шатлал, нэгж үнэ, татвар болон дугуйруулах дүрэмтэй байна. Нэхэмжлэх нь ашигласан хэмжилтийн хувилбар болон тарифын хувилбарыг заана. Мөнгөн дүнг decimal эсвэл хамгийн жижиг мөнгөний нэгжээр тооцож, binary floating point-ийн зөрүү үүсгэхгүй.

Хэрэглэгч, гэрээ, хангамжийн цэг, тоолуурыг нэг хүснэгтэд нэг ID болгон нэгтгэхгүй. Нэг хэрэглэгч олон цэгтэй, нэг цэг хугацааны явцад өөр хэрэглэгчтэй байж болно. Тоолуур сольсон болон тариф сарын дундуур өөрчлөгдсөн үеийн хуваарилалтын дүрэм батлагдсан байх шаардлагатай.

Payment ledger нь гүйлгээний ID, эх үүсвэр, дүн, валют, төлөв, холбогдох данстай байна. Callback давтан ирэхэд нэг удаа бичигдэх түлхүүртэй; төлбөрийн цуцлалт болон буцаалтыг түүхийг устгахгүйгээр эсрэг бичилтээр бүртгэнэ. Settlement хүлээж буй төлбөрийг баталгаажсан төлбөрөөс ялгана.

#Командын төлөвийн машин

Timeout гарсан таслах командыг сохроор давтан илгээхгүй. Эхлээд төхөөрөмжийн төлөвийг шалгаж, үйлдэл давхардахгүй нөхцөлийг тогтооно. CANCEL нь илгээгээгүй хүсэлтийг зогсоож болох боловч аль хэдийн биелсэн үйлдлийг автоматаар буцаасан гэсэн үг биш.

#Таслах болон залгах бодлого

Хуучирсан үлдэгдэл, тулгалт хүлээсэн төлбөр, маргаантай нэхэмжлэл, эрхийн зөрүү, хамгаалагдсан хэрэглэгч, тодорхойгүй төхөөрөмжийн төлөвт автомат таслалт зогсоно. Олноор гүйцэтгэх командын тоо, хурд, бүсийг хязгаарлана. Туршилтын болон бодит командын эрх, түлхүүр, дарааллыг тусгаарлана.

Төлбөр орсны дараах залгалт нь мөн эрх, талбайн аюулгүй ажиллагааны нөхцөл, төхөөрөмжийн төлөвийг шалгана. Нэг товч дарснаар эсвэл дансны төлөв өөрчлөгдсөнөөр цахилгаан залгагдсан гэж хэрэглэгчид мэдэгдэхгүй.

#1211 Аюулгүй байдал ба найдвартай ашиглалт

NISTIR 7628 Rev 1 нь smart grid-ийн архитектур, эрсдэл, эмзэг байдалд тохируулан шаардлага боловсруулах хүрээ өгдөг. DLMS UA нь compliance болон companion profile-д тулгуурласан compatibility баталгаажуулалтыг ялгадаг. Иймээс “DLMS дэмждэг” гэдэг нь PowerGrid-ийн бүх үйлдэлд нийцнэ гэсэн баталгаа биш. [S20–21]

#PowerGrid ийн хэрэгжүүлэх хяналтууд

Реле удирдах эрхийг энгийн архив харах эрхээс салгана. Олон хэрэглэгчид нөлөөлөх өөрчлөлтөд хүсэлт гаргагч ба батлагчийг тусгаарлах саналтай. Хувийн мэдээлэл болон төхөөрөмжийн нууц түлхүүр лог, тайлан, алдааны хариунд гарахгүй байна.

#Холбоо тасарсан үеийн ажиллагаа

Адаптер нь шалтгаанаас хамаарсан retry, exponential backoff, санамсаргүй тархаалт, нэг төхөөрөмжид зэрэг гүйцэтгэх хязгаартай байна. Удаан offline төхөөрөмж шинэ онлайн төхөөрөмжийн уншилтыг саатуулахгүй. Backfill-ийн ачааллыг өнөөгийн заалтаас тусдаа квотоор удирдана.

Холбоо сэргэсний дараа бүх төхөөрөмжийг нэг мөчид poll хийхгүй. Төхөөрөмжийн локал хадгалалтын бодит багтаамжаас хамаарч нөхөж авах хугацааг тохируулна. Сервер өөрөө түүхий заалтыг баталгаатай хадгалаагүй бол эх системд амжилттай хүлээн авсан гэж хариулахгүй.

#Ашиглалтын эзэн ба хэмжүүр

Төхөөрөмжийн баг холболт, мэдээллийн баг VEE ба архив, санхүүгийн баг тариф ба тулгалт, ашиглалтын баг сервер ба сэргэлт, аюулгүй байдлын хариуцагч эрх ба түлхүүрийг хариуцна. Ослын нэг удирдагчтай, ээлж шилжүүлэх тэмдэглэлтэй байна. RPO буюу зөвшөөрөх өгөгдлийн алдагдал, RTO буюу сэргээх хугацааг үйлчилгээ бүрээр гэрээлнэ.

#1312 Одоогийн код ба нээлттэй эхийн сонголт

1.4 хувилбарын шинэчлэлт. PowerGrid-ийг одоо gerege-systems/power-grid-mn репод Gerege Nexus (backend/v1.32.0)-ийн private distribution хэлбэрээр хөгжүүлж байна. Энэ суурь нь нэвтрэлт, байгууллага, гишүүнчлэл, эрхийн хэсгийг агуулдаг. Харин уншилт, архив, команд, TEAMI зэрэг бизнес модуль одоогоор байхгүй. Иймээс доорх хүснэгтийн «одоогийн суурь» багана нь өмнөх teami-gerege-uz прототипийн үнэлгээ юм. Түүний алдаа (simulator өгөгдөл, DB-д COMPLETED гэж бичдэг команд) power-grid-mn-д хуулагдаж ирээгүй. Эдгээр мөрийг шинэ модулийг бичихдээ «давтахгүй байх» шаардлага гэж уншина. Тухайлбал PG-02 нь simulator-ийг эхнээс нь production эх үүсвэрээс тусгаарлах, PG-07 нь командын статусыг эхнээс нь бодит гүйцэтгэлээс салгах ажил болно.

Өмнөх кодын үнэлгээ нь teami-gerege-uz репозиторийн master дахь 4ac3dfb15829 хувилбар (commit огноо 2026 оны 9 сарын 27) дээр хийгдсэн. Үнэлгээ нь баримт, уншилт ба ачааллын handler, TEAMI таталтын тайлбарт тулгуурласан. [S26–28]

#Компонентын сонголт

Санал: үндсэн MDM болон бизнес дүрмээ Go дээр хадгалж, Gurux-ийг шаардлагатай хэл дээрх тусдаа адаптерт туршина. Процесс тусгаарласан нь лицензийн үүргээс автоматаар чөлөөлнө гэж үзэхгүй. Түгээх хэлбэр, өөрчлөлт, commercial лицензийн шаардлагыг сонголт хийх үед шалгана.

Драйвер сонгох дараалал: бодит meter inventory → protocol ба түлхүүрийн баримт → лабораторийн уншилт → хязгаарлагдсан талбайн туршилт → ашиглалтын дэмжлэгийн үнэлгээ. GitHub одны тоо эсвэл demo dashboard нь төхөөрөмжийн нийцлийн баталгаа болохгүй.

#1413 Туршилтын төлөвлөгөө ба хүлээн авах босго

Эхний талбай нь нэг трансформаторын бүтэн балансын заагтай, цэгийн жагсаалт ба холболт нь баталгаатай байна. Дараагийн талбайг өөр тоолуурын загвар, холбоо, хэрэглэгчийн төрөлтэй сонгоно. Нэг талбай дээр амжилттай ажилласан нь улсын хэмжээнд нэвтрүүлэх хангалттай баталгаа биш.

#Туршилтын дараалал

Лабораторид төхөөрөмжийн профайл, түлхүүр, OBIS, цаг, коэффициент, локал хадгалалт, relay-ийн бодит боломжийг тогтооно. Дараа нь талбайд зөвхөн уншилт ажиллуулж, эх заалтыг одоогийн системтэй тулгана. Billing-ийг хэрэглэгчид нэхэмжлэхгүйгээр дор хаяж хоёр бүтэн тооцооны мөчлөг зэрэгцүүлэн ажиллуулна. Төхөөрөмжийн командын туршилтыг эрх бүхий баг хязгаарлагдсан хүрээнд гүйцэтгэнэ.

Эдгээр босго нь PowerGrid-ийн санал бөгөөд олон улсын стандартын заавал мөрдөх тоо биш. Төхөөрөмж, холбоо, бизнесийн эрсдэлийн хэмжилтээр баталгаажуулна. Хүлээгдсэн интервалын denominator-оос offline төхөөрөмжийг чимээгүй хасахгүй; төлөвлөгөөт засвар, ашиглалтаас гарсан цэгийн хасалтыг тусад нь тайлбарлана.

Төлбөрийн ledger-ийн хүлээн авсан гүйлгээнд RPO 0 хүрэх хадгалалтын загварыг зорилго болгоно. Үүнийг ерөнхий MDM-ийн 15 минутын RPO-той адилтгахгүй. Командын latency болон read timeout-ыг тоолуурын төрөл, холбооны сувгаар тусад нь тогтооно.

#1514 Багтаамж ба ачааллын инженерчлэл

Монгол Улсын нийт 1,000,000 тоолуурыг PowerGrid-д бүрэн хамруулна гэсэн суурь хувилбараар тооцно. Нэг тоолуурын нэг сувагт 15 минутын интервалаар хэмжилт бүртгэвэл өдөрт 96 бичлэг, 365 хоногт 35,040 бичлэг үүснэ. Серверт дамжуулах давтамж нь хэмжилтийн интервалаас ялгаатай байж болно. Доорх 10,000 ба 100,000 тоолуур нь улсын нийт хамрах хүрээний 1% ба 10%-ийн завсрын шат; 1,000,000 нь 100%-ийн зорилтот шат юм. Эдгээр нь серверийн туршилтаар баталгаажсан хүчин чадал биш.

Дөрвөн сувагтай 1 сая тоолуурын үед өдөрт 384 сая, жилд 140.16 тэрбум хэмжилт болно. 15 минутын зааг бүрт 4 сая бичлэг нэг минутын дотор орж ирвэл ойролцоогоор 66,667 бичлэг/секунд шаардлагатай. Иймээс зөвхөн хоногийн дундаж ачааллаар сервер сонгож болохгүй.

Нэг сувгийн 1 сая тоолуурын хувилбарт 15 минутын 1 сая бичлэгийг нэг минутанд хүлээн авбал ойролцоогоор 16,667 бичлэг/секунд болно. Дөрвөн сувгийн хоногийн дундаж нь 4,444.4 бичлэг/секунд. Эдгээр нь хэмжилтийн бичлэгийн тоо бөгөөд сүлжээний хүсэлт эсвэл пакетийн тоо биш; нэг batch олон бичлэг агуулж болно.

#Хадгалалтын жишиг тооцоо

Нэг сувгийн хэмжилт 100–250 byte эзэлнэ гэсэн туршилтаар шалгах таамаглал хэрэглэвэл 1 сая тоолуурын жилийн түүхий өгөгдөл 3.50–8.76 TB орчим болно. Индекс, хуулбар, backup, event, аудит болон түр боловсруулалтын зай ороогүй. Нийт багтаамжийг түүхий өгөгдлөөс 3 дахин их гэж төлөвлөвөл 10.5–26.3 TB; дөрвөн сувагт 42–105 TB орчим болно. Энэ нь decimal TB тооцоо бөгөөд schema ба compression-оор их өөрчлөгдөнө.

#PowerGrid дэх техникийн сонголт

PostgreSQL-ийн боломжийг эхлээд partition, зөв индекс, багц insert, өдөр/сар агрегат, архивын retention-оор хэмжинэ. Түүхий payload-ыг object storage-д салгах хувилбар үнэлнэ. Query удааширсан эсвэл retention өртөг ихэссэн нотолгоогоор тусгай аналитик сан сонгоно. Шинэ технологи нэмэхдээ өгөгдлийн давхардсан үнэн эх үүсвэр үүсгэхгүй.

Queue нь буфер, retry, backpressure-ийн үүрэгтэй байна. Оролтыг дор хаяж нэг удаа хүргэх нөхцөлд receiver нь idempotent буюу давтан ирсэн бичлэгийг нэг удаа хэрэгжүүлдэг байна. “Exactly once” гэсэн тохиргоонд бүх бизнесийн зөв байдлыг даатгахгүй.

#Ачааллын заавал турших хувилбарууд

Өдрийн хэвийн оролт; тоолуурын цаг таарч нэгэн зэрэг ирэх оргил; 24 цагийн тасалдлын нөхөн таталт; долоо хоногийн backfill; олон хэрэглэгчийн тайлан; сарын billing; тасралтын дохиоллын шуурга; backup ба ingestion зэрэг ажиллах үеийг тус тус хэмжинэ. p95/p99 latency, queue depth, DB write lag, backfill completion time, алдааны хувийг хамт бүртгэнэ.

Хэмжилтийн нарийвчлалыг бизнесийн шаардлагаар сонгоно. Зөвхөн 30 минутын хэмжилт дэмждэг төхөөрөмжөөс 5 минутын бодит өгөгдөл шаардах боломжгүй. Нарийвчлал өөрчлөх боломжийг төхөөрөмжийн тохиргоо, firmware болон техникийн үзүүлэлтээр батална. UI дээр илүү нарийвчилж зурсан нь хэмжилтийн чанар сайжирсан гэсэн үг биш.

#1615 Эдийн засаг ба нийлүүлэгч сонгох арга

#Нийт эзэмших өртөг

Open-source лицензийн үнэ бага байх нь нийт өртөг бага гэсэн баталгаа биш. Тоолуур, холбоо, төхөөрөмжийн түлхүүр, талбайн суурилуулалт, өгөгдөл цэвэрлэх, интеграц, жижүүр, firmware, backup, кибер хамгаалалт, сургалт, хэрэглэгчийн үйлчилгээний зардлыг хамтад нь тооцно.

Жилийн цэвэр үр ашиг = баталгаажсан нэмэлт орлого + зайлсхийсэн зардал − нэмэлт ашиглалтын зардал. Энгийн нөхөх хугацаа = эхний хөрөнгө оруулалт / жилийн цэвэр үр ашиг; үр ашиг тэг эсвэл сөрөг бол энэ хэмжүүр тохирохгүй. Мөнгөн урсгалын хөнгөлөлт, тоног төхөөрөмжийн солилт, тарифын өөрчлөлтийг урт хугацааны үнэлгээнд нэмнэ.

Арилжааны алдагдал буурснаас нэмэгдсэн тооцоолсон борлуулга, тэр борлуулалтын төлбөр цуглуулалт, техникийн хэмнэлтийг давхар үр ашиг болгон тоолохгүй. Туршилтын өмнөх ба дараах хугацаанд улирал, цаг агаар, тариф, хэрэглэгчийн өөрчлөлт нөлөөлснийг салгаж үнэлнэ.

#Нэг сая тоолуурын өртгийн суурь

Нийт хамрах хүрээ 1 сая боловч бүх тоолуурыг шинээр худалдан авна гэж төсөвлөхгүй. Бүртгэлээр одоо ашиглаж болох, холбоо нэмэх шаардлагатай, солих шаардлагатай төхөөрөмжийг ялгана. Нэг удаагийн зардалд шинэ эсвэл солих төхөөрөмжийн тоо × нэгж үнэ, талбайн ажил, интеграц, өгөгдөл шилжүүлэлт орно. Холбооны зардлыг тоолуур бүрд SIM байна гэж үзэлгүй, бодит SIM болон концентраторын тоогоор тооцно.

Жишиг мэдрэмжийн тооцоо: 1 сая тоолуурт бүгдэд хамаарах сарын нэгж зардал 1,000 төгрөгөөр өөрчлөгдвөл жилийн нийт зардал 12 тэрбум төгрөгөөр өөрчлөгдөнө. Энэ нь үнийн санал биш, хамрах хүрээ × нэгж зардлын арифметик жишээ юм.

#Нийлүүлэгчийн үнэлгээний санал

Шалгуур тус бүрийг 0–5 оноогоор үнэлж жинлэнэ. Гэхдээ төхөөрөмжийн түлхүүрийн удирдлагыг эрх бүхий операторт шилжүүлэх төлөвлөгөөгүй, дэмжигдсэн төхөөрөмжийн нотолгоогүй, худал амжилттай command харуулдаг, өгөгдлөө бүрэн гаргаж авах боломжгүй зэрэг ноцтой зөрүүг өндөр нийт оноогоор нөхөхгүй. Үндсэн шаардлага хангахгүй бол сонголтоос хасна.

#1716 Хөгжүүлэлтийн дараалал ба шийдвэрүүд

Доорх хугацаа нь ажлын төлөвлөлтийн жишиг. 6–8 хүний үндсэн баг, талбайн инженерийн оролцоо, тоолуур ба интеграцын эрх бэлэн байх нөхцөлд авч үзсэн; нийлүүлэлт, байгууллагын зөвшөөрөл, hardware солилтын хугацааг гэрээний амлалт болгон тооцоогүй.

#Нэг сая тоолуурт хүрэх нэвтрүүлэлтийн хамрах хүрээ

Доорх нь хуримтлагдсан хамрах хүрээний санал; мөрүүдийн тоог нэмж нийлбэр гаргахгүй. Үе бүрд 13 дугаар бүлгийн KPI болон бодит төхөөрөмжийн нийцлийг баталсны дараа өргөжүүлнэ.

Эхний талбайн бодит тоог трансформаторын бүтэн бүлгээр сонгох тул 1,000 нь ойролцоо зорилт. Үндсэн 6–8 хүний багийн жишиг нь бүтээгдэхүүн хөгжүүлэлтийн багт хамаарна. Нэг сая тоолуурын талбайн суурилуулалт, ээлжийн хяналт, хэрэглэгчийн үйлчилгээний орон тоог ажлын хэмжээгээр тусад нь тооцно. Улсын бүрэн нэвтрүүлэлтийн хугацааг өдөрт холбох буюу солих төхөөрөмжийн хүчин чадал, холбооны бэлэн байдал, худалдан авалтын хуваариар тогтооно.

#Эхний спринтийн ажлын жагсаалт

PG-01: тоолуурын inventory ба capability profile. PG-02: simulator эх үүсвэрийг production-оос хаах. PG-03: TEAMI source ID, timezone, нэгжийн mapping. PG-04: raw receipt ба idempotency түлхүүр. PG-05: архивын actual, estimated, substituted төлөв ба version. PG-06: collection job-ийг бодит worker болон retry-тэй болгох.

PG-07: command status-ыг бодит гүйцэтгэлээс салгах. PG-08: service point ба meter mounting-ийн түүх. PG-09: D+1 completeness dashboard. PG-10: лабораторийн хоёр загварын нийцлийн тест. PG-11: authz схем, scope cell, хоёр түлхүүрийн командын дүрэм, pgTAP эрхийн матриц (17 дугаар бүлэг). Эдгээрийн Definition of Done нь код, автомат шалгалт, бодит төхөөрөмжийн нотолгоо шаардсан хэсгийн протокол, ашиглалтын богино заавраас бүрдэнэ.

#Багийн санал болгож буй бүрэлдэхүүн

Бүтээгдэхүүн ба эрчим хүчний домэйн хариуцагч; хоёр backend/integration инженер; frontend инженер; QA ба өгөгдлийн чанарын инженер; DevOps/аюулгүй байдлын инженер. Талбайн цахилгааны инженер болон billing мэргэжилтэн тогтмол оролцоно. Нэг хүн олон үүрэг хавсарч болох ч төхөөрөмжийн командын баталгаажуулалт, төлбөрийн жишиг тооцоог эзэнгүй орхихгүй.

#Одоо шийдэх зүйлс

Туршилтын трансформатор ба харьяа хэрэглэгчдийн жагсаалтыг батлах; тоолуурын protocol баримт, firmware, түлхүүрийн олголтыг авах; TEAMI-аас өгөгдөл авах эрх ба хугацааны утгыг тогтоох; дотоодын тариф, хэрэглэгчийн хамгаалалтын дүрмийг нэгтгэх; PowerGrid-ийн эхний release-ийг бодит хэмжилт ба балансын хүрээнд гаргах шийдвэр гаргана. Мөн hub эсвэл тархсан өгөгдлийн загвар, зөвшөөрлийн бүртгэлийн эзэн, нэгтгэлийн k босгыг 17.12-ын дагуу шийдвэрлэнэ.

#1817 Өгөгдөлд хандах эрх, бүлэглэл ба нууцлалын загвар

Энэ бүлэг 1.3 хувилбарт нэмэгдэв. Зорилго нь «хэн, ямар үндэслэлээр, ямар цэгийн, ямар хугацааны, ямар нарийвчлалтай өгөгдлийг харах вэ» гэдгийг олон улсын жишигт нийцүүлэн тогтоох юм. Мөн засаг захиргааны нэгж болон бусад бүлгээр харах, шүүх системийг Core хэмжилтийн системээс тусад нь барих архитектурыг санал болгоно. Доорх SQL, хүснэгт, босго нь PowerGrid-ийн инженерийн санал бөгөөд Монголын хууль, ЭХЗХ-ны журамтай тулгаж батлах шаардлагатай.

#17.1 ЕХ-ны «My Energy Data» тайлангаас авах сургамж

Европын Smart Grids Task Force-ийн Expert Group 1-ийн түр бүлэг 2016 оны 11 сард «My Energy Data» тайланг гаргасан. Тайлан нь 10 гишүүн улсын хэмжилтийн өгөгдөлд хандах үйлчилгээг харьцуулж, хэрэглэгч өөрийн өгөгдлийг татах болон гуравдагч талд хуваалцах нийтлэг формат, үйлчилгээний тодорхойлолтыг санал болгосон. [S29]

Тайлан өгөгдөл удирдлагын гурван загварыг ялгасан:

Тайлан GDPR-ийн үүргийг (data subject, controller, processor, supervisory authority) эрчим хүчний салбарын үүрэгтэй холбосон. Үүнд хэмжилтийн өгөгдөл хариуцагч (Metered Data Responsible), хэрэглэгчийн зөвшөөрөл цуглуулагч, зөвшөөрлийн бүртгэл хариуцагч, таних үйлчилгээ үзүүлэгч гэсэн шинэ үүргүүдийг нэрлэсэн. Мөн хэрэглэгч өөрийн өгөгдөлд хандах, хэнтэй хуваалцахыг хянах эрхийг баталгаажуулалт ба зөвшөөрлийн механизмаар тодорхойлох ёстой гэжээ. [S29, 10–11 дүгээр хуудас]

Хоёр үндсэн үйлчилгээг тодорхойлсон: [S29, 24–27 дугаар хуудас]

• Download My Data. Хэрэглэгч нэвтэрч, өөрийн өгөгдлийг хүнд ойлгомжтой, бүтэцтэй форматаар нэг удаа эсвэл тогтмол татна.
• Share My Data. Хэрэглэгч гуравдагч талд эрх олгоно. Зөвшөөрлийн бүртгэл нь хүлээн авагч, хугацаа, зорилгыг хадгална. Өгөгдлийг машинд уншигдах бүтэцтэй форматаар дамжуулна. Хэрэглэгч эрхээ цуцлах эсвэл засвар хүсэхэд гуравдагч талд автоматаар мэдэгдэнэ.

Тайлан гишүүн улсуудын формат (CSV, JSON, XML, ebIX, DLMS/COSEM) өөр өөр байгааг харуулж, Хойд Америкийн Green Button (NAESB REQ.21 ESPI)-ийг жишээ болгосон. Нийтлэг форматыг CIM, ebIX зэрэг стандарттай нийцтэй, өдөр, цаг, 30, 15, 1 минутын олон нарийвчлал, хэрэглээ, үйлдвэрлэл, реактив энерги зэрэг олон хувьсагчтай байхаар санал болгосон. [S29, 29–32 дугаар хуудас]

Шийдэгдээгүй асуудлууд гэж зөвшөөрлийн бүртгэлийг хэн ажиллуулах, хариуцлага, joint controller-ийн үүргийн хуваарилалт, opt-in эсвэл opt-out, зөвшөөрлийг дараагийн талд дамжуулах эсэх, холбогдох талуудын баталгаажуулалт, нийтлэг дэд бүтцийн зардлыг хэрхэн нөхөхийг нэрлэсэн. [S29, 25–29 дүгээр хуудас]

PowerGrid-д авах санал:

1. PowerGrid нь Дани, Финландын төв hub загварт ойр. Иймээс зөвшөөрлийн бүртгэлийг хэн эзэмших, ажиллуулах, хариуцлага хүлээхийг эхнээс нь хуулийн хувьд тодорхой болгоно. Тайланд энэ асуудлыг шийдэгдээгүй хэвээр үлдсэн гол асуулт гэж тэмдэглэсэн.
2. «Өөрийн өгөгдлөө татах» болон «гуравдагч талд хуваалцах» хоёрыг тусдаа функц, тусдаа эрх, тусдаа аудиттай болгоно.
3. Хэрэглэгчийн экспортын форматыг CIM эсвэл Green Button-тэй зураглах боломжтой, нарийвчлал ба хэмжигдэхүүнийг ил тод заасан JSON/CSV байдлаар тодорхойлно.
4. Тайлан 2016 онд буюу GDPR хэрэгжиж эхлэхээс өмнө бичигдсэн. Түүний зөвлөмжийг ЕХ дараа нь 2023/1162 журмаар албан ёсны лавлагаа загвар болгосон тул PowerGrid-ийн үүргийн нэршилд 2023/1162-ийг суурь болгоно.

#17.2 ЕХ-ны 2023/1162 хэрэгжүүлэх журмын лавлагаа загвар

Комиссын 2023 оны 6 сарын 6-ны 2023/1162 хэрэгжүүлэх журам нь хэмжилт ба хэрэглээний өгөгдөлд хандах харилцан ажиллагааны шаардлага, ялгаварлалгүй, ил тод процедурыг тогтоосон. 2023 оны 6 сарын 15-нд албан ёсны сэтгүүлд нийтлэгдсэн. Лавлагаа загварын шаардлага (3 дугаар зүйл) 2025 оны 1 сарын 5-наас хэрэгжиж эхэлсэн. Гишүүн улсууд үндэсний практикаа 2025 оны 7 сарын 5-ны дотор Комисст тайлагнах үүрэгтэй. [S30–31]

2 дугаар зүйлийн гол үүргүүд болон PowerGrid-д буулгах санал:

Хавсралтын лавлагаа загвар зургаан процедуртай: хэрэглэгч баталгаажсан түүхэн өгөгдлөө авах; хэрэглэгчийн зөвшөөрлөөр eligible party түүхэн өгөгдөл авах; eligible party үйлчилгээгээ зогсоох; хэрэглэгч зөвшөөрлөө цуцлах; ойролцоо бодит хугацааны өгөгдлийн урсгалыг идэвхжүүлэх; тоолуурын баталгаажаагүй шуурхай өгөгдлийг унших. [S30]

PowerGrid-д авах санал: Эдгээр зургаан процедурыг PowerGrid-ийн хүлээн авах тестийн сценари болгоно. Ялангуяа «зөвшөөрөл цуцлагдмагц бүх талд мэдэгдэж, хандалт тэр даруй зогсох», «баталгаажсан түүхэн өгөгдөл ба баталгаажаагүй шуурхай өгөгдлийг өөр сувгаар, өөр шошготой өгөх» шаардлагыг 4 дүгээр бүлгийн Италийн Chain 2 сургамжтай нэгтгэнэ.

#17.3 Бусад жишиг ба тэдгээрээс авах механизм

Залруулга: өмнөх хэлэлцүүлэгт «DCC-д нийлүүлэгч зөвхөн бүртгэлтэй байсан хугацааныхаа өгөгдлийг хардаг» гэж дурдсан. Шалгасан SEC Section H болон User Role тайлбараас үүнийг шууд баталсан заалт олдсонгүй. DCC-ийн баталгаатай механизм нь User Role + тухайн төхөөрөмжид Eligible User эсэх + SMI төлөв юм. Иймээс өгөгдлийн хугацааны хязгаар (data_from/data_until)-ыг PowerGrid-ийн өөрийн дизайны шийдвэр гэж тэмдэглэнэ.

#17.4 Шинэчилсэн архитектур: гурван тусдаа систем

Олон улсын жишгүүдийн аль нь ч эрхийг засаг захиргааны нутаг дэвсгэрээр бус, үүрэг ба хэмжилтийн цэгтэй холбоо хамаарлаар олгодог. Иймээс засаг захиргаа болон бусад бүлгээр харах, шүүх системийг Core-оос тусад нь барина.

1┌─────────────────────────────┐  эрхийн нэг эх сурвалж2│ Authz үйлчилгээ (PDP)       │  өөрийн authz схем эсвэл OpenFGA/SpiceDB3│ + Зөвшөөрлийн бүртгэл       │  2023/1162-ийн Permission administrator4└──────┬──────────────┬───────┘5       │ allowed cells │ dataset / row policy6       ▼               ▼7┌──────────────────┐   ┌───────────────────────────────┐8│ 1. Core (OLTP)   │──▶│ 3. Analytics / Reporting      │9│ PostgreSQL + RLS │   │ нэгтгэл, k-босго, нээлттэй    │10│ эзэмшил, grid    │   │ өгөгдөл, судалгааны dataset   │11│ area, топологи   │   └──────────────▲────────────────┘12└──────▲───────────┘                  │ dimension13       │ гишүүнчлэлийн snapshot        │14┌──────┴──────────────────────────────┴──────┐15│ 2. Grouping / Dimension үйлчилгээ          │16│ засаг захиргаа (bitemporal), дурын бүлэг,  │17│ төсөл, кампанит ажил, хэрэглэгчийн сегмент │18└────────────────────────────────────────────┘

Гол дүрэм:

• Засаг захиргааны нэгж Core-д эрхийн хэмжээс биш, зөвхөн атрибут. Хилийн өөрчлөлт Core-ийн өгөгдлийг дахин тооцохыг шаардахгүй.
• Шинэ бүлэглэл нэмэхэд (жишээ нь «гэр хорооллын дулаан хангамжийн төсөл») зөвхөн Grouping өөрчлөгдөнө. Core-ийн схем, RLS өөрчлөгдөхгүй.
• UI дээрх шүүлтүүр нь эрхийн олонлог дотор л ажиллана. Шүүлтүүр эрхийг хэзээ ч өргөтгөхгүй.
• Нутгийн захиргаа Core-ийн түүхий хүснэгтэд хандах замгүй. Нууцлал нь бүтцээрээ хангагдана.
• Grouping-ийн snapshot хоцорвол бүлгийн grant хуучирсан олонлогоор ажиллана. Snapshot бүр хувилбар, огноотой байх ба Core аль хувилбарыг ашигласнаа аудитын бүртгэлд хадгална.

#17.5 Эрхийн загвар

1access_grant2  grantee_org_id / grantee_user_id3  basis            REGULATORY | OPERATIONAL | CONTRACT | CUSTOMER_CONSENT | AUDIT4  role             HRM / IEC 62351-8 үүрэг (DSO_OPERATOR, REGULATOR_VIEWER, ENGINEER…)5  action           reading.read | summary.read | pii.read | export | tariff.change6                   | command.request | command.approve7  resource_type8  scope_kind       ALL | GRID_AREA | TOPOLOGY | GROUP | METERING_POINT9  scope_ids        ALL-аас бусад үед хоосон байж болохгүй (CHECK)10  data_from / data_until     ← ямар хугацааны өгөгдөл харах11  valid_from / valid_until   ← эрх хэзээ хүчинтэй байх12  purpose, legal_ref         ← зорилгын хязгаарлалт, хуулийн үндэслэл13  group_snapshot_version     ← GROUP үед ашигласан гишүүнчлэлийн хувилбар14  status

Хэрэглэгчийн бодит эрх = байгууллагын grant-уудын нэгдэл ∩ үүргийн эрх ∩ хэрэглэгчид хуваарилсан хамрах хүрээний нэгдэл. Нэг grant доторх нөхцөлүүд (сүлжээ, бүс, топологи, хугацаа) AND-аар холбогдоно. Өөр grant-уудын хооронд cross-product үүсгэхгүй: «(А AND Баянзүрх) OR (Б AND Хан-Уул)» гэсэн семантик хадгалагдана.

Scope cell. (owner_org_id, grid_area_id, topology_node_id[навч])-ийн давтагдахгүй хослол бүрт нэг scope_cell_id олгоно. Заалт, команд, төлбөрийн мөр бүр хэмжилт хийгдэх үеийн харьяаллаар scope_cell_id-тай хадгалагдана. Засаг захиргаа Core-ийн хэмжээс биш болсон тул cell-ийн тоо ойролцоогоор трансформаторын тоотой тэнцэнэ. Policy дотор мөр бүрт функц дуудахгүй, зөвшөөрөгдсөн cell-ийн олонлогийг transaction бүрт нэг удаа тооцно:

1CREATE POLICY reading_select ON meter_reading2FOR SELECT TO powergrid_app3USING (4  (SELECT authz.has_all('reading.read'))5  OR scope_cell_id = ANY ((SELECT authz.allowed_cells('reading.read')))6);

(SELECT ...) хэлбэр нь функцийг InitPlan болгож нэг удаа тооцоолуулах зорилготой. Энэ нь гүйцэтгэлийн таамаглал тул бодит EXPLAIN болон TimescaleDB/partition pruning-ийн туршилтаар батална. PostgreSQL-д нэг хүснэгтийн permissive policy-ууд OR-оор нийлдэг, BYPASSRLS атрибуттай болон хүснэгтийн эзэмшигч role RLS-ийг алгасдаг тул аппын role-д эдгээрийг өгөхгүй. [S39]

Cell-ээс нарийн grant (1.4 хувилбарт нэмэв). Scope cell нь трансформаторын түвшний нэгж. Иймээс дан ганц allowed_cells хоёр төрлийн grant-ыг илэрхийлж чадахгүй:

1. scope_kind = METERING_POINT. Хэрэглэгчийн зөвшөөрлөөр (CUSTOMER_CONSENT) гуравдагч тал нэг цэгийн эрх авдаг. Cell-ээр шүүвэл тухайн трансформаторын бүх өрхийг харах эрх болж хувирна.
2. data_from / data_until. Эзэмшил шилжүүлэх, аудитор, гуравдагч талын grant-ууд тодорхой хугацааны өгөгдлөөр хязгаарлагдана. Cell олонлог хугацааг мэддэггүй.

Иймээс зөвшөөрөгдсөн олонлогийг (scope_cell_id, metering_point_id | NULL, data_from, data_until) хэлбэрийн мөрүүдээр гаргаж, policy-д EXISTS хэлбэрээр тулгана:

1CREATE POLICY reading_select ON meter_reading2FOR SELECT TO powergrid_app3USING (4  (SELECT authz.has_all('reading.read'))5  OR EXISTS (6    SELECT 1 FROM authz.effective_scope('reading.read') s   -- transaction-д нэг удаа materialize7    WHERE s.scope_cell_id = meter_reading.scope_cell_id8      AND (s.metering_point_id IS NULL OR s.metering_point_id = meter_reading.metering_point_id)9      AND meter_reading.interval_start >= s.data_from10      AND (s.data_until IS NULL OR meter_reading.interval_start < s.data_until)11  )12);

Хамрах хүрээ нь бүтэн cell, хугацааны хязгааргүй grant-ууд дээр өмнөх = ANY(allowed_cells) хэлбэр илүү хурдан. Тийм учраас хоёр policy-г permissive байдлаар (OR) зэрэг хэрэглэх эсэхийг EXPLAIN-аар шийднэ. purpose нь мөрийн шүүлтүүр биш. Энэ нь API, экспортын түвшинд шалгагдаж, аудитад бичигдэнэ.

Context-ийн итгэлийн хязгаар. Аппын DB хэрэглэгч SET LOCAL app.* утгыг өөрөө тохируулж чаддаг. Тиймээс апп эвдэрвэл RLS бүрэн хамгаалахгүй. RLS нь гол төлөв аппын алдаанаас хамгаална гэж баримтад шударгаар бичнэ. Хүчитгэх арга: апп зөвхөн app.session_id дамжуулна; authz.current_user_id() (SECURITY DEFINER) нь зөвхөн нэвтрэлтийн үйлчилгээ бичдэг authz.session хүснэгтээс хугацаа, цуцлалт, идэвхтэй байгууллагыг шалгана. Connection pool-той үед заавал transaction-ий хүрээтэй SET LOCAL ашиглана.

Хэрэгжүүлэх сонголт. Эрхийн нэг эх сурвалжийг PostgreSQL дахь өөрийн authz схемээр эхлүүлэх нь хамгийн энгийн. Олон систем (ClickHouse, файл экспорт, API gateway) нэг эрхийг хуваалцах шаардлага өсвөл Zanzibar загварын Go дээрх OpenFGA эсвэл SpiceDB-г (хоёулаа Apache-2.0) PDP болгон харьцуулна. Аль ч тохиолдолд Core-ийн RLS ба ClickHouse-ийн row policy-г тэр нэг эх сурвалжаас үүсгэж, хоёр системийн эрх зөрөхгүй байлгана. [S42]

#17.6 Харьяаллын цаг хугацааны семантик

• Мөрөнд хадгалах topology_node_id нь «normal topology» буюу төлөвлөсөн хэвийн схемээс авна. Шуурхай сэлгэлтийг тусад нь хадгална.
• Заалт ба түүхэн тайланд хэмжилтийн үеийн харьяаллыг, тоолуурт команд өгөхөд одоогийн харьяаллыг ашиглана. Resource бүрт аль семантикийг хэрэглэхийг тогтооно.
• Эзэмшил шилжихэд хуучин эзэмшигч шилжүүлгээс хойшхи өгөгдлийг харахгүй, шинэ эзэмшигч өмнөх өгөгдлийг автоматаар авахгүй. Шилжүүлгийн шинэ meter_assignment хувилбар үүсгэнэ.
• (owner_org_id, grid_area_id, metering_point_id) нийлмэл FK-д эх хүснэгт дээр UNIQUE индекс хэрэгтэй, FK нь ON UPDATE NO ACTION байна.

#17.7 Команд ба service role-ийн хамгаалалт

Реле таслах нь хэрэглэгчийн аюулгүй байдалд нөлөөлдөг (эмнэлгийн тоног төхөөрөмжтэй өрх, өвлийн хүйтэн). RLS-ээс гадна:

• Хүсэлт гаргагч ба батлагч өөр байх «хоёр түлхүүр» дүрмийг constraint эсвэл trigger-ээр хэрэгжүүлнэ (approved_by <> requested_by).
• Олон тоолуурт нэг дор өгөх командад тоо хязгаар, нэмэлт баталгаажуулалт тавина.
• Хамгаалагдсан хэрэглэгчийн жагсаалтыг worker илгээхийн өмнө дахин шалгана (10 дугаар бүлэг).
• HES ingestion сервис powergrid_ingest role-той: зөвхөн INSERT, тухайн HES instance-д бүртгэлтэй owner_org_id-оор WITH CHECK хязгаартай, SELECT эрхгүй.
• Background job бүр хэрэглэгчийн эрхийг өвлөхгүй, өөрийн тодорхой service role-той байна.

#17.8 Агрегатын нууцлал

Баг эсвэл хороонд цөөн өрх байвал «нийт хэрэглээ» нь бараг хувь хүний мэдээлэл болно. Их Британийн SLC10A нь нэг сараас богино хугацааны өрхийн хэрэглээг нэгтгэх эсвэл хувь хүнтэй холбогдохгүй болгохыг шаарддаг; SSEN нэг агрегатад хамгийн багадаа 5 MPAN ашигладаг. [S36]

PowerGrid-ийн санал:

• k-ээс бага нүдийг нууна, хэмжээг «<k» гэж харуулна.
• Давамгайллын дүрэм (1.4 хувилбарт нэмэв). k-г хангасан ч нэг том хэрэглэгч (үйлдвэр, уурхай, байгууллага) нүдний нийлбэрийн ихэнхийг эзэлдэг бол нийлбэр нь түүний хэрэглээг илчилнэ. Иймээс хамгийн том 1 цэг нийлбэрийн p%-иас (санал: 50%), хамгийн том 2 цэг q%-иас (санал: 80%) их байвал нүдийг нууна. Мөн давхардсан дүнгээр нуусан нүдийг сэргээж тооцохоос сэргийлж хоёрдогч нуулт (secondary suppression) хийнэ. p ба q нь k-тай хамт батлагдана.
• Ялгавар тооцох халдлагаас хамгаална: хоёр давхцсан шүүлтүүрийн зөрүүгээр нэг өрхийг тодруулах боломжийг хаахын тулд Analytics-д зөвхөн урьдчилан тодорхойлсон бүлгүүдийг нийтэлж, дурын шүүлтүүр давхцуулахыг хязгаарлана.
• detail_level-ийг тусдаа action болгоно (summary.read, reading.read). Ингэвэл агрегатын эрх түүхий хүснэгтэд хэзээ ч таарахгүй.
• k=10 нь PowerGrid-ийн санал; Ofgem-ийн заавал мөрдөх тоо биш. Монголын хуулийн шаардлага, ЭХЗХ-ны журмаар батална.

#17.9 Монголын оролцогчдыг үүрэгт буулгах

Байгууллагуудын нэр, хуулийн бүрэн эрх нь жишээ. Эрчим хүчний тухай хууль, ЭХЗХ-ны журам болон Хүний хувийн мэдээлэл хамгаалах тухай хууль (2021 оны 12 сарын 17-нд баталж, 2022 оны 5 сарын 1-нээс хэрэгжсэн)-тай тулгаж батлах хэрэгтэй. Тоолуурын хэрэглээний муруй тухайн хуулийн «хувийн мэдээлэл»-д хэрхэн хамаарах, хэрэглэгчийн зөвшөөрлийн хэлбэр, хяналтын байгууллагын шаардлагыг хуулийн зөвлөхөөр тодруулна. [S40]

#17.10 Хүлээн авах туршилт

#17.11 Технологийн лицензийн тэмдэглэл

Analytics-ийн хувилбарт TimescaleDB-ийн continuous aggregate ашиглахыг санал болгож байсан. TimescaleDB-ийн баримтаар continuous aggregate, columnstore буюу шахалт, retention policy нь Apache 2 хувилбарт биш, Timescale License (Community) хувилбарт багтдаг. [S41] Иймээс эдгээрийг ашиглах бол TSL-ийн нөхцөлийг хуулийн талаас шалгана. Эсвэл PostgreSQL-ийн энгийн materialized view/partition болон ClickHouse-ийн хувилбартай харьцуулна.

#17.12 Нээлттэй шийдвэрүүд

1. Hub эсвэл тархсан загвар уу? Шийдэгдэв (1.6, 18.2): PowerGrid нь hub. Түгээх компаниуд өөрийн HES/MDM-ээ хадгалж, өгөгдлөө гэрээгээр илгээнэ.
2. Зөвшөөрлийн бүртгэлийг хэн ажиллуулж, хариуцлага хүлээх вэ?
3. Хэрэглэгчийн зөвшөөрлийг eID-ээр баталгаажуулах уу?
4. Analytics-ийн k босго, хугацааны нарийвчлал, нээлттэй өгөгдлийн хүрээг аль байгууллага батлах вэ?
5. Эрхийн эх сурвалжийг PostgreSQL authz схемээр эхлүүлэх үү, эсвэл эхнээс нь OpenFGA/SpiceDB хэрэглэх үү?

#1918 Монголын нөхцөлд гаргасан шийдвэрүүд

Энэ бүлэг 1.4 хувилбарт асуулт хэлбэрээр нэмэгдсэн. 1.5 хувилбарт захиалагчийн чиглэлээр шийдвэр болгон шинэчилсэн. Шийдвэр бүр дэлхийн жишигт тулгуурласан бөгөөд ADR хэлбэрээр батлагдана. Бодит тоо баримт (тоолуурын тоо, загвар, тарифын тогтоол) шийдвэрээр бус, өгөгдлөөр л тодорхойлогдоно. Тиймээс ийм зүйлсийг 18.8-д «өгөгдлийн хүсэлт» болгон тусад нь жагсаав.

#18.1 Зорилтын эрэмбэ (захиалагчийн чиглэл, 2026-10-14)

«Бүрэн удирдах»-ын хил. PowerGrid тоолуурын түвшинд удирдана: реле таслах, залгах, ачааллын хязгаар, тарифын тохиргоо. Шугам, дэд станцын сэлгэлт, хамгаалалт нь Үндэсний диспетчерийн төвийн SCADA/EMS-ийн хариуцлагад үлдэнэ. PowerGrid SCADA-аас зөвхөн уншиж, урсгалын зураглалдаа ашиглана (8 дугаар бүлэг). Энэ хил нь олон улсын жишигтэй нийцнэ: AMI/MDM болон SCADA/ADMS нь тусдаа систем бөгөөд интеграцын заагаар холбогддог.

#18.2 Өгөгдлийн эх сурвалж: түгээх компаниудын систем (hub загвар)

Нөхцөл (захиалагчийн мэдээлэл, 2026-10-14). Түгээх сүлжээний компаниудад тоолуурын өгөгдөл ерөнхийдөө аль хэдийн цугларсан байгаа. Иймээс PowerGrid-ийн эхний ажил нь тоолуураас шууд унших биш. Харин одоо байгаа өгөгдлийг нэгтгэх ажил болно.

Жишиг.

• Финландын Fingrid Datahub болон Данийн Энержинет DataHub нь тоолуур уншдаггүй.
• Түгээх компани (DSO) бүр «Metered Data Responsible» үүрэгтэй: өөрийн тоолуураа уншиж, баталгаажуулсан өгөгдлөө тогтсон форматаар hub руу илгээдэг.
• Hub нь бүртгэл, эрх, хэрэглэгчийн хандалт, зах зээлийн оролцогчдын өгөгдөл солилцоог хариуцдаг [S01, S33–34].
• ЕХ-ны «My Energy Data» тайлан энэ загварыг «төв data hub» гэж ангилдаг (17.1).

Шийдвэр (ADR-002-ыг шийднэ: hub).

1. PowerGrid бол үндэсний hub. PowerGrid нь metered data administrator, metering point administrator, data access provider үүргийг гүйцэтгэнэ. Түгээх компани бүр өөрийн HES/MDM-ээ хадгалж, metered data responsible үүрэгтэй үлдэнэ (17.2).

2. Өгөгдөл солилцооны гэрээ. Түгээх компаниудтай нэг стандарт гэрээ байгуулна. Гэрээнд дараах зүйлс багтана:

   • хэмжилтийн цэг ба тоолуурын бүртгэл;
   • register ба interval заалт, тэдгээрийн чанарын төлөв (A/E/S/F);
   • үйл явдал (тасралт, хөндлөнгийн оролдлого);
   • давтамж (өдөр бүр, D+1) ба засвар илгээх журам.

   Формат нь IEC 61968-9 (CIM)-тэй зураглагдах JSON/CSV байна. Тээвэрлэлт нь API эсвэл SFTP байна. Компани бүрийн өөрийн форматыг эхэндээ адаптераар хүлээн авч, гэрээний форматад шатлан шилжүүлнэ.

3. Урсгалын хяналт. Фидер ба трансформаторын тоолуурын өгөгдлийг мөн түгээх компаниудаас авна. Дэд станц, дамжуулах түвшнийг диспетчерийн төвийн SCADA-аас зөвхөн уншина. Түвшин бүрийн балансыг 9 дүгээр бүлгийн дүрмээр (бүрэн байдал, estimated хувь, topology хувилбартай) тооцно. Хэрэглэгчийн тоолуурын өгөгдөл аль хэдийн байгаа тул урсгалын зураглалд хэрэглэгчийн түвшин эхнээсээ орно.

4. Шууд уншилт зөвхөн цоорхойд. PowerGrid-ийн өөрийн DLMS адаптерыг (12 дугаар бүлэг) зөвхөн HES-гүй түгээх компани эсвэл бүсэд, мөн hub-ын хөндлөнгийн шалгалтын (check meter) зорилгоор ашиглана.

5. Команд ба prepaid. Реле таслах, залгах командыг тухайн түгээх компанийн HES-ээр дамжуулна. PowerGrid командын хүсэлт, зөвшөөрөл, хамгаалалтын бодлого, аудитыг эзэмшинэ. Компанийн HES нь гүйцэтгэл болон read-back үр дүнг буцаана. 10 дугаар бүлгийн төлөвийн машин өөрчлөгдөхгүй, зөвхөн адаптер нь HES болно. HES командын API-гүй компанид prepaid-ийн автомат таслалт идэвхжихгүй.

6. Эрх. Түгээх компани бүр зөвхөн өөрийн owner_org_id-ийн өгөгдлийг илгээж, хардаг. Энэ нь 17.7-ийн powergrid_ingest дүрэм юм.

Үр дагавар.

• 13 дугаар бүлгийн «лабораторид тоолуур турших» алхам эхний шатанд «түгээх компани бүрийн өгөгдлийн чанарын аудит» болж өөрчлөгдөнө: бүрэн байдал, давхардал, цаг, нэгж, ID-ийн тогтвортой байдал.
• 14 дүгээр бүлгийн оргил ачаалал багасна, учир нь өгөгдөл тоолуураас биш, компаниудаас багцаар ирнэ.

#18.3 Гар утсаар төлөх

Жишиг. Энэтхэгийн BBPS бол олон банк, апп нэг стандарт «bill fetch → pay → confirm» протоколоор нийлүүлэгчийн нэхэмжлэлийг төлдөг нэгдсэн сүлжээ. Кенийн KPLC хэрэглэгчид M-Pesa-аар postpaid төлбөр төлж, prepaid token худалдан авдаг. Узбекистаны HET-ийн апп заалт, төлбөр, өрийг нэг дор нэгтгэдэг [S19]. Эдгээр жишгийн нийтлэг зарчим: нийлүүлэгч нь биллер, төлбөрийн суваг олон байна, тулгалт нэг ledger-т хийгдэнэ.

Шийдвэр.

1. PowerGrid бол биллер. PowerGrid нэхэмжлэл үүсгэх, төлбөр хүлээн авах, буцаалт хийх, өдөр тутмын тулгалт хийх нэг стандарт API-тай байна. Банк, QR төлбөрийн үйлчилгээ үзүүлэгч, e-Mongolia бүр энэ API-д адаптераар холбогдоно. Нэг үйлчилгээ үзүүлэгчид түгжигдэхгүй.
2. Хоёр суваг.
   • Хэрэглэгчийн апп: Nexus-ийн native mobile апп болон вэб (person surface).
   • Банкны апп дотор mini app: Nexus-ийн guest горимоор нээгдэнэ.
3. Төлбөрийн урсгал. Хэрэглэгч нэхэмжлэл сонгоно → QR эсвэл deeplink нэхэмжлэх үүснэ → банк callback илгээнэ → ledger-т idempotent бичилт хийгдэнэ. Нэхэмжлэх бүр өвөрмөц reference-тэй. Callback-ийг үйлчилгээ үзүүлэгчийн API-аас статус асууж баталгаажуулна. Өдрийн settlement файлтай тулгана. Ledger-ийн дүрэм 10 дугаар бүлгийн дагуу.
4. Payment hub эхлээд, billing дараа нь. PowerGrid-ийн тариф ба billing ашиглалтад орох хүртэл (shadow billing ≥2 мөчлөг) хүлээхгүй. Эхний хувилбарт одоогийн billing системийн нээлттэй нэхэмжлэлийг импортолж, гар утсаар төлүүлээд, төлбөрийг буцааж тэр системд илгээнэ. BBPS нийлүүлэгчийн одоо байгаа billing дээр ажилладагтай ижил зарчим. Энэ нь зорилт 1-ийн «гар утсаар төлөх» хэсгийг хамгийн хурдан хүргэнэ.
5. Хувийн мэдээлэл. Төлбөрийн сувагт зөвхөн дансны дугаар, дүн, нэрийн масктай хэлбэрийг өгнө. Хэрэглээний муруйг төлбөрийн сувагт өгөхгүй.

#18.4 Postpaid-аас prepaid руу

Жишиг.

• Prepaid-ийн хоёр загвар бий. Нэг нь STS token загвар: үлдэгдлийг тоолуур хадгалж, хэрэглэгч 20 оронтой код оруулна (Африк, IEC 62055-41). Нөгөө нь ухаалаг prepaid: үлдэгдлийг сервер тооцож, алсаас таслах/залгах команд өгнө (Энэтхэгийн RDSS).
• Энэтхэгт prepaid тоолуурт emergency credit олгож, үлдэгдлийн урьдчилсан мэдэгдэл илгээдэг [S16].
• Их Британийн Ofgem prepay хэрэглэгчид «friendly credit»-ийн цаг (шөнө, амралтын өдөр таслахгүй) болон emergency credit-ийг шаарддаг.
• АНУ-ын олон муж хүйтний температурын босгоор таслалтыг хориглодог (winter moratorium).

Шийдвэр.

1. Ухаалаг prepaid загвар. Үлдэгдлийг PowerGrid-ийн ledger тооцно. Өдөр бүрийн register заалтаар хэрэглээг хасна. Таслах, залгахыг 10 дугаар бүлгийн командын төлөвийн машинаар гүйцэтгэнэ. Шалтгаан: зорилт 1 нь бүрэн хяналт; серверийн үлдэгдэл тарифын өөрчлөлтийг төхөөрөмж рүү түлхэлгүй хэрэгжүүлэх, апп-д бодит үлдэгдэл харуулах, гар утсаар цэнэглэх боломж олгоно.

2. STS-ийг зөвхөн нөөц сонголт болгоно. Холбоогүй цэг болон аль хэдийн STS keypad тоолуур суурилсан цэгт хэрэглэнэ. Vending-ийг гэрээт үйлчилгээ үзүүлэгчтэй адаптераар холбоно. Тухайн тоолуурын 2024 оны TID rollover-ыг шалгасан байх ёстой.

3. Шилжилтийн дараалал.

   1. Postpaid хэвээр, гар утсаар төлнө.
   2. Postpaid дээр өдрийн хэрэглээ болон тооцоолсон дүнг апп-д харуулна («виртуал prepaid»).
   3. Нэг трансформаторын бүлэгт сайн дурын prepaid пилот хийнэ.
   4. Шинэ холболт болон өртэй хэрэглэгчид prepaid-ийг үндсэн горим болгоно.
   5. Улсын хэмжээнд ЭХЗХ-ны журам батлагдсаны дараа өргөжүүлнэ.

   Бодлогын давхарга нь журмаас хамаарахгүй тул 1, 2-р алхмыг журам батлагдахыг хүлээлгүйгээр хэрэгжүүлнэ.

4. Хэрэглэгчийн хамгаалалт (тохируулж болох анхны утга).

Тоонууд нь PowerGrid-ийн санал бөгөөд ЭХЗХ-ны журмаар батлагдана.

#18.5 Цагийн бүс

Шийдвэр.

• Бүх timestamp-ыг UTC (timestamptz)-ээр хадгална.
• metering_point бүрт аймгийн харьяаллаас хамааран local_zone-г тогтооно: Ховдын бүсийн 5 аймагт UTC+7, бусад нь UTC+8 (IANA Asia/Hovd, Asia/Ulaanbaatar).
• Тарифын цагийн бүс (өдөр, шөнө), өдрийн хаалт, сарын хаалт, таслахгүй цагийг тухайн цэгийн local_zone-оор тооцно.
• Тоолуурын цагийг тухайн бүсийн стандарт цагаар тохируулна. clock_quality-ийг 9 дүгээр бүлгийн дагуу хадгална.
• 2017 оноос өмнөх түүхэн өгөгдөлд IANA-ийн түүхэн дүрмийг хэрэглэнэ (зуны цаг орно).

#18.6 Тоолуурын протокол, түлхүүр, худалдан авалт

Шийдвэр.

1. Интеграцын зам (18.2).
   • Үндсэн зам: түгээх компанийн HES/MDM-ээс өгөгдөл солилцооны гэрээгээр авна.
   • Нөөц зам: HES-гүй хэсэгт шууд DLMS/COSEM адаптер (Gurux, 12 дугаар бүлэг) ашиглана.
   • Inventory DL/T 645 тоолуурыг мэдэгдэхүйц хувьтай гэж харуулбал хоёр дахь протоколын адаптер нэмнэ. Харуулахгүй бол нэмэхгүй.
2. Гар уншилт. Холбоогүй цэгт IEC 62056-21 оптик портоор гар төхөөрөмжөөр уншиж, source_system = manual_handheld, quality = A-аар оруулна. Гараар бичсэн заалтыг тусдаа эх үүсвэрээр ялгана.
3. Түлхүүрийн эзэмшил. DLMS болон STS-ийн түлхүүр хуулийн дагуу операторын мэдэлд байна. Шинэ худалдан авалтын гэрээнд түлхүүр шилжүүлэх нөхцөлийг заавал тусгана. Шилжүүлэх боломжгүй тоолуурт алсын команд идэвхжүүлэхгүй (15 дугаар бүлгийн хасах шалгуур).
4. Шинэ тоолуурын техникийн шаардлага.
   • DLMS/COSEM; IDIS эсвэл түүнтэй адил companion profile.
   • HLS (security suite 1 буюу түүнээс дээш).
   • Реле, prepaid горимын дэмжлэг.
   • Ажиллах температур −40…+70°C (IEC 62052-11-ийн өргөтгөсөн хүрээ).
   • 4G/NB-IoT эсвэл PLC+DCU.
   • 15 эсвэл 30 минутын load profile, ≥60 хоногийн локал архив.

#18.7 Тариф, нэхэмжлэх, хууль ба дэд бүтэц

Тариф ба нэхэмжлэх.

• Тарифын хөдөлгүүр нэг тариф, бүсчилсэн (өдөр/шөнө, 2–3 бүс), шатлалт, хэрэглэгчийн ангиллыг тохиргоогоор дэмжинэ.
• Postpaid нэхэмжлэлийг сарын эхний өдрийн 00:00-ийн (local_zone) register заалтаар гаргана. Prepaid өдрийн register snapshot-оор хасна.
• Эхний шатанд billing-д load profile шаардлагагүй. Load profile-ийг баланс болон хэрэглэгчийн графикт ашиглана.
• Үүний үр дүнд эхний үеийн billing-ийн өгөгдлийн хэмжээ 14 дүгээр бүлгийн 15 минутын тооцооноос мэдэгдэхүйц бага гарна. Багтаамжийн тооцооны 15 минутын хувилбар нь баланс болон load profile-д хүчинтэй хэвээр.
• Мөнгөн дүнг numeric-ээр тооцно. Эцсийн нэхэмжлэлийг бүхэл төгрөг рүү дугуйруулна. НӨАТ болон хураамжийн хувийг тарифын хувилбарт тусгана.

Хууль ба төрийн систем.

• PowerGrid-ийг эгзэгтэй мэдээллийн дэд бүтэц гэж үзэж зохион байгуулна. Кибер аюулгүй байдлын тухай хуулийн шаардлага, IEC 62443 болон ISO/IEC 27001-тэй нийцсэн хяналт хэрэгжүүлнэ.
• Өгөгдлийг Монгол Улсын нутаг дэвсгэр дээр байршуулна. Хувийн мэдээллийг хилээр дамжуулахгүй.
• Иргэнийг eID-ээр (nexus.EID) таньж, регистрийн дугаарыг ХУР-аар баталгаажуулна.
• Регистрийн дугаарыг шифрлэж хадгална. Хайлтад hash ашиглана.

Дэд бүтэц.

• Хот дахь орон сууц: PLC+DCU эсвэл 4G.
• Гэр хороолол: 4G/NB-IoT.
• Сум, баг: хамрах хүрээгээр 4G эсвэл гар уншилт.
• Эхний пилот хоёр талбайтай: Улаанбаатарын нэг орон сууцны трансформатор (нягт, сайн холбоотой) болон нэг гэр хорооллын трансформатор (өвлийн ачаалал, холбооны эрсдэл). 13 дугаар бүлгийн «өөр нөхцөлтэй хоёр дахь талбай» шаардлагыг эхнээс нь хангана.

#18.8 Өгөгдлийн хүсэлт (шийдвэрээр орлуулах боломжгүй)

1. Түгээх компани бүрийн системийн inventory:
   • HES/MDM/billing-ийн нийлүүлэгч, хувилбар;
   • хамрах тоолуурын тоо, алсаас уншигдах хувь;
   • register эсвэл interval, интервалын урт;
   • экспортын хэлбэр (API, файл, DB), түүхэн өгөгдлийн хугацаа;
   • командын API байгаа эсэх;
   • өгөгдөл хуваалцах гэрээ, хуулийн үндэслэл.
2. Өгөгдлийн дээж (нэг сар, нэг трансформаторын бүлэг) — компани бүрээс. Тоолуурын загвар, реле, prepaid горим, түлхүүрийн эзэмшлийн inventory.
3. Фидер болон трансформаторын тоолуурын хамрах хүрээ (компани бүрээр).
4. Үндэсний диспетчерийн төвийн SCADA-аас өгөгдөл авах интеграцын хэлбэр, эрх.
5. Одоогийн billing систем, түүний нэхэмжлэл импортлох болон төлбөр буцааж илгээх интерфэйс.
6. Хүчинтэй тарифын тогтоол, хэрэглэгчийн ангилал.
7. Төлбөрийн эхний үйлчилгээ үзүүлэгч(ид)-ийн API-ийн баримт, гэрээ.
8. Хамгаалагдсан хэрэглэгчийн жагсаалтын эх сурвалж.
9. Пилотын хоёр трансформатор ба харьяа хэрэглэгчдийн жагсаалт.

#20Эх сурвалжийн бүртгэл

Бүх цахим эх сурвалжийг 2026 оны 10 сарын 2-нд шалгав. Гарчиг дээр дарж эх сурвалжийг нээнэ. Тоон үзүүлэлт бүрийн хугацаа, хамрах хүрээг үндсэн текстэд тусгасан.

**[S01] Fingrid **Datahub

Албан ёсны үйлчилгээний тайлбар; хэрэглээний цэг, оролцогч, эрхийн хүрээ.

**[S02] Fingrid **Datahub customer portal questions and answers

Мэдээлэл ирэх хугацаа, 15 минут/цагийн нарийвчлал, estimated өгөгдөл, агрегат нээлттэй өгөгдөл.

**[S03] AEMO **Five Minute Settlements

2021 оны 10 сарын 1-нд хэрэгжсэн 5 минутын settlement.

**[S04] AEMO **Interval Metering Data Results

Заалтын A/E/S/F төлөв, current/history бичлэг, хувилбарын цаг. 2026 оны 7 сарын 31-ний шинэчлэлт.

**[S05] Enedis **Rapport RSE 2024

2024 оны эцсийн Linky суурилуулалтын операторын мэдээлэл.

**[S06] Enedis **Données personnelles

Хэмжилтийн өгөгдлийн зориулалт, зөвшөөрөл, хадгалалтын бодлого.

**[S07] E Distribuzione **Open Meter

2G тоолуурын нэвтрүүлэлт, бүтээгдэхүүний тайлбар; огноогүй веб хуудсын үзсэн үеийн төлөв.

**[S08] E Distribuzione **Chain 2

PLC-C хэрэглэгчийн суваг, төхөөрөмжийн нийцэл, үйлчилгээний нөхцөл.

**[S09] Smart DCC **Annual Report 2024–25

Цахилгаан ба хийн холбогдсон тоолуур, үйлчилгээний бэлэн байдал. Операторын тайлан.

**[S10] National Audit Office **Update on the rollout of smart meters

2023 оны аудит; smart mode-д ажиллахгүй тоолуурын тухайн үеийн үзүүлэлт.

**[S11] US Department of Energy **Advanced Metering Infrastructure and Customer Systems

SGIG үр дүнгийн 2016 оны тайлан; хэвлэмэл 25–26 ба 66 дугаар хуудсын outage болон интеграцын тайлбар.

**[S12] TEPCO Power Grid **Smart Meter Project

FY2020 хүртэлх хамрах хүрээ, 30 минутын боловсруулалт, operations center.

**[S13] TEPCO Power Grid **Electricity meter specifications

Нээлттэй техникийн тодорхойлолт ба худалдан авалтын зарчим. Япон хэл дээрх эх.

**[S14] Energy Market Authority Singapore **What are advanced electricity meters

Хагас цагийн хэмжилт ба 2026 он хүртэлх нэвтрүүлэх зорилт.

**[S15] SP Group **Sustainability Review FY2022–23

SP app дахь хагас цагийн хэрэглээний харагдац.

**[S16] India Ministry of Power via PIB **Nationwide Push for Smart Prepaid Meters

2025 оны 12 сарын 11; суурилуулалт, RDSS баталсан тоо, emergency credit, хэрэглэгчийн үйлчилгээний арга хэмжээ.

**[S17] Asian Development Bank **Uzbekistan Advanced Electricity Metering Project Completion Report

2022 оны 12 сар; CAS, трансформаторын баланс, billing интеграц, лаборатори.

**[S18] Uzbekistan Ministry of Energy **HET Billing technical work announcement

2024 оны 8 сарын 9; буруу өртэй харагдсан хэрэглэгчийг таслахгүй тухай мэдэгдэл.

**[S19] UZINFOCOM and HET **HET Billing Mobile

Албан ёсны аппын боломжууд; хэрэглээ, төлбөр, өр, хүсэлт.

**[S20] NIST **NISTIR 7628 Revision 1

2014 оны smart grid cybersecurity эрсдэлийн хүрээ. Монголын заавал дагах хууль гэж тайлбарлаагүй.

**[S21] DLMS User Association **Qualification and certification

Compliance ба compatibility баталгаажуулалтын ялгаа.

**[S22] Gurux **Gurux DLMS Python and licensing FAQ

Python сангийн GPL 2.0 лиценз ба GPL/commercial сонголтын мэдээлэл.

Gurux dual licensing FAQ

**[S23] Fraunhofer ISE OpenMUC **OpenMUC Overview

Framework, драйверууд, GPLv3 болон тусгай лицензийн мэдээлэл.

[S24] ThingsBoard — Repository ба одоогийн LICENSE, 2026-09-29-ний лицензийн өөрчлөлт

2026-10-02-ны залруулга: CE 4.3 болон 4.4+ хувилбарын лицензийг ялгав. Дэлгэрэнгүй сонголтыг Нээлттэй эх ба төслийн мэдлэгийн судалгаа-аас үзнэ.

**[S25] OSGP project repository **Grid eXchange Fabric retirement notice

README-д retired, идэвхтэй хөгжүүлэлт ба засвар үйлчилгээ байхгүй гэж тэмдэглэсэн.

**[S26] gerege systems **teami gerege uz overview

Төслийн зорилго, MDM модулиуд. Commit 4ac3dfb15829264722d2b2fc78fa8361deb58cac.

**[S27] gerege systems **Readings and load control handlers

Уншилтын өгөгдөл үүсгэх болон DB төлөв өөрчилдөг командын хэрэгжүүлэлт.

Load control handler

**[S28] gerege systems **TEAMI archive pull integration

Нэг удаагийн таталт, ID ба timezone, production бэлтгэлийн шаардлага.

**[S29] European Smart Grids Task Force, Expert Group 1 **“My Energy Data” report, 2016-11

Өгөгдөл удирдлагын гурван загвар, GDPR-ийн үүрэг, Download/Share My Data, зөвшөөрлийн бүртгэл, форматын харьцуулалт, Green Button.

**[S30] European Commission **Implementing Regulation (EU) 2023/1162

2 дугаар зүйлийн үүргүүд, хавсралтын 6 процедур, 3 дугаар зүйл 2025-01-05-наас, үндэсний практикийн тайлан 2025-07-05.

**[S31] ENTSO-E ба EU DSO Entity TSO-DSO платформ **Electricity Data Interoperability

Үндэсний практикийн repository, Joint Working Group on Data Interoperability.

**[S32] ENTSO-E, ebIX, EFET **Harmonised Electricity Market Role Model 2023-01

Зах зээлийн үүрэг, домэйн, Metering Point ба Metering Grid Area.

**[S33] Energinet **Terms of access to and use of the DataHub, third party

NemID-ээр олгох цахим итгэмжлэл, гуравдагч талын үйлдлийн лог, зөрчилд хасах.

**[S34] Energinet **Customer and third-party API for DataHub (Eloverblik)

Хэрэглэгч ба гуравдагч талын API-ийн техникийн тайлбар, 2022-03-21.

**[S35] Smart Energy Code Company **User Role, SEC Section H: DCC Services

7 User Role, Eligible User шаардлага (H3.6), үүргийн үйлчилгээ (H3.8), SMI төлөвөөр ялгах (H3.9).

**[S36] SSEN **Smart Meter Data Privacy Plan v2.3

SLC10A-ийн шаардлага, хамгийн бага 5 MPAN, LV фидер/трансформаторын түвшний нэгтгэл, нэгтгээгүй өгөгдлийг устгах.

**[S37] IEC **IEC 61968-9:2024 Meter reading and control

CIM-ийн UsagePoint, EndDevice, бүлгийн ангиллууд.

**[S38] IEC **IEC/TS 62351-8:2011 Role-based access control (preview)

Урьдчилан тодорхойлсон үүрэг, «area of responsibility» тодорхойлолт, PUSH/PULL загвар.

**[S39] PostgreSQL **Row Security Policies

Permissive/restrictive policy-ийн нийлэх дүрэм, BYPASSRLS, хүснэгтийн эзэмшигч ба FORCE ROW LEVEL SECURITY.

**[S40] Монгол Улсын хууль **Хүний хувийн мэдээлэл хамгаалах тухай хууль, Gratanet-ийн тайлбар

2021-12-17-нд баталж, 2022-05-01-нээс хэрэгжсэн.

**[S41] Timescale **TimescaleDB editions

Continuous aggregate, columnstore, retention policy нь Community (TSL) хувилбарт.

**[S42] OpenFGA ба SpiceDB **OpenFGA, SpiceDB

Go дээрх Zanzibar загварын эрхийн сервер, Apache-2.0.