# Trends in Architecture and Middleware of Radio Telescope Control System

Authors: Jun Li; Na Wang; Zhiyong Liu; Yining Song; Ning Li; Lingming Xu; Jili Wang
Journal: Advances in Astronomy
 (2021)

---

## Abstract

The control system is the central control unit of the radio telescope. It is used to monitor, control, coordinate, and manage software and hardware systems so as to satisfy the requirements of high-precision control in astronomical observation of radio telescope. The control system architecture is the foundation for the implementation of the control system, which determines the stability, scalability, and maintainability of the control system. Furthermore, the architecture design of the control system is closely geared towards the technological development of radio telescope and computer software architecture. In this article, we analyze the characteristic of the control system of a radio telescope in various steps and discuss the development of their architecture and middleware framework. System architecture and middleware framework of control system also serve as a useful reference for the design of other radio telescope control systems.


---

## Body

## 1. Introduction

The development of radio telescope drives the research of radio astronomy dramatically. Meanwhile, the progress of astronomy has put forward higher requirements for radio telescope. In the early days, radio telescopes have a simple equipment structure, a single business logic functionality of software [1, 2]. However, with the increase of scientific needs, the continuous breakthroughs in key technologies of radio telescope, the degree of automation, and the requirements of antenna accuracy are also continuously improved. Therefore, modern radio telescopes have a wide distribution and variety of hardware devices, which makes the business logic between the hardware devices complex and various, leading to an exponential increasing of control system complexity [3–5].Since the 21st century, radio telescopes have developed rapidly in both single dish and array antennas [6, 7]. For single dish antenna, Green Bank Telescope (GBT) [8], Tianma Radio Telescope (TMRT) [9], Sardinia Radio Telescope [10], Five-hundred-meter Aperture Spherical radio Telescope (FAST) [11], Qitai Radio Telescope (in the construction phase) [12], and other radio telescopes [13–15] with a large aperture, wide band, high sensitivity have been built. Astronomical observation introduces large quantities of auxiliary control and measuring equipment, mainly including active surface control, subreflector adjustment, laser interferometry, meteorological measurements, and electromagnetic environment monitoring. These devices are helpful for real-time tracking and high-precision pointing of astronomical observation objects by radio telescope. Furthermore, the complicated radio telescope puts forward higher requirements on the logical structure of architecture design of the control system, which greatly increases the complexity of the control system. For array antennas, large-scale array antennas such as Atacama Large Millimeter Array (ALMA) [16], LOFAR [17], Giant Metrewave Radio Telescope (GMRT) [18], Australian Square Kilometre Array Pathfinder (ASKAP) [19], and MeerKAT [20] have been built, as well as the planned Square Kilometre Array (SKA) [21]. The multinode collaborative work of these array telescopes presents new challenges to the expansibility and cooperativity of the control system.The control system is the core of the radio telescope. It is used to coordinate and manage the antenna, receiver, terminal, measurement sensor, and other subsystems of radio telescope. The software of these subsystems uses different technologies, such as cross platforms, multiple languages, and interface definition [22]. The design of the control system needs to comprehensively consider the runtime environment, scientific requirements of each subsystem, and incorporate the design concepts of software architecture, especially the middleware framework that accompanies the development of software architecture. In this article, we will analyze the control system of modern radio telescope and focus on the control system architecture, middleware framework, and their development trend. Section 2 analyzes the control system architecture and its development trend; Section 3 analyzes the middleware framework and its development used by the control system; Section 4 summarizes the full text.


## 2. Control System Architecture

Control system architecture is the general planning for the design of a radio telescope and is the foundation of control system implementation. Its design is directly associated with scientific requirements, radio telescope key technology, and computer software technology. Control systems in different periods use different software architectures; hence, these architectures are classified into three stages.


### 2.1. The First Stage Is before the 1990s

Owing to the relatively single scientific requirements, fewer hardware devices of radio telescope, simple device functions, and less business logic function between subsystems, the control system was built with a centralized architecture to satisfy the requirements of radio telescope. The centralized architecture was mainly applied in early radio telescopes, such as the 30 m Millimeter Radio telescope control system [1], Effelsberg control system [23], Nobeyama Radio Observatory 45 m (NRO45M) telescope control system [24], and Parkes control system [25]. This type of control system centrally processed all the business logic of antenna, receiver, and other subsystems. The control system adopted code level or library file call, which had the advantages of simple structure, short development cycle, and easy deployment. Notwithstanding, code dependence between antennas, receivers, and other subsystems was strong, resulting in a high degree of coupling and poor extensibility of the control system. When the hardware, software interface, or library file of the subsystem changes, the entire control system may need to be updated, resulting in poor maintainability and portability of the control system.


### 2.2. The Second Stage Is from the 1990s to the Beginning of the 21st Century

With the increase of science requirements, the growing number of hardware devices and auxiliary devices, devices function becoming more complex, and more complicated business logic between subsystems, centralized control systems could not flexibly add, delete, or update devices or functions. Therefore, distributed architecture satisfied these requirements of radio telescope by using modular design, such as Effelsberg control system [2], NRO45M telescope control system [26], and GBT enterprise software [27]. This type of control system coordinated and managed the antenna, receiver, terminal, and other subsystems of the radio telescope. Any of the subsystems was divided into one or more modules. For example, the antenna subsystem was compartmentalized into an active surface, servo, and other modules. The development, testing, deployment, and operation of these modules were carried out independently, and a unifying communication mechanism is adopted between the modules. Above all, the design of the control system modules needed to consider all requirements of the radio telescope and the dependency relationship with other modules. In addition, the division of module boundaries and the definition of interface parameters affected the performance of the control system, making the predesign of the control system more complicated. In a word, a high-performance control system could add, delete, modify, or update functions or modules at any time so that the control system has good scalability and easy maintenance.


