Railway Cloud: Management and Orchestration Functionality Designed as Microservices

Abstract

The cloudification and virtualisation of railway functions have the potential to improve railway operation efficiency, reliability, safety, and security, as well as to enhance passenger experience by offering innovative services. This paper considers issues related to the management and orchestration of railway clouds that host cloudified railway functions. A microservices-based approach to the design of railway cloud management and orchestration functionality is proposed. The basic railway cloud concepts were defined, and functionality related to the basic orchestration of the railway cloud and deployments is analysed in order to derive the requirements of platform resources and workload management. This functionality is further designed in the form of microservices, meaning that they could possibly be used in orchestration applications to enable improvements in scalability, fault isolation, and data security. The design of microservices follows the principles of the Representational State of Transfer (REST) application programming interface (API) as a set of interlinked resources. Resources related to railway cloud orchestration are identified with their associated data, relationships to other resources, and applicable methods. The resources’ methods are used in railway applications to implement the required orchestration functionality and to maintain the state of railway cloud orchestration processes. To verify the synthesised microservices, the common orchestration application logic and microservices’ logic were modelled, and it was proved that the orchestration processes, which run concurrently, expose equivalent behaviour. The proposed approach was validated using a simulation, aiming to evaluate injected latency as a key performance indicator for the reliability and safety of railway operations. Additionally, some safety and security issues related to railway cloud management and orchestration are considered.

1. Introduction

Digitalisation is shaping the transformation of railway transport, and it is essential for building sustainable economies and lifecycles. Mission critical communications and cloud technologies are accelerating the railway journey into the realms of digitalisation and sustainability. Fifth-generation (5G) communications, artificial intelligence (AI), cloud computing, and virtualisation technologies empower railways with new levels of connectivity, safety, reliability, and sustainability.

Using a 5G cloud native railway infrastructure and virtualisation of railway functions enables improvements in operation efficiency, lower costs, and the fast deployment of innovative applications. The provision of ubiquitous and uninterrupted connectivity using 5G ultra-reliable low-latency communications and the support of the Future Railway Mobile Communication System (FRMCS), defined by the International Union of Telecommunications, is expected to increase the level of automatic train operation, enabling a good level of security for passengers and staff, and improving service punctuality and the passenger experience [1,2,3,4,5].

AI methods have huge potential to solve practical problems in the railway industry related to train automation, the maintenance of track and catenary systems, the monitoring of civil structures, etc. [6,7,8,9]. There is an increasing number of contributions in the literature applying AI methods in railway operations, such as using renewable energy and smart grid systems [10], digital twins for smart railways [11,12], automatic train operation [13,14], trackside predictive maintenance operations [15,16,17], the dynamic forecasting of train dwell time [18], transport system modelling [19], etc.

Cloud computing could accelerate the digital journey of railways by gathering operational information, such as train speed and location and track and meteorological conditions, and by sending control information, which is critical to life, in real time to the onboard computer in the train cab. This could ensure safer railway control systems and stable operations. An analytic cloud-based system combined with real-time monitoring can reduce unexpected operation interruptions, improve the performance of railway traffic management, and contribute to more reliable, safe, and passenger-oriented services [20,21]. By shifting railway applications into a cloud paradigm, huge sets of diverse operational data reflecting physical asset states could be stored, processed, and analysed in real time to identify anomalies, potential damages, or even hazardous conditions. With its computing power, cloud-based railway platforms provide scalable and flexible solutions for the processing of colossal and complicated datasets related to the monitoring of train movements, maintenance, and traffic forecasting. With advances in computing technologies such as multi-core processors, the embedded systems in railways could be virtualised. Railway functions that could be virtualised include train signalling and control, monitoring and surveillance, diagnostics and maintenance, passenger information systems, ticketing, and communication systems. Virtualisation provides a flexible solution for all types of railway applications, enabling upgrades with minimal effort [22,23]. Virtualisation, with its modular software architecture, could contribute to improvements in the safety of mission critical functions. Different tasks can be executed independently of each other, having access to their own partition and own sets of resources, enabling the assignment of different trust levels and the application of appropriate security policies. The real-time requirements of safety-critical functions can be met by the assignment of the necessary computing resources.

In the authors’ previous research, a cloud-based railway control system architecture, which enables the use of AI and function virtualisation, was proposed [24,25]. The main advantages of this proposed architecture are its modular structure and the decoupling of time-sensitive control functions from time-tolerant control functions.

In this paper, more details of the railway cloud platform are discussed, and cloud management functionality is considered. Also, an approach to design microservices for railway cloud orchestration is presented.

The remainder of this paper is organised as follows. The next section presents works related to railway cloud architecture, management, and applications and highlights the novelty of this paper. Section 3 briefly describes the proposed cloud-based railway control system architecture, with an emphasis on the railway cloud platform and its management functionality. Section 4 is devoted to explaining railway cloud management use cases, which are the basis for synthesising the functionality of management microservices. Section 5 presents the proposed approach for the design of railway cloud orchestration microservices, including the verification and validation of microservices. Some issues related to safety and security in cloudified railway systems are discussed in Section 6. Finally, the conclusion summarises the benefits of this approach and points out the inherent disadvantages of microservices that cloud be mitigated through proper planning and management.

2. Related Works

Research related to railways’ cloudification can be classified into three areas: the employment of edge clouds related to the optimisation of offloading real-time control onto edge clouds; cloud computing platform’s architectures concerning resilient and secured frameworks embedding intelligent workflows and virtualisation technologies; and cloud-based railway applications for automatic train supervision, track monitoring and surveillance, fault diagnostics, and ticketing systems.

Real-time monitoring in railways provides accurate support in terms of fault management, enabling the generation of valuable and actionable insights, and edge computing is a good method used to perform analytics close to data sources. In [26], the authors propose a method for train predictive control, which offloads computations related to real-time control onto edge services, while a deep learning-based algorithm for trajectory prediction is executed on a centralised server. In [27], an approach to optimise railway logistics based on mobile edge cloud is proposed. The authors of [28] exploit the benefits of multi-access edge computing to offload train tasks to edge servers using blockchain technology for authenticity. An edge computing-based solution for the problem of the processing of mass data, gathered from intelligent railway station equipment, is presented in [29].

