We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

EVerest: AC and DC electric vehicle charging with open source software and hardware

00:00

Formal Metadata

Title
EVerest: AC and DC electric vehicle charging with open source software and hardware
Title of Series
Number of Parts
542
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
We will give a brief introduction to electric vehicle charging technology, including an overview of the standards and protocols involved. This will be followed by a deep dive into how you can build your own AC charging station with open hardware, utilizing the EVerest open source software stack. Concluding the talk, we will present an outlook on how you could assemble a DC charging station with readily available components. The primary goal of EVerest is to develop and maintain an open source software stack for EV charging infrastructure. You can think of it as an operating system for EV chargers with implementations of communication protocols, software modules for representations of hardware devices and tools for simulating the charging process. In this talk you will learn how you can adapt and use EVerest with existing charging station hardware, as well as building your own AC and DC charging stations. We will show you how you can get started by using open hardware designs and schematics in combination with open source software to build a charging station that will reliably charge your electric vehicle.
14
15
43
87
Thumbnail
26:29
146
Thumbnail
18:05
199
207
Thumbnail
22:17
264
278
Thumbnail
30:52
293
Thumbnail
15:53
341
Thumbnail
31:01
354
359
410
Food energyComputer hardwareOpen sourceSoftwareRoboticsComputerWorkstation <Musikinstrument>AuthenticationStack (abstract data type)Computing platformArchitectureInterface (computing)Physical systemDigital rights managementHybrid computerModul <Datentyp>WhiteboardDevice driverData typeConfiguration spaceToken ringFunction (mathematics)Internet service providerModule (mathematics)Point cloudPower (physics)MetreNetwork topologyMathematical optimizationComplex (psychology)Distribution (mathematics)LastteilungLimit (category theory)Formal languageKeyboard shortcutSimulationLoop (music)Communications protocolJava appletScripting languageConnected spaceControl flowWellenwiderstand <Strömungsmechanik>BuildingGame controllerOpen setRevision controlCASE <Informatik>Computer fileQuantum stateOpen sourceSoftwareComputer hardwareWordProjective planeComputer scienceRoboticsModule (mathematics)Sinc functionPortable communications deviceWhiteboardRepository (publishing)UsabilityLetterpress printingRadio-frequency identificationConfiguration spaceExterior algebraFood energySpecial unitary groupMultiplication signPlastikkarteMobile appInterface (computing)Digital rights managementSpeichermodellComplex (psychology)Network topologyNormal (geometry)Chemical equationDistribution (mathematics)MetreUser interfacePower (physics)Game controllerWorkstation <Musikinstrument>Slide ruleReading (process)Computing platformDifferent (Kate Ryan album)CASE <Informatik>Open setPhysical systemLogicRevision controlStack (abstract data type)Hardware-in-the-loop simulationExecution unitComplete metric spaceFormal languageStructural loadComputer fileConnected spaceBootingCartesian coordinate systemOcean currentKeyboard shortcutDevice driverMechanism designInternet service providerAuthenticationComputer architectureTelecommunicationCommunications protocolPoint cloudScheduling (computing)MereologyVoltmeterSpacetimeSuite (music)Cycle (graph theory)MicrocontrollerResultantTrojanisches Pferd <Informatik>QuicksortState of matterCirclePresentation of a groupWebsiteLoop (music)Endliche ModelltheorieLatent heatTheory of relativityMusical ensemblePoint (geometry)Mathematical optimizationBitGoodness of fitMedical imagingMaterialization (paranormal)Sign (mathematics)Form (programming)Computer simulationMoment (mathematics)XMLComputer animation
Phase transitionWhiteboardWhiteboardDiagramRight angleSynchronizationPhase transitionPower (physics)Game controllerComputer hardwareBlock diagram
Module (mathematics)Control flowSynchronizationPhase transitionElectric currentOcean currentFrequencyWhiteboardoutputPower (physics)MetrePower (physics)MeasurementGame controllerMetreFrequencyWhiteboardPhase transitionPersonal identification numberLevel (video gaming)FirmwareSynchronizationConnected spaceVoltmeterMicrocontrollerWeb pageModule (mathematics)Function (mathematics)Forcing (mathematics)40 (number)Ocean currentFreewareAreaComputer animation
Game controllerFirmwareCodeWhiteboardGUI widgetPlastikkarteAsynchronous Transfer ModeControl flowLogicVirtual machineState of matterEvent horizonTransport Layer SecurityAddress spaceLocal ringLink (knot theory)Communications protocolStandard deviationUDP <Protokoll>TelecommunicationPower (physics)Computer networkModule (mathematics)Directed setBackupModemCAN busWireless LANModul <Datentyp>Client (computing)Web pageWhiteboardGame controllerPlastikkarteEndliche ModelltheorieCommunications protocolAsynchronous Transfer ModeLevel (video gaming)Data storage deviceQuicksortInformation and communications technologyConnected spaceExtreme programmingCycle (graph theory)DataflowComputer simulationReal-time operating systemBackupClient (computing)TelecommunicationPower (physics)Representation (politics)LogicWebsiteNumberEvent horizonTendonDigital photographyLattice (order)CASE <Informatik>State of matterStandard deviationPhysical system40 (number)SoftwareBlock diagramIP addressPressureFinite-state machineMicrocontrollerPersonal identification numberWireless LANModule (mathematics)Radio-frequency identificationModemCAN busComplete metric spaceCodeDean numberGreen's functionFirmwareFlash memoryAddress spaceLink (knot theory)Local ringStructural loadBinary codeComputer clusterBroadcasting (networking)Computer animation
Power (physics)Phase transitionControl flowWhiteboardData typeGame controllerImplementationPower (physics)Type theoryRight angleWhiteboardCommunications protocolProjective planeTelecommunicationCategory of beingWorkstation <Musikinstrument>Phase transitionWebsite
WhiteboardTelecommunicationReal numberCAN busTime evolutionSynchronizationLattice (order)Software developerCodeRepository (publishing)Computer hardwareElectronic mailing listWeb pageFood energyYouTubeLink (knot theory)FirmwareProjective planeEmailWeb pageElectronic mailing listYouTubeRow (database)CodeLattice (order)Right angleProper mapSoftware developerSynchronizationMultiplication signSpeichermodellLink (knot theory)TelecommunicationGoodness of fitSpring (hydrology)WebsiteCommunications protocolElectronic program guideSelf-organizationWhiteboardMicrocontrollerGame controllerLevel (video gaming)Food energyCASE <Informatik>Metropolitan area networkSuite (music)Computer animation
Point cloudProgram flowchart
Transcript: English(auto-generated)
Hello, my name is Kai and I'm going to talk to you about Everest AC and DC electric vehicle charging with open source software and hardware. First, a few words about myself. I have a background in computer science and robotics and I've been working at Pionix on the Everest project since early 2021.
So how do you actually charge a car? Most of you that have electric vehicles will probably be familiar with these methods, but I'm just going to recap them real quick so everybody is on the same baseline here.
You have your basic AC charging and you have a portable charger at home that you just plug into a wall socket or maybe even have a wall mounted charging station that can charge your car with up to 11 or 22 kilowatts. In public, you sometimes still see these slow AC chargers where you maybe even have to bring your own cable.
Just plug that one in, plug into your car, then you authorize with an RFID card or maybe even an app and then charging is properly built to your account. There's an alternative to that, which I would call the smart AC charging with ISO 15118 or maybe even
plug and charge, which is a much more secure way of authorizing your charging session with a backend provider. And what's probably for the crowd at this presentation, very interesting in the future, is the possibility to have bidirectional AC charging.
Think about vehicle to grid, vehicle to load scenarios where the car can be used maybe as a solar battery for your home that you can charge when the sun is shining, when energy is cheap and then you can use that energy in times where the grid is stressed a little bit.
And you want to reduce your demand on the electricity grid and then you might be able to just discharge your car and use your car as a battery for your home. Also, something that people will be most familiar with is the DC charging using the DIN spec and the ISO norm again.
These are usually the big highway fast chargers where you can charge with up to like 200-300 kilowatts. But there's also smaller units for the home. Think about DC-DC solar systems and things like that.
And also here, what's probably very exciting for all of you is upcoming bidirectional DC charging and taking energy back out of the car again. What is Everest? It's a complete software stack for EV charges. It runs on basically any embedded Linux platform out there.
It is released under the Apache 2.0 license and the aim is to support as many different hardware platforms as possible. In this talk, we're going to mostly focus on building our own charger with an open hardware design that I will present later on.
So some of the features that Everest has, it's built on a very modular architecture where different modules can do very specific things and then they can communicate over MQTT with each other. There is also a graphical setup web interface that you can use to configure different topologies of charges.
You can see some examples here on the slides and you can also use the same web interface to do energy management configuration as well. Next, I'm going to quickly go through the steps that you would have
to take to use this graphical web interface to configure your own charging station. First, we start with an EVSE manager. This is a module that owns a charging connector and takes care of the charging logic and the whole charging session handling and it orchestrates all the other modules access to this one connector.
Now we add a board support package, which in this case is the EAT driver module, which will handle all the control pilot handling, the access to the relays and the reading of, for example, the RCD currents.
Now we add an energy manager. This can be just a very simple configuration, a more advanced one I will show you in a few slides. Following that, we need an authentication mechanism. Here we add an authentication manager as
well as two token providers that we'll be able to authenticate our charging session with. In the next step, we can add some cloud connectivity. In this example, we add a OCPP 1.6 JSON module as well
as a power meter via Modbus and a system module that supports the rebooting and the firmware update of the charging station via OCPP. And in the last step, we add an API module so that external applications can
talk to the Everest system and read out some telemetry, but also control the charging session. As I mentioned before, you can use the same graphical configuration interface to also configure the energy management.
Here you can see a more complex energy distribution tree to be able to load balance multiple charging stations. Here we add an energy manager as a root node, add a 22 amp fuse to our grid connection.
And then as children of that fuse, we can add smaller fuses that then connect to the EVSE managers underneath it. And these EVSE managers now have different cars connected with different charging goals.
And the energy management system is able to schedule charging via a global optimizer so that every car gets the most optimal charging schedule assigned to it. Everest also comes with software and hardware-in-the-loop simulation facilities, and it implements
a lot of protocols that are relevant in the EV charging space at the moment, like OCPP 1.6 with 2.0.1 support coming very soon. We have support for ISO 15118 AC and DC for the DIN spec, for the basic PWM charging.
We also have the possibility to do communication with Modbus devices. Think about external power meters, for example, and also an API over MQTT where you can get some data about the charging session to maybe integrate into your home automation system. Everest itself is written in C++17, but there's also language bindings for Python and JavaScript available,
so you can write modules in all of these three languages, whichever suits your needs the most. So let's talk about the basic PWM charging.
The car and the charging station can communicate over the so-called control pilot signal. This is just a plus minus 12 volt signal where the car can lower the positive part of the signal by adding load resistors and a diode to lower this voltage to a specific voltage. For example, 9 volt signals that the car is connected, 6 volt means that the car actually wants to charge.
And the charging station then can use a PWM duty cycle to encode the available current for the car to draw. This is typically between 6 and 32 amps.
So how do you actually build one of these AC chargers? The good news is an AC charger is not a complicated battery charger. This part happens on the onboard charger in the car. The AC charger is just a smart relay. So what you typically only need is a power path, so a mains connection, some relays, an RCD for safety, optionally maybe a
power meter if you want to know how far your car has charged already, plus a microcontroller to interface with this control pilot signal. If you want to do some more advanced things, a Linux board is usually a good idea to have as well.
I'm now going to talk about our open hardware design that we've released, the YETI and the YAG boards. They are available under this GitHub repository and are released under the CERN open hardware license version 2 in the permissive flavor.
This hardware design has been developed to be as developer friendly as possible. So it includes a lot of features, but it's obviously not optimized for cost savings or ease of manufacturing in mind. But it has a lot of very exciting features so you can build all kinds of charging stations on top of these designs.
It's been designed in keycard 6 and case design files for 3D printing are also available. So let's talk about the first of these hardware designs, which is the YETI power board. It is a 22 kilowatt AC three phase power board.
Here on the low left, you can see a block diagram of this power board and on the right, some pictures of the upper and the lower side of the board. Let's talk about the features that the YETI board has.
It is capable of doing the control pilot signal generation as well as the control pilot signal sampling in sync with the PWM signal. It also has onboard relays for three phase power switching with welding detection and the three phase power metering support with up to 8 kilohertz of sampling.
There is the possibility to measure voltages, currents, power frequencies of all phases plus the neutral. There is an RCD module integrated, which can detect DC ground faults as well as AC faults and it can output the measured leakage current as telemetry.
There is also a 10 pin connector for a high level board to control the YETI board over UART. This is also then used to connect the YETI to our high level board design, which I will talk about later.
If you want to use the YETI as a standalone charger, which is totally possible, there is also an external connector for a small LCD. You can also add Modbus devices for external power meters. We have some external GPIOs on this board and the board itself can be powered just by the 110
or 230 volt mains connection with an internal power supply then, which is also capable of supplying the YAG board. But you can also connect an external 12 volt supply if you so choose. This board has also a lot of more features, which you can then just look up under this link.
The YETI comes with an STM32 microcontroller onboard and the firmware for this microcontroller is also available on our GitHub page. It's licensed under Apache 2.0 license and the purpose of this microcontroller firmware is that it can control
all the devices on the YETI board and all the electrical safety relevant code is encapsulated into that firmware. On top of that, it also does all of the communication of the YETI board over the UART using Protobuf with a high level communication board and then with the Everest software.
How do you use this YETI board? You can either use it as a standalone charger or you can use it as a power path for a smart charger. You can also configure it to do automatic switching between these modes in case the
higher level Linux board fails for some reason, you can still continue as a standalone charger. If you want to use the YETI board as a standalone charger, it is a complete AC charger for electric vehicles, supporting the basic charging I talked about earlier. This means it contains the complete charging load check that you need and a car will charge immediately when you connect it to the board.
There's also some UART connection that you can use to observe the status of the charging session and also to have limited control over the charging session such as pausing and resuming the charging.
This mode is what we call the high level control mode of the firmware. But you can also use the YETI board as a power path for a smart charger. Here you would then switch it into the so-called low level control mode just with a UART command and here you must provide the charging logic externally.
Only the basic state machine remains in the microcontroller, which is essential for electrical safety. An external board is then capable to set the PWM duty cycle and is able to read back the control pilot events.
And this is also the mode that Everest then uses to enable the so-called high level charging using ISO 15118 or the Dean spec. I will now explain what this high level charging mode is. It uses a power line communication on top of the control pilot PWM signal.
It literally uses the same wire using the home plug green fire standard. And the following steps need to be done to create a successful high level charging session. First, a logical network between the charger and the car is set up using Slack. Then IPv6 link local addresses are set up on both sides.
The car will then send a UDP broadcast to find the charger and the charger replies with its IP address and port number. A TCP TLS connection is then created from the car to the charger. And over that, the ISO 15118 protocol is then spoken, which is encoded in some XML data in a binary XML representation called XE.
Now I'm going to talk to you about the YACC high level control board. Here on the right side, you can see a few photos of one of these boards assembled. And on the left side, you see a block diagram of this high level control board.
This is used to run Everest on an embedded Linux system. Some of the features of this YACC control board is that it can receive a Raspberry Pi compute module 4. This is basically your system where you run your Linux on.
It has a 10 pin connector for a direct connection to the board, a real-time clock with a backup battery, a power line communications green-file modem for doing the high level charging communication with the car that I just talked about. There's also a UART and power connector populated for popular RFID modules.
And there's also RS-485 Modbus connectivity. You have a CAN bus available, you have Ethernet, wireless LAN, you have Bluetooth, USB ports. There's even a USB client port to be able to flash the flash storage of the compute module 4.
And of course, you have lots of external GPIOs to play with. Now we have everything that we need to put together a basic but also smart charging station.
So from right to left, you just need a mains free-phase power-in plug. You need one of these YETI power boards. Plug that in. On the other side, you plug in a type 2 connector to your car. If you then plug this into your car, you're already good to go.
And you will be able to charge your electric vehicle with up to 22 kilowatts if the vehicle supports it. If you want to do some more interesting things, like try out some of the smart charging protocols and maybe develop some interesting solutions on top of that.
You can add this high-level control board and then just start working on some interesting implementations. Another exciting project that we're working on right now is a DIY bidirectional DC charger.
If you've paid attention over the last couple of minutes, you will have noticed that the YAG board already comes prepared with everything that you would need for proper DC communication. Because the DC communication is done over the same control pilot wire using the high-level charging protocols.
And the only thing you really just need to build a proper DC charger is some power electronics and an isolation monitor and then you're pretty much good to go. Obviously, this is a lot more complicated and we're still hard at work for creating a good design here.
But you can definitely stay tuned for more coming in the spring or summer from us. If this was interesting for you, here's how you can get involved with the Avers project. You can check out our code on the GitHub organization. You can also check out the hardware designs and microcontroller firmware.
We do have a mailing list if you want to ask some questions. There's the project page on the Linux Foundation Energy website. We do have a quick start guide to help you get started with development. And on every first day of the month, there's a technical steering committee meeting
where we talk about what we implemented in the last weeks leading up to this technical steering committee meeting. It's always being announced via the mailing list and recordings are made available shortly after on YouTube. There's also a weekly developer sync meeting where you can join Avers developers,
ask questions and start contributing. This meeting happens every Tuesday between 10 and 11 a.m. Central European Time and the meeting link for that is sent out via our meetings. Thank you very much for listening and I'm open to receiving questions now.