1 Introduction

An integrated supervisory control system (ISCS) is a large-scale computer integrated system that integrates multiple specialty subsystems of metro automation based on modern computers, networks, automation, and information technology. It can be integrated on a unified platform to support the monitoring, control, and management of power supervisory control and data acquisition systems (PSCADA), building automation systems (BAS), automatic fire alarm systems (FAS), automatic train supervision (ATS), closed-circuit television (CCTV), etc., to realize information sharing and linkage control functions among various specialty subsystems [1]. International ISCS are mostly expanded by a supervisory control and data acquisition (SCADA) system [2, 3], but a SCADA system is focused more on the data acquisition and monitoring control of a small number of specialty subsystems, and ISCS has gradually integrated more specialties. ISCS involves many specialty systems, and it is necessary to realize the cooperative operation among the specialties by monitoring each specialty [4]. Therefore, ISCS is required to provide an open architecture that can integrate and interconnect various specialties of metro automation systems, and can be continuously developed and functionally expanded.

However, as each subsystem of the traditional metro ISCS is provided by a different supplier with its own complete software and hardware solution, and then integrated through a front-end processor (FEP), there are many problems in the system integration scope, information timeliness, follow-up expansion, and so on, which can no longer meet the emerging new requirements (huge data acquisition and real-time processing) in the development of rail transit.

With the development and maturity of new technologies such as cloud computing and microservices, there are better solutions for multi-specialty, multi-system, multi-service integration, and expansion. This paper analyzes the problems of traditional metro ISCS and proposes a new ISCS Plus concept and architecture based on cloud computing and microservice technology. To provide systematic, intelligent, and automated solutions for the development of metro weak current systems, the overall architecture of ISCS Plus is designed by analyzing the integration modes of different specialty subsystems, constructing a shared resource pool in the cloud and isolating subsystem functions accordingly, and then decomposing the functional modules of traditional specialties into microservices for integration.

2 Literature Review

As the demand for urban rail transit grows, the scope and quantity of data acquired and shared by various weak current specialty systems in the metro ISCS is increasing exponentially; however, the defects and deficiencies of traditional technologies are also increasingly prominent, and they need to be solved by technical improvement and upgrading.

At present, countries all over the world have widely adopted the informatization strategy to promote the development of urban rail transit. Informatization has been applied in construction, operation, management, safety, service, and other aspects of metro systems. In 2020, the China Association of Metros issued the Outline for the Development of Smart Urban Rail in China's Urban Rail Transit, which proposed that "On the basis of independent innovation, focusing on digitalization, intellectualization and networking, the achievements of new technological revolution are expected to be vigorously applied and deeply integrated with urban rail transit." The strategy in the outline points out that greater efforts will be made to promote the application of new technologies such as cloud computing and big data in the urban rail transportation industry [5].

2.1 Traditional Metro ISCS

Traditional metro ISCS acquires and shares some information from weak current systems of various specialties through integration and interconnection. Among these, integrated subsystems are an automation system whose functions are integrated by ISCS. The interconnected ISCS has its own complete system structure, keeps the subsystems running independently, and interacts with the integrated monitoring system through the external interface to realize information exchange, sharing, and linkage control functions. According to the specifications [6], the specialties that should be integrated include PSCADA, BAS, FAS, CCTV, and platform screen doors (PSD). Specialty systems that can be interconnected or integrated include CCTV, passenger announcement (PA), passenger information systems (PIS), automatic fare collection systems (AFC), access control systems (ACS), clock systems (CLK), distributed temperature sensing systems (DTS), electrical fire and emergency power supply (EPS), and energy measurement and other systems [4], as shown in Fig. 1.

Fig. 1
figure 1

Traditional metro ISCS integration and interconnected subsystem range

Full size image

