ZERAS: OCPP를 통한 전기차 충전 인프라 강화

### ZERAS 및 OCPP로 전기차 충전 인프라 강화
* ⚡ 오픈 소스 서밋에 오신 것을 환영합니다. 이번 오픈 소스 서밋에서는 **제로스가 어떻게 전기차 공급 장비로 기능**하며, 기본적으로 **OCPP(오픈 충전 포인트 프로토콜)를 활용한 충전소 역할**을 하는지 살펴볼 것입니다.
* 👨 저는 Linux 분야에서 **13년 이상의 경력**을 쌓고 Linux 커널 및 ZERAS와 같은 오픈 소스 프로젝트에 기여한 Linus의 소프트웨어 엔지니어인 Sanand입니다.
* 🔌 이 강연에서는 **전기차 충전 인프라의 현재 상태와 한계점**과, 이러한 문제를 해결하여 충전 경험을 향상시킬 수 있는 **ZERAS의 방법**에 대해 다룹니다.
* 🌍 2009년 오픈 충전 연합이 설립한 **OCPP는 전기차 공급 장비와 중앙 관리 시스템 간의 통신에 중요한 역할**을 하며, 전기차 산업의 상호 운용성과 효율성을 보장합니다.
* 🏗 또한 **다중 이더넷 인터페이스 지원, TCP/IP 스택, 정확한 청구를 위한 에너지 미터 통합** 등의 장점에 대해 논의하면서 ZERAS 내에서 OCPP의 구현 세부 사항을 살펴볼 것입니다.
* 📊 OCPP는 에너지 소비를 모니터링하고 정확한 청구를 생성하는 데 필수적인 **거래 시작 및 중지**와 같은 필수 기능을 처리하는 핵심 프로필을 포함하여 다양한 프로필과 메시지를 지원합니다.
* 🔄 마지막으로, 지속적인 개발과 전기차 충전 인프라를 더욱 개선하기 위한 추가 기능의 통합을 포함하여 **ZERAS 내에서 OCPP의 미래**를 검토할 것입니다.
* ❓ 전기자동차 충전 솔루션의 진화하는 환경에서 **OCPP의 구현과 기능, 그리고 그 중요한 역할**에 관한 질문이 있으시면 언제든지 환영합니다.

Zaras는 개방형 충전소 프로토콜의 효율적인 구현을 통해 전기차 충전 인프라를 개선합니다.

Hello everyone, uh good morning and welcome to the Open Source Summit. Uh, in this talk, we are going to see how ZERAS is used or acts as electrical vehicle supply equipment. In other words, in short, it is called an electrical charging station. And um, using the open standard called Open Charge Point Protocol. So, my name is Sanand. I'm a part of Linus. I'm working as a software engineer or the EMB software engineer at Linus. Over 13 years of experience uh in the Linux uh working in a Linux uh. I'm a developer and contributor to the open source projects like Linux Kernel and ZERAS. Uh, about U Linam, it's a software servicing company which provides uh uh embedded software development and consulting and training in embedded Linux and ZERAS project. So, we do servicing in the range of bootloader development and then colal development uh new board support packages and also the device driver development. I live in Berlin. Okay, here is the summary of this talk. Um, first we will check what electrical vehicle and uh how the

current state of the charging infrastructure and what are the limitations currently having and then how does zaras help to improve the limitations for achieving a better charging infrastructure. This talk is primarily focused on the Open Charge Point protocol (OCPP). It's an open standard specification, so we will look into the why, what is the Open Charge Point protocol (OCPP), and then we will have a brief look into the specification internals. After that, we will have a look into the OCPP implementation, the native implementation of the stack in the zaras, and how to consume it in the application layer. And after that, we will have a look into the electrical vehicle supply equipment standards, which is mainly used to connect between the charging station and EV for handshaking and delivering the power. And finally, we will look into the current state of OCPP in the zaras and the future work. Okay, so electrical vehicles are an emerging market because of their advantage of being environmentally friendly, but there is a limitation in the infrastructure due to a lack of