### 2.3. The Third Stage Is from the Beginning of the 21st Century to the Present

As a result of the rapid growth of scientific requirements, the growing types of hardware devices and auxiliary devices, the complex functions of devices, and more complicated business logic between subsystems, the second-stage distributed control system had poor support for multiprogramming language and cross-platform. However, the middleware framework solved these problems, which shielded complex implementation details and provided a unified interface. Therefore, a distributed architecture based on middleware framework was organized into two ways: (1) Service-Oriented Architecture (SOA) based on middleware framework [28], such as Large Millimeter Telescope (LMT) monitoring and control system [29] and TMRT distributed control software [30]; (2) the combination of SOA and event-driven architecture (EDA) based on middleware framework, such as ALMA software [31], ASKAP monitoring and control system [32], and GMRT control and monitoring system [33]. This type of control system coordinated and managed the software and hardware subsystems, such as antennas, receivers, and terminals divided any subsystem into one or more components. For example, the terminal subsystem was classified as components such as VLBI joint measurement, single antenna observation, and antenna measurement. These components were independently developed, tested, deployed, and run and were connected by a middleware framework. Middleware framework simplified complex interfaces such as operating system, network, and database into simple and unified interfaces, integrated SOA, or the combination of SOA and EDA into its design. Among them, the control system based on SOA is mainly used for the analysis and execution of control commands. In addition, the control system based on EDA is mainly used for monitoring devices and control systems. When designing the control system, the interface parameters of each component need to consider the overall requirements of the radio telescope and the dependence on other components. At the same time, the division of component boundaries and the definition of interface parameters affect the performance of the control system and increase the complexity of the control system’s early design. Compared with the control system of the second stage, the control system has lower complexity, better scalability, and higher maintainability and supports more platforms and programming languages.In conclusion, software architecture applied to control system changes from a centralized architecture to a distributed architecture without a middleware framework and then to a distributed architecture based on middleware framework. Table1 compares the advantages/disadvantages of the three-stage control system in terms of communication method, application requirements, business logic, and development difficulty. The first stage centralized control system has the benefits of simple development, short developing period, low cost, and easy deployment. However, this type of control system has some shortcomings, mainly including the inability to flexibly add, delete, and update functions and subsystems; it has the characteristics of weak extension, poor maintenance, and low portability; application code between subsystems has strong dependencies. The advantages of the second-stage distributed control system mainly include the following: modular design improves code reusability and development efficiency; modules can be independently developed, tested, deployed, and run; system is easy to add, delete, or modify modules or subsystems. Notwithstanding, the control system at this stage has some shortcomings. For example, the early stage of control system design is complex and cross-language and platform support is poor; calling relation between subsystems is complex and difficult to maintain; software engineers use complex underlying interfaces such as operating systems and networks to implement control system. The merits of the third stage distributed control system mainly include the following: middleware framework provides a simple, unified standard interface for control system development; the component granularity is smaller than the second-stage module granularity; control system has the characteristics of good scalability, high maintainability, and supports multiplatform cross-language. However, this type of control system has some shortcomings. For example, the division of component boundaries affects the performance of the control system; the logical relationship between components is complex, which makes it difficult to operate, test, and deploy the control system.Table 1
Comparison the characteristics of the three-stage control system.
NameThe first stage: centralized control systemThe second stage: distributed control system without middleware frameworkThe third stage: distributed control system based on middleware frameworkCommunication methodTCP/IP, UDPTCP/IP, UDPMiddleware (ICE, TANGO, EPICS)Granularity—CoarseFineApplication requirementsSingle scientific requirements, centralized hardware distribution, simple equipment functions, single business logic functionMany kinds of hardware equipment and auxiliary equipment, complex functions of equipment, complicated business logicMany types of hardware and auxiliary equipment, very complicated equipment functions, and quite complicated business logicCall levelCode level, libraryModularityComponent, serviceInvocation styleCall between functions or modulesInterprocess callInterprocess callBusiness logicCentralized processing of all functionsExtract core business and improve module reuseIncrease the dispatch center to manage the service, the service call is transparent, and there is no need to care about dependenciesDevelopment difficultyLowHighMediumMaintainabilityWeakStrongMediumDeployment methodCentralized deployment of all functionsDistributed deployment with independent modulesIndependent distributed deployment of components and servicesBecause there are many kinds of radio telescope hardware devices, complicated structure, huge functions, and complex business logic, modern radio telescope control systems use a distributed architecture based on a middleware framework.


## 2.1. The First Stage Is before the 1990s

Owing to the relatively single scientific requirements, fewer hardware devices of radio telescope, simple device functions, and less business logic function between subsystems, the control system was built with a centralized architecture to satisfy the requirements of radio telescope. The centralized architecture was mainly applied in early radio telescopes, such as the 30 m Millimeter Radio telescope control system [1], Effelsberg control system [23], Nobeyama Radio Observatory 45 m (NRO45M) telescope control system [24], and Parkes control system [25]. This type of control system centrally processed all the business logic of antenna, receiver, and other subsystems. The control system adopted code level or library file call, which had the advantages of simple structure, short development cycle, and easy deployment. Notwithstanding, code dependence between antennas, receivers, and other subsystems was strong, resulting in a high degree of coupling and poor extensibility of the control system. When the hardware, software interface, or library file of the subsystem changes, the entire control system may need to be updated, resulting in poor maintainability and portability of the control system.


