Пошук
Пошук
Сторінки
Записи
  • UA
  • EN
  • EN
  • Організація обміну даними

    Система управління ринком електроенергії передбачає потоки вхідних та вихідних даних.

    Вхідні дані можуть бути одержані Системою трьома основними способами:

    До вхідних даних Системи відносяться наступні:

    Тип даних Доступна форма передачі в Систему Кому доступні
    Двосторонні торгові графіки

    WEB-інтерфейс

    GUI

    Учасники ринку
    Дані комерційного обліку

    WEB-інтерфейс

    GUI

    Учасники ринку
    Планові графіки виробництва

    WEB-інтерфейс

    GUI

    Учасники ринку із роллю Виробник (Producer)
    Пропозиції GUI Учасники ринку, акредитовані на відповідних аукціонах
    Результати ринку на добу наперед

    WEB-інтерфейс

     

    Оператор ринку

    Система управління ринком здатна також породжувати вихідні дані для зовнішніх систем та користувачів. Здебільшого вихідні дані призначені для інших систем НЕК «Укренерго», але є і такі, що можуть бути використані учасниками ринку.

    До таких вихідних даних відносяться:

    Тип даних Доступна форма передачі в Систему Кому доступні
    Інформація щодо компаній, зареєстрованих у Системі WEB-інтерфейс  Оператор ринку

    Наразі триває робота з розширення переліку даних, що можуть бути одержані із Системи, зокрема, для цілей організації моніторингу операцій окремих контрагентів та аналітики.

    Формати і приклади обміну даними

    Формати обміну даними базуються на стандартах ENTSO-E. Для зручності учасників ринку електроенергії опис форматів обміну даними із Системою управління ринком електроенергії згруповані у два файли відповідно до базової ролі на ринку.

    Сюди опис інтерфейсів зі старої сторінки?

    Документи містять:

    • опис форматів файлів та їх параметрів із прикладами заповнення відповідних параметрів
    • приклади файлів у форматі xml.

    Важливо! Описи форматів файлів наведені англійською мовою задля збереження точної відповідності оригіналу документу, розробленого в ході впровадження Системи управління ринком. Наразі триває робота з належного перекладу документів українською мовою.

    • Опис форматів та приклади обміну даними із Системою для учасника ринку.
    • Опис форматів та приклади обміну даними із Системою для виробника електроенергії (пропозиції на аукціони).
    • Опис форматів та приклади обміну даними із Системою для оператора системи розподілу.
    • Опис форматів та приклади обміну даними із Системою для Оператора ринку.

    Ці чотири файли – це англомовні описи?

    Перелік правил верифікації даних та кодів помилок

    Будь-які дані, що надходять до Системи управління ринком, перевіряються з точки зору формальної логіки та бізнес-сутності відповідних об’єктів.  Результати такої перевірки відображаються у повідомленні (acknowledgement) про прийняття відповідного файлу. Результат обробки даних Системою управління ринком маркується кодом та текстовим значенням відповідного результату. Перелік можливих результатів наведений у файлі.

    Важливо! Опис можливих результатів перевірок наведені англійською мовою задля збереження точної відповідності оригіналу документу, розробленого в ході впровадження Системи управління ринком. Наразі триває робота з належного перекладу документу українською мовою.

    Це Business Rules and Validation (MMS 2.0)?


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

    Для вирішення труднощів, з якими стикаються учасники ринку, наводимо перелік помилок системи з їх деталізацією.

    Коди помилок та їх тлумачення

    Конвертер файлів

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

    Але у надзвичайних випадках за відсутності доступу до відповідних  систем може виникнути потреба у формуванні відповідних файлів вручну.

    Задля допомоги учасникам ринку розроблено конвертор з формату Excel у формат XML. Цей конвертор може стати у нагоді у тому числі компаніям та фахівцям, що знаходяться на етапі вивчення механізмів функціонування Системи управління ринком та ринку в цілому.

    Конвертор доступний за посиланням  https://twox.pid.sh

    Для конвертації торгового графіку має бути ввімкнутий параметр «internal-schedule-document-5_1».

    Для конвертації графіку фізичного відпуску має бути ввімкнутий параметр  «PRS-document-6_0».

    Тестовий приклад формування .xlsx файлу графіку фізичного відпуску: Графік фізичного відпуску

    Тестові приклади формування xlsx та xml файлів торгових графіків у відповідності до наступних прикладів:

    Приклад: В форматі xlsx.

    Учасник, ринку який подає графік за двосторонніми договорами ZAKHIDENERGO 23X-UKR-ZAKHID-4

    Продавець ZAKHIDENERGO 23X-UKR-ZAKHID-4

    Покупець KHARKIVENERGOZBUT 62X0567145339922

    Дата продажу (дата передачі обсягів) 15.04.2019 року

    Обсяг продажу в годину 50.0

    Приклад 2:

    В форматі xlsx.

    Учасник, ринку який подає графік за двосторонніми договорами ZAKHIDENERGO 23X-UKR-ZAKHID-4

    Продавець ZAKHIDENERGO 23X-UKR-ZAKHID-4

    Покупець 1 KHARKIVENERGOZBUT 62X0567145339922

    Покупець 2 TOV E ENGINEERING 62X791105280272J

    Дата продажу (дата передачі обсягів) 16.04.2019 року

    Обсяг продажу Покупець 1 на годину 50.0

    Обсяг продажу Покупець 2 в годину 65.0

    Щодо заповнення xlsx файлу коригуванню підлягають поля відмічені жирним шрифтом.

    Постачальники допоміжних послуг (ДП) повинні надавати ОСП графік фізичного відпуску для кожної одиниці відпуску (наявної в учасника ринку) з обов’язковим зазначенням мінімального навантаження (технічний мінімум), що може нести одиниця надання ДП тривалий час, максимального навантаження (встановлена потужність), що може нести одиниця надання ДП тривалий час, та даних щодо резервів з розбиттям на резерви на завантаження та розвантаження, відповідно до алгоритмів моніторингу надання ДП, наведених в Додатку 6 до Правил ринку.

    Учасники ринку повинні постійно коригувати дані заявки протягом торгового дня, на години, що залишилися, виходячи з тієї ситуації, яка складається в енергосистемі.

    Щодо технічного користувача системи

    Загальні відомості

    Market Management System (MMS, Система) здатна приймати від учасників ринку електричної енергії дані, передбачені стандартом IEC TS 62325-504 «Framework for energy market communications», а саме:

    • Двосторонні торговельні графіки (ESS TPS[1]),
    • Графіки виробництва (ERRP APS),
    • Дані комерційного обліку (EAMD).

    Зазначені документи можуть бути надані до Системи двома шляхами:

    • Безпосередньо з інтерфейсу Системи з використанням функції Завантажити (Upload);
    • Без входу в інтерфейс Системи з використанням API (Application Programming Interface).

    Можливість завантаження відповідних документів користувачем безпосередньо в інтерфейсі Системи достатньою мірою описана у відповідній інструкції користувача і далі у цьому роз’ясненні розглядатись не буде.

    Завантаження даних з використанням API використовується у випадку необхідності налаштування взаємодії за принципом «система – система» автоматично, без участі або з мінімальною участю користувача.

    Для організації такої взаємодії потрібний:

    • Належним чином зареєстрований технічний користувач;
    • Мають бути належним чином виконані налаштування системи, що передаватиме дані.

     


     

    Щодо реєстрації та прав технічного користувача

    Процедура реєстрації технічного користувача є тотожною процедурі реєстрації звичайного користувача Системи і здійснюється на підставі належним чином оформленої заяви, що подається юридичною особою – учасником ринку електроенергії (Заява щодо додаткових відомостей). Відкритий сертифікат кваліфікованого електронного підпису  можна надіслати електронною поштою на адресу офісу реєстрації regoffice@ua.energy.

    Для реєстрації технічного користувача Системи мають бути надані:

    • Унікальна адреса електронної пошти;
    • Сертифікат кваліфікованого електронного підпису, який використовується для авторизації та аутентифікації користувача.

    Технічний користувач Системи може ініціювати передачу до неї усіх видів документів, згаданих у розділі Загальні відомості цього роз’яснення.

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

    Слід звернути увагу на те, що користувачі, належним чином зареєстровані у Системі:

    із роллю Balance Group Manager, мають доступ до усіх відповідних даних Системи незалежно від того, в який спосіб ці дані були завантажені до Системи – через інтерфейс користувача чи за допомогою API.

    із роллю Data Responsible (використовується для ППКО), мають доступ до відповідних даних Системи незалежно від того, в який спосіб ці дані були завантажені до Системи – через інтерфейс користувача чи за допомогою API.

    Учасник ринку на власний розсуд може використовувати для реєстрації технічного користувача кваліфікований цифровий підпис типу печатка (тобто не персоніфікований) або персоніфікований кваліфікований цифровий підпис.

    Кваліфікований цифровий підпис має бути виданий відповідно стандартів з використанням алгоритму шифрування RSA.

    Із переліком надавачів, які проводять діяльність у сфері надання кваліфікованих електронних довірчих послуг, можна ознайомитись за посилкою Центральний засвідчувальний орган | Довірчий список (czo.gov.ua).

    Важливо! Сертифікат відкритого ключа та відповідний приватний ключ,  які видані за  стандартом алгоритму електронного підпису, визначеному ДСТУ 4145-2002,  не використовуються для реєстрації технічного користувача.

    Публічна частина кваліфікованого цифрового підпису повинна відповідати стандарту X.509.

     


     

    Щодо налаштування системи – джерела даних для використання API

    Відповідно до вимог інформаційної безпеки, та у відповідності до міжнародних рекомендацій система MMS.UA.ENERGY у свої роботі використовує протокол безпеки транспортного рівня (Transport Layer Security, TLS) версії 1.2. Будьте уважні: підтримка протоколів TLS1.1 та TLS1.0 Системою не здійснюється.

    Каналом передачі даних є мережа Internet з використанням протоколу шифрування SSL.

    Веб-сервіс імплементує державний стандарт «ДСТУ IEC TS 62325-504:2017 Інфраструктура комунікацій на енергетичному ринку. Частина 504. Використання веб-сервісів для взаємо обміну електронними даними на Європейському ринку електроенергії (IEC TS 62325-504:2015, IDT)».

    Адреса веб-сервісу https://mms.ua.energy/soap/entsoe-documents/services/request (Порт стандартний 443).

    Для забезпечення можливості інтеграції іншого  програмного забезпечення із Системи, в тому числі із використанням протоколів прикладного програмного інтерфейсу (API), необхідно забезпечити підтримку протоколів та алгоритмів транспортного рівня як наведено нижче:

    Cipher suite (hex value) Bits Protocols Key exchange Authentication Cipher MAC
    ECDHE-RSA-AES128-GCM-SHA256 (0xc02f) 128 TLS1.2 ECDHE RSA AES-GCM SHA256
    ECDHE-RSA-AES128-SHA256 (0xc027) 128 TLS1.2 ECDHE RSA AES SHA256
    ECDHE-RSA-AES256-GCM-SHA384 (0xc030) 256 TLS1.2 ECDHE RSA AES-GCM SHA384
    ECDHE-RSA-AES256-SHA384 (0xc028) 256 TLS1.2 ECDHE RSA AES SHA384
    ECDHE-RSA-CHACHA20-POLY1305-SHA256 (0xcca8) 256 TLS1.2 ECDHE RSA CHACHA20-POLY1305 SHA256

    Потрібно звернути увагу на офіційні міжнародні рекомендації щодо використання протоколу TLS1.2 та відмову від використання протоколів TLS1.1 та TLS1.0 Вони визначені документом The Internet Engineering Task Force (IETF) no longer recommends the use of older TLS versions, який містить деталізовані технічні обґрунтування.

     


     

    Деякі пояснення щодо алгоритму взаємодії між системою – джерелом даних та Системою MMS

    Наступні коментарі щодо алгоритму взаємодії систем можуть бути корисні при налаштуванні, тестуванні та експлуатації API.

    1. Протягом 1-2 хвилин після надіслання документу може бути здійснений запит переліку підтверджень з відповідним періодом часу (From: час надіслання документу, To: фактичний час);
    2. Потрібно перевірити всі підтвердження, повернені цим запитом. Кожен документ ідентифікується унікальним кодом. Слід просто зберігати у системі-джерелі вже оброблені документи, щоб уникнути можливої повторної обробки підтверджень.
    3. Після виявлення нових підтверджень потрібно обробити кожне з них в окремій функції GET. Зазвичай це не повинно бути проблемою продуктивності, оскільки кожен документ адресовано саме конкретній системі-джерелу, і тому кожен новий документ потрібно перевірити. Ця функція перевірки повинна мати можливість обробляти підтвердження, що належать певному учаснику ринку. Це визначається параметром mrID – унікальним кодом, який наводиться у кожному документі;
    4. В одному підтвердженні міститься один унікальний mrId в тезі “mRID “. Отже, система-джерело може зв’язати підтвердження з оригінальним документом за допомогою цього mrId. Ось приклад підтвердження:

        ACK_null_22646

        2019-10-17T11:33:43Z

        10X1001C–00001X

        A04

        62X287776153688Q

        A01

        62X287776153688Q-20191022-2c3f947f

        1

       

            A01

       

    (Оригінальний mrId у цьому прикладі: 62X287776153688Q-20191022-2c3f947f).

    5. Якщо підтвердження для відповідного mrId не знайдено, слід повторити спробу. Якщо відповідь не була отримана протягом 15 хвилин, сталася спеціальна помилка обробки (наприклад, через недійсний XML формат) і MMS не змогла створити правильне підтвердження цієї помилки.


     

    Концепція комунікації

    Наступні коментарі щодо концепції комунікації систем можуть бути корисні при налаштуванні, тестуванні та експлуатації API.

    1. Підтвердження від MMS є доступними через LIST/GET:

    – для документів, одержаних від учасників ринку через веб-сервіс утворюється підтвердження, доступне через LIST/GET команди;

    – для документів, завантажених через інтерфейс користувача, підтвердження через LIST/GET команди недоступне.

    2. Підтвердження від MMS через команду PUT:

    Наразі стандартним є метод взаємодії LIST/GET. Якщо з технічних причин певний учасник ринку потребує зміни цих команд на PUT, така заміна може бути здійснена за запитом і потребуватиме певного часу. Загалом використання PUT не рекомендується.

    3. Підтвердження від системи учасника ринку через команду PUT:

    Повідомлення можна надсилати MMS за допомогою команди PUT. Ці підтвердження зберігатимуться у MMS.

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

    Результат валідації документу системою MMS доставляється в асинхронному повідомленні. Його можна та доцільно завантажувати з сервера документів та зберігати у системі – джерелі даних.


     

    Щодо тестування обміну даними через API

    Зазвичай налаштування та випробування взаємодії з боку учасника ринку потребує певних зусиль та часу, тому доцільно використовувати для цього тестове середовище системи MMS. Для одержання максимально швидкої та адекватної технічної підтримки на період налаштувань та випробувань про їх початок потрібно повідомити НЕК «Укренерго» із зазначенням контактної особи з технічних питань з боку учасника ринку.

    Звертаємо Вашу увагу на те, що для старту тестування обміну даними через API необхідно пройти процедуру реєстрації технічного користувача, дана процедура на тестовому середовищі тотожна процедурі реєстрації технічного користувача на продуктивному та виконується на підставі належним чином оформленої заяви, що подається юридичною особою – учасником ринку електроенергії (Заява щодо додаткових відомостей), та сертифікату кваліфікованого електронного підпису. Відкритий сертифікат кваліфікованого електронного підпису  необхідно надіслати електронною поштою на адресу офісу реєстрації regoffice@ua.energy .

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


     

    Щодо проведення тестування завантаження даних в Систему – тестовий сценарій

    Для проведення тестування завантаження даних необхідно виконати дії згідно тестового сценарію робочого процесу завантажити тестовий  SOAP та внести до нього відповідні дані.

    • Підготувати коректний файл з даними для завантаження  в Систему. Приклад структури файлу можна подивитись у відповідному розділі сайту. Для перевірки  завантаження даних до Системи потрібно відправити файл-запит. При цьому Система отримає, обробить та поверне повідомлення-відповідь, що містять інформацію про прийняття або відхилення даних.
    • Підготувати помилковий файл  з даними для завантаження  в Систему. Мета цієї дії – отримати якомога більше повідомлень с кодами помилок. Адміністратор на боці платформи ММS  зможе передивитись помилкові повідомлення у комунікаційних логах та надати кваліфіковану консультацію з приводу налаштувань на боці учасників ринку.
    Учасникам ринку