Event Hierarchy

The classes which define the events hierarchy are shown in Figure 1.

Figure 1. Events hierarchy.

• AbstractEvent: Abstract class from which all events are derived. It defines the attributes common to all events, namely: type, id, severity. The setSeverity method allows the system to change the severity of an event after it has been accepted.
• ConcreteEvent: A representation for a specific kind of event.
• GroundEventDecorator: Allows the extension of the functionality of a given event object when it is downlinked to earth, where we have few memory/processing restrictions.
• AbstractEventFactory: It provides the standard interface for the creation of event objects.
• ConcreteEventFactory: A concrete factory is responsible for creating specific types of event objects. The caller to the ELF system indicates which event implementation it desires to create by specifying a given factory class when signaling an event. The purpose of creating event objects through a factory is relieving the ELF system from deciding which concrete implementation should be used once an event is signaled. This facilitates the task of adding new event classes, since we only need to define the new event class and its factory, with no modification to the core ELF classes.
• Severity: Enumeration class which define the allowed degrees of event severity.

Event Signaling

The classes which take part in the signaling of events are shown in Figure 2.

Figure 2. Event manager.

• EventManager: Basic interface for event signaling.
• DefaultEventManager: Default EventManager implementation, which aims to minimize the cost of signaling an event.

Entry Policy

The classes involved with the entry policy are shown in figure 3.

Figure 3. Entry policies.

• AbstractEntryPolicy: Parent class to all specific entry policies. It defines the basic interface for event acceptance and parameter manipulation.
• ConcreteEntryPolicy: A class which defines a specific policy for accepting events.
• EntryPolicyManager: It manages the application of entry policies. The EntryPolicyManager keeps the list of current atomic entry policies and define methods for manipulating this list and accessing individual policy objects. The executePolicies method evaluates whether a given event shoul be accepted. On invocation, this method will iterate through the policy list and call the acceptEvent method on each policy object. The iteration is interrupted once any policy rejects the event. A event will be accepted only if no policy rejects it.

Concrete entry policies

Some possible implementations of entry policies are shown in Figure 4.

Figure 4. Concrete entry policies.

• RejectByType: Rejects an event in case its type is present in a rejection list.
• RejectBySeverity: Rejects all events whose severity is below a given threshold.
• CompoundEntryPolicy: This class allows the composition of atomic policies, making it possible a tree-like decision model. The acceptEvent method for this class can be represented by the following pseudo code:
  

  acceptEvent(arglist) {
      if (test.acceptEvent(arglist)) {
          return tPolicy.acceptEvent(arglist)    
      } 
      else {
          return fPolicy.acceptEvent(arglist)    
      } 
  }
  							

• RejectBySeverityAndType:Rejects an event when both its severity is below some threshold and its type belongs to a rejection list.

Retention Policy

The involved with the implementation of the retention policies are shown in Figure 5.

Figure 5. Retention policy classes.

• RetentionPolicyManager: It is responsible for managing the application of individual retention policies.
• AbstractRetentionPolicy: Defines the basic interface for retention policy objects.
• ConcreteRetentionPolicy: Implements a concrete retention policy. It is responsible for interacting with the DataManagement system in order to remove the events which should no longer be storaged.