Skip to content

Commit

Permalink
Remove RPCs AddComponent[Exclusion|Inclusion]Bounds
Browse files Browse the repository at this point in the history 
These RPCs are not required anymore, sice the addition of RPC
`AddComponentBounds`.

Signed-off-by: Tiyash Basu <tiyash.basu@frequenz.com>
  • Loading branch information
@tiyash-basu-frequenz
tiyash-basu-frequenz committed Mar 27, 2024
1 parent ef9979f commit fb4db18
Show file tree
Hide file tree
Showing 2 changed files with 2 additions and 124 deletions.
3 changes: 2 additions & 1 deletion RELEASE_NOTES.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,8 @@
of `frequenz-api-common` for more information.

- A new RPC named `AddComponentBounds` has been introduced, which accepts only
inclusive bounds.
inclusive bounds. The old RPCs `AddComponentInclusionBounds` and
`AddComponentExclusionBounds` have been removed.

<!-- Here goes notes on how to upgrade from previous versions, including deprecations and what they should be replaced with -->

Expand Down
123 changes: 0 additions & 123 deletions proto/frequenz/api/microgrid/v1/microgrid.proto
View file
Original file line number Diff line number Diff line change
Expand Up @@ -161,93 +161,6 @@ service Microgrid {
rpc AddComponentBounds(AddComponentBoundsRequest)
returns (AddComponentBoundsResponse);

// Adds exclusion bounds for a given metric of a given component, and returns
// the UTC timestamp until which the given exclusion bounds will stay in
// effect.
//
// Exclusion bounds refer to the range of values that are disallowed for the
// metric. If these bounds for a metric are [`lower`, `upper`], then this
// metric's `value` needs to comply with the constraints
// `value <= lower` OR `upper <= value`.
//
// Exclusion bounds are a useful tool for enhancing the performance of a
// system. They can be used to restrict the acceptance of commands that fall
// below a certain threshold, which can help ensure the smooth functioning of
// the system.
// E.g., exclusion bounds can be set to limit the minimum charging power to a
// sufficiently high level, preventing a peak-shaver client from sending
// charge powers that are too low when a DC heater client is executing a
// charge pulse. This can significantly improve the overall performance of the
// DC heating mechanism.
//
//
// If multiple exclusion bounds have been provided bor a metric, then the
// aggregated lower and upper exclusion bounds are calculated as follows:
// lower: the minimum of all lower exclusion bounds
// upper: the maximum of all upper exclusion bounds
//
// It is important to note that these bounds work together with
// `system_inclusion_bounds`.
//
// E.g., for the system to accept a charge command,
// clients need to request power values within the bounds
// `[system_inclusion_bounds.lower, system_exclusion_bounds.lower]`.
// This means that clients can only request charge commands with values that
// are within the `system_inclusion_bounds`, but not within
// `system_exclusion_bounds`.
// Similarly, for the system to accept a discharge command,
// clients need to request power values within the bounds
// `[system_exclusion_bounds.upper, system_inclusion_bounds.upper]`.
//
// The following diagram illustrates the relationship between the bounds.
// ```
// inclusion.lower inclusion.upper
// <-------|============|------------------|============|--------->
// exclusion.lower exclusion.upper
// ```
// ---- values here are disallowed and will be rejected
// ==== vales here are allowed and will be accepted
rpc AddComponentExclusionBounds(AddComponentExclusionBoundsRequest)
returns (AddComponentExclusionBoundsResponse);

// Adds inclusion bounds for a given metric of a given component, and returns
// the UTC timestamp until which the given inclusion bounds will stay in
// effect.
//
// Inclusion bounds refer to the range of values that are allowed for the
// metric. If these bounds for a metric are [`lower`, `upper`], then this
// metric's `value` needs to comply with the constraint
// `lower <= value <= upper`.
//
// If multiple inclusion bounds have been provided bor a metric, then the
// aggregated lower and upper inclusion bounds are calculated as follows:
// lower: the maximum of all lower inclusion bounds
// upper: the minimum of all upper inclusion bounds
//
// It is important to note that these bounds work together with
// `system_exclusion_bounds`.
//
// E.g., for the system to accept a charge command,
// clients need to request power values within the bounds
// `[system_inclusion_bounds.lower, system_exclusion_bounds.lower]`.
// This means that clients can only request charge commands with values that
// are within the `system_inclusion_bounds`, but not within
// `system_exclusion_bounds`.
// Similarly, for the system to accept a discharge command,
// clients need to request power values within the bounds
// `[system_exclusion_bounds.upper, system_inclusion_bounds.upper]`.
//
// The following diagram illustrates the relationship between the bounds.
// ```
// inclusion.lower inclusion.upper
// <-------|============|------------------|============|--------->
// exclusion.lower exclusion.upper
// ```
// ---- values here are disallowed and will be rejected
// ==== vales here are allowed and will be accepted
rpc AddComponentInclusionBounds(AddComponentInclusionBoundsRequest)
returns (AddComponentInclusionBoundsResponse);

// Sets the active power output of a component with a given ID, provided the
// component supports it. The power output is specified in watts.
//
Expand Down Expand Up @@ -559,42 +472,6 @@ message AddComponentBoundsResponse {
google.protobuf.Timestamp ts = 1;
}

// Request parameters for the RPC `AddComponentExclusionBounds`.
message AddComponentExclusionBoundsRequest {
// The ID of the target component.
uint64 component_id = 1;

// The target metric whose bounds have to be set.
ComponentBoundsTargetMetric target_metric = 2;

// The bounds for the target metric.
frequenz.api.common.v1.metrics.Bounds bounds = 3;
}

// Response message for the RPC `AddComponentExclusionBounds`.
message AddComponentExclusionBoundsResponse {
// The timestamp until which the given exclusion bounds will stay in effect.
google.protobuf.Timestamp ts = 1;
}

// Request parameters for the RPC `AddComponentInclusionBounds`.
message AddComponentInclusionBoundsRequest {
// The ID of the target component.
uint64 component_id = 1;

// The target metric whose bounds have to be set.
ComponentBoundsTargetMetric target_metric = 2;

// The bounds for the target metric.
frequenz.api.common.v1.metrics.Bounds bounds = 3;
}

// Response message for the RPC `AddComponentInclusionBounds`.
message AddComponentInclusionBoundsResponse {
// The timestamp until which the given inclusion bounds will stay in effect.
google.protobuf.Timestamp ts = 1;
}

// Request parameters for the RPC `SetComponentPowerActive`.
message SetComponentPowerActiveRequest {
// The ID of the component to set the output active power of.
Expand Down

0 comments on commit fb4db18

Please sign in to comment.