## 2.2. The Second Stage Is from the 1990s to the Beginning of the 21st Century

With the increase of science requirements, the growing number of hardware devices and auxiliary devices, devices function becoming more complex, and more complicated business logic between subsystems, centralized control systems could not flexibly add, delete, or update devices or functions. Therefore, distributed architecture satisfied these requirements of radio telescope by using modular design, such as Effelsberg control system [2], NRO45M telescope control system [26], and GBT enterprise software [27]. This type of control system coordinated and managed the antenna, receiver, terminal, and other subsystems of the radio telescope. Any of the subsystems was divided into one or more modules. For example, the antenna subsystem was compartmentalized into an active surface, servo, and other modules. The development, testing, deployment, and operation of these modules were carried out independently, and a unifying communication mechanism is adopted between the modules. Above all, the design of the control system modules needed to consider all requirements of the radio telescope and the dependency relationship with other modules. In addition, the division of module boundaries and the definition of interface parameters affected the performance of the control system, making the predesign of the control system more complicated. In a word, a high-performance control system could add, delete, modify, or update functions or modules at any time so that the control system has good scalability and easy maintenance.


## 2.3. The Third Stage Is from the Beginning of the 21st Century to the Present

As a result of the rapid growth of scientific requirements, the growing types of hardware devices and auxiliary devices, the complex functions of devices, and more complicated business logic between subsystems, the second-stage distributed control system had poor support for multiprogramming language and cross-platform. However, the middleware framework solved these problems, which shielded complex implementation details and provided a unified interface. Therefore, a distributed architecture based on middleware framework was organized into two ways: (1) Service-Oriented Architecture (SOA) based on middleware framework [28], such as Large Millimeter Telescope (LMT) monitoring and control system [29] and TMRT distributed control software [30]; (2) the combination of SOA and event-driven architecture (EDA) based on middleware framework, such as ALMA software [31], ASKAP monitoring and control system [32], and GMRT control and monitoring system [33]. This type of control system coordinated and managed the software and hardware subsystems, such as antennas, receivers, and terminals divided any subsystem into one or more components. For example, the terminal subsystem was classified as components such as VLBI joint measurement, single antenna observation, and antenna measurement. These components were independently developed, tested, deployed, and run and were connected by a middleware framework. Middleware framework simplified complex interfaces such as operating system, network, and database into simple and unified interfaces, integrated SOA, or the combination of SOA and EDA into its design. Among them, the control system based on SOA is mainly used for the analysis and execution of control commands. In addition, the control system based on EDA is mainly used for monitoring devices and control systems. When designing the control system, the interface parameters of each component need to consider the overall requirements of the radio telescope and the dependence on other components. At the same time, the division of component boundaries and the definition of interface parameters affect the performance of the control system and increase the complexity of the control system’s early design. Compared with the control system of the second stage, the control system has lower complexity, better scalability, and higher maintainability and supports more platforms and programming languages.In conclusion, software architecture applied to control system changes from a centralized architecture to a distributed architecture without a middleware framework and then to a distributed architecture based on middleware framework. Table1 compares the advantages/disadvantages of the three-stage control system in terms of communication method, application requirements, business logic, and development difficulty. The first stage centralized control system has the benefits of simple development, short developing period, low cost, and easy deployment. However, this type of control system has some shortcomings, mainly including the inability to flexibly add, delete, and update functions and subsystems; it has the characteristics of weak extension, poor maintenance, and low portability; application code between subsystems has strong dependencies. The advantages of the second-stage distributed control system mainly include the following: modular design improves code reusability and development efficiency; modules can be independently developed, tested, deployed, and run; system is easy to add, delete, or modify modules or subsystems. Notwithstanding, the control system at this stage has some shortcomings. For example, the early stage of control system design is complex and cross-language and platform support is poor; calling relation between subsystems is complex and difficult to maintain; software engineers use complex underlying interfaces such as operating systems and networks to implement control system. The merits of the third stage distributed control system mainly include the following: middleware framework provides a simple, unified standard interface for control system development; the component granularity is smaller than the second-stage module granularity; control system has the characteristics of good scalability, high maintainability, and supports multiplatform cross-language. However, this type of control system has some shortcomings. For example, the division of component boundaries affects the performance of the control system; the logical relationship between components is complex, which makes it difficult to operate, test, and deploy the control system.Table 1
Comparison the characteristics of the three-stage control system.
NameThe first stage: centralized control systemThe second stage: distributed control system without middleware frameworkThe third stage: distributed control system based on middleware frameworkCommunication methodTCP/IP, UDPTCP/IP, UDPMiddleware (ICE, TANGO, EPICS)Granularity—CoarseFineApplication requirementsSingle scientific requirements, centralized hardware distribution, simple equipment functions, single business logic functionMany kinds of hardware equipment and auxiliary equipment, complex functions of equipment, complicated business logicMany types of hardware and auxiliary equipment, very complicated equipment functions, and quite complicated business logicCall levelCode level, libraryModularityComponent, serviceInvocation styleCall between functions or modulesInterprocess callInterprocess callBusiness logicCentralized processing of all functionsExtract core business and improve module reuseIncrease the dispatch center to manage the service, the service call is transparent, and there is no need to care about dependenciesDevelopment difficultyLowHighMediumMaintainabilityWeakStrongMediumDeployment methodCentralized deployment of all functionsDistributed deployment with independent modulesIndependent distributed deployment of components and servicesBecause there are many kinds of radio telescope hardware devices, complicated structure, huge functions, and complex business logic, modern radio telescope control systems use a distributed architecture based on a middleware framework.


