This working group focusses on the communication between the charging station (EVerest) and the management system(s) (CPMS)
...
Meeting Notes:
23 October 2024: Cloud communication WG meeting
Participants:
Marc
MAaike
Mahdi
Martin
James
Tim (Host)
No new members present.
Dev Update:
#839 Configurable default limits for composite schedule calculation
Due to be included in release 2024.9.0 (due this week) - should be part of the EVerest September release
Shortly discussed the outcome of the F2F meeting (see notes below).
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.
Improve the callback for GetComposite schedule on start transaction. Current way it is implemented it could take 15 seconds before. It gets called after the transaction has started, but that can be "too slow".
AFS open PRs:
- Review work divided, no action needed at the moment.
- There is also a later PR for documentation: 836: added to the list
OCPP 2.1 Architecture meeting (22 October) agenda:
- Discussed the proposed agenda:
- Protocol version independent runtime initialization of ChargePoint
- Consolidate ChargePoint calss
- Documentation
- Priorities & Roadmap planning
- Optional/Extra discussions:
- Iterate / Clean up open Github issues
- Storage abstraction for internal database
- Single source storage abstraction for different OCPP protocol versions
9 October 2024 (Cloud Communication Call)
Last call with the AFS team
Development update:
- External Constrainse is in draft but ready.
- Documentation PR is also ready.
- PR open for Basic Auth issue during reconnect
Architecture:
- Good first online OCPP 2.0.1 & 2.1 architecture discussion.
- 1.6, 2.0.1 & 2.1 websocket handshake.
- Reuse 2.1 message model in 2.0.1
- Planning a architecture face-to-face on 22th of October in the The Netherlands, now checking for a location. More will follow when it becomes available.
Documentation generation:
- We have the option to generate libOCPP documentation using doxygen. Are these static pages available.
- Currently this documentation is not yet build and shared. Is a good idea to look into.
RUST Status:
- Currently possible to implement modules in RUST.
- OpenADR 3.0 is developed in RUST and will be integrated into EVerest soon
- For the local cost calculation in OCPP 2.1, RUST might be a good option.
9 October 2024 (OCPP 2.1 Architecture brainstorm)
1.1 Message Handling
* Question: Can we just use the OCPP2.1 message types in message handlers?
1.2 Schemas
* Contain some change in lengths of properties (e.g. exiResponse)
* Remarks to the draft can be added to public Excel sheet from the OCA
1.3 Other topics to discuss:
* Storage abstraction (Device Model + Internal Database)
* Switching between protocol versions at runtime
* Connectivity Management
* Simplifying the charge point interface to simplify adding more functional blocks
2.1 RPC Framework extensions
* SEND: unidirectional, no ack, outside of synchronous behavior of rpc framework
* CALLRESULTERROR: Only allowed in 2.1 not 2.0.1
2.2 Websocket Subprotocol
* WS handshake specifices the OCPP version to use, not the device model settings
3 Things to investigate
* How to deal with message fields that are longer in 2.1 than in 2.0.1. We can receive the longer messages but should we limit when sending and if so, how?
4 Preliminary design decisions
* Use OCPP2.1 message types in the implementation for both 2.0.1 and 2.1
* OCPPChargingStation base class required to do initial websocket handshake and select protocol version based on that
5 Migrating to another CSMS
* All transaction should have finished, then Reset
* If switching between protocol versions we might have issues with messages from another protocol version in the message queue: Empty message queue when switiching protocol versions?
* Document how a proper transition could look like (wipe data if required, stop running transactions, etc.)
6 Date for F2F
Focus on October 22nd and have 23rd spare
2 October 2024
Feature Freeze:
- Some issues found during testing.
- Second release candidate 2024.9.0-rc2 coming soon
Smart Charging:
- Last use cases will be finished before AFS work stops.
Roadmap:
- Discussed and updated roadmap
- Robert will put in new OCPP 2.1 features
25 September 2024
Feature freeze for 2024.9.0.
- rc1 is tagged
Open pull requests that need review:
- https://github.com/EVerest/libocpp/pull/789
- https://github.com/EVerest/libocpp/pull/790
California Pricing for OCPP 2.0.1 is done and merged
This also means Display Message and Tariff & Cost are also done.
Work is ongoing for Reservation without an EVSE ID.
Feedback from the plugfest:
- Some issues found
- Most are minor
- Some more serious
Unit tests are getting slow:
- Is on the list of AFS, each test spins up a queue, that can be mocked to improved unit test run speed.
Magic Numbers:
- There are magic numbers in libOCPP, also in smoe of the APIs. Can we change that to macros or defines or something.
Community does not seem enthousaistic. For now we leave it as is.
18 September 2024
Small group today: lot of OCPP developers are at the OCA Plugfest.
Deprecated functionality:
First time this is asked
C++ has feature for this: https://en.cppreference.com/w/cpp/language/attributes/deprecated
Gianfranco will try to write a proposal for the entire EVerest project for Deprecated features/functions etc. Maybe it can be presented during the TSC meeting next week.
Smart Charging Alignment: Nothing to align at the moment, work in progress
11 September 2024
Recordings:
...