Питання та відповіді

DTU — це інтеграційна платформа для енергосистеми України, побудована як три рівноправні самостійні продукти: A1 (фізична безпека мережі), A2 (моніторинг ринкових маніпуляцій) і A3 (прогноз втрат та закупівель). Така архітектура означає, що кожен продукт вважатися окремим рішенням, з власним ТЗ, контрактом і бюджетом — замовник може купити один, два або всі три без залежностей. Це дає гнучкість: не обов'язково інвестувати в усе, а потім масштабувати за потребою.

Так, повністю. Кожен продукт — це замкнене рішення зі своєю функціональністю. A1 без A2 і A3 буде виявляти ризики в мережі, аналізувати режими й видавати рейтинг критичних об'єктів. Два інші продукти — це не умова роботи, а опціональні доповнення. Навіть якщо ви маєте всі три, кожен продовжить штатно функціонувати, якщо один із них вийде з ладу.

Шина (Event Bus) — це комунікаційний шар, що з'єднує продукти A1, A2 та A3 і дозволяє їм обмінюватися подіями. Наприклад, коли A1 виявляє аномальний переток, він публікує цю подію, A2 проаналізує ринковий контекст, а A3 реактивно перерахує прогноз втрат. Шина необов'язкова — активується лише якщо замовник має ≥2 продукти й бажає їх синхронізувати. Якщо у вас тільки один продукт — шина не активується й не потрібна.

Платформа розробляється із гарантією **повної передачі без залежності від розробника**. На Етапі-1 (MVP) — несекретна синтетична демонстрація; на Етапі-2 — реальні дані під NDA в захищеному КСЗІ-контурі замовника. У будь-якому випадку вся интелектуальна власність, код і методологія переходять до вас повністю — без подальших вимог до розробника і без облачної залежності.

Етап-1 — це MVP-доказ концепції на достовірній синтетиці та публічних даних ENTSO-E. Це показує метод і логіку, але не заявляється як точне передбачення на ваших даних. Етап-2 (за 2-3 місяця) включає: підключення реальних контурів, калібрування на ваших даних, атестацію у складі КСЗІ, отримання допусків до державної таємниці. Тобто на Етапі-1 ви бачите «як воно працює»; на Етапі-2 буде «як воно працює з вашими даними».

Етап-1 використовує три джерела: (1) публічні дані ENTSO-E Transparency Platform про перетоки в европейській мережі, (2) синтетичні данні топології, побудовані на реальних якорях (напр., пік навантаження України ~18 ГВт зимою — перевірено), (3) синтетичні сценарії ударів за статистикою реальних атак 2022-2025. Кожна синтетична цифра виводиться з верифікованого факту, а не беруться з потолку.

Під кожну синтетичну цифру лежить 'реальний якір' — перевірений факт. Наприклад, потері магістралі рахуються як % від реальної передачі енергії (~113 ТВт⋅ч/рік, CIGRE 2017), а не як випадкові числа. Система перевіряє правила: (1) порядок величин збігається з якорем, (2) знаки й напрями фізично коректні, (3) зв'язки між величинами відповідають законам (потері ∝ I²R), (4) сезонність/суточність реальна. Експерт-енергетик, бачачи результат, має зрозуміти: 'так, це схоже на правду'.

Кожна відповідь API чи звіт містить поле `data_origin`, що явно вказує джерело: SYNTHETIC (демо на синтетиці), OPEN_DATA (публічні ENTSO-E), NDA_CALIBRATED (калібровано на реальних даних Укренерго на Етапі-2). Це не прихований дисклеймер, а обов'язкова мітка, зрозуміла для кожного користувача — людина знає, про які дані вона дивиться й наскільки вони надійні.

Етап-2 розміщується в захищеному КСЗІ-контурі (у своєму серверу чи затвердженому приватному хмарному середовищі) з атестацією за нормативними документами технічного захисту інформації (НД ТЗІ). Шина подій має кріптозахист каналів, управління доступом на рівні RBAC (кожен користувач бачить тільки дозволене), повний аудит усіх операцій. Секретні дані не виходять за межи атестованого периметра. Замовник отримує повну контроль й розуміння архітектури безпеки.

A1 будує цифровий двійник ОЕС, що моделює режим мережі й виявляє вразливості. Він: (1) розраховує Risk Score — показник критичності кожного об'єкта (трансформатор, лінія, ПС), (2) проводить N-k contingency аналіз (що станеться, якщо впаде N об'єктів), (3) будує «Pareto-список» — топ-4 об'єктів, захист яких убезпечує систему від більшості сценаріїв, (4) прогнозує каскадні відмови (коли одна аварія спричиняє ланцюг інших), (5) повертає стан на час события (Replay) й аналізує гіпотетичні сценарії (What-if). За вихідні беруться: топологія 750/330 кВ, розрахункові режими, статистика ударів.