Moving the tasks of railway operation and maintenance to the cloud sets strict requirements in terms of reliability, safety, and security. The resilience requirements of the cloud for its use in critical railway systems are considered in [30]. The capabilities of the cloud to deploy virtualised real-time, safety-critical functions to commercial off-the-shelf products are studied in [31]. To cope with problems related to diverse logistic information across borders, in [32], the authors propose a hybrid cloud with three layers of services. A cloud-based architecture of an intelligent operation and maintenance system in railways is presented in [33], with focus on the respective workflows. In [34], the authors study the capabilities of building cloud computing platforms for railways with open-source products and propose a high-level security architecture for the cloud. In [35], the authors present the idea of cloud-based supervisory control systems for urban railway transport and identify the related functionality, which could be synthesised as microservices. However, the authors do not provide any details on the design of microservices and do not discuss cloud management aspects. A study on security architectures and key technologies for railway clouds is provided in [36].

Most of the existing research focused on railway clouds is devoted to specific cloud-based railways applications [37]. These applications cover automatic train supervision [38], virtual coupling [39], track surveillance and monitoring [40,41], fault detection in railway infrastructure components [42], predictive maintenance [43], smart ticketing systems [44,45], train movements prediction [46], operation and maintenance of rail power supply systems [47], and security-related issues [48,49].

Table 1. Summary of works concerning problems related to the railways cloud aspects.

Area	References	Considered Problems
Railway edge clouds	[26,27,28,29]	Optimization of offloading real-time control on edge clouds
Cloud computing platform architectures	[30,31,32,33,34,35,36]	Resilient and secure frameworks embedding AI and intelligent workflows, virtualization technologies
Cloud-based railway applications	[37,38,39,40,41,42,43,44,45,46,47,48,49]	Automatic train supervision, track monitoring, fault diagnostics, track surveillance, secure communications, ticketing systems

summarizes some of the recent works concerning problems related to the aspects of the railway cloud.

The management of industrial clouds comes with a set of problems related to data security and privacy, performance and reliability, cloud migration, interoperability, optimization of management costs, and required skills and knowledge.

The management of industrial clouds comes with a set of problems related to data security and privacy, performance and reliability, cloud migration, interoperability, optimisation of management costs, required skills, and knowledge.

In [50], the authors provide a study on industrial multi-cloud management platforms, analysing the difficulties and challenges of building such architectures. In [51], innovative approaches to resource allocation and performance optimisation techniques in a multi-cloud environment are explored. A blockchain-based multi-cloud infrastructure that unifies the management of clouds provided by different vendors is presented in [52]. In [53], the principles of cloud management required for optimal cloud resource allocation and the migration of virtual machines are stressed. In [54], the authors provide a survey on cloud resource management by comparing different cloud computing algorithms. Problems related to the balance between cloud performance and power consumption and existing management approaches are discussed in [55]. In [56], the author proposes a hybrid approach to secure cloud resource allocation based on machine learning and task scheduling. A cloud resource management strategy is discussed in [57], which is an auction mechanism and improves traditional resource allocation strategies. The problems related to data recovery and backup in cloud computing are discussed in [58]. In [59], the authors present a review of the research in cloud computing security, point out threats and challenges, and propose ideas for resolving cloud data integrity. Based on the analysis of existing works on cloud computing security, in [60], the authors identify associated challenges and propose some recommendations. In [61], a layered security performance management model is studied. In [62], the authors propose a method for the estimation of access to cloud data and a new security access control scheme.

Table 2. Summary of the recent research on cloud management.

Cloud Management Aspects	Reference Numbers	Considered Problems
Multi-cloud platform management	[50,51,52]	Architectures, performance optimization, unified management
Cloud resource allocation	[53,54,55,56,57,58]	Principles, algorithms, performance, data recovery and backup
Cloud security	[59,60,61,62]	Threats, challenges, recommendations, access control methods

summarises the latest research on cloud management.

The variety of works conducted on railway edge clouds and cloudified railway applications do not concern the interfaces between clouds and the rest part of the railway control system. They focus on control functions that could be cloudified and on the benefits of user proximity. The mechanisms of interaction between edge rail applications and managed railway objects are not refined. Works related to cloud computing platform’s architectures consider resilient and secured frameworks that make it possible to embed intelligent and virtualised functions which stress reliability, safety, and security requirements. Railway cloud management, being a unified, open, and multi-vendor solution, seems to be an open research question.

The existing research related to industrial clouds focuses on multi-cloud interoperability and cloud resource management issues. The proposed cloud management architectures provide high-level views without elaborating on management functionality, generic cloud management services, management functions, and numerous elements. Furthermore, the interworking between cloud services management and controlled components, as a complex of interfaces and procedures, is left without discussion or in-depth typical use cases. Interworking implies an increase in complexity; however, this must be achieved without compromising the vital key performance indicators.

This literature review shows that there is a lack of unified open cloud management platforms that meet the strict requirements of railway operators for ultra-high reliability, safety, and security.

In this paper, novel railway cloud functions and a unified management interface are proposed. The presented cloud-based railway control architecture enables a railway operator to both use clouds from different providers and manage them uniformly. The suggested cloud management functionality is synthesised as services for the orchestration of railway cloud life cycle processes based on open interfaces. Open interfaces expose improved capacity, high reliability, and better service provisioning in comparison with any proprietary ones.

The intelligent railway control system architecture presented in [24] aims to enhance resiliency, scalability, automation, interoperability, innovation fostering, unified management, and enhanced security. The architecture is cloud-based and enables hardware and software disaggregation, eliminates the need for proprietary hardware, and mitigates the vendor-dependency risks. The cloudification of railway functions fosters scalability, enabling the deployment of flexible and modular components. The architecture allows for embedding intelligence in railway operation and management, incorporating machine learning (ML) framework, and providing an environment to run both non-real-time and near-real-time AI applications. It has the potential to improve interoperability as railway operators can manage different components based on open application programming interfaces (APIs), which also reduces complexity and fosters innovation. The focus in [24] is on the disaggregation of control functionality related to the automation of railway functions and the open interface between time-tolerant and time-sensitive control.