## 3. Application of Middleware Framework

Modern radio telescope control systems are mostly constructed using the distributed architecture based on the middleware framework in the third stage. Middleware framework is the piece of software that is located between two independent applications: an independent application and independent system. Middleware framework hides the details of the operating system, network, or database so that developers only need to pay attention to business logic [34]. Middleware framework provides a standard protocol for communication between subsystems, which is used to connect different layers (high level, low level, and device layer [35], as shown in Figure 1) in control system architecture. When designing a control system, different types of architectures use different middleware frameworks that provide mechanisms to simplify the development of the control system, such as component or service encapsulation and interaction rules. Middleware frameworks are used by the radio telescope control system (see Table 2); these middleware frameworks are divided into high-level coordination middleware framework and high- and low-level management middleware framework. The control system constructed by the high-level coordination middleware framework can coordinate the high level of Figure 1. This kind of middleware framework mainly includes CORBA [36] and ICE [37]. The control system constructed by the high-level management middleware framework can coordinate and manage the high level and low level of Figure 1. This type of middleware framework mainly includes ACS [38], the combination of CORBA (or ICE) and EPICS [39], and Tango [40].Figure 1
Middleware framework applied to a control system architecture of radio telescope.Table 2
Middleware framework used by major radio telescope.
NameDiameterCountryMiddlewareLMT1 × 50MexicoCORBATMRT1 × 65ChinaICEALMA66 × 12ChileACSSRT1 × 64ItalyACSFAST1 × 500ChinaCORBA + EPICSASKAP36 × 12AustraliaICE + EPICSGMRT30 × 45IndiaTangoSKA——TangoCORBA : Common Object Request Broker Architecture; ICE : Internet Communications Engine; EPICS : Experimental Physics and Industrial Control System; ACS : ALMA Control System.


### 3.1. High-Level Coordination Middleware Framework

The control system is constructed by the high-level coordination middleware framework and provides some common functions such as information management, organization, and mission planning to the high level of Figure1. This kind of middleware framework includes CORBA and ICE, which provides a soft bus with functions such as service transparency, communication shielding, and information exchange. Middleware framework also provides a neutral language for defining interfaces, which can be compiled into different programming languages to implement operation and parameter transfer between subsystems.CORBA is a middleware framework with a soft bus function proposed to solve the interconnection of distributed heterogeneous environments [41]. The core Object Request Broker (ORB) of CORBA is used to build a soft bus. The soft bus separates a client from a server and provides transparent network access services for a client [42]. CORBA’s Interface Definition Language (IDL) is mapped to a variety of programming languages to generate static call interfaces and static IDL Stubs [43]. CORBA is used not only in early radio telescopes, such as LMT control system [44], but also in industrial equipment and scientific devices [45–48]. CORBA provides the foundation for middleware frameworks such as ACS and Tango and also provides design ideas for ICE. However, CORBA does not provide a hardware device driver interface and has shortcomings such as complex structure, long learning cycle, high implementation cost, stopped development, and being discontinued.ICE, absorbing the design ideas of CORBA, is a middleware framework based on remote procedure call (RPC) [49]. ICE Core not merely shields complex interfaces such as network and operating system but also provides transparent access services. Therefore, developers only need to focus on business logic [50]. Specification Language for ICE (Slice) is a neutral language similar to CORBA IDL, which sets the contract or interface between a client and a server and provides functions including data persistence and serialization. In addition to being used in radio telescopes, such as TMRT distributed control software [51], ICE is also used in large-scale software systems, scientific devices, and industrial equipment [52, 53]. Furthermore, the control system constructed by the combination of ICE and EPICS coordinates and manages the high level and low level of Figure 1, e.g., the ASKAP monitoring and control system [54]. However, ICE does not provide a hardware device driver interface. It is a heavyweight middleware framework, and engineers need to have a certain knowledge of the technology stack.In summary, the control system constructed by the high-level coordination middleware framework coordinates software subsystems. This kind of middleware framework is developed from CORBA to ICE. ICE has replaced CORBA because CORBA has stopped updating and maintaining and ICE has simpler interfaces and implementation details than CORBA. In brief, the control system built with ICE has higher scalability and better maintainability.


### 3.2. High- and Low-Level Management Middleware Framework

