Нээлттэй эхийн судалгаа

1.2 хувилбарын өөрчлөлт: Go дээрх DLMS сангууд (gxdlms-go, gosem), EPRI dlms-access-point, EnAccess OpenSmartMeter, OpenMeter-ийг нэмэв; эрхийн сервер (OpenFGA, SpiceDB) ба pgTAP-ийг нэмэв; TimescaleDB-ийн continuous aggregate-ийн лицензийн заагийг тодруулав; FN-09-ийг шинэчилж FN-13–FN-15-ыг нэмэв. Өгөгдөлд хандах эрхийн дэлгэрэнгүй загварыг олон улсын судалгааны 17 дугаар бүлэг-т бичсэн.

#011. Зорилго ба гол шийдвэр

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

Баталсан бүтээгдэхүүний чиглэл: PowerGrid бол Монгол Улсын 1 сая тоолуурыг хамрах зорилготой, өөрсдийн хөгжүүлэх үндэсний шинэ систем. Өөрийн домэйн загвар, API, хэрэглэгчийн интерфэйс, бизнесийн дүрэм, эрхийн бүтэц, ашиглалтын удирдлагатай байна. Нээлттэй эхийн төслүүдийн сайн функционал, ажлын урсгал, алдааны боловсруулалт, архитектурын шийдлийг судалж, PowerGrid-ийн бие даасан шаардлага болгон боловсруулна.

Энэ тайлангийн бүтээгдэхүүн сонгох, адаптер турших, программ суулгах саналууд нь техникийн боломжит хувилбарын лавлагаа бөгөөд батлагдсан stack биш. Гол үр дүн нь “ямар бүтээгдэхүүн суулгах вэ” гэсэн жагсаалтаас илүү “PowerGrid яг юу хийдэг, ямар дүрмээр ажилладаг, зөв ажилласныг хэрхэн батлах вэ” гэсэн функционал тодорхойлолт байна. Ерөнхий зориулалтын сан, протоколын SDK, өгөгдлийн санг дахин ашиглах эсэхийг функционал ба архитектурын шаардлага гарсны дараа тусад нь шийднэ.

Бүтээгдэхүүний чадвар, лицензийн баримтыг албан ёсны репозиторий болон баримтаас авсан. “PowerGrid-д санал” гэсэн шийдвэрүүд нь энэ судалгааны инженерийн үнэлгээ. Нэг сая төхөөрөмжийн бодит туршилт, бүтээгдэхүүнүүдийн харьцуулсан benchmark хийгээгүй; серверийн тоо болон баталгаатай throughput амлаагүй.

#022. Өмнөх судалгаанд хийх лицензийн залруулга

ThingsBoard-ийн 2026-09-29-ний мэдэгдлээр 4.4-өөс BUSL 1.1 бүхий source-available загварт шилжсэн. CE 4.3 нь Apache 2.0 хэвээр гэж тайлбарласан. Иймээс өмнөх тайлангийн ThingsBoard-ийг хувилбар ялгалгүй Apache 2.0 гэж нэрлэсэн мөрийг шинэчилнэ. Албан мэдэгдэл

Одоогийн LICENSE-д арилжааны үнэгүй ашиглалтыг 100 төхөөрөмж, нэг серверээр; арилжааны бусыг 1,000 төхөөрөмжөөр хязгаарласан бөгөөд нэмэлт нөхцөлтэй. Нэг сая тоолуурын PowerGrid нь энэ үнэгүй хүрээнд багтахгүй. Энэ лицензийн мэдээлэл нь ThingsBoard код эсвэл бүтээгдэхүүнийг шууд ашиглах хувилбарт хамаарна. PowerGrid-ийн баталсан чиглэл нь өөрийн бүтээгдэхүүн хөгжүүлэх тул ThingsBoard-ийн бизнесийн үйлдэл, хэрэглэгчийн урсгалыг лавлагаа болгон судална. Хуучин Apache хувилбарыг хадгалах бол шинэчлэлт, хамгаалалтын засварыг хэн хариуцахыг тооцно. ThingsBoard LICENSE

GitHub дээр эх код харагддаг, үнэ төлбөргүй татагддаг, OSI утгаар нээлттэй эхтэй гэдэг нь өөр ойлголт. Сонголтын бүртгэлд бүтээгдэхүүний нэрээс гадна хувилбар, commit, лицензийн файл, шаардлагатай боломж, шинэчлэх замыг хадгална.

