openbackhaul / alarms Goto Github PK
View Code? Open in Web Editor NEWCentralized representation of alarms
License: Apache License 2.0
Centralized representation of alarms
License: Apache License 2.0
The latest UML2YANG tool will include mandatory substatement to attributes that has "Multiplicity 1 + no default values defined".
The following attributes which are formerly optional will be changed to mandatory in the upcoming YANG.
grouping attribute-value-changed-notification
1.referenced-severity-configuration-identifier
grouping alarm-event-notification
2. alarm-event-sequence-number
3. alarm-type-id
4. alarm-type-qualifier
5. resource
grouping alarm-kind-type
6. alarm-type-id
7. alarm-type-qualifier
grouping severity-configuration-type
8. severity-configuration-identifier
9. alarm-type-id
10. alarm-type-qualifier
11. resource-group-description
grouping current-alarm-type
12. current-alarm-identifier
13. alarm-type-id
14. alarm-type-qualifier
15. resource
grouping alarm-event-record-type
16. alarm-event-sequence-number
17. alarm-type-id
18. alarm-type-qualifier
19. resource
The current-alarm-list
in the current-alarms
container does not have a key.
In revision 2023-10-05 of the alarms-1-0
model, the resource-group-description
attribute in the severity-configuration-type
grouping has been made mandatory which is in line with issue #10.
My assumption is however that the intention was to make the resource-list
attribute mandatory, similar to other groupings (current-alarm-type
, alarm-event-record-type
, alarm-behavior-type
) and as implied by the comment in issue #10 (comment).
(The resource-group-description
attribute is only informational and thus plain text.)
It shall be configurable, whether a specific kind of alarm is notified or not.
Potential Proposal:
An additional SeverityConfigurationType::notificationsIsOn : Boolean = false attribute shall be added.
It shall be equipped with the comment: "true : A notification gets sent, if such kind of alarm is raised or cleared."
Following are the issues observed in the pyang output for the yang generated for the UML Alarms_1.0.0-tsp.220224.1810,
1. alarms-1-0.yang:133: error: "core-model-1-4:local-class" in the path for subresource at alarms-1-0.yang:98 (at alarms-1-0.yang:131) is not found
2. alarms-1-0.yang:615: error: "core-model-1-4:local-class" in the path for subresource at alarms-1-0.yang:43 (at alarms-1-0.yang:613) is not found
3. alarms-1-0.yang:670: error: "core-model-1-4:local-class" in the path for subresource at alarms-1-0.yang:43 (at alarms-1-0.yang:668) is not found
4. alarms-1-0.yang:124: error: "core-model-1-4:global-class" in the path for resource at alarms-1-0.yang:98 (at alarms-1-0.yang:122) is not found
5. alarms-1-0.yang:606: error: "core-model-1-4:global-class" in the path for resource at alarms-1-0.yang:43 (at alarms-1-0.yang:604) is not found
6. alarms-1-0.yang:661: error: "core-model-1-4:global-class" in the path for resource at alarms-1-0.yang:43 (at alarms-1-0.yang:659) is not found
For the errors #1,#2,#3 the details are as follow ,
leaf subresource {
type leafref {
path "/core-model:local-class/core-model:local-id";
require-instance false;
}
config false;
description
"Concrete resource causing this alarm notification.";
}
For the errors #4,#5,#6 the details are as follow ,
leaf resource {
type leafref {
path "/core-model:global-class/core-model:uuid";
require-instance false;
}
config false;
description
"Concrete resource causing this alarm notification.";
}
In UML , the attributes resource and subresource are modeled as a shared aggregation. And so the tool is converting it to a leafref.
Following is the actual expectation for the path reference , (details provided by Thorsten Heinze)
We need something similar to the following, but with multiple different paths being accepted.
type leafref {
require-instance false;
path "/core-model:control-construct/core-model:logical-termination-point/core-model:uuid";
}
It would be like
type leafref {
require-instance false;
path "/core-model:control-construct/*/core-model:uuid";
}
or at least like
type leafref {
require-instance false;
path "/core-model:control-construct/core-model:logical-termination-point/core-model:uuid" OR "/core-model:control-construct/core-model:equipment/core-model:uuid";
}
, but it seems YANG doesn’t know such things.
While configuring the level of severity of a combination of alarm type and resource, peripheral conditions might be of relevance.
E.g. the protection configuration (e.g. 1+0 or 1+1) might influence, whether a LoS alarm would be assigned to be critical or just e.g. major.
Based on this consideration we added two attributes (“severityLevelForServiceAffecting” and “severityLevelForNotServiceAffecting”) two every combination of alarm type and resource.
While searching for a generally adopted definition of what’s “service affecting”, we found indication that the definition of severity level “critical” is that the service is affected.
If the severity level would always be “critical” in all cases the service is affected, configuration of the severity level would be obsolete in these cases.
Potential proposal to the 5G-xhaul call
Creating a single SeverityConfigurationType::severityLevel attribute with comment: “Allows configuring the severity level of alarms of the specified combination of alarm type and resource, in case they are not service affecting. If such alarm would be service affecting, severity level ‘critical’ would be assigned in general.”
Deleting SeverityConfigurationType::severityLevelForServiceAffecting and SeverityConfigurationType::severityLevelForNotServiceAffecting attributes from the modeling.
Shall it be possible to change the severity level of an already existing alarm?
If yes:
Currently AlarmConfiguration::SeverityConfigurationType::severityLevelList allows to configure the severity of an alarm, but it is not possible to configure that the alarm shall neither be listed in the CurrentAlarmList nor be indicated by notification.
Potential Proposal:
The SeverityType enumeration shall be complemented by an additional DISABLED value.
Or is this not to be mixed with the severity configuration?
Usual technology specific models are offering four types of notifications:
Because not object gets instantiated or deleted in the Alarms modelling there would be just two types of notifications, right?
Comment of the AlarmCapability::AlarmKindType::alarmTypeQualifier : "The optionally dynamically defined alarm type identifier for this possible alarm." somehow indicates that the values could be changed.
If value to be changed:
Contradictory modeling/commenting to be resolved.
Which object shall be referenced by the _objectIdRef attribute in the AttributeValueChangedNotification?
Usually, it is LTP, but alarms are attached to ControlConstruct, which is not really meaningful, or?
The CurrentAlarmType datatype contains the key attribute currentAlarmIdentifier.
The currentAlarmIdentifier is not communicated within the AlarmEventNotification.
Without the currentAlarmIdentifier key attribute value the CurrentAlarms list inside the cache cannot be updated based on the received AlarmEventNotification.
This includes, for example:
Potential Proposal:
The currentAlarmIdentifier is added to the attributes comprised in the AlarmEventNotification.
The probable-cause
attribute in the alarm-inventory-list
is of type int16
. It is not clear which values should or may be reported in this attribute.
The comment refers to X.733 but I could not find numerical values there. Furthermore, devices may report additional probable causes, e.g. from X.736 or M.3100.
Some implementations notify the status of some resources using an alarm with the severity STATUS value.
The model does not provide a suitable value (including SEVERITY_TYPE_INDETERMINATE) to map this STATUS value to.
The proposal is to add the SEVERITY_TYPE_STATUS identity based on SEVERITY_TYPE to extend values provided in ITU-T M.3160.
The AlarmTypeIdType datatype is an empty enumeration in the UML.
It is for the vendors to add their individual alarm names into an extendable identity.
Because there is no set of predefined values, which would allow concluding on the planned content of the enumeration, implementers are wondering about its purpose.
Potential solution:
A comment should be added to the enumeration in UML
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.