In [24], the intelligent control functionality is elaborated on, and a microservices-based approach to the design of AI/ML lifecycle procedures is proposed. Microservices’ functionality includes the discovery of the capabilities of the ML model and inference host, ML model training, selection, deployment, inference, performance monitoring, retraining updates, and termination.

In this paper, the focus is on railway cloud as an important component of an intelligent railway control system architecture and its interface towards achieving the management, automation, and orchestration of a platform. This paper’s novelty lies in our proposed approach to design railway cloud management and orchestration functionality as microservices. Our research findings will hopefully enable railway operators to develop their own Mobility as a Service (MaaS) applications that offer customised mobility solutions tailored to the user’s individual needs [63].

The research methodology includes an analysis of basic railway cloud orchestration use cases, the identification of railway cloud management functionality, the synthesis of railway cloud orchestration microservices, the verification of microservices, and the evaluation of microservice performance indicators, which are all critical for creating railway operations that are reliable and safe. The analysis of railway cloud orchestration includes cases, with the goal of deriving the requirements of railway cloud management functionality. Based on these requirements, the basic functionality required for railway cloud provisioning is identified and synthesised as services. As microservice design follows the Representational State Transfer (REST) principles, the basic service resources are identified and organised in tree structures, the methods that allow for resource manipulation are determined, and data types and structures are modelled. The verification of microservices is conducted by modelling the common logics of orchestration applications and microservices, which must be synchronised. The last step of this research methodology aims to demonstrate the benefits of the proposed approach for fulfilling strong railway requirements by evaluating latency, as one of the key performance indicators, which is injected by the microservices’ application programming interfaces.

3. Railway Cloud Basic Concepts, Management, and Orchestration Services

A railway cloud platform may be regarded as a cloud computing platform that meets the requirements to host the relevant cloudified railway functions and supporting software components. It is required to expose the appropriate management and orchestration functions through service-based interfaces. A railway operator may employ clouds from different providers, but they need to manage them in a uniform way. The railway cloud platform hardware is composed of computing, storage, and networking resources grouped in one centralised or more distributed railway cloud resource pool. The railway cloud platform software, including virtualisation software, services, and management tools, is decoupled from the hardware and exposes open API, which improves flexibility and mitigates dependency on a single vendor.

Railway cloud resources are organised in resource pools. A railway cloud node, or simply a node, is a logical or physical server with assigned cloud resources and an operating system. Several nodes form a group. One or more groups form railway cloud clusters with the aim of achieving the required availability. Within a group, the nodes are interconnected in a group network. Within a railway cloud cluster, communication is based on a cluster network, which unites all group networks included in it. One or more railway cloud clusters can be installed at a given location (site). A united network exists for the site clusters. For each site, there is a gateway from one or more network providers to enable communication across the whole railway cloud. A specific role is assigned to each node. Some of the nodes may be dedicated to cloud management functions, whereas other nodes may be exposed to functions that manage the resources assigned to the cloudified functions, and there may be some nodes that host the cloudified railway functions.

The Railway Management Automation and Orchestration (RMAO) platform, as an integral part of the intelligent railway control system, is responsible for the management and orchestration of resources and services. It is responsible for service provisioning and lifecycle management, resource orchestration, and service assurance. The management interface between the RMAO platform and the railway cloud platform (RCP) needs to support two types of services:

• Cloud resource management (CRM) services which are responsible for the allocation and delivery of cloud resources and resource management software, i.e., services that orchestrate railway cloud lifecycle processes, e.g., cloud deployment services, cloud infrastructure catalogue services, railway cloud monitoring services, railway cloud provisioning services, etc.
• Cloudified function management (CFM) services which manage the lifecycles of the cloudified railway functions deployed on the railway cloud.

Figure 1 shows the basic concepts and services related to the railway cloud.

The basic orchestration of the railway cloud is related to the railway cloud’s provisioning. The provisioning of the railway cloud includes the railway cloud’s deployment and the integration of cloud services within the railway infrastructure. It assumes that the basic infrastructure (e.g., physical resources) is built and installed and that secured connectivity between the components of the intelligent railway control systems exists. The focus is on the deployment of railway cloud services and resource allocation.

The following use cases represent well-known steps in the basic orchestration of the railway cloud, as show in Figure 2:

• Railway cloud pre-deployment processing. The RMAO creates a record associated with the new railway cloud in its catalog.
• Railway cloud platform software installation. The RMAO initializes the railway cloud, enabling communication with the RCP.
• Railway cloud registration and initialization. The RMAO initializes and registers the railway cloud and prepares it for installing the cloudified railway functions.
• Railway cloud post-deployment hardware infrastructure scaling. The RMAO powers on and initializes additional railway cloud nodes for an existing railway cloud.
• Railway cloud platforms software update. The RMAO upgrades or downgrades the platform software of an existing railway cloud.
• Functional status query and update. The RMAO queries and updates of the functional status of the railway cloud resources.
• Update of CRM software. The RMAO updates the railway cloud’s CRM service software.
• Update of CFM software. The RMAO updates the railway cloud’s CFM service software.

Figure 2. Basic railway cloud’s orchestration use cases.

Figure 2. Basic railway cloud’s orchestration use cases.

4. Railway Cloud Orchestration Use Cases

A railway operator may have multiple edge railway clouds to face the requirements of real-time functionality, and in this case, the railway clouds’ deployment must be performed by the RMAO platform. Railway cloud instantiation and deployment are triggered by the RMAO platform and include pre-deployment processing, platform software installation, registration, and activation.

Railway cloud pre-deployment processing is required to configure the RMAO platform to add a railway cloud into its catalogue prior to the activation and registration of the railway cloud. The process is initiated by the cloud manager, and the RMAO platform generates a unique identification of the new cloud instance and creates a catalogue with the railway cloud ID. Then, the new railway cloud nodes are installed, and connectivity is setup by the personnel; afterwards, the RMAO is notified and provided with information to connect to the built railway cloud, including the target node and identity of the basic software to be loaded onto the railway cloud. The RMAO uploads the railway cloud’s basic software on the first railway cloud node, which in turn raises the railway cloud to additional railway cloud nodes. The CRM services in the RCP load the railway cloud’s basic software onto other nodes, activate CFM services, and create the software catalogue.