charging infrastructure, so electrical vehicle supply equipment, or the charging station, is simply called a charging station, which is used for the supply of electricity or energy to the electrical vehicle. The electrical vehicle utilizes that to the battery charging, and in comparison with the gasoline vehicle, like a petrol station, which takes a few minutes to refill the fuel, one of the limitations with the electrical vehicle is the amount of time it will take to recharge the battery is very huge. It also occupies the parking space until it gets recharged fully. One of the advantages of the charging session is that it is portable and can be easily installed in most parking places. So, is it really necessary to be installed in the parking place? Because we cannot make the installation in the petrol station or gas station because we need more parking lots. So, the better place to install the charging station is the existing parking place where we can utilize that. So, in a nutshell, we need more and

more lightweight distributed networks, so where we can employ that instead of handling one bulky machine, which can handle multiple ports, like 100 ports of charging vehicles. It can handle it, so we really need a distributed network where we have the parking lot, where we will have the highways, or as the hotels, or even the working office space and environment. So, we have seen what is the limitation, and what we really need is a distributed charging infrastructure. And how does the Zona help with this distributed charging infrastructure? So, microcontrollers are more suitable for lightweight applications. And then, yeah, for the microcontrollers, we obviously have one of the choices, Zaras, which has more advantages in terms of it supports multiple Ethernet interfaces. And then, the other interface, which we'll go and see, the Zaras has its advantages, like it has native implementation of TCP/IP stacks, and then it can be directly used to the Ethernet controller. And apart from that, we can use the internet infrastructure for the Wi-Fi controllers.

and a lot of Wi-Fi controllers which support offloading, which means we can send a payload, and then that TCP or the IP packet will be framed by the offloading controllers. So, we have the support in the zaras for the offload socket option also, which will reduce the burden on the microcontroller, which can focus on the application side. And one of the requirements for the evsc is like when we are going to install the charging station in their highways, like where it is in the remote areas, we have a lack of internet infrastructure. So, we can use the modem as one of the internet-facing interfaces. So, Zas supports modem-like one single-day solution like NRF, where we have the application processor or application CPU, and also the motor can coexist in a single eye. Otherwise, also the Z supports other external modems, which work on the cmax or the PPP or AT commands. And then Z itself supports a variety of architecture support like extensa, Risk five, arm, and also the

because of that um we have a more and more platform supported uh so in if you want to uh go be proof of concept which will be helpful like the existing platform with the ethernet support or Wi-Fi can be used to as a proof of con before going into uh real product use case so as an evsc really wants to measure the how much the power it is how much the power or the energy which is delivered to the eveve uh the charging station should be employed with the energy meter so most of the energy industrial energy meter supports digital Communications like modbus or uh modb and then the uart or others serial EMB modules so thanks to Z Ras which supports the native support of the mod bus as well and at the end we have uh we are going to have the support for the open charment protocol native stack in the Z as well so collectively we have a lot of advantages why we should go for the Seas or how it would be helpful for improving the charging

infrastructure. In addition to that, we do have an RFID reader, which probably with the NFC stacks, and it's going to be integrated or merged soon into the Zas. So, we have seen so far what the drawbacks in the charging station are. How does the Zeras going to help in that? So now we will briefly check into the open charge PL protocols and what it is, why it is really needed in the electrical vehicle supply of the charging stations. The open charge Point protocol, or simply called as OCPP, is an application protocol which is used for communication between the electrical vehicle Supply equipment and the central management system. So we know the charging station is to provide that power to the electrical vehicle, but what is this Central management system? It is a kind of a backend server which will handle the user entity and how much the charges, how much energy has been used by the consumer on different charging stations, and based on that, the billing will be generated. So these databases will be maintained by the central management system. So it is

