Current Work
From EStar
The Architecture
The original idea behind eSTAR was to have intelligent software controlling observing programmes on a network of robotic telescopes. At first our model was that these agents, each of which controlled a science programme, were interacting with relatively dumb telescopes.
However, it became clear that a more useful paradigm is that of the multi-agent contract model. In such an architecture both the software controlling the science programme, and the software embedded at the telescope acting as a high-level interface to the native telescope control software, are thought of as agents. A negotiation takes place between these agents in which each of the telescopes bids to carry out the work, with the user's agent scheduling the work with the agent embedded at the telescope that promises to return the best result.
This architectural distinction of viewing both sides of the negotiation as agents, and as equals, is crucial. Importantly this preserves the autonomy of individual telescope operators to implement scheduling of observations at their facility as they see fit. It is also a key feature of the emerging Grid architectures, and offers adaptability in the face of asynchronously arriving data. For instance an agent working autonmously of the user can change, reschedule, or cancel queries, workflows or follow-up observations based on new information received.
Resource discovery
A typical observing session starts with a user's intelligent agent, the piece of software tasked with carrying out the user's science programme, wanting to perform a specific observation. This desire may have come about in a number of ways, the agent may be trying to service an ongoing observational campaign on a specific object, or responding to a real time alert.
The agent will begin by performing a resource discovery step. Both by necessity and design this will be a fairly rough proceedure, elimitating the resources that obviously do not meet its needs. For instance, in the case that the desired observations were in the optical, the agent may elimitate resources which advertise the ability to perform observations only in the radio bands.
Quantifying availability
The agent will then contact the agents embedded at the various resources with a description of the observations it would like to perform. This embedded agent, which we refer to as as a node agent, will reply with its evaluation of how well it can carry out the the observational programme. This evaluation will take account of the many local variables, for instance for optical telescopes; the time of day, position of the Moon and the local weather, all of which are unknown and unknowable to the user's intelligent agent, before returning a "score" reflecting how well agent embedded at the resource feels it can fufil at the.
At this point it is important to recognise that no commitment to carry out an observation has been made by the node agent, nor is there an expectation of such on the part of the user's agent. This scoring stage may be repeated several times, for instance, it is possible that no node agent will be able to fulfil the user agent's initial request or some node agents may have replied with alternative plans; perhaps offering to carry out the observation in a slightly different filter, or with an offer to carry out the observations as specified, but not within the time frame required.
Quantifying ability
During this negotiation phase the user's agent will evaluate the scoring replies returned by all the node agents and determine which is the "best scoring node". This evaluation will take account of not only the ability to perform the observations as per the user agent's specification, but also the timescales over which the observations will be performed. Once a best scoring node is determined to the satisfaction of the user agent it will then send an observation request document, in effect a contract, to the node that scored highest.
At this stage the best scoring node may reject the observation request outright. Alternatively, another round of negotiation may be entered into, this may be broken off by either party; perhaps again the node agent will reject the observation request, or the user's agent may decided to request the observations from the next best scoring node, or in fact may reopen the scoring process. If we were operating in a market based system this process might be referred to as 'contract negotiation' or 'bidding'. This is a vitally important point, at no time is there the possibility to demand an observation from a resource, all observation requests are exactly that, requests.
The data products
Once an observation request has been accepted by a node agent embedded at a resource, the agent will attempt to carry it out as it as agreed. It is important to realise that since we are dealing with real time systems, problems such as changing weather conditions may prevent the node agent carrying out its agreement. The node agent will forward back the status information concerning the ongoing observations to the user agent which orignally placed the request. In the case where the observations fail, the user's agent may again reopen the scoring process or cut its losses and re-evaluate its own needs. In the more common case where the observations are taken then the node agent will in general attempt to reduce the data using a real time data reduction pipeline, before returning the results to the user's agent.
Data reduction can most easily be carried out at this stage, closest to the resource that generated it, where instrument specific knowledge can be applied, rather than at the user's end which knows little, or nothing, about the original instrumentation. For example, a node agent will usually attempt to return a point source catalogue of photometry rather than an original image, although links to the original data frames can and should be embedded in the message describing the observations returned the the original requesting agent.
Meta-networks
An important distinction to between eSTAR and previous work in this field is that there is no such thing as an eSTAR native telescope, even inside the network. The network itself serves as a meta-network, presenting a uniform interface to an already heterogeneous collection of telescopes and instrumentation. It can be argued that eSTAR could therefore effectively serve as a meta-network between the existing proprietary robotic telescope networks. By allowing eSTAR access to their telescope the facility do not give up control to the network. Scheduling and prioritising observations are still done locally. A telescope facility can therefore allow access in stages; for incoming events only, for bi-directional events, or finally allowing full access.
