Management of Virtualized Railway Applications

Abstract

Robust, reliable, and secure communications are essential for efficient railway operation and keeping employees and passengers safe. The Future Railway Mobile Communication System (FRMCS) is a global standard aimed at providing innovative, essential, and high-performance communication applications in railway transport. In comparison with the legacy communication system (GSM-R), it provides high data rates, ultra-high reliability, and low latency. The FRMCS architecture will also benefit from cloud computing, following the principles of the cloud-native 5G core network design based on Network Function Virtualization (NFV). In this paper, an approach to the management of virtualized FRMCS applications is presented. First, the key management functionality related to the virtualized FRMCS application is identified based on an analysis of the different use cases. Next, this functionality is synthesized as RESTful services. The communication between application management and the services is designed as Application Programing Interfaces (APIs). The APIs are formally verified by modeling the management states of an FRMCS application instance from different points of view, and it is mathematically proved that the management state models are synchronized in time. The latency introduced by the designed APIs, as a key performance indicator, is evaluated through emulation.

1. Introduction

The reliability and safety of railway transport are paramount, and a strong emphasis is placed on ensuring noninterrupted service and protection of human life and property. The use of cutting-edge technologies is transforming railways by automating critical services and optimizing infrastructure maintenance [1]. Automation enables the use of advanced technologies such as automatic train control, automatic train protection, and intelligent signaling to enhance safety and efficiency. Leveraging smart technologies can improve the condition and performance of rail infrastructure, reduce downtime, and increase overall operational reliability. The integration of artificial intelligence (AI), Internet of Things (IoT), and edge computing can help to create a safer, more reliable, and more efficient railway network that can handle the challenges of modern transportation [2,3,4,5,6]. Intelligent railways can quickly detect potential issues and prevent accidents through advanced analytics and AI-powered insights. They are able to identify and address potential threats before they become major problems, and thus reduce the risk of accidents or incidents [4]. Reliable and secure communications between trains, stations, and control centers are crucial for safe and efficient rail operation [7,8].

The Future Railway Mobile Communication System (FRMCS), defined as a global standard, aims to revolutionize railway communications. It is designed by the International Union of Railways as a successor of Global System for Mobile Communications-Railways (GSM-R). Based on fifth generation (5G) mobile communications, it will offer ultra-fast, secure, and wireless voice, video, and data transmission, providing enhanced performance, capacity, safety, and operational efficiency [9,10]. FRMCS will also provide a flexible platform for rail companies to develop new applications and services, making it easier to innovate and improve the railway system [11,12,13].

The FRMCS standardization process is ongoing. The specification of the first edition of FRMCS is expected to be completed by the end of 2026. The user requirements for FRMCS are captured in [14]. The functional use cases describe the interactions between a functional role and the system to achieve a certain goal [15]. The identified need, which is discussed in [16], is for interworking between GSM-R and mission-critical FRMCS applications, specified by ETSI (European Telecommunications Standard Institute), to enable communications between users and groups operating on the two systems. A high-level description of the logical architecture of the FRMCS is provided in [17]. The design of the FRMCS will follow the principles of Service-Based Architecture (SBA).

While the legacy narrowband GSM-R networks are based on a bare metal deployment, FRMCS is expected to provide bearer independence in order to support innovative services with ultra-high reliability and low latency. The FRMCS architecture will benefit from the use of the cloud, following the principles of the cloud-native 5G core network design, which is based on Network Function Virtualization (NFV) and Software-Defined Networking (SDN) [18]. With NFV, the management of the software-defined railway equipment will become more flexible and agile. Railway solutions will be in use for several decades, which requires FRMCS to be adaptable. Virtualization is the most suitable technological solution, enabling the addition of new functions with minimal efforts and migration to new software versions with cost savings. Virtualization is also beneficial for railway safety thanks to task segregation. Critical and non-critical railway tasks can run independently from each other on the same platform without compromising the safety-critical requirements. With NFV, the software-based functions access their own dedicated resources and, therefore, individual critical levels can be assigned to each of them. As is outlined in [19], SDN and NFV models have the potential to streamline and simplify the development and deployment processes of mission-critical railway networks, which must provide 99.999% reliability and safety.

In this paper, we propose a service-based approach to FRMCS application management in a virtualized environment. The focus is on the functionality of the deployment and lifecycle management of FRMCS applications, which are synthesized as RESTful services. The main contributions in this paper are summarized as follows:

• The requirements for FRMCS application package and lifecycle management are identified based on an analysis of different use cases.
• RESTful interfaces between entities involved in the management of FRMCS application packages and the lifecycle of FRMCS application instances are designed.
• A model representing the logic of an application, that manages the lifecycle of the FRMCS application instance using the APIs, and a model representing the logic of the managing service are developed and formally verified.
• The latency injected by the developed RESTful interfaces is evaluated as a key performance indicator through emulation.

The rest of the paper is structured as follows. The next section provides an overview of related work. Section 3 briefly presents the railway NFV cloud architecture that runs the FRMCS applications. Section 4 analyzes some use cases of FRMCS application package management and FRMCS application instance lifecycle management. Section 5 presents an approach to synthesizing the management functionality as services. The verification of the approach is provided in Section 6. The results of the API simulation are discussed in Section 7. Before the conclusion, Section 8 provides a discussion on the benefits and limitations of adoption of the NFV framework in railway control networks.

2. Related Works

In [20], the basic railway cloud concepts are defined, the functionality related to the orchestration of the railway cloud and deployments is studied, and the requirements for platform resource and workload management are derived. The basic functions of the cloud platform are designed as services. An approach to the design of the railway cloud resource management as a service is presented in [21].

The introduction of SDN and NFV and their impact on service provisioning and maintenance efficiency in railway control networks are discussed in [22]. The authors study configurable orchestration systems, which can dynamically instantiate the required services on virtual machines directly in the peripheral locations on the railway by means of edge computing solutions in order to perform maintenance operations on peripheral assets. In [23], the authors propose a high-level architecture for railway applications incorporating Multi-access Edge Computing, NFV, SDN, AI, and Blockchain, and study the impact that these technologies could have on existing rail applications, identifying the challenges and future directions for rail networks. In [24], two collaborative cloud–edge–end computing architectures for intelligent service in a high-speed train are proposed, in which the edge servers are either deployed along the railway lines or onboard the train. Existing virtualization technologies for deploying a (private) Real-Time (RT)-Cloud on standard server hardware are examined in [25], to run an existing railway use case while meeting stringent safety and security requirements.