As an automatic system, the metro ISCS has evolved through several stages including discrete systems, multi-electric integration systems, most or all weak current system integration and interconnection [4]. Taking the ISCS of metro lines in Beijing of China as an example, in 2002, Beijing Metro Line 13 implemented an automatic monitoring system for power supply, environmental control and disaster prevention alarm for the first time [7, 8]. By 2012, Beijing Metro Line 6 proposed the Train Integration Automatic System (TIAS) which deeply integrates ATS, PSCADA and BAS, integrates PA, CCTV and PSD through an interface, and interconnects with FAS and CLK in information [9].

ISCS has evolved from the discrete monitoring system in the 1990s, to the current ISCS and driving command comprehensive automation, to the comprehensive operation management platform system, and its development is an inevitable trend of scientific and technological progress. Computer technology and network communication technology provide the technical foundation for urban rail transit development [4]. Tuytelaars et al. studied the application of automatic object recognition technology to the ISCS [10], while Belmonte et al. studied the impact and the role of SCADA-based data acquisition technology on rail traffic safety [11]. Xu et al. studied the redundant design of ISCS under traditional network and basic hardware [12]. Du et al. applied distributed component management technology to the acquisition and performance evaluation of a large number of ISCS monitoring points [13], and Kuznetsov et al. proposed a calculation and identification algorithm of power loss based on the data acquired by SCADA [14]. Wu et al. studied the rail transit automation system based on cloud computing technology [15]. From the perspective of the development of a comprehensive metro monitoring system, the development level of science and technology determines the development level of urban rail transit automation. The ISCS of urban rail transit basically develops synchronously with the automation technology at the time.

2.2 Problems of Traditional Metro ISCS

With the rapid development of urban rail transit, the connections between monitoring targets during operation are becoming more varied and complicated, the demand for timeliness of information collection and processing is increasing, and greater emphasis is being placed on the safety and reliability of operations [16, 17], all of which contribute to higher demand for resource and information sharing [15].

With the progress of science and technology in the past decade, the metro ISCS has also made great progress, but the current system still cannot meet the operation requirements well, and it is still unable to realize information sharing, intelligent response, and automated processing of all weak current systems. The traditional ISCS has the following problems.

(1) The traditional ISCS has a small integration range, insufficient information sharing, and low processing timeliness.

The existing popular metro ISCS only integrates BAS, PSCADA, and FAS, and interconnects ATS, ACS, PSD, CCTV, PA, PIS, AFC, and other systems. With the implementation of fully automatic operation, the ISCS integrates ATS only because of the demand of train operation; nothing else has changed, such as TIAS in Beijing. Therefore, not all the information for the non-integrated system is included in ISCS; only some equipment operation information is extracted to the ISCS, which makes information sharing insufficient [9].

In addition, because most of the traditional ISCS subsystems adopt interconnected methods, the real-time information sharing level is not high. The data and information are generally transferred to the ISCS after its original information has been processed, which causes a delay in the information processing of the ISCS. For example, after the AFC system acquires information, it only transfers real-time operation and status information of the equipment to ISCS. The important passenger flow information is not sent to the ISCS in real time, which makes the ISCS unable to implement the station's emergency plan based on the passenger flow information during instantaneous large passenger flow [1].

(2) Functions are fixed in traditional ISCS, and subsequent expansion of operational functions is limited.

The traditional ISCS has basically completed fixed functions in the construction stage and can also meet the normal operation and maintenance requirements of the equipment. The linkage with other systems is realized through a communication interface. As more systems are connected, the linkage function becomes stronger, and the more manufacturers and interfaces need to be coordinated accordingly. Changes or failures in any manufacturer's interface will affect existing linkages. If a new linkage function needs to be coordinated with the participation of different manufacturers, it may not be implemented due to coordination difficulties.

(3) The structure of the traditional ISCS is fixed, the flexibility is insufficient, and modularization and standardization cannot be achieved. The sharing efficiency and compatibility of functions and the maintainability are low.

Traditional ISCS are developed by different manufacturers, and each manufacturer has its own unique architecture. Most use a single structure, and the system structure is fixed. Because of its lack of flexibility and its incompatibility, it is impossible to use standardization and modularization to achieve system functions, and when business requirements increase, as functional modules cannot be reused, it results in an increasingly large system and low system maintainability [13, 15]. It is also difficult to integrate systems from different manufacturers into a network-level ISCS [15].

