Scaling the Control Unit of KM3NeT to full detector

AbstraktAbstract

The KM3NeT Collaboration is incrementally building and operating two underwater Cherenkov neutrino telescopes, composed by modular units named DOMs (for Digital Optical Module), each one hosting 31 photomultipliers, and arranged in strings of 18, named DUs (for Detection Unit) anchored to the sea bed and kept in tension by a buoy. One telescope, named ORCA, will consist of a single building block of 115 DUs, whereas the larger one, ARCA, will consist of 2 building blocks for a total of 230 strings, i.e. ~4,000 DOMs and ~130,000 photomultipliers. Efficiently controlling so many objects is challenging, with the inevitable variety of network, hardware and firmware generations that can be expected in a multi-decade project such as KM3NeT. The Control Unit software has the task to maximise the livetime of the detector, automatically handling most common operations as well as several exceptional conditions, in a context where communications are not trivial and the controlled endpoints are instrumented devices floating in the seawater. The Control Unit collects incoming monitoring data from each DOM, including tiltmeter/compass data that help continuously reconstructing the changing shape of the detector in the currents, while at the same time it ensures that all DOMs and photomultipliers swiftly react to operating parameter adjustment requests. The architectural choices are discussed on a quantitative footing showing the increasing challenges of growing, complex machines. The evolution of the Control Unit software is taking place while the telescopes are taking valuable data, providing relevant physics output to the scientific community.

The KM3NeT Collaboration is incrementally building and operating two underwater Cherenkov neutrino telescopes, composed by modular units named DOMs (for Digital Optical Module), each one hosting 31 photomultipliers, and arranged in strings of 18, named DUs (for Detection Unit) anchored to the sea bed and kept in tension by a buoy. One telescope, named ORCA, will consist of a single building block of 115 DUs, whereas the larger one, ARCA, will consist of 2 building blocks for a total of 230 strings, i.e. ~4,000 DOMs and ~130,000 photomultipliers. Efficiently controlling so many objects is challenging, with the inevitable variety of network, hardware and firmware generations that can be expected in a multi-decade project such as KM3NeT. The Control Unit software has the task to maximise the livetime of the detector, automatically handling most common operations as well as several exceptional conditions, in a context where communications are not trivial and the controlled endpoints are instrumented devices floating in the seawater. The Control Unit collects incoming monitoring data from each DOM, including tiltmeter/compass data that help continuously reconstructing the changing shape of the detector in the currents, while at the same time it ensures that all DOMs and photomultipliers swiftly react to operating parameter adjustment requests. The architectural choices are discussed on a quantitative footing showing the increasing challenges of growing, complex machines. The evolution of the Control Unit software is taking place while the telescopes are taking valuable data, providing relevant physics output to the scientific community.