Cloud management refers to the process of planning, designing, building, deploying, managing, and maintaining applications and infrastructure in a cloud computing environment. To ensure a high level of security and reliability, and to help rail operators to focus on running their mission-critical services, the railway cloud will use the Software as a Service (SaaS) model. In the SaaS model, cloud management refers to managing software applications, including licensing, updates, and support.

Application lifecycle management (ALM) refers to a set of processes and tools used to manage the entire software development lifecycle, from conceptualization to deployment. It aims to ensure that applications are developed efficiently, reliably, and with minimal defects [26,27,28,29,30]. ALM typically includes the following activities:

• Requirement gathering: Collecting and documenting application requirements from stakeholders.
• Design: Creating a detailed design of the application, including architecture, user interface, and technical specifications.
• Development: Building the application using various development methodologies (e.g., Agile, Waterfall).
• Testing: Verifying that the application works correctly and meets the required standards.
• Deployment: Releasing the application to production.
• Maintenance: Updating, fixing, and supporting the application after deployment.

Reference [31] presents the integration of application security testing tools into ALM systems, showing how it can assist with automation and traceability to help an organization implement a secure software development process. In [32], the authors propose a cost-efficient optimized orchestration system that addresses the whole lifecycle management of different service function chains; the system considers the quality of service and actual capacities of virtual network functions, which are potentially deployed across multiple cloud–edges. An approach to predicting the resource usage of a VNF (virtualized network function) is proposed in [33] with the aim to optimize its lifecycle management.

The analysis of the references shows a clear lack of open interfaces for the management of virtualized railway applications. The design of an architectural framework for the management and orchestration of virtualized railway functions may follow the principles of SBA. The related works deal with the methods and algorithms for virtualized application management with no stress on interfaces in the management and orchestration supported over a reference point between components in a holistic architectural framework. The interface functions may be realized as services that are used by management applications. RESTful APIs are lightweight, scalable, flexible, and independent. They rely on HTTP and are format-agnostic, which makes them flexible. The API design is technology-independent, as both client and server applications can be written in various programming languages, and a change in the underlying technology on either side will not affect the communication. REST APIs can also be scaled quickly, primarily due to the separation between the client and the server. Additionally, developers can also easily integrate REST APIs without much added work.

We propose a service-based approach to the management of virtualized FRMCS applications. The requirements of management and orchestration are identified through an analysis of basic use cases. RESTful APIs for the management of virtualized FRMCS applications are synthesized. To verify the developed API, models that reflect the view of the managing entity and managed entity for the status of a virtualized FRMCS application instance are developed. The concept of synchronization between the states, introduced in [21], is used to verify the designed RESTful API, to check the developed models against the desired behavior, and to verify the concurrent run of the models. Since latency is a key performance indicator for critical FRMCS communication applications, the latency injected by the proposed API is estimated through emulation.

3. Railway NFV Cloud Architecture

A key principle of the cloudified FRMCS is the decoupling of railway hardware and software for all components and the deployment of software components on general-purpose equipment. This decoupling simplifies the physical deployment and maintenance, and enables flexible installation and lifecycle management through cloudified railway function orchestration and automation.

The cloudified architecture for management and orchestration of a virtualized railway control system may follow the principles of ETSI’s reference virtualized architecture [34]. Figure 1 shows the proposed architectural framework for the management and orchestration of virtualized railway functions.

Railway Management Automation and Orchestration (RMAO) is responsible for the management of the whole virtualized railway control network. The key capabilities of RMAO that provide support of the railway control system are the FCAPS (Fault, Configuration, Accounting, Performance, and Security) interface to the railway functions and cloud management and orchestration. The support provided by RMAO through FCAPS to railway functions includes performance, configuration, fault, file, and software management; communication surveillance; trace; and physical railway function discovery. The functions of railway cloud management and orchestration include the discovery and administration of railway cloud resources; scale-in and scale-out for railway cloud; FCAPS of railway cloud; software management of the Railway Cloud Platform; the creation, deletion, deployment, and association of cloud resources; the scaling of allocated cloud resources; FCAPS of deployments and allocated cloud resources; and software management of deployments.

The Railway Cloud Platform (RCP) is responsible for the overall strategy, planning, and execution of an organization’s cloud environment. This includes managing cloud resources, ensuring security and compliance, optimizing costs, and automating processes. It bridges the gap between business requirements and technical implementation, enabling railways to leverage the benefits of cloud computing effectively.

The Railway Cloud Platform Manager (RCPM) is responsible for the overall strategy, planning, and execution of an organization’s cloud environment. This includes managing cloud resources, ensuring security and compliance, optimizing costs, and automating processes. Its purpose is to manage the lifecycle, configuration, information, performance, and fault of virtualized FRMCS applications (and other virtualized railway functions).

The Virtualized Infrastructure Manager (VIM) serves to manage the software images, virtualized resources, infrastructure resource faults, performance, and acceleration capabilities of virtualized FRMCS applications (and other virtualized railway functions).

4. Use Cases of FRMCS Application Package and Lifecycle Management

A cloudified FRMCS application is an FRMCS application that is deployable on the railway cloud via one or more deployments (i.e., on railway cloud resources that comprise all or part of a cloudified FRMCS application). The FRMCS application package contains an executable image (a docker image or other binary image used to configure an accelerator), an FRMCS application descriptor that defines the application requirements (cloud capabilities and capacity), and a manifest file listing the files in the package and a hash of their content.

The Railway Cloud Platform (RCP) must provide the following management functions for FRMCS application packages: onboarding, information query, deleting, enabling/disabling, and fetching an FRMCS application package or selected files contained in the package. In addition, the RCP must provide notifications about the onboarding of an FRMCS application package or about changes in the FRMCS application package states.

The required basic functionality for lifecycle management of the FRMCS application includes instantiating, operating, scaling-up and -down (including auto-scaling), software upgrades, healing (including auto-healing), and terminating an FRMCS application instance; changing the state of an FRMCS application instance; and provisioning of notifications regarding lifecycle management operations.

The interface between the RCO and RCPM also needs to provide functionalities for package and lifecycle management in FRMCS applications.