2.3 Advantages of Cloud Computing Technology in ISCS

Cloud computing is another revolutionary change in information technology following the large-scale transformation from the mainframe computer to the client/server (C/S) model in the 1980s. Cloud computing is a product of the development and integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility technology, network storage, virtualization, and load balancing [18]. Its purpose is to organize and integrate the shared software/hardware resources and information through network-based computing and provide it to computers and other systems as needed [19]. Cloud computing is a business computing model. It distributes computing tasks on a resource pool comprising a large number of computers. It enables various application systems to obtain computing power, storage space, and information services as needed. It provides dynamic scalable and cheap computing services on demand through the network. [20,21,22,23].

Throughout the metro, the weak current system is almost entirely composed of server equipment, switch equipment, computer equipment, and related software systems. With the development of computer technology, the CPU processing capacity of the server is becoming increasingly powerful, and because of high performance requirements for the safety of metro business systems, many systems are equipped with redundant servers. But because the data service is relatively fixed, and there is no explosive growth, this leads to a huge waste of the computing resources set by each system. The server’s CPU usage is about 5%, and because the fault-tolerant mechanism requires a 1+1 backup method, it results in serious waste of CPU resources under the traditional architecture. The use of cloud computing technology can significantly improve the rate of resource utilization [15, 24, 25].

The system server needs to restart when the system server fails in traditional C/S or B/S mode. System restart time is generally 15–30 min. By using cloud technology, the system can be migrated quickly, and the system recovery time can be reduced to 2 min, greatly improving the reliability. Especially for line extension and upgrading, it can be debugged through the virtual server, greatly reducing the impact on the existing operating system [18].

For metro weak current systems, business systems also have different requirements for resources. For example, in order to prevent avalanches, traditional ISCS have clear requirements for CPU utilization. We can make use of the elastic characteristics of cloud computing to allocate resources according to the actual situation, thus improving resource utilization and reducing resource waste [15, 25].

The newly revised "Technical standard for urban rail transit integrated supervision and control system" in China [6] proposed that "cloud computing technology can be adopted in ISCS", and it further pointed out that "cloud computing solution is suggested to include ISCS control center, cloud computing center and ISCS station level cloud computing workstation".

2.4 Advantages of the Application of Microservice Architecture in ISCS

The concept of microservice architecture has sparked widespread interest since its introduction, and its emergence has solved the problems of traditional system maintenance and expansion difficulties [26].

Microservice architecture is a method of developing a single application as a set of small services. Each service runs in its own process. The communication between services uses a lightweight communication mechanism (usually using the HTTP API resource). These services are built around business capabilities and can be deployed independently through a fully automated deployment mechanism. The services share a minimal centralized management. Services can be developed in different languages and use different data storage technologies [27,28,29].

In the past, the traditional system architecture used a single model to build the system. As business requirements became more diverse, systems became progressively larger to accommodate the expanding demands. The greater demands may affect the operation of other functions during deployment because of the shared database. Any function that needs to be added may involve different resources (such as concurrency, read-write IO), so a small change will affect the use of other functions, and the expansion and operation and maintenance of the system become increasingly difficult [30, 31].

The microservice architecture has the following characteristics [29, 32,33,34,35,36].

  1. 1.

    The application logic is decomposed into small-grained components with clear responsibilities [32, 33];

  2. 2.

    Each component has a small area of responsibility and is deployed completely independently [31];

  3. 3.

    Microservices use a lightweight communication protocol to provide data exchange between service consumers and service providers [21, 34, 35];

  4. 4.

    The underlying implementation of the service has nothing to do with technology; it can be developed using multiple languages and technologies [29, 30];

  5. 5.

    Microservices are small, independent, and well-distributed [36].

The above characteristics of microservice architecture can effectively solve the problems of maintenance difficulties and other issues due to system expansion in a traditional architecture.

