The Control Unit of the KM3NeT Data Acquisition System

SPIE Proceedings, 2006

An alarm system is a cornerstone service in every computer controlled environment. Its purpose is the notification of exceptional conditions in the system requiring an intervention from the staff. The specifications for the alarm system in the Alma Common Software (ACS) require not only that each alarm has to be shown to operators in a short time, but also that correlated alarms must be "reduced" and presented in compact form in such a way that operators are able to easily identify the root cause for an abnormal condition. In the development of ACS we always investigate the availability of adequate implementations before writing a service from scratch. Such an implementation, the CERN Laser Alarm System, developed for the Large Hadron Collider, was fulfilling and exceeding our requirements. We have therefore started a pilot collaboration project to verify the possibility of integrating Large Hadron Collider Alarm Service (LASER) into ACS. A test suite was developed to demonstrate that the full chain of events starting from the publication of new alarms from a set of sources to their representation in a GUI happened as expected. Particular attention was given to the reduction mechanism for its importance in helping the operators in finding the real cause of each problem in a short time. The project showed that it is possible to integrate two different software systems if they are written with well defined interface and have a similar infrastructure. In this paper we describe the modifications we introduce to integrate CERN LASER into ACS.

Software and Cyberinfrastructure for Astronomy V, 2018

The SKA project is an international effort (10 member and 10 associated countries with the involvement of 100 companies and research institutions) to build the world's largest radio telescope. The SKA Telescope Manager (TM) is the core package of the SKA Telescope aimed at scheduling observations, controlling their execution, monitoring the telescope and so on. To do that, TM directly interfaces with the Local Monitoring and Control systems (LMCs) of the other SKA Elements (e.g. Dishes), exchanging commands and data with them by using the TANGO controls framework. TM in turn needs to be monitored and controlled, in order its continuous and proper operation is ensured. This higher responsibility together with others like collecting and displaying logging data to operators, performing lifecycle management of TM applications, directly dealwhen possible -with management of TM faults (which also includes a direct handling of TM status and performance data) and interfacing with the virtualization platform compose the TM Services (SER) package that is discussed and presented in the present paper.

Observatory Operations: Strategies, Processes, and Systems III, 2010

Operating a modern telescope requires many software systems working together to maintain/monitor the optomechanical positions, sequence and control individual instruments and wave-front sensors and control the data transfer and quality monitoring. Supporting these complex interconnected systems can be a daunting task, especially when any single failure can cause a cascade effect which tends to hide the original problem.

2023

KM3NeT is a multi-site neutrino telescope under construction in the depth of the Mediterranean Sea, consisting of two Cherenkov telescopes, ARCA and ORCA, both of which are currently in data-taking. Among the primary scientific goals of KM3NeT are the observation of cosmic neutrinos and the investigation of their sources. ARCA and ORCA are optimized in complementary energy ranges, allowing for the exploration of neutrino astronomy from MeV to tens of PeV. The combination of an extended field of view and a high duty cycle of Cherenkov-based neutrino detectors is crucial for detecting and informing other telescopes about interesting neutrino candidates in a very short time. As emission from these sources can rapidly fade, the alerts need to be shared with low latency, in order to allow for a prompt follow-up in the multi-messenger and multi-wavelength domains, particularly for the detection of transient and variable sources. In the case of poorly localized triggers, such as gravitational waves, KM3NeT can provide refined pointing directions, representing a further advantage. This contribution reports on the status of the software architecture implemented in KM3NeT for a fast reconstruction and classification of events occurring in the detectors. Additionally, the results of the online processing of KM3NeT data in coincidence with GRB221009A will be presented.

Proceedings of the IEEE, 1991

The next generation space data systems currently in the planning stages are being designed to implement standardized and internationally agreed upon teckniques of data handling, data classification, and data transmission. These techniques are for the most part being developed by the Consultative Committee for Space Data Systems (CCSDS), a worldwide cooperative effort of national space agencies. In this paper we present a comprehensive discussion of three major aspects of the work of the CCSDS. First, we examine the CCSDS space data communications network concept on which the data communications facilities of future advanced orbiting systems will be based. Second, we derive the specifications of an open communications architecture as a reference model for the development of services and protocols that support the transfer of information over space data communications networks. Third, we offer detailed specifications of the communication services and information transfer protocols that have reached a high degree of maturity and stability. The paper also includes a complete list of currently available CCSDS standards and supporting documentation. I. INTRODUCTION In somewhat simplified terms, a space data system is designed to achieve two basic objectives. First, it provides for the bidirectional exchange of information between groundbased users such as experimenters, application processes, data archives, and mission controllers, on the one hand, and the science instruments, data processors, tape recorders, controllers and other equipment onboard a spacecraft on the other. Second, it offers facilities for the processing, storage, archiving, and subsequent retrieval of the information obtained from onboard experiments or ground-based command and control centers. To accomplish these objectives the physical and logical components of a space data system cooperate to provide services to the onboard and ground based users. One may distinguish between services in which the users belong to