Figure 3 shows the high-level interaction between the RMAO platform and the RCP during the pre-processing of the railway cloud and installation of the platform software.

The registration and initialisation of the railway cloud include the update of the CRM services’ software catalogue, if required, configuration of the railway cloud, discovery of new CFM services and their capabilities, and registration of them in the railway cloud catalogue.

The update of the railway cloud catalogue is related to the renovation of information about the railway cloud type and its capabilities, e.g., resource configuration, capacity, allocations, applications, and availability. It is triggered upon an initial railway cloud deployment or later when changes are required. The scaling of the hardware infrastructure of the railway cloud is related to resource scale-up or -down and it is triggered, e.g., when a decision is made to install and register a new railway cloud node. In this case, the railway cloud catalogue update procedure is used.

The railway cloud platform’s software update must ensure service continuity. As a precondition, the cloudified railway functions, deployed on the affected edge railway clouds, need to be migrated to other railway clouds. Within the update process, CRM services download and validate the software, perform a pre-check procedure to determine whether the software is acceptable or not, update the software’s images, perform a restart, if required, and update the software catalogue. In case of software update failure, a roll-back procedure to the working software version takes place.

The update of CRM and CFM services’ software includes software download, pre-checking, modification, and testing. To provide more details on upgrading or downgrading the software of the CFM services, this use case is elaborated as follows and illustrated in Figure 4.

The CFM services’ software update process is triggered by the railway cloud manager, who requests the RMAO platform to update the software version within a railway cloud. To synchronise CFM services’ software, the RMAO platform queries the CRM services in the RCP for its current software catalogue, and if the software catalogue is not the required one, the RMAO platform provides information about the software version. If the CRM services obtain the requested software version, then the RMAO platform is notified that the software version is available; otherwise, the RMAO platform is notified that the software update is unsuccessful. The deployment of the CFM services’ software images begins with pre-checking, which is requested by the RMAO platform. If the pre-check procedure shows that the requested software version is acceptable, the RMAO platform is notified and, in turn, it instructs the CRM services to install the new CFM services’ software. The CRM services allocate the necessary resources, install the requested software version, and perform specific testing. In the case of a successful software update, the CRM services update their software catalogue and notify the RMAO. Any failure during the deployment of the CFM services’ software is reported to the RMAO. The software update process terminates with a notification to the railway cloud manager about the result.

Based on the analysis of basic use cases of railway cloud orchestration, requirements could be derived. As preconditions, the railway cloud hardware must be installed, pre-configured and ready, and a stable connectivity must exist. The basic requirements related to the orchestration of the railway cloud are as follows:

• The RMAO needs to assign a unique identifier to a newly deployed railway cloud that will be used for handling the cloud registration process.
• The RMAO needs to load the railway cloud platform software on the first node.
• The CRM services need to load the basic railway cloud software on the other nodes to configure and activate the CFM services and to create/refresh the software catalogue.
• The RMAO needs to be able to query the CRM services about the software catalogue to configure the CFM services, if required, and to register the CFM services in its catalogue.
• The RMAO should be able to update information in the railway cloud catalogue (e.g., resource configurations, capacity, utilisation, etc.) or to add information about a newly installed node.
• The RMAO should be able to scale the railway cloud hardware infrastructure.
• The RMAO should be able to update the railway cloud platform software by triggering the software download and validation procedure.
• The CRM services need to be able to perform pre-checking of the downloaded software to migrate the cloudified railway functions deployed on the affected nodes to other nodes, to update the software images, and to perform a restart if required.
• The RMAO needs to be able to query and update the railway cloud functional status.
• The RMAO needs to be able to update the software of the CRM services and the software of the CFM services, including the triggering of the requested software version’s download, pre-checking, installing, and catalogue update.
• The RMAO needs to notify the railway cloud operator about the result of the orchestration process.

The requirements for the orchestration of the cloudified railway functions include the following capabilities:

• Instantiation of the cloudified railway functions on the cloud.
• Scaling of the cloudified railway functions.
• Software update of the cloudified railway functions.
• Termination of the cloudified railway functions.

In addition to the considered basic use cases, orchestration includes functionality for railway cloud and cloudified function healing, alarm management, performance management, network connection management, provisioning, and resource optimisation.

The next section presents an approach to design the railway cloud’s orchestration functionality as microservices. The focus is on microservices related to the software update of CRM and CFM services.

5. Microservices for Railway Cloud Orchestration

The identified railway cloud orchestration functionality can be designed as RESTful microservices. Microservices enable the design of a modular application, which allows for rapid and reliable application development. Microservices can be deployed independently; they communicate using APIs and are loosely coupled. The well-known benefits of the design of microservices include resilience, reusability, technological independence, and easy deployment.

RESTful microservices are designed following the principles of the REST client–server architectural style. RESTful services expose uniform APIs that feature scalability, updatability, and performance. In REST, functionality and data are regarded as resources, which are accessible through Uniform Resource Identifiers (URIs), which are usually web addresses. Every content can be treated as a resource. A resource is represented by its type, associated data (called resource attributes), relationships with other resources, and a set of applicable methods. Resources are manipulated through their representations, where the clients and server exchange resource representation using HTTP methods (POST to create a new resource, GET to retrieve resource information, PUT or PATCH to update a resource, and DELETE to remove a resource). Both data modelling techniques and object-oriented design are used to identify resources based on the analysis of railway cloud orchestration use cases.

5.1. Design of Microservices

The main entities in railway cloud orchestration are related to the railway cloud catalogue. The railway cloud catalogue contains information about the cloud physical and logical resources and cloudified railway functions deployed on the cloud. The RMAO can retrieve information about the assigned cloud resources and their uses. The catalogue information is manipulated by RMAO provisioning requests for cloud resource assignment, e.g., in the case of faults or maintenance operations. The catalogue information is exchanged between the orchestration services in the RMAO and CRM services in the RCP. When resources are needed in railway cloud clusters, the CRM services can add a resource to the respective cloud resource pools, allocate resources to the nodes or the site networks, and notify the RMAO. The RMAO can discover railway cloud clusters, a cluster network, and nodes.

