The object AlarmSeverityAssignmentProfile (ASAP) models the (flexible) severity assignment to specified probable causes. So the ASAP object includes a table, with each row specifying the probable cause (plus optionally the probableCauseQualifier and / or the nativeProbableCause) and the assigned severity for "service affecting", "non service affecting" and "service independent or unknown" alarms.

Probable cause, probableCauseQualifier and nativeProbableCause are the coordinates of the ASAP entries, so there must not be two ASAP entries with the same coordinates. It is the responsibility of the EMS to enforce this.

Alarms against entities that are not modeled by the interface are reported using the "AID" objectType. For these "AID" alarms the ASAP mechanism is not applicable.

Typically the ASAP function is implemented in the OS or NE where the alarm is originated. I. e. the severity will usually be assigned directly by the NE, so it is up to the EMS to download the defined ASAP to the NE. Other alarms, e.g. on arcs like SNCs, may be generated by the EMS. 

An alarm becomes reportable by NE/EMS:
- when for PTP, CTP, FTP: AlarmReporting changes from "off" to "on" 
- when for SNC, TopologicalLink, Equipment, EquipmentHolder, GTP: alarmReportingIndicator changes from false to true.
Alarms are always reportable for all other objects as they do not have any alarm reporting attribute.

When an alarm becomes reportable the ASAPs are applied (accessed via the asapPointer). The severity of the alarm is adopted from the ASAP entry that matches for all of the following:
- same probableCause 
- same probableCauseQualifier (an empty string is a match)
- same nativeProbableCause (an empty string is a match).

For example, if the reportable alarm has LOS probableCause and an ASAP entry is found with LOS probableCause and both probableCauseQualifier and nativeProbableCause are empty strings, then the search is successful.

If there is a matching ASAP, then the severities are adopted on the following basis:
- the alarm is service affecting: the severity specified in the serviceAffecting field is assigned
- the alarm is service non affecting: the severity specified in the serviceNonAffecting field is assigned
- the alarm is service independent or NE/EMS is not equipped to determine if the alarm affects service or not:
  the severity specified in the serviceIndependentOrUnknown field is assigned.

   If the assigned severity specified in the ASAP is:
   - "FREE_CHOICE" then the NE/EMS are free to determine the severity. If there is no local mechanism on
     the ME/EMS to determine severity then the severity "INDETERMINATE" should be assigned. 
   - "NOTALARMED" then the EMS should not emit an alarm over the EML-NML interface.

If there is no ASAP that matches, then the NE/EMS is free to determine the severity. If there is no local mechanism on the NE/EMS to determine severity then the severity "INDETERMINATE" should be assigned.

Once a severity has been assigned, the alarm notification is emitted (other than for "NOTALARMED").

Note: Any operation of alarm retrieval will not include "NOTALARMED" alarms.

Object Lifecycle: Created and deleted by EMS and NMS.

Object Creation Notification Issued? Yes
Object Deletion Notification Issued? Yes
