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