A2 моніторить поведінку учасників РДН (ринок на добу наперед) і ВДР (внутрішньодобовий). Він: (1) будує baseline — 'нормальну' поведінку кожного трейдера (цінові діапазони, обсяги, часи активності), (2) виявляє аномалії (наприклад, раптовий стрибок пропозиції на 500%, швидкі зміни заявок, синхронні ходи кількох гравців), (3) аналізує координовані дії (граф сговору — які учасники часто діють синхронно), (4) фільтрує хибні тривоги за допомогою контексту (ціновий стрибок при дефіциті — обґрунтований, при цьому ж дефіциті без фізичної причини — підозрілий). Результат — рейтинг ризику кожного учасника, рекомендації для НКРЕКП.

A3 прогнозує технологічні втрати в мережі й закупівельну потребу. Втрати розраховуються як функція від: (1) нагрузки в мережі (потері ∝ I²R, тобто зростають квадратично), (2) погоди (крона погодозалежна: 10-20 кВт/км в норму, до 84 кВт/км в дощ), (3) сезону/часу доби (зимовий пік → більше перетоків → більше втрат). На вихід: прогноз МВт⋅ч на період (день/тиждень/місяць) з точністю MAPE 5-8% (як у европейських операторів Fingrid, CatBoost). Закупівлі рахуються шаром — базова генерація, компенсація втрат, резерв, цінова оцінка. На Етапі-2 буде пряма integración з реальними перетоками й цінами закупок.

Так. Це інваріант 'щит ↔ меч': сигнал, що для одного продукту це діагностичний щит (захист від помилок), для іншого стає мечем (ранній сигнал для дії). Приклад: A1 виявляє аномальний переток у перерізі 750 кВ → публікує подію в шину. A2, отримавши цю подію, звіряє час із своєю ринковою аномалією: чи є там аномальна заявка? Якщо так, то фізична причина є (не сговір) → знижує тривогу. Якщо немає — підозра на маніпуляцію зростає. A3 бачить зміну режиму → миттєво перераховує втрати. Жоден продукт окремо цього не дає; разом вони мають набагато більше контексту й точності.

Розмежування вбудоване в маршрутизацію подій на рівні RBAC (role-based access control). Якщо подія має гриф «для A1 тільки», вона не доставляється підписнику на A2, навіть якщо той запросив. Якщо користувач має допуск до A1, але не до A2, він бачить факт, що 'є ринковий контекст до фізичної аномалії', але захищений вміст A2 для нього залишатиметься скритим. Не 'залікування' дозволом на екрані, а справжня ізоляція даних у кожній операції.

На Етапі-1 — всі дані несекретні (SYNTHETIC/OPEN_DATA). На Етапі-2 у защищеному контурі можуть виникнути дані з грифом 'цілком таємно'. Гриф-бар'єр — це правило: подія з вищим грифом НЕ потрапляє на нижчий (секретна подія не вийде за межи атестованого периметра). Не через дублювання систем, а через перевірку гриф-політики при кожній доставці. Якщо користувач з несекретного рівня запросить дані, система відповість, що інформація недоступна — без утечи деталей.