#033. Бүрэлдэхүүний харьцуулалт

Доорх лицензүүд нь шалгасан upstream эхийн нөхцөл. Cloud үйлчилгээ, enterprise багц, plugin, контейнерийн дагалдах dependency тусдаа нөхцөлтэй байж болно. Ангилал нь PowerGrid-д хэрэглэх санал бөгөөд нийлүүлэгчийн баталгаа биш.

#044. Тоолууртай холбогдох давхарга

#4.1 Gurux-ийг хэрхэн хэрэглэх вэ

Gurux нь DLMS өгөгдлийг үүсгэх, задлах сан; transport-ыг өөр холболтын сангаар хэрэгжүүлж болдог. Төсөл dual license нөхцөлтэй бөгөөд техникийн тусламжийг GitHub issue-ээс илүү өөрийн форумаар авахыг заасан. Албан хуудсанд 2026 оны шинэ release-үүд харагдаж байгаа нь хөгжүүлэлтийн идэвхийн нэг нотолгоо боловч SLA биш. Repository, DLMS тайлбар ба release холбоосууд

PowerGrid-д санал: Python адаптераар эхний лабораторийн уншилтыг гаргаж, Go backend-тэй version-тэй API эсвэл мессежийн гэрээгээр холбоно. Production хэлний сонголтыг бодит тоолуурын session хугацаа, санах ой, алдааны нөхөн сэргэлтээр шийднэ. Нийт платформын хэл Go байна гэдэг шалтгаанаар DLMS протоколыг шинээр бичих шаардлагагүй. Go дээрх Gurux gxdlms-go бий ч 2026-10-02-ны байдлаар албан release-гүй, цөөн commit-тэй тул бодит тоолуур дээр Python эсвэл C хувилбартай ижил тестээр харьцуулсны дараа HES-ийн цөм болгох эсэхийг шийднэ. Gurux-ийн Go сан мөн GPL-2.0 ба арилжааны давхар лицензтэй.

Адаптерийн гаралт нь meter ID, source ID, profile/OBIS, эх timestamp, UTC timestamp, нэгж, scaler, raw value, тайлбарласан утга, чанарын төлөв, receipt ID-тай байна. Холболтын нууцыг payload-д оруулахгүй. Төхөөрөмж бүрийн session-ийг давхар эзэмшихээс хамгаалж, timeout, retry, jitter, backfill дарааллыг PowerGrid хэрэгжүүлнэ.

PoC-ийн гарах баримт: хоёр өөр загвар дээр 24 цагийн профиль уншсан үр дүн; төхөөрөмжийн дэлгэцтэй тулгалт; зориудын тасалдлын дараах нөхөн таталт; timezone болон scaler-ийн жишиг; firmware тус бүрийн нийцлийн хүснэгт. Simulator дээр амжилттай болсон нь бодит төхөөрөмжийн баталгаа болохгүй.

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

#4.2 OpenMUC ба MQTT-ийн байр суурь

OpenMUC нь Java/OSGi framework бөгөөд Modbus, IEC 61850, IEC 60870-5-104, IEC 62056-21 зэрэг драйвер, MQTT/AMQP холболтын боломжийг жагсаасан. Энэ жагсаалтаас бүх загварын DLMS тоолуурыг автоматаар дэмжинэ гэж дүгнэхгүй. OpenMUC

PowerGrid-д трансформаторын хэмжүүр, үйлдвэрлэлийн төхөөрөмж, хуучин локал уншилтын gateway шаардлагатай бол туршина. Edge дээр түр хадгалалт, timestamp, sequence, replay-г тодорхой болгоно. Java/OSGi ашиглалтын мэдлэг, шинэчлэлт, тусдаа лицензийн зардлыг тооцно.

Mosquitto нь MQTT broker болон клиент хэрэгслүүдтэй. Төслийн тайлбар, лиценз. MQTT нь бүх тоолуурын төрөлх протокол гэж үзэхгүй. Gateway MQTT руу хөрвүүлж болох ч DB-д давхаргүй хадгалах, төхөөрөмж дээр команд үнэхээр биелсэн эсэхийг broker дангаараа батлахгүй. Нэг сая шууд холболтын HA шаардлагыг лабораторийн нэг broker-оос шууд дүгнэхгүй.

