OCMF — це відкритий стандарт обміну вимірювальними даними, спеціально розроблений для заряджання електромобілів. Завдяки стандартизованій структурі, зашифрованим підписам і гнучкому адаптуванню він усуває три основні галузеві больові точки: відсутність прозорості в вимірюванні заряду, сприйнятливість до фальсифікації даних і несумісність протоколів. Це робить виставлення рахунків більш надійним, а галузеву співпрацю більш ефективною.
Що таке OCMF?
OCMF (Open Charge Metering Format) – це галузевий стандарт, розроблений Європейським альянсом заряджань та організацією SAFE-eV. Це як «спільна мова» для вимірювання даних у зарядній галузі, що визначає уніфіковані правила передачі даних про зарядку між зарядними станціями, системами управління та операторами. Це гарантує, що ключова інформація, як-от сума стягнення плати, час стягнення плати та вартість, є "зрозумілою, читабельною та захищеною-від несанкціонованого доступу".
Простіше кажучи, до OCMF різні бренди зарядних станцій використовували різні формати даних, наприклад, різні регіони розмовляли різними діалектами, що унеможливлювало пряме спілкування. Завдяки OCMF усі сумісні пристрої використовують уніфіковану «мову» для передачі даних, забезпечуючи можливість відстеження та перевірки даних від початку стягнення плати до завершення виставлення рахунку.
Ключові технологічні моменти OCMF
1. Стандартизована структура: руйнування «бази даних» OCMF має легкий дизайн без складних додаткових заголовків. Основні дані інкапсульовані у фіксованому форматі, що адаптується до типових сценаріїв послідовного зв’язку, таких як RS-485. Він включає такі ключові поля, як кількість заряджання (Вт·год), час заряджання, ідентифікатор пристрою та інформацію про тарифи, а також підтримує ітерацію та розширення версій – наприклад, версія V1.2.0 додала дані компенсації втрат кабелю, а версія V1.3.0 додала поле версії прошивки контролера заряджання, що забезпечує уніфікованість і гнучкість. Ця стандартизація дозволяє різним маркам зарядних станцій, платформ керування (CSMS) і платіжних систем взаємодіяти без додаткової адаптації, що значно знижує витрати на співпрацю в галузі.
2. Механізм шифрування та підпису: усунення "підробки даних" Це найважливіший механізм безпеки OCMF. Дані вимірювання, згенеровані зарядною купою, шифруються та підписуються перед передачею, а одержувач перевіряє цілісність даних за допомогою відкритого ключа. Це схоже на додавання «водяного знака безпеки» до даних; якщо його підроблено, процес перевірки негайно виявить його, запобігаючи проблемам із «завищеною ціною та неправильним виставленням рахунків» у джерела.
Цей механізм повністю відповідає міжнародним нормам метрології, таким як German Mess- & Eichrecht, що робить дані про стягнення плати юридично дійсними та забезпечує основу довіри для користувачів, операторів і регуляторів.
3. Адаптація кількох -протоколів: сумісний із «новими та старими пристроями» OCMF не обмежується одним протоколом зв’язку та може гнучко адаптуватися до основних протоколів заряджання, таких як OCPP 1.6 та OCPP 2.0.1/2.1. Налаштувавши різні параметри, він може підтримувати традиційні сценарії фіксованої зарядки та задовольняти нові потреби, такі як -ad-hoc зарядка. Наприклад, у системі OCPP 2.0.1 після ввімкнення відповідної конфігурації OCMF може автоматично передавати підписані дані на ключових вузлах, таких як початок і кінець заряджання, без модифікації існуючого обладнання, що дозволяє оновити старі пристрої до «надійних вимірювальних пристроїв».
Практичні застосування OCMF
1. Сценарії застосування охоплюють всю екосистему зарядки:
● Виробники зарядних паль: розробляйте вимірювальні модулі відповідно до стандартів OCMF, що дозволяє пряму інтеграцію даних з основними операторськими платформами без окремої адаптації.
● Оператори зарядки: рівномірно отримують дані від зарядних станцій різних марок, що спрощує керування серверною частиною та знижує витрати на експлуатацію та обслуговування.
● Користувачі: після стягнення плати користувачі можуть перевірити автентичність платіжних даних за допомогою зашифрованих підписів, уникаючи суперечок щодо «надмірно високої комісії за стягнення плати».
● Регуляторні органи: прямий доступ до сумісних вимірювальних даних, що забезпечує-нагляд за межами підприємства та покращує ефективність управління галуззю.
2. Типовий робочий процес
● Ви підключаєте кабель для заряджання, щоб почати заряджання, і зарядна станція записує такі дані, як кількість і час заряджання в режимі реального часу;
● Дані інкапсульовані у форматі OCMF, а «цифровий підпис» генерується за допомогою алгоритму шифрування;
● Підписаний пакет даних OCMF передається на платформу керування через протокол SLIP (з початковим і кінцевим роздільниками);
● Після того, як платформа перевірить підпис, вона аналізує дані та генерує рахунок;
● Після завершення зарядки повний запис даних OCMF можна використовувати як платіжний ваучер для підтримки подальшої перевірки.
Еволюція версії OCMF
Галузевий стандарт OCMF, який постійно вдосконалюється, зазнав постійних ітерацій з моменту його запуску, адаптуючись до реальних потреб галузі: V1.0.1: уточнене визначення версії та базова структура даних, закладаючи основу для стандартизації;
● Версія 1.1.0: додано інформацію про тарифи для адаптації до сценаріїв тимчасової тарифікації;
● V1.2.0: додано дані про компенсацію втрат кабелю для вирішення проблем вимірювання втрат енергії під час заряджання;
● V1.3.0: додано поле версії мікропрограми контролера для підвищення точності керування пристроєм.
Кожне оновлення базується на цілях «вищої точності, більшої безпеки та більшої сумісності», гарантуючи, що стандарт завжди йде в ногу з розвитком галузі.
Довідкова таблиця основних полів і сценаріїв застосування OCMF
У цій довідковій таблиці підсумовано основні поля OCMF (Відкритий формат вимірювання заряду) версій від V1.0.1 до V1.3.0, уточнюючи значення, тип даних, підтримку версій і основні прикладні сценарії кожного поля. Це полегшує швидку довідку та практичну адаптацію до розгортання.
| Назва поля | Значення поля | Тип даних | Підтримка версій | Основні сценарії застосування |
|---|---|---|---|---|
| ver | Номер версії формату OCMF | Рядок (наприклад, "1.3.0") | Всі версії | Для адаптації версії між пристроєм і платформою, забезпечення сумісності аналізу даних |
| gw_vendor | Ідентифікатор постачальника шлюзу | Рядок | V0.4 і вище | Простежуваність пристрою; розрізняти шлюзи від різних постачальників для управління експлуатацією та обслуговуванням |
| gw_sn | Серійний номер шлюзу | рядок (обов'язково) | V0.4 і вище | Унікальна ідентифікація шлюзових пристроїв; сформувати простежуваний ланцюжок із даними вимірювання |
| meter_vendor | Ідентифікатор постачальника вимірювального модуля | Рядок | Всі версії | Простежуваність приладів обліку; знайти відповідальних осіб у разі суперечок щодо даних |
| meter_sn | Серійний номер модуля обліку | рядок (обов'язково) | Всі версії | Унікальна ідентифікація вимірювальних модулів; забезпечити однозначну-{1}}відповідність між даними вимірювання та приладами |
| енергії | Загальна енергія зарядки | Числовий (Одиниця: Вт·год) | Всі версії | Основна платіжна база; базові дані для розрахунків користувачів і звірки операторів |
| час_початку | Час початку зарядки | Мітка часу | Всі версії | Обчислюйте тривалість заряджання, порівнюйте ціни на електроенергію-за певний період і створюйте точні рахунки |
| end_time | Час закінчення зарядки | Мітка часу | Всі версії | Підтвердити цикл зарядки; розрахувати загальну тривалість заряджання з часом початку |
| тариф | Інформація про ціни на електроенергію (включаючи періоди часу, тарифи) | Структуровані дані | V1.1.0 і вище | Адаптація до тимчасових сценаріїв зарядки; підтримка--ціноутворення та динамічного розрахунку за тарифами |
| втрата кабелю | Компенсація втрати енергії в кабелі | Числовий (Одиниця: Вт·год) | V1.2.0 і вище | Коректна втрата енергії під час зарядки; забезпечити точність даних вимірювання |
| пор | Версія мікропрограми контролера зарядної палі | рядок (необов'язково) | V1.3.0 і вище | Управління прошивкою; визначити, чи потрібні оновлення для усунення вразливостей вимірювання |
| підпис | Цифровий підпис | Зашифрований рядок | Всі версії | Перевірка даних-на підробку; запобігання фальсифікації платіжних даних і забезпечення юридичної сили |
| sig_alg | Ідентифікатор алгоритму підпису | Рядок | V0.4 і вище | Уточнити спосіб шифрування даних; приймач перевіряє підпис за допомогою відповідного алгоритму |
| статус_автентифікації | Статус авторизації (успішна чи ні) | Логічний | V0.4 і вище | Підтвердити легітимність транзакцій нарахування; відхилити розрахунки за несанкціоновані операції |
| лічильник подій | Лічильник подій | Ціле число | V0.4 і вище | Запис кількості ключових подій під час зарядки; допомога в усуненні несправностей |
Додаткові примітки щодо пріоритету поля:
1. Поля, позначені як «обов’язкові» (такі як gw_sn, meter_sn, energy), є основними для достовірності даних вимірювання; їх відсутність перешкоджатиме нормальному розселенню.
2. Сумісність версій: поля з вищих версій (наприклад, cable_loss, cf) є необов’язковими в системах нижчих версій. Необхідно оновити пристрій до відповідної версії, якщо ці поля потрібні.
3. Адаптація протоколу: усі поля можна передавати через протоколи OCPP 1.6 і OCPP 2.0.1/2.1 без необхідності будь-яких додаткових модифікацій структури полів.
Таблиця відображення сумісності полів OCMF і протоколу OCPP
OCMF, як стандарт даних вимірювання заряду, покладається на OCPP (Open Charge Point Protocol) для передачі даних між пристроями. У наведеній нижче таблиці пояснюється середовище передачі, залежності конфігурації та правила адаптації основних полів OCMF у різних версіях OCPP, вирішуючи практичне питання «як дані OCMF передаються та успішно передаються в межах OCPP».
| Основне поле OCMF | Значення поля | Підтримувана версія OCPP | Носій передачі OCPP (повідомлення/поле) | Залежність конфігурації OCPP |
|---|---|---|---|---|
| FV | Версія формату OCMF (наприклад, 1.0, 1.2.0) | 1,5 і вище | Метадані SignedData (вбудовані в атрибути MeterValue) | Додаткова конфігурація не потрібна |
| GS | Серійний номер шлюзу (унікальний ідентифікатор для компонентів підпису) | 1,5 і вище |
1. MeterValue.req → JSON у SignedData 2. StopTransaction.req → TransactionData |
Налаштуйте "зв’язок зв’язування-зарядної купи" (наприклад, пов’яжіть GS із ChargePointIdentity OCPP) |
| РС | Серійний номер модуля обліку (унікальний ідентифікатор лічильника) | 1,5 і вище | JSON у SignedData (згруповано з MV/MF як «інформація про пристрій вимірювання») | Немає додаткової конфігурації, але переконайтеся, що MS пов’язано з профілями заряджання в серверній частині OCPP |
| RD-TM | Час читання (включаючи статус синхронізації, наприклад, «2018-07-24T13:22:04,000+0200 S») | 1,5 і вище |
1. MeterValue.timestamp (базовий час) 2. JSON у SignedData (статус синхронізації "S/R") |
Налаштувати ClockAlignedDataInterval=900 (15 хвилин, узгоджується з часовими інтервалами регулювання вимірювання) |
| RD-RV | Показання лічильника (наприклад, 2935,6 кВт/год) | 1,5 і вище |
1. MeterValue.value (Необроблений формат, для швидкого відображення) 2. JSON у SignedData (формат із підписом, для перевірки виставлення рахунків) |
Налаштувати MeterValue.sAlignedData=Active.Energy.Register.Import |
| RD-TX | Статус транзакції (наприклад, B=Початок, E=Кінець, T=Зміна тарифу) | 1,5 і вище |
1. StartTransaction.req → TransactionStatus 2. StopTransaction.req → Причина 3. MeterValue.req → JSON у SignedData |
Налаштувати StopTransactionsSignatureFormat=MR/SR (MR: одна передача даних початку/зупинки; SR: дві окремі передачі) |
| LC | Компенсація втрат кабелю (включаючи опір LR, блок LU тощо) | 2.0 і вище | JSON у SignedData (нове поле в OCMF 1.2.0) | Оновіть протокол OCPP до 2.0+; налаштувати «параметри алгоритму втрати кабелю» в контролері зарядної палі |
| Є | Статус авторизації користувача (true=Authorized, false=Unauthorized) | 2.0 і вище |
1. Authorize.req → IdTagInfo.Status 2. JSON у SignedData (прив’язується до результату авторизації OCPP) |
Налаштувати OCPP_AUTH_TLS (авторизувати дані через зашифрований текст TLS) |
| IT | Тип ідентифікації користувача (наприклад, картка ISO14443=RFID) | 2.0 і вище | Authorize.req → IdTagType (або JSON у SignedData) | Налаштуйте «відповідність між типом ідентифікації та ідентифікаційним тегом» у серверній частині OCPP (наприклад, ISO14443 відповідає ідентифікаційному тегу OCPP у 16-значному шістнадцятковому форматі) |
| SD | Дані цифрового підпису (результат шифрування ECDSA) | 1,5 і вище |
1. MeterValue.req → Значення (ValueFormat=SignedData, у шістнадцятковому кодуванні) 2. StopTransaction.req → TransactionSignature |
1. Налаштуйте SignatureAlgorithm=ECDSA-secp256r1-SHA256 (алгоритм OCMF за замовчуванням) 2. Увімкніть MeterValuesSignatureContext=CSL/RW (вкажіть точки запуску підпису) |
| PG | Ідентифікатор сторінки (наприклад, T12345=читання для транзакції 12345) | 1,5 і вище | JSON у SignedData (прив’язаний до TransactionId OCPP) | Налаштуйте «перевірку безперервності розбивки сторінок» (сервер OCPP перевіряє послідовні номери PG, наприклад, T1→T2→T3, щоб уникнути втрати даних) |
Додаткові примітки
1. Правила уніфікованого формату передачі: усі поля OCMF інкапсульовано у форматі «SignedData» у OCPP – тобто OCMF|
2. Межі сумісності версій:
● OCPP 1.5: підтримує лише основні поля OCMF (такі як FV, GS, RD-RV, SD) і не підтримує поля вищої версії (LC, IT типу ISO15118);
● OCPP 2.0 і новіших версій: повністю підтримує всі поля OCMF 1.2.0 і нижчих версій і може бути розширено для майбутніх доповнень OCMF за допомогою поля «CustomData».
3. Пріоритет конфігурації: якщо конфігурація OCPP суперечить вимогам OCMF (наприклад, ClockAlignedDataInterval OCPP ≠ 15 хвилин), правила вимірювання OCMF мають мати перевагу (наприклад, примусове налаштування до 900 секунд), щоб гарантувати, що дані відповідають юридичній дійсності калібрування.
Резюме: Чому OCMF стає важливим стандартом у галузі?
У індустрії зарядки електромобілів, яка швидко розвивається, достовірність і сумісність вимірювальних даних є основними вузькими місцями. OCMF завдяки поєднанню «уніфікованого формату + зашифрованої перевірки + гнучкої адаптації» вирішує головну проблему користувача щодо «чесного виставлення рахунків», зменшує витрати на технічну адаптацію для компаній і надає прозорий інструмент для регулювання, справді досягаючи виграшної-ситуації для всіх сторін.
Оскільки все більше і більше виробників зарядних пристроїв і операторів приймають стандарт OCMF, процес заряджання стане зручнішим у майбутньому – користувачі зможуть впевнено використовувати будь-яку марку зарядних пристроїв і плавно здійснювати платежі на різних платформах операторів. Це основна цінність, яку відкриті стандарти привносять у галузь.