Some manufacturers in the metro industry, such as Hollysys [37] and Yajie Yi [38], are now designing new metro weak power systems by adopting microservice architecture, but they are still in the design and development stage.

3 Core Design of ISCS Plus

In order to solve the problems of traditional metro ISCS, we propose a new ISCS Plus system based on cloud computing and microservice technology, which integrates a larger range of weak current specialty subsystems through merging, integration, and interconnection. Among these, cloud technology provides a basic resource platform for multi-discipline integration, and microservice technology is used to achieve integration between multi-discipline subsystems. This chapter focuses on the planning of the scope of integration, the design of the basic resource platforms, and the design of integration methods.

3.1 Design of Integration Range for Weak Current Subsystems

In order to better realize the automatic processing of the entire metro weak current system, ISCS Plus solves problems such as narrow integration range, insufficient information sharing, and low processing timeliness that characterize traditional ISCS. As more data are acquired by ISCS Plus, the problem of less information will be resolved. ISCS Plus is no longer satisfied with partial acquisition of the equipment and device information. Instead, all the equipment and device information need to be acquired to fulfill the real scene-based simulation of the equipment through the acquired information, and finally an accurate decision command is provided according to the mathematical strategy and model algorithm. Following the design principle of “improving the coordination and cooperation of various systems, efficiently achieving linkage between systems, and improving the overall automation level of the entire rail transit line”, we propose a new design of an integration mode called ISCS Plus based on new technologies of cloud computing and microservice architecture on the basis of inheriting the traditional integration and interconnection architecture.

According to the safety level and real-time data requirements of various metro weak current subsystems, the integration method between the weak current subsystems and ISCS are analyzed and recommended. The specific analysis is shown in Table 1.

Table 1 Analysis of the system integration method of traditional weak current system and ISCS
Full size table

From the statistics in Table 1 we can see that the different specialty subsystems of the traditional weak current system have different safety requirements and different real-time data processing requirements, so different specialty subsystems have different integration methods. Subsystems with high real-time requirements such as PSCADA, BAS, ATS, FAS, PSD, CCTV, PIS, PA, AFC, ACS, and power supply should be integrated; however, CCTV, PIS, PA, AFC, ACS, and power supply can also be interconnected. These systems are very important for the automatic processing of metros. For other data processing systems with low real-time requirements and low security requirements, integration and information sharing is not required. For systems with high security requirements and high real-time requirements, such as automatic train protection (ATP) and computer interlocking systems (CI), for security reasons, they are not integrated, and information sharing is not implemented.

Traditional ISCS integrated with other weak current systems includes interface integration and application integration. In practice, for technical reasons, the interface integration method was more often adopted to implement the integrated system, and it was integrated in the new system‘s software interface to achieve a unified software interface and unified account and permission management. Different applications are installed on different servers, using different databases, such as TIAS. Application integration mode was adopted for most systems that should be integrated. In addition to achieving a unified interface and unified account and authority management, it also unifies the application management. The subsystems that should be integrated do not exist separately, and the applications are installed on a server.

Through interconnection, the weak current system and the ISCS basically communicate with each other through an interface. Every subsystem has its own complete system structure and maintains the independent operation of the system, while sharing and performing function information exchange with ISCS. In ISCS, the start of linkage control is triggered after data are received and data analysis is performed to realize automatic processing.

Based on the above statistics and analysis, in order to accomplish the original intention of the integrated monitoring design, to achieve intelligent response and automated processing, we propose a merging method that meets the higher requirements of real-time data processing in the traditional integrated way, i.e., merging multiple weak current systems with strict real-time data processing requirements into one system, to unify account and authority management, to unify application management, and finally to create an independent software system. For some systems with low real-time requirements, the integration method is adopted, and for some systems with high security and real-time requirements, the interconnection method is adopted.

Merging, integration, and interconnection are three methods adopted to integrate traditional weak current systems such as ISCS, ATS, PA, PIS, centralized alarm systems, AFC, platform door systems, ACS, CLK, transmission systems, office automation systems, and other traditional metro weak current systems. The integrated architecture of ISCS Plus is shown in Fig. 2.