#055. Өгөгдлийн платформ ба queue сонголт

#5.1 PostgreSQL ба ClickHouse

PostgreSQL-ийн partitioning нь том хүснэгтийг хуваах, хугацаагаар өгөгдөл удирдах, тодорхой query-г оновчлох боломжтой. Энэ нь автоматаар олон серверт хуваарилах баталгаа биш. Partitioning баримт

PowerGrid-ийн customer, service point, meter mounting history, tariff version, command, payment ledger-ийг PostgreSQL-д authoritative байдлаар хадгална. Хэмжилтийн эхний туршилтад partition, batch insert, зөв индекс, өдөр/сарын aggregate ашиглана. Нэг сая тоолуурын жилийн бүх интервалын online query-г нэг PostgreSQL node даана гэж урьдчилан батлахгүй.

ClickHouse нь баганан аналитик сан. Repository. PowerGrid-д бүс, трансформатор, хоног, тарифын бүлгийн тайланг хурдасгах нэр дэвшигч. Төлбөрийн transaction ledger-ийг орлуулахгүй. Шинэчилсэн хэмжилт аналитик руу очихдоо measurement_id, revision, quality, source watermark-аа хадгалж, аль хувилбар хүчинтэйг query бүр зөв хэрэглэх ёстой. Хоёр сангийн хоцролт, нийлбэрийн зөрүүг reconciliation job шалгана.

TimescaleDB-ийн эх нь Apache болон Timescale License хэсгүүдтэй. Тиймээс “PostgreSQL extension учраас бүх боломж нь Apache” гэж тооцохгүй. Лицензийн зааг. Шаардлагатай feature-үүдийг сонгосон build дээр нь үнэлж байж PostgreSQL-only болон ClickHouse хувилбартай харьцуулна.

#5.2 NATS JetStream эсвэл Kafka

Core NATS нь хадгалалтгүй, тухайн үед холбогдсон subscriber-д хүргэдэг бол JetStream нь хадгалалт, replay, acknowledgment бүхий урсгал нэмдэг. JetStream. PowerGrid-д хэмжилтийг Core NATS дангаар дамжуулж, хүлээн авагч тасарсан үед алдах загвар сонгохгүй.

Kafka нь тархсан event streaming платформ. Apache Kafka. Сонголтыг “нэг сая” гэсэн тоогоор дангаар шийдэхгүй; retention, replay, consumer-уудын тоо, peak throughput, багийн ашиглалтын чадвараар харьцуулна.

Санал: эхний PoC-д JetStream-ийг авч, Kafka-тай ижил нөхцөлөөр харьцуулсны дараа үндсэн нэг queue сонгоно. Хоёуланг нь зэрэг production-д нэвтрүүлэх нэмэлт үйл ажиллагааны ачааллыг эхний шатанд авахгүй.

DB commit амжилттай боловч ack алдагдах тохиолдолд мессеж давтан ирнэ. Иймээс idempotency_key, transactional outbox/inbox, retry-ийн хязгаар, алдаатай мессежийн тусдаа дараалал, дахин ажиллуулах эрх хэрэгтэй. “Exactly once” нэртэй боломж нь тоолуур → queue → DB → billing бүх замын зөв байдлыг дангаар батлахгүй.

#066. Нэвтрэлт, нууц, ашиглалтын бүрэлдэхүүн

Keycloak нь identity болон authentication суурь. Repository. PowerGrid нь token-оос гадна байгууллага, бүс, service point-ийн эрхийг backend, export, background job бүрд шалгана. Нэвтрэх эрхтэй хүн бүр таслах эрхтэй болохгүй; командын зөвшөөрлийг тусдаа permission болгоно.

Эрхийн давхарга. Keycloak нь «хэн бэ» гэдгийг, PowerGrid-ийн authz давхарга нь «юуг харах, хийх вэ» гэдгийг шийднэ. Эхний шатанд PostgreSQL дахь өөрийн authz схем, RLS, scope cell-ээр эхэлж, эрхийн матрицыг pgTAP-аар тестэлнэ. ClickHouse, экспорт, API gateway зэрэг олон систем нэг эрхийг хуваалцах үед OpenFGA эсвэл SpiceDB-г PDP болгон харьцуулна. Хэрэглэгчийн зөвшөөрлийн бүртгэлийг ЕХ-ны 2023/1162-ийн Permission administrator үүргийн дагуу тусдаа модуль болгоно. Дэлгэрэнгүйг олон улсын судалгааны 17 дугаар бүлгээс үзнэ.