The control system constructed by the high- and low-level middleware framework not only provides data management, information organization, task planning, and other functions for the high level in Figure1 but also supplies parameter adjustment loop control, data acquisition, equipment monitoring, and fault diagnosis for the low level in Figure 1. This type of middleware framework mainly includes ACS, the combination of ICE (or CORBA) and EPICS, and Tango, which provides a soft bus with transparent access services, information transform, and other functions and at the same time, provides the functions of monitoring, controlling, and managing hardware subsystems.ACS, custom-developed for radio telescope, is a middleware framework developed based on CORBA. It not merely integrates common issues in radio telescope but also hides the complex interface of CORBA, network, and database [55]. ACS uses CORBA to realize synchronous communication and asynchronous communication, provides services and runtime libraries for the control system, e.g., component/container services and astronomical libraries [56]. ACS is not only used in radio telescope, such as ALMA software [57] and SRT control software [58], but also in optical telescopes and physical devices [59–63]. However, ACS is seldom used in equipment and maintenance; updates have ceased after 2010.In order to quickly develop the control system and ensure the performance of the radio telescope, ACS was replaced by two solutions: (1) the combination of ICE (or CORBA) and EPICS; (2) Tango, a single middleware framework with similar functions as ACS.For the first method, ICE (or CORBA) is that a user sends control commands to the radio telescope, and EPICS returns the monitoring status information of the hardware device or control system to the designated location. EPICS incorporates EDA into its design. EPICS is a middleware framework originated from large-scale experimental physical devices, providing soft real-time communication functions [64]. The channel access (CA) mechanism of EPICS is based on the TCP/IP protocol, provides an application program interface for the operation interface (OPI) and input/output controller (IOC) [65]. CA is the foundation of EPICS, providing a soft bus with transparent network access service functions. IOC is the core of EPICS and provides an interface for the server application. It can control equipment through a bus or direct I/O to collect/store data information in real-time. OPI provides an interface for client application development and receives control commands sent by the upper layer and status information returned by the lower layer. EPICS is not only applied to radio telescopes, e.g., FAST control system [66, 67] and ASKAP monitoring and control system [68], but also applied to large scientific equipment such as accelerators, physical experiment devices, and optical telescopes [69–73].For the second method, Tango is a middleware framework that originated from a large-scale physical experiment device. Tango uses CORBA and ZeroMQ to implement synchronous communication and asynchronous communication between systems, respectively [74]. Tango provides not only a simple and unified interface for devices, but also a drive interface for hardware devices, an operating environment, and development tools for the system. In addition, the soft bus provided by Tango needs to be recompiled when a new device is added, CORBA is used to send control commands, and ZeroMQ sends the status information of the hardware device to the user interface [75]. Tango provides the basis for the realization of radio telescope control systems, such as GMRT monitoring and control system [76] and SKA monitoring and control system [77]. GMRT monitoring and control system is based on the Sensor Actuator and Control Element (SACE) model and developed by Tango [78]. SKA consists of 1.3 million low-frequency arrays, 250 intermediate-frequency arrays, 2500 high-frequency arrays, with the longest baseline of 3000 kilometres [79]. Notwithstanding, SKA monitoring and control system is constructed with Tango, hierarchical design mode [80]. In addition to being used in radio telescope, Tango is also used in the development of control system for synchrotrons, lasers, and other scientific devices [81, 82].In summary, the control system constructed by the high- and low-level management middleware framework coordinates and manages the software and hardware system. Middleware framework is developed from ACS, which is customized for radio telescope, by the combination of EPICS and ICE (or CORBA) and Tango. The combination of EPICS and ICE and Tango has gradually replaced ACS because ACS has ceased to be updated and maintained. Therefore, the control system constructed by using the combination of EPICS and ICE and Tango has good stability, high scalability, and strong maintainability.


### 3.3. Analysis of Middleware Framework

