Support OCPP 2.1 variables

[maaikez]

Describe your changes

Add support for OCPP 2.1 variables and add check for required variables in device model.

Issue ticket number and link

Checklist before requesting a review

• I have performed a self-review of my code
• I have made corresponding changes to the documentation
• [n/a] If OCPP 2.0.1: I have updated the OCPP 2.0.1 status document
• I read the contribution documentation and made sure that my changes meet its requirements

[Pietfried]

One general issue I see with this change is that you can now define device models that are valid according to the new integrity check but could lead to unhandled exceptions at runtime. Lets have a look at an example.

AlignedDataCtrlr.AlignedDataTxEndedInterval is only required if AlignedDataCtrlr.Available is true. So you can define a device model that doenst contain AlignedDataCtrlr.AlignedDataTxEndedInterval. In the code, we just access AlignedDataCtrlr.AlignedDataTxEndedInterval using this->device_model.get_value<int>(ControllerComponentVariables::AlignedDataTxEndedInterval). This leads to an unhandled exception.

I see three options:

1. Define every variable that is required only if the Available variable of the Controller is present and true as a ComponentVariable and not a RequiredComponentVariable. This avoids the option to use get_value and forces us to use get_optional_value instead.
   This is the safest option, but it leads to quite some changes in code.

2. Keep defining these variables as RequiredComponentVariable and use get_value but make sure everywhere where it is called that the Available variable is checked.
   Requires fewer changes than 1) but we can still crash at runtime

3. We could enforce that more controllers are required than in the specification. This is also how the code was written (if the spec says a variable is required we require it, no matter what value Available of the Controller has. Libocpp does support the AlignedDataCtrlr features, so it must also be present. Same is true for SampledDataCtrlr so we can enforce that they are present and available. LocalAuthListCtrlr, SmartChargingCtrlr, TariffCostCtrlr, MonitoringCtrlr and DisplayMessageCtrlr I would consider optional and we could then go with option 2).
   Only few changes in existing code. We still need to protect code blocks where variables are accessed directly using get_value. The introduction of the functional blocks should make this easier though.

Interested in your thoughts @maaikez and @marcemmers .

[Pietfried]

This file is auto-generated. You either need to define this elsewhere or adjust the jinja template in https://github.com/EVerest/libocpp/blob/main/src/code_generator/common/templates/ocpp_types.hpp.jinja . I would prefer to move the definition into the device_model.hpp and therefore remove it from the jinja template

[maaikez]

Hmm there will be a circular dependency then (DeviceModel <-> CtrlrComponentVariables).
Why not add it in CtrlrComponentVariables?

[Pietfried]

I would add a comment here with the reason why its empty

[Pietfried]

nit: test_allow_zero2 defined before test_allow_zero looks a little bit odd. A name like test_min_limit_and_allow_zero is probably better

[maaikez]

One general issue I see with this change is that you can now define device models that are valid according to the new integrity check but could lead to unhandled exceptions at runtime. Lets have a look at an example.

...

I see three options:

...

2. Keep defining these variables as `RequiredComponentVariable` and use `get_value` but make sure everywhere where it is called that the `Available` variable is checked.
   Requires fewer changes than 1) but we can still crash at runtime

3. We could enforce that more controllers are required than in the specification. This is also how the code was written (if the spec says a variable is required we require it, no matter what value `Available` of the Controller has. Libocpp does support the `AlignedDataCtrlr` features, so it must also be present. Same is true for `SampledDataCtrlr` so we can enforce that they are present and available. `LocalAuthListCtrlr`, `SmartChargingCtrlr`, `TariffCostCtrlr`, `MonitoringCtrlr` and `DisplayMessageCtrlr` I would consider optional and we could then go with option 2).
   Only few changes in existing code. We still need to protect code blocks where variables are accessed directly using `get_value`. The introduction of the functional blocks should make this easier though.

Interested in your thoughts @maaikez and @marcemmers .

I would say 3 (in combination with 2). This is the way libocpp is written so we should just make the components available that we depend on. I also see no use in making them optional (AlignedDataCtrlr and SampledDataCtrlr).

[Pietfried]

• clang format is still failing
• I'd suggest to catch DeviceModelError here for all incoming messages from the CSMS https://github.com/EVerest/libocpp/blob/main/lib/ocpp/v201/charge_point.cpp#L772

[Pietfried]

Just noticed that this has been already merged, Im still submitting the comments so we could add them later

[Pietfried]

Suggested change

	one of the required Variables is not there.
	one of the required Variables is not present.

[Pietfried]

Suggested change

	There are some Components that are always required because that is how libocpp works: `AlignedDataCtrlr` and
	There are some Components that are always required because they are required by libocpp: `AlignedDataCtrlr` and

[Pietfried]

Suggested change

	There are some required Variables, which can be found in the OCPP spec.
	There are Variables that are defined as **required** in the OCPP specification.

[Pietfried]

Suggested change

	Some `Variables` are only required if the `Component` is `Available`, for example `Reservation` and `Smart Charging`.
	Some `Variables` are only required if the `Available` variable of the respective `Component` is present and configured to true. Examples for this are the `ReservationCtrlr` and the `SmartChargingCtrlr`.