Should bounds be aggregated to the most restrictive set possible?

[tiyash-basu-frequenz]

Currently, if the Microgrid API received multiple bounds, it will aggregate those to find the most conservative set possible. Usually, the core-apps set these bounds for power for components like inverters, batteries, and EV chargers. This has been designed like this to achieve safety, say, when the temperature of a battery is too high,and we want to limit the max current, or when more current will trigger an over-current warning in a battery.

Should we continue doing this? Or should we do the opposite, as in find the maximum possible range from all input bounds? Or just report all bounds as suggestions, and allow users to breach them at their own expense?

[tiyash-basu-frequenz]

This topic was discussed in a meeting, and the following points were mentioned:

• The SDK has it's own bounds, so users can interact with those directly. It is okay if the API bounds enforce safety.
• There is an aspect of DoS attacks in both scenarios:
  • If bounds are aggregated to be more conservative, then a bad actor could always set the bounds to (0, 0). This would prevent any activity in the targeted component (this could have impacts SoC-guard charging or DC heating).
  • If bounds are aggregated to be more accommodating, then a bad actor could set very large bounds, say (f32::MIN, f32::MIN). This could mean more errors, and more component-shutdowns in extreme situations.

There was no concrete opinion in the call, but it felt leaning more on the safety(conservative) side.

Note: It's impacts on SoC-guard charging or DC heating can be limited by tweaking the service.