Fig. 2
figure 2

ISCS Plus integrated architecture diagram

Full size image

For PSCADA, BAS, and other specialty systems, the system security requirements are low; however, the data real-time requirements are high, and the data processing is closely related to the daily operation. Therefore, the traditional integration mode is changed to the merging mode in ISCS Plus. Although ATS has a high system security requirement, it still depends on ATP and CI to ensure security. At the same time, because it is at the core of daily operations, we propose that merging integration should be applied for ATS. For the centralized alarm system of the communication system, because it monitors the running state of the system in real time and plays an important role in the fault diagnosis of the system, we also propose to adopt the merging mode for the centralized alarm system of communication system.

For systems such as transmission systems and wireless communication systems, the system security requirements are low, the real-time requirements are weak, and they are subsidiary systems; therefore, an integrated integration method is adopted to achieve information sharing. All the functions of these systems are realized by ISCS Plus, but they are not separated and combined in a modular way. Instead, embedding of the whole system or interface integration is adopted, which is part of ISCS Plus.

The office automation system is not closely related to metro operations, so it adopts an interconnected integration method. For CI and ATP, because of their high system security level and strong data real-time requirements, the existing technology does not satisfy the relevant security requirements and they are integrated through interconnected integration. The maintenance and monitoring system is closely related to safety, so an interconnected method is also adopted.

3.2 Design of Infrastructure Based on Cloud Computing

The traditional metro weak current systems involve many business systems and include many physical servers. Based on the needs of our design work, we conducted a follow-up survey on the construction of multiple lines of weak current systems in recent years, mainly investigating the operations of the main business systems and the number of installed servers in the control center during the construction period. The actual implementation data of the weak current system are shown in Table 2.

Table 2 Actual implementation data of the weak current system of the metro in one city in recent years
Full size table

In this metro system, the traditional control center manages 39 weak current systems including interface communication, network management, monitoring, logging, business applications, training simulation, and other application systems. In order to ensure the normal operation of these 39 systems, 56 physical servers (excluding storage) are used as the basic support platform in the control center.

The application of cloud computing technology in finance, Internet, and other industries has been studied from the perspective of CPU usage, maintenance efficiency, energy consumption, reliability, etc. The specific analysis results of CPU usage, maintenance efficiency, energy consumption, and reliability with and without the use of cloud computing technology are compared in Table 3.

Table 3 Comparison of indicators before and after adopting cloud computing
Full size table

We also carried out a survey on the metro industry businesses which had adopted cloud computing technology during the past 2 years and studied the resource demands by the traditional systems. The survey results on the cloud computing resource requirements for weak current specialty systems are shown in Table 4.

Table 4 Cloud computing resource requirements for weak current specialty systems
Full size table

It can be seen from Table 2 that by adopting cloud computing technology, the system resource requires 464 cores. As it is necessary to take into account the cloud computing management node, the 464 cores are multiplied by 1.3, and then about 603 cores are required for computing. Therefore, the resource pool of the cloud platform needs a total of 603 cores. Considering that each set of servers provides two-way 16 cores, a total of 19 servers are required.

From the above analysis, it can be seen that after using ISCS Plus to integrate these weak current systems, the whole system needs to perform more functions, and also more infrastructures are needed, so more computing services are required. Cloud computing provides “dynamic scalable and cheap computing services on demand through network” [23, 33]. Such a large application system requires many computing resources. Some tech such as supercomputers, high-end servers, and high-end storage could be used to satisfy the requirements. However, application systems must also control resource management, task management, and security management of hardware. In addition, the expansion of future application systems will be limited by the development of hardware. Therefore, we propose to adopt cloud computing to design the basic platform of ISCS Plus to meet the huge computing resource requirement and solve the problem of hardware cost and its limited potential for expansion.

