Prototyping the graphical user interface for the operator of the Cherenkov Telescope Array
PPrototyping the graphical user interface for the operator ofthe Cherenkov Telescope Array
I. Sadeh a , I. Oya a , J. Schwarz b , E. Pietriga c , and the CTA Consortium da DESY-Zeuthen, D-15738 Zeuthen, Germany b INAF - Osservatorio Astronomico di Brera, Italy c INRIA Saclay - Ile de France, LRI (Univ. Paris-Sud & CNRS), France d ABSTRACT
The Cherenkov Telescope Array (CTA) is a planned gamma-ray observatory. CTA will incorporate about 100imaging atmospheric Cherenkov telescopes (IACTs) at a Southern site, and about 20 in the North. PreviousIACT experiments have used up to five telescopes. Subsequently, the design of a graphical user interface (GUI)for the operator of CTA involves new challenges. We present a GUI prototype, the concept for which is beingdeveloped in collaboration with experts from the field of Human-Computer Interaction. The prototype is basedon Web technology; it incorporates a
Python web server,
Web Sockets and graphics generated with the d3.jsJavascript library.
Keywords:
The Cherenkov Telescope Array, graphical user interface, Web technology.
1. INTRODUCTION
The Cherenkov Telescope Array (CTA) is a planned observatory for very high-energy gamma-rays, sensitive toenergies from 20 GeV to a few hundred TeV. Gamma-rays induce particle cascades in the atmosphere. These areaccompanied by Cherenkov radiation, which is emitted by the charged particles in the cascade. The Cherenkovlight may be detected by imaging atmospheric Cherenkov telescopes (IACTs). Using multiple telescopes inconcert, Cherenkov showers can stereoscopically be sampled, allowing to reconstruct the properties of the primarygamma-ray.CTA will include three different telescope types, sensitive to different gamma-ray energy ranges. The tele-scopes will be deployed in two sites, Northern and Southern, which will respectively include about 100 andabout 20 telescopes. Currently running IACT experiments such as H.E.S.S., MAGIC and VERITAS, arerestricted to up to five telescopes. Compared to these instruments, the large number of CTA telescopes willimprove the sensitivity and the energy coverage of gamma-ray measurements by at least an order of magnitude.The large number of telescopes has implications for the development of a graphical user interface (GUI) forthe operator of a CTA site. The complexity of the system presents new and interesting challenges, requiringinnovative design. In the following, we detail the development process of the operator GUI. We discuss therequirements we have derived for the GUI, and describe our prototype implementation. ∗
2. DEVELOPMENT PROCESS AND REQUIREMENTS FOR THE GUI
In order to develop an effective user interface, we have drawn upon the lessons learned from the Atacama LargeMillimeter/submillimeter Array (ALMA). ALMA is an astronomical interferometer of radio telescopes in theAtacama desert of northern Chile. It will be comprised of up to 66 radio antennas, and so will be comparableto CTA in complexity.During the early stages of ALMA, conventional user interfaces were developed. Early experience operatingthe ALMA array with only a few antennas indicated that the latter were not adequate. The initial interfacesrequired many unnecessary interactions to access relevant information. This resulted in extraneous cognitive ∗ Media resources illustrating features of the prototype are available at . a r X i v : . [ a s t r o - ph . I M ] A ug oad, and was not efficient for quick diagnosis of system problems. The implementation was therefore improved,taking into account advances in the field of Human-Computer Interaction (HCI). For creating the GUI for the operator of CTA, we are following the design process used for ALMA. TheGUI is being developed by involving experienced telescope operators and astroparticle physicists on the onehand, and experts from the field of HCI on the other. In contrast to ALMA, we have been able to adopt thismodel at the start of the design process for CTA. We will therefore be able to apply HCI input to all aspectsof the operator interface. The development process includes practical face-to-face meetings, in tangent withbrainstorming workshops with representatives of the relevant stakeholders. To date, we have held two suchparticipatory design workshops. The outcome of the meetings is twofold. For one, the workshops helped usto refine the scope of the operator GUI, i.e., answer the question, “what should the GUI enable users to do?”.Additionally, we have defined a preliminary set of panels for the GUI. That is, we have began to address thequestion, “how should the GUI be designed?”.With regards to the first question, we first note that on-site operations related to observing with CTA willnormally be automated. Consequently, the GUI for the operator of a CTA site will nominally be used to performthe following tasks:1. initiate and end observations;2. override the automated scheduled operations in order to perform a specific task, or for safety reasons, whichmight require manual control over a given telescope or group of telescopes;3. monitor the state of the array during data acquisition, which includes monitoring of low-level hardwarecomponents, of software processes, and of the output of a near real-time data analysis;4. identify and diagnose problems with specific sub-systems or processes, in order to solve minor problems orto notify technical experts, as needed.With regards to the second question, we have defined the following categories, which will be represented bydifferent GUI panels (some of which may overlap):1.
Telescope: monitor the status of telescopes and their respective sub-systems; manually control singletelescopes and sub-arrays, etc.2.
Process: monitor and modify predefined operation sequences, such as starting up the array at the begin-ning of the night, and performing a scheduled observing task.3.
Science: monitor the output of a physics analysis on the level of a single telescope or of a sub-array,including trigger rates, event-reconstruction metrics, science summary reports, etc.4.
Infrastructure: monitor the status of auxiliary systems, such as the power grid, as well as other indicators,such as alarms and data transfer rates.5.
Environment: monitor environmental systems, such as weather monitors, all-sky cameras, etc.6.
Miscellaneous: provide access to terminals, shift logs, expert call sheets, etc.With these guidelines in mind, we have identified the following set of initial requirements for the GUI:1. the GUI will be able to convey information for various levels of telescope multiplicity; on the level ofthe entire array ( ∼
100 telescopes); the level of sub arrays (between 1 and 32 groups); or the level of asingle telescope and the associated sub-systems. Multi-telescope views for a given sub-system will also beavailable, which will take into account differences between telescope types. The various levels of informationwill be integrated using semantic zooming (defined below);2. the GUI will need to be highly responsive, where the different panels of the GUI will have the option tobe synchronized; 2. the GUI will integrate different interfaces to CTA software (databases, live feeds etc.) with various latencies;4. the different components of the GUI will be modular, allowing for quick updates and for collaborativedevelopment.In the next section, we illustrate the requirements for the operator GUI using a prototype design. At thisstage of development, the prototype by no means addresses the complete scope of the GUI. Instead, it acts as aproof of concept for those features which were identified as most important.
3. PROTOTYPING ACTIVITIES
Our prototype is based on Web technologies. A Web-based framework has the advantage of being lightweight andmodular. It also naturally allows for remote access, which will enable the GUI to be used for remote monitoring,and for remote operation. These will be useful both for physicists and for technical experts, who the operator ofthe array will need to consult.The back-end of the prototype is a
Python server called
Pyramid . † A Python framework has the advantage ofbeing very versatile, incorporating the ability to use many off-the-shelf libraries for computation, communication,multi-threading and multi-processing. The front-end is a web browser. The design is responsive, i.e., adjustableaccording to the width of the display. It is implemented using
Polymer , ‡ a Web Component application pro-gramming interface (API), developed by
Google , based on the
Material Design § concept. Data are displayedusing an open-source Javascript library, called d3.js . ¶ The latter is a data-driven framework, with integratedmechanisms for displaying, updating and animating vector graphics. Communication between the back-end andthe front-end of the GUI is performed using
Web Sockets . These allow asynchronous communication, facili-tating quick and robust GUI behaviour. For plotting, we also use dc.js , (cid:107) a library based on d3.js and on Crossfilter . ∗∗ The latter is a
Javascript library, which facilitates exploring large multivariate datasets.Figure 1 shows a representation of the layout of a CTA array, where each circle corresponds to a singletelescope. The relative position of telescopes corresponds to a scaled physical layout on-site, constituting apseudo-geographic display of the array. The attached numerical values and the colour scheme of elementscorrespond to a health metric . This metric may represent different properties according to the visualizationcontext . The panel incorporates semantic zooming , which defines the context. Semantic zooming is a techniqueof assigning different layers of information to a given visual element. This behaviour complements the usualgeometric zooming, where the size of elements changes with the zoom factor. For the type of semantic zoomimplemented in this example, the level of detail associated with an element increases as one zooms-in. The figureshows the evolution of the display for different zoom factors, as follows. Zoom factor : Figure 1(a) shows a global view of all telescopes, emphasizing physical positions, as wellas a general health metric. In this example, health corresponds to the combined health of all sub-systems ofthe telescope. For illustration, one of these sub-system, the camera, reports reduced health as the percentage ofdead pixels.
Zoom factor : Given this zoom level, Fig. 1(b) shows how the display changes for a given element which ishovered over. The hover action triggers a transition, where a circle representing a single telescope is replaced bya more detailed view of the associated sub-systems. The context from the previous zoom level is preserved duringthe transition. The health metric, which was previously represented by the full circle, has morphed into the redcircle surrounding the four wedges. Each of the wedges represents one of the sub-systems of a telescope: thedata-acquisition system (DAQ); the camera; the mirror system; and the mount (the structure of the telescope).Each of the latter now also reports its individual health metric. These are represented numerically, by colourand by the percentage of filled area within the corresponding wedge. † See http://docs.pylonsproject.org/projects/pyramid/ . ‡ § See https://design.google.com/ . ¶ See https://d3js.org/ . (cid:107)
See https://github.com/dc-js/dc.js . ∗∗ See http://square.github.io/crossfilter/ . a) (b)(c) (d)Figure 1. Pseudo-geographic display of a CTA array, showing different semantic zoom levels, as described in the text.The zoom factors are 1 in (a), 7 in (b), and ∼
14 in (c) and (d). oom factor ∼ : Given this zoom level, another transition occurs. Figure 1(c) shows a second level ofcomponents, which is exposed for each of the four sub-systems. As before, the context from the previous zoomlevel is preserved; the health metric of each of the sub-systems is now represented by a thin outer arc. The innerwedges now each have different layouts of components. These are arranged in sunburst diagrams , which are ahierarchical variation on a pie chart. The change from the view shown in Fig. 1(c) to that shown in Fig. 1(d)occurs as the user clicks on the wedge of the mount. The sunburst diagram of the latter then opens up to afull 360 ◦ , and the wedges of the DAQ, camera and mirror disappear. The generic names ( mount 0 , mount 1 ,etc.) are temporary place-holders for different elements of the mount sub-system, such as drivers and PLC(programmable logic controller) status indicators.Figure 2 presents another telescope-centric view. In this case, two synchronized panels are provided side byside. The panel on the left shows the positions on the sky, at which telescopes point. The polar plot has twocoordinates. The angular coordinate, denoted by ϕ , represents the azimuth on the sky; it spans the range from 0 ◦ (at the top-most position of the circle) to 180 ◦ (for the right-hand side), and 0 ◦ to − ◦ (for the left-hand side).The radial coordinate, denoted by δ , indicates the elevation, with values between 0 ◦ (at the edge of the figure)and 90 ◦ (on the centre). Telescopes are represented by full circles. Each one has an intended target position,indicated by rings, where faint dashed lines connect telescopes and targets. The display is updated in real-time,showing the movement of telescopes from their initial pointing, towards their respective target positions.The panel on the right shows a logical grouping of telescopes, as opposed to the pseudo-geographic displayof Fig. 1. In this case, telescope positions indicate association to a sub-array, which here stands for a group oftelescopes which all point at the same target on the sky. This type of visualization, called an enclosure diagram ,is a hierarchical nested layout of elements. In this case, grey-shaded circles represent sub-arrays, with colouredcircles standing for telescopes.Both the panel on the left and that on the right incorporate semantic zooming, as indicated by comparingFigs. 2(a), 2(b), and 2(c). For the left panel, the behaviour is a simple scaling of elements. As one zooms in orout, the size of telescopes and targets changes very slowly with respect to the changing scale of the coordinatesystem. For the panel on the right, the semantic zoom includes a threshold transition at zoom factor ∼ ϕ and δ coordinates of the telescope and its target, using the same visual language as for the panel onthe left. Another threshold transition occurs at zoom factor ∼
14, as presented in Fig. 2(c). In this instance, thepurpose of the visualization is to provide detailed information, regarding the coordinates at which the telescopeis pointing.The two panels are synchronized using brushing and linking, following the principles of coordinated multipleviews. In Fig. 2(b), a sub-array is selected on the right panel; this causes the associated elements in the panelon the left to become highlighted. Such behaviour allows to quickly identify in the display on the left, whichtelescopes are assigned to which sub-array. In Fig. 2(c), the single selected telescope is similarly the only elementin focus, both on the right panel and on the left. The interplay between the two panels illustrated here alsoserves to demonstrate an important feature of panel-synchronization. Namely, that synchronization need notnecessarily work both ways. As in this case, user interactions with the panel on the right affect the panel on theleft by focusing specific elements, but the reverse does not hold.Figure 3 shows three views of a panel featuring monitoring plots. In this example, the data are extractedfrom the database of a weather monitoring station. They include measurements of the humidity inside andoutside of the weather station, of the speed and direction of the wind near the station, and of the atmosphericpressure. The monitoring plots are placed inside a container, designated as a
Dashboard . Plots may be resizedand dragged within the Dashboard, or placed in separate Dashboards. The plots are generated using dc.js .They are correlated (a feature of
Crossfilter ), as shown in, e.g., Fig. 3(b). In this case, the user has selecteda range of values of the atmospheric pressure parameter (marked by the blue brush). The other plots reflectthe selection, by showing only those measurements which have a corresponding atmospheric pressure within thechosen range. A side-menu may be overlaid on top of the plots, as shown in Fig. 3(c). Several control optionsexist. To name a few, the user may add new plots; the user may select new dates for querying the database; andthe user may switch to a live-mode , where real-time data are updated every few seconds.5 a)(b)(c)Figure 2. Synchronized panels, showing the positions on the sky at which telescopes point (left), and the grouping oftelescopes into sub-arrays (right), as described in the text. The zoom factors for the panel on the right are 1 in (a), 2in (b), and ∼
14 in (c). a)(b) (c)Figure 3. Example of a monitoring panel, featuring data extracted from the database of a weather monitoring station.These include measurements of the humidity inside and outside of the weather station, of the speed and direction of thewind near the station, and of the atmospheric pressure. (a) : A selection of data monitoring plots. (b) : Illustration ofthe synchronization of plots. A selected range of values of the atmospheric pressure parameter (shaded in blue), affectsthe other plots, by excluding data outside of the chosen scope. (c) : A side-menu with various control options may beoverlaid on top of the plots, upon clicking the purple button on the top right corner. The option also exists (not shown),of pinning the menu alongside the plots instead. dc.js library for generating synchronized plots; testing the performance of an interfacebetween the Python web-server and an external database; splitting data processing tasks between the
Python server and the web browser client. The results of these tests have so far been encouraging; they have indicatedthat a web-based framework is suitable for the next stages of development of the operator GUI.
4. SUMMARY
The planned Cherenkov Telescope Array will be comparably more complex than existing IACT experiments.This poses new challenges for creating an effective graphical user interface for the operator of the array.The development of the GUI for CTA follows the successful working model of the ALMA experiment. Thedesign process brings together experienced telescope operators and astroparticle physicists on the one hand,and experts from the field of Human-Computer Interaction on the other. The relevant stakeholders have sofar conducted two participatory design workshops, in addition to other face-to-face meetings. The outcome ofthe work to date is: a refined definition of the scope of the GUI and of the requirements on its performance; apreliminary list of GUI panels; identification of a set of relevant data visualization techniques.A preliminary prototype of several GUI panels has been implemented. It is based on Web technologies,incorporating a
Python web server,
Web Sockets and graphics generated with the d3.js Javascript library.The prototype illustrates semantic zooming and coordinated multiple views, and serves for performance testingof the proposed technology.
ACKNOWLEDGMENTS
We would like to thank Caroline Appert, Antonio Cabrera, Francesco Dazzi, Valentina Fioretti, Stafano Gabici,Markus Garczarczyk, Rosa Macias and the members of the ACTL team, for their helpful comments and insights.
REFERENCES [1] Actis, M. et al., “Design concepts for the Cherenkov Telescope Array CTA: an advanced facility for ground-based high-energy gamma-ray astronomy,”
Experimental Astronomy , 193–316 (Dec. 2011).[2] Fuessling, M., Oya, I., Balzer, A., et al., “Status of the array control and data acquisition system for thecherenkov telescope array,” Proc. SPIE , 99133C–99133C–12 (2016).[3] Oya, I., Fuessling, M., Antonino, P. O., et al., “The software architecture to control the cherenkov telescopearray,”
Proc. SPIE , 991303–991303–15 (2016).[4] Hillas, A., “Evolution of ground-based gamma-ray astronomy from the early days to the cherenkov telescopearrays,”
Astroparticle Physics , 19 – 43 (2013). Seeing the High-Energy Universe with the CherenkovTelescope Array - The Science Explored with the CTA.[5] Aharonian, F. et al., “Observations of the Crab nebula with H.E.S.S.,” A&A , 899–915 (Oct. 2006).[6] Albert, J. et al., “VHE Gamma-Ray Observation of the Crab Nebula and Pulsar with MAGIC,” Astrophys.J. , 1037–1055 (2008).[7] Holder, J. et al., “The first VERITAS telescope,”
Astropart. Phys. , 391–401 (2006).[8] Wootten, A. and Thompson, A. R., “The Atacama Large Millimeter/Submillimeter Array,” IEEE Proceed-ings , 1463–1471 (Aug. 2009).[9] Pietriga, E. et al., “Interaction design challenges and solutions for ALMA operations monitoring and con-trol,” in [ SPIE Astronomical Telescopes and Instrumentation ], SPIE, ed.,
Proc. SPIE 8451, Software andCyberinfrastructure for Astronomy II , SPIE (July 2012).[10] Perlin, K. and Fox, D., “Pad: An alternative approach to the computer interface,” in [
Proceedings of the20th Annual Conference on Computer Graphics and Interactive Techniques ], SIGGRAPH ’93 , 57–64, ACM(1993).[11] Stasko, J., Catrambonw, R., Guzdial, M., and McDonald, K., “An evaluation of space-filling informationvisualizations for depicting hierarchical structures,”
Int. J. Hum.-Comput. Stud. , 663–694 (Nov. 2000).812] Behera, B., Oya, I., Birsin, E., K¨oppel, H., Melkumyan, D., Schlenstedt, S., Schmidt, T., Schwanke, U.,Wegner, P., Wiesand, S., and Winde, M., “Development of the ACS+OPC UA based control system for aCTA medium size telescope prototype,” in [ Software and Cyberinfrastructure for Astronomy II ], Proc. SPIE , 84510H (Sept. 2012).[13] North, C. and Shneiderman, B., “Snap-together visualization: a user interface for coordinating visualizationsvia relational schemata,” in [