robotic telescope networks, agent architectures and event messaging alasdair allan tim naylor eric...
TRANSCRIPT
Robotic telescope networks, agent architectures and event messagingAlasdair Allan
Tim Naylor
Eric SaundersUniversity of Exeter
Iain Steele
Chris MottramLiverpool John Moores University
Tim Jenness
Frossie Economou
Brad Cavanagh
Andy AdamsonJoint Astronomy Centre, Hawaii
VOEvent Workshop, Apr 2005
2
What is an agent anyway?
• An agent is “just software” not magic
Loosely, an agent is a computational entity which:
• Acts on behalf of another entity in an autonomous fashion
• Performs its actions with some level of proactivity and/or responsiveness
• Exhibits some level of the key attributes of learning, co-operation and mobility
VOEvent Workshop, Apr 2005
3
Agents as architecture
• From a developer’s perspective there are five major trends which are evident from the history of computing. These are,– ubiquity– interconnection– intelligence– delegation– human-orientation
• Agent architectures are the next paradigm shift following these trends.
VOEvent Workshop, Apr 2005
4
The intelligence thing…
• The complexity of tasks that we are capable of automating and delegating to computers has grown steadily
• If you don’t feel comfortable with this definition of “intelligence”, it’s probably because you’re human
VOEvent Workshop, Apr 2005
5
The delegation thing…
• Computers are doing more for us – without our intervention
• We are giving control to computers, even in safety critical tasks
• One example: fly-by-wire aircraft, where the machine’s judgment may be trusted more than an experienced pilot
VOEvent Workshop, Apr 2005
6
Multi-agent systems
• A multi-agent system is one that consists of a number of agents, which interact with one-another.
• In the most general case, agents will be acting on behalf of users with different goals and motivations.
• To successfully interact, they will require the ability to cooperate, coordinate, and negotiate with each other, much as people do…
VOEvent Workshop, Apr 2005
7
Barriers and Flatness
• If you put barriers in the way of people who want to do something, they will find ways around these barriers.
• The real world does not operate in a hierarchical manner.
• In the real world you usually know someone, who knows someone, who knows what you want.
VOEvent Workshop, Apr 2005
8
Peer-to-Peer
• Agents operate in a peer-to-peer manner and can make use of these interconnections between people and data.
• Carrying out intelligent resource discovery could mean that your agent looks to your collaborators agent for data and expertise before it looks to “central” sources.
VOEvent Workshop, Apr 2005
9
The world is flat…
• The world is small and flat, but it is none the less still very complex.
• Architectures which take account of this are intuitive, and will map well into the real world. Those that do not will have problems.
© Terry Pratchett
VOEvent Workshop, Apr 2005
10
The eSTAR concept
Two fundamental ideas behind the project which makes it unique:
• Treat telescopes and databases in a similar manner, both being made available on the Observational Grid.
• The main user of the Grid and the Virtual Observatories (VO) should not be humans, but autonomous intelligent agents.
VOEvent Workshop, Apr 2005
11
Multi-agent systems for eSTAR
• The eSTAR uses the collaborative agent paradigm, with a flat peer-to-peer network topology.
• A hierarchical system would not be robust, or scale well, and it’s not the way the real world operates.
• We’ve built the first agent based astronomical system, and it was clearly the correct choice of architecture.
VOEvent Workshop, Apr 2005
12
We are not alone…
• The Thinking Telescope System (Los Alamos) www.thinkingtelescopes.lanl.gov
VOEvent Workshop, Apr 2005
13
The short term plan…
We have an exciting time ahead:
• Currently deploying on UKIRT in collaboration with the JAC to do real time GRB follow-up [APR]
• Deploy eSTAR onto Robonet-1.0 to allow it to carry out observations using adaptive dataset planning and do micro-lensing work this summer [MAY]
• Finish work on the WFCAM/eSTAR Transient Object Detection Agent in collaboration with the JAC [JULY]
VOEvent Workshop, Apr 2005
14
eSTAR and UKIRT
• All aspects of an observation programme at the JAC are either software readable or software controllable
• To the agent its irrelevant that’s there is a human in the loop
• Agents now being deployed to carry out GRB follow-up
© Nik Szymanek
VOEvent Workshop, Apr 2005
15
eSTAR and Robonet-1.0
• Searching for extra-Solar planets using gravitational microlensing in the galactic bulge
• Real time GRB follow-up using the same agent software as UKIRT
• Consortium “open” time, a testbed for our adaptive dataset planning work
VOEvent Workshop, Apr 2005
16
The eSTAR network
© Nik Szymanek
UKIRT at JACH
User Agents
The Grid
Embedded Agent
Robonet-1.0
Embedded Agent
OGLE Observations
Alert Agent
GCN Alerts
Alert Agent
Alert Agent
WFCAM
The VO
VOEvent Workshop, Apr 2005
17
In the longer term…
• Adding more telescopes, means the network becomes heterogeneous. Does that mean more complexity?
• What about the existing proprietary networks?
• Need to establish interoperability between the existing networks. Standards based, using RTML over SOAP (and VOEvent for notification?)
VOEvent Workshop, Apr 2005
18
The eSTAR meta-network
User Agents
The GridBrokerService
ProprietaryTelescope Network
Alert Agent
VOEvent Workshop, Apr 2005
19
A Grid Market
User Agents
The Grid Grid Market
BrokerService
ProprietaryTelescope Network
BrokerService
ProprietaryTelescope Network
The VirtualObservatory
BrokerService
VOEvent Workshop, Apr 2005
20
What about event notification
• Needs to be,– light-weight, so easily implemented– extensible, so easily modified– built to be interpreted by software, not humans
• Must take the peer-to-peer nature of agent architectures into account, there will be more parsing of messages going on than you might expect.
VOEvent Workshop, Apr 2005
21
What is the minimal specification?
• Probably needs to specify,– What– Where– When– Who
• But can get away without,– What– Who
VOEvent Workshop, Apr 2005
22
What is a minimal VOEvent?<?xml version="1.0”><VOEvent packetType=“Discovery” role=“Test”>
<Event> <Coordinates> . . . </Coordinates> <Date> . . . </Date>
<Description> . . . </Description></Event>
<Instrument> . . .</Instrument>
</VOEvent>
<?xml version="1.0”><VOEvent packetType=“Discovery” role=“Test”>
<Event> <Coordinates> . . . </Coordinates> <Date> . . . </Date>
<Description> . . . </Description></Event>
<Instrument> . . .</Instrument>
</VOEvent>
<?xml version="1.0”><VOEvent packetType=“Discovery” role=“Test”>
<Event> <Coordinates> . . . </Coordinates> <Date> . . . </Date>
</Event>
</VOEvent>
VOEvent Workshop, Apr 2005
23
Coordinate representation
The following will handle most cases,<Event> <Coordinates format=“simple”> <RightAscension format="hh mm ss.s" units="hms">
24 00 00.0 </RightAscension> <Declination format="sdd mm ss.s" units="dms”>
+45 00 00.0 </Declination> <Equinox>2004.34</Equinox> <Epoch>J2000</Epoch> </Coordinates> <Date time="UTC">2005-03-18T12:36:19.619</Dats> . . .</Event>
VOEvent Workshop, Apr 2005
24
More complex cases?
But the more complex cases may need STC,<Event> <Coordinates format=“stc document”> <Document type=“url”>
http://some.host.ac.uk/documents/event_001.xml </Document> </Coordinates> <Date time="UTC">2005-03-18T12:36:19.619</Dats> . . .</Event>
VOEvent Workshop, Apr 2005
25
Instrument representation
Can be inline, or you should be able to point to a URI,<?xml version="1.0”><VOEvent packetType=“Discovery” role=“Test”>
<Event> . . .</Event>
<Instrument format=“rtml”> <Document type=“url”>
http://some.host.ac.uk/document/instrument_description.xml </Document></Instrument>
</VOEvent>
VOEvent Workshop, Apr 2005
26
Pointers to documents?
Or perhaps even this,<?xml version="1.0”><VOEvent packetType=“Discovery” role=“Test”>
<Document type=“url” format=“rtml”>http://some.host.ac.uk/document/rtml_document.xml
</Document>
</VOEvent>
In some cases you could actually do this, <?xml version="1.0”><VOEvent packetType=“Discovery” role=“Test”>
<Document type=“url” format=“voevent”>http://some.host.ac.uk/document/voevent_document.xml
</Document>
</VOEvent>
VOEvent Workshop, Apr 2005
27
Summary
• Events need to be passed through multiple systems, parsed, interpreted and routed. Need a light-weight standard that is easy to implement.
• The importance of being able to use URIs to point to (sub-)documents can’t be overstressed.
• And finally, an invitation…
VOEvent Workshop, Apr 2005
28
The HTN WorkshopJuly 18 -21 2005
Aims• Establish the standards for
interoperability between robotic telescope networks
• Work towards the establishment of an e-market for the exchange of telescope time
• Establish the standards for interoperability with the Virtual Observatory (VO) for event notification
See htn-workshop2005.ex.ac.ukScience Goal Monitor