The cloud computing technology architecture consist of four layers, i.e., a physical resource layer, resource pooling layer, hypervisor clustering layer, and microservice building layer. The physical resource layer includes computers, storage, network equipment, databases, and software; the resource pooling layer is a large number of resources of the same type to form a homogeneous or nearly isomorphic resource pool, such as a physical server pool, virtual server pool, or storage pool; the hypervisor clustering layer is responsible for the management of cloud computing resources and scheduling of many application tasks, so that it allows resources to provide services for applications efficiently and safely; the microservice construction layer encapsulates cloud computing capabilities into standard services, and integrates them into microservice architecture for management and application [30]. ISCS Plus mainly adopts the core resource pool concept of cloud computing. The size of the pool can be dynamically expanded, and the processing power allocated to users can be dynamically recycled and reused. This model can greatly improve the resource utilization rate and enhance the service quality of the platform. At the same time, the basic platform of cloud computing is adopted, and the business system does not need to manage hardware. At the same time, future resources can be freely expanded as the application system expands.

In the field of cloud computing, there are two major cloud computing products: OpenStack [39] series and VMware [40]. The main differences between OpenStack and VMware are shown in Table 5.

Table 5 Differences between OpenStack and VMware
Full size table

Both OpenStack and VMware are a feasible choice as basic cloud platform technology for the ISCS Plus basic platform; however, when taking into account better compatibility, the OpenStack cloud platform is preferred.

For the unified management of the IaaS layer, with the use of the OpenStack cloud resource management platform, IT resources are grouped and maintained through server virtualization technology, distributed storage, SDN, and management technology to form resource pools such as computing, storage, and network to provide users with measured and elastically allocated resource services. At the same time, through the CPU reuse technology, a physical CPU can be virtualized to present multiple VCPU, which can improve the utilization rate of the physical core CPU and of hardware computing resources. It can easily achieve a 1:3 integration ratio, improve the resource utilization rate, improve the performance of the platform, and meet the resource requirements of the system.

3.3 Design of Merging Mode Based on Microservices

The traditional ISCS only integrates PSCADA and BAS; its functions are simple. Even the TIAS system only integrates one more ATS system than the traditional integrated monitoring system. The overall system has a small amount of code, so it is often designed in a single architecture; that is, a single program file constitutes all of the system software. ISCS Plus proposed in this paper merges 13 subsystems and it performs many more functions. If a monolithic architecture is used to develop such software, it will create difficulties due to the large amount of code, and will make maintenance and expansion more difficult.

Among the various software architectures, the most widely used today are single, distributed, Service-Oriented Architecture (SOA), and microservice architectures. For these four, because ISCS Plus encompasses many functions and has a large amount of code, a single architecture is not suitable. Although the distributed architecture can divide a large system into multiple business modules, the business modules are deployed on different servers, and the data interaction between each module occurs through the interface. However, due to data redundancy, functional redundancy, and high coupling between subsystems, it is also unable to satisfy the resource allocation requirements of the PSCADA system, which requires an instantaneous business surge in the morning and evening. The third type, SOA architecture, provides the service of different functional units of the application and effectively connects these services through the interface, but there is a fuzzy boundary between the system and the service. This leads to large granularity of extracted services and high coupling between systems and services. At the same time, it is not well combined with cloud computing, container, and other technologies, so it is impossible to satisfy the dynamic scalability and load balancing of resources and business in the future. Finally, the microservice architecture can provide fine-grained splitting of system functions, and each service split only completes a specific business function, such as permission service and login service, which only implements the business of login and permission assignment. Hence, the granularity of service is very low, and it can more accurately formulate the optimization scheme of each service and adjust according to the demand, and the scope of influence is convenient for subsequent expansion. Combined with container technology, the number of services can be balanced and scaled according to the business requirements to adapt to the actual needs.

From the above analysis, taking into account the new technologies of cloud computing and containers like Docker or Kubernetes, a microservice architecture is designed to accomplish the integration mode.

When applying the core of a microservice architecture, service splitting is performed based on business capability. First, we should analyze the business functions of 13 converged systems by using microservice architecture for statistical analysis. Table 6 lists the functions of the 13 converged systems in detail.

Table 6 Core function analysis of the 13 subsystems to be integrated by ISCS Plus
Full size table

