This working group focusses on the communication between the charging station (EVerest) and the management system(s) (CPMS)
...
Meeting Notes:
22 October 2024: Face to Face meeting in Almere:
# Detailed agenda for Cloud WG F2F
1. Protocol version independent runtime initialization of ChargePoint
- Preparation: (UML) visualization (optionally for multiple options) (Marc + Piet)
- Consider switching protocol versions at runtime
2. Lunch
3. Consolidate ChargePoint class
- Goal: Unblow v201::ChargePoint class by moving functionality to new classes (e.g. separate by feature profiles, functional blocks)
- Preparation: How does a good development path look for this? How can we get started? (Kai)
4. Documentation
- Preparation: Present what and the structure of what is already there. Optionally already present how we can improve that (Maaike)
- Consider different protocol versions
- Generation of configuration keys / variables documentation
5. Priorities & Roadmap planning
- Goal: Agree on short term next steps and priorities
- Nothing to prepare
6. Optional discussions (if we find the time)
- Iterate / Clean up open Github issues
- Storage abstraction for internal database: https://github.com/EVerest/libocpp/issues/832
- Single source storage abstraction for different OCPP protocol versions (might overlap with point 1 anyways)
7. Diner!
## Runtime Protocol Initialization
### Runtime Switching design:
* We want to have a fallback in case the CSMS is not able the handle multiple OCPP versions in the HTTP websocket handshake --> We want to use the OCPPVersion specified in the NetworkConnectionProfile in that case
* We are in favor of using the facade pattern with one single interface to the core for all OCPP versions (long term plan)
* We consider starting using that pattern only for OCPP2.0.1 and 2.1 and leave 1.6 as is for now (since its just faster)
* We want to get started with the common ocpp interface as fast as possible because it allows the integration of OCPP1.6 and we can integrate OCPP2.1 as well already
* We think the OCPP2.0.1/2.1 implementation should directly implement the common ocpp interface
* We need to factor out the ConnectivityManager from the ChargePoint classes
* If there has never been a connection with a CSMS, we specify an expected version as part of the NetworkConnectionProfile and use the offline behavior / messages of that version. If it turns out that the CSMS is using another version, we drop all transaction data
* We can make use of the strategy pattern to wrap the current 1.6 and 2.0.1 implementations
### Issues & Risks for protocol switching at runtime
* Hard to identify potential issues in common ocpp interface when moving to OCPP1.6
* Switching protocols at runtime leads to issues with Storage and MessageQueue
* In an offline case without knowing which ocpp version will be used: We can not yet queue messages yet, because we dont know the protocol version
* Clarify B 1.1. Transactions before being accepted by a CSMS with OCA
* Question to OCA: What do we do with transaction data in persistent storage when switching version
Topics discussed but not needed yet:
* When a connection drops, we might want to reconnect and only allow connection with that same OCPP version for the first few retries. For now we probably don't need it since CSMSs won't switch protocols often.
### Decisions:
* We dont want to support runtime switching between major OCPP versions (OCPP1.6 <-> OCPP2.0.1/2.1)
* Reasons:
* Removes a LOT of complexity for the implementation (transaction handling, storage issues, etc.)
* In the real world, a charging station is configured to use either 1.6 or 2.0.1 or 2.1 . CSMS will probably not make use of that websocket handshake protocol switching anyways.
## Consolidate ChargePoint class
### Notes
* Use ChargePoint Interface header to include by the user
* Goal: Allows for easier testing
### Decisions
* We want to have seperate classes for every functional block of OCPP2.0.1
* These classes will be members of the charge point class
* The testability of the classes should be taken into consideration
* Every class implementing a functional block requires some shared functionality
* handle_message (for the responsibilities of the functional block)
* device_model
* message_queue / sending messages
* maybe: evse_manager etc.
- [ ] 1-2 people to prepare class diagrams / block diagrams for the class structure for functional blocks
- [ ] Implement test cases for a functional block in the new design
This is our last state:
```plantuml
@startuml
class ChargePoint
class Security implements ISecurity
class Provisioning implements IProvisioning
class FunctionalBlock
interface ICommon {
+handle_message()
+all_callbacks_implemented()
}
interface ISecurity implements ICommon
interface IProvisioning implements ICommon
ChargePoint --* ISecurity
ChargePoint --* IProvisioning
Security : -&FunctionalBlock
FunctionalBlock : -&MessageQueue
FunctionalBlock : +&EvseManager
FunctionalBlock : +send()
IProvisioning : +boot_notification_req()
Provisioning : -&FunctionalBlock
Provisioning : -handle_set_variable_req()
@enduml
```
## Documentation
### Notes
* Present documentation
* README
* docs/
* inline documentation
* Possibility to make use of doxygen features a little bit more (e.g. groups)
* We should seperate between developer documentation and user documentation
* Would be nice to have doc files linked in the rendered doxygen
* We find its important to emphasize documenting the usage of libocpp
* Host the doxygen at everest.github.io
* split up docs/ folder into docs/v16/ docs/v201/ and docs/common or docs/general
* Using mermaid instead of plantuml because in renders in github
README:
* Generic introduction
* Supported functionality / feature profiles
* CSMS compatability
* Integration in EVerest
* Integrate this library --> Move out of README or short summary
* Install libocpp -> Remove and add Requirements for the library; Building and installing should be moved to developer documentation
* Quickstart --> Move out of README and link to EVerest SIL
* Building doxygen documentation
* Unit testing: Remove and move to developer documentation
* Building with FetchContent: Move to developer documentation
* Support for security profile 2 and 3 with TPM: Move to developer documentation
Developer Getting started guide (GETTING_STARTED.md)
* Building & Installing
* Unit Testing
* How to integrate (in more detail, link to doxygen docs)
* Building with FetchContent
* Support for security profile 2 and 3 with TPM
- [ ] Split up docs/ folder into docs/v16/ docs/v201/ and docs/common or docs/general
- [ ] Close AFS Docs PR and take only useful parts of it
- [ ] Consolidate README file using the details above
- [ ] Set up getting started guide for developers (Use what has been removed from the README and put everything into one document and link it)
- [ ] Generate configuration key documentation for OCPP1.6
- [ ] Generate component config documentation for OCPP2.0.1 (probably including a refactoring of the component config JSON structure)
- [ ] Hosted version of doxygen (including the docs/ folder)
- [ ] PR for doxygen Topics (Maaike)
### Autogenerate Configuration Key and Variable documentation
* Autogenerate for OCPP1.6 using profile JSON schemas
* Autogenerate for OCPP2.0.1 using component config
### Questions
* Can we host the documentation on everest.github.io ?
## Priorities and Roadmap planning
* Convert findings and action items into Github Issues for each topic
* Getting started with consolidating charge point
* [ ] 1-2 people to prepare class diagrams / block diagrams for the class structure for functional blocks (Kai/Piet due October 30)
* [ ] Implement the design we agreed on for one functional block (Kai/Piet due November 13)
* [ ] Following: Implement test cases for a functional block in the new design
* Get the design in place so it can be used
* Do functional block by functional block
* Moving forward with 2.1:
* [ ] Rip out websocketpp (Ioan)
* [ ] Generate OCPP2.1 messages and compile libocpp with it (Kai)
* for testing https://github.com/mobilityhouse/ocpp/tree/448-ocpp-21 has code generation capabilities for Python (to be used with https://github.com/EVerest/ocpp-csms)
* [ ] Implement 2.1 as part of connectivity manager (Marc/Wilco) --> Seperate PR from 769.
* Close out OCPP2.0.1
* But we can still keep a few things open
* Documentation (1-2 Github issue for all of that) (Piet)
- [ ] Split up docs/ folder into docs/v16/ docs/v201/ and docs/common or docs/general
- [ ] Close AFS Docs PR and take only useful parts of it
- [ ] Consolidate README file using the details above
- [ ] Set up getting started guide for developers (Use what has been removed from the README and put everything into one document and link it)
- [ ] Generate configuration key documentation for OCPP1.6
- [ ] Generate component config documentation for OCPP2.0.1 (probably including a refactoring of the component config JSON structure)
- [ ] Hosted version of doxygen (including the docs/ folder)
- [ ] PR for doxygen Topics (Maaike)
16 October 2024:
PR 837: https://github.com/EVerest/libocpp/pull/837
- There seems to be a mix up between ChargingProfilePurpose and ChargingProfileKind. It should have been a check for Purpose, not kind in this case.
...