|
|
|
Experiment Control |
||||||||||||||||||||||
|
||||||||||||||||||||||
|
Experiment Control is responsible for providing coordination between the various subsystems that make up IceCube's software at the South Pole, and to provide a mechanism for running the experiment from "off-pole" when there is network access. To fulfill these responsibilities Experiment Control has been broken down into a number of separate tasks: - A Web based interface to the experiment's software. - A common infrastructure that all sub-systems can use for control, configuration, monitoring and logging. - A stand-alone subsystem that manages the inter-subsystem coordination. Throughout its work, the Experiment Control group has emphasized the use of existing standard where possible so that we can make use of existing software rather than reinventing the wheel. This allows us to tailor those standard to the needs of the IceCube developers. IceAxe The IceAxe portal is the web based interface developed by Experiment Control. The figure below shows an example of this interface. It is displaying the main ACME (Access to Control and Monitoring of the Experiment) page. From this page all of the software at the South Pole can be started and stopped.
The reason we chose a portal as the basis for our web interface is that portals are designed to allow user customization so that in the future each member of the collaboration can tailor this access to meet their needs. They will be able to do this because the idea behind a portal is that any page is made up of one or more portlets and each user can choose which portlets appear on their pages and where. The practical effect of this architecture is that each subsystem simply needs to provide a selection of portlets that enable users to control, configure and monitor that subsystem, then each user can build their own pages. The responsibility of managing these portlets is left to the the Portal implementation. Moreover as the portlet interface is defined in JSR-168 <http://www.jcp.org/en/jsr/detail?id=168> IceCube developers can concentrate on the contents of the portlets and remain independent of our choice of Portal. To help speed development of portlets from IceCube, the Experiment Control group has provided a simple framework that obeys the portlet interface and allows its display to be rendered using JSP (Java Server Pages) and input, in the form of HTML forms, to be processed by a simple Java classes created by the developers. This approach does not preclude developers from producing their own portlets, but is does allow those who do not wish to get too deeply involved in portlets to provide content for IceAxe fairly quickly. Infrastructure To enable different subsystems to share common services the Experiment Control group has selected a number of different standards to act as the core subsystem infrastructures. The figure below shows the selections that where made.
The main control, configuration and monitoring of subsystems is done via a JMX (Java Management Extensions) server. The requirements for such a server are set out in JSR-003 <http://www.jcp.org/en/jsr/detail?id=3>. In IceCube we decided to use the JBoss <http://www.jboss.com/developers/index> implementation of this standard as it not only acted as a JMX server, but includes other standards that we can use, such as EJBs (Enterprise Java Beans), which we'll mention in a moment. By requiring all subsystems to expose their control, configuration and monitoring aspects using this standard we are then able to run the experiment in a number of different way. The most basic is use a web application called a JMX-Console that simple provides web access to all of the subsystems attributes and methods. While this Logging across subsystems is handled by the de-facto Java standard logging package log4j <http://logging.apache.org/log4j/docs/>. We chose this package above the native java.util.logging package because log4j was more mature and offered more features at the time the decision was made and it also had connectivity with C/C++ which enabled us to integrate the PnF subsystem, which uses C/C++, into a single logging system. However to enable use to change logging subsystem in the future, all Java code is written use the commons-logging package <http://jakarta.apache.org/commons/logging/>, which allows the underlying implementation to be changed at run time. To handle configuration persistency and internal bookkeeping a number of options are available. The standard approach in Java is to use EJBs, which, as noted earlier, are available as part of JBoss. This provides most of the functionality required by the subsystems. For those that need more customized access, we support JDBC access to the databases. For non-Java code, such as PnF, SQL access to the underlying databases is provided. ACME The ACME (Access to Control and Monitoring of the Experiment) subsystem is the standalone subsystem responsible for coordination between the individual subsystems. This coordination can be as simple as starting all the subsystems at the same time or more complex task such as coordinating the delivery of the DAQ configuration to PNF so the PNF knows how to process the data when it arrives. As well as coordinating subsystem, the ACME subsystem is responsible for the monitoring the overall health of the software systems at the South Pole. To that end it can use the infrastructure described in the previous section to monitor the subsystems and take corrective action when necessary. |
||||||||||||||||||||||