um, the open charge management protocol is established by Open Charge Alliance. It was established in 2009, and since then, it has the advantage of being designed to be free, open source, and also supporting interoperability. It has become a global benchmark for the entire EV industry to adapt the OCPP in all the charging stations, I would say. Okay, so does OCPP really need a need in the charging station? Is a question because, uh, when um, I have a private charging station which can directly connect to the electrical vehicle, then there is no need of charging the OCP protocol. But really, when we have the public infrastructure installed, the EVSC, then we need a communication back to the back end, which is uh, supported by this open charge point protocols. So, I would say the open charge protocol is not an option for the public infrastructure, and also, I would say it is recommended for the private infrastructure as well, private charging session as well. Why uh, because we need a more and more distributed uh, net charging infrastructure for that um, even the

private contributor to the charging infrastructure, which will help the whole EV industry or the EV segment. So, when the private charging session is not in use, it can lend for public access, and based on that, you can boost the EV segment or the charging segment. So, OCPP has been developed with multiple versions, starting from V 1.4 and 1.5, which are already obsolete, which supports different messaging formats, which we will go to see in the next slides. Currently, we have the support of version 1.6 and version 2.0.1. And with respect to current presentations, we limit the scope of version 1.6. Okay, if you're new to the electrical vehicle supply equipment of the charging, these are all the abbreviations which we'll be going to use in the following slide, so it would be helpful if we can see these are the observations. So, CP meant for the charge point, and CP was charge point operator who can handle the database of the

maintenance of the central system and CS is the backend system, which is the Central system. Then, ID ID tag, a unique U identification used to identify the user, maybe the access card where we can read the ID tag. OCPP is Open Charge Point Protocol. Then, there are two messages which are framed by the OCPP, the PD, which is a Protocol Defined Unit, and RPCU, which we will see in the next slides. Okay, the profiles and messages, the basic communication between the central system and the charge point, are based on the predefined Protocol Defined Unit, or simply the PDU messages. So, these are the basic building blocks of communication between the charging station and the central system. So, there are approximately, the version 1.6 supports 29 messages. We are not going to see all those messages because of the time constraints, but these messages are grouped into a profile based on the features and functionality. Here are the list of profiles supported by the version 1.6, the core profile, which is the

mandatory profile um basically handles all the messages which are required for the charging and stop charging, etc. Apart from that, we have the local authorization list message and U yeah, which is mainly for to authorize when there is no connection between the communic, the central system, and charge point because of the network issue of anything. And then the charge point can uh take an action like um, it can authorize the user if the user has been already authorized and it has a validity tag. Then we have the firmware management profile, which is for the over-the-air update of the firmware for the CH Point itself. So we will not see all these profiles, but we limit to the core profile and uh its messages. Here are the list of the messages which is supported by the core profiles and out again uh we are not going to see all of them, but at least we will pick the messages which are essential for one complete charging cycles. So we will have a look into the authorized boot notification message, meter values, start stop transaction, and then remote start stop.

transactions okay so boot notification is a PDU message which is the first message which is which Char Point sends to the central system. So Central system will enumerate or discovers there is a charge Point available in the network using the boot notification message and after startup or the reboot or the charge Point initiate the communication with the central system. So the boot notification message carries the following informations like charge Point model, charge Point vendor IDs, and then the ICC id, imsi id. So no other PD message should be sent without acknowledgement or of the boot notification or the acceptable of central system. Okay when the user wants to get into the access of the charging station first he has to get authorized. So the unique identifier authorized is unique ID identifier is used for the authorization purpose. This unique identifier is read from the access card using RFID on the charging station. Otherwise there is other mechanism like when the mobile applications like smartphone smartphone mobile application otherwise the web browser is used to kind of a virtual ID directly it can