OpenBao нь secret, certificate, key удирдах зориулалттай. Repository. Тоолуурын нууцыг UI, Git, telemetry log-д хадгалахгүй; зөвхөн эрхтэй адаптер шаардлагатай үед авдаг болгоно. HSM шаардлагатай эсэх, түлхүүрийн эх олголт, эргэлт, сэргээх, төхөөрөмжийн counter-той нийцэх ажиллагааг тусдаа шалгана. Secret manager суулгаснаар DLMS key rotation автоматаар шийдэгдэхгүй.

Prometheus ба Grafana нь ажиллагааны metrics болон харагдацын хэрэгсэл. Prometheus, Grafana. PowerGrid-д read success, D+1 completeness, queue lag, backfill age, command UNKNOWN, DB write latency, backup age-г хянана. Тоолуур бүрийн serial-ийг Prometheus label болгон сая сая series үүсгэхийн оронд бүс, адаптер, загвараар aggregate гаргаж, төхөөрөмжийн дэлгэрэнгүйг MDM сангаас харуулна. Хэрэглэгчийн billing portal-ийг Grafana dashboard-аар орлуулахгүй.

pgBackRest нь PostgreSQL backup/restore хэрэгсэл, албан repository-д 2026-09-27-ны release бүртгэгдсэн. Repository. Backup файл бий гэдэг нь сэргээнэ гэсэн нотолгоо биш. Тусгаар орчинд хугацааны цэг рүү сэргээж, хэмжилт, төлбөрийн нийлбэр, command audit-ыг тулгана. Replication-ийг backup-тай адилтгахгүй. PostgreSQL-ийн synchronous/asynchronous replication сонголт нь өгөгдөл алдах эрсдэл ба latency-д өөр нөлөөтэй. Replication баримт

#077. GIS, сүлжээний тооцоо ба жишиг төслүүд

PostGIS нь байршил, газарзүйн query хийх PostgreSQL өргөтгөл. Repository. PowerGrid-д transformer, feeder, meter-ийн координат болон хүчинтэй хугацаатай холбоосыг хадгалах саналтай. Газрын зураг дээр ойр байгаа хоёр цэг цахилгаанаар холбогдсон гэсэн үг биш; topology-г инженерийн бүртгэлээр батална.

pandapower нь цахилгаан сүлжээ загварчлах, тооцоолох зориулалттай Python төсөл, BSD-3-Clause лицензтэй. Төсөл, лиценз. PowerGrid-д шугамын параметр, трансформатор, ачаалал, фаз, topology бүрдсэний дараа техникийн алдагдал болон ачааллын хувилбар судлахад хэрэглэнэ. Зөвхөн тоолуурын хэрэглээ байхад бодит сүлжээний бүх алдагдлыг найдвартай тооцно гэж үзэхгүй. Эхний үеийн MDM, billing-д зайлшгүй dependency болгохгүй.

GXF буюу өмнөх OSGP-ийн repository нь retired, идэвхтэй хөгжүүлэлт ба арчилгаа зогссон гэж ил тод тэмдэглэсэн. GXF README. Protocol adapter, integration test, domain boundary-ийн зохион байгуулалтыг судлахад ашигтай. Харин шинэ PowerGrid-ийн production суурь болговол хуучин dependency, security patch, fork-ийн бүх хариуцлагыг өөрсдөө хүлээнэ. LF Energy-ийн landscape-ийг дараагийн судалгааны индекс болгон ашиглаж болно; жагсаалтад байна гэдэг нь тухайн төсөл идэвхтэй, үйлдвэрлэлд бэлэн гэсэн баталгаа биш.

#088. PowerGrid өөрөө бүтээх шаардлагатай хэсэг