Система розрахована на три рівні: (1) **Диспетчер** — real-time дашборд, оперативні тривоги, WebSocket-потік подій, рекомендації щохвилини. Бачить то, що потрібно для поточного управління. (2) **Аналітик** — глибокі analityka, машина часу (Replay/What-if), граф сговорів, детальні звіти, історія. Може копатися в даних. (3) **Керівництво** — agregowani звіти, KPI, стратегічні рекомендації ('посилити ці 4 об'єкти'), trend. Кожен рівень має свій інтерфейс, свої дозволи, свою гранулярність даних.

Агентний контур (БОНУС усередині кожного продукту) — це автоматичний фільтр, що працює постійно: (1) прогонює мільйони сценаріїв (war-gaming, Monte Carlo), (2) автоматично фільтрує шум / очевидні неважливі події, (3) видає людині вже відібране — топ-N ризиків. Людина залишається у контурі: вона перевіряє рекомендацію агента, приймає остаточне рішення. Це не 'автономна система', а 'агент як помічник' — масштабування думки експерта через мільйони розрахунків. Безпека: кожне рішення агента логується, аудитується й підлягає повідомленню.

Інтерв'ю з експертами (диспетчери, інженери режимів, ринкові аналітики, фахівці з безпеки). Кожне питання типу: 'Як ви це робите зараз вручну?' → відповідь трансформується в критерій / формулу / поріг алгоритму. Приклад: A1 питає 'За яким критерієм об'єкт вважається відмовленим?' → відповідь 'напруга < 0.9 Uном' → це стає в модель. Також запит актуальних даних: топологія мережі, режимні зрізи, уставки РЗА, час відновлення обладнання, реальні інциденти для калібрування. Усе під NDA.

На MVP немає Pareto аналізу реальної сітки (є метод, прогон на синтетиці); на Етапі-2 — реальна топологія, реальні 4 об'єкти із 137. На MVP guerra-gaming гонить N≈1000 сценаріїв; на Етапі-2 — N=100k. На MVP детектори A2 — 4 флажка на синтетичному order book; на Етапі-2 — обучение на реальній історії з НКРЕКП. На MVP Risk Score методологічно коректна, але на синтетичних даних; на Етапі-2 — валідована на реальних інцидентах 2022-2025. Кожне з цих розширень вимагає доменної деталізації й реальних даних від НЕК.

Три типи тестів: (1) **Автономність** — при вимкненій шині кожен продукт A1/A2/A3 демонструє повну функціональність без залежностей. (2) **Наскрізний сценарій** — A1 виявляє аномалію → публікує в шину → A2 отримує й аналізує контекст → A3 реактивно перераховує → журнал кореляції відтворює весь ланцюг. (3) **Калібрування на фактах** — система перевіряється на реальних інцидентах 2022-2025 (що впало, як каскадувало, скільки МВт втрачено) й показує прийнятну точність. Без цього не буде акта приймання.

Повна передача без залежності означає: (1) **код** — весь вихідний код у вашому репозиторії, з документацією, тестами, ліцензією для модифікації; (2) **архітектура** — описано й пояснено з такою деталізацією, що ви (чи інші розробники) можете розвивати сами; (3) **дані** — актуальна топологія, режимні зрізи, параметри моделей у вашій БД; (4) **обучение** — командам НЕК проводиться навчання з адміністрування, розвитку, інтеграції; (5) **ліцензія** — вам надається права на використання й модифікацію. Розробник не має 'хатки' у вашій системі, розробник зникає — система працює далі.

Цифровий двійник — це точна математична модель магістральної мережі 750/330 кВ, яка дозволяє змоделювати мільйони сценаріїв роботи реальної мережі без ризику. Це не просто теорія: диспетчери вже розраховують режими вручну, але A1 робить це масово і виявляє вразливості, які людина не встигає бачити.

Традиційний N-1 перевіряє, що буде, якщо одна лінія впаде — це статичний чек. A1 робить масовий аналіз (мільйони сценаріїв з Monte-Carlo), шукає опасні комбінації (когда три фактори окремо безпечні, але разом — критичні), і працює 24/7 як система раннього попередження.

Трьом рівням одночасно. Оперативні диспетчери бачать карту ризиків прямо зараз, інженери режимів проганяють детальні сценарії для калібрування, керівництво отримує інтегральний індекс ризику з трендом і топ-список того, що зміцнювати першочергово.

Ні, A1 повністю автономний. Це окремий продукт з власним ядром, власними даними і власною моделлю. Інтеграція з A2 чи A3 — опціональна, через окрему «шину подій», і відсутність інших продуктів жодним чином не обмежує роботу A1.

На Етапі-1 (зараз) мережа і сценарії — синтетичні (згенеровані алгоритмічно на основі закритих даних ENTSO-E і фізичних законів). На Етапі-2 будуть реальні дані SCADA. Але функція и точність модели перевіряються на синтетиці, щоб не потребувати державної таємниці на MVP.

На MVP (Етап-1) — спрощена модель, яка достатня для виявлення критичних вузлів. На Етап-2 буде повний AC load flow з деталізацією рівнянь режимів, AC-розрахунками і калібруванням до реальної телеметрії. Конкретні формули — це доменна задача фази-2, в ТЗ прописано тільки «що» модель робить.

Monte-Carlo — це випадковий перебір мільйонів комбінацій умов (навантаження × погода × конфігурація × ремонти), щоб виявити, які комбінації небезпечні. War-Gaming — режим, де ми також змінюємо сценарії атак (кількість об'єктів, хвилі, напрямки), щоб запрогнозувати наслідки масованих ударів.

Залежить від обчислювальної потужності і деталізації моделі. На MVP цільова швидкість — щоб базовий сценарний простір (典型 режими × погодні умови × контингенсу) перебирався за години, а не дні. На Етап-2 буде шкала часів на основі реальних тестів.

Тому що критичні комбінації часто нетипові. Наприклад, опалювальний сезон + ожеледь на силових лініях + раптовий спад вітру на видобутку = мережа входить в небезпечний режим, хоча кожен фактор окремо був у межах норми. Лише масовий перебір виявляє такі комбінації.

N-1 означає: якщо одна лінія/трансформатор впаде, мережа не колапсує. N-k — те ж саме для комбінацій k елементів. На Етапі-1 виконується повний N-1 перебір. Для N-2/N-3 (воєнні сценарії масованих ударів) — глибина буде визначена на основі реальних даних Укренерго на Етап-2.

Система перевіряє кілька критеріїв: перевищення межі допустимого струму, падіння напруги нижче 0.9 від номіналу, спрацювання релейного захисту за певною уставкою. Конкретні пороги — це доменне знання, яке запитано у фахівців Укренерго на Етап-2.

Вузькі місця — це об'єкти (лінії, трансформатори), відмова яких найчастіше призводить до каскадів і збоїв інших елементів. A1 аналізує мільйони результатів і ранжує об'єкти за тим, скільки разів їхня відмова була критична. Це топ-список того, який елемент захищати першочергово.

Так, це критично. Після відмови елемента система не просто «рубить» його — вона також симулює спрацювання автоматики (АЧР відключа навантаження, САВН регулює напругу, система ділиться на острови). Без цього симулятор перебільшить або менший наслідки.

Ніяк не просто. Risk Score = Критичність (скільки навантаження залежить від об'єкта) × Вразливість (близькість до фронту, попередні влучання) × (1/Відновлюваність) × поправка на резервування. Це багатовимірна оцінка, яка побудована на формалізованих експертних факторах НЕК.

Це класична задача оптимізації: знайти мінімальний набір об'єктів (наприклад, 20 з 140), захист яких дасть максимальне зниження системного ризику (наприклад, 80%). Замість розпилювати бюджет на всі 140, керівництво отримує впорядкований список ТОП-20 з обґрунтуванням і кошторисом впливу.

Так. A1 має режим інтерактивного перерахунку: ви вибираєте об'єкт, система робить умовний перерахунок (виключає його з вразливих елементів) і показує, на скільки % знизиться системний ризик. Це запускається за секунди на базовому контурі.

Це робить агентний контур A1 (24/7 бонус): агенти шукають по масиву результатів аномалії, критичні комбінації, сценарії з найвищим впливом на ризик. Вони фільтрують мусор і ранжують по перспективності. Людина отримує коротке резюме, готове до перевірки експертом, а не 5 мільйонів рядків.

Система моделює послідовність подій по графу мережі: після відмови лінії її навантаження перерозподіляється на сусідів, сусіди перевантажуються, спрацьовує їх захист, вони вимикаються, навантаження «плавить» далі. Це послідовність, яка повинна відтворювати реальну ПА і історичні каскади з архіву Укренерго.

Так, є екран історичних інцидентів. A1 зберігає реєстр реальних подій, зіставляє їх з модельними сценаріями та робить ретроспективний тест: чи виявила б модель цей інцидент як небезпечний сценарій раніше. Це калібрування двійника на фактах.

Система моніторить поточні умови (навантаження, погода, конфігурація мережі, прогноз) та порівнює їх з виявленими критичними комбінаціями. Якщо дійсні умови наближаються до опасної комбінації, A1 видає сигнал із горизонтом (за 1-2 доби): «небезпечний режим близько, порадимо включити резерв на об'єкті X».

Так, але з явною позначкою зниженої достовірності. Якщо метеорологічні дані недоступні, система гарантує, що не видасть «впевнене» попередження на неповних даних — замість цього показує: «Сценарій ймовірний, але довіра середня через відсутність прогнозу погоди».

На Етап-1 (MVP) користуються синтетичною топологією на основі відкритих даних ENTSO-E, яка архітектурно еквівалентна реальній, але не чутлива. На Етап-2 буде реальна топологія SCADA, але лише в захищеному (ізольованому) контурі КСЗІ для уповноважених користувачів. MVP є, відповідно, грифу ДСК (для службового користування) без таємниці.

ДСК (для службового користування) — це відсекретна версія, придатна для демонстрацій і аналізу закономірностей. КСЗІ (комплексна система захисту інформації) — це атестований контур для роботи з державною таємницею, з повним криптозахистом, аудитом і дотриманням режимних вимог. MVP запускається на ДСК, Етап-2 — виключно в КСЗІ.

Модель RBAC (Role-Based Access Control) в A1 — окремий від A2/A3. Диспетчер бачить карту ризиків свого регіону, інженер режимів — всю мережу з деталями, керівник — агрегований зріз без чутливих даних. Кожен запит і експорт проходять через перевірку прав (RLS/CLS) і логуються в незмінний аудит.

Це мовний інтерфейс на українській: ви пишете природномовне запитання («покази всі попередження рівня високий за останній місяць по корональному фактору»), агент перетворює його на SQL, виконує запит у межах ваших прав доступу, повертає таблицю чи графік і пояснює результат. Всі запити логуються для аудиту.

На Етап-1 — головне завдання аналізу, результати залишаються в A1. На Етап-2 можлива опціональна інтеграція з A2 (маніпуляції) і A3 (втрати) через окрему «шину подій» (BUS), але це адаптер, а не умова роботи. Критичні експорти для керівництва журналюються і обмежуються грифом.

Етап-1 (MVP): карта ризиків, N-1 аналіз, базовий Monte-Carlo, Pareto-список, раннє попередження на SYNTHETIC + OPEN_DATA. Етап-2: реальна топологія, повний AC load flow із калібруванням, N-2/N-3 для war-gaming, КСЗІ з грифом «цілком таємно», промислове впровадження й навчання користувачів.

MVP готова при завершенні Етап-1 (дата за договором), її можна експлуатувати на синтетиці в несекретному середовищі (офіс, демонстрації). На Етап-2 система розгортається у КСЗІ на реальних даних — дата також за договором. Два етапи = два розроблення, два приймання, два бюджети.

На Етап-2 передбачена процедура калібрування і верифікації: експерти порівнюють результати двійника з реальною телеметрією, виявляють розбіжності, коригують параметри моделі. Це буде формалізовано в методиці Етап-2. Агенти 24/7 (бонус) автономно шукають розбіжності й пропонують поправки.

War-gaming сценарії (параметри ударів, тип боєприпасів, схеми атак) розроблюються на Етап-2 разом з доменними фахівцями Укренерго. На MVP є базовий режим Monte-Carlo; war-gaming як окремий режим уточнюється на основі експертизи і політичних рішень Замовника.

На MVP (Етап-1) Red Team режим в базовій формі — так: система перебирає комбінації відмов для симуляції масованих ударів. Але конкретні патерни реальних атак (дата/тип/ціль/наслідок) — це чутливі дані, які будуть на Етап-2 під NDA. На MVP використовуються синтетичні параметри для демонстрації технології.

A2 — це автоматизована система, що працює 24/7 і сама шукає ознаки маніпуляцій у мільйонах транзакцій. На відміну від ручного аналізу, система генерує мільйони гіпотез, відсіює шум й приносить аналітику найперспективніші сигнали. Ви не тонете в даних — машина робить це за вас.

Детектори A2 формують сигнали на розгляд (STR), а не юридичні докази маніпуляції. Кожен алерт — це причина для дослідження, яке повинен провести експерт нагляду. Система ніколи не виносить вердикт про правопорушення, тому що остаточне рішення приймає людина, а не алгоритм.

На Етапі-1 (MVP) система використовує синтетичний журнал заявок із вшитими маніпулятивними патернами для тестування детекторів, плюс відкриті дані ENTSO-E про ціни й обсяги. Усі дані позначені міткою data_origin: SYNTHETIC або OPEN_DATA. На Етапі-2 система перейде на реальні дані оператора ринку під NDA.

Так, A2 повністю автономна. Вона працює на власному журналі даних і не залежить від інших продуктів. Інтеграція з A1 або A3 через шину подій — це опціональний бонус, що може поліпшити якість фільтрації хибних тривог за рахунок фізичного контексту. Без неї система функціонує на 100%.

A2 вбудовує RBAC (рольове управління доступом) на рівні рядків і стовпців даних — не як зовнішній «екран», а як частину ядра. Аналітик видить тільки ті учасників, сегменти й періоди, до яких у нього є дозвіл. Всі запити логуються в незмінний аудит. На Етапі-2 система експлуатується у захищеному контурі КСЗІ під гарантіями державної таємниці.

A2 розпізнає п'ять основних класів: цінові маніпуляції (придержування потужності), маніпуляції заявками (масова подача й швидке відкликання, спуфінг), wash-угоди, координовані дії учасників (картелі) та транскордонні зсуви. На Етапі-2 список розширюється залежно від практики нагляду.

Система порівнює заявку з базовою лінією поведінки учасника за ціною, обсягом і часом. Якщо заявка значно відхиляється від норми учасника (наприклад, ціна на 20% вище його звичного діапазону або обсяг у 5 разів більше), система фіксує це як потенційну аномалію. Пороги налаштовуються доменними фахівцями й можуть змінюватися без перекомпіляції.

Базова лінія — це штучно навчений клон поведінки кожного учасника, на основі його історичних даних. Система враховує сезонність (зима/літо), день тижня, час доби й навіть реакцію учасника на цінові сигнали. Коли поведінка учасника законно змінилася (нові потужності, новий бізнес-профіль), базова лінія адаптується через певний період.

Для кожного сигналу система показує перелік ознак-тригерів із числовими значеннями, наприклад: «92% заявок відкликано за 4 хвилини», «обсяг заявок у 7 разів більший від медіани», «подача за 30 секунд до клірингу». Усі ознаки клікабельні — ви можете перейти до сирих даних і перевірити факти.

Так. Кожен детектор віддає не лише факт спрацювання, а й міру впевненості (наприклад, 87% або 92%). Це допомагає аналітику пріоритизувати розслідування — сигнали з високою впевненістю йдуть у чергу першими. Міра впевненості обчислюється на основі вибору кількох ознак, а не однієї.

A2 будує граф зв'язків учасників, де ребра означають синхронність їх стратегій. Якщо два учасники одночасно подають схожі заявки, використовують дзеркальні ціни або часто торгують на один лот, система це бачить. Система розраховує силу зв'язку (кореляцію) й виявляє кластери з підозрілою щільністю.

На Етапі-1 система працює з орієнтовним часовим вікном синхронності (кілька секунд до кількох хвилин), яке буде уточнено на Етапі-2 разом з фахівцями нагляду. Параметри налаштовуються інтерактивно — ви можете змінити вікно й одразу переглянути граф з новими кластерами.

На Етапі-1 порог встановлюється практично (наприклад, 5–10 «збігів» в означеному часовому вікні за період). На Етапі-2 цей поріг буде уточнено на реальних даних разом з доменними фахівцями. Зміна порога дозволяє вам керувати чутливістю детектора — від суворої (мало хибних тривог) до м'якої (більше покриття потенціальних змов).

На Етапі-2 — так, якщо у вас є довідники про афілійованість, спільних власників чи групові відносини. Система добавить ці дані як атрибути вузлів графа, щоб підняти довіру до виявлених кластерів. На Етапі-1 система працює лише з ринковою поведінкою, що все одно дозволяє виявляти синхронні дії.

Ціна може легально піднятися з дефіциту, аварії, зміни ціни газу чи значного зростання попиту. A2 на Етапі-1 контролює основні зовнішні сигнали (ENTSO-E дані про генерацію, навантаження). На Етапі-2, якщо буде активна шина між A1 і A2, система отримає фізичний контекст від A1 (аварія, ремонт, обмеження мережі), що дозволить автоматично відсіяти багато хибних тривог.

Великий учасник може легально різко змінити обсяг після нової контрактації; молодий учасник дебютує з нестандартною поведінкою; раптовий стрибок ціни викликаний справжнім дефіцитом, а не маніпуляцією. На Етапі-2 ви будете позначати ці кейси як «спростовано», й система буде навчатися на них, щоб знижувати false-positive rate.

Доменні фахівці задають пороги детекторів, ваги в рейтингу ризику й параметри фільтра перспективності. Ви можете пом'якшити систему (підняти порог чутливості), щоб зменшити шум, або посилити її, щоб не пропустити реальні патерни. Всі зміни журналюються й відтворювані.

Так. Це називається false positive (хибна тривога). На Етапі-1 система калібрується на синтетичних даних, поки точність невідома. На Етапі-2, на реальних даних, система буде переучуватися на основі верифікованих кейсів, щоб знижувати false-positive rate. Це одна з причин, чому детектор — сигнальний, а не доказовий: людина завжди перевіряє.

На Етапі-1 A2 самостійно підтягує доступні дані (ENTSO-E, публічні новини, дані про генерацію й навантаження). На Етапі-2 у вас додадуться внутрішні дані про статус об'єктів, ремонти й обмеження. Опціонально, через шину подій, частину цих подій може передавати A1. A2 не залежить від цих источників, але використовує їх, щоб посилити контекст.

Рейтинг — це зважена сума сигналів від усіх детекторів за певний період. Кожен сигнал додає до рейтингу відповідно до його типу й впевненості. Наприклад, потенційна координація з іншими учасниками может мати вищу вагу, ніж одинична дивна заявка. Ви бачите декомпозицію — які саме фактори сформували рейтинг.

Один сигнал — це отримана деталь на конкретний момент часу. Накопичений ризик — це репутація учасника протягом часу. Учасник зі змінною поведінкою (кілька аномалій на тиждень) матиме вищий рейтинг, ніж учасник з однією сумнівною заявкою. Система врахує й частоту, й серйозність кожного епізоду.

На Етапі-2 система може мати правило затухання (decay) — старі епізоди поступово втрачають вагу, якщо учасник показує чисту поведінку. Це дозволяє реабілітацію: учасник не буде «засуджений» на все життя за одне порушення 6 місяців назад. На Етапі-1 детальна політика затухання буде узгоджена з фахівцями.

Система подає рейтинг як числовий бал із декомпозицією. На Етапі-2 фахівці вирішуватимуть, скільки порогів вводити (наприклад, 5 зон від зеленої до червоної) для пріоритизації роботи нагляду. На Етапі-1 система показує неперервний бал й ранжує учасників від найнижчого до найвищого ризику.

Через інтерфейс A2, де ви бачите чергу алертів із фільтрацією й сортуванням. Клікаєте на алерт → відкривається картка з деталями, ознаками-тригерами й посиланнями на сирі дані. Ви можете призначити алерт на розгляд, позначити його як спростований або як підтверджену маніпуляцію. Усе логується.

Через агента-бібліотекаря (NL→SQL). Ви пишете питання природною українською — «скільки учасників подали аномальні заявки в РСВ за останній день?» — система перетворює його на SQL, виконує запит і повертає таблицю або графік. Запит проходить через RBAC (ви бачите лише дозволені дані) і логується.

Так. Є екран «Профіль учасника», де ви бачите його базову лінію поведінки, часові ряди активності й порівняння з нормою сегмента. Там же — історія всіх його алертів і累積ний рейтинг ризику. На Етапі-1 учасники анонімізовані; на Етапі-2 — персоніфіковані під RBAC.

Є екран «Звіти і повідомлення» з конструктором шаблонів. Ви вибираєте період, сегмент, учасника чи клас патерну — система генерує звіт із усіма ознаками, дисклеймером сигнальності й посиланнями на дані. Можна налаштувати автоматичні звіти за розкладом чи тригер при критичному алерті. Формат й строки — узгоджуються на Етапі-2 з регламентом НКРЕКП.

Так, але із обмеженнями за RBAC і двостороннім принципом «щита». Чутливі зрізи (персоніфіковані ринкові дані) експортуються лише з окремих прав, й кожен експорт логується. На Етапі-1 експорт обмежений синтетичними даними; на Етапі-2 буде чітка політика за вимогами держтаємниці й комерційної таємниці учасників.

На Етапі-2 система переходить на реальні мікроструктурні дані РСВ/ВСР (від оператора ринку), працює з персоніфікованими учасниками й працює у захищеному контурі КСЗІ. Детектори калібруються на реальних даних, задаються остаточні пороги й ваги рейтингу. Агентний шар 24/7 повністю активується. Система атестується за НД ТЗІ й отримує гриф «цілком таємно».

Доменні фахівці нагляду НКРЕКП й операторів ринку відповідають на специальне питання про практику (QUESTIONS_A2_market.md). Їх відповіді перетворюються на конкретні числові пороги, ваги й формули, які фіксуються в окремому доменному додатку під грифом. Цей процес — частина Етапу-2, не MVP.

Інтеграція через шину подій — це опціональна надбудова. На Етапі-1 A2 працює повністю автономно. На Етапі-2, якщо буде рішення про шину, A2 зможе отримувати від A1 фізичні контексти (аварії, обмеження) для фільтрації хибних тривог, а від A3 — прогнози про ринкові умови. Без цієї шини A2 функціонує на 100%.

Етап-2 передбачений терміном 12–24 місяці. Перші місяці — інтеграція реальних даних, калібрування детекторів, переучування моделей на живих кейсах. Система буде працювати в паралельному режимі (разом з ручним аналізом) доки не досягне прийнятної якості. Реальні метрики якості (покриття патернів, false-positive rate) встановляються контрактно.

A3 прогнозує технологічні втрати у магістральній мережі 750/330 кВ на горизонті 1–7 діб і перетворює цей прогноз на потребу в закупівлі електроенергії для компенсації. Система допомагає оцінити ризики різних сценаріїв закупівлі (РСВ/ВСР/балансуючий ринок) та контролює якість прогнозу через аналіз відхилень. Це самостійний продукт, який працює без залежності від інших рішень НЕК.

Ні, A3 працює повністю самостійно. Інтеграція з іншими рішеннями (фізичний клон мережі, система нагляду РСВ/ВСР) є опціональною й реалізується через окремий інтеграційний шар. Без цієї інтеграції A3 використовує відкриті дані ENTSO-E та синтетику, що забезпечує повноцінну роботу системи.

Основний горизонт — 1–7 діб із щоденною дискретністю, цільова дискретність — погодинна. Система дає не лише точкові прогнози, а й розподіли (P10/P50/P90) для розрахунку ризику, щоб аналітик міг приймати рішення в умовах невизначеності.

A3 розкладає прогноз на три фізичні драйвери: навантажувальні втрати (I²R в активному опорі), втрати холостого ходу трансформаторів та корона на повітряних лініях. Система окремо показує, скільки втрат додає поточна/прогнозована погода. Агент-пояснювач генерує текстові пояснення українською («зростання на 12% через мокрий сніг на ВЛ-750»).

I²R — це втрати в активному опорі ліній і обмоток трансформаторів. Вони залежать від квадрата струму (навантаження²), що робить прогноз нелінійно чутливим до помилок у прогнозі перетоків. Ось чому для точного прогнозу втрат критично важливо мати якісні дані про навантаження й перетоки в мережі.

Питомі втрати на корону на ВЛ-750 можуть сягати до 84 кВт/км і різко зростають за дощу, мокрого снігу, паморозі та високої вологості. A3 розраховує корону через прогноз погоди — якщо немає даних про опади й вологість, прогноз втрат переходить у режим зниженої достовірності з явним маркуванням у інтерфейсі.

Обов'язково: прогноз перетоків/навантаження (ENTSO-E Transparency Platform) та метеопрогноз (≥2 джерела для надійності). Опціонально: вузловий режим (AC load-flow) від системи фізичного моделювання для підвищення точності I²R. Без будь-якого обов'язкового входу система переходить у деградований режим з маркуванням, але продовжує працювати.

Кожен прогноз маркується режимом достовірності (повні входи / деградований) і походженням даних (`SYNTHETIC` / `OPEN_DATA` / `NDA_CALIBRATED`). Якщо наприклад немає метеопрогнозу для корони, система показує це явно на екрані й обчислює прогноз за наявних даних із маркуванням знижена надійність.

Потреба в закупівлі = прогнозовані втрати + параметри, що редагуються аналітиком (резерв, профіль, уже законтрактовані обсяги). Система враховує невизначеність прогнозу втрат, щоб аналітик міг розуміти ризик кожної стратегії закупівлі. Потребу можна експортувати у табличному вигляді з обліком режиму доступу (RBAC).

Сценарії — це варіанти розподілу закупівлі між РСВ, ВСР та балансуючим ринком. Для кожного сценарію система оцінює ризик небалансу та потенційні штрафи на основі розподілу похибки прогнозу (а не лише точкової оцінки). Аналітик бачить порівняльну таблицю: вартість, ризик, чутливість до похибки, й може в реальному часі перерахувати ризик при зміні параметрів.

На Етапі-1 (MVP) система використовує відкриті та синтетичні ціни без модельованих механізмів клірингу. На Етапі-2 буде додано моделювання реальних цін РСВ/ВСР/БР з повною симуляцією ринку, але базова функція системи (прогноз втрат і сценарне планування) працює й без цього.

На екрані «Сценарії закупівель» показується чутливість до похибки: якщо ви прогнозуєте 100 МВт·год втрат, але у вас точність ±10%, то дефіцит може бути 10 МВт·год. Система показує, як цей дефіцит впливає на штрафи в кожному сценарії, щоб ви могли вибрати стратегію, яка краще переносить помилки прогнозу.

На екрані «Аналіз відхилень» показуються MAPE (середня абсолютна відсоткова похибка) та пов'язані метрики (MAE, bias) окремо для кожного горизонту (1д…7д), рівня напруги (750/330 кВ) і драйвера (I²R/корона/трансформатори). Система вловлює систематичний зсув і атрибутує великі відхилення (наприклад «метеопрогноз помилився на +3°»), щоб замкнути цикл навчання.

Це агент, який розуміє природну українську мову й перетворює ваші запити на SQL-запити до даних. Ви можете запитати: «покажи всі дні з MAPE > 8% за корональним драйвером» чи «порівняй втрати вихідних і робочих днів у липні», а агент виконає запит й покаже таблицю/графік. Усі запити проходять через RBAC на рівні рядків і стовпців.

Екран «Прогноз втрат» показує лише факт vs прогноз у часі. Екран «Драйвери» пояснює, з чого складається прогноз: розклад на I²R / холостий хід / корону, видимий вплив погоди й числові внески кожного драйвера. Якщо прогноз зростає на 20%, ви миттєво бачите, що 12% — це корона через прогнозований сніг, а 8% — зростання навантаження.

Система дає табличний експорт з будь-якого екрана з урахуванням вашої ролі й доступу (RBAC обмежує, які рівні напруги й період ви можете експортувати). Експорт маркується походженням даних (SYNTHETIC / OPEN_DATA / NDA_CALIBRATED) — це важливо для адекватної комунікації з керівництвом. Усі експорти логуються в неперервний журнал для безпеки.

RBAC в A3 — це не просто окремий екран доступу, а частина самої схеми даних. Кожен запис даних і кожен результат прогнозу помічаються рівнем напруги, регіоном, періодом. Користувач на екрані бачить й може експортувати лише те, на що має право — обмеження діють на рівні рядків і стовпців. Окремий допуск до A3 не надає й не потребує доступу до інших систем НЕК.

`SYNTHETIC` — дані штучно згенеровані для рідкісних режимів. `OPEN_DATA` — дані з відкритих джерел (ENTSO-E, météo.gov). `NDA_CALIBRATED` — реальні дані НЕК під таємницею (тільки на Етапі-2 у захищеному контурі). Кожна точка на графіку помічена цим маркуванням, щоб ви розуміли, наскільки надійним є результат.

На Етапі-2 A3 отримує реальні телеметричні дані SCADA/АСКОЕ, реальну топологію мережі й комерційні метеоджерела під NDA. Система перейде до фізично-узгоджених моделей (PINN) замість статистичної регресії; буде точніше прогнозувати I²R через вузловий режим (AC load-flow). Все буде оброблятися у захищеному контурі з КСЗІ й допущено до розповсюджування як «цілком таємно».

Так, це обов'язковий режим роботи для самостійності A3. Ви можете вручну ввести по полях що впало, втрату потужності, регіони без живлення. Система перераховує баланс і закупівельну потребу за нові умови. На Етапі-2 цей контекст може надходити автоматично від системи A1 через опціональну інтеграційну шину (бонус-зв'язок).

Так, без точного вузлового режиму (AC load-flow) від A1 система буде спиратись на агреговані перетоки ENTSO-E для розрахунку I²R. Це знижує точність на кілька відсотків, але система про це скажу — вона явно маркує режим деградованої достовірності. Для Етапу-1 це нормально; на Етапі-2 зв'язок з A1 (якщо буде) позначиться на якості.

A3 не є симулятором оптового ринку з механіками клірингу й ціноутворення. Вона не прогнозує споживання (це вхід), не розраховує генерацію (це вхід), не дає рекомендацій щодо ремонту обладнання. A3 спеціалізується на одному — на прогнозі технологічних втрат та підтримці планування закупівлі на їх компенсацію.

Почніть з «Прогноз втрат»: там головний графік факт vs прогноз, видна точність на різних горизонтах, показана дискретність входів і маркування достовірності. Потім перейдіть на «Драйвери» — розберіться, чому саме такий прогноз. Потім оцініть закупівельну потребу на екрані «Прогноз закупівельної потреби» й виберіть найкращий сценарій на екрані «Сценарії закупівель».

На Етапі-1 система працює на синтетиці й відкритих даних, тож MAPE служить як baseline для подальшого порівняння. Точні цільові значення встановлюються у Програмі випробувань разом з Замовником під час Етапу-1. На Етапі-2 на реальних даних точність зростатиме за рахунок фізично-узгоджених моделей (PINN) й дійсних телеметрії.

Перейдіть на екран «Аналіз відхилень» й відфільтруйте за цим драйвером й часовим періодом. Агент-бібліотекар допоможе вам виявити систематичний зсув (наприклад метеопрогноз систематично помиляється на +2° за певного сезону). Потім ви можете скасувати навчання на нових даних або скорегувати модель, щоб замкнути цикл якості.

Це залежить від вашого оперативного циклу. Якщо ви плануєте закупівлю добу-в-добу в РСВ/ВСР, то перерахунок потрібен щодня. Якщо є поточні події (авантажі, відключення), система дозволяє вручну ввести контекст і миттєво перерахувати баланс (цільовий час — одиниці секунд на горизонт 7 діб). На Етапі-2 можна автоматизувати цю інформацію з A1.

Фільтри й критерії відбору інформації, які агент використовує, параметризовані й журналюються. Ви можете створювати вибірки й граф запитів, які часто використовуються (наприклад «покажи MAPE по рівнях напруги за останній місяць»). Це прискорює роботу й лишає слід у аудиті для цілей безпеки й контролю якості.