start communicating with the central system, and then the central system will authorize the user. So when the user gets authorized, then he can be able to start charging his vehicle after connecting the connector into the EV from the charging stations. So once we have authorized the user, gate authorized, then the charge station, after connecting the cables, the charge station can deliver the power to the electrical vehicle. After that, it can send a message, a confirmation message to the central system that the start transaction, the transaction has been already started by sending the start transaction PDU message. Okay, once we have started the transaction, then if the battery gets completed, otherwise if the user wants to interrupt the stop the charging, then he can hit a button on the charging station. Then the charge point can terminate the power supply to the electrical vehicle. After that, it can send a stop transaction PD message to the central system to notify that a transaction has been already stopped. Okay, so far we have seen the stop transaction and boot notification, all these messages which originate from the charging station to the central

system, but that is a way, as I said, when the user wants to start charging. He can request to the central system using the mobile application or the web browser. Then, the charging station can request a start transaction message to the charge point. So, this is used by the two messages called the remote start transaction and remote stop transactions. Upon receiving this remote start transaction, stop transaction, the charge station can decide whether it can start or stop based on the local environment, like whether the power supply is available to deliver the EV or else the cable is connected. So, once it is done, then again it should follow the same process of what we have seen in the last previous slides, like start transaction, stop transaction. So, one of the peculiar cases with here is the remote stop transactions. It is not necessary that this remote start and stop has to be always the pair. Even if the local charge station sensor start transaction, those transactions will be available on the central system. So, remote start-stop transaction message which can be sent from the central

system for already started charging session. Okay, there are some cases where malfunction of the cable retentions, like after authorization, the user has to get the cable and then connect to the charges. If there are any malfunctions that happen with that, then he can request the CPU operator, the CPU operator, so that the charge point operator can send an unlock connector message from the central system to the charging station. Okay, so we have seen the start transaction, stop transaction, which carries the information like which connector it has started, and also the time of starting, the meter values are sent, and also at the time of stopping, the meter value has to be sent. So, based on this stop and start transaction meter values, the buildings are generated, how much power has been consumed, apart from that, in the start and between the start and stop transaction, so the charge point can may collect the information of the current meter readings and also send it to the central system. The purpose is like the central system may have the kind of

graph mechanism to plot how much the charging is consumed. And for those purposes, it is the meter values that are used. And um, we can, the meter values carry the values like a connector ID and the current meter value. It is like frequently sent from the charging station to the central system. So we have seen so far the specifications, what are the basic messages of the predefined unit messages. And these predefined unit messages are not sent to the central system directly. Instead, it will be wrapped into a um or encoded into a wrapper called a remote procedure call messages. This carries um a message type and then a unique identifier and the payload of the OCPP PD message itself. So the message types are primarily categorized into three types. One, the call to send a request. And um, call res is to reply or getting the response for the call message. And then call error if in case of any error or the failure with the reasons. The OCPP specification is mentioned that it should, there should not be a new call message originating either from the charge point or central.

system unless other until the previous call message has been responded or time Root, which means um there will be only two call messages exist in between the charge point and the central system at any instance. One originator from the charge Point, another originate from the central system, and that should not be new one uh new call message should be started before the response of the time road. So, we have seen the message frame, and here we will see the example for the call request message frame and also the call response message frames in details. So, we have the message type of one by which carries constant two for the call request, and um we have the message ID, which is used for the purpose of identifying the message itself. So, it should be the unique identifier of any string of 1 to 32 bytes. After that, the action which will carries the pdu. What is the purpose of the pdu like the boot notification or start transaction or stop transaction, and then the payload itself. The payload what we have used in this uh presentation is uh there are two type of

payloads supported or PDU message format supported in the OCP 1.6. One is the JSON format and another one is SOAP, but with the later version or the version 2.0 only we have the JSON format. So throughout this slides, we have used only the JSON format. So here we can see the example for the boot notification and then the charge point vendor IDs and the model has been sent on the call request and we will get into the call response as the message type constant 3 and then the unique message identifier which is used to send for the call request. Here the same should be here so it can match which packet the response has been received. Then we have the response JSON for the payload for the boot notifications. So we have so far seen what is the specification, what specification has said about the message format and then the message sending the wrapper, but how could we really visualize U into the complete charging station. So we will see here one of the example use cases because we have we cannot able to cover