The National Aeronautics and Space Administration (NASA) Space Communications and Navigation office (SCaN) has commissioned a series of trade studies to define a new architecture intended to integrate the three existing networks that it operates, the Deep Space Network (DSN), Space Network (SN), and Near Earth Network (NEN), into one integrated network that offers users a set of common, standardized, services and interfaces. The integrated monitor and control architecture utilizes common software and common operator interfaces that can be deployed at all three network elements. This software uses state-of-the-art concepts such as a pool of re-programmable equipment that acts like a configurable software radio, distributed hierarchical control, and centralized management of the whole SCaN integrated network. For this trade space study a model-based approach using SysML was adopted to describe and analyze several possible options for the integrated network monitor and control architecture. This model was used to refine the design and to drive the costing of the four different software options. This trade study modeled the three existing self standing network elements at point of departure, and then described how to integrate them using variations of new and existing monitor and control system components for the different proposed deployments under consideration. This paper will describe the trade space explored, the selected system architecture, the modeling and trade study methods, and some observations on useful approaches to implementing such model based trade space representation and analysis.

2019

The CMS Detector Control System (DCS) is implemented as a large distributed and redundant system, with applications interacting and sharing data in multiple ways. The CMS XML-RPC is a software toolkit implementing the standard Remote Procedure Call (RPC) protocol, using the Extensible Mark-up Language (XML) and a custom lightweight variant using the JavaScript Object Notation (JSON) to model, encode and expose resources through the Hypertext Transfer Protocol (HTTP). The CMS XMLRPC toolkit complies with the standard specification of the XML-RPC protocol that allows system developers to build collaborative software architectures with self-contained and reusable logic, and with encapsulation of well-defined processes. The implementation of this protocol introduces not only a powerful communication method to operate and exchange data with web-based applications, but also a new programming paradigm to design service-oriented software architectures within the CMS DCS domain. This paper p...

Fusion Engineering and Design, 2006

The steady state superconducting tokamak (SST-1) central control system is a distributed heterogeneous process communication system built on socket programming. It consists of machine, experiment and discharge control plus timing and a database. The software controls and monitors SST-1 subsystems: water-cooling, power supplies, cryogenics and vacuum over a local area network (LAN). The SST-1 control room is the place where all the activities like session announcement, machine control, experiment control, discharge control and monitoring are performed. We have realized that, instead of having a single monitoring place, we should have multiple monitoring points and it should be made possible to control the experiment from any PC over the LAN. In order to meet such requirements for remote participation in tokamak operation, we are upgrading the existing software. The upgraded software is based on Common Object Request Broker Architecture (CORBA) technology. The software is utilizing CORBA-services such as event service, naming services, interface repository and security services. The inherent features of CORBA make the software, platform and language independent. The software supports a variety of communication paradigms including publish-subscribe, peer-to-peer, and request-reply. Based on this software, one can participate in SST-1 tokamak operation from the LAN, or a wide area network (WAN) connection anywhere on the Internet. Each user can customize plasma parameters and diagnostics data that he wants to monitor, at any time without any change in the software and a copy of these parameters will be available to him. This paper focuses on the publish-subscribe communication paradigm and its application for a machine monitoring system.

Proceedings of 37th International Cosmic Ray Conference — PoS(ICRC2021), 2021

We present the current development of the Monitoring, Logging and Alarm subsystems in the framework of the Array Control and Data Acquisition System (ACADA) for the Cherenkov Telescope Array (CTA). The Monitoring System (MON) is the subsystem responsible for monitoring and logging the overall array (at each of the CTA sites) through the acquisition of monitoring and logging information from the array elements. The MON allows us to perform a systematic approach to fault detection and diagnosis supporting corrective and predictive maintenance to minimize the downtime of the system. We present a unified tool for monitoring data items from the telescopes and other devices deployed at the CTA array sites. Data are immediately available for the operator interface and quick-look quality checks and stored for later detailed inspection. The Array Alarm System (AAS) is the subsystem that provides the service that gathers, filters, exposes, and persists alarms raised by both the ACADA processes and the array elements supervised by the ACADA system. It collects alarms from the telescopes, the array calibration, the environmental monitoring instruments and the ACADA systems. The AAS subsystem also creates new alarms based on the analysis and correlation of the system software logs and the status of the system hardware providing the filter mechanisms for all the alarms. Data from the alarm system are then sent to the operator via the human-machine interface.

Journal of Astronomical Telescopes, Instruments, and Systems, 2021

The KM3NeT infrastructure consists of two deep-sea neutrino telescopes being deployed in the Mediterranean Sea. The telescopes will detect extraterrestrial and atmospheric neutrinos by means of the incident photons induced by the passage of relativistic charged particles through the seawater as a consequence of a neutrino interaction. The telescopes are configured in a three-dimensional grid of digital optical modules, each hosting 31 photomultipliers. The photomultiplier signals produced by the incident Cherenkov photons are converted into digital information consisting of the integrated pulse duration and the time at which it surpasses a chosen threshold. The digitization is done by means of time to digital converters (TDCs) embedded in the field programmable gate array of the central logic board. Subsequently, a state machine formats the acquired data for its transmission to shore. We present the architecture and performance of the front-end firmware consisting of the TDCs and the state machine. © The Authors. Published by SPIE under a Creative Commons Attribution 4.0 Unported License. Distribution or reproduction of this work in whole or in part requires full attribution of the original publication, including its DOI.