As we move forward on identifying the requirements for WIRCam, one key requirement is the ability to monitor subsystem parameters and send out alerts based upon predefined error or warning conditions. With MegaPrime, these alerts were hard-coded in the fipcom agent software. This has worked pretty well with MegaPrime, but it has several drawbacks. First, the rules are hard-coded in the C code of the agent. This makes it more difficult to perform iterative fine-tuning of the rules. If a rule needs to be changed, someone in the software group needs to be informed and change the agent. Meanwhile, everyone using MegaPrime needs to hope that there were no side-affects to the agent introduced by the change. At this point, there are several rules which have been determined to be less than optimal, but a determination has been made that some of the changes may not be worth the risk of changing the fipcom agent.
Another issue with the MegaPrime model is that the fipcom agent must be running in order for the alerts to be available. Because all of the current MegaPrime alerts are based on fipcom data this may not be a major issue. However, plant and instrument control data is now being added to the Status Server by sources which are not director-based agents. The best example of this would be the Allen-Bradley PLC status and control information. As a result, it appears that much of the critical state and status information, upon which notification rules would be based, will be available in the Status Server. However, there isn't the dependency that an agent running under director must execute the notification rules.
At this point, I don't believe that the current mechanism used with MegaPrime is the best choice for WIRCam instrument, or plant control related notifications. The purpose of this document is to list a first set of requirements for a notification system based on information contained in the Status Server. These requirements were defined in a meeting held with Will Rambold, Rohendra Atapattu, Tom Benedict, Grant Matsushige and myself. At this point, there may be more requirements, which still need to be identified. The goal of this document is to highlight the requirements which have already been defined and, through the distribution and review of the document, perhaps identify additional requirements.
Unless otherwise noted, the requirements identified in this document are intended to be implemented in the first release of a notification system. However, release requirements may dictate the priority and staging of functionality.