all of them, but here we have mentioned one of the use cases, like how the user interaction between the EV and EVSC, and then the EVSC to charging station uses the OCPP PD messages. The first, the user has to get access for that purpose. He shows the access card to the EVSC. Then, the EVSC will have a card reader, like NFC or the RFID reader, which will read the ID tag. Once it reads the ID tag, it will send the OCPP authorized request message to the central system. Then, the central system will check all the database, like navigating whether the ID tag is matched, and if it is already in the valid state or else it's expired or blocked, all these checks. So, once we will take it to the Happy path here, like the ID tag has been already matched, and then we will get the response like authorized. So, once authorized, the user is able to, the connector is released from the EVSC, so the user can pull in the

connector from the EVSC and then connect to the EV. Then, once the cable is connected, the user can press the start button available on the charging station. Once the start button has been pressed, the EVSC will release the circuit for delivering the energy, and then it can send the OCP message that the transaction has already started with the meter readings when it was about to start. So, one successful transaction, then the meter values are continuously sent from the EV, like how much consumption by the EV until the stop transaction or the complete charging cycle ends. So, when the user wants to interrupt or stop the charging, then he can hit the button on the stop charging button on the EVSC. Then the EVSC will shut down the power to the EV, and then it can send the energy meter what is the last reading after shutting down. Then it can send the OCP message stop transaction to the central system. After that, the cable can be

disconnected and inserted to the EVSC. So, we have seen one complete charging session. Use cases for how the user interacts with the charging station directly for the start and stop chargings. We will have another example which showcases the user can directly interact with the central system instead of EVSC. So, if a user can have a web authorized or the smartphone which can able to interact with the central system, then the virtual RFID is used here to communicate with the central system. And then the central system will check the database and then it will authorize the user. Once he has been authorized, the EVSC will unlock the connector. So, the connector can be the user can pull in the connector and connect to the EV vehicle. After that, the user can start the transaction or the start charging by pressing a button on the application and it goes to the central system. And then the central system will send a message, remote start transaction message. After that, the EV has to solely responsible to decide whether it can deliver the power to the

electrical vehicle based on whether the good Power is available to that, uh, and also the cable is connected in the proper things of all this. So once, uh, charging is started, then it can send a start transaction message to the central system. It carries the same, um, the cycle what we have seen in the previous slides, like it sends meter values frequently. After that, uh, when the user wants to stop, then he can, um, yeah, request the central system using a web application or else the mobile phone smart application. Then, uh, the central system will send the remote stop transaction. After that, the Evac will shut on the power and will do the stop charging sequence. After that, it will send a stop transaction PDU message to the central system. And finally, the EVS or the user can disconnect the evsc, uh, the cable from the EV and to the, you can connect back to the evsc. Okay, so far we have seen how the OCPP specification uh, messages appear and how it has been wrapped into uh, uh, RPC message to communicate with the central system. Um, so now we get

into the how the protocol is being implemented in the Z foras since OCPP is an application protocol. So, it can coexist with the MQTT, CoAP, and other application protocols. The OCPP sends a message using the socket APIs, especially the WebSocket APIs, to the central system in any of the network interfaces like Ethernet, Wi-Fi, or the modem. And then, the OCPP exposes public APIs for the application use case. So, applications can directly use those APIs to send data to the central system or back and forth. Okay, now we will look into how the OCPP stack is implemented in the Z foras. So, as I said, we have native at the bottom, we have the native WebSocket implementation of the Z, and then at the top, we have the application which consumes the OCPP consumer APIs. So, from the bottom up, we have the RPC message format, and above that, we have the JSON PDU format. Then we have the list of profile implementations, the code profile which has the start transaction, stop transaction, and then we have the