Өмнөх судалгаанд шалгасан teami-gerege-uz commit 4ac3dfb15829264722d2b2fc78fa8361deb58cac дээр уншилтын task нь simulated өгөгдөл үүсгэдэг, relay handler нь DB төлөв шинэчилдэг, TEAMI архивын нэг удаагийн таталт нь production scheduler-тай адил биш байсан. Энэ нь тухайн snapshot-ийн үнэлгээ; одоогийн HEAD-ийн шинэ аудит биш. Readings, Load control, TEAMI pull

Иймээс эхний ажлын үр дүн нь шинэ dashboard биш, эх төхөөрөмжөөс ирсэн заалтыг тайлбарлаж, хадгалж, дахин гаргаж үзүүлэх баталгаатай урсгал байна.

#099. Нэг сая тоолуурын архитектурын санал

flowchart TD
  M[Тоолуур ба концентратор] --> A[Протоколын адаптерууд]
  A --> Q[Хадгалалттай ingestion queue]
  Q --> R[Эх өгөгдлийн архив]
  Q --> V[VEE ба canonical хэмжилт]
  V --> P[PostgreSQL бүртгэл ба гүйлгээ]
  V --> C[ClickHouse аналитик шаардлагаар]
  P --> B[Тариф ба төлбөрийн тулгалт]
  P --> U[PowerGrid API ба React UI]
  C --> U
  U --> W[Командын хүсэлт ба зөвшөөрөл]
  W --> D[Тусдаа command worker]
  D --> A
  A --> E[Хариу ба бодит төлөвийн баталгаажуулалт]
  E --> P

Keycloak нь хэрэглэгчийн identity, OpenBao нь нууцын хандалтаар эдгээр үйлчилгээг дэмжинэ. Raw архивын хадгалах технологи, retention-ийг тусдаа сонгоно. Queue-г олон жилийн архив гэж үзэхгүй. Бүсчилсэн adapter pool нь холбооны доголдлын нөлөөг хязгаарлаж, нэг төхөөрөмжид зэрэг хоёр worker команд өгөхөөс хамгаалах ownership-той байна.

#9.1 Тооцооны суурь

Эдгээр нь DB хэмжилтийн бичлэгийн тоо; MQTT connection, packet, API request-ийн тоо биш. Нэг message-д олон channel багцалж болно. Нэг сая байнгын socket шаардлагатай эсэх нь концентратор болон push/poll загвараас хамаарна.

100–250 byte/хэмжилт гэсэн шалгах таамаглалаар нэг сувгийн жилийн raw хэмжээ 3.50–8.76 TB; дөрвөн сувагт 14.02–35.04 TB. Индекс, replica, backup, event, revision ороогүй. Эдгээрт нийт 3 дахин багтаамж төлөвлөх жишгээр 10.5–26.3 TB ба 42.0–105.1 TB болно. Бодит schema, compression, retention-аар хэмжиж шинэчилнэ.

24 цагийн тасалдлаар дөрвөн сувагт 384 сая backlog үүснэ. Үүнийг 6 цагт нөхөх зорилт тавибал 17,777.8 нэмэлт бичлэг/секунд, хэвийн урсгалтай нийлээд дунджаар 22,222.2 бичлэг/секунд шаардана. Энэ нь DB талын тооцоо; төхөөрөмжийн холбоо 6 цагт бүх архивыг өгөх боломжийг батлаагүй.

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

1. Ижил өгөгдөл, replication, durability, диск, retention-ээр queue болон DB хувилбаруудыг харьцуулах.
2. Peak, долоо хоногийн backfill, billing query, backup-ийг зэрэг ажиллуулах.
3. Worker restart, broker node loss, DB failover үед алдагдсан болон давхардсан хэмжилтийг тоолох.
4. 1 сая ID-тай synthetic ачааллыг бодит төхөөрөмжийн нийцлийн туршилтаас тусад нь тайлагнах.
5. p95/p99 latency, queue age, write lag, query хугацаа, сэргээх хугацааг хэмжих.
6. Queue-гийн амжилтыг billing болон төхөөрөмжийн командын бодит амжилттай андуурахгүй байх.

#1010. Төслийн мэдлэгийн зураглал

Дараах нь багийн сургалт, дотоод баримтжуулалтын санал. Зөвхөн ном уншсан эсэхээр бус, дахин ашиглах баримт ба туршилтын үр дүнгээр мэдлэгийг үнэлнэ.

