Мора да го поставите управувањето со оптоварување на „монитор“ во поставките на Управникот за полнење во cFos Power Brain Wallbox. Потоа кликнете на менувачот во плочката на wallbox за да отидете до поставките. Таму скролувате до областа „OCPP gateway settings“.
УРЛ на порталот OCPP | URL-адресата на заднината на OCPP, на пр. ws///за/ врски или wss://за врски шифрирани со TLS. Некои задни делови бараат и одредена патека, на пр. ws://ocpp.backend.com/path/to/resource/. |
Лозинка на порталот OCPP | Ако позадинскиот оператор наведе лозинка за OCPP конекцијата, таа мора да се внесе овде. Ако операторот за заднина не наведе лозинка, ова поле може да остане празно. |
ИД на клиентот на порталот OCPP | ИД со кој портата известува до задниот дел. Овој проект обично треба да биде наведен од операторот на задниот дел. Некои бекенд ги идентификуваат своите клиенти преку поединечни клучеви кои се дел од URL-то, на пример ws://xyz123.backend.com/ или ws://ocpp.backend.com/xyz123/. Во овој случај, клиентот може слободно да го избере идентификаторот на клиентот. |
За да го направите ова, кликнете на "Поставки" за соодветното wallидно поле и внесете го следново:
Тип на уред | EVSE со OCPP 1.6 |
адреса | Овде мора да го внесете ID-то на ChargeBox што е конфигурирано во ѕидното сандаче. |
ИД | Овде треба да го внесете ID на конекторот. За ѕидни кутии со една точка за полнење секогаш е 1, за две точки за полнење е 1 или 2 итн. |
Во поставките на Управникот за полнење, под „OCPP Server TLS“ изберете ја опцијата „Исклучено“ доколку не се прифаќаат шифрирани врски, „Откриј“ ако треба да се прифатат и шифрирани и нешифрирани врски и „Вклучено“ ако треба да се прифатат само шифрирани врски. бидат прифатени. Под „OCPP Server Port“ изберете ја TCP-портата на која треба да се прифатат OCPP врските (стандард 19520). Лозинката на серверот OCPP е изборна и, доколку е наведена, мора да се внесе и во wallbox.
Во wallbox, конфигурирајте го OCPP-1.6J како протокол во поставките за OCPP. Како сервер, внесете ја IP адресата на Управникот за полнење и избраната порта OCPP. На ова обично му претходи ws:// . Така, на пример, ws://:19520/
Претходниот ws:// покажува дека врската е воспоставена нешифрирана. Ова обично треба да биде доволно се додека Wallbox и cFos Charging Manager се во иста локална мрежа. Меѓутоа, ако врската треба да се воспостави во шифрирана форма, наместо тоа треба да се стави префикс wss:// . Ве молиме проверете дали вашиот избор на ws:// или wss:// одговара на вашиот избор за параметарот „OCPP Server TLS“ (видете погоре). За ws:// параметарот „OCPP Server TLS“ мора да биде поставен на „Off“ или „Detect“, за wss:// мора да биде поставен на „On“ или „Detect“.
Идентификацијата на ChargeBox избрана во Управникот за полнење мора да се внесе и во Wallbox. Има ѕидни кутии каде ова не може слободно да се избере, но е фиксирано и одговара, на пример, на серискиот број на кутијата. Потоа мора да се внесе соодветно во Управникот за наплата.
Во некои ѕидни кутии портот се внесува во посебно поле. На некои уреди ws:// може или мора да се испушти, на други е задолжително. Повеќето ѕидни кутии треба да се рестартираат по промената на поставките за OCPP.
CFos Charging Manager поставува таканаречени профили за полнење преку OCPP во ѕидно сандаче или станица за полнење поврзана со него. Стандардниот профил вели дека вчитувањето не е дозволено. Некои станици за полнење ги складираат и овие профили за полнење дури и по ресетирање. Ако таквата станица за полнење треба да работи подоцна без CFos Charging Manager, профилите за полнење таму мора прво да се избришат. Ова може да се направи со cFos Charging Manager на следниов начин:
Некои ѕидни кутии со OCPP, како што е Innogy eBox professional S или Mennekes Amtron, може да пренесат податоци од мерачот што се усогласени со законот за калибрација до OCPP заднината. Портата OCPP на cFos Charging Manager може транспарентно да ги проследува таквите податоци од мерачот до задниот дел.
Некои ѕидни кутии со OCPP можат да испраќаат податоци за Giro-E од терминалот на EC картичката до задниот дел. CFos Charging Manager го проследува ова транспарентно до задниот дел.
Портата не е потребна за управување со cFos Power Brain Wallbox, бидејќи cFos Power Brain Wallbox овозможува истовремено работење на OCPP до задниот дел за авторизација и наплата, како и Modbus за управување со оптоварување. За да го направите ова, конфигурирајте го клиентот OCPP под „CFos Power Brain Configuration“ и исто така активирајте го Modbus. Потоа внесете cFos Power Brain Wallbox под „Start“ и внесете ги податоците за адресата или COM портата и ID на Modbus.
Ако сакате да ја поставите портата, мора да ги конфигурирате следните параметри. За да го направите ова, кликнете на "Поставки" за соодветниот EVSE и внесете го следново:
УРЛ на порталот OCPP | URL-то на заднината за наплата на OCPP, на пр. ws///за нешифрирани врски или wss///за врски шифрирани со TLS. Некои задни делови бараат и одредена патека, на пр. ws://ocpp.backend.com/path/to/resource/. |
Лозинка на порталот OCPP | Ако позадинскиот оператор наведе лозинка за OCPP конекцијата, таа мора да се внесе овде. Ако операторот за заднина не наведе лозинка, ова поле може да остане празно. |
ИД на клиентот на порталот OCPP | ИД со кој портата известува до задниот дел. Овој проект обично треба да биде наведен од операторот на задниот дел. Некои бекенд ги идентификуваат своите клиенти преку поединечни клучеви кои се дел од URL-то, на пример ws://xyz123.backend.com/ или ws://ocpp.backend.com/xyz123/. Во овој случај, клиентот може слободно да го избере идентификаторот на клиентот. |
Сертификатите се користат кога се користат шифрирани TLS врски помеѓу клиентот и серверот. За успешно воспоставување на таква врска, серверот секогаш бара сертификат и поврзан приватен клуч. cFos Charging Manager веќе има самопотпишан сертификат на бродот. Затоа не е неопходно да се увезуваат сопствени сертификати. Сепак, оваа опција постои и на страната на серверот и на клиентот.
На страната на серверот, вашиот сопствен сертификат и поврзаниот приватен клуч може да се увезат. Овој сертификат може да биде сам потпишан или потпишан од официјален орган за сертификација (CA). Ако не е зачуван сертификат CA во клиентот, секогаш ќе се воспостави TLS врска. Ако еден или повеќе CA сертификати се зачувани во клиентот, соодветните сертификати на серверот мора да се совпаѓаат (OCPP Security Profile 2). Самиот сертификат на серверот може да се зачува како сертификат CA. Ако клиентот има врска на Интернет, таму може да се складираат и root сертификати од властите за сертификација кои го потпишале сертификатот на серверот. Сепак, можете да го зачувате и вашиот сопствен root сертификат кој го потпишал сертификатот на серверот.
Како дополнително ниво на безбедност, сертификатот може да се користи и во спротивна насока (OCPP безбедносен протокол 3). За таа цел, сертификатот и поврзаниот приватен клуч се зачувуваат во клиентот. Меѓу сертификатите CA, серверот го добива и овој сертификат или root сертификат што го потпишал сертификатот на клиентот. Ова значи дека врската TLS се воспоставува само ако серверот може да го потврди сертификатот на клиентот.
Можете сами да креирате сертификати, на пример со програмата OpenSSL, која е достапна бесплатно за Windows и Linux. Еве неколку примери за користење OpenSSL. Примерите користат конфигурациска датотека зачувана во формат UTF8 во врска со параметарот -config. Ова има предност што umlauts и други знаци на Unicode исто така може да се користат во сертификатот. Конфигурациската датотека секогаш го има следниов формат:
[req] prompt = no distinguished_name = dn req_extensions = ext [dn] CN = Unsere Tiefgarage emailAddress = info@tiefgarage-koeln.de O = Tiefgarage Köln GmbH OU = Abteilung 13 L = Köln C = DE [ext] subjectAltName = DNS:tiefgarage-koeln.de,DNS:*.tiefgarage-koeln.de
Создавање приватен клуч rootCA.key за root сертификат:openssl genrsa -des3 -out rootCA.key 4096
Создадете самопотпишан корен сертификат rootCA.crt користејќи го приватниот клуч rootCA.key создаден погоре и конфигурациската датотека rootCA.cnf (параметарот -days одредува колку дена е валиден сертификатот):openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 365 -out rootCA.crt -config rootCA.cnf -utf8
Креирање приватен клуч client.key за сертификат за клиент:openssl genrsa -out client.key 2048
Креирање на барање за потпишување сертификат (CSR) client.csr за сертификат за клиент користејќи го приватниот клуч client.key создаден погоре и конфигурациската датотека client.cnf:openssl req -new -key client.key -out client.csr -config client.cnf -utf8
Создавање на клиентски сертификат client1.crt, кој е потпишан со горенаведениот root сертификат rootCA.crt и поврзаниот приватен клуч rootCA.key (повторно, параметарот -days одредува колку долго е валиден сертификатот):openssl x509 -req -in client.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out client.crt -days 365 -sha256
Можете да ракувате со cFos Power Brain Wallbox паралелно со Modbus и OCPP, на пример да го интегрирате во локалното управување со оптоварување преку Modbus и да го прикачите на заднината за наплата преку OCPP. За да го направите ова, „Активирај Mosbus“ мора да биде вклучено во поставките на cFos Power Brain Wallbox и мора да се конфигурира TCP порт или COM параметар за да може ѕидното сандаче да се адресира преку Modbus. Дополнително, под поставките OCPP мора да се постават URL-адреса на заднината на OCPP, ID на клиентот OCPP и, доколку е потребно, ID на конекторот OCPP. OCPP потоа започнува вчитувања, т.е. трансакции. Врз основа на пренесениот РФИД, тој одредува дали трансакцијата е дозволена и потоа започнува да се вчитува доколку е потребно. Ако нема RFID читач, можете да конфигурирате фиксен RFID што е познат на OCPP заднината. Струјата на полнење сега може да се регулира со управување со оптоварување користејќи Modbus, т.е. струјата на полнење одредена од профилот за полнење OCPP може да се намали. Профилот за полнење ја одредува максималната струја на полнење. Според тоа, струјата на полнење е секогаш минимумот од струите на полнење специфицирани преку Modbus и OCPP. Полнењето исто така може привремено да се деактивира и повторно да се активира преку Modbus или OCPP. Вчитуваме само ако и двете - Modbus и OCPP backend - дозволуваат вчитување.