interesting one, which is the key management on the right side. What is this key management? We have the key-value pair, which is maintained or used to communicate between the charging station and the central system. For example, we have the meter values. It has to be sent frequently, but how much time it has to send. So, this is configurable using the key management key-value pair. Apart from that, we have heartbeat messages. So, the timing between the heartbeat, how much time it has to send, it can be read from the central system and also can be changed by the central system. And for that purpose, we have the key-value pair. Then we have the OCPP internal implementation, which carries the socket connection and the reconnection handlings. So, the user has nothing to do with when the internet or the socket gets disconnected. The OCPP stack itself can be able to reconnect, establish the connection. And we have the user notification handlings. So, for example, whether the central system sends some of the requests to the charge point, then the

It has to notify the user like start charging, stop charging. Otherwise, even the internal request from the OCP, like the meter value, the frequency, has to read from the application that will be used by the user registered callback in the unit functions. Now we will look into the API U, which is exposed to the consumer. The first one is open charment, the _ unit API, which is supplied with the charge point information and central system information. The charge point model, vendor, and the number of connectors are the mandatory information which needs to be filled to the charge point information, and then central system information like IP address, which is a resolved one, and then port and websocket URL supplied here. So before initializing the OCV library, the network interface should be already up and running because once we call the OCPP init, then it will try to establish the socket connection with the central system, and then it sends the boot notification message. Then we have the pair of session handling API, so OCPP session open and

close so each connector, then the charge point may support n number of connectors, and each connector should have open a new unique session handling before any of the further, uh, like start transaction or the stop transaction AP is used. The session management is sole purpose of internal to the stack and nothing relevant to the specifications. Okay, so from the application, so when it wants to get authorized, then it can use the OCP for authorized API, uh, which carries the ID tag as an input, and then we will get the status as a response, and the status may carry the invalid, accepted, blocked, etc. So once we have the response with the _ _ accepted, then the user is allowed to start charging. So we have this OC start transaction messages like when the charging station has already started delivering the power, it can read the energy meter values, and then it can send the start transaction message to notify that the central system transaction has been started. So it is binded with the connector ID and then, uh, what is the energy meter at the time of start. Then once we have

the transaction has been started. Uh, then the user calls back the register call back, and the unit function will be called from the stack using the reason like get meter values, just to read the meter value Val. So, so it is uh recommended that this call back function needs to be written as quick as possible, like the meter value should not be read. The call back itself may be another parallel thread which can read the and can share between the uh this call back function on the the under the thread. And um, the other reasons may be like start charging and stop charging, which is originated from the central system. Once uh, the complete charging cycle has completed, then we can have we can use the application may use ocp P stop transaction with yeah, the reading from the energy meter. Okay, we have seen so far the ocpp, which is used primarily between the charge point and the central system uh, but does EV evsc really complete with that? Not really, because uh, we have the real land shaking between uh U the charge point and electrical vehicle and to deliver the power which is

um yeah mentioned by the standard I16 851 and ISO 15118. Unfortunately, these specifications of the standards are not open, and we can see a yeah very overview about that. So, we have two mechanisms for handshaking. One is for the control pilot, and another one is the proximity pilot. Control pilot is mainly used for the communication to negotiate the charging level of the car and the charging station, and then proximity serves for the cable detection and current limitation. So, OCPP, I would say the OCPP part will cover 40 to 50% of EVSC. The other part is covered by the application with the I implementation. So, if you will see the use cases here, once a user got authorized, then it will be in the state of A1, which the control pilot values is the voltage level in the 12. After that, the cable is connected to the EV, then it will drop to the 9 voltage by detecting the cable is connector. Then Evac can prepare for the charging, and it will

um, it will communicate to, or it will notify the electrical vehicle that the um, the charging is charging. It is ready to power the charging, uh, deliver the charging um, so the PWM signal is used with the 9 volts. After detecting the PWM signal by the EV, then the EV will pull into the pull, pull down the control pilot voltage to the 6 volts. So, the charging is started, and then we have the, we can send the start charging OCPP A, and then we have the EVAC stopped. Once we get full charging, and we will enter into the state like C1 and stop charging. So, once the user presses the stop button, it can come into the default ST, the B1, and then the cable can be disconnected. So, it will go to the state A1F, okay. So, we are almost come to the end of the presentation, um, here the state like the OCPP, uh, is currently under review, and it will be merged after the review is completed. Then currently, we have 1.6 core profile is supported, and then

