Notifications are modeled as abstract objects which are better suited to tracking and management by software. FMS can be thought of as a framework that is both flexible and extensible, allowing domain/technology-specific filters and rules to be plugged in. This chapter is based on the approach to fault management that is taken in FMS. As in Chapter 11, we will give some insights into how FMS can extended through its APIs. 12.2 Events The "Event" is the basic unit of management information that is complete in itself and relates to an occurrence such as the discovery of an element, status update of an element or failure in an element. The set of all Events comprises a repository of all system occurrences. Alarm results may be correlated with other events to represent faults in NEs that may need immediate attention. K. Misra et al. (eds.), OSS for Telecom Networks © Springer-Verlag London Limited 2004 OSS for Telecom Networks Event and alert objects define the basic attributes and actions needed for fault management. Users can model their own objects by extending the basic units to plug in domain-specific properties. It is possible to add additional attributes to these basic units or their derivatives at run time. Events may be basic notifications from those SNMP agents which are external to the fault management system or they may be status poll events and threshold events which are generated when FMS is integrated with other network management ser- vices. Event generation can be induced through customised means using APIs. FMS models the failure information as event objects. Each event object pertains to a single failure in an element and has unique properties. There can be occurrences of mul- tiple failure in an element and hence there will be a flow of events, each representing a unique failure. The generated Events are parsed to make the notifications readable to the user. They are then processed by event filters which apply automatic actions to an event with the help of Event Observer, which is a user-written c