You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I thought the approach Stefan took in his PowerPoint slides about how overallStatus is derived is clearer. Here's some Markdown that attempts to capture that:
Devices MUST follow the rules below when mapping the domain statuses into the combined overallStatus:
When the Receiver is Inactive the overallStatus is set to Inactive
On Receiver Activation the Receiver monitor enters a stabilisation period in which the overallStatus is set to Healthy and remains Healthy for the duration specified by the statusReportingDelay property. (This allows for devices to go through a period of instability when connecting to new streams without generating spurious alarms for an operator.)
Once the stabilisation period has ended and until the Receiver becomes Inactive the following algorithm applies:
If all statuses are either Healthy (or equivalent) or Unused the overallStatus is set to Healthy
Otherwise if any status is Unhealthy (or equivalent) the overallStatus is set to Unhealthy
Otherwise the overallStatus is set to PartiallyHealthy
The text was updated successfully, but these errors were encountered:
I thought the approach Stefan took in his PowerPoint slides about how overallStatus is derived is clearer. Here's some Markdown that attempts to capture that:
Devices MUST follow the rules below when mapping the domain statuses into the combined overallStatus:
statusReportingDelay
property. (This allows for devices to go through a period of instability when connecting to new streams without generating spurious alarms for an operator.)The text was updated successfully, but these errors were encountered: