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

improved sequence description, updated change history

Browse source
This commit is contained in:
uhi22 2022-10-21 15:22:42 +02:00
parent 0b8cc4ba81
commit 346542cb52
1 changed files with 27 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

41
readme.md
View file

@ -104,18 +104,23 @@ 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.
1. The charger creates a "random" value for NID (network ID) and 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).
1. The user connects the plug into the car.
2. The car pulls the 12V at CP line to 9V.
3. The charger changes the CP from "permanent high" to "5% PWM".
4. The car wakes up its communication controller and homeplug modem.
5. The car sees coordinator packets on the line, and starts the SLAC sequence by sending SLAC_PARAM.REQ. Can be also two times.
2. 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.
4. The car sees the 5%, and interprets it as request for digital communication. It wakes up its communication controller 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.
6. 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.
8. The car sends MNBC_SOUND.IND, to provide different sounds. In total 10 times.
9. The charger sends ATTEN_CHAR.IND, which contains the number of sounds and for each group the attenuation in dB.
10. 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.
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.
However, the used homeplug adaptor seems not to support this feature. That's why we need to "guess" some attenuation values 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
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
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.
12. The car sends SLAC_MATCH.REQ to the charger. It wants to pair with it.
12. 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).
14. 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. The RF traffic can only be decoded by
@ -125,16 +130,20 @@ approach is used: SDP, which is the SECC discovery protocol. The DHCP may be als
17. 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.".
18. 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 is clear. For
this, it sends a "Neighbour solicitation". (This looks a little bit oversized, because only the participants are in the local network, but
it is standard technology.)
20. The charger responds to the neighbor solicitation request.
21. Now, the car and the charger have a clear view about addressing (MAC, IP).
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
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.)
20. 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, 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 python script.
21. Now, the car and the charger have a clear view about addressing (MAC, IPv6).
22. The car requests to open a TCP connection to chargerIP at port 15118.
23. The charger, which was listening on port 15118, confirms the TCP channel.
23. 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.
25. The car and the charger use the TCP channel, to exchange V2GTP messages, with EXI content.
26. Todo: Controlled by the content of the EXI messages, the car and the charging are walking through different states to negotiate, start and supervise the charging process.
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
initiates the EXI data exchange.
26. Todo: The car walks through different states to negotiate, start and supervise the charging process.
@ -157,5 +166,9 @@ to see the complete SLAC traffic (both directions) which sniffing the communicat
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-21 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.
(further steps ongoing)