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.

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

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

Scripts