According to the statistics in Table 6, by referring to the characteristics of the microservice architecture, the service of ISCS Plus is designed primarily by considering the system complexity and the service reusability. The split service should be easier to maintain and update. Microservices are divided into general services and individual services to achieve high load, scalability, low coupling, and so on. Each service runs independently without interference, and each service is isolated and secure.

Firstly, the functions which all systems have are extracted, split, and integrated. For example, the basic remote control function in BAS, the operation status and fault information function of monitoring equipment in FAS, the system monitoring function of AFC, the state monitoring of the PSD system, and the state monitoring of ACS can all be formed as one monitoring service. The alarm functions of all systems are also extracted to form an alarm service; the authorization and user management in all systems are extracted to form a basic information configuration service; all system log functions are extracted to form a log service; the statistical functions of all systems are extracted to form the report service; and those services formed by these general functions are general services. The integrated services are responsible for the general functions of each specialty, independent of specific business, with high reusability, so that the system will not cause a failure of a unit or service.

Secondly, when the business of subsystem functions is sufficiently complicated, services are divided based on domain drivers including schedule mode function of BAS, operation diagram of ATS system, train hold function, editing and broadcasting function of PIS, and access control authorization function of ACS, to form special services such as PSCADA, PA, PIs, AFC, and ATS, and form the individual service pool. The specific design of ISCS Plus based on microservice architecture is shown in Fig. 3.

Fig. 3
figure 3

ISCS Plus design based on microservice architecture

Full size image

In microservice architecture combined with cloud computing and container technology, for some individual services and important services, multiple nodes can be deployed. In addition, combined with cloud computing technology, service instances are separately deployed on different cloud nodes, and each service runs independently without interference from other services, which ensures system reliability.

4 Design of the Overall Architecture of ISCS Plus

Based on the analysis of the integration scope, basic resource platform, and integration mode design above, the overall architecture design of ISCS Plus is proposed by taking into account the different real-time requirements of system data processing, reliability, and stability. Its architecture includes three layers and three platforms, which are the application layer of the data display platform, core layer of the data processing platform, and access layer of the data acquisition platform.

The application layer mainly comprises the data display and human–computer interaction functions, and adopts event-driven architecture according to the real-time characteristics of business requirements. The core layer of the data processing platform is mainly responsible for all data processing and functions, and achieves the business system integration through the microservice architecture. The access layer of the data acquisition platform mainly realizes the data acquisition function; this layer adopts the distributed architecture considering the characteristics of the station dispersion. The design of the overall architecture of ISCS Plus is shown in Fig. 4.

Fig. 4
figure 4

Overall architecture of ISCS Plus

Full size image

1. Application layer

The system is designed as a mixed mode with C/S and B/S. As the traditional automation control operation framework, C/S mode carries the screen display of PSCADA, BAS, FAS, PSD, ATS, PIs, PA, CCTV, AFC, operation scheduling, trend chart, monitoring, alarm, etc. B/S mode is an operation framework with the characteristics of convenient interconnection and interworking. The main services carried by B/S mode include ACS, equipment maintenance, intelligent network management, OA, and signal system.

2. Core layer

2.1 Dedicated services

A specialty system service mainly provides the special functions of each business system, including line monitoring function, train monitoring function, train operation control and adjustment function, and train schedule diagram management function of ATS; remote control, telemetry, remote signaling, and remote adjustment of PSCADA; and blocking alarm, general response function, and time process function of BAS.

The equipment management service can maintain the basic information of the equipment and provide the functions of adding, deleting, querying, and modifying. This service can associate the device with type, configure the area where the device is located, and so on.

The equipment point management service interface provides the maintenance of the basic information of the equipment point and provides the functions of adding, deleting, querying, and modifying. It enables one to associate equipment points with equipment point types, configure equipment points to associate equipment, etc.

The network management service realizes the integration and development of network management with various business systems, provides monitoring service for the equipment operation status of each business system, and provides basic information configuration for the equipment of each business system.