the future work is the TLs support and 1.6 optional profile and 2.0.1 supports. Thank you. Uh, do you have any questions? Yeah, one second. Hi. Uh, thank you for the presentation. Uh, this was really clear to me. Um, the diagrams really helped in terms of explaining um, each of the steps and in order for this overall charging workflow. Um, one thing that perhaps isn't um, so apparent um, is really this start transaction. Yes. Um, phase, right, whereby uh, the uh, charge Point equipment sends this uh, request to the central system. So, is this a required step in order for the vehicle to begin charging, or is this purely to send some information to the central system to like notify them, okay? Is this a critical part, or is this a blocking operation, or is this like sort of okay? So, the main purpose of OCPP is, as I said, it has to communicate to the central system so that the central system knows how to um, how much the power has been consumed by the user, and then it will generate the buildings. So, for that, the start

transaction should be notified to the central system, and then also the stop transaction has to be notified to the central system with the meter values. So, it can, the central system will calculate based on how much the start of the energy meter and what is the end value of the energy meter. Based on the difference, it will translate into the buildings. Okay, thank you for clarifying. Hello, we're good presentation, and I would like to extend your topic about ISO 15118 a little bit. So, the last standard is more about encryption safety, and one major part of it is Plug and Play. So, yeah, so, but I don't see any content on your slides, and I'm curious about, does your company support such a feature? And when we do plug and play, we find which is so difficult to connect your charger, your charge point to the vehicle. So, you have to let your charger to notice who is using it, who is using it, and which account it belongs to, and how when to St Chargers. So, by that standard.

ISO uh ISO one 518 uh provides a very complicated uh handshaking certification procedure layer. So how uh how does saver uh helps you on it or does it have doesn't doesn't doesn't have at all. Thank you. So since it is a closed resource we cannot able to explain much into the current presentation uh otherwise we have implemented to one of the customer the EV uh with fullblown with a specification of 11518. Yes is that answers your question uh I think it's more than that but I can contact with you later. Sure. Thank you. Okay. Thank you very much there one more. Yeah sorry I did hey I was just wondering um how often does the meter pull uh back to the central system and also what happens if you miss the stop transaction from the central system uh I you know I don't want to end up like getting free energy from this uh charge point for forever but I was just curious how uh op or ocpp handles that. Okay uh for your first question it is configurable values so that how often the meter value has to be

sent as you said. There is a key-value pair which is read from the central system, and also it can modify the values. So, based on that, the meter values is sent, and in the last question, the stop transaction has been missed by the central system, you mean, or um, because the no if the charge if the charge point misses the stop transaction from the central system. Okay, so Central system does not send uh stop transaction message to the charge point. The charge point is the one which will notify the central system that the transaction has been ended with the stop transaction message. Got it. Thank you very much. Thank you.

OCPP: Zephyr RTOS as Electric Vehicle Supply Equipment(EVSE) - Saravanan Sekar, Linumiz

Zephyr is a small, scalable real-time operating system (RTOS) for use on resource-constrained systems supporting multiple architectures.  Developers are able to tailor their optimal solution.
As a true open source project, the community can evolve the Zephyr RTOS to support new hardware, developer tools, sensor and device drivers.

The Zephyr Project

제로스는 충전 인프라를 개선하기 위해 개방형 충전소 프로토콜(OCPP)을 사용하는 전기자동차 공급 장비 역할을 합니다.

이 강연에서는 현재 충전 인프라의 한계와 분산형 충전소 네트워크의 필요성을 강조합니다.

ZERAS는 다중 이더넷 인터페이스, 기본 TCP/IP 스택 구현, 오프로딩 지원 등의 장점을 제공하여 경량 애플리케이션과 원격 설치에 이상적입니다.

