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 
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
_sym_db = _symbol_database.Default()




DESCRIPTOR = _descriptor_pool.Default().AddSerializedFile(b'\n!frequenz/api/common/metrics.proto\x12\x1b\x66requenz.api.common.metrics\"&\n\x06\x42ounds\x12\r\n\x05lower\x18\x01 \x01(\x02\x12\r\n\x05upper\x18\x02 \x01(\x02\"\x9d\x02\n\x06Metric\x12\r\n\x05value\x18\x01 \x01(\x02\x12\x39\n\x0crated_bounds\x18\x02 \x01(\x0b\x32#.frequenz.api.common.metrics.Bounds\x12=\n\x10\x63omponent_bounds\x18\x03 \x01(\x0b\x32#.frequenz.api.common.metrics.Bounds\x12\x44\n\x17system_exclusion_bounds\x18\x04 \x01(\x0b\x32#.frequenz.api.common.metrics.Bounds\x12\x44\n\x17system_inclusion_bounds\x18\x05 \x01(\x0b\x32#.frequenz.api.common.metrics.Bounds\"\xee\x02\n\x11MetricAggregation\x12\x0b\n\x03\x61vg\x18\x01 \x01(\x02\x12\x10\n\x03min\x18\x02 \x01(\x02H\x00\x88\x01\x01\x12\x10\n\x03max\x18\x03 \x01(\x02H\x01\x88\x01\x01\x12\x12\n\nraw_values\x18\x0c \x03(\x02\x12\x39\n\x0crated_bounds\x18\r \x01(\x0b\x32#.frequenz.api.common.metrics.Bounds\x12=\n\x10\x63omponent_bounds\x18\x0e \x01(\x0b\x32#.frequenz.api.common.metrics.Bounds\x12\x44\n\x17system_exclusion_bounds\x18\x04 \x01(\x0b\x32#.frequenz.api.common.metrics.Bounds\x12\x44\n\x17system_inclusion_bounds\x18\x05 \x01(\x0b\x32#.frequenz.api.common.metrics.BoundsB\x06\n\x04_minB\x06\n\x04_maxb\x06proto3')

_globals = globals()
_builder.BuildMessageAndEnumDescriptors(DESCRIPTOR, _globals)
_builder.BuildTopDescriptorsAndMessages(DESCRIPTOR, 'frequenz.api.common.metrics_pb2', _globals)
if not _descriptor._USE_C_DESCRIPTORS:
  DESCRIPTOR._loaded_options = None
  _globals['_BOUNDS']._serialized_start=66
  _globals['_BOUNDS']._serialized_end=104
  _globals['_METRIC']._serialized_start=107
  _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