Figure 2 shows the flow of the FRMCS application instantiation, comprising the following steps:

• The railway cloud operator requests deployment of an FRMCS application, providing configuration data.
• The RCO checks the configuration data and authorizes the request.
• The RCO sends a request to the Railway Cloud Platform Manager to instantiate an FRMCS application.
• The RCPM requests the provision of resources or capabilities from the VIM by sending the required computing, storage, and networking resources. The RCMP includes information about the FRMCS application image.
• The VIM allocates the resources, and if an application image is available for the FRMCS, the VIM loads the virtualization container with this image and runs the FRMCS application instance.
• The VIM responds to the request for resource provisioning.
• The RCPM sends a configuration request to the RCP, including required and optional FRMCS services.
• The RCP provides the FRMCS service information to the FRMCS application instance.
• The RCP responds to the configuration request.
• The RCPM responds to the request for FRMCS application instantiation.
• The result of the FRMCS application deployment is returned to the railway cloud operator.

The instantiation is role-based rather than location-based, i.e., the initial instantiation might be initiated by the operator and when the performance indicators change, and the operator or RMAO can automatically expand the capacity by instantiating a new application instance.

Once instantiated, an FRMCS application instance may be started or stopped. To operate an FRMCS application instance, the railway cloud operator or the RMAO sends a start request or a stop request to the RCO. The RCO forwards the request to the RCPM, which, in turn, processes the request and returns the result upon completion of the operation. The RCO then sends a notification regarding the operation result.

Scaling out refers to the instantiation of additional resources for the deployment of a virtualized FRMCS application in order to expand its capacity. This results in horizontal elasticity and allows the FRMCS application to consume the resources it needs based on the network traffic.

Scaling in refers to the deletion of FRMCS application deployments to reduce the capacity in order to improve efficiency. This supports horizontal elasticity and allows the NF to consume only the resources it needs based on the level of demand.

The termination of an FRMCS application instance may be initiated by the railway cloud operator, which sends a request to the RCO that includes the ID of the FRMCS application to be terminated. The RCO authorizes the request, verifies whether the FRMCS application instance exists, and sends a request to the RCPM to terminate the application instance. The RCPM forwards the request to the RCP. To perform a graceful termination, the RCP notifies the FRMCS application of the termination event. The FRMCS application completes its task run before the termination, and informs the RCP. As an alternative, after expiry of an application termination timer, the RCP shuts down the FRMCS application and sends a response to the RCPM. The RCPM requests release of resources allocated to the FRMCS application from the VIM. After the release of resources, a response is sent to the RCPM, which in turn responds to the RCO with the result of the termination of the FRMCS application instance, and then the railway cloud operator is notified.

The execution of lifecycle management operations for an application instance (instantiate, operate, terminate) takes some time. The RCO may monitor the progress of the operation. For this, the RCO subscribes to notifications sent by the RCPM upon the occurrence of changes in the state of an FRMCS application instance lifecycle management operation. The invocation of an operation related to FRMCS application lifecycle management enables the RCPM to interfere in the execution of the operation, cancel it before its successful completion, retry explicitly canceled operations, or reject them due to persisting problems. The FRMCS application instance lifecycle management operation can be in one of the following states: launching (the operation is initiated), processing (the request for operation execution is accepted), finished (the operation is completed successfully), temporarily failed (the operation execution is stopped and the railway cloud retries to remove the problem by itself), and failed (there is a permanent problem in the operation execution). The intervention actions initiated by the RCO are cancel, retry, and reject.

5. FRMCS Application Management as a Service

The required functionalities for package management and instance lifecycle management in FRMCS applications (identified in the previous section) can be synthesized as RESTful services.

The FRMCSAppPackageMgnt service provides the required management functionality for FRMCS application packages. Figure 3 shows the structure of unified resource identifiers (URIs) of resources related to the management of FRMCS application packages. The resource URIs follow the root {apiRoot/frmcsAppPmgnt.v1}, where the service is registered. The FRMCS application packages can be identified in two ways: by an RCO-managed identifier (appRcID) assigned during package onboarding and by an identifier defined by the FRMCS application vendor during package creation (appVID). Thus, the identifiers are part of the metadata for a given application package. The vendor should issue another appVID for the next version of the same application package and the RCO should define a fresh appRcID for each onboarding. The FRMCS application packages with assigned appRcID have completed their onboarding process and are available for use by the RCPM.

Table 1. Overview of the service resources of FRMCSAppPackageMgnt.

Resource Name	Resource URI	HTTP Method	Description
FRMCS application packages	/frmcsAppPackages OR /onboarded.frmcsAppPackages	POST	Creates a new resource for onboarded FRMCS application packages.
		GET	Retrieves the list of onboarded FRMCS application packages.
Individual FRMCS application package	/frmcsAppPackages/{appVID} OR /onboarded.frmcsAppPackages /{appRcID}	GET	Retrieves information on an individual onboarded FRMCS application package.
		PATCH	Enables or disables an individual onboarded FRMCS application package.
		DELETE	Deletes an individual onboarded FRMCS application package.
FRMCS application descriptor	/frmcsAppPackages/{appVID} /appDescriptor OR /onboarded.frmcsAppPackages /{appRcID}/appDescriptor	GET	Retrieves the application descriptor of an onboarded FRMCS application package.
FRMCS application package content	/frmcsAppPackages/{appVID} /appContent OR /onboarded.frmcsAppPackages /{appRcID}/appContent	GET	Obtains an onboarded FRMCS application package.
		PUT	Uploads an FRMCS application package by providing its content.
Subscriptions	/subscriptions	POST	Creates a subscription to onboarding or changes in FRMCS application packages.
		GET	Retrieves the list of subscriptions.
Individual subscription	/subscriptions/{subscriptionID}	GET	Retrieves information about an individual subscription.
		DELETE	Terminates an individual subscription.

summarizes the FRMCSAppPackageMgnt service resources and the applicable HTTP methods.

The FRMCSAppInstLCM service provides the required functionality for FRMCS application instance lifecycle management. Figure 4 shows the structure of the URIs of resources related to the lifecycle management of an FRMCS application instance. The resource URIs follow the root {apiRoot/frmcsAppInstanceLCM.v1}, where the service is registered. The FRMCSAppInstLCM service resources represent FRMCS application instances, the operations invoked on them, and the intervention taken for each operation.