The railway operator may have clouds based on different virtual cluster technologies and those provided by different vendors. Each railway cloud cluster provides CFM services and exposes an interface towards the RMAO, which enables the lifecycle management of the cloudified railway functions. The CRM software catalogue contains information about different CRM services, devoted to, e.g., railway cloud software platform installation, railway cloud registration and initialisation, railway cloud catalogue update, cloud platform software update, railway cloud functional status query and update, CRM services’ software update, and CFM services’ software update.

Therefore, the relevant resources related to basic railway cloud orchestration represent information about the railway cloud platform, platform software, and CRM and CFM services’ software. The considered use case illustrated in Figure 3 exemplifies interface functionality for the software update of CFM services; more details on the CRM services’ software catalogue are described.

In addition to the resources representing the CRM services’ software, the software catalogue contains a resource that represents the list of available CFM service packages, which could be based on different virtual cluster technologies. This resource is a container of resources, each of which represents a package of CFM services. The resource representing a specific CFM service package contains a sub-resource representing the list of available software versions of this package. A specific software version of the CFM service package is also represented by a resource. The resource representing a specific software version contains a resource representing the list of CFM services, and the individual CFM service in a specific CFM package version is also presented as a resource. A resource, representing all active subscriptions for notifications about changes in the state of a specific resource, could be attached to the resource. The resource representing all active subscriptions is a collection of individual subscriptions.

The resources identified so far are organised in a tree structure, where all the resource URIs have a root, namely the URI of the list of CFM service packages and could be published in a service registry.

Table 3. CFM services’ software update: resources and methods summary.

Resource Name	Resource URI	HTTP Method	Meaning
CFM service packages	…/CFMservicePackages	GET	Retrieves information about the list of available CFM service packages.
A specific CFM service package	…/CFMservicePackages/{CFMservicePackageID}	GET	Retrieves information about specific CFM service packages.
All software versions of the specific CFM service package	…/CFMservicePackages/{CFMservicePackageID}/SWversions	GET	Retrieves the list of software versions of the CFM service package.
		POST	Creates a new software version of the CFM service package.
An individual software version	…/CFMservicePackages/{CFMservicePackageID}/SWversions/{SWversionID}	GET	Retrieves information about specific software versions of the CFM service package.
		PUT	Updates information about the software version.
		DELETE	Deletes the software version.
All CFM services in the software version	…/CFMservicePackages/{CFMservicePackageID}/SWversions/{SWversionID}/CFMservices	GET	Retrieves the list of all CFM services in the software version.
An individual CFM service	…/CFMservicePackages/{CFMservicePackageID}/SWversions/{SWversionID}/CFMservices/{CFMserviceID}	GET	Retrieves information about specific CFM services.
		PUT	Updates the CFM service.
		DELETE	Deletes the CFM service.

summarises the names, URIs, and applicable HTTP methods to the resources related to the software update of CFM services. For simplicity, the table does not include subscription-related resources.

The applicable HTTP methods to the resource representing all active subscriptions related to the state of other resources are GET, which retrieves the list of all subscriptions, and POST, which creates a new subscription. The resource representing an individual subscription could be manipulated by applying the GET method, which retrieves the subscription information, the PUT method, which modifies the subscription, and the DELETE method, which removes the subscription.

The data model defines the data structures that are used in resource representation. The resource attributes are metadata that provide information about properties associated with the resource.

Figure 5 shows the structure of the resource representing an individual CFM service software, which is described by its attributes and sub-resource. In addition to common attributes such as access rights, creation time, and last modification time, the attributes of the resource, representing CFM service software, include the CFM service name, software version, service software URI, and the software action status, which indicates the status of the action (i.e., progress indicator or final state). The software action resource is a sub-resource, which is described by attributes that allow the new software to be downloaded, pre-checked, installed, tested by CRM services, tested by CFM services, activated, or deactivated. The execution of an action on the CFM service software is triggered by applying the HTTP PUT method to the corresponding software action’s attribute.

The logic of orchestration applications and the microservices’ logic manipulate the state of resources by applying the respective HTTP methods on them.

5.2. Verification of Microservices

The orchestration application logic must maintain the state of the software update process. It triggers the transitions in the model by applying the supported HTTP methods on the resources related to the software update service. On the other hand, the respective CRM microservice in the RCP also needs to have a view of the software update process, which must be synchronised with the view of the orchestration application.

To illustrate the practicability of the proposed microservices-based approach to the design of railway cloud orchestration services, models representing the state of the CFM services’ software process are developed. The models reflect the views on the process state of the orchestration application and of the respective CRM microservice.

Figure 6 shows the CFM services’ software update model supported by the orchestration application.

The CFMswUpdateStart state is the initial state of the CFM software update process. A request to update triggers the CFM software image binaries’ synchronisation. In the CFMswImagesQuery state, the application queries the software catalogue. In the CFMswImageSynchronisation state, the requested software version images are not in the catalogue, and information about the software version is sent to the CRM microservice. In the CFMswPrecheck state, a pre-check procedure of the software version is performed. In the CFMsoftwareUpdate state, the new CFM services’ software version is updated. In the CFMswUpdateCompleted state, the update process has been completed successfully. Any failures in the update process result in transition to the CFMswUpdateFailed state.

Figure 7 shows the CFM services’ software update model supported by the CRM microservice.

The SWupdateStart state is the initial state of the CFM services’ software update from the CRM service point of view. The update process moves to the ObtainingSWversion state if software binaries synchronisation is needed, and in this state, the CRM microservice obtains the software version information. In the PrecheckingSWversion state, a preliminary internal check of the new CFM software version is performed. Pre-checking includes validation of the software version images in the SWversionValidation state. The transition to the ResourceAllocationAndSWinstallation state is triggered upon a command to install the new software version. In this state, the CRM microservice ensures that the update conditions are met, requests resource allocation and software version installation, then marks the CFM services’ software as modified. The triggering of a testing procedure moves the software update process to the SWversionTesting state. In the SWcatalogueUpdate state, the CRM microservice updates its software catalogue and moves to the final SWupdated state. If the software test fails, the CRM service requests roll-back to the previously running CFM services’ software version (the RollingBackSWversion state) and moves to the SWnotUpdated state. A transition to the SWnotUpdated state is also triggered when the pre-checking procedure fails.