#10.1 DLMS сургалтын эх сурвалж

Gurux DLMS in a nutshell нь communication, addressing, authentication, frame-ийн анхан ойлголт өгнө. COSEM objects нь Clock, Register, Profile Generic, Disconnect Control зэрэг объектын баримтыг холбоно. Эдгээр нь төхөөрөмж үйлдвэрлэгчийн companion specification-ийг орлуулахгүй. PowerGrid нь тухайн загварын client/server address, authentication, security suite, object list, profile capture objects, access rights-ийг нийлүүлэгчээс авна.

Лабораторийн дасгал: эхлээд association ба зөвхөн унших эрх; дараа нь register болон interval profile; дараа нь clock/scaler; сүүлд тасалдал, timeout, authentication failure. Relay командын дасгалыг тусгаар лабораторид эрх бүхий инженерээр гүйцэтгэнэ.

#10.2 Өгөгдөл ба төлбөрийн мэдлэг

meter_id, service_point_id, customer_id, contract_id-г ялгана. Тоолуур солигдоход service point хадгалагдах ба хоёр тоолуурын mounting interval давхцах эсэхийг шалгана. Raw утга, canonical утга, засварласан revision-ийг эх үүсвэрээр нь мөрдөнө.

Golden dataset-д тариф солигдох өдөр, сарын зааг, хоцорсон заалт, rollover/reset, тоолуур солилт, буруу scaler, давхар callback, буцаалт, хэсэгчилсэн төлбөр, negative/reverse energy орно. Санхүүгийн баг тайлбарласан жишээ бүрийн expected үр дүнг батална. AI-ийн гаргасан тайлбар нь батлагдсан тарифын дүрэм болохгүй.

#10.3 Ашиглалт ба кибер хамгаалалтын мэдлэг

NISTIR 7628 Rev.1 нь smart-grid кибер хамгаалалтын түүхэн суурь удирдамж. Монголын одоогийн хууль, байгууллагын дүрмийн оронд хэрэглэхгүй. PowerGrid-ийн threat model-д meter key алдагдах, хуурамч command, tenant хооронд мэдээлэл задрах, replay, supply-chain өөрчлөлт, backup устах тохиолдлыг оруулна.

On-call баг “тоолуур offline”, “холбооны сүлжээ доголдсон”, “queue хоцорсон”, “DB удааширсан”, “billing зөрсөн”-ийг тусдаа ялгадаг байна. Incident бүрт хэрэглэгчийн нөлөөлөл, тухайн бүс, эхэлсэн цаг, сэргэлтийн нотолгоо, дахин давтагдахаас сэргийлэх өөрчлөлт бүртгэнэ.

#1111. Дотоод мэдлэгийн сангийн санал

Git репозиторид дараах Markdown бүтэцтэй, review-тэй баримтуудыг хадгалах саналтай. Энд зөвхөн бүтцийг тодорхойлсон; бүтээгдэхүүний репозиторид хавтас үүсгээгүй.

1knowledge/2  glossary.md3  architecture.md4  decisions/               # ADR: сонголт, хувилбар, нотолгоо5  devices/                 # үйлдвэрлэгч, загвар, firmware, profile6  data-contracts/          # хэмжилт, event, command schema7  vee/                     # дүрэм, version, баталсан хүн8  billing/                 # тариф ба golden test cases9  operations/              # runbook, backup, DR, on-call10  security/                # threat model, role matrix, authz ба RLS бодлого11  privacy/                 # зөвшөөрлийн урсгал, k-босго, DPIA12  dependencies/            # version, LICENSE, SBOM, upgrade13  evidence/                # нууцгүй test report, benchmark

Баримт бүр эзэн, хүчинтэй огноо, хувилбар, эх сурвалж, хянагч, холбогдох тестийн ID-тай байна. Нууц түлхүүр, хэрэглэгчийн бүтэн мэдээлэл, бодит production packet-ийг засваргүйгээр Git-д оруулахгүй. Тестийн өгөгдлийг анонимчилж, simulator-ийн гаралтайг тэмдэглэнэ.

