mirror of
https://github.com/uhi22/pyPLC.git
synced 2024-11-20 01:13:58 +00:00
readme clean-up
This commit is contained in:
parent
12ed9f1a7c
commit
6bdca0f93e
1 changed files with 25 additions and 19 deletions
44
readme.md
44
readme.md
|
@ -110,18 +110,21 @@ Pcap-ct does not work with Python 3.4. After update to Python 3.8, it works.
|
|||
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 (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.
|
||||
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 (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.
|
||||
4. 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.
|
||||
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.
|
||||
8. 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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
@ -130,8 +133,8 @@ decides based on the attenuation levels, which of the charges is the nearest.
|
|||
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
|
||||
participants who are using the same NID and NMK.
|
||||
15. 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.
|
||||
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
|
||||
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
|
||||
|
@ -141,45 +144,47 @@ with 2 bytes payload, which defines the security level expected by the car. In u
|
|||
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. Use
|
||||
`ipconfig -all` on Windows, to find out the addresses.
|
||||
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.
|
||||
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
|
||||
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).
|
||||
22. 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)
|
||||
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. 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.
|
||||
27. 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.
|
||||
28. Todo: Decribe the steps in detail.
|
||||
|
||||
|
||||
|
||||
|
||||
## Change history / functional status
|
||||
### 2022-10-19 Communication with Ioniq car established
|
||||
### 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 is established.
|
||||
* 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.
|
||||
![image](https://user-images.githubusercontent.com/98478946/196766285-1c3152f7-31db-4b5f-98b1-9f1216f9b9de.png)
|
||||
|
||||
### 2022-10-19 Sniffing mode not yet working with the TPlink adaptors
|
||||
### 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-21 SLAC, SDP and ICMP are working
|
||||
### 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-26 Network is established in sniffer mode
|
||||
### 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, 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
|
||||
|
@ -189,7 +194,7 @@ is hidden, most likely because the TPlink "too intelligent", it knows who has wh
|
|||
third participant in the network. Trace in results/2022-10-26_WP4_networkEstablishedButHiddenCommunication.pcapng
|
||||
|
||||
## Biggest Challenges
|
||||
- [ListenMode] Find a way to enable the sniffer mode or monitor mode in the AR7420. Seems to be not included in the public qca/open-plc-utils.
|
||||
- [*ListenMode*] Find a way to enable the sniffer mode or monitor mode in the AR7420. Seems to be not included in the public qca/open-plc-utils.
|
||||
Without this mode, we see only the broadcase messages, not the TCP / UDP traffic between the EVSE and the PEV. Any idea how to enable full-transparency
|
||||
of the QCA?
|
||||
- [all modes] convert the EXI data to the readable xml (e.g. using https://github.com/FlUxIuS/V2Gdecoder, or https://github.com/Martin-P/OpenV2G).
|
||||
|
@ -197,6 +202,7 @@ Evaluate different EXI decoders/encoders, regarding speed, correctness and stabi
|
|||
- [all modes] replace the fix-configured addresses (MAC, IP) in the python script by the real one from the operating system
|
||||
|
||||
## Other open topics
|
||||
- [EvseMode] Add listener to socket at port 15118
|
||||
- [*EvseMode*] Add listener to socket at port 15118
|
||||
- [*PevMode*] Testing
|
||||
- improve docu (update layer diagram, improve hardware docu, add link to evse which provides the 5% PWM)
|
||||
- (and much more)
|
||||
|
|
Loading…
Reference in a new issue