To prove mathematically that both software update models are correct and synchronised, it is necessary to describe the models formally, for which the Labelled Transition System (LTS) concept is used. An LTS is a tuple (S, L, T, s₀), where S is a finite set of states, L is a finite set of labels that trigger the state transitions, T is a state transition relation, and s₀ is an initial state.

In the following definitions, the names of the states and labels are denoted by short notations in brackets.

Definition 1. 

Let M^app = (S^app, L^app, T^app, s^app₀) be an LTS representing the model of the CFM services’ software update process, supported by an orchestration application, where:

S^app = {CFMswUpdateStart [s^a₁], CFMswImagesQuery [s^a₂], CFMswImageSynchronization [s^a₃], CFMswPrecheck [s^a₄], CFMsoftwareUpdate [s^a₅], CFMswUpdateCompleted [s^a₆], CFMswUpdateFailed [s^a₇]}

L^app = {cloudSWupdateReq [l^a₁], getCloudSWcatalogRes(available) [l^a₂], getCloudSWcatalogRes(unavailable) [l^a₃], swVersionAvailable [l^a₄], swVersionUnavailable [l^a₅], swPrecheckRes(ok) [l^a₆], swPrecheckRes(nok) [l^a₇], installSWversionAck [l^a₈], installSWversionErr [l^a₉]}

T^app = { (s^a₁ l^a₁ s^a₂), (s^a₂ l^a₃ s^a₃), (s^a₃ l^a₄ s^a₄), (s^a₂ l^a₂ s^a₄), (s^a₄ l^a₆ s^a₅), (s^a₃ l^a₅ s^a₇), (s^a₄ l^a₇ s^a₇), (s^a₅ l^a₈ s^a₆), (s^a₅ l^a₉ s^a₇)}

s^app₀ = CFMswUpdateStart [s^a₁].

Definition 2. 

Let M^crm = (S^crm, L^crm, T^crm, s^crm₀) be an LTS representing the model of the CFM services’ software update process, supported by the CRM microservice, where:

S^crm = {SWupdateStart [s^m₁], ObtainingSWversion [s^m₂], PrecheckSWversion [s^m₃], SWversionValidation [s^m₄], ResourceAllocationAndSWinstallation [s^m₅], SWversionTesting [s^m₆], SWcatalogUpdate [s^m₇], SWupdated [s^m₈], RollingBackSWversion [s^m₉], SWnotUpdated [s^m₁₀])

L^crm = {getCloudSWcatalogReq [l^m₁], swVersionInfo [l^m₂], swVersionObtained [l^m₃], swPrecheckReq [l^m₄], validateSWversionReq [l^m₅], validateSWversionRes [l^m₆], validSWversion [l^m₇], invalidSWversion [l^m₈], installSWversionCom [l^m₉], resourceAllocationRes [l^m₁₀], installSWversionRes [l^m₁₁], swTest(ok) [l^m₁₂], testSWversionRes(ok) [l^m₁₃], activateSWAck [l^m₁₄], swTest(nok) [l^m₁₅], testSWversionRes(nok) [l^m₁₆], rollbackSWversionRes [l^m₁₇]}

T^crm = {(s^m₁ l^m₁ s^m₁), (s^m₁ l^m₂ s^m₂), (s^m₂ l^m₃ s^m₂), (s^m₁ l^m₄ s^m₃), (s^m₂ l^m₄ s^m₃), (s^m₃ l^m₅ s^m₄), (s^m₄ l^m₆ s^m₃), (s^m₃ l^m₇ s^m₃), (s^m₃ l^m₈ s^m₁₀), (s^m₃ l^m₉ s^m₅), (s^m₅ l^m₁₀ s^m₅), (s^m₅ l^m₁₁ s^m₆), (s^m₆ l^m₁₂ s^m₆), (s^m₆ l^m₁₃ s^m₇), (s^m₇ l^m₁₄ s^m₈), (s^m₆ l^m₁₅ s^m₉), (s^m₆ l^m₁₆ s^m₉), (s^m₉ l^m₁₇ s^m₁₀)}

s^crm₀ = SWupdateStart [s^m₁].

The proof that both models support synchronised views on the state of the software update process is based on the fundamental notion of a weak bi-simulation. Bi-simulation uses structural conditions to characterise the equivalent (indistinguishable) observable behaviour of concurrent processes. It is a binary relationship between the states which associates the concurrent processes that behave in the same way [64,65]. Weak bi-simulation hides internal transitions which are not externally visible in the process behaviour. It is used for model verification and constraints satisfaction.

Proposition 1. 

The LTSs representing the model of the CFM services’ software update process, supported by an orchestration application and by the CRM microservice (namely, M^app and M^crm), expose equivalent behaviour.

Proof. 

By R₁ = {(s^a₁, s^m₁), (s^a₄, s^m₃), (s^a₅, s^m₅), (s^a₆, s^m₈), (s^a₇, s^m₁₀)} it is denoted a relationship between the states of M^app and M^crm. The following bijection function between transitions in the state pairs in R₁ is identified:

