github-mirrors/pyPLC
1
0
Fork 0
mirror of https://github.com/uhi22/pyPLC.git synced 2024-11-20 01:13:58 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

extended session sequence description and linked reference

Browse source
This commit is contained in:
uhi22 2022-11-03 17:45:50 +01:00
parent 41d8c26be4
commit 35337c7c2a
1 changed files with 58 additions and 32 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

90
readme.md
View file

@ -17,6 +17,7 @@ In this project, we call this mode *ListenMode*.
* [v] https://github.com/FlUxIuS/V2Gdecoder * [v] https://github.com/FlUxIuS/V2Gdecoder
* [vi] https://github.com/SwitchEV/iso15118 * [vi] https://github.com/SwitchEV/iso15118
* [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. * [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
## Quick start / overview ## Quick start / overview
- Modify a PLC adaptor hardware, that it runs on battery - Modify a PLC adaptor hardware, that it runs on battery
@ -112,52 +113,77 @@ This chapter describes the start of a charging session, considering all layers.
Precondition: On charger side, there is a homeplugGP-capable device present, which is configured as CentralCoordinator. Precondition: On charger side, there is a homeplugGP-capable device present, which is configured as CentralCoordinator.
1. The charger (Supply entity communication controller, SECC) creates a "random" value for NID (network ID) and 1. The charger (Supply entity communication controller, SECC) creates a "random" value for NID (network ID) and
NMK (network membership key), and configures its homeplug modem with these values. NMK (network membership key), and configures its homeplug modem with these values.
1. The charger provides 12V on the control pilot (CP) line (State A). 2. The charger provides 12V on the control pilot (CP) line (State A).
1. The user connects the plug into the car. 3. The user connects the plug into the car.
2. The car pulls the 12V at CP line to 9V (State B). 4. The car pulls the 12V at CP line to 9V (State B).
3. The charger sees the level change on CP and applies 5% PWM on CP. 5. The charger sees the level change on CP and applies 5% PWM on CP.
4. The car sees the 5%, and interprets it as request for digital communication. It wakes up its communication controller (electric vehicle 6. The car sees the 5%, and interprets it as request for digital communication. It wakes up its communication controller (electric vehicle
communication controller, EVCC) and homeplug modem. communication controller, EVCC) and homeplug modem.
5. The car sees homeplug coordinator packets on the CP, and starts the SLAC sequence by sending SLAC_PARAM.REQ. Can be also two times. 7. The car sees homeplug coordinator packets on the CP, and starts the SLAC sequence by sending SLAC_PARAM.REQ. Can be also two times.
6. The charger receives the SLAC_PARAM.REQ and confirms it with SLAC_PARAM.CNF. 8. The charger receives the SLAC_PARAM.REQ and confirms it with SLAC_PARAM.CNF.
7. The car sends START_ATTEN_CHAR.IND, to start the attenuation measurement. In total 3 times. 9. The car sends START_ATTEN_CHAR.IND, to start the attenuation measurement. In total 3 times.
8. The car sends MNBC_SOUND.IND, to provide different sounds (signals different frequency ranges). In total 10 times. 10. The car sends MNBC_SOUND.IND, to provide different sounds (signals different frequency ranges). In total 10 times.
8. 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. 11. 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 However, the used homeplug adaptor with AR7420 seems not to support this feature. That's why we need to "guess" some attenuation values
for the next step. for the next step.
9. 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 12. 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
implausible values (e.g. all zero dB), and the process may be stuck. implausible values (e.g. all zero dB), and the process may be stuck.
10. The car receives the ATTEN_CHAR.IND. If it would receive multiple of them from different chargers (due to cross-coupling), the car 13. The car receives the ATTEN_CHAR.IND. If it would receive multiple of them from different chargers (due to cross-coupling), the car
decides based on the attenuation levels, which of the charges is the nearest. decides based on the attenuation levels, which of the charges is the nearest.
11. The car sends ATTEN_CHAR.RSP to the charger which reported the loudest signals. 14. The car sends ATTEN_CHAR.RSP to the charger which reported the loudest signals.
12. The car sends SLAC_MATCH.REQ to the charger. This means, it wants to pair with it. 15. The car sends SLAC_MATCH.REQ to the charger. This means, it wants to pair with it.
13. The charger responds with SLAC_MATCH.CNF. This contains the self-decided NID (network ID) and NMK (network membership key). 16. The charger responds with SLAC_MATCH.CNF. This contains the self-decided NID (network ID) and NMK (network membership key).
14. The car receives the SLAC_MATCH.CNF, takes the NID and NMK from this message, and configures its homeplug modem with this data. 17. The car receives the SLAC_MATCH.CNF, takes the NID and NMK from this message, and configures its homeplug modem with this data.
15. Now, the homeplug modems of the car and of the charger have formed a "private" Homeplug network (AV local network, AVLN). The RF 18. Now, the homeplug modems of the car and of the charger have formed a "private" Homeplug network (AV local network, AVLN). The RF
traffic can only be decoded by participants who are using the same NID and NMK. traffic can only be decoded by participants who are using the same NID and NMK.
16. 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 19. 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. approach is used: SDP, which is the SECC discovery protocol. The DHCP may be also supported as fallback.
17. The car sends a broadcast message "Is here a charger in this network?". Technically, it is an IPv6.UDP.V2GTP.SDP message 20. The car sends a broadcast message "Is here a charger in this network?". Technically, it is an IPv6.UDP.V2GTP.SDP message
with 2 bytes payload, which defines the security level expected by the car. In usual case, the car says "I want unprotected TCP.". with 2 bytes payload, which defines the security level expected by the car. In usual case, the car says "I want unprotected TCP.".
18. The charger receives the SDP request, and sends a SDP response "My IP address is xy, and I support unprotected TCP." 21. The charger receives the SDP request, and sends a SDP response "My IP address is xy, and I support unprotected TCP."
19. The car wants to make sure, that the IP addresses are unique and the relation between IP address and MAC address is clear. For 22. The car wants to make sure, that the IP addresses are unique and the relation between IP address and MAC address is clear. For
this, it sends a "Neighbour solicitation". (This looks a little bit oversized, because only two participants are in the local network, and this, it sends a "Neighbour solicitation". (This looks a little bit oversized, because only two participants are in the local network, and
their addresses have already been exchanged in the above steps. But ICMP is standard technology.) their addresses have already been exchanged in the above steps. But ICMP is standard technology.)
20. The charger responds to the neighbor solicitation request with a neighbor advertisement. This contains the MAC address of the charger. 23. The charger responds to the neighbor solicitation request with a neighbor advertisement. This contains the MAC address of the charger.
In the case, we use this pyPLC project as charger (*EvseMode*), we rely on the operating system that it covers the ICMP. On Win10, In the case, we use this pyPLC project as charger (*EvseMode*), we rely on the operating system that it covers the ICMP. On Win10,
this works perfectly, the only thing we must make sure, that the MAC and IPv6 of the ethernet port are correctly configured in the this works perfectly, the only thing we must make sure, that the MAC and IPv6 of the ethernet port are correctly configured in the
python script. Use `ipconfig -all` on Windows, to find out the addresses. python script. Use `ipconfig -all` on Windows, to find out the addresses.
21. Now, the car and the charger have a clear view about addressing (MAC adresses, IPv6 addresses). 24. Now, the car and the charger have a clear view about addressing (MAC adresses, IPv6 addresses).
22. The car requests to open a TCP connection to charger at port 15118. 25. The car requests to open a TCP connection to charger at port 15118.
23. The charger, which was listening on port 15118, confirms the TCP channel. (Todo: not yet implemented) 26. The charger, which was listening on port 15118, confirms the TCP channel. (Todo: not yet implemented)
24. Now, the car and the charger have a reliable, bidirectional TCP channel. 27. Now, the car and the charger have a reliable, bidirectional TCP channel.
25. The car and the charger use the TCP channel, to exchange V2GTP messages, with EXI content. 28. The car and the charger use the TCP channel, to exchange V2GTP messages, with EXI content.
26. The charger is the "server" for the EXI, it is just waiting for requests from the car. The car is the "client", it actively 29. 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. initiates the EXI data exchange.
27. The car walks through different states to negotiate, start and supervise the charging process. From communication point of view, 30. 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 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
28. Todo: Decribe the steps in detail. the various steps is visible in a sequence chart in [viii].
31. The car announces the supported application protocols, e.g. DIN or ISO, using the SupportedApplicationProtocolRequest.
32. The charger chooses the best application protocol from the list, and announces the decision with SupportedApplicationProtocolResponse.
33. The car initiates the charging session with SessionSetupRequest.
34. The charger confirms the session with SessionSetupResponse.
35. The car sends ServiceDiscoveryRequest.
36. The charger confirms with ServiceDiscoveryResponse.
37. The car sends PaymentServiceSelectionRequest.
38. The charger confirms with PaymentServiceSelectionResponse.
39. The car sends AuthorizationRequest.
40. The charger confirms with AuthorizationResponse.
41. The car sends ChargeParameterRequest.
42. The charger confirms with ChargeParameterResponse. Now, the initialization phase of the charging session is finished.
43. The car sends CableCheckRequest.
44. The charger confirms with CableCheckResponse.
45. The car sends PreChargeRequest.
46. The charger confirms with PreChargeResponse.
47. The car sends PowerDelivery(Start)Request.
48. The charger confirms with PowerDeliveryResponse.
49. The car sends CurrentDemandRequest (repeated while the charging is ongoing).
50. The charger confirms with CurrentDemandResponse.
51. The car sends PowerDelivery(Stop)Request.
52. The charger confirms with PowerDeliveryResponse.
53. The car sends WeldingDetectionRequest.
54. The charger confirms with WeldingDetectionResponse.
55. The car sends SessionStopRequest.
56. The charger confirms with SessionStopResponse.