Figure 5 shows the flows of onboarding, disabling, and enabling an FRMCS application package by using the proposed API. Upon a request to onboard an FRMCS application package, the RCO checks the existence of all mandatory package elements, validates their authenticity and integrity, and checks the FRMCS application image format, rules, and requirements. The RCO allocates a unique AppRcID for the onboarded FRMCS application package, prepares the required virtualization infrastructure managers with the application image, and acknowledges the onboarding of the package. The purpose of disabling an FRMCS application package is so that it cannot be used for instantiation. The RMAO sends requests to disable an FRMCS application package to the RCO. The RCO processes the request, checking whether the FRMCS application package exists, marks the package as disabled, and acknowledges the request to disable the FRMCS application package. A disabled FRMCS application package can also be enabled in order to be used again.

Table 2. Overview of the service resources of FRMCSAppInstLCM.

Resource Name	Resource URI	HTTP Method	Description
FRMCS application instances	/frmcsAppInstances	POST	Creates a new resource for an FRMCS application instance.
		GET	Retrieves the list of FRMCS application instances.
Individual FRMCS application instance	/frmcsAppInstances /{frmcsAppInstanceID}	GET	Retrieves information on an FRMCS application instance.
		DELETE	Deletes an individual FRMCS application instance.
Exemplify FRMCS application instance action	/frmcsAppInstances /{frmcsAppInstanceID} /instantiate	POST	Creates the FRMCS application instance.
Terminate FRMCS application instance action	/frmcsAppInstances /{frmcsAppInstanceID}/terminate	POST	Terminates the FRMCS application instance.
Operate FRMCS application instance action	/frmcsAppInstances /{frmcsAppInstanceID}/operate	POST	Operates the FRMCS application instance.
Controls applied on application instance operation	/frmcsAppInstOpCtrls	GET	Obtains the applied controls on operations.
Individual control applied on FRMCS application instance operation	/frmcsAppInstOpCtrls /{frmcsAppInstOpCtrlID}	GET	Retrieves the operation state.
Cancel FRMCS application instance operation	/frmcsAppInstOpCtrls /{frmcsAppInstOpCtrlID}/cancel	POST	Cancels the ongoing operation.
Retry FRMCS application instance operation	/frmcsAppInstOpCtrls /{frmcsAppInstOpCtrlID}/retry	POST	Retries the ongoing operation.
Reject FRMCS application instance operation	/frmcsAppInstOpCtrls /{frmcsAppInstOpCtrlID}/reject	POST	Rejects the ongoing operation.
Subscriptions	/subscriptions	POST	Creates a subscription to notifications related to FRMCS application’s lifecycle changes.
		GET	Retrieves the list of subscriptions.
Individual subscription	/subscriptions/{subscriptionID}	GET	Retrieves information about an individual subscription.
		DELETE	Terminates the subscription.

summarizes the resources and supported methods related to the lifecycle management of FRMCS application instances.

Figure 6 shows the flow of the FRMCS application instantiation using the proposed API.

First, a resource representing an FRMCS application instance is created. Next, an “instantiate” operation is created on the FRMCS application instance. The RCO subscribes to notifications regarding changes in the FRMCS application instance lifecycle. The RCPM notifies the RCO when the operation is launched, processing, and completed.

Further elaboration of the proposed approach will be related to the development of the information models, which provide more details about the concepts and relationships in the domain under consideration.

6. Approach Formal Verification

To verify the proposed service-based approach to the lifecycle management of the FRMCS application instances, models of its status are developed. The models represent the view of the RCO and the view of the RCPM. Both models run in parallel and therefore their views on the state of an FRMCS application instance have to be synchronized.

Figure 7 shows the simplified model of a state machine, representing the RCO’s view on the FRMCS application instance’s lifecycle state.

In the following model description, the term “state” represents a specific condition or mode of operation, “event” is used for an occurrence that triggers a change in state, “transition” is a movement from one state to another, triggered by an event, and “action” is a specific operation performed when a transition occurs [35,36].

In the NonInstantiated state (denoted by s^o₁ for brevity), the application instance is not instantiated. When a request is received (instantiate event) from the railway cloud operator to instantiate an FRMCS application, the request is forwarded to the FRMCSAppInstLCM service (or just service) (instantiateReq action).

In the Instantiating state (abbreviated as s^o₂), the application in the RCO is waiting for the result of the FRMCS application instantiation operation. The railway cloud operator may subscribe to notifications about the result of FRMCS application instantiation (subscribe event) and the managing application in the RCO (or just application) subscribes with the service to receive notifications about the result of the initiating operation (subscribeReq action). The railway cloud operator may cancel the initiation operation (cancel event) and the application requests from the service to cancel the instantiation (cancelReq action). The instantiation may be successful (instantiateRes(success) event) or may fail (instantiateRes(failed) event). The railway operator is notified about the result of the operation.

In the Failed.Instantiation state (abbreviated as s^o₃), the FRMCS application instantiation is failed. The railway cloud operator may repeat the instantiation request (retry event) and the application requests from the service to retry the operation (retryReq action).

In the Instatiated.Stopped state (abbreviated as s^o₄), the FRMCS application is instantiated but not started. The railway cloud operator may start the FRMCS application (start event) and the application sends a startReq request to the service. The railway cloud operator may terminate the FRMCS application instance (terminate event) and the application sends a terminateReq request to the service.

In the Starting state (abbreviated as s^o₅), the FRMCS application instance is starting. The railway cloud operator may cancel the startup operation (cancel event), and thus, the application sends a request to the service to cancel the startup of the FRMCS application instance. The starting of the FRMCS application may be successful (startRes(success) event) or fail (startRes(failed) event).

In the Failed.Start state (abbreviated as s^o₆), the startup of the FRMCS application has failed. The railway cloud operator may repeat the start request, and the application thus sends a request to the service to retry the operation or may cancel the starting operation.

In the Instatiated.Started state (abbreviated as s^o₇), the FRMCS application has been instantiated and started. The railway cloud operator may stop the FRMCS application (stop event), and the application sends a stopReq request to the service. The railway cloud operator may terminate the FRMCS application instance, for which the application sends a terminateReq request to the service.