This section analyzes the application requirements of five middleware frameworks in the radio telescope control system and compares and analyzes their advantages and disadvantages.When choosing a middleware framework suitable for a radio telescope control system, it can be considered from the development and management perspectives of software system architects, telescope managers, and software engineers. The design requirements of software system architects mainly include whether the middleware framework can satisfy the requirements of the control system. The focus of telescope managers includes the development cost and maintenance cost of the middleware framework to construct a control system. The development requirements of software engineers are which middleware framework to use to develop control system and the development cycle and difficulty of middleware framework to construct control system. Therefore, a comprehensive comparison of middleware framework characteristics is required, as shown in Table3. The following part compares and analyzes these middleware frameworks from five aspects: “serialization interface,” “communication,” “event service,” “process management,” and “security.”Table 3
Comparison the characteristics of five middleware frameworks.
NameCORBAACSTangoICEEPICSSerialization interfaceIDL, CDRIDL or XMLSerialization modelSlicePVDataCommunicationGIOP, IIOPGIOP, IIOPGIOP, IIOP, ZeroMQRPC, IceStormCA protocolEvent serviceEvent channelEvent channelZeroMQIceStormCAProcess managementIOR, ORBContainer/Component, ORBDevice server, ZeroMQIceGridcaRepeater, ChannelRPCFault diagnosisLog serviceACS alarm systemLog serviceLog serviceAlarm serviceSecurityMultiple standards, not implementedSecurity service, Authorization policiesHAProxyIceSSL, GlacierCA gatewaysAt which levelHigh levelHigh and low levelHigh and low levelHigh levelLow levelMaintenanceStopStopUpdateUpdateUpdateApplicationLMTALMA, SRTGMRT, SKATMRTAKSAPNote: GIOP: General Inter-ORB Protocol, IIOP: Internet Inter-ORB Protocol, CA: channel access, IOR: Interoperable Object Reference, RDS: Read Different than Set; CDR: Common Data Representation.“Serialization interface” is the foundation of the realization of a cross-platform, multilanguage control system. IDL of CORBA and ACS is mapped to IDL Stub interface and IDL Skeleton interface to realize data serialization and deserialization. Compared with CORBA IDL, Tango’s serialization model better satisfies serialization/deserialization of devices, classes, and processes. ICE’s Slice draws on the design ideas of IDL, which is easier to write than CORBA’s IDL, and has the characteristics of better serialization and deserialization performance. EPICS PVData serializes and deserializes complete data types.“Communication” simplifies the communication method in the design and implementation of the control system. General Inter-ORB Protocol (GIOP) of CORBA, ACS is an abstract protocol that provides a set of transmission syntax and communication information format. Internet Inter-ORB Protocol (IIOP) is a specific implementation of GIOP. Tango uses ZeroMQ’s asynchronous communication to replace CORBA’s IIOP and GIOP, which can better realize asynchronous communication. ICE satisfies both synchronous communication and asynchronous communication. ICE’s RPC has richer functions and simpler interfaces than CORBA. IceStorm is an efficient publish/subscribe service for asynchronous transmission of messages. EPICS’s CA protocol is a communication protocol for transmitting information between server and client to satisfy the requirements of multiclient, multiserver message transmission.“Event service” can improve the coordination and management capabilities of the control system. The event channel of CORBA and ACS provides event distribution service, which can satisfy the communication between subsystems. Event channel is suitable for early control systems, but it is difficult to apply to modern control systems. Tango uses ZeroMQ instead of event channel to implement event distribution. ZeroMQ uses a multicast protocol to reduce server network bandwidth overhead compared to event channel. ICE’s IceStorm implements message distribution services, which is less coupled than CORBA’s client and server. EPICS CA provides remote access to management records and fields for IOC, which can realize search, discovery, and flow control of subsystems.“Process management” is the basis for the effective operation of the control system. CORBA’s IOR is used to register and manage processes, while Object Request Broker (ORB) coordinates and manages message transmission between processes. Tango’s Device server provides one or more services with a smaller granularity than CORBA. On the other hand, ZeroMQ coordinates and manages message transmission and forwarding between processes. The concurrency of IceGrid, which ICE has, is stronger than CORBA, and it can better manage processes at the same time. Container/Component and ORB of ACS are used to coordinate and manage calls between processes. The caRepeater process of EPICS makes the CA client process independent of host’s IOC, and ChannelRPC is used for information transmission, coordination, and management between different processes.“Security” is a powerful guarantee to improve the reliability of data transmission in the control system. CORBA has designed a variety of security protocols, but most of them have not been implemented, and the designed and implemented control system has low security. The security service and authorization policies provided by ACS satisfy the security of the control system. Tango uses HAProxy to realize information transmission in the network, which is more secure and has better performance than CORBA. ICE’s Glacier allows clients and servers to communicate securely through a firewall, which is more secure than CORBA. In addition to providing server security, EPICS CA gateways also provide users with secure access.By comparing and analyzing the five middleware frameworks, it is found that Tango, ICE, and EPICS have more advantages than CORBA and ACS, which mainly include the following aspects:(1)
They have been under continuous maintenance and update(2)
They provide simpler serialization AND communication interfaces(3)
They use event distribution more concisely(4)
The process management adopted by them is more convenient AND easy to develop(5)
The safety protection schemes adopted by them are more effective(6)
The basic functions they provide are more complete(7)
They have been gradually applied to radio telescopes in recent yearsIf the middleware framework used in the control system design only needs to coordinate and manage the software subsystems of the radio telescope, ICE can be chosen to build the control system. If the control system is used to monitor, control, and manage the hardware and software subsystems, ICE can be combined with EPICS or Tango to build the control system.


## 3.1. High-Level Coordination Middleware Framework

The control system is constructed by the high-level coordination middleware framework and provides some common functions such as information management, organization, and mission planning to the high level of Figure1. This kind of middleware framework includes CORBA and ICE, which provides a soft bus with functions such as service transparency, communication shielding, and information exchange. Middleware framework also provides a neutral language for defining interfaces, which can be compiled into different programming languages to implement operation and parameter transfer between subsystems.CORBA is a middleware framework with a soft bus function proposed to solve the interconnection of distributed heterogeneous environments [41]. The core Object Request Broker (ORB) of CORBA is used to build a soft bus. The soft bus separates a client from a server and provides transparent network access services for a client [42]. CORBA’s Interface Definition Language (IDL) is mapped to a variety of programming languages to generate static call interfaces and static IDL Stubs [43]. CORBA is used not only in early radio telescopes, such as LMT control system [44], but also in industrial equipment and scientific devices [45–48]. CORBA provides the foundation for middleware frameworks such as ACS and Tango and also provides design ideas for ICE. However, CORBA does not provide a hardware device driver interface and has shortcomings such as complex structure, long learning cycle, high implementation cost, stopped development, and being discontinued.ICE, absorbing the design ideas of CORBA, is a middleware framework based on remote procedure call (RPC) [49]. ICE Core not merely shields complex interfaces such as network and operating system but also provides transparent access services. Therefore, developers only need to focus on business logic [50]. Specification Language for ICE (Slice) is a neutral language similar to CORBA IDL, which sets the contract or interface between a client and a server and provides functions including data persistence and serialization. In addition to being used in radio telescopes, such as TMRT distributed control software [51], ICE is also used in large-scale software systems, scientific devices, and industrial equipment [52, 53]. Furthermore, the control system constructed by the combination of ICE and EPICS coordinates and manages the high level and low level of Figure 1, e.g., the ASKAP monitoring and control system [54]. However, ICE does not provide a hardware device driver interface. It is a heavyweight middleware framework, and engineers need to have a certain knowledge of the technology stack.In summary, the control system constructed by the high-level coordination middleware framework coordinates software subsystems. This kind of middleware framework is developed from CORBA to ICE. ICE has replaced CORBA because CORBA has stopped updating and maintaining and ICE has simpler interfaces and implementation details than CORBA. In brief, the control system built with ICE has higher scalability and better maintainability.


## 3.2. High- and Low-Level Management Middleware Framework

