Архитектур

Эх сурвалж: олон улсын судалгаа v1.6 (цаашид «GS §N»), нээлттэй эх ба мэдлэг v1.2 («OS §N»), Nexus цөмийн docs/ARCHITECTURE.md, docs/MODULES.md, docs/DISTRIBUTION.md (backend/v1.35.0). Хэрэгжүүлэх дараалал: implementation-plan.mn.md.

#011. Зорилго ба хамрах хүрээ

PowerGrid бол Монгол Улсын 1,000,000 цахилгааны тоолуурыг (захиалагчийн төлөвлөлтийн таамаглал, албан статистик биш) хамрах зорилготой үндэсний хэмжилтийн өгөгдлийн платформ. Гол үнэ цэнэ нь бодит тоолуурын заалтаас тайлбарлаж болох төлбөр, баталгаатай команд хүртэлх урсгалын зөв байдал (OS §13).

Зорилтын эрэмбэ (GS §18.1):

1. Эн тэргүүний зорилт:
   • Эрчим хүчний урсгалыг дэд станцаас хэрэглэгч хүртэл бүрэн хянах.
   • Гар утсаар төлбөр төлөх.
2. Ойрын ирээдүйн зорилт: postpaid-аас prepaid руу шилжих.

«Удирдах» гэдэг нь тоолуурын түвшний удирдлагыг хэлнэ: реле болон ачааллын хязгаар. Сүлжээний сэлгэлтийг SCADA хариуцна.

Бүтээгдэхүүний зарчмууд (судалгаанаас):

1. Түүхий заалтыг дарж засахгүй — засвар бүр шинэ хувилбар (GS §3, §9).
2. DB-ийн төлөв өөрчлөгдсөн нь төхөөрөмж дээр биелсэн гэсэн үг биш (GS §10, FN-08).
3. Simulator/туршилтын өгөгдлийг quality төлөвөөр бус, эх үүсвэр ба орчноор тусгаарлана (GS §9).
4. Эрхийг засаг захиргаагаар бус, үүрэг + хэмжилтийн цэгтэй холбоо хамаарлаар олгоно (GS §17.4).
5. «Exactly once»-д найдахгүй; хүлээн авагч бүр idempotent (GS §14, OS §5.2).
6. Шинэ технологийг хэмжсэн нотолгоогоор нэмнэ; эхлээд PostgreSQL (GS §14).

#022. Системийн контекст