• A software update is triggered, a CFM services’ software image binaries synchronisation takes place, a pre-check of the new CFM services’ software version is triggered: ∀ (s^a₁ l^a₁ s^a₂) ∧ ((s^a₂ l^a₃ s^a₃) ∧ (s^a₃ l^a₄ s^a₄) ∨ (s^a₂ l^a₂ s^a₄)) ∃ (s^m₁ l^m₁ s^m₁) ∧ ((s^m₁ l^m₂ s^m₂) ∧ (s^m₂ l^m₃ s^m₂) ∧ (s^m₂ l^m₄ s^m₃) ∨ (s^m₁ l^m₄ s^m₃)).
• The pre-check procedure is successful, and a software uploading is triggered: ∀ (s^a₄ l^a₆ s^a₅) ∃ (s^m₃ l^m₅ s^m₄) ∧ (s^m₄ l^m₆ s^m₃) ∧ (s^m₃ l^m₇ s^m₃) ∧(s^m₃ l^m₉ s^m₅).
• The pre-check procedure is unsuccessful: ∀ (s^a₄ l^a₇ s^a₇) ∃ (s^m₃ l^m₈ s^m₁₀).
• The CFM services’ software upload, which includes resource allocation, software installation and testing, is successful: ∀ (s^a₅ l^a₈ s^a₆) ∃ (s^m₅ l^m₁₀ s^m₅) ∧ (s^m₅ l^m₁₁ s^m₆) ∧ (s^m₆ l^m₁₂ s^m₆) ∧ (s^m₆ l^m₁₃ s^m₇) ∧ (s^m₇ l^m₁₄ s^m₈).
• The CFM services’ software is uploaded, resources are allocated, and the software is installed, but the test procedures fail, and a rollback procedure is executed: ∀ (s^a₅ l^a₉ s^a₇) ∃ ((s^m₅ l^m₁₁ s^m₆) ∧ ((s^m₆ l^m₁₅ s^m₉) ∨ (s^m₆ l^m₁₆ s^m₉)) ∧ (s^m₉ l^m₁₇ s^m₁₀).

The identified bijection function between the transitions in the state pairs in R₁ proves that R₁ is a weak bi-simulation relationship and, therefore, the behaviour of both LTSs representing the model of the CFM services’ software update process, supported by an orchestration application and by the CRM microservice, is equivalent. □

A respective CFM microservice also participates in the process of CFM services’ software update. Figure 8 shows the model representing the software update process from the CFM service’s point of view.

The SWupdate state is the initial state of the software update process. In the ResourceAllocation state, cloud resources are assigned. In the SWinstallation state, the new software version is installed. The testing of the newly installed SW version takes place in the SWtesting state; the new software version is activated in the SWactivation state, and in the UpdatedSW state, the CFM services’ software is successfully updated. In the SWversionRollback state, the previously running SW version is rolled back, and the process moves to the NotUpdatedSW state.

Definition 3. 

Let M^cfm = (S^cfm, L^cfm, T^cfm, s^cfm₀) be an LTS representing the model of the CFM services’ software update process, supported by the CFM microservice, where:

S^cfm = {SWupdate [sⁿ₁], ResourceAllocation [sⁿ₂],SWinstallation [sⁿ₃], SWtesting [sⁿ₄], SWactivation [sⁿ₅], UpdateSW [sⁿ₆], SWversionRollback [sⁿ₇], UpdatedSWNot [sⁿ₈]}

L^cfm = {resourceAllocationReq [lⁿ₁], alocatedResources [lⁿ₂], installSWversionReq [lⁿ₃], swInstalled [lⁿ₄], testSWversionReq [lⁿ₅], testFailed [lⁿ₆], testPassed [lⁿ₇], activateSWCom [lⁿ₈], swActivated [lⁿ₉], rollbackSWversionReq [lⁿ₁₀], rollbackCompleted [l^m₁₁]}

T^cfm = {(sⁿ₁ lⁿ₁ sⁿ₂), (sⁿ₂ lⁿ₂ sⁿ₂), (sⁿ₂ lⁿ₃ sⁿ₃), (sⁿ₃ lⁿ₄ sⁿ₃), (sⁿ₃ lⁿ₅ sⁿ₄), (sⁿ₄ lⁿ₆ sⁿ₄), (sⁿ₄ lⁿ₇ sⁿ₄), (sⁿ₄ lⁿ₈ sⁿ₅), (sⁿ₅ lⁿ₉ sⁿ₆), (sⁿ₄ lⁿ₁₀ sⁿ₇), (sⁿ₇ lⁿ₁₁ sⁿ₈)}

s^cfm₀ = SWupdate [sⁿ₁].

Proposition 2. 

The LTSs representing the model of the CFM services’ software update process, supported by the CRM microservice and the CFM microservice (namely, M^crm and M^cfm), expose equivalent behaviour.

Proof. 

By R₂ = {(s^m₁, sⁿ₁), (s^m₅, sⁿ₂), (s^m₆, sⁿ₄), (s^m₈, sⁿ₆), (s^m₁₀, sⁿ₈)} it is denoted a relationship between the states of M^crm and M^cfm. The following bijection function between transitions in the state pairs in R₂ is identified:

• A software update is triggered, the new software version is available pre-checked, and a resource allocation is triggered: ∀ (s^m₁ l^m₁ s^m₁) ∧ ((s^m₁ l^m₂ s^m₂) ∧ (s^m₂ l^m₃ s^m₂) ∧ (s^m₂ l^m₄ s^m₃) ∨ (s^m₁ l^m₄ s^m₃)) ∧ (s^m₃ l^m₉ s^m₅) ∃ (sⁿ₁ lⁿ₁ sⁿ₂) ∧ (sⁿ₂ lⁿ₂ sⁿ₂).
• The resource allocation is done, the new SW version is installed, and a testing procedure is triggered: ∀ (s^m₅ l^m₁₀ s^m₅) ∧ (s^m₅ l^m₁₁ s^m₆) ∃ (sⁿ₂ lⁿ₃ sⁿ₃) ∧ (sⁿ₃ lⁿ₄ sⁿ₃) ∧ (sⁿ₃ lⁿ₅ sⁿ₄).
• The new SW version successfully passes the testing procedure, and it is activated: ∀ (s^m₆ l^m₁₂ s^m₆) ∧ (s^m₆ l^m₁₃ s^m₇) ∧ (s^m₇ l^m₁₄ s^m₈) ∃ (sⁿ₄ lⁿ₇ sⁿ₄) ∧ (sⁿ₄ lⁿ₈ sⁿ₅) ∧ (sⁿ₅ lⁿ₉ sⁿ₆).
• The test of the new SW version fails, and a rollback to the previous SW version is done: ∀ (s^m₆ l^m₁₆ s^m₉) ∧ (s^m₉ l^m₁₇ s^m₁₀) ∃ (sⁿ₄ lⁿ₇ sⁿ₄) ∧ (sⁿ₄ lⁿ₁₀ sⁿ₇) ∧ (sⁿ₇ lⁿ₁₁ sⁿ₈).

Therefore, R₂ indicates a weak bi-simulation relationship, and M^crm and M^cfm expose equivalent behaviour. □

5.3. Validation of Microservices

Key performance indicators (KPIs) are essential metrics measuring the smooth operation of microservices and applications. Measuring KPIs and statistical performance analysis could reveal management operation improvement opportunities. In order to demonstrate the benefits of the proposed approach for fulfilling the strong mission critical requirements of railway operations and to validate the synthesised microservices, latency, injected by the microservices’ API, is evaluated.

Latency is referred to as one of the functional metrics related to the performance of microservices. It is, in general, time-variable and could be measured in a specified time interval and described by a profile over time. The concept of latency is wide, but in this paper, latency is defined as the time taken for an HTTP request, generated by a railway cloud orchestration application to get to the server that hosts microservices, and the time taken by the respective HTTP response to travel back.

The RESTful approach is based on the well-known client–server pattern and considering that the requirement about the cross-platform property of the implementation must be kept, the programming tool Java is used for the numerical simulation. Both sides of the interface are deployed in a single group in order to avoid any influence of outer traffic. This makes the results as reference for a lower bound estimation of the latency with as modest resources allocated as four cores of the CPU and memory of four GBs. The client- and server-side are multi-threaded, but, purposefully, no scale-up is allowed. The results in terms of latency, shown in Figure 9, represent a frame of two thousand operations over the interface in a consecutive manner without any delays between.

The time frame is chosen well after the initial lazy instantiation of the objects. It might be observed that the mean of the latency is about 2 milliseconds, and the major part of the value is up to about 4 milliseconds. However, a minority of values exist that hit almost 50 milliseconds, and this is a clear signal that, if the load increases, one should expect further degradation of the indicator.

6. Railway Cloud Issues Regarding Safety and Security

The migration of railway control systems, real-time monitoring, and operation management to the cloud bring about challenges in terms of railway safety and security, and railway cloud management plays an important role in achieving the necessary requirements.

The aim of railway safety is to protect passengers, the environment, and railway assets by applying automatic protection functions. Railway safety requires understanding potential risks for the malfunctioning of equipment and software errors and to minimise their impact. The proposed railway cloud management system could assist in these processes. Usually, the proper automatic protection functions include the monitoring of system performance, the safe delivery of updates, and risk management. Functional railway safety requires performance assessment of the cloud and virtualised resources, identification of the risks for achievement of the required performance, risk mitigation by redundancy in the system design, and proving a performance achievement. For virtualised resources, it is important to provide operation continuity while minimising recovery time, which means that high cloud availability could be achieved by railway system resilience instead of individual equipment resilience. The required level of resilience can be achieved by distributed railway clouds and increasing the railway cluster’s redundancy instances for on-time replacements. In the cloud, railway operators can continuously monitor workflows to discover faults and errors, as well as network traffic anomalies, or to balance the load. An important factor for railway system resilience is also the cloud archiving capabilities that facilitate recovery from failures.

The aim of railway cloud security is to protect cloud-based infrastructure, applications, and data. The main railway cloud security benefits are as follows:

• Lower investments and reduced operational costs due to the security and compliance framework respected by cloud services providers.
• Improved reliability and availability based on the authorized access to data and centralized security control.
• Flexible cloud security scaling with evolving requirements.
• Improved protection against distributed denial of service via continuous attack monitoring and dispersing.

The main railway cloud components and data that must be protected include the following: software images repository, cloud catalogue information for hardware and software resources, cloudified railway functions information, software components and their associated data, private keys, certificates and credentials, railway cloud and cloudified railway function monitoring, etc.

The requirements of railway cloud security could be derived through the analysis of threats. For example, a railway cloud API attack could affect cloud deployments through a compromised virtualisation layer, which may result in information disclosure or tampering, or the denial of a service. Such unsecured cloud API and the lack of authorisation could impact availability, integrity, and confidentiality. Some of the common requirements to achieve cloud security can be found in published security guidelines and best practices. They include certificate management, cloud network segmentation and traffic filtering, identity authentication, access management, security configuration by cloud virtualisation level, secure lifecycle of the cloudified functions and applications, protection of software images, logging, monitoring, and alerting of threats, and security audit. In addition, secured access to encrypted storage, hardware, and network security protection must be provided.

7. Conclusions

The movement of the railway industry to the use of cloud technology brings with it many benefits that could improve the operation of railways and enhance passenger experience with travel-centric and innovative services. To provide high reliability, safety, and security, the railway cloud needs to ensure management and orchestration functionality.

In this paper, we proposed an approach to design railway cloud management and orchestration functionality as microservices. The main research contributions are summarised as follows:

• Identification of the key railway cloud concepts
• Recognition of the general principles of the railway cloud management and orchestration interface
• Description of some of the basic use cases related to the railway cloud orchestration
• Definition of requirements for the railway cloud orchestration
• Synthesis of cloud orchestration functionality as microservices by identification of resources, representing physical or logical objects in the railway cloud orchestration, their structure, applicable methods, and data types
• Verification of microservices by modelling the common orchestration logic of microservices and railway applications
• Validation of microservices by evaluation of latency injected by the microservices API as a key performance indicator for mission-critical applications.

Some issues related to the safety and security of the railway cloud are considered.

The main benefits of the proposed approach in comparison with any proprietary solutions are that it defines an open and extensible railway cloud management and orchestration interface that enables the addition of functions and information without changing the existing procedures. It also enables a railway operator to employ clouds from different vendors and to manage and orchestrate these clouds in a uniform way. The identified functionality and the proposed approach are independent of the specific RMAO platform and railway cloud platform implementations and enable a third party to create and integrate their orchestration applications using the interface.

Despite these benefits, which are inherent to microservices, potential drawbacks and challenges exist. The management of microservices is complex due to their number and interdependencies, as well as the increased use of computing and storage resources, which leads to decreases in performance. APIs inject latency due to network communications, which may cause network congestion. Some challenges in microservices-oriented design include ensuring service data consistency and integrity across different microservices, testing challenges, and security challenges, requiring the implementation of security measures across all microservices. These disadvantages could be mitigated through proper planning, design, and management.

Future works will aim to cover management functionality related to cloudified railway functions, including the description of related use cases and microservices’ design, verification, and validation. Management functionality will encompass basic cloudified railway function orchestration use cases, the recovery use cases, fault use cases, performance management use cases, provisioning use cases, and resource optimisation use cases.