The control system constructed by the high- and low-level middleware framework not only provides data management, information organization, task planning, and other functions for the high level in Figure1 but also supplies parameter adjustment loop control, data acquisition, equipment monitoring, and fault diagnosis for the low level in Figure 1. This type of middleware framework mainly includes ACS, the combination of ICE (or CORBA) and EPICS, and Tango, which provides a soft bus with transparent access services, information transform, and other functions and at the same time, provides the functions of monitoring, controlling, and managing hardware subsystems.ACS, custom-developed for radio telescope, is a middleware framework developed based on CORBA. It not merely integrates common issues in radio telescope but also hides the complex interface of CORBA, network, and database [55]. ACS uses CORBA to realize synchronous communication and asynchronous communication, provides services and runtime libraries for the control system, e.g., component/container services and astronomical libraries [56]. ACS is not only used in radio telescope, such as ALMA software [57] and SRT control software [58], but also in optical telescopes and physical devices [59–63]. However, ACS is seldom used in equipment and maintenance; updates have ceased after 2010.In order to quickly develop the control system and ensure the performance of the radio telescope, ACS was replaced by two solutions: (1) the combination of ICE (or CORBA) and EPICS; (2) Tango, a single middleware framework with similar functions as ACS.For the first method, ICE (or CORBA) is that a user sends control commands to the radio telescope, and EPICS returns the monitoring status information of the hardware device or control system to the designated location. EPICS incorporates EDA into its design. EPICS is a middleware framework originated from large-scale experimental physical devices, providing soft real-time communication functions [64]. The channel access (CA) mechanism of EPICS is based on the TCP/IP protocol, provides an application program interface for the operation interface (OPI) and input/output controller (IOC) [65]. CA is the foundation of EPICS, providing a soft bus with transparent network access service functions. IOC is the core of EPICS and provides an interface for the server application. It can control equipment through a bus or direct I/O to collect/store data information in real-time. OPI provides an interface for client application development and receives control commands sent by the upper layer and status information returned by the lower layer. EPICS is not only applied to radio telescopes, e.g., FAST control system [66, 67] and ASKAP monitoring and control system [68], but also applied to large scientific equipment such as accelerators, physical experiment devices, and optical telescopes [69–73].For the second method, Tango is a middleware framework that originated from a large-scale physical experiment device. Tango uses CORBA and ZeroMQ to implement synchronous communication and asynchronous communication between systems, respectively [74]. Tango provides not only a simple and unified interface for devices, but also a drive interface for hardware devices, an operating environment, and development tools for the system. In addition, the soft bus provided by Tango needs to be recompiled when a new device is added, CORBA is used to send control commands, and ZeroMQ sends the status information of the hardware device to the user interface [75]. Tango provides the basis for the realization of radio telescope control systems, such as GMRT monitoring and control system [76] and SKA monitoring and control system [77]. GMRT monitoring and control system is based on the Sensor Actuator and Control Element (SACE) model and developed by Tango [78]. SKA consists of 1.3 million low-frequency arrays, 250 intermediate-frequency arrays, 2500 high-frequency arrays, with the longest baseline of 3000 kilometres [79]. Notwithstanding, SKA monitoring and control system is constructed with Tango, hierarchical design mode [80]. In addition to being used in radio telescope, Tango is also used in the development of control system for synchrotrons, lasers, and other scientific devices [81, 82].In summary, the control system constructed by the high- and low-level management middleware framework coordinates and manages the software and hardware system. Middleware framework is developed from ACS, which is customized for radio telescope, by the combination of EPICS and ICE (or CORBA) and Tango. The combination of EPICS and ICE and Tango has gradually replaced ACS because ACS has ceased to be updated and maintained. Therefore, the control system constructed by using the combination of EPICS and ICE and Tango has good stability, high scalability, and strong maintainability.


## 3.3. Analysis of Middleware Framework