1                    ┌───────────── Хэрэглэгчид ─────────────┐2 Иргэн/ААН (eID)   Түгээх компани   ЭХЗХ   Аймаг/дүүрэг   Гуравдагч тал   Аудитор3      │                 │             │          │              │            │4      ▼                 ▼             ▼          ▼              ▼            ▼5 /api/v1/me/*      /api/v1/*  (Nexus workspace урсгал)      API + зөвшөөрөл6      └────────────────┴──────┬──────┴──────────┴──────────────┴────────────┘7                              ▼8               ┌───────── powergrid-api (Nexus host.Run) ─────────┐9               │  powergrid модуль(ууд) + Nexus цөм (auth, RBAC,  │10               │  workspace, audit, eID, каталог)                 │11               └───────┬───────────────────────────┬──────────────┘12                       │ PostgreSQL                │ outbox → JetStream13                       ▼                           ▼14               ┌──────────────┐         ┌──────────────────────┐15               │ PostgreSQL   │◀────────│ powergrid-worker     │  ingest, VEE,16               │ powergrid.*  │         │ (Go, тусдаа процесс) │  command, backfill17               └──────────────┘         └──────────┬───────────┘18                                                   │ версионтой мессежийн гэрээ19                                        ┌──────────▼───────────┐20                                        │ HES адаптер(ууд)     │  бүсчилсэн pool21                                        │ түгээх компанийн     │22                                        │ импорт/команд (үндсэн)│23                                        │ DLMS (цоорхойд)       │24                                        └──────────┬───────────┘25                                                   ▼26                          Түгээх компаниудын HES/MDM · SCADA (зөвхөн унших) · тоолуур (цоорхойд)

#033. Nexus дээр буулгах нь

PowerGrid нь Nexus-ийн Go dependency хэлбэрийн distribution (core.lock, backend/v1.35.0). Цөмийг засахгүй; шаардлагатай өөрчлөлтийг эхлээд цөмд оруулна (DISTRIBUTION §«Шинэ distribution» 10).

#3.1 Модулийн хуваалт

Эхэнд нэг модуль io.gerege.powergrid (Core) — registry, ingest, MDM/VEE, баланс, команд, эрх нэг schema-д, хоорондоо FK-тэй. Модуль хооронд FK тавих, migration-ий дараалал зохицуулах өртгийг суулгалтын хил шаардлагатай болох хүртэл авахгүй. Хоёр модулийг тусад нь салгана, учир нь хэрэглэгч, өгөгдлийн хил нь өөр:

Дотооддоо Core нь Go багцуудаар хуваагдана (registry, ingest, mdm, balance, billing, command, authz, incident). Тусдаа модуль болгох шалгуур: өөр байгууллага өөр цагт суулгах шаардлага гарах.

#3.2 Процессууд

UI хүсэлт төхөөрөмжтэй шууд харилцахгүй; бүх төхөөрөмжийн ажил queue-ээр (GS §8).

#044. Домэйн загвар (Core)

IEC CIM-тэй зураглах боломжтой нэршил (GS §17.3). ID-уудыг хэзээ ч нэгтгэхгүй (GS §3, §10).

1organisation (= workspace) ─┬─ grid_area ── topology_node (substation → feeder → transformer)2                            │                       │  хүчинтэй хугацаатай (normal topology)3                            ▼                       ▼4                      metering_point (CIM UsagePoint) — тогтвортой ID, тоолуур солигдсон ч хэвээр5                         │        │6     meter_mounting ─────┘        └──── supply_contract ── customer7     (meter ↔ point, valid_from/until; давхцахгүй — EXCLUDE constraint)8                │9              meter (CIM EndDevice) ── device_model ── capability_profile (firmware, OBIS, команд)

Lifecycle төлөв тоолуур бүрт тусдаа (GS §5): registered → installed → commissioned → communicating → billing_ready. KPI тус бүрээр.

#4.1 Заалт

GS §9-ийн заавал талбарууд:

• Интервал тогтмол биш (5/15/30/60 мин); 30 минутыг хуваасан утгыг 5 минутын бодит гэж тэмдэглэхгүй.
• meter_reading — сараар partition, (metering_point_id, channel, interval_start, version) unique.
• Одоогийн хувилбарыг is_current эсвэл тусдаа «current» view-ээр; түүх устахгүй.
• kWh индекс, интервалын kWh, агшин зуурын kW нь өөр хэмжигдэхүүн — UI-д холихгүй.

#4.2 Raw receipt

Адаптерын batch бүр raw_receipt (source ID, checksum, received_at, payload-ийн байршил)-д commit хийгдсэний дараа л эх системд ACK буцаана (GS §11). Payload нь эхэндээ PostgreSQL-д, хэмжээ нотлогдвол object storage руу (GS §14).

#055. Өгөгдлийн урсгал

#5.1 Заалтын урсгал

1тоолуур / TEAMI ─▶ HES адаптер ─▶ JetStream (readings.raw.<region>)2   ─▶ ingest consumer: idempotency_key = (source_system, source_record_id, checksum)3        ├─ raw_receipt INSERT (давхардвал no-op)4        └─ canonical meter_reading (quality=A, version=1)5   ─▶ VEE ─┬─ тэнцсэн → баталгаажсан архив → баланс, billing, портал6           └─ унасан  → quarantine (billing-д автоматаар орохгүй)7   ─▶ хожуу бодит заалт → шинэ version → нөлөөлсөн баланс/billing-ийн дахин тооцох жагсаалт

VEE шалгалтууд (GS §9): давхардал, интервалын давхцал/цоорхой, хүрээнээс гарсан утга, индекс буурсан, rollover, тоолуур солилт, цагийн зөрүү, нэгж/коэффициент өөрчлөлт. Экспорт дэмждэг төхөөрөмжийн сөрөг утга алдаа биш. Дүрэм нь capability_profile ба хэмжилтийн төрлөөс хамаарна; дүрэм бүр хувилбартай.

#5.2 Командын урсгал (FN-08)

1REQUESTED ─▶ APPROVED ─▶ QUEUED ─▶ SENT ─▶ ACKNOWLEDGED ─▶ VERIFIED2     │           │          │        │           │3     └───────────┴──────────┴────────┴───────────┴──▶ FAILED | UNKNOWN | EXPIRED | CANCELLED

• approved_by <> requested_by — CHECK constraint (хоёр түлхүүр, GS §17.7).
• Worker илгээхийн өмнө эрх, хугацаа, хамгаалагдсан хэрэглэгч, маргаантай нэхэмжлэлийг дахин шалгана.
• ACK ≠ VERIFIED; read-back-аар батална. Timeout → UNKNOWN + төлөв шалгах ажил; сохор retry хийхгүй.
• Төхөөрөмж бүрд нэг идэвхтэй команд (partial unique index); bulk командад тоо, хурд, бүсийн хязгаар.
• Командын эрх (command.request, command.approve) нь reading.read-ээс тусдаа.
• Туршилтын ба бодит командын түлхүүр, дараалал тусдаа.

#5.3 Төлбөр (FN-07)

• Тариф: хүчинтэй хугацаа, ангилал, шатлал, татвар, дугуйруулах дүрэм; хувилбартай.
• Нэхэмжлэх нь хэрэглэсэн хэмжилтийн ба тарифын хувилбарыг заана; мөнгө numeric/мөнгөний хамгийн жижиг нэгж.
• Ledger append-only: давтан callback → нэг бичилт (idempotency key), буцаалт эсрэг бичилтээр.
• Хаагдсан нэхэмжлэлийг чимээгүй өөрчлөхгүй — засварын баримт.
• Хуучин системтэй зөрүү шийдэгдэх хүртэл автомат таслалт идэвхгүй (GS §7).
• Гар утсаар төлөх (GS §18.3):
  • PowerGrid бол биллер. payment_provider адаптер нь invoice/QR үүсгэх, статус асуух, callback, буцаалт, settlement файлыг хариуцна.
  • Нээлттэй billing API (ADR-010): нэхэмжлэл бүх төлбөрийн апп, банк, QR үйлчилгээ, e-Mongolia руу нэг стандарт API-аар очно; иргэн дуртай аппаараа төлнө. PowerGrid App-ыг төлбөрийн суваг болгон онцлохгүй.
  • Callback-д дангаар итгэхгүй, үйлчилгээ үзүүлэгчээс статусыг асууж баталгаажуулна.
  • Өдөр бүр ledger ↔ settlement ↔ billing-ийг тулгана.
  • PowerGrid-ийн billing бэлэн болох хүртэл нэхэмжлэлийг одоогийн billing-ээс импортолж, төлбөрийг outbox-оор буцааж илгээнэ.
• Prepaid (GS §18.4):
  • Дансны горим нь POSTPAID | PREPAID.
  • Үлдэгдлийг ledger тооцож, өдрийн register snapshot-оор хасна.
  • Таслалт, залгалт нь §5.2-ын командын урсгал болон хамгаалалтын бодлогын хөдөлгүүрээр (таслахгүй цаг, хүйтний хориг, хамгаалагдсан хэрэглэгч) явна.
  • Emergency credit болон өрийн суутгалыг тохиргоогоор тогтооно.

#5.4 Баланс (FN-05)

зөрүү = оролт − гаралт − зөвшөөрөгдсөн тоолуургүй хэрэглээ; оролт тэг/баталгаагүй бол хувь тооцохгүй. Dashboard зөрүүтэй хамт бүрэн байдал, estimated хувь, хамрагдсан цэгийн тоо, topology хувилбарыг харуулна. Бүрэн бус бүлэг алдагдлын чансаанд орохгүй (GS §9).

#066. Технологийн сонголт

TimescaleDB-ийн continuous aggregate/columnstore/retention нь TSL — ашиглахын өмнө хуулийн шалгалт (GS §17.11). ThingsBoard 4.4+ (BUSL), GXF (retired) суурь болохгүй.

#077. Өгөгдөлд хандах эрх (FN-09)

#7.1 Хоёр давхаргын тусгаарлалт

Nexus-ийн dbguard холболт бүрийг gerege_nexus_tenant role, app.current_tenant, app.current_user-аар уядаг. Энэ нь «өөрийн байгууллагын мөр» гэсэн нэг хэмжээс. PowerGrid-д хэмжээс илүү: ЭХЗХ бүх grid area-г, гуравдагч тал зөвшөөрлөөр нэг цэгийг, инженер өөрийн топологийн бүсийг харна. Тиймээс powergrid хүснэгтүүдийн бодлого:

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

authz.allowed_cells нь app.current_tenant, app.current_user-аас (dbguard тавьсан) тухайн хэрэглэгчийн бүх grant-ыг нэгтгэнэ: эзэмшигч байгууллагын өөрийн cell-үүд нь OPERATIONAL grant, ЭХЗХ-ны хандалт REGULATORY grant, гуравдагч тал CUSTOMER_CONSENT grant. Ингэснээр байгууллага дамнасан хандалт тусгай policy шаардахгүй. (SELECT …) нь InitPlan болж transaction-д нэг удаа тооцогдох ёстой — EXPLAIN-аар батална (GS §17.5). Анхаар: зөвхөн cell-ээр шүүх нь METERING_POINT (гуравдагч тал нэг цэг) ба data_from/data_until (аудитор, эзэмшил шилжүүлэх) grant-ыг илэрхийлж чадахгүй. Cell + цэг + хугацааны authz.effective_scope EXISTS хувилбарыг GS §17.5-аас үз. Энэ policy-ийн эцсийн хэлбэр ADR-001-ийн сэдэв (§11).

#7.2 Grant

1access_grant2  grantee_org_id / grantee_user_id3  basis        REGULATORY | OPERATIONAL | CONTRACT | CUSTOMER_CONSENT | AUDIT4  role         DSO_OPERATOR | ENGINEER | REGULATOR_VIEWER | SECAUD | …5  action       reading.read | summary.read | pii.read | export | tariff.change6               | command.request | command.approve7  scope_kind   ALL | GRID_AREA | TOPOLOGY | GROUP | METERING_POINT8  scope_ids    ALL-аас бусад үед хоосон байж болохгүй (CHECK)9  data_from / data_until, valid_from / valid_until10  purpose, legal_ref, group_snapshot_version, status

Бодит эрх = байгууллагын grant-уудын нэгдэл ∩ үүргийн эрх ∩ хэрэглэгчийн хамрах хүрээний нэгдэл. Нэг grant доторх нөхцөл AND; grant хооронд cross-product үүсгэхгүй.

#7.3 Scope cell

(owner_org_id, grid_area_id, topology_node_id[навч]) хослол бүрт scope_cell_id. Заалт, команд, төлбөр бүр хэмжилтийн үеийн харьяаллаар cell-тэй хадгалагдана; команд одоогийн харьяаллаар шалгагдана (GS §17.6). Cell-ийн тоо ≈ трансформаторын тоо. Засаг захиргаа Core-д атрибут, эрхийн хэмжээс биш.

#7.4 Service role

Background job хэрэглэгчийн эрх өвлөхгүй. Аппын role-д BYPASSRLS болон хүснэгтийн эзэмшил өгөхгүй; хүснэгт FORCE ROW LEVEL SECURITY.

Итгэлийн хязгаар: аппын DB хэрэглэгч SET LOCAL app.*-ийг өөрөө тавьж чадна — RLS нь аппын алдаанаас хамгаална, эвдэрсэн аппаас бүрэн биш (GS §17.5). Үүнийг threat model-д ингэж бичнэ.

#7.5 Зөвшөөрөл (FN-13) ба аналитик (FN-15)

• 2023/1162-ийн 6 процедур = хүлээн авах тестийн сценари. Цуцлалт дараагийн хүсэлтээс хүчинтэй, бүх талд мэдэгдэл.
• «Download My Data» ба «Share My Data» тусдаа функц, эрх, аудит. Экспорт CIM/Green Button-тэй зураглах JSON/CSV.
• Баталгаажсан түүхэн өгөгдөл ба баталгаажаагүй шуурхай өгөгдөл өөр суваг, өөр шошго.
• Аналитик: k ≥ 10 (нутгийн захиргаа, нээлттэй, өдөр+), k ≥ 5 (DSO төлөвлөлт, 15–30 мин); k-ээс бага нүд «<k». Зөвхөн урьдчилан тодорхойлсон бүлэг нийтэлнэ (ялгавар халдлага). k нь санал — ЭХЗХ/хуулиар батална.
• ЭХЗХ, аудиторын дэлгэрэнгүй хандалт бүр: хэн, юу, хэзээ, ямар grant-аар.

#7.6 Бүлэглэл (FN-14)

Засаг захиргааны мод bitemporal; дурын бүлэг (CIM UsagePointGroup). Гишүүнчлэлийн snapshot хувилбар, огноотой; Core аль хувилбарыг хэрэглэснээ аудитад хадгална. Шинэ бүлэглэл Core-ийн schema, RLS-ийг өөрчлөхгүй.

#088. Аюулгүй байдал

Threat model (OS §10.3): meter key алдагдах, хуурамч команд, tenant хооронд задрал, replay, supply-chain өөрчлөлт, backup устах.

#099. Багтаамж

Түүхий хэмжээ 1 сая × 1 суваг: 3.5–8.8 TB/жил (100–250 B), нийт ×3. 24 цагийн тасалдлыг 6 цагт нөхөх нь 4 сувагт ~22,000 бичлэг/сек (OS §9.1). Эдгээр нь тооцоо — туршилтаар батлагдаагүй. Ачааллын заавал турших хувилбарууд: GS §14.

#1010. Ажиллагаа

• Хэмжүүр (Prometheus): read success, D+1 completeness, queue lag, backfill age, command UNKNOWN, DB write latency, backup age.
• On-call ялгах ангилал: тоолуур offline / холбоо / queue хоцрол / DB / billing зөрүү.
• Нэг фидерийн олон дохиолол → нэг incident; холбоо тасрах ≠ цахилгаан тасрах (GS §5).
• RPO/RTO санал: MDM RPO ≤ 15 мин, RTO ≤ 4 цаг; ledger RPO 0 зорилт.
• Deploy: deployment.mn.md (одоо нэг сервер, compose).

#1111. Шийдвэрийн бүртгэл (ADR)

docs/decisions/NNN-*.md-д бичнэ. Нээлттэй: