Originally in designing software for the GBT, we thought messages could be treated simply as a subcategory of monitoring values, i.e., the user programs needed the ability to access values (in this case text) from all parts of the telescope. All we needed to do was pipe the text into the Samplers. However, it became clear that the alarm or messaging system needed more functionality than simply handling text generated from different devices.2Messages have requirements beyond those for monitor values.
Most messages need to represent conditions or states rather than transient events. The appearance of a line of text on a terminal is able to describe an event well enough, but more is needed to describe states adequately. For example, the message ``Power supply voltage is too low" does not communicate when the voltage became too low or whether the situation still exists. Messages need initial and terminating times associated with them so they can indicate ongoing situations.
Messages also need to have some type of severity level assigned to them. Not all events generating messages have the same impact on telescope operation. Some events cause questionable data to be generated while others may place personnel or equipment in danger.
Messages when displayed need to generate a context to help make the message meaningful. One obstacle that often keeps a user from understanding a message is the loss of context surrounding the message from the time it is generated to when it is displayed. What may be a perfectly clear line of text inside a piece of code can become nebulous when unexpectedly displayed in an operational environment. In the example above think of the questions a user might have: Exactly which power supply is being described? If the power supply itself is bad, would other messages be generated? Is the current scan's data being affected and how? Is there equipment being damaged? Should there be some action taken immediately? A message should have pointers associated with it that are accessible by the user, e.g., device name, computer of origin, relations to other messages, and references to system documentation.
Messages also need some mechanism in place to handle ``cascading messages." When some critical element generates a message, but at the same time a number of other elements in the system because they are dependent on the first also begin to fail, each generates its own message, continuing in a domino effect. The resulting flood of text masks the key message that would allow the user to discover the root problem.
To meet these needs, messages have to have a handle so they can be easily manipulated and have additional information attached to them. In object-oriented systems, this is done by making each message an object. In the GBT each message is encapsulated into the class Message. The C++ class constructor for Message accepts a unique identifier, a severity level, and a flag indicating whether the Message signals a state change or a transient event. The constructor also attaches additional information to the Message such as device name and computer of origin. The class method check tests for trigger conditions, indicating whether the state is asserted or the event has occurred. The check method sends a Message object to the MessageMux whenever the method check indicates a change in state or an event occurrence. The MessageMux appends additional information to create an AnnotatedMessage that is made available to any program through a MesgMuxIF object. The MessageMux also keeps a history of past messages on file. It is necessary for each Message to have a unique identifier in order for a display programs to handle multiple events for the same Message. In the future the identifier will be used to identify Messages in a table which will be read by the MessageMux. The table will include display options, actions to be taken, inhibitions between Messages to control cascading, and inferences between Messages to generate explanatory messages when patterns of Message states/events are detected.