- pyPLC in EvseMode runs together with the SmartEvse and fetches the SOC from the car before AC charging: https://github.com/SmartEVSE/SmartEVSE-3/issues/25. Thanks to arpiecodes, ArendJanKramer, fluppie and co for the contributions.
- pyPLC works as CCS-to-CHAdeMO bridge on johu's Touran: https://openinverter.org/forum/viewtopic.php?p=57908#p57908, https://www.youtube.com/watch?v=tfCaqdUFx3Q Congratulations and thanks for the excellent collaboration.
- celeron55 is on a 5000km road trip with the EVPrevia through Europe and uses pyPLC as the main charging solution. https://openinverter.org/forum/viewtopic.php?p=57940#p57940 and https://www.youtube.com/watch?v=bcMmEXSlFD8 Congratulations and enjoy the trip.
Main improvements between v0.8 and v0.9:
- Improved configuration file incl documentation
- EvseMode: Fix for using the correct SchemaID and checking for DIN protocol in the ProtocolHandshake
- PevMode: CHAdeMO integrated
- EvseMode: Sending SOC etc to the SmartEVSE via http
- PevMode: introduction of SafeShutdownSequence in case of errors. This makes sure, that the contactors are opened only if no current flows, and that the connector is unlocked only if the contactors are opened.
- PevMode: reaction on various error codes and status codes which are reported by the EVSE
- Testsuite: Automatic run of 16 [fault-injection-tests](doc/testing_and_simulation.md) and creation of a test report
- PevMode: Integration of celeron55's hardware interface
- PevMode: Startup scripts from celeron55 which create log file and pcap file per session (linux only)
- Helper: Take a pcap and show voltage, current and SOC in an oscillograph-like diagram (pcapConverter.py, scope.py) https://openinverter.org/forum/viewtopic.php?p=56459#p56459
Celeron55 is the winner. He managed to combine all the prerequisits, to have the world wide first pyPlc charging session. Congratulations and thanks for the great contribution. https://openinverter.org/forum/viewtopic.php?p=56188&sid=9579fd29268d0e332c81ed528f59f09b#p56188
### 2023-02-27 PEV mode with OLED-display works on headless Raspberry
- Charging status is shown on OLED display. Details in [hardware.md](doc/hardware.md)
- RaspberryPi 3 configured to auto-start the PEV software as service. Startup time around 21 seconds from power-up until the SLAC starts. Details
in [installation_on_raspberry.md](doc/installation_on_raspberry.md)
### 2022-12-21 v0.5 Light-bulb-demo-charging works on multiple chargers
- On 3 of 4 tested charger models, the light-bulb-demo works: AlpitronicHPC, ABB HPC, ABB Triple. The Ionity Tritium overshoots the target voltage due to missing load, and aborts.
- Welding detection gives negative or no answer.
- Traces https://github.com/uhi22/pyPLC/blob/master/results/2022-12-21_westpark_alpi_charge_ok_with_bulb.pcapng and https://github.com/uhi22/pyPLC/blob/master/results/2022-12-21_alpi_ABBHPC_ABB_Ionity_lightbulb_3of4ok.decoded.txt
- Pictures and discussion in https://openinverter.org/forum/viewtopic.php?p=50172#p50172
### 2022-12-20 Measurement of inlet voltage works
- Tests ran on Alpitronics HPC.
- Measuring the inlet voltage with Arduino "Dieter" works. During CableCheck and PreCharge, the inlet voltage is shown in the GUI.
- The Alpi confirms the PowerDelivery (start), but rejects the CurrentDemandRequest with FAILED_SequenceError and EVSE_Shutdown.
- Results (log file and pcap) are stored in https://github.com/uhi22/pyPLC/tree/master/results.
### 2022-12-13 v0.4 On Compleo, Light Bulb survives 400V cable check and PreCharge
- SLAC issue is fixed on Compleo. Authorization works. Hardware interface "Dieter" controls the CP into state C.
- The charger delivers power in the cable check, and a connected 230V bulb makes bright light and survives the 400V.
- PreCharge starts, but terminates before full voltage is reached. Switching the load with power-relay is not yet implemented from
hardware side. Without the load, we see the intended 230V precharge voltage, and run into timeout (to be investigated).
### 2022-12-02 v0.3 On Alpitonics until ChargeParameterDiscovery
- TCP connection works now on Alpitronics charger
- ContractAuthentication loop works
### 2022-11-25 v0.2 On ABB charger until ChargeParamDiscoveryRequest
- With Win10 notebook in PevMode, tested on Alpitronics HPC and ABB Triple charger. On the Alpi, the SLAC and SDP works. The TCP connection fails. On ABB, the SLAC, SDP and TCP works. Also the protocol negotiation works. We come until ChargeParamDiscoveryReqest.
- Log messages are sent via UDP port 514 as broadcast, like Syslog messages. The Wireshark shows them as readable text, so we have the actual communication between car and charger in the trace and also the debug log.
- Example pcap in results/2022-11-25_v0.2_ABB_until_ChargeParamDiscovery.pcapng
- With Win10 notebook in EvseMode, tested on the Ioniq car. It comes until the CurrentDemandRequest.
- For using Raspberry in PevMode without display, there is now the pevNoGui.py, which can be auto-started by configuring a service which calls starter.sh, and this calls starter.py (this is still expermental).
- The old Raspberry model B needs 90s from power-on until it sends the first log messages. Means, the boot is quite slow.
- Raspberry in PevMode and Win10 notebook in EvseMode work well together until the PreCharge.
- Known issues:
- The TCP port, which is announced in the SDP response, is ignored. This can be the root cause of failing TCP connection on Alpitronics.
- The SLAC timing includes too long wait times. This may be the root cause for failing SLAC on Supercharger and Compleo.
### 2022-11-15 [*PevMode*] Draft of SLAC sequencer
In PevMode, the software runs through the SLAC sequence with a simulated Evse. After SLAC is finished, we send a software
version request broadcast message, to find out, whether we have at least two homeplug modems in the network (one for the
car and one for the charger). If this is fulfilled, we should use the SDP to discover the chargers IPv6 address. But this
is not yet implemented.
### 2022-11-11 [*EvseMode*] Ioniq in the PreCharge loop
The EVSE state machine, together with the EXI decoder/encoder, is able to talk to the Ioniq car until the PreCharge loop. The
car terminates the loop after some seconds, because the intended voltage is not reached (no physical electricity connected to the
charge port). Maybe it is possible to convince the car to close the relay, just by pretending "voltage is reached" in the
PreCharge response. But maybe the car makes a plausibilization with the physical voltage, then further development would require
a physical power supply.
### 2022-11-09 [*EvseMode*][*PevMode*] Exi decoder first steps working
Using EXI decoder/encoder from basis https://github.com/Martin-P/OpenV2G and created fork https://github.com/uhi22/OpenV2Gx to
provide a command-line interface, which can be used by the python script. The OpenV2G includes generated source code for four
xml schemas (Handshake, DIN, ISO1, ISO2), provided by Siemens. Seems to be good maintained and is very efficient, because the
decoder/encoder are directly available as C code, dedicated for each schema. This skips the slow process of reading the schema,
parsing it, creating the grammer information. On Windows10 notebook, measured 15ms for decoder run from python via command line.
The OpenV2G was compiled on Windows10 using the included makefile, using the `mingw32-make all`.
The OpenV2G decoder/encoder code reveals some differences between the different schemas (DIN versus ISO). As starting point, only the
DIN schema is considered in the command line interface and python part.
The python part now contains the charging state machines for car and charger, as draft.
Using the TPlink and Win10 laptop as evse, connected to Ioniq car, the python script successfully succeeds to SLAC, TCP connection,
schema handshake, SessionSetup, ServiceDiscovery, ServicePaymentSelection. It stops on ChargeParameterDiscovery, most likely to
missing or wrong implementation. Results (log file and pcap) are stored in
As summary, the concept with the python script together with the compiled EXI decoder works. Further efforts can be spent on
completing the missing details of the V2G messages.
### 2022-10-26 [*ListenMode*] Network/AVLN is established
Using the TPlink in EVSE mode and Win10 laptop, listening to a communication setup between real car and real alpitronics charger, the python script
successfully extracts the NID and NMK from the SLAC_MATCH response, sets this information into the TPlink, and the TPlink turns three
LEDs on. Means: Network established. When we send a broadcast software version request, we get three responses: One from the TPlink, one from the
PLC modem of the car, and one from the PLC modem of the charger. This confirms, that the network is established.
But: From the higher level communication (IPv6, UDP, TCP) we see only the broadcast neighbor solicitation at the beginning. The remaining traffic
is hidden, most likely because the TPlink "too intelligent", it knows who has which MAC address and hides traffic which is not intended for the
third participant in the network. Trace in results/2022-10-26_WP4_networkEstablishedButHiddenCommunication.pcapng
### 2022-10-21 [*EvseMode*] SLAC, SDP and ICMP are working
Using the TPlink and Win10 laptop as evse, the python script runs successfully the SLAC and SDP (SECC discovery protocol). Afterwards, the car uses
neighbor solicitation (ICMP) to confirm the IPv6 address, and the Win10 responds to it. The car tries to open the TCP on port 15118, this is failing
because of missing implementation of the listener on PC side.
### 2022-10-19 [*ListenMode*] Sniffing mode not yet working with the TPlink adaptors
* with a Devolo dLAN 200 AVplus, software INT6000-MAC-4-4-4405-00-4497-20101201-FINAL-B in original parametrization, it is possible
to see the complete SLAC traffic (both directions) which sniffing the communication between a real charger and a real car. This does
NOT work with the TPlink adaptors. They route only "their own" direction of the traffic to the ethernet. Means: The pev-configured device
does not see the real car, and the evse-configured device does not see the real charger. This is bad for sniffing.
### 2022-10-19 [*EvseMode*] Communication/AVLN with Ioniq car established
* Using a TPlink TL-PA4010P with firmware MAC-QCA7420-1.4.0.20-00-20171027-CS and the PIB configuration file patched for evse according to the open-plc-utils docu.
* Python software running on Win10, Python 3.10.8
* On control pilot, sending 5% PWM to initiate digital communication with the car
* Since the TPlink is configured as coordinator, it sends "alive" messages, and the IONIQ starts sending the SLAC_PARAM.REQ.
* Per keystroke, we trigger a SET_KEY before the car is connected. The TPlink responds with "rejected", but this is normal, the LEDs are turning off and on, key is accepted.
* Python script interprets the relevant incoming messages (SLAC_PARAM.REQ, MNBC_SOUND.IND, SLAC_MATCH.REQ) and reacts accordingly.
* After successfull SLAC sequence, all three LEDs on the TPlink are ON, means: Network (AVLN) is established.
* In wireshark, we see that the car is sending UDP multicast messages to destination port 15118. This looks like a good sign, that it wants a ISO15118 compatible communication.
- Optional: Install the Plugin for Wireshark from https://github.com/geynis/v2g-ws-dissectors, to decode the V2GTP. This does NOT decode the EXI itself.
It is worth to read its documentation, starting in docbook/index.html, this contains all what we need for the next steps. A more detailled description and discussion is available in https://openinverter.org/forum/viewtopic.php?p=55120#p55120.
Clone the http://github.com/qca/open-plc-utils to your raspberry (or other linux computer).
Connect the homeplug modem using an ethernet cable to your raspberry.
Open a command shell on the raspberry.
The description below assumes that the homeplug modem is connected to the ethernet interface eth0. If on your setup you are using an different interface, replace the "eth0" in the commands by the appropriate interface name.
Patch the configuration file (see https://github.com/qca/open-plc-utils/blob/master/docbook/ch05s15.html). For each side (pev (vehicle) and evse (charger)) there is a special configuration.
This chapter describes the start of a charging session, considering all layers. The checkpoint numbers can be used as reference in code and in the log files.
(Todo: Only a few checkpoint numbers are referenced in the code. Adding more is work-in-progress.)
* Checkpoint7: The modem of the car sees homeplug coordinator packets on the CP. This is the precondition that it sends anything on HomePlug.
* Checkpoint100: The car starts the SLAC sequence by sending SLAC_PARAM.REQ. Can be also two times.
* Checkpoint101: The charger receives the SLAC_PARAM.REQ and confirms it with SLAC_PARAM.CNF.
* Checkpoint102: The car receives the SLAC_PARAM.CNF.
* Checkpoint103: The car sends START_ATTEN_CHAR.IND, to start the attenuation measurement. In total 3 times.
* Checkpoint104: The car sends MNBC_SOUND.IND, to provide different sounds (signals different frequency ranges). In total 10 times.
* Checkpoint110: The homeplug modem in the charger should measure the signal strength, and report the values to the SECC in an ethernet frame ATTEN_PROFILE.IND. However, the used homeplug adaptor with AR7420 seems not to support this feature. That's why we need to "guess" some attenuation values
* Checkpoint120: The charger sends ATTEN_CHAR.IND, which contains the number of sounds and for each group the attenuation in dB. Pitfall: The car may ignore
* Checkpoint140: The car sends ATTEN_CHAR.RSP to the charger which reported the loudest signals.
* Checkpoint150: The car sends SLAC_MATCH.REQ to the charger. This means, it wants to pair with it.
* Checkpoint155: The charger responds with SLAC_MATCH.CNF. This contains the self-decided NID (network ID) and NMK (network membership key).
* Checkpoint160: The car receives the SLAC_MATCH.CNF, takes the NID and NMK from this message.
* Checkpoint170: The car configures its homeplug modem with the received NID and NMK.
* Checkpoint180: The homeplug modem of the car makes a restart to apply the new settings. This takes approx five seconds. The LEDs of the modem are going off and on again during this restart.
* Checkpoint200: The car wants to know the chargers IP address. In computer networks, a DHCP would be a usual way to do this. In the CCS world, a different
approach is used: SDP, which is the SECC discovery protocol. The DHCP may be also supported as fallback. The car sends a broadcast message "Is here a charger in this network?". Technically, it is an IPv6.UDP.V2GTP.SDP message
* Checkpoint205: The charger responds to the neighbor solicitation request with a neighbor advertisement. This contains the MAC address of the charger.
* Checkpoint210: Now, the car and the charger have a clear view about addressing (MAC adresses, IPv6 addresses).
* Checkpoint300: The charger starts listening on the TCP port which it announced in the SDP response.
* Checkpoint301: The car requests to open a TCP connection to charger at the port which was announced on the SDP response. This may be 15118 or may be a different port, depending on the chargers implementation. Technically, this is a TCP message with SYN.
* Checkpoint302: The charger, which was listening on that port, confirms the TCP channel, by sending ACK+SYN.
* Checkpoint303: The car finishes the TCP connection setup by sending ACK. This is the end of the "three-way-handshake". TCP state machines on both sides are in state "ESTABLISHED". The car and the charger have a reliable, bidirectional TCP channel.
* Explanation: From now on, the car and the charger use the TCP channel, to exchange V2GTP messages, with EXI content. The charger is the "server" for the EXI, it is just waiting for requests from the car. The car is the "client", it actively
initiates the EXI data exchange. The car walks through different states to negotiate, start and supervise the charging process. From communication point of view, the complete process uses XML data, which is packed in EXI frames, which in turn are transported in the TCP channel mentioned above. The overview over
the exact schema is essential for the next step. The car announces the supported application protocols, e.g. DIN or ISO, using the SupportedApplicationProtocolRequest.
* Checkpoint401: The charger receives SupportedApplicationProtocolRequest and chooses the best application protocol from the list.
* Checkpoint402: The charger announces the decision with SupportedApplicationProtocolResponse.
* Checkpoint403: The car receives SupportedApplicationProtocolResponse and knows now, whether the charger supports a compatible XML schema.
* Checkpoint500: The car initiates the charging session with SessionSetupRequest. The SessionID in
* Checkpoint506: The car receives the SessionSetupResponse.
* Checkpoint510: The car sends ServiceDiscoveryRequest. Usually, this means it says "I want to charge" by setting serviceCathegory=EVCharging.
* Checkpoint515: The charger confirms with ServiceDiscoveryResponse. This contains the offered services and payment options. Usually it says which type
* Checkpoint520: The car sends ServicePaymentSelectionRequest. Usually (in non-plug-and-charge case), the car says "I cannot pay, something else should
* Checkpoint581: The car measures the voltage on the inlet and on the battery. Alternatively, the car does not measure the inlet voltage, and instead listens to the EVSEPresentVoltage which is reported by the charger.
* Checkpoint582: The above steps (PreChargeRequest, PreChargeResponse, measuring voltage) are repeating, while the
present voltage did not yet reach the target voltage.
* Checkpoint600: The car sends PowerDelivery(Start)Request.
* Checkpoint605: The charger confirms with PowerDeliveryResponse.
* Checkpoint700: The car sends CurrentDemandRequest (repeated while the charging is ongoing). In this message, the car tells the charger the target voltage and
* Checkpoint705: The charger confirms with CurrentDemandResponse. This contains the measured voltage, measured current, and flags which show which limitation
* Checkpoint790: When the user stops the charging session on the charger, the charger sends DC_EVSEStatus.EVSEStatusCode = 2 "EVSE_Shutdown" in the CurrentDemandResponse. (Observed on Compleo, see https://github.com/uhi22/Ioniq28Investigations/blob/main/CCM_ChargeControlModule_PLC_CCS/ccm_spi_ioniq_compleo_full_charge_sequence_ended_on_charger.txt.pcap.decoded.txt)
## Detailled investigation about the normal end of the charging session
### From Ioniq trace (https://raw.githubusercontent.com/uhi22/Ioniq28Investigations/main/CCM_ChargeControlModule_PLC_CCS/ccm_spi_ioniq_compleo_full_charge_sequence_ended_on_charger.txt.pcap.decoded.txt)
* User presses "Stop" at the charger
* [10.778] CurrentDemandRes.EVSEStatusCode = 2 EVSE_Shutdown. In the same message, the EVSEPresentCurrent is still 125A.
* After PowerDeliveryRes(Stop), the PEV shall send WeldingDetectionReq within V2G_EVCC_Sequence_Performance_Time (40s) (really: fourty seconds, Table 109).
* Figure 107: The PEV shall set stateB after receiving PowerDeliveryRes and before WeldingDetectionReq.
* The time from WeldingDetectionReq until WeldingDetectionResponse shall be below 1.5s, the timeout on PEV side 2s.
* If the EVSE receives WeldingDetectionReq or SessionStopReq, it shall check for StateB within 1.5s and shall respond "OK" within 1.5s if the StateB was seen, or "FAILED" if the stateB was not seen.
### Combined together
* User presses "Stop" at the charger
* [10.778] CurrentDemandRes.EVSEStatusCode = 2 EVSE_Shutdown. In the same message, the EVSEPresentCurrent is still 125A.
* [15.000] The car sees that the voltage is below dangerous level and unlocks the connector. (Better here than after SessionStopReq, because if the charger crashes and does not send a SessionStop, we should not been locked forever.)
### Q1: What is the minimal setup, to catch the MAC addresses in the communication between a real charger and a real car?
- Hardware: A TPlink TL-PA4010P homeplug adaptor, with the configuration for PEV. Modified according to the hardware manual https://github.com/uhi22/pyPLC/blob/master/doc/hardware.md
- Software: Wireshark. Only wireshark. (The pyPlc project and the exi decoder is NOT necessary to sniff the MAC addresses.)
### Q2: Is it possible to use this software, to make the car closing the relay, so that I'm able to draw energy out of the car?
Good question. This depends on how strict the car is. This first hurdle is to convince the car, to close the relay. This is
done after a successful PreCharge phase. And it depends on the implementation of the car, whether it needs physically correct
voltage on the inlet before closing the relay, or whether it relies on the pretended voltage in the PreChargeResponse message.
With setup from [EvseMode manual](docu/EvseMode.md),
the Hyundai Ioniq 2016 closes the contactors by just a simulated charging session. Discussion in https://openinverter.org/forum/viewtopic.php?t=3551, pictures here: https://openinverter.org/forum/viewtopic.php?p=55656#p55656
- This project is not a final product. Further development will be necessary to ensure compatibility with chargers, and make it flexible for practical use.
### Q5: What can be the reason, that the charger reports a failed cable check?
In the cable check phase, the charger checks the following things:
1. CP/PE lines. The charger expects "State C", this means, the car must connect a diode and two resistors between the CP and the PE. This shall result in PWM levels of -12V and +6V. The charger measures these level, and will complain with CableCheck=Failed if it detects a mismatch. Some potential root causes for failed checks are:
- CP is not connected at all.
- Diode is missing or has wrong polarity.
- Diode is too slow to handle the 1kHz/5%PWM.
- Wrong resistor values chosen or too high tolerance of the resistors
- Connection between circuit ground and PE missing
- too high saturation voltage of the switch transistor
- wrong coupling network between the CP/PE and the PLC modem transformator. This may disturb the PWM levels, due to low-pass-filtering or it may inject too much power from the PLC modem.
- Software not configured to use the correct output path for the StateC switching
2. Isolation of the DC path. It is recommended to use two contactors, one for each DC lines, to avoid asymmetrical results in the isolation measurements.
3. PP line: Some chargers (e.g. some of the Tesla Superchargers) are checking the voltage between the PP line and PE. The "official" recommendation seems to be to use on car side a pull-up of 330 ohm to 5V, and perhaps 3k pulldown to ground. Discussed here: https://openinverter.org/forum/viewtopic.php?p=67464#p67464 However, many chargers (e.g. alpitronics) seem not to care for the PP at all.
### Q7: The pyPLC seems to create json data by processing the hexadecimal data of receive data array, how does it do this?
The byte stream which is transferred via the homeplug physical layer runs to the following layers:
- Ethernet: contains the MAC addresses of the transmitter and receiver
- IPv6: contains the IP addresses and checksum
- TCP: assures reliable communication by checking the sequence counters and making retry in case of packet loss
- V2GTP: is just an additional protocol header to announce which data is transferrred
- EXI: converts between a byte stream and a structured message
The json data, which is mentioned in the question, is the output of the EXI decoder. The pyPLC uses the following approach for the exi decoder:
- The exi decoder was developed by Siemens and published here: http://openv2g.sourceforge.net/ This is pure C code, which is very fast, but also needs a lot of RAM and ROM space. It also has the drawback, that it will be not available for the latest updates of the ISO15118 (discussed here: https://openinverter.org/forum/viewtopic.php?p=54026#p54026). There are other exi solutions available, with are worst in terms of speed or availability (used in ref [v] and [vi]).
- The original Siemens code is mirrored into https://github.com/Martin-P/OpenV2G
- Since pyPLC is in python and cannot directly use the C code from Siemens, I added a command line interface to it. So python calls the compiled executable exi decoder, gives the input as command line parameter, and gets back the decoded message as standard output of the executable. This standard output is json-like. The extended OpenV2G has the name OpenV2Gx, and is available here: https://github.com/uhi22/OpenV2Gx. The readme contains examples how this can be used stand-alone for decoding and encoding exi message on command line.
Thanks to CCSknowitall for clarifying tricky details.
Thanks to celeron55 for the large number of test drives to various public chargers, and for improving the software. Thanks for helpful discussions to Pete9008, peternooy, tom91, asavage and all which I forgot to mention.
There are other projects around CCS charging. It's worth a look to the state and progress there.
### SwitchEV
- It is not clear, how they cope with the EXI decoder. In https://github.com/SwitchEV/iso15118/issues/157 it is confirmed
that the Java EXI codec is slow, and they announce a fast, Rust based codec in the Josev_pro variant. And they plan to
integrate https://github.com/chargebyte/openv2g (which is basically the same version 0.9.5 of the Siemens tool as https://github.com/Martin-P/OpenV2G ) for the community version. At the moment this sounds like "either pay or wait".
### EVEREST
- https://github.com/EVerest
- References https://github.com/EVerest/ext-switchev-iso15118. Not clear whether it uses the same Java EXI codec.
### SmartEVSE
- https://github.com/SmartEVSE/SmartEVSE-3/issues/25 discussion is ongoing, how to integrate the ISO high-level-communication
* [ii] https://openinverter.org/forum/viewtopic.php?p=37085#p37085 discussion of this project
* [iii] https://github.com/qca/open-plc-utils utilities for configuring the PLC adaptor
* [iv] https://github.com/karpierz/pcap-ct library for low-level-network-access
* [v] https://github.com/FlUxIuS/V2Gdecoder demo for EXI decoder
* [vi] https://github.com/SwitchEV/iso15118 another "nearly" open source CCS project
* [vii] https://books.google.de/books?id=WYlmEAAAQBAJ&pg=PA99&lpg=PA99&dq=%22ampsnif%22&source=bl&ots=hqCjdFooZ-&sig=ACfU3U0EleLZQu0zWhHQZGktp8OytCMrLg&hl=de&sa=X&ved=2ahUKEwjT0Yq88P36AhWj_rsIHeGMA5MQ6AF6BAgKEAM#v=onepage&q=%22ampsnif%22&f=false How to enable sniffer mode.
* [viii] https://www.mdpi.com/2076-3417/6/6/165/htm "Building an Interoperability Test System for Electric Vehicle Chargers Based on ISO/IEC 15118 and IEC 61850 Standards", including V2G message sequence chart
* [ix] https://www.oppcharge.org/dok/ISO_15118-2_OpportunityCharging_Rev1.3.0.pdf Pantograph specific differences with some insight into ISO15118.
* [x] https://assured-project.eu/storage/files/assured-10-interoperability-reference.pdf Fast and Smart Charging Solutions for
* [xi] https://morth.nic.in/sites/default/files/ASI/320201825106PMAIS_138_Part_2_F.pdf The Indian Fast Charging specification, seems to contain Chademo (Annex A, System A), an other "System B" in annex B, and CCS as "System C" in Annex C.
* [xii] User group which discusses the issues of the ISO15118. Link found on wikipedia article regarding Megawatt charging, https://de.wikipedia.org/wiki/Megawatt_Charging_System ref 5 https://www.elektroniknet.de/automotive/elektromobilitaet/smart-charging-grundlagen-und-herausforderungen.210253.html points to user group for developers https://iso15118.elaad.io/pt2/15118-20/user-group/ which is public.
* [xiii] The exi xml schema definitions, e.g. https://standards.iso.org/iso/15118/-20/ed-1/en/
* [xiv] exi encoders for ISO (din, 2, 20): https://github.com/tux-evse/iso15118-encoders?tab=readme-ov-file
* [xv] codec generator https://github.com/EVerest/cbexigen and the generated codec library https://github.com/EVerest/libcbv2g