This section analyzes the application requirements of five middleware frameworks in the radio telescope control system and compares and analyzes their advantages and disadvantages.When choosing a middleware framework suitable for a radio telescope control system, it can be considered from the development and management perspectives of software system architects, telescope managers, and software engineers. The design requirements of software system architects mainly include whether the middleware framework can satisfy the requirements of the control system. The focus of telescope managers includes the development cost and maintenance cost of the middleware framework to construct a control system. The development requirements of software engineers are which middleware framework to use to develop control system and the development cycle and difficulty of middleware framework to construct control system. Therefore, a comprehensive comparison of middleware framework characteristics is required, as shown in Table3. The following part compares and analyzes these middleware frameworks from five aspects: “serialization interface,” “communication,” “event service,” “process management,” and “security.”Table 3
Comparison the characteristics of five middleware frameworks.
NameCORBAACSTangoICEEPICSSerialization interfaceIDL, CDRIDL or XMLSerialization modelSlicePVDataCommunicationGIOP, IIOPGIOP, IIOPGIOP, IIOP, ZeroMQRPC, IceStormCA protocolEvent serviceEvent channelEvent channelZeroMQIceStormCAProcess managementIOR, ORBContainer/Component, ORBDevice server, ZeroMQIceGridcaRepeater, ChannelRPCFault diagnosisLog serviceACS alarm systemLog serviceLog serviceAlarm serviceSecurityMultiple standards, not implementedSecurity service, Authorization policiesHAProxyIceSSL, GlacierCA gatewaysAt which levelHigh levelHigh and low levelHigh and low levelHigh levelLow levelMaintenanceStopStopUpdateUpdateUpdateApplicationLMTALMA, SRTGMRT, SKATMRTAKSAPNote: GIOP: General Inter-ORB Protocol, IIOP: Internet Inter-ORB Protocol, CA: channel access, IOR: Interoperable Object Reference, RDS: Read Different than Set; CDR: Common Data Representation.“Serialization interface” is the foundation of the realization of a cross-platform, multilanguage control system. IDL of CORBA and ACS is mapped to IDL Stub interface and IDL Skeleton interface to realize data serialization and deserialization. Compared with CORBA IDL, Tango’s serialization model better satisfies serialization/deserialization of devices, classes, and processes. ICE’s Slice draws on the design ideas of IDL, which is easier to write than CORBA’s IDL, and has the characteristics of better serialization and deserialization performance. EPICS PVData serializes and deserializes complete data types.“Communication” simplifies the communication method in the design and implementation of the control system. General Inter-ORB Protocol (GIOP) of CORBA, ACS is an abstract protocol that provides a set of transmission syntax and communication information format. Internet Inter-ORB Protocol (IIOP) is a specific implementation of GIOP. Tango uses ZeroMQ’s asynchronous communication to replace CORBA’s IIOP and GIOP, which can better realize asynchronous communication. ICE satisfies both synchronous communication and asynchronous communication. ICE’s RPC has richer functions and simpler interfaces than CORBA. IceStorm is an efficient publish/subscribe service for asynchronous transmission of messages. EPICS’s CA protocol is a communication protocol for transmitting information between server and client to satisfy the requirements of multiclient, multiserver message transmission.“Event service” can improve the coordination and management capabilities of the control system. The event channel of CORBA and ACS provides event distribution service, which can satisfy the communication between subsystems. Event channel is suitable for early control systems, but it is difficult to apply to modern control systems. Tango uses ZeroMQ instead of event channel to implement event distribution. ZeroMQ uses a multicast protocol to reduce server network bandwidth overhead compared to event channel. ICE’s IceStorm implements message distribution services, which is less coupled than CORBA’s client and server. EPICS CA provides remote access to management records and fields for IOC, which can realize search, discovery, and flow control of subsystems.“Process management” is the basis for the effective operation of the control system. CORBA’s IOR is used to register and manage processes, while Object Request Broker (ORB) coordinates and manages message transmission between processes. Tango’s Device server provides one or more services with a smaller granularity than CORBA. On the other hand, ZeroMQ coordinates and manages message transmission and forwarding between processes. The concurrency of IceGrid, which ICE has, is stronger than CORBA, and it can better manage processes at the same time. Container/Component and ORB of ACS are used to coordinate and manage calls between processes. The caRepeater process of EPICS makes the CA client process independent of host’s IOC, and ChannelRPC is used for information transmission, coordination, and management between different processes.“Security” is a powerful guarantee to improve the reliability of data transmission in the control system. CORBA has designed a variety of security protocols, but most of them have not been implemented, and the designed and implemented control system has low security. The security service and authorization policies provided by ACS satisfy the security of the control system. Tango uses HAProxy to realize information transmission in the network, which is more secure and has better performance than CORBA. ICE’s Glacier allows clients and servers to communicate securely through a firewall, which is more secure than CORBA. In addition to providing server security, EPICS CA gateways also provide users with secure access.By comparing and analyzing the five middleware frameworks, it is found that Tango, ICE, and EPICS have more advantages than CORBA and ACS, which mainly include the following aspects:(1)
They have been under continuous maintenance and update(2)
They provide simpler serialization AND communication interfaces(3)
They use event distribution more concisely(4)
The process management adopted by them is more convenient AND easy to develop(5)
The safety protection schemes adopted by them are more effective(6)
The basic functions they provide are more complete(7)
They have been gradually applied to radio telescopes in recent yearsIf the middleware framework used in the control system design only needs to coordinate and manage the software subsystems of the radio telescope, ICE can be chosen to build the control system. If the control system is used to monitor, control, and manage the hardware and software subsystems, ICE can be combined with EPICS or Tango to build the control system.


## 4. Conclusion

This article summarizes the control system of radio telescope in different periods, analyzes and compares the software architecture and middleware framework used in the control system. Software architecture is the overall plan of the radio telescope and the basis for the realization of the control system. It develops from a centralized architecture with simple structure and short development cycle to an extensible and flexible distributed architecture without middleware framework and then to a highly extensible, portable, and maintainable distributed architecture based on middleware framework. By comparing and analyzing the merits and shortcomings of the three-stage control system, it is found that distributed architecture based on the middleware framework of the third stage is more suitable for the design and implementation of modern radio telescope control systems. Middleware framework simplifies the complex operating system, network, and other interfaces into a unified and simple standard interface, which is conducive to the design and implementation of the high-level and low-level control systems. High-level coordination middleware framework has developed from CORBA with complex interfaces and complex functions to ICE with simple interfaces and simplified functions; high- and low-level management middleware framework has developed from ACS to the combination of ICE and EPICS or Tango. After comparing the benefits and drawbacks of using middleware frameworks in modern radio telescope control systems, it is found that ICE, EPICS, and Tango are more suitable for building control systems. Therefore, in the design of the radio telescope control system architecture, it is necessary to select the middleware framework to be used in terms of software and hardware subsystems, control and monitoring software and hardware. If the control system is mainly based on service or control, system architects could choose a middleware framework with similar functions as ICE to have more advantages. If a control system is used to monitor, control, and manage control system, a middleware framework similar to the combination function of ICE and EPICS or Tango function could be used. In addition, when choosing a suitable middleware framework to build a control system, we should consider not only the nonfunctional requirements such as extensibility and maintainability but also the functional requirements such as complete functions, stable performance, and simple interface of middleware framework.



---

*Source: 2655250-2021-06-29.xml*