Skip to content

metrics_pb2

frequenz.api.common.metrics_pb2 ¤

Generated protocol buffer code.

Classes¤

frequenz.api.common.metrics_pb2.Bounds ¤

Bases: Message

A set of lower and upper bounds for any metric. The units of the bounds are always the same as the related metric.

Source code in frequenz/api/common/metrics_pb2.py 
27
28
29
30
  _globals['_METRIC']._serialized_end=392
  _globals['_METRICAGGREGATION']._serialized_start=395
  _globals['_METRICAGGREGATION']._serialized_end=761
# @@protoc_insertion_point(module_scope)
Attributes¤
lower: builtins.float instance-attribute ¤

The lower bound.

upper: builtins.float instance-attribute ¤

The upper bound.

frequenz.api.common.metrics_pb2.Metric ¤

Bases: Message

A metric's value, with optional limits.

Attributes¤
component_bounds: global___Bounds property ¤

The current bounds of the metric, as imposed by the component this metric originates from.

rated_bounds: global___Bounds property ¤

The manufacturer's rated bounds of the metric. This may differ from system_bounds as it does not take into account the current state of the overall system.

system_exclusion_bounds: global___Bounds property ¤

These bounds indicate 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.

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 wil be rejected ==== vales here are allowed and will be accepted

system_inclusion_bounds: global___Bounds property ¤

These bounds indicate 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

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 wil be rejected ==== vales here are allowed and will be accepted

value: builtins.float instance-attribute ¤

The current value of the metric.

frequenz.api.common.metrics_pb2.MetricAggregation ¤

Bases: Message

Metrics depicted as a collection of statistical summaries.

Useful when a component has to report multiple values for the same metric. E.g., a battery is a collection of several blocks, and each block has a temperature sensor. The battery can report a summary of the values provided by all these sensors, like, min, max, avg, etc., and if possible, the entire array of temperature values.

Attributes¤
avg: builtins.float instance-attribute ¤

The average value of the metric.

component_bounds: global___Bounds property ¤

The current bounds of the metric, as imposed by the component this metric originates from.

max: builtins.float instance-attribute ¤

The maximum value of the metric.

min: builtins.float instance-attribute ¤

The minimum value of the metric.

rated_bounds: global___Bounds property ¤

The manufacturer's rated bounds of the metric. This may differ from system_bounds as it does not take into account the current state of the overall system.

raw_values: google.protobuf.internal.containers.RepeatedScalarFieldContainer[builtins.float] property ¤

The array of all the metric values.

system_exclusion_bounds: global___Bounds property ¤

These bounds indicate 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.

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 power 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 wil be rejected ==== vales here are allowed and will be accepted

system_inclusion_bounds: global___Bounds property ¤

These bounds indicate 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

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 power 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 wil be rejected ==== vales here are allowed and will be accepted