Design Fest
Event Logging
Authors:
Ivan Neto
Nelson Takashi Omori
Paulo Cheque Bernardo
Renato Pelizzari da Silva
Rodrigo Ferreira
Baroni
The problem
This is a short description of the
problem. The detailed description is
here.
A spacecraft has to report required
telemetry
data to Earth, to report warnings and errors, to
verify internal behavior
during system testing, and to provide ground operators with detailed
data
when investigating in-flight anomalies. However, there are limitations
like: low downlink rate, low processor speed, low memory and the
spacecraft may contact Earth only once a week.
Considering all of the above, we have
to
design an event logging facility (ELF) for the spacecraft.
The desired program:
- Design a base class for events
that includes attributes for time stamp, event ID, and event severity,
plus any other attributes needed for the entry policy and retention
policy.
This class must be extensible for events that need to be logged with
additional
event-specific data.
- Design an event signaling mechanism
(whether a method, template function, or macro) that programmers will
use
to instrument their code. This mechanism should incur minimal overhead
when the entry policy is set to discard the given event.
- Design a parameterized entry
policy that filters events based on their type, ID, severity, and
frequency
of occurrence.
- Design a parameterized retention
policy that, when the disk is full, discards logged events based on
type, severity, age, and
population
limit.
- Provide a mechanism for ground
operators to dynamically change the parameters of any policy.
The system has these
requirements:
- All event
objects must contain a time stamp, event identifier, and event severity.
- An event
identifier must be encoded as a number, not a string, because strings
consume
too much of the limited downlink capacity.
- ELF must
support three levels of event severity: a "green" level for purely
informational
events, a "yellow" level for warnings, and a "red" level for errors.
- Application
programmers must be able to define new event types that contain
application-specific
data.
- The contents
of an event object must be strongly typed so that downstream processing
can access the contents in a type safe manner.
- ELF must
define a signaling interface whereby an event occurrence is signaled
with
all the information needed to construct an event object.
- For reasons
of runtime efficiency in high-performance applications, at least one of
the signaling interfaces (if more than one) must be designed for speed,
ignoring events for which logging is currently disabled.
- ELF must
define interfaces for controlling entry policy and retention policy.
- It must
be possible to change the tunable parameters of a policy at run-time,
i.e.,
no source code changes and no recompilations.
- It is desirable
to include with a logged event the source location where it was
signaled.
This helps distinguish between events that otherwise have the same
signature.
- Since brevity
is a virtue to most programmers, ELF should provide at least one
signaling
interface for basic events that can be written in a compact form. The
intent
is to make it easy to instrument an application's source code,
particularly
during early design and debugging.
The design
The program is composed by these classes:
LogSystem
It receives an Event object and apply the entry police. The programmer has to
take care of how many events it sends to add to the LogSystem directly, because
there is the needed to call LogSystem::arrangeDataBase( ) periodically to check
and remove some events that can have its retention policy expired and maybe with
full disk, and so to get free space to add new events into the DataBase.
Event
Base class for events. It contains
attributes like severity, event ID, event type ID, timestamp and
sourceLocation.
RetentionPolicy
Object that represents a retention
policy. It is utilized when the disk is full,
and the system has to decide if deleting data is necessary.
RetentionPolicyManager
Every type of Event has its own
retention RetentionPolicy.
The RetentionPolicyManager manages all of the retention policies that
are sent from Earth through Facade.
StoragePolicy
Object that represents all storages policy. When an event occurs, all storage
policies are checked, and just if some policy matches the event being requested
to be logged, it will be stored.
EntryPolicy
Keeps info about how long (retention policy) that a single kind of event
desirable to be logged will be kept into the database.
LogSystemManagerFacade
Facade allows Earth to get the logs and to change the storage and retention
policies of the LogSystem. This can be done by calling getDataLogs( ),
changeStoragePolicies(desiredEvents: EntryPolicy) and
changeRetentionsPolice(retPolicies: RetentionPolicy).
DMSDriver
Driver to communicate with data manager
subsystem.
Dynamic
We assumed that the object Event comes
from other components already instantiated. So the LogSystem will
receive this object and will call the method add(ev: Event). Then
it gets the event type policy from StoragePolicy, inserts the
RetentionPolicy into the Event and verifies if it is applicable. If
it is, it connects with DMS and stores the Event using
DMSDriver.
In some cases, the disk is full, so the SystemLog has to choose some
data to be deleted. It calls arrangeDataBase(), that will utilize the
information about retention policy, that was stored with the Event, and
will free space and log the new entry.
Ground Operator
This diagram describes how a ground operator can interact with the spacecraft to get the desired logged data or update the system with new retention or entry polices.
System Programmer
A system programmer can add new kind of events and specific data. The programmer should also throw this event and catch it, so this event can be logged afterward if necessary.