In the Stopping state (abbreviated as s^o₈), the FRMCS application instance is stopping. The railway cloud operator may cancel the stop operation. The FRMCS application may be stopped (stopRes(success event) or the stopping of the FRMCS application may fail (stopRes(failed) event).

In the Failed.Stop state (abbreviated as s^o₉), the FRMCS application stopping has failed. The railway cloud operator may repeat the stop request or cancel the stop operation.

In the Terminating (abbreviated as s^o₁₀) state, the FRMCS application instance is terminating. The railway cloud operator may cancel the stop operation, the FRMCS application may be terminated, or the termination may fail.

In the Failed.Termination state (abbreviated as s^o₁₁), the FRMCS application termination has failed. The railway cloud operator may repeat the termination request or cancel the operation.

Figure 8 shows the simplified model of a state machine, representing the RCPM’s view on the FRMCS application instance’s lifecycle state. The state transitions in both models are triggered by HTTP methods, supported by the respective resources of the FRMCSAppInstLCM service.

In the Null state (abbreviated as s^m₁), the FRMCS application is not instantiated. In the RequestProcessing state (abbreviated as s^m₂), the requests from the application to instantiate an FRMCS application are authorized. In the ResourceAllocation&Configuration state (abbreviated as s^m₃), the instantiation request is authorized, the required resources are allocated, and the FRMCS application instance is configured. In the AppInst.Stopped state (abbreviated as s^m₄), the FRMCS application instance is created and configured, but not started. In the AppInst.Starting state (abbreviated as s^m₅), the FRMCS application instance is starting. In the AppInst.Started state (abbreviated as s^m₆), the FRMCS application instance is started. In the AppInst.Stopping state (abbreviated as s^m₇), the FRMCS application instance is stopping. In the AppInst.Terminating state (abbreviated as s^m₈), the FRMCS application instance is terminating.

To prove that both models are synchronized in time, they are formally described as LTSs. An LTS is a quadruple of a set of states, a set of events, a set of transitions, and an initial state. To provide a more concise description of the transitions and to make the following proposition and its proof more readable, short notations in brackets are used for the names of the events that are used.

Definition 1.

L^rco = (S^rco, Σ ^rco, →^rco, s^rco₀) denotes an LTS representing the FRMCS application instance’s lifecycle model, supported by the managing application in RCO, where

• S^rco = { s^o₁, s^o₂, s^o₃, s^o₄, s^o₅, s^o₆, [s^o₇, s^o₈, s^o₉, s^o₁₀, s^o₁₁} is the set of states;
• Σ ^rco = {instantiate [a₁], subscribe [a₂], subscribeRes [a₃], notify(processing) [a₄], cancel [a₅], cancelRes [a₆], retry [a₇], retryRes [a₈], instantiateRes(success) [a₉], instantiateRes(failed) [a₁₀], reject [a₁₁], start [a₁₂], startRes(failed) [a₁₃], startRes(success) [a₁₄], stop [a₁₅], stopRes(failed) [a₁₆], stopRes(success) [a₁₇], terminated [a₁₈], terminateRes(fail.started) [a₁₉], terminateRes(fail.stopped) [a₂₀], terminateRes(success) [a₂₁], unsubscribe [a₂₂], unsubscribeRes [a₂₃], reject(stopped) [a₂₄], reject(started) [a₂₅], rejectRes [a₂₆]} is the set of events;
• →^rco = {(s^o₁$\stackrel{a1}{\to }$s^o₂), (s^o₂$\stackrel{a2}{\to }$s^o₂), (s^o₂$\stackrel{a3}{\to }$s^o₂), (s^o₂$\stackrel{a4}{\to }$s^o₂), (s^o₂$\stackrel{a5}{\to }$s^o₃), (s^o₃$\stackrel{a6}{\to }$s^o₃), (s^o₃$\stackrel{a7}{\to }$s^o₂), (s^o₂$\stackrel{a8}{\to }$s^o₂), (s^o₂$\stackrel{a9}{\to }$s^o₄), (s^o₂$\stackrel{a10}{\to }$s^o₁), (s^o₂$\stackrel{a11}{\to }$s^o₁), (s^o₁$\stackrel{a26}{\to }$s^o₁), (s^o₄$\stackrel{a12}{\to }$s^o₅), (s^o₅$\stackrel{a4}{\to }$s^o₅), (s^o₅$\stackrel{a8}{\to }$s^o₅), (s^o₅$\stackrel{a5}{\to }$s^o₆), (s^o₆$\stackrel{a6}{\to }$s^o₆), (s^o₆$\stackrel{a7}{\to }$s^o₅), (s^o₅$\stackrel{a11}{\to }$s^o₄), (s^o₅$\stackrel{a13}{\to }$s^o₄), (s^o₅$\stackrel{a14}{\to }$s^o₇), (s^o₇$\stackrel{a15}{\to }$s^o₈), (s^o₈$\stackrel{a4}{\to }$s^o₈), (s^o₈$\stackrel{a8}{\to }$s^o₈), (s^o₈$\stackrel{a5}{\to }$s^o₉), (s^o₉$\stackrel{a6}{\to }$s^o₉), (s^o₉$\stackrel{a7}{\to }$s^o₈), (s^o₈$\stackrel{a11}{\to }$s^o₇), (s^o₈$\stackrel{a16}{\to }$s^o₇), (s^o₈$\stackrel{a17}{\to }$s^o₄), (s^o₄$\stackrel{a18}{\to }$s^o₁₀), (s^o₇$\stackrel{a18}{\to }$s^o₁₀), (s^o₁₀$\stackrel{a4}{\to }$s^o₁₀), (s^o₁₀$\stackrel{a8}{\to }$s^o₁₀), (s^o₁₀$\stackrel{a5}{\to }$s^o₁₁), (s^o₁₁$\stackrel{a6}{\to }$s^o₁₁), (s^o₁₁$\stackrel{a7}{\to }$s^o₁₀), (s^o₁₀$\stackrel{a8}{\to }$s^o₁₀), (s^o₁₀$\stackrel{a19}{\to }$s^o₄), (s^o₁₀$\stackrel{a20}{\to }$s^o₇), (s^o₁₀$\stackrel{a21}{\to }$s^o₁), (s^o₁$\stackrel{a22}{\to }$s^o₁), (s^o₁$\stackrel{a23}{\to }$s^o₁), (s^o₁₀$\stackrel{a24}{\to }$s^o₄), (s^o₁₀$\stackrel{a25}{\to }$s^o₇), (s^o₄$\stackrel{a26}{\to }$s^o₄), (s^o₇$\stackrel{a26}{\to }$s^o₇) } is the set of transitions;
• s^rco₀ = [s^o₁] is the initial state.

Definition 2.

L^rcpm = (S^rcpm, Σ ^rcpm, →^rcpm, s^rcpm₀) denotes an LTS representing the FRMCS application instance’s lifecycle model, supported by the cloud management service in RCPM, where

• S^rcpm = { s^m₁, s^m₂, s^m₃, s^m₄, s^m₅, s^m₆, s^m₇, s^m₈} is the set of states;
• Σ ^rcpm = {instantiateReq [t₁], unauthorizedRequest [t₂], authorizedRequest [t₃], subscriptionReq [t₄], cancelReq [t₅], cancelApp.Res [t₆], retryReq [t₇], rejectReq [t₈], rejectAppRes [t₉], instantiateAppRes(failed) [t₁₀], unsubscribeReq [t₁₁], instantiateAppRes(success) [t₁₂], startReq [t₁₃], startAppRes(failed) [t₁₄], startAppRes(success) [t₁₅], stopReq [t₁₆], stopAppRes [t₁₇], stopAppRes(success) [t₁₈], terminateReq [t₁₉], terminateAppRes(success) [t₂₀], rejectAppRes(started) [t₂₁], terminateAppRes(fail,started) [t₂₂], rejectAppRes(stopped) [t₂₃], terminateAppRes(fail,stopped) [t₂₄]} is the set of events;
• →^rcpm = { (s^m₁$\stackrel{t1}{\to }$s^m₂), (s^m₂$\stackrel{t2}{\to }$s^m₁), (s^m₂$\stackrel{t3}{\to }$s^m₃), (s^m₃$\stackrel{t4}{\to }$s^m₃), (s^m₃$\stackrel{t5}{\to }$s^m₃), (s^m₃$\stackrel{t6}{\to }$s^m₃), (s^m₃$\stackrel{t7}{\to }$s^m₃), (s^m₃$\stackrel{t8}{\to }$s^m₃), (s^m₃$\stackrel{t9}{\to }$s^m₁), (s^m₃$\stackrel{t10}{\to }$s^m₁), (s^m₁$\stackrel{t11}{\to }$s^m₁), (s^m₃$\stackrel{t12}{\to }$s^m₄), (s^m₃$\stackrel{t13}{\to }$s^m₅), (s^m₅$\stackrel{t5}{\to }$s^m₅), (s^m₅$\stackrel{t6}{\to }$s^m₅), (s^m₅$\stackrel{t7}{\to }$s^m₅), (s^m₅$\stackrel{t8}{\to }$s^m₅), (s^m₅$\stackrel{t9}{\to }$s^m₄), (s^m₅$\stackrel{t14}{\to }$s^m₄), (s^m₅$\stackrel{t15}{\to }$s^m₆), (s^m₆$\stackrel{t16}{\to }$s^m₇), (s^m₇$\stackrel{t5}{\to }$s^m₇), (s^m₇$\stackrel{t6}{\to }$s^m₇), (s^m₇$\stackrel{t7}{\to }$s^m₇), (s^m₇$\stackrel{t8}{\to }$s^m₇), (s^m₇$\stackrel{t9}{\to }$s^m₆), (s^m₇$\stackrel{t17}{\to }$s^m₆), (s^m₇$\stackrel{t18}{\to }$s^m₄), (s^m₄$\stackrel{t19}{\to }$s^m₈), (s^m₆$\stackrel{t19}{\to }$s^m₈), (s^m₈$\stackrel{t5}{\to }$s^m₈), (s^m₈$\stackrel{t6}{\to }$s^m₈), (s^m₈$\stackrel{t7}{\to }$s^m₈), (s^m₈$\stackrel{t8}{\to }$s^m₈), (s^m₈$\stackrel{t21}{\to }$s^m₆), (s^m₈$\stackrel{t22}{\to }$s^m₆), (s^m₈$\stackrel{t23}{\to }$s^m₄), (s^m₈$\stackrel{t24}{\to }$s^m₄), (s^m₈$\stackrel{t20}{\to }$s^m₁)} is the set of transitions;
• s^rcpm₀ = [s^m₁] is the initial state.
• To prove that the models representing the FRMCS application instance’s status are synchronized in time, the concept of synchronization in the states of two LTSs is used. The formal mathematical definition of this concept may be found in [33]. The idea is to identify such tuples of states where (1) one state in a tuple belongs to one LTS and the other state belongs to the other LTS, and (2) a bijection function exists between the transitions starting in a state in a tuple and terminating in a state in a tuple.

Proposition 1.

Let R represent a set of tuples of states in L^rco and L^rcpm (i.e., R ⊆ S^rco × S^rcpm), where R = {(s^o₁, s^m₁), (s^o₄, s^m₄), (s^o₇, s^m₆)}. R is the synchronization between the states in L^rco and L^rcpm.

Proof 1.

We identify a bijection function of transition between the states in tuples of R, which is shown in

Table 3. Bijective function of transition sequences in models representing the FRMCS application instance’s status.

Transition Abstraction	State Tuples of Initial States and Terminating States	Transition Sequences in Lrco	Transition Sequences in Lrpcm
The instantiation of a new FRMCS application instance fails	(so1, sm1), (so1, sm1)	so1$\stackrel{a1}{\to }$so2$\stackrel{a10}{\to }$so1	sm1$\stackrel{t1}{\to }$sm2$\stackrel{t2}{\to }$sm1 or (sm1$\stackrel{t1}{\to }$sm2$\stackrel{t3}{\to }$sm3$\stackrel{t10}{\to }$sm1
The FRMCS application instance is instantiated, but not started.	(so1, sm1), (so4, sm4)	so1$\stackrel{a1}{\to }$so2$\stackrel{a2}{\to }$so2$\stackrel{a3}{\to }$so2$\stackrel{a4}{\to }$so2$\stackrel{a9}{\to }$so4	sm1$\stackrel{t1}{\to }$sm2$\stackrel{t3}{\to }$sm3$\stackrel{t4}{\to }$sm3$\stackrel{t12}{\to }$sm4
The instantiation of a new FRMCS application instance is canceled, and the operation is rejected after a predefined number of retries.	(so1, sm1), (so1, sm1)	so1$\stackrel{a1}{\to }$so2$\stackrel{a2}{\to }$so2$\stackrel{a3}{\to }$so2 $\stackrel{a4}{\to }$so2$\stackrel{a5}{\to }$so3$\stackrel{a6}{\to }$so3$\stackrel{a7}{\to }$so2$\stackrel{a8}{\to }$so2$\stackrel{a10}{\to }$so1	sm1$\stackrel{t1}{\to }$sm2$\stackrel{t3}{\to }$sm3$\stackrel{t4}{\to }$sm3$\stackrel{t5}{\to }$sm3$\stackrel{t6}{\to }$sm3$\stackrel{t7}{\to }$sm3$\stackrel{t8}{\to }$sm3$\stackrel{t9}{\to }$sm1
The FRMCS application instance is started.	(so4, sm4), (so7, sm6)	so4$\stackrel{a12}{\to }$so5$\stackrel{a4}{\to }$so5$\stackrel{a14}{\to }$so7	sm4$\stackrel{t13}{\to }$sm5$\stackrel{t15}{\to }$sm6
The starting of the FRMCS application instance fails.	(so4, sm4), (so4, sm4)	so4$\stackrel{a12}{\to }$so5$\stackrel{a13}{\to }$so4	sm4$\stackrel{t13}{\to }$sm5$\stackrel{t14}{\to }$sm4
The starting of the FRMCS application instance is canceled, and the operation is rejected after a predefined number of retries.	(so4, sm4), (so4, sm4)	so4$\stackrel{a12}{\to }$so5$\stackrel{a5}{\to }$so6$\stackrel{a6}{\to }$so6$\stackrel{a7}{\to }$so5$\stackrel{a11}{\to }$so4	sm4$\stackrel{t13}{\to }$sm5$\stackrel{t5}{\to }$sm5$\stackrel{t6}{\to }$sm5$\stackrel{t7}{\to }$sm5$\stackrel{t8}{\to }$sm5$\stackrel{t9}{\to }$sm4
The started FRMCS application instance is stopped successfully.	(so7, sm6), (so4, sm4)	so7$\stackrel{a15}{\to }$so8$\stackrel{a4}{\to }$so8$\stackrel{a17}{\to }$so4	sm6$\stackrel{t16}{\to }$sm7$\stackrel{t18}{\to }$sm4
The stopping of the started FRMCS application fails.	(so7, sm6), (so7, sm6)	so7$\stackrel{a15}{\to }$so8$\stackrel{a4}{\to }$so8$\stackrel{a16}{\to }$so7	sm6$\stackrel{t16}{\to }$sm7$\stackrel{t17}{\to }$sm6
The stopping of the FRMCS application instance is canceled, and the operation is rejected after a predefined number of retries.	(so7, sm6), (so7, sm6)	so7$\stackrel{a15}{\to }$so8$\stackrel{a4}{\to }$so8$\stackrel{a5}{\to }$so9$\stackrel{a6}{\to }$so9$\stackrel{a7}{\to }$so8$\stackrel{a11}{\to }$so7	sm6$\stackrel{t16}{\to }$sm7$\stackrel{t5}{\to }$sm7$\stackrel{t6}{\to }$sm7$\stackrel{t7}{\to }$sm7$\stackrel{t8}{\to }$sm7$\stackrel{t9}{\to }$sm6
The started or stopped FRMCS application instance is terminated successfully.	(so7, sm6), (so1, sm1)	so7$\stackrel{a18}{\to }$so10$\stackrel{a4}{\to }$so10$\stackrel{a21}{\to }$so1$\stackrel{a22}{\to }$so1$\stackrel{a23}{\to }$so1 or so4$\stackrel{a18}{\to }$so10$\stackrel{a4}{\to }$so10$\stackrel{a21}{\to }$so1$\stackrel{a22}{\to }$so1$\stackrel{a23}{\to }$so1	sm6$\stackrel{t19}{\to }$sm8$\stackrel{t20}{\to }$sm1$\stackrel{t11}{\to }$sm1 or sm4$\stackrel{t19}{\to }$sm8$\stackrel{t20}{\to }$sm1$\stackrel{t11}{\to }$sm1.
The termination of the started or stopped FRMCS application fails.	(so7, sm6), (so7, sm6) or (so4, sm4) (so4, sm4)	so7$\stackrel{a18}{\to }$so10$\stackrel{a4}{\to }$so10$\stackrel{a20}{\to }$so7 or so4$\stackrel{a18}{\to }$so10$\stackrel{a4}{\to }$so10$\stackrel{a19}{\to }$so4	sm6$\stackrel{t19}{\to }$sm8$\stackrel{t22}{\to }$sm6 or sm4$\stackrel{t19}{\to }$sm8$\stackrel{t23}{\to }$sm4
The termination of the started or stopped FRMCS application instance is canceled, and the operation is rejected after a predefined number of retries.	(so7, sm6), (so7, sm6) or (so4, sm4), (so4, sm4)	so7$\stackrel{a18}{\to }$so10$\stackrel{a4}{\to }$so10$\stackrel{a5}{\to }$so11$\stackrel{a6}{\to }$so11$\stackrel{a7}{\to }$so10$\stackrel{a8}{\to }$so10$\stackrel{a25}{\to }$so7$\stackrel{a26}{\to }$so7 or so4$\stackrel{a18}{\to }$so10$\stackrel{a4}{\to }$so10$\stackrel{a5}{\to }$so11$\stackrel{a6}{\to }$so11$\stackrel{a7}{\to }$so10$\stackrel{a8}{\to }$so10$\stackrel{a24}{\to }$so4$\stackrel{a26}{\to }$so4	sm6$\stackrel{t19}{\to }$sm8$\stackrel{t5}{\to }$sm8$\stackrel{t6}{\to }$sm8$\stackrel{t7}{\to }$sm8$\stackrel{t8}{\to }$sm8$\stackrel{t21}{\to }$sm6 or sm4$\stackrel{t19}{\to }$sm8$\stackrel{t5}{\to }$sm8$\stackrel{t6}{\to }$sm8$\stackrel{t7}{\to }$sm8$\stackrel{t8}{\to }$sm8$\stackrel{t23}{\to }$sm4

. In Table 3, the first column describes the abstract meaning of the transition, and the second column indicates the tuple of initial states for the transition and the tuple of terminating states for the transition. The third and fourth columns show the transitions in L^rco and L^rcpm, respectively.

Therefore, R is synchronized between states. □

This means that L^rco and L^rcpm have synchronized-in-time views on the FRMCS application instance’s status.

7. API Emulation

Latency is a key performance indicator for critical FRMCS applications. An experiment was conducted to assess the latency injected by the proposed APIs. The experiment was conducted in a laboratory environment due to the lack of real cloud infrastructure for rail transport.

The communication between FRMCS management applications in the RCO and the designed services in the RCPM is simulated. As the RESTful APIs are HTTP-based, the experimental setup includes components demonstrating the functionality of both the server and the client. The RESTful load consists of POST requests with the domain-specific data in JSON format generated by a Java-based HTTP multi-threaded client. The server component consists of two docker instances: one instance enables the REST endpoint and the Cassandra client, and the other enables the Cassandra server, providing a lightweight virtualized storage service. Containers are deployed onto two nodes with eight cores, and each node is 32 GB in size. The nodes are connected via 1 Gb Ethernet, and the serving-side containers are bridged, though IPv6 link local addressing is used to separate them from the adjacent traffic as much as possible. The deployment of the containers is on Kubernetes, where the parametrization (CPU/RAM/storage/networking) is set in YAML.

Figure 9 shows the raw sequence of latency values for the fifth group of 1000 traffic messages out of a total of 20,000 over the RESTful endpoint.

In Figure 10, the Probability Mass Function (PMF) is shown for the distribution of 20,000 latency values.

The main part is below 2 ms; however, 0.5% of all requests demonstrate latency over 10 ms, which is an indication for an open issue.

It is possible that there would be an eventual increase in the average latency value, possibly because of changes to topology in further implementations, e.g., load balancing, which we believe will require attention in the future.

8. Discussions

The virtualization of FRMCS applications has several advantages, such as cost efficiency because they can be run on a single physical server or cloud; scalability because they can easily adapt to traffic demands; flexibility and agility related to fast delivery and development; more efficient resource utilization by optimizing the dynamic allocation; and service innovation due to their programmability.

The industrial stability of virtualized railway control networks may be improved significantly. Virtualization can enhance disaster recovery and resilience in communication networks. By virtualizing network functions, NFV allows for dynamic resource allocation and rapid deployment of services, enabling faster recovery from disruptions caused by disasters. This includes the ability to migrate virtualized FRMSC applications to alternative locations, ensuring critical services are restored quickly.

To cope with the growing complexity and simplify network operations, more generic management solutions must be developed. These can help service providers to cover a broader spectrum of use cases, both at the network deployment level and at the operations level, with a common generic management toolset. At both levels, NFV technologies bring major opportunities, not only in offering a framework for deploying networks on a more unified physical and virtual infrastructure, but also in providing a generic management and resource service platform. Moreover, simplification enhances the efficiency and agility of network operations, and affects both to the network itself and the services offered over the network. This improves customer satisfaction and the perception of telecom operators. In particular, the introduction of declarative intent-based operations can play a key role in simplifying virtualized railway communication operations. The declarative intent-driven operation only needs the API to be consumed by and exposed to managed objects’ desired state to be maintained. This shifts more responsibility to the API producer management function to fulfill the desired state, and it also demands additional orchestration capabilities to be supported by it. This more declarative manner of operation has been successful in diverse management and orchestration systems.

Virtualization can benefit the integration of legacy systems by providing a cost-effective and efficient way to maintain and modernize outdated applications. By creating virtual environments that mimic the original hardware and software requirements, virtualization allows legacy systems to run on newer hardware without requiring expensive and time-consuming migrations to new systems. This extends the lifespan of legacy systems, enabling continued use of critical applications while minimizing the risks associated with obsolete hardware and software. By avoiding complete system overhauls, virtualization also significantly reduces the costs associated with hardware upgrades and software migrations. It enables the integration of legacy systems with newer technologies, allowing businesses to leverage modern functionalities without completely replacing their legacy infrastructure. It also creates isolated environments that protect legacy applications from conflicts with newer technologies and operating systems.

While virtualization offers many advantages, it is not without its challenges. One of the prime concerns is performance. Critical FRMCS communication applications have strong latency requirements and high throughput, especially in emergency situations. While virtualization simplifies the provision of FRMCS applications, it also introduces complexity in management because supervising virtualized platforms and providing solutions to technical issues, such as interoperability between various components, constitute difficult tasks. In addition, virtualization brings some security risks, such as bugs in the hypervisor and the virtualization management system. Virtualized FRMCS applications would only be efficient with solid security measures, and the development of best practices can assure this. Interoperability issues exist in multi-tenancy and multi-site orchestration, hybrid private–public cloud infrastructure, etc., as it is difficult to ensure that components from different manufacturers do not conflict. There also exist challenges in the implementation of virtualization for FRMCS applications related to the compatibility of legacy infrastructure regarding service assurance and quality of experience.

A synergy of virtualization and edge computing could contribute to mitigating problems with performance and reliability in the FRMCS. Harmonizing endeavors that strive to develop tools such as common interfaces and protocols can go a long way toward boosting interoperability and the integration of virtualized FRMCS applications. Strong security systems, including encryption, access controls, and threat detection, are vital and should be employed in virtualization environments in order to rescue them from cyber-attacks.

9. Conclusions

Network Function Virtualization is one of the enabling technologies for the digitalization of railway transportation. The virtualization of FRMCS applications facilitates the seamless integration of advanced technologies such as IoT and AI. The proposed approach to the management of virtualized FRMCS applications provides a programmable and customizable framework for the deployment and orchestration of innovative railway applications. It enables railway operators to dynamically deploy, scale, and change mission-critical railway functions for automatic train control and train protection, the monitoring and control of critical infrastructure, trackside maintenance, etc. The centralized management and orchestration of FRMCS applications provides assurance and reliability by enabling automated fault detection, self-healing, and performance optimization. By embracing NFV, the railway industry can unlock new opportunities for innovations, efficiency, and sustainability.

Virtualization facilitates the creation of hybrid environments where legacy and modern systems coexist and interact, allowing for a phased approach to modernization.