Мэдлэгийн AI хайлт нэмж болно. Эхний хэрэглээ нь батлагдсан зааврыг эх сурвалжтай олох, алдааны код тайлбарлах байна. Production command гүйцэтгэх, тариф солих, өрөөр таслах шийдвэрийг энэ хайлтын агентын эрхэд оруулахгүй. AI платформын сонголт нь үндсэн хэмжилтийн замыг ажиллуулах урьдчилсан нөхцөл биш.

#1212. Судалгаа ба PoC-ийн ажлын дараалал

Доорх 6 долоо хоног нь лабораторийн төхөөрөмж, эрх, инженерүүд бэлэн үеийн ажлын санал. Улсын нэг сая тоолуурын нэвтрүүлэлтийн хугацаа биш.

Billing-ийн баталгаа нь хоёр бүтэн тооцооны мөчлөгийг зэрэгцүүлж шалгах зэрэг нэмэлт хугацаа шаардана. Зургаан долоо хоногийн PoC-г production acceptance гэж нэрлэхгүй.

#1313. Сонголтын эцсийн босго

Нэр дэвшигч бүрт дараах баримт бүрдсэнээр шийдвэр гаргана: сонгосон release/commit; LICENSE ба dependency бүртгэл; install/upgrade/rollback заавар; security issue авах суваг; төхөөрөмж эсвэл ачааллын нотолгоо; backup/restore боломж; өгөгдлөө гаргаж авах арга; ашиглалтын эзэн; таван жилийн өртгийн оролтууд.

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

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

#1414. Үндэсний өөрийн системийн функционал боловсруулах зарчим

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

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

#Жишээ FN-08 Алсын командын нарийвчилсан урсгал

Хэрэглэгч: тухайн байгууллага, бүсэд төхөөрөмж удирдах эрхтэй оператор. Оролт: meter ID, хүссэн төлөв, шалтгаан, хүсэлтийн ID, хүчинтэй хугацаа. Урьдчилсан нөхцөл: төхөөрөмж команд дэмждэг, суурилуулалтын холбоос хүчинтэй, зохих зөвшөөрөл бүрдсэн байна.

1. PowerGrid хүсэлтийн эрх, төхөөрөмжийн чадамж, хамгаалалтын дүрэм, зэрэгцээ команд байгаа эсэхийг шалгана.
2. Шаардлагатай зөвшөөрлийг тусдаа үйлдлээр бүртгэж, зөвшөөрсөн хүн ба тухайн үеийн өгөгдлийн хувилбарыг хадгална.
3. Worker илгээхийн өмнө хүсэлтийн хугацаа, эрх ба хамгаалалтын нөхцөлийг дахин шалгана.
4. Төхөөрөмжид илгээсэн болон хариу хүлээн авсан үйл явдлыг тус тус бүртгэнэ.
5. ACK ирсэн ч бодит төлөвийг шалгаагүй бол VERIFIED болгохгүй. Read-back эсвэл дэмжигдсэн төлөвийн нотолгоогоор батална.
6. Timeout болсон бол үр дүн тодорхойгүйг UNKNOWN гэж харуулж, төлөв шалгах ажил үүсгэнэ. Хүсэлтийг сохроор давтан гүйцэтгэхгүй.
7. Оператор timeline-аас хэн, хэзээ, ямар шалтгаанаар, ямар үр дүнтэй ажилласныг харна.

Хүлээн авах шалгуур: DB update дангаараа амжилт болохгүй; давхар хүсэлт давхар команд үүсгэхгүй; хугацаа дууссан команд дараа нь гүйцэтгэгдэхгүй; өөр бүсийн оператор удирдахгүй; төхөөрөмжийн төлөв зөрвөл амжилт гэж харагдахгүй. Энэ урсгалыг өөрсдийн API, UI, өгөгдлийн загвар, тестээр хэрэгжүүлнэ.

#Дараагийн баримт бичгийн зорилго

Дараагийн функционал тодорхойлолтод FN-01–FN-15 бүрийн дэлгэц, хэрэглэгчийн үйлдэл, бизнесийн дүрэм, төлөвийн шилжилт, өгөгдлийн талбар, интеграц, сөрөг тохиолдол, хүлээн авах шалгуурыг дэлгэрүүлнэ. Үндэсний шинэ системийн бүтээгдэхүүний шаардлага нь тухайн нээлттэй эхийн төслийн UI эсвэл дотоод өгөгдлийн загвараар хязгаарлагдахгүй.