전기차 충전 인프라 개선을 위한 제라스의 역할

Zeras는 이더넷과 Wi-Fi를 활용하여 EV 충전의 개념 증명을 위한 플랫폼 지원을 제공합니다.

에너지 미터의 디지털 통신은 Zeras의 기본 모드버스 지원과 함께 충전소의 전력 측정을 향상시킵니다.

개방형 충전소 프로토콜(OCPP)은 충전소와 중앙 관리 시스템 간의 통신에 매우 중요하며, 상호 운용성과 분산형 충전 인프라를 촉진합니다.

중앙 시스템과 충전 지점 간 통신

중앙 시스템은 사용자 식별을 위해 고유 ID 태그를 사용하여 개방형 충전소 프로토콜(OCPP)을 통해 충전소와 통신합니다.

6은 프로필로 그룹화된 29개의 메시지를 지원하며, 핵심 프로필은 필수 충전 기능을 처리합니다.

통신의 주요 메시지에는 부팅 알림, 사용자 인증, 거래 시작, 거래 중지 등이 있으며, 이를 통해 충전 과정과 전기 자동차에 전력을 공급할 수 있습니다.

충전 프로세스는 사용자가 모바일 앱이나 웹 브라우저를 통해 시작하거나 중지할 수 있으며, 충전소는 이러한 요청에 응답합니다.

원격 시작 및 중지 트랜잭션 메시지가 항상 쌍을 이루는 것은 아니므로 충전 세션을 유연하게 관리할 수 있습니다.

전력 소비를 추적하기 위해 충전소에서 중앙 시스템으로 미터 값을 전송하고, 충전소와 중앙 시스템 간의 통신을 위해 미리 정의된 단위 메시지를 원격 프로시저 호출 메시지로 래핑합니다.

6은 JSON과 SOAP 메시지 형식이 모두 지원하지만 버전 2.

부팅 알림 예시는 매칭을 위해 고유 메시지 식별자를 사용하는 호출 요청 및 응답 프로세스를 보여줍니다.

사용자 상호작용 사용 사례는 충전소 액세스부터 충전 거래 시작 및 중지까지의 흐름을 보여주며, 중앙 시스템이 인증 및 전력 공급에서 핵심적인 역할을 합니다.

OCPP 프로토콜은 중앙 시스템으로 트랜잭션 메시지를 전송하고 WebSocket API를 사용하여 통신함으로써 전기 자동차 충전을 관리합니다.

Z Foras의 프로토콜 스택에는 기본 WebSocket 구현, RPC 메시지 형식, 구성 가능한 설정을 위한 키 관리가 포함되어 있습니다.

또한 OCPP는 소켓 연결 및 재연결, 사용자 알림을 처리하고 충전 포인트 및 중앙 시스템 정보에 대한 API를 노출합니다.

EVSC의 세션 관리 및 충전 프로세스

충전 포인트는 여러 커넥터를 지원하며, 각 커넥터는 거래를 시작하기 전에 고유한 세션이 필요합니다.

인증 API용 OCP는 사용자를 검증하는 데 사용되며, 수락되면 사용자는 충전을 시작할 수 있습니다.

충전 과정에는 충전소와 전기 자동차 간의 핸드셰이크가 포함되며, OCPP는 EVSC의 40~50%를 담당하고 나머지는 애플리케이션 구현에서 관리합니다.

OCPP의 주요 목적은 중앙 시스템과 통신하여 전력 소비량을 알리고 청구서를 생성하는 것입니다.

시작 거래는 중앙 시스템이 에너지 사용량을 추적하는 데 중요하며, 중지 거래는 청구서 계산을 위한 계량기 값을 제공합니다.

계량기 값 업데이트 빈도는 구성할 수 있으며, 충전 지점은 거래가 종료되었음을 중앙 시스템에 알릴 책임이 있습니다.