Cloud platform management services include the functions of monitoring equipment performance, recording and transmission of equipment alarm information, and hierarchical browsing of equipment information.

The system can set up big data management services to provide the functions of monitoring equipment performance, recording and transmitting equipment alarm information, and equipment information hierarchical browsing.

2.2 General services

The authorization service provides the client's login to the platform with user name and password. After authentication by the platform, authorization information expressed by a SHA-256 encrypted string is recorded by the platform. The authorization information will have a timeout setting, and so will be invalid when the time limit is exceeded.

The alarm service mainly includes a real-time alarm, historical alarm, and alarm processing.

The log service plays a global role and provides a logging service to authenticated clients. There are many subsystems in the system, and their logs that are generated are complex. Therefore, event monitoring technology is used to record logs, which provides an execution context for receiving, storing, processing, and distributing events. The log is stored on a non-relational database.

The purpose of the monitoring service is to ensure that all equipment points in the whole line are recorded in the cache. The purpose is to load the cache data with priority according to the client's demand for loading the point status and value. It does not need to communicate with the device directly, which increases the speed and improves the user experience and system response. The client can query a point value or multiple point values according to the point ID.

The log acquisition service is used to produce the running log, user behavior log, diagnosis log, and microservice flow log of the system. After the logs are generated, they are sent to the database through the log acquisitor.

3. Access layer

The access layer mainly controls the data access acquisition platform in the station, the priority of acquisition for data, and the sequence of concurrent data.

Gateway services simplify the configuration of interconnected applications by providing a single-entry point for all information, avoiding the purchase, operation, troubleshooting, and maintenance of a variety of disparate solutions to maintain discrete connectivity. Modbus TCP/IP, 104, and other protocol drivers are provided downward, and the protocol is unified upward.

The intelligent connector can send COV, alarm information and log information, receive command and control command, cross-station linkage command, alarm processing information, and linkage update command and mode update command.

By subscribing to Kafka, the cache storage service splits the data packets and stores them in the form of key value pairs in the cache storage server for platform query. The cache storage service adopts stateless design and multi-node working mode.

5 Conclusion and Prospects

The problems of traditional metro ISCS were analyzed in this paper. These issues include a small integration scope, insufficient information sharing, low processing timeliness, function fixed, subsequent expansion and upgrading limited, structure fixed, and low compatibility and maintainability. To solve these problems, a new concept and architecture of ISCS Plus based on cloud computing and microservice technology is proposed, which integrates a wider range of weak current specialty subsystems through merging, integration, and interconnection. Among these subsystems, cloud technology mainly provides a basic resource platform for multi-disciplinary integration, while microservice technology is used to achieve the integration of multi-disciplinary subsystems. Based on the new design, the overall architecture of ISCS Plus is established, including application layer data display platform, core layer data processing platform, and access layer data acquisition platform. By means of merging, integration, and interconnection, more weak current systems are integrated. The ISCS Plus has the following characteristics:

  1. 1.

    Wider scope of integration and information sharing: With the change of the system integration mode, the link from information generation to consumption becomes shorter, and the real-time performance of cross-system synchronous data is shortened from more than 10 min to 5 min or even less than 1 min.

  2. 2.

    Using microservice mode, standardized interface, and function module standardization, system linkage needs only a small amount of interface configuration and requires minimal code development. Users can freely combine business functions on demand, which reduces the cost and difficulty of customized development or system upgrading.

  3. 3.

    It can maintain the functions of standard and traditional applications in the old system, and simultaneously break the boundaries of subsystems, conduct deep integration and comprehensive integration, and flexibly extend and redefine the functions of the system according to the requirements of continuous development of operation, maintenance, and passenger service.

  4. 4.

    ISCS Plus is an open architecture, so the products of third-party system manufacturers can be directly deployed into the system architecture for expeditious application.

In the future, for those systems with high safety and real-time data requirements such as interlocking, automatic train operation, and automatic train protection, a closer integration mode suitable for their business requirements and technical characteristics can be studied to further realize the interconnection and intelligent linkage of various specialty systems of integrated monitoring.