The Heterogeneous Telescope Network HTN

1
The Heterogeneous Telescope Network (HTN)
The Liverpool Telescope, CREDIT Liverpool John
Moores University

• Alasdair Allan1,2 on behalf of the HTN consortium
• 1School of Physics, University of Exeter, Stocker
  Road, Exeter, EX4 4QL, U.K.
• 2Royal Observatory, University of Edinburgh,
  Edinburgh, U.K.

2
What is the HTN consortium?

• 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 http//www.telescope-networks.org/ for
  details.

3
Why was the HTN inevitable?

• Better question is Why was the Internet
  inevitable?
• Just as we saw the Internet grow organically out
  of existing proprietary networks, so we might
  expect the emerging proprietary networks of
  telescopes to join together into more cohesive
  whole.
• Those scattered proto-networks already exist

4
What science can it do?

• There exists a large number of potential projects
  in the time domain that become much easier with
  access to global facilities and all-sky coverage.
• rapid Gamma-Ray Burst follow-up
• microlensing planet searches
• pre-main sequence star variability
• long term variable star monitoring
• supernova cosmology
• asteroid and near-Earth object discovery,
  recovery
• ground based support for satellite observations

5
The 1st HTN Workshop
Delegates at the 1st HTN Workshop in Exeter,
U.K., in July2005
Initial funding for the HTN was from an EPSRC
grant for Links to International e-Science
Sister Projects
6
The 2nd HTN Workshop
Delegates at the 2nd HTN Workshop in Göttingen,
Germany in July 2006
7
What did we discuss?

• Document standard
• Protocol standard
• Transport standard
• Event notification
• Establishing an e-Market

8
How far have we got?

• Document standard
• leverage the existing work on RTML
• Protocol standard
• leverage the existing work by eSTAR
• Transport standard
• Agreed on standard backbone transport
• Event notification
• interoperability with the VO
• use their VOEvent standard
• participate in standards process

9
Document standard

• Remote Telescope Mark-up Language (RTML)
• RTML 1.1 Experimentally used by HOU
• RTML 2.1 The official version of RTML
• RTML 2.2 Branch of 2.1 (a.k.a RTML eSTAR)
• RTML 3 Major re-write of the standard
• http//monet.uni-sw.gwdg.de/twiki/bin/view/RTML/We
  bHome

10
Protocol standard

• Resource discovery
• Where are the telescopes?
• Phase 0
• What services/capabilities does the telescope
  provide?
• Phase I
• Exchange of preliminary requests, and scoring
  responses, to evaluate the ability of the
  telescope to perform the desired observations.
• Phase II
• Exchange of observation request and the
  corresponding confirmation or rejection of the
  observing request.
• Data return
• Return of data and final status of the
  observations .

11
How does it work?
CREDIT Liverpool John Moores University
CREDIT The eSTAR Project
User Software
Telescope Software
User Interface
All other communications
The Grid
Resource discovery

• Resource discovery
• Phase 0
• Phase I (scoring)
• Phase II (observing)
• Data return

12
Event notification

• The evolution of VOEvent can be seen as a
  parallel strand to the standards proposed by the
  HTN.
• The proposed VOEvent standard has been designed
  to transport information concerning transient
  events.
• The proposed HTN standard has been designed to
  allow the recipient of an event message to
  negotiate for follow-up observations to these
  events.

13
What didnt we decide?

• Transport standard
• no single transport standard mandated
• e-Market
• barely got started on the discussion
• presence taken into account architecturally?

14
Transport standards

• Became clear during the meeting that the protocol
  for exchanging messages must be entirely neutral
  with respect to the underlying transport
  protocols.
• Future-proofs us against technological
  advancement.
• Also allows technologically simple
  implementations to be deployed today.

15
Does transport matter?

• Why? Nobody thought about RFC 1149 when IP
  datagram packets were standardised
• See http//www.blug.linux.no/rfc1149/

16
e-Market in telescope time

• Perhaps one of the few scalable ways of providing
  access to the growing number of robotic and
  remote telescopes.
• Architecturally perhaps the easiest way of
  allowing autonomous real-time access to these
  telescopes
• Otherwise we have to make numerous bi-lateral
  agreements between existing and future networks

17
The e-market architecture
Telescope
18
A place for the VO?
Telescope
The Virtual Observatory
19
Different types of e-market

• Centralised
• Semi-centralised
• Distributed
• Stone-age

20
Summary

• Paradigm we developed cuts across notions of
  master schedulers running a network of
  telescopes.
• However we were surprised at the degree of
  convergent thinking at both workshops.
• Need to agree protocols now, whilst the networks
  and their associated paradigms are in their
  infancy.

http//www.telescope-networks.org/