mirror of
https://github.com/uhi22/pyPLC.git
synced 2024-11-10 01:05:42 +00:00
improved sequence description, updated change history
This commit is contained in:
parent
0b8cc4ba81
commit
346542cb52
1 changed files with 27 additions and 14 deletions
41
readme.md
41
readme.md
|
@ -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)
|
||||
|
|
Loading…
Reference in a new issue