Operating system and signal system cloud platform

Abstract

The embodiment of the invention provides an operating system and a signal system cloud platform, and the operating system comprises an abstraction layer which is used for packaging the architecture-level drive of a computing node, architecture-level virtualization and the core of a CPU, and providing a packaging interface irrelevant to a hardware system for other layers; the microkernel layer is used for constructing various components of the microkernel by using the interface provided by the abstraction layer; and the application layer comprises a plurality of virtual machines running on a micro kernel, the virtual machines comprise real-time virtual machines and non-real-time virtual machines, and each real-time virtual machine is configured with resources isolated from other virtual machines. According to the technical scheme of the embodiment of the invention, the computing node hardware is abstracted, and the microkernel constructed based on the abstraction supports real-time and non-real-time virtual machines, so that applications with different security levels run in parallel on the same physical computer, and the utilization efficiency of hardware resources is improved.

Description

Technical Field

[0001] The present application relates to the field of operating system technology, and in particular to an operating system and a signal system cloud platform. Background Art

[0002] The signal system deploys control devices at the control site and only manages the control devices at the remote end. The signal system has poor integration, complex on-site deployment, high implementation costs and cannot support control at different security levels.

[0003] When integrating the control functions of signal systems in the cloud, existing operating systems are all heavyweight solutions. The kernel directly includes kernel components based on each hardware system, including virtualization solutions and methods for each hardware system. Not only is the operating system cumbersome, it is also unable to flexibly support applications with different security levels. Summary of the invention

[0004] In view of this, an embodiment of the present application provides an operating system and a cloud platform. The operating system of the embodiment of the present application abstracts the computing node hardware, and the microkernel built based on the abstraction supports real-time and non-real-time virtual machines at different security levels. It can not only run as a lightweight solution on computing nodes of various hardware systems, but also enable multiple applications at different security levels to run in parallel on the same physical computer, thereby improving the utilization efficiency of hardware resources and meeting the system information security and functional safety integration requirements of smart devices in the fields of smart cars, rail transit, etc. for multiple operating systems.

[0005] In the first aspect, an embodiment of the present application provides an operating system, including: an abstraction layer, which is used to encapsulate the computing node architecture-level driver, architecture-level virtualization and CPU core, and provide a packaging interface independent of the hardware system to other layers, the architecture-level driver includes at least one of the following: IOMMU driver, MMU driver, interrupt controller driver, and the architecture-level virtualization includes one of the following: clock virtualization and interrupt controller virtualization; a microkernel layer, which is used to use the packaging interface provided by the abstraction layer to build various components and simulation devices of the microkernel, and the components are at least used to implement vCPU management, memory management, scheduling management, and virtual machine management; an application layer, including various virtual machines running on the microkernel layer, the virtual machines including real-time virtual machines and non-real-time virtual machines, and each real-time virtual machine is isolated from other virtual machines through the microkernel configuration of resources.

[0006] As mentioned above, the above operating system abstracts the computing node hardware, and the microkernel built based on this abstraction supports real-time and non-real-time virtual machines with different security levels. It can not only run as a lightweight solution on computing nodes of various hardware systems, but also enable multiple applications with different security levels to run in parallel on the same physical computer, thereby improving the utilization efficiency of hardware resources and meeting the system information security and functional safety integration requirements of smart devices in the fields of smart cars, rail transit, etc. for multiple operating systems.

[0007] In a possible implementation of the first aspect, during scheduling management, the microkernel layer is used to set the physical CPU scheduled to the real-time virtual machine as a real-time physical CPU, and the real-time physical CPU turns off timer interrupts and preemption timers.

[0008] From the above, by setting the real-time physical CPU and turning off its timer interrupt and preemption timer, the real-time virtual machine on it will not be interrupted by other non-real-time tasks and interrupts, and it is also ensured that the real-time virtual machine can run without interference, thereby meeting the real-time requirements.

[0009] In a possible implementation of the first aspect, the tasks of the real-time virtual machine include real-time tasks and non-real-time tasks. Each virtual machine is provided with a task scheduler for scheduling the vCPU scheduled to the real-time task as a real-time vCPU, and the real-time vCPU turns off timer interrupts and preemption timers.

[0010] As described above, by setting the real-time physical vCPU and disabling its timer interrupt and preemption timer, the real-time task on it will not be interrupted by other non-real-time tasks and interrupts, and it is also ensured that the real-time task can run without interference, thereby meeting the real-time requirements.

[0011] In a possible implementation of the first aspect, the microkernel layer is used to map the vCPU of each virtual machine to the physical CPU during vCPU management, the vCPU of each real-time virtual machine is bound to a dedicated physical CPU, and the vCPUs of two or more virtual machines share one physical CPU.

[0012] As described above, the vCPU of each real-time virtual machine is bound to a dedicated physical CPU, and the security / real-time virtual machine core isolation mechanism is used to ensure that the vCPU operating status of the virtual machine should not be tampered with by other virtual machines; by sharing a physical CPU with the vCPUs of two or more virtual machines, flexible computing resource sharing is provided for vCPU tasks with low real-time and low performance requirements.

[0013] In a possible implementation of the first aspect, the simulation device includes an Ivshmem device, and each virtual machine communicates with each other through the Ivshmem device. The microkernel layer is used to configure the Ivshmem device as a virtual standard PCI device and configure it with memory shared by each virtual machine.

[0014] From the above, by designing the Ivshmem device as a virtual standard PCI device and exposing the shared memory address and size of this PCI device to each virtual machine, the application in the virtual machine can access this standard PCI device driver, and then access and operate the shared memory area provided by the virtual PCI device to support high-speed communication between virtual machines.

[0015] In a possible implementation of the first aspect, the microkernel layer is used to configure the clock space for the pass-through device of each virtual machine through the encapsulation interface related to clock virtualization provided by the abstract layer when starting each virtual machine, and sets each virtual machine to be unable to access the clock space of the virtual machine, and the clock space of each virtual machine is different; when each virtual machine accesses the clock space of its pass-through device, it falls into the microkernel layer, and the microkernel layer is also used to access the space corresponding to the clock address on behalf of the virtual machine, and feedback the access result to the virtual machine.

[0016] From the above, the virtual machine controls the opening and closing of the clock of its direct physical device according to demand, avoiding the default opening of the clock required for all virtual machines when the microkernel is started and initialized, reducing the clock power consumption of the physical direct device, and can obtain clock information of any space size in time, without being limited by the space management granularity of the MMU, reducing the memory space occupied by the clock space.

[0017] In a possible implementation of the first aspect, when the microkernel layer is started, it is used to modify the interrupt routing through the encapsulation interface related to interrupt controller virtualization provided by the abstract layer, so that the interrupt allocated to each virtual machine is directly routed to the virtual machine when it is generated.

[0018] From the above, by modifying the interrupt routing, the interrupt allocated to each virtual machine is directly routed to the virtual machine when it is generated, so as to realize interrupt transparent transmission, shorten the virtual machine interrupt path, and improve the interrupt virtualization efficiency.

[0019] In a possible implementation of the first aspect, when the computing node is an ARM system, when the microkernel layer is started, it is specifically used to clear the IMO bit and AMO bit of the HCR_EL2 register through the encapsulation interface related to interrupt controller virtualization provided by the abstract layer.

[0020] From the above, by clearing the IMO bit and AMO bit of the HCR_EL2 register of the ARM system, the physical interrupt and SError interrupt are directly routed to EL1 (ie, the virtual machine level), shortening the interrupt path of the ARM system virtual machine and improving the interrupt virtualization efficiency.

[0021] In a possible implementation of the first aspect, when the microkernel layer is started, it is used to allocate resources to each virtual machine according to the device tree of the microkernel and the virtual machine, and the device tree of the microkernel and the virtual machine is generated through a visual interface of an external SDC; wherein, resources are configured for the microkernel and each virtual machine on the visual interface, and the device tree of the microkernel and the virtual machine is generated according to the original device tree obtained from the computing node and the configured resources.

[0022] From the above, the virtual machines can be visually configured through SDC and the resources between virtual machines can be isolated. This not only meets the resource size of the virtual machines, making the development of virtual machines more flexible and the function selection more appropriate, but also makes the operation simpler and the configuration interface clear at a glance.

[0023] In a possible implementation of the first aspect, the microkernel layer sets a libvirt interface of Open Stack, runs a Nova-Compute service on a non-real-time virtual machine of the computing node, and the Nova-Compute service starts other virtual machines on the computing node through the libvirt interface and manages the started virtual machines. The libvirt interface encapsulates the virtual machine management of the microkernel layer.

[0024] As described above, the microkernel layer of the scheduled computing node sets the libvirt interface of Open Stack. The Nova-Compute service uses the real-time virtual machine through the libvirt interface to implement real-time virtual machine management on the operating system based on Open Stack, thereby improving its real-time performance and security.

[0025] In a possible implementation manner of the first aspect, the operating system is developed according to the software development management process of EN50128 and achieves SIL4 level safety certification.

[0026] As mentioned above, the SIL4 safety-certified operating system ensures the security, isolation, and stability of the virtualized environment to prevent potential security threats and fault propagation, and reduce potential security risks.

[0027] In the second aspect, an embodiment of the present application provides a signal system cloud platform, comprising: a management node and several computing nodes, each computing node running an operating system as described in any implementation method of the first aspect; the management node is used to schedule corresponding computing nodes for the applications of the signal system, and start corresponding virtual machines on the scheduled computing nodes and deploy the applications of the signal system on the started virtual machines; wherein the computing nodes scheduled for the security applications of the signal system meet the real-time requirements of the security applications, and the virtual machines corresponding to the security applications are real-time virtual machines.

[0028] From the above, the signal system cloud platform embodiment integrates the lightweight isolated virtualization solution and cloud technology of the operating system, and provides a real-time virtual machine that meets the real-time requirements of the security application for the signal system, so as to improve the high reliability and high availability of the security application.

[0029] In a possible implementation of the second aspect, each computing node is provided with a non-real-time virtual machine, which is used to serve as a management agent of the management node on the computing node; the management node is also used to manage the virtual machines on the computing node through the management agent on each computing node.

[0030] From the above, by setting a management agent on each computing node and the management node managing the virtual machines on the computing node through the management agent on each computing node, the management node can manage the virtual machines of each computing node on the signal system cloud platform.

[0031] In a possible implementation of the second aspect, the management node is also used to manage the resources of each virtual machine on the computer node through the management agent on each computing node in one of the following ways: when any resource load of the virtual machine reaches a preset threshold, trigger an alarm; when the virtual machine is running, protect the resources of the virtual machine; when the idle time of the virtual machine exceeds a threshold, delete the virtual machine; after the virtual machine is deleted, recycle the resources of the virtual machine.

[0032] From the above, the management and monitoring of virtual machine resources is the key link to ensure the stable operation of the system. Through the management node, the operation status of the virtual machine can be fully grasped and effectively managed. The resources of the running virtual machines can be protected and monitored to improve the certainty of the virtual machines. The resources of the virtual machines that have been idle for a long time and have been deleted can be recovered in time to improve the utilization of system resources.

[0033] In a possible implementation of the second aspect, the microkernel layer of the operating system of each computing node sets the libvirt interface of Open Stack, and runs the Nova-Compute service on a non-real-time virtual machine of each computing node as a management agent of the computing node based on Open Stack; the management node includes a control node based on Open Stack, which is used to schedule computing nodes for each application of the signal system according to the real-time requirements of the application, and use the Nova-Compute service on the scheduled computing node to start and manage the virtual machine through the libvirt interface of the computing node.

[0034] As described above, the microkernel layer of the computing node sets the libvirt interface of Open Stack. The management node uses the libvirt interface to manage the virtual machines on each computing node through the Nova-Compute service on the computing node, thereby providing dynamic management services for the virtual machines on each computing node through the network, improving its real-time performance and security.

[0035] In a possible implementation of the second aspect, each of the security applications is deployed on a corresponding real-time virtual machine through 2x2 take 2 redundancy.

[0036] From the above, by deploying 2 times 2 take 2 redundancy on real-time virtual machines for different computing operations, the high reliability and high availability of safety applications of the signal system are improved.

[0037] In a possible implementation of the second aspect, each computing node communicates with the management node and each computing node communicates with each other through a TSN protocol.

[0038] As mentioned above, each computing node communicates with the management node and between each computing node through the TSN protocol, which improves the time certainty of the safety application of the signal system.

[0039] In a possible implementation of the second aspect, the management node is also used to manage the virtual network between the virtual machines on each computing node, and the management includes at least one of the following: defining the topology of the virtual network, configuring the network parameters and network security policies of the virtual network, monitoring the performance of the virtual network, and troubleshooting the virtual network.

[0040] From the above, the virtual network between the virtual machines on each computing node is managed by the management node to achieve secure communication between the virtual machines.

[0041] In a possible implementation of the second aspect, the cloud platform is used for rail transit signal control, and the safety application implements at least one of the following functions: ATP, interlocking, and control of trackside switches and / or signal machines.

[0042] From the above, the signal system cloud platform implementation scheme integrates the lightweight isolated virtualization solution and cloud technology of the operating system, and provides a real-time virtual machine for the ATP, interlocking and other safety applications of the rail transit signal system, so as to improve the integration of the rail transit signal system and achieve its high reliability and high availability.

[0043] In a possible implementation of the second aspect, the safety application is specifically used to control the trackside turnouts and / or the signal through the equipment controller of the station; or the safety application is specifically used to control the trackside turnouts through the turnout controller of the station and / or to control the trackside signal through the signal controller of the station; or the safety application is specifically used to control the trackside turnouts through the turnout controller of the trackside and / or to control the trackside signal through the signal controller of the trackside, wherein the cloud platform is connected to the turnout controller and the signal controller via a 5G network.

[0044] From the above, the ATP, interlocking and other safety applications of the rail transit system can control the trackside switches and signal machines through multiple paths, which is suitable for a variety of scenarios.

[0045] In a third aspect, an embodiment of the present application provides a computing device, including:

[0046] bus;

[0047] A communication interface connected to the bus;

[0048] at least one processor connected to the bus; and

[0049] At least one memory connected to the bus and storing program instructions, wherein when the program instructions are executed by the at least one processor, an operating system as described in any embodiment of the first aspect is installed on the computing device.

[0050] In a fourth aspect, the embodiments of the present application provide

[0051] A computer-readable storage medium stores program instructions thereon, wherein when the program instructions are executed by a computer, the operating system as described in any embodiment of the first aspect is installed on the computer. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 This is a schematic diagram of the structure of an operating system embodiment 1 of the present application;

[0053] Figure 2 This is a schematic diagram of the structure of an operating system embodiment 2 of the present application;

[0054] Figure 3 This is a schematic diagram of the architecture of a processor mapping solution of a vCPU management component of a microkernel layer of an operating system embodiment 2 of the present application;

[0055] Figure 4 This is a schematic diagram of the architecture of a scheduling management component of a microkernel layer of an operating system embodiment 2 of the present application;

[0056] Figure 5 A schematic diagram of a communication architecture based on an Ivshmem device according to a second operating system embodiment of the present application;

[0057] Fig. 6A A schematic diagram of an interrupt transmission architecture without an interrupt transparent transmission solution is shown;

[0058] Figure 6B This is a schematic diagram of the interrupt transparent transmission solution architecture of an operating system embodiment 2 of the present application;

[0059] Figure 7 This is a schematic diagram of the architecture of the direct device clock control of the second operating system embodiment of the present application;

[0060] Figure 8 A schematic diagram of the architecture of virtual machine resource configuration of an operating system embodiment 2 of the present application;

[0061] Fig. 9 A schematic diagram of an architecture of a signal system cloud platform embodiment of the present application based on Open Stack management virtual machines;

[0062] Fig.10 This is a schematic diagram of an architecture of 2 times 2 taking 2 of a signal system cloud platform embodiment of the present application;

[0063] Fig.11 This is a schematic diagram of the structure of a rail transit signal system cloud platform controlled by a station equipment controller in the present application;

[0064] Fig.12 This is a schematic diagram of the structure of a rail transit signal system cloud platform controlled by a station's turnout controller and signal controller;

[0065] Fig.13 This is a schematic diagram of the structure of a rail transit signal system cloud platform controlled by a trackside turnout controller and a signal controller;

[0066] Fig.14 This is a schematic diagram of the structure of a computing device according to the present application. DETAILED DESCRIPTION

[0067] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0068] In the following description, the terms "first\second\third, etc." or module A, module B, module C, etc. are only used to distinguish similar objects, or to distinguish different embodiments, and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0069] In the following description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the previous and next steps can be interchanged, or they can be executed simultaneously.

[0070] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0071] An embodiment of the present application provides an operating system and a signal system cloud platform, the operating system including: an abstraction layer, used to encapsulate the computing node architecture-level driver, architecture-level virtualization and CPU core, and provide a hardware-system-independent encapsulation interface to other layers, the architecture-level driver includes at least one of the following: IOMMU driver, MMU driver, interrupt controller driver, the architecture-level virtualization includes one of the following: clock virtualization and interrupt controller virtualization; a microkernel layer, used to use the encapsulation interface provided by the abstraction layer to build various components and simulation devices of the microkernel, the components are at least used to implement vCPU management, memory management, scheduling management, and virtual machine management; an application layer, including various virtual machines running on the microkernel layer, the virtual machines include real-time virtual machines and non-real-time virtual machines, and each real-time virtual machine is isolated from other virtual machines through the microkernel configuration resources.

[0072] The technical solution of the embodiment of the present application abstracts the computing node hardware independent of the computer system. The microkernel built based on the abstraction supports real-time and non-real-time virtual machines at different security levels. It not only enables multiple applications at different security levels to run in parallel on the same physical computer, but also improves the utilization efficiency of hardware resources. It can also run as a lightweight solution on computers of various hardware systems, and can meet the system information security and functional safety integration requirements of smart devices in the fields of smart cars, rail transit, etc. for multiple operating systems.

[0073] The following describes various embodiments of the present application in conjunction with the accompanying drawings. Figure 1 An operating system embodiment 1 of the present application is introduced.

[0074] Figure 1 The structure of a first embodiment of an operating system is shown, including: an abstraction layer 110 , a microkernel layer 120 and an application layer 130 .

[0075] The abstraction layer 110 is used to encapsulate the computing node architecture-level driver, architecture-level virtualization, and CPU core, and provide a hardware-system-independent encapsulation interface to other layers.

[0076] For example, the encapsulation interface for ARM system and x86 system does not have parameters related to ARM system or x86 system, but only function-related parameters, which facilitates component calling in the microkernel, realizes a lightweight microkernel, and makes the microkernel suitable for computers of various systems.

[0077] Among them, the architecture-level driver includes at least one of the following: IOMMU driver, MMU driver, interrupt controller driver; architecture-level virtualization includes at least one of the following: clock virtualization and interrupt controller virtualization. The CPU core is mainly used to control the parallel conflict and cache access of the physical CPU, including: interrupt / exception / context processing, spin lock, atomic operation and cache management. The encapsulation interface related to the interrupt controller driver supports interrupt controller virtualization.

[0078] The microkernel layer 120 is used to construct various components and simulated devices of the microkernel using the encapsulation interface provided by the abstraction layer 110, provide hardware resources for each user-mode virtual machine of the application layer 130 thereon, and form an operating environment for each user-mode virtual machine.

[0079] Among them, the components are used to implement at least microkernel functions such as vCPU management, memory management, scheduling management, and virtual machine management. Various components of the microkernel are constructed through the interface provided by the abstract layer 110, so that the implementation of each component is independent of the system of the computing node hardware, and a lightweight microkernel is realized. The encapsulation interface related to the IOMMU driver and the MMU driver in the abstract layer 110 supports memory management, and the encapsulation interface related to the interrupt controller driver and the interrupt controller virtualization in the abstract layer 110 supports scheduling management. The simulated device is shared by each virtual machine.

[0080] The application layer 130 includes various virtual machines running on the microkernel layer 120 , including real-time virtual machines and non-real-time virtual machines.

[0081] Each real-time virtual machine is configured with resources isolated from other virtual machines through the microkernel layer 120 to improve its real-time performance.

[0082] In a possible implementation of this embodiment, the microkernel layer 120 is used to set the physical CPU scheduled to the real-time virtual machine as a real-time physical CPU during scheduling management, and the real-time physical CPU turns off timer interrupts and preemption timers.

[0083] Among them, the real-time and non-real-time attributes are set for the virtual machine. For the real-time virtual machine, the timer interrupt and preemption timer of the physical CPU scheduled for it (even if the scheduling is a vCPU, it is eventually mapped to the physical CPU) are turned off through the microkernel layer 120, and the real-time virtual machine will not be interrupted by other non-real-time tasks and interrupts, and it is also ensured that the real-time virtual machine can run without interference, thereby meeting the real-time requirements. However, it should be noted that: when a physical CPU is switched from a real-time virtual machine to a non-real-time virtual machine, its timer interrupt and preemption timer will not be turned off.

[0084] In a possible implementation of this embodiment, the tasks of the real-time virtual machine include real-time tasks and non-real-time tasks. Each virtual machine is provided with a task scheduler for scheduling the vCPU for the real-time task as a real-time vCPU, and the real-time vCPU turns off the timer interrupt and preemption timer. The real-time task will not be interrupted by other non-real-time tasks, and it is also ensured that the real-time task can run without interference, thereby meeting the real-time requirements. However, it should be noted that when a vCPU switches from a real-time task to a non-real-time task, its timer interrupt and preemption timer will not be turned off.

[0085] In a possible implementation of this embodiment, the microkernel layer 120 is used to map the vCPU of each virtual machine to the physical CPU during vCPU management, and the mapping strategy includes processor partitioning and processor sharing.

[0086] Among them, processor partitioning binds the vCPU of each real-time virtual machine to a dedicated physical CPU, and ensures that the running state of the vCPU of the virtual machine should not be tampered with by other virtual machines through the security / real-time virtual machine core isolation mechanism.

[0087] Among them, processor sharing enables the vCPUs of two or more virtual machines to share one physical CPU. Switching between different vCPUs requires switching more complex contexts. As long as interrupt passthrough is not enabled in the virtual machine, the physical CPU can be shared. Processor sharing can provide flexible computing resource sharing for vCPU tasks with low real-time and low performance requirements.

[0088] In a possible implementation of this embodiment, the simulation device of the microkernel layer 120 includes an Ivshmem device, and each virtual machine communicates with each other through the Ivshmem device. The microkernel layer 120 is used to configure the Ivshmem device as a virtual standard PCI device and configure it with memory shared by each virtual machine.

[0089] Among them, the microkernel layer 120 designs the Ivshmem device as a virtual standard PCI device, and exposes the shared memory address and size of this PCI device to each virtual machine. The application in the virtual machine can access this standard PCI device driver, and then access and operate the shared memory area provided by the virtual PCI device to support high-speed communication between virtual machines.

[0090] In one possible implementation of this embodiment, the microkernel layer 120 is used to configure the clock space for the pass-through device of each virtual machine through the interface related to clock virtualization provided by the abstract layer 110 when starting each virtual machine, and set each virtual machine to be unable to access the clock space of the virtual machine, and the clock space of each virtual machine is different; when each virtual machine accesses the clock space of its pass-through device, it falls into the microkernel layer 120, and the microkernel layer 120 is also used to access the space corresponding to the clock address on behalf of the virtual machine, and feedback the access result to the virtual machine.

[0091] Among them, the virtual machine controls the opening and closing of the clock of its direct physical device according to demand, avoiding the default opening of the clock required for all virtual machines when the microkernel is started and initialized, reducing the clock power consumption of the physical direct device, and can obtain clock information of any space size in time, without being limited by the space management granularity of the MMU, reducing the memory space occupied by the clock space.

[0092] In one possible implementation of this embodiment, when the microkernel layer 120 is started, it is used to modify the interrupt routing through the interface related to the interrupt controller virtualization provided by the abstract layer 110, so that the interrupt allocated to each virtual machine is directly routed to the virtual machine when it is generated, thereby realizing interrupt transparent transmission, shortening the virtual machine interrupt path, and improving the efficiency of interrupt virtualization.

[0093] Among them, by routing the interrupt assigned to each virtual machine directly to the virtual machine when it is generated, interrupt transparent transmission is achieved, the virtual machine interrupt path is shortened, the interrupt virtualization efficiency is improved, and there is no need to modify the ATF code. The implementation method is simple and the virtio device sharing function is not affected.

[0094] In one possible implementation of this embodiment, when interrupt pass-through is used and the computing node is an ARM system, when the microkernel layer 120 is started, the IMO bit and AMO bit of the HCR_EL2 register are cleared through the interface related to interrupt controller virtualization provided by the abstract layer 110, so that the physical interrupt and SError interrupt are directly routed to EL1 (ie, the virtual machine level).

[0095] Among them, the abstract layer 110 knows that the computer system of the computing node is the ARM system. When receiving the modification interrupt route to EL1, the interrupt controller virtualization code of the ARM system automatically converts the command received from the relevant package interface into a command to clear the IMO bit and AMO bit of the HCR_EL2 register, and clears the IMO bit and AMO bit of the HCR_EL2 register through the driver of the interrupt controller of the ARM system.

[0096] In a possible implementation of this embodiment, when interrupt pass-through is used and the computing node is an ARM system, the microkernel layer 120 applies for physical SPI interrupt numbers for the virtio front-end and back-end respectively at startup through the interface related to interrupt controller virtualization provided by the abstract layer 110, and the physical interrupt number needs to be outside the range of physical interrupt numbers used by all virtual machines. When the virtio front-end and back-end are trapped in the microkernel by writing memory for notification, the microkernel layer 120 sets a specific bit of the GIC register GICD_ISPENDR according to the applied physical interrupt number through the interface related to interrupt controller virtualization provided by the abstract layer 110, and generates a physical SPI interrupt, which is directly processed by the corresponding virtual machine.

[0097] In a possible implementation of this embodiment, the microkernel layer 120 is used to allocate resources to each virtual machine according to the device tree of the microkernel and the virtual machine when it is started, and the device tree of the microkernel and the virtual machine is generated through a visual interface of an external SDC; wherein resources are configured for the microkernel and each virtual machine on the visual interface, and the device tree of the microkernel and the virtual machine is generated according to the original device tree obtained from the computing node and the configured resources.

[0098] Among them, the device tree of the microkernel and the virtual machine is generated according to the original device tree obtained from the computing node and the configured resources, including: obtaining the original device tree on the hardware board of the computing node through the visual interface of the SDC, wherein the hardware resources on the computing node all have nodes in the original device tree; setting all nodes in the original device tree to an unenabled state to obtain a new device tree for the computing node; configuring hardware resources for each virtual machine of the computing node, and using the new device tree as the basic device tree, obtaining the device tree of each virtual machine according to the hardware resources configured for each virtual machine; having a device tree for an existing virtual machine on the computing node, and displaying the hardware resource configuration of the existing virtual machine on the visual interface of the SDC according to the device tree, and then reconfiguring the hardware resources of the existing virtual machine.

[0099] Through SDC, virtual machines can be visually configured and resources between virtual machines can be isolated, which not only meets the resource size of virtual machines, making virtual machine development more flexible and function selection more appropriate, but also makes operation simpler and the configuration interface clear at a glance.

[0100] In a possible implementation of this embodiment, the components of the microkernel layer 120 include virtual machine management, which is encapsulated as a libvirt interface based on Open Stack, and a Nova-Compute service is run on a non-real-time virtual machine of a computing node as an Open Stack-based management agent of the computing node. The Nova-Compute service sets the libvirt connection address to the libvirt interface of the microkernel layer 120, starts other virtual machines on the computing node through the libvirt interface, and manages the started virtual machines.

[0101] When running the Nova-Compute service, the image directory of the virtual machine of the computing node is set to the image path directory of the microkernel of the computing node, so that the microkernel can obtain the image of the virtual machine. The MAC address of the network card of the virtual machine to be created obtained from Neutron based on Open Stack is sent to the microkernel of the computing node. The Type 1 virtual machine network card created in the microkernel can obtain the correct IP address through the DHCP network service provided by the platform based on Open Stack.

[0102] The computing nodes that meet the requirements are scheduled according to the virtualization type of the virtual machine. The scheduled computing nodes create virtual machines through the interfaces connected to the Libvirt connection addresses of nova-compute configured according to their virtualization types, thereby creating real-time virtual machines based on type1 virtualization on computing nodes with type1 virtualization through Open Stack, thereby improving the real-time performance of real-time virtual machines.

[0103] In a possible implementation of this embodiment, the operating system of this embodiment is developed according to the software development management process of EN50128 and reaches SIL4 level safety certification. Among them, the operating system of this embodiment passes the safety certification, including ensuring the security, isolation and stability of the virtualized environment to prevent potential security threats and fault propagation. Through safety certification, it can be ensured that the operating system of this embodiment follows the best safety practices in the design and implementation process, and reduces potential safety risks.

[0104] In summary, an operating system implementation example abstracts the computing node hardware, and a microkernel built based on the abstraction supports real-time and non-real-time virtual machines at different security levels. It not only enables multiple applications at different security levels to run in parallel on the same physical computer, but also improves the utilization efficiency of hardware resources. It can also run as a lightweight solution on computers with a variety of hardware systems, and can meet the system information security and functional safety integration requirements of multiple operating systems for smart devices in the fields of smart cars, rail transit, etc.

[0105] Combine the following Figures 2 to 8 A second operating system embodiment of the present application is introduced.

[0106] A second operating system embodiment is a detailed implementation of the first operating system embodiment, and has all the advantages of the first operating system embodiment.

[0107] Figure 2 The structure of a second operating system embodiment is shown, including: a basic module 210, an abstract layer 220, a microkernel layer 230 and an application layer 240.

[0108] The basic module 210 includes a basic C library, a basic log module, a bitmap module, and a linked list module, and provides basic functions for other layers, wherein the basic C library is a basic library for the C language runtime.

[0109] The abstraction layer 220 provides the microkernel layer 230 with an ASP architecture interface, which is independent of the hardware system of the computing node and abstractly encapsulates the functions of different hardware systems, including: an encapsulation interface for architecture-level drivers, an encapsulation interface for architecture-level virtualization, and an encapsulation interface for the CPU core.

[0110] Among them, when encapsulating the architecture-level driver, the architecture-level drivers of different computing node systems are encapsulated into a unified encapsulation interface. The encapsulation interface is independent of the computing node hardware system and only needs to call the driver's functional parameters. The driver includes at least IOMMU driver, MMU driver, interrupt controller driver, and timer driver.

[0111] Among them, when virtualizing the encapsulation architecture level, the encapsulation interface of the interrupt controller, clock, power supply and timer is virtualized, so that the virtualized interrupt, clock, power supply and timer are independent of the specific hardware system, and only the parameters of the user-mode related functions on the microkernel are required.

[0112] Among them, the core encapsulation of the CPU mainly encapsulates the parallel access control of the CPU critical area, including interrupt\exception\context processing, spin lock, atomic operation and cache processing, and also performs encapsulation that is independent of the system of the computing node hardware.

[0113] The microkernel layer 230 provides a system call interface to the application layer 240, and constructs microkernel components and simulation devices that are independent of the computing node hardware system through the ASP architecture interface of the abstract layer 220.

[0114] The microkernel component includes one of the following components: vCPU management, memory management, virtual machine management, system call, initialization, scheduling management, and kernel lock.

[0115] The simulated device includes one of the following devices: vPCI, vUART, Ivshmem, and vWatchdog.

[0116] The application layer 240 includes various virtual machines running on the microkernel layer 230, including: user-mode virtual machines, service virtual machines, and security virtual machines.

[0117] Among them, the user-state virtual machine includes a non-real-time virtual machine, which runs a user service program for low-isolation computing with low time requirements; the operating system thereon is a non-real-time operating system, for example, including Ubuntu, Hongdao and openEuler operating systems.

[0118] Among them, the service virtual machine provides public services for other virtual machines, including: virtual machine remote management service, local device driver service, and Virtio backend driver service.

[0119] Among them, the secure virtual machine includes a real-time virtual machine. The resources of the real-time virtual machine are isolated from those of other virtual machines. A real-time operating system runs on it, including direct device drivers and simulated device drivers. It performs security control on related devices and deploys real-time security applications. Only users with authentication permissions can use it.

[0120] From the above, an operating system embodiment 2 is a high-security, high-real-time and lightweight Hypervisor designed for security-critical fields. It can run multiple virtual machines with different security levels on a hardware platform, and realize effective isolation of hardware resources such as CPU, memory, and peripherals between operating systems. It can meet the system information security and functional safety integration requirements of smart devices in the fields of smart cars, rail transit, etc. for multiple operating systems. In order to meet the real-time, deterministic and security requirements of virtual machines in different scenarios, static resource configuration strategies are provided, a variety of virtual machine scheduling algorithms are provided, and capabilities such as device pass-through and interrupt pass-through are supported. Among them, for the sake of simplicity of description, in this embodiment, the Hypervisor replaces the basic module 210, the abstract layer 220 and the microkernel layer 230 as a whole, which will not be repeated below.

[0121] In order to meet the real-time, deterministic and security requirements of virtual machines in different scenarios, this embodiment provides a static resource configuration strategy, provides a variety of virtual machine scheduling algorithms, and also supports device transparent transmission, interrupt transparent transmission and other capabilities. The key capabilities of the operating system of this embodiment are described below in conjunction with the accompanying drawings.

[0122] Combine the following Figure 3 The following introduces a vCPU management component of the microkernel layer 230 of the second operating system embodiment. The vCPU management component is used to implement the mapping between the vCPU and the physical CPU, and to implement the isolation of the real-time virtual machine on the physical CPU resources.

[0123] Figure 3 A processor mapping scheme of the vCPU management component of the microkernel layer 230 of the second operating system embodiment is shown.

[0124] The vCPU management component supports two modes of physical processor management, including processor partitioning and processor sharing.

[0125] Processor partitioning: Processor partitioning means that a vCPU has a dedicated physical CPU bound to it, and the security / real-time virtual machine core isolation mechanism is used to ensure that the vCPU running state of the virtual machine should not be tampered with by other virtual machines. For example, CPU3 (physical CPU3) in the figure is bound to a vCPU alone and is exclusively used by a virtual machine (VM).

[0126] Processor sharing: Two or more vCPUs share one physical CPU. Switching between different vCPUs requires switching more complex contexts. As long as interrupt passthrough is not enabled in the client virtual machine, the physical CPU can be shared. In the processor sharing solution, real-time virtual machines are allocated fixed-time time slices in the time scheduler, and non-real-time virtual machines use shared time slices, providing flexible computing resource sharing for vCPU tasks with low real-time and low performance requirements.

[0127] For example, in the figure, CPU0 / 1 / 2 (physical CPU0 / 1 / 2) is occupied by two virtual machines (VMs), that is, the corresponding vCPUs in these two virtual machines share one physical CPU.

[0128] Combine the following Figure 4 The following introduces the scheduling management component of the microkernel layer 230 of the second operating system embodiment.

[0129] The scheduling management component provides isolated resources for real-time virtual machines and implements balanced scheduling for non-real-time virtual machines, making full use of physical CPU resources.

[0130] Figure 4 The figure shows the architecture of the scheduling management component of the microkernel layer 230 of the second operating system embodiment. The microkernel layer 230 provides a scheduler framework and supports multiple scheduling algorithms, including a priority scheduler and a time scheduler. The scheduling management component of the microkernel layer 230 registers different scheduler algorithms to the scheduler management framework according to its different scheduling strategies.

[0131] The microkernel layer 230 maintains a global task waiting queue, and each task is a virtual machine in the scheduling management component embodiment. When a physical CPU core is idle in the system, the scheduling management component selects a ready task (ready virtual machine) from the global task waiting queue and starts to execute on this core.

[0132] Each virtual machine has a priority ranging from 0 to 32, with 0 being the highest and 31 being the lowest. The task waiting queue has 32 sub-queues, with virtual machines of each priority queued separately, and ready virtual machines of the same priority are scheduled in round-robin time slices.

[0133] The virtual machine attributes are newly added with a real-time attribute flag, and the microkernel layer 230 provides an interface to set the real-time attribute of the virtual machine. Non-real-time virtual machines and partial real-time virtual machines can run on multiple shared physical CPU cores, while partial real-time virtual machines are divided into a fixed physical CPU core for running.

[0134] The microkernel layer 230 provides a real-time physical CPU set. When the virtual machine is switched, if the virtual machine to be run is a real-time virtual machine, the scheduling management component sets the current idle physical CPU to the real-time CPU set. The scheduling management component will not notify the real-time physical CPU running the real-time virtual machine to reschedule, so as to avoid the rescheduling IPI interrupt affecting the real-time virtual machine. When switching from a non-real-time virtual machine to a real-time virtual machine, the preemption timer of the real-time physical CPU is canceled and the timer interrupt is turned off. The real-time virtual machine executes immediately and will not be interrupted by its timer interrupt, IPI interrupt and external interrupt. Canceling the preemption timer can ensure that the real-time virtual machine can run without interference, thereby meeting the real-time requirements.

[0135] The physical CPU that is running a non-real-time virtual machine selects the ready virtual machine with the highest priority from the global task waiting queue to run. If there are multiple ready virtual machines in the sub-queue of the selected priority, they are scheduled in round-robin mode using time slices. If there are no ready virtual machines, the idle task is run.

[0136] A task scheduler is set in the real-time virtual machine. The task scheduler uses a method similar to the scheduling management component of the microkernel layer 230 of the second operating system embodiment to perform tasks. The vCPU scheduled to the real-time task is a real-time vCPU, and the real-time vCPU turns off the timer interrupt and preemption timer. The real-time task will not be interrupted by other non-real-time tasks, and it is also ensured that the real-time task can run without interference, thereby meeting the real-time requirements. However, it should be noted that when a vCPU switches from a real-time task to a non-real-time task, its timer interrupt and preemption timer will not be turned off.

[0137] Combine the following Figure 5 An Ivshmem device of a second operating system embodiment is introduced.

[0138] There may be high-speed, low-latency, and large-volume data communication requirements between virtual machines. To address this requirement, a shared memory mechanism between virtual machines based on the Ivshmem device is introduced. The Ivshmem device allows virtual machines to communicate with each other through a shared memory mechanism.

[0139] Figure 5 A communication architecture based on Ivshmem device of a second operating system embodiment is shown.

[0140] In the microkernel layer 230, the Ivshmem device is designed as a virtual standard PCI device and the shared memory address and size of this PCI device are exposed to each virtual machine. The application in the virtual machine accesses this standard PCI device driver through the Ivshmem device application layer driver in its user space and the Ivshmem PCI device kernel driver in its kernel space, and then accesses and operates the shared memory area provided by the virtual PCI device to support communication between virtual machines.

[0141] Combine the following Fig. 6A and Figure 6B An interrupt transparent transmission solution of operating system embodiment 2 is introduced.

[0142] Fig. 6A The interrupt transmission architecture without the interrupt pass-through solution is shown. In the virtualization solution without interrupt pass-through, when a hardware interrupt occurs, it will first fall into the hypervisor, which will handle the interrupt, and then inject virtual interrupts into the virtual machine. After the virtual machine is restored, the virtual interrupt is handled by the virtual machine. In this case, the hardware interrupt has a processing process of the virtual machine manager, resulting in a relatively long interrupt processing path, which will affect the real-time performance of the virtual machine.

[0143] Figure 6B The architecture of an interrupt transparent transmission solution of a second operating system embodiment is shown.

[0144] In the interrupt transparent transmission scheme implementation example, through the interrupt transparent transmission scheme, when the hardware interrupt hirq is generated, the hardware interrupt is directly processed by the virtual machine VM, and will not fall into the virtual machine manager for processing. This greatly shortens the interrupt processing path, can improve the real-time performance of the virtual machine, and does not need to modify the ATF code. The implementation method is simple, and the virtio device sharing function can also work normally.

[0145] For example, for an ARM system SOC, the following process implements the interrupt transparent transmission solution:

[0146] 1) Hypervisor starts, that is, starts the basic module 210, the abstraction layer 220 and the microkernel layer 230;

[0147] 2) When the virtual machine management component of the microkernel layer 230 determines that virtual interrupt passthrough is used, it calls the encapsulation interface related to interrupt controller virtualization of the abstract layer 220 to clear the IMO and AMO bits of the HCR_EL2 register, so that the physical interrupt and SError interrupt are directly routed to EL1;

[0148] 3) The virtual machine starts and uses the interrupt transparent transmission solution.

[0149] For virtio devices, the following process is used:

[0150] 1) Initialization components of the microkernel layer 230, the virtio front-end and back-end;

[0151] 2) The virtual machine management component of the microkernel layer 230 applies for physical SPI interrupt numbers for the virtio front-end and back-end respectively, and the physical interrupt numbers need to be outside the range of physical interrupt numbers used by all virtual machines;

[0152] 3) The virtio frontend and backend fall into the hypervisor by writing memory;

[0153] 4) The scheduling management component of the microkernel layer 230 sets a specific bit of the GIC register GICD_ISPENDR according to the requested physical interrupt number to generate a physical SPI interrupt;

[0154] 5) Physical SPI interrupt is generated and directly handled by the corresponding virtual machine.

[0155] Combine the following Figure 7 A second operating system embodiment of a direct device clock control embodiment is introduced.

[0156] Clock trees with low power consumption and small footprint play a vital role in computing nodes. In order to ensure the isolation of clock trees in virtual machines, to ensure that clock tree operations between virtual machines do not affect other virtual machines, and to ensure the real-time performance of real-time virtual machines, a clock tree virtualization mechanism must be provided.

[0157] Figure 7 A schematic diagram of a pass-through device clock control architecture of a second operating system embodiment is shown.

[0158] Each virtual machine is configured with a clock tree, which includes the clock space of each pass-through device. When starting each virtual machine, the microkernel layer 120 is used to configure the clock space of the pass-through device of each virtual machine through the interface related to clock virtualization provided by the abstract layer 110. The clock space of each virtual machine is different and does not affect each other. In the figure, the clock space of the pass-through devices device1 and device1 of the virtual machine VM1 is different from the clock space of the pass-through devices device3 and device4 of the virtual machine VM2.

[0159] It is set that each virtual machine cannot access the clock space of the virtual machine. When each virtual machine accesses the clock space of its direct device, it falls into the microkernel layer 120 (belonging to the hypervisor in the figure) through the permission check in the figure. The microkernel layer 120 is also used to access the space corresponding to the clock address on behalf of the virtual machine and feedback the access result to the virtual machine.

[0160] Therefore, the virtual machine controls the opening and closing of the clock of its direct physical device according to demand, avoiding the default opening of the clock required for all virtual machines when the microkernel is started and initialized, reducing the clock power consumption of the physical direct device, and can obtain clock information of any space size in time without being limited by the space management granularity of the MMU (for example, the minimum is 64KB), reducing the memory space occupied by the clock space.

[0161] Combine the following Figure 8 A virtual machine resource configuration embodiment of a second operating system embodiment is introduced.

[0162] The virtual machine resource configuration embodiment configures the hardware resources of the virtual machine through the visual interface of the SDC, and generates a device tree for each virtual machine in combination with the original device tree of the computing node, which is used to allocate hardware resources to each virtual machine when the microkernel of the operating system is started.

[0163] Figure 8 A schematic diagram of a virtual machine resource configuration architecture of a second operating system embodiment is shown.

[0164] Establish an SDC server on the computing node, establish an SDC client on an external PC, configure the resources of the virtual machine through the SDC visual interface, and start the virtual machine on the computing node, including the following process:

[0165] 1) Obtain the original device tree source.dtb on the hardware board of the computing node and the device tree and hypervisor device tree of the existing virtual machine on the computing node through the SDC server.

[0166] Among them, the SDC server runs the pre-installed system of the computing node, which has been started. The pre-installed system corresponds to an existing virtual machine running on the hypervisor of the computing node.

[0167] 2) All nodes with status in the original device tree source.dtb are set to a disabled state through the FDT standard interface, and a new device tree new.dtb of the computing node is obtained.

[0168] 3) Configure hardware resources for each virtual machine of the computing node, and use the new device tree new.dtb as the basic device tree, and obtain the device tree vmx.dtb of each virtual machine according to the hardware resources configured for each virtual machine.

[0169] Among them, for the virtual machines that already exist on the computing node, the resource configuration of the existing virtual machines is displayed on the visual interface of SDC, and then the resource configuration of the virtual machine is modified. For the virtual machines that are not currently on the computing node, the virtual machines can be added on the visual interface of SDC (vm create) and then resource configuration can be performed; the unnecessary virtual machines can also be deleted on the visual interface of SDC (vm delete)

[0170] For each virtual machine vmx, this step includes the following sub-steps.

[0171] (1) Configure the CPU ID occupied by the virtual machine vmx, which is the ID of the physical CPU;

[0172] (2) Configure the virtual machine type, service / user virtual machine;

[0173] (3) Configure the operating system type, real-time / non-real-time;

[0174] (4) Configure direct physical devices, including serial ports, GPU, EMMC, USB, etc.

[0175] (5) Configure virtual devices, including VNET, VBLK, and shared memory;

[0176] (6) Generate a new device tree vmx.dtb, using new.dtb as the basic device tree and generating a new vmx.dtb according to the configuration of the virtual machine.

[0177] 4) The Hypervisor of the computing node is used as the base device tree by using the new device tree new.dtb. According to the hardware resources configured for the Hypervisor, the device tree Hypervisor.dtb of the Hypervisor is obtained.

[0178] The resource configuration of the hypervisor of the computing node is displayed on the SDC visual interface, and then it can be modified.

[0179] Among them, this step includes the following sub-steps.

[0180] (1) Configure the debug serial port and debug level;

[0181] (2) Configure the clock frequency;

[0182] (3) Configure shared memory, etc.

[0183] (4) Advanced users configure the hypervisor's physical CPU ID and dedicated memory (optional sub-step);

[0184] (5) Advanced users specify specific physical addresses of memory for each virtual machine (optional sub-step).

[0185] (6) Generate a new device tree hypervisor.dtb, using new.dtb as the basic device tree and according to the hypervisor configuration, generate a new hypervisor.dtb.

[0186] Among them, hypervisor.dtb includes the physical memory addresses specified by advanced users for each virtual machine.

[0187] 5) Calculate the loading address of the image and device tree, generate the start.sh script file and change the hypervisor device tree of the computing node, and upload the start.sh script file and hypervisor device tree to the SDC server.

[0188] Among them, this step includes the following sub-steps.

[0189] (1) The SDC client visualization interface accesses the device tree and virtual machine image files on the computing node through the FTP service and calculates the file size.

[0190] Among them, the device tree and virtual machine image files on the computing node have been uploaded to the SDC server, namely the computing node, in advance.

[0191] (2) Calculate the loading addresses of all device trees and virtual machine image files and add them to the start.sh script file.

[0192] The start.sh script file is used to start the hypervisor, which includes the image file of the hypervisor and the loading address of the device tree.

[0193] (3) Modify the hypervisor.dtb file and fill the device tree of each virtual machine and the loading address of the virtual machine image file into the hypervisor.dtb file.

[0194] (4) Upload the start.sh script file, the device tree of the virtual machine, and the hypervisor.dtb file to the SDC server, that is, the computing node.

[0195] 6) Execute the start.sh script under the uboot of the computing node. Start.sh starts the hypervisor.

[0196] The start.sh script includes the device tree of the hypervisor and the loading address of the image file. Start.sh obtains the device tree and the image file of the hypervisor from the loading address and runs the hypervisor image file to start the hypervisor, that is, to start the basic module 210, the abstract layer 220 and the microkernel layer 230.

[0197] Among them, other scripts can also be generated through the visual interface of SDC, which are used for virtual machine start (vm start), virtual machine pause (vm suspend), virtual machine stop (vm stop), etc., and uploaded to the server side of SDC for operation.

[0198] 7) The hypervisor of the computing node obtains the device tree and image files of each virtual machine.

[0199] After the hypervisor is running, the device tree and the image file of each virtual machine are obtained from the loading address of the device tree and the image file of each virtual machine in the hypervisor device tree.

[0200] 8) During the hypervisor runtime, the virtual machine management component (in the microkernel layer 230) parses each device tree through the encapsulated interface and the FDT standard interface to obtain the resource structure of the hypervisor and each virtual machine, and allocates hardware resources to the hypervisor and each virtual machine according to each structure.

[0201] 9) The virtual machine management component runs the image of each virtual machine on the hardware resources allocated to the virtual machine, and starts the virtual machine according to the device tree of the virtual machine.

[0202] The following introduces a virtual machine management solution based on Open Stack in a second operating system embodiment.

[0203] In this embodiment, the virtual machines of the operating system are managed based on Open Stack. The components of the microkernel layer 230 include virtual machine management and monitoring management. The virtual machine management is encapsulated as a libvirt interface based on Open Stack. The Nova-Compute service is run on a non-real-time virtual machine of the computing node as an Open Stack-based management agent of the computing node.

[0204] The driver of the Nova-Compute service is generated through customized code and is used for the following functions:

[0205] 1) The libvirt connection address of the Nova-Compute service is set to the libvirt interface of the microkernel layer 120, and other virtual machines on the computing node are started through the libvirt interface, and the started virtual machines are managed, including the creation, startup, monitoring, suspension, stop and deletion of the life cycle of the virtual machine.

[0206] 2) When running the Nova-Compute service, set the image directory of the virtual machine of the computing node to the image path directory of the microkernel of the computing node, so that the microkernel can obtain the image of the virtual machine to create and start the virtual machine of the computing node.

[0207] 3) The MAC address of the network card of the virtual machine to be created obtained from Neutron based on Open Stack is sent to the microkernel of the computing node. The Type 1 virtual machine network card created in the microkernel can obtain the correct IP address through the DHCP network service provided by the Open Stack-based platform.

[0208] Combine the following Fig. 9 and Fig.10 A signal system cloud platform embodiment of the present application is introduced.

[0209] A signal system cloud platform includes a management node and several computing nodes. Each computing node runs an operating system as described in operating system embodiment 1 or operating system embodiment 2, and has all the advantages of operating system embodiment 1 or embodiment 2.

[0210] The management node is used to schedule the corresponding computing nodes for the signal system application, start the corresponding virtual machine on the scheduled computing node, and deploy the signal system application on the started virtual machine. The human-computer interaction interface of the cloud platform is also set on the management node to realize the management and supervision of the computing nodes.

[0211] Among them, the applications of the signal system include safety applications and management applications. The safety applications are deployed on the real-time virtual machines of the corresponding computing nodes, and each safety application runs synchronously and redundantly on different computing nodes. The management application is deployed on the non-real-time virtual machines of the corresponding computing nodes to serve the virtual machines on the computing nodes.

[0212] Among them, the computing nodes scheduled for the safety application of the signal system meet the real-time requirements of the safety application. The corresponding virtual machine here is a real-time virtual machine, and the real-time requirements require the number of CPU cores, memory size, disk space and other requirements.

[0213] In one implementation of this embodiment, a non-real-time virtual machine is set on each computing node to serve as a management agent of the management node on the computing node; the management node is also used to monitor the virtual machine on the computing node through the management agent on each computing node, thereby performing life cycle management on the virtual machine on each computing node, and the management includes the creation, startup, monitoring, suspension, stop and deletion of the life cycle of the virtual machine. The scheduled computing node meets the requirements of the virtual machine such as the number of CPU cores, memory size, disk space, etc.

[0214] In one implementation of this embodiment, the management node is also used to manage the resources of each virtual machine on the computer node through the management agent on each computing node in one of the following ways: when any resource load of the virtual machine reaches a preset threshold, an alarm is triggered; when the virtual machine is running, the resources of the virtual machine are protected; when the idle time of the virtual machine exceeds the threshold, the virtual machine is deleted; after the virtual machine is deleted, the resources of the virtual machine are recycled. From the above, managing and monitoring virtual machine resources is a key link to ensure the stable operation of the system. Through the management node, the operation status of the virtual machine is fully grasped and effectively managed, the resources of the running virtual machine are protected and monitored, the certainty of the virtual machine is improved, and the resources of the virtual machine that has been idle for a long time and deleted are recycled in time, thereby improving the utilization rate of system resources.

[0215] In one implementation of this embodiment, each computing node and the management node, as well as each other, communicate via the TSN protocol, thereby improving the real-time performance of the safety application of the signal system.

[0216] In one implementation of this embodiment, the management node is also used to manage the virtual network between virtual machines, and the management includes at least one of the following: defining the topology of the virtual network, configuring the network parameters and network security policies of the virtual network, monitoring the performance of the virtual network, and troubleshooting the virtual network. First, the management node defines the virtual network topology, including network devices such as switches, routers, firewalls, and the connection relationship between them; then, the management node configures network parameters such as IP addresses, subnet masks, gateways, etc. according to actual needs to ensure that virtual machines can communicate correctly. In addition, the management node also provides a network security policy setting function, which defines security policies such as access control rules and traffic restrictions according to business needs to protect the system from network attacks and data leakage risks. In the process of virtual network management, the management node should also provide network performance monitoring and troubleshooting functions to help users discover and solve network problems in a timely manner and ensure the stable operation of the system.

[0217] In an implementation of this embodiment, the management node manages the virtual machine on each computing node based on Open Stack.

[0218] Fig. 9 An architecture of an Open Stack management virtual machine in an embodiment of a signal system cloud platform is shown, which includes: a management node 910 and a plurality of computing nodes 920 .

[0219] The hypervisor of each computing node includes components for virtual machine management and monitoring management, which encapsulates the virtual machine management and monitoring management as an Open Stack-based libvirt interface, and runs the Nova-Compute service on a non-real-time virtual machine of the computing node as an Open Stack-based management agent of the management node 910 on the computing node.

[0220] The driver of the Nova-Compute service sets the libvirt connection address of the Nova-Compute service to the libvirt interface of the microkernel layer, starts other virtual machines on the computing node through the libvirt interface, and manages the started virtual machines. The driver is implemented by customizing and rewriting the source code of the Nova-Compute service.

[0221] It should be noted that: in this embodiment, the hypervisor includes at least an abstraction layer and a microkernel layer of an operating system implementation one or two.

[0222] The management node 910 includes a control node based on Open Stack, which is used to schedule computing nodes for each application of the signal system according to the real-time requirements of the application, and manage virtual machines through the libvirt interface of the computing node using the Nova-Compute service on the scheduled computing node, including the creation, startup, monitoring, suspension, stop and deletion of the life cycle of the virtual machine. The scheduling function of the control node is realized by customizing and rewriting the source code of the Open Stack-based scheduler.

[0223] In one implementation of this embodiment, each safety application of the signal system is deployed on a corresponding real-time virtual machine through 2 times 2 take 2 redundancy to improve the high reliability and high availability of the safety application.

[0224] Fig.10 An architecture of 2 times 2 equals 2 for an embodiment of a signal system cloud platform is shown.

[0225] In this architecture, the 2-out-of-2 means using the output result of the security application on any of the two computing nodes when the synchronous outputs of the redundantly deployed security applications on the two computing nodes are completely consistent, and the 2-times means deploying the security application on four computing nodes respectively, of which two computing nodes are the active group, serving as the two computing nodes of the 2-out-of-2, and the other two computing nodes are the standby group, serving as the synchronous redundant backup of the 2-out-of-2. For example, the computing nodes corresponding to hardware 1 and the computing nodes corresponding to hardware 1 are the active group, serving as the two computing nodes of the 2-out-of-2; the computing nodes corresponding to hardware 3 and the computing nodes corresponding to hardware 4 are the active group, serving as the synchronous redundant backup of the two computing nodes of the 2-out-of-2.

[0226] There is another way to multiply 2 by 2. Fig.10 The architecture shown in FIG. 2 is a 2x2-take-2 architecture deployed on two computing nodes, with partitions as the basic unit. At this time, two or more partitions A, B, ... are run on the same computing node, each running multiple periodic tasks. The AB partition completes the 2x2 function, and two computing nodes running the same task constitute a complete 2x2-take-2 architecture.

[0227] In each 2x2-out-of-2 architecture, the management node is also used to synchronize and migrate virtual machines in the signal system. The real-time synchronization of data between two different groups of virtual machines in the 2x2-out-of-2 safety redundant architecture means that any data changes on one side will be immediately reflected on the other side. Once the active group fails, the standby group will quickly take over the work of the active group to ensure uninterrupted service. At the same time, the system also has dynamic expansion capabilities. When the standby system needs maintenance or fails, the management node will create a new group of virtual machines and start them as a new group to take over the work of the existing standby group and continue to maintain the 2x2-out-of-2 safety redundant state.

[0228] In summary, a signal system cloud platform embodiment integrates a lightweight isolated virtualization solution and cloud technology of an operating system described in operating system embodiment one or embodiment two, and provides a real-time virtual machine that meets the real-time requirements of the security application for the signal system's security application, thereby improving the high reliability and high availability of the security application.

[0229] Combine the following Figures 11 to 13 An embodiment of a rail transit signal system cloud platform of the present application is introduced.

[0230] A rail transit signal system cloud platform embodiment is a specific way in which a signal system cloud platform embodiment is used for a rail transit signal system, and has all the advantages of a signal system cloud platform embodiment.

[0231] The safety application of the rail transit signal system is deployed in the real-time virtual machine of the computing node of the cloud platform. The safety application is deployed through a 2x2-out-of-2 redundant architecture and implements at least one of the following functions: ATP, interlocking, and control of trackside switches and / or signal machines. The monitoring application of the safety application of the rail transit signal system is deployed in the non-real-time virtual machine of the computing node of the cloud platform.

[0232] In one implementation of this embodiment, the safety application of the rail transit signal system is specifically used to control the trackside switch and / or the signal machine through the equipment controller of the station.

[0233] Fig.11 A structural diagram showing a rail transit signal system cloud platform controlled by a station equipment controller.

[0234] Among them, the ATP, interlocking and other safety applications of the rail transit signal system are deployed in the real-time virtual machines of the computing nodes of the signal cloud based on a 2x2-take-2 redundant architecture, and the monitoring applications of the safety applications of the rail transit signal system are deployed in the non-real-time virtual machines of the computing nodes of the monitoring cloud. Both the signal cloud and the monitoring cloud belong to the rail transit signal system cloud platform.

[0235] Among them, the station installs a machine cage, and an equipment controller is set in the machine cage. The monitoring cloud is connected to the equipment controller. The safety application of the rail transit signal system controls equipment such as trackside switches and signal machines through the equipment controller of the station.

[0236] In one implementation of this embodiment, the safety application of the rail transit signal system is specifically used to control the trackside turnouts through the turnout controller at the station and to control the trackside signals through the signal controller at the station.

[0237] Fig.12 A structural diagram showing a rail transit signal system cloud platform controlled by a station's turnout controller and signal controller.

[0238] Among them, the ATP, interlocking and other safety applications of the rail transit signal system are deployed in the real-time virtual machines of the computing nodes of the monitoring cloud based on a 2x2-take-2 redundant architecture, and the monitoring applications of the safety applications of the rail transit signal system are deployed in the non-real-time virtual machines of the computing nodes of the monitoring cloud. The monitoring cloud belongs to the rail transit signal system cloud platform.

[0239] Among them, the station is equipped with switch controllers, signal controllers and other controllers, and the monitoring cloud is connected to the trackside switch controllers, signal controllers and other controllers. The safety application of the rail transit signal system controls the trackside switches through the station's switch controller, controls the trackside signals through the station's signal controller, and also realizes corresponding control through other controllers of the station.

[0240] In one implementation of this embodiment, the safety application of the rail transit signal system is specifically used to control the trackside turnouts through the trackside turnout controller and to control the trackside signal through the trackside signal controller.

[0241] Fig.13 The present invention shows a structural diagram of a rail transit signal system cloud platform controlled by a turnout controller and a signal machine controller beside the track.

[0242] Among them, the ATP, interlocking and other safety applications of the rail transit signal system are deployed in the real-time virtual machines of the computing nodes of the monitoring cloud based on a 2x2-take-2 redundant architecture, and the monitoring applications of the safety applications of the rail transit signal system are deployed in the non-real-time virtual machines of the computing nodes of the monitoring cloud. The monitoring cloud belongs to the rail transit signal system cloud platform.

[0243] Among them, switch controllers, signal controllers and other controllers are set up on the trackside, and the monitoring cloud is connected to the switch controllers, signal controllers and other controllers through the 5G network. The safety application of the rail transit signal system controls the trackside switches through the switch controllers on the trackside, controls the trackside signals through the signal controllers on the trackside, and also realizes corresponding control through other controllers on the trackside.

[0244] The above three implementation methods of this embodiment support various application scenarios of the rail transit signal system cloud platform, thereby improving the applicability of this embodiment.

[0245] In summary, a rail transit signal system cloud platform embodiment integrates a lightweight virtualization solution and cloud technology of an operating system described in operating system embodiment one or embodiment two, and provides a real-time virtual machine that meets the real-time requirements of the safety application of the rail transit signal system, so as to improve the high reliability and high availability of safety applications such as ATP and interlocking of the rail transit signal system.

[0246] The present application embodiment also provides a computing device, Fig.14 Detailed introduction.

[0247] The computing device 1400 includes a processor 1410 , a memory 1420 , a communication interface 1430 , and a bus 1440 .

[0248] It should be understood that the communication interface 1430 in the computing device 1400 shown in this figure can be used to communicate with other devices.

[0249] The processor 1410 may be connected to a memory 1420. The memory 1420 may be used to store the program code and data. Therefore, the memory 1420 may be a storage unit inside the processor 1410, or an external storage unit independent of the processor 1410, or a component including a storage unit inside the processor 1410 and an external storage unit independent of the processor 1410.

[0250] Optionally, the computing device 1400 may further include a bus 1440. The memory 1420 and the communication interface 1430 may be connected to the processor 1410 via the bus 1440. The bus 1440 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus 1440 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the figure is represented by only one line, but it does not mean that there is only one bus or one type of bus.

[0251] It should be understood that in the embodiment of the present application, the processor 1410 may adopt a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. Alternatively, the processor 1410 may adopt one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiment of the present application.

[0252] The memory 1420 may include a read-only memory and a random access memory, and provides instructions and data to the processor 1410. A portion of the processor 1410 may also include a nonvolatile random access memory. For example, the processor 1410 may also store information on the device type.

[0253] When the computing device 1400 is running, the processor 1410 executes the computer-executable instructions in the memory 1420 to install various embodiments of an operating system on the computing device.

[0254] It should be understood that the computing device 1400 according to the embodiment of the present application can correspond to the corresponding subjects in the methods according to the embodiments of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 1400 are respectively for realizing the corresponding processes of each method of the present embodiment, which will not be repeated here for the sake of brevity.

[0255] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0256] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0257] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0258] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0259] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0260] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0261] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it is used to install various embodiments of an operating system on the computer.

[0262] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above.More specific examples (non-exhaustive lists) of computer-readable storage media include, electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above.In this document, computer-readable storage media can be any tangible medium containing or storing programs, which can be used by instruction execution systems, devices or devices or used in combination with them.

[0263] Computer-readable signal media may include data signals transmitted in baseband or as part of a carrier wave, which carry computer-readable program code. Such transmitted data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, transmit, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0264] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0265] Computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0266] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, all of which belong to the scope of protection of the present application.

Claims

1. An operating system, characterized in that: include: The abstraction layer is used to encapsulate the computing node architecture-level driver, architecture-level virtualization and CPU core, and provide a hardware-independent encapsulation interface to other layers. The architecture-level driver includes at least one of the following: IOMMU driver, MMU driver, interrupt controller driver. The architecture-level virtualization includes one of the following: clock virtualization and interrupt controller virtualization. A microkernel layer, used to construct various components and simulation devices of the microkernel using the encapsulation interface provided by the abstraction layer, wherein the components are used to implement at least vCPU management, memory management, scheduling management, and virtual machine management; The application layer includes various virtual machines running on the microkernel layer. The virtual machines include real-time virtual machines and non-real-time virtual machines. Each real-time virtual machine is configured with resources isolated from other virtual machines through the microkernel.

2. The operating system according to claim 1, characterized in that: During scheduling management, the microkernel layer is used to set the physical CPU scheduled to the real-time virtual machine as a real-time physical CPU, and the real-time physical CPU turns off timer interrupts and preemption timers.

3. The operating system according to claim 1, characterized in that: The tasks of the real-time virtual machine include real-time tasks and non-real-time tasks. Each virtual machine is provided with a task scheduler for scheduling the vCPU for the real-time task as the real-time vCPU. The real-time vCPU turns off the timer interrupt and the preemption timer.

4. The operating system according to claim 1, characterized in that: The microkernel layer is used to map the vCPU of each virtual machine to the physical CPU during vCPU management. The vCPU of each real-time virtual machine is bound to a dedicated physical CPU, and the vCPUs of two or more virtual machines share one physical CPU.

5. The operating system according to claim 1, characterized in that: The simulation device includes an Ivshmem device, and each virtual machine communicates with each other through the Ivshmem device. The microkernel layer is used to configure the Ivshmem device as a virtual standard PCI device and configure a memory shared by each virtual machine for it.

6. The operating system according to claim 1, characterized in that: The microkernel layer is used to configure the clock space for the pass-through device of each virtual machine through the encapsulation interface related to clock virtualization provided by the abstract layer when starting each virtual machine, and set each virtual machine to be unable to access the clock space of the virtual machine, and the clock space of each virtual machine is different; When each virtual machine accesses the clock space of its direct device, it falls into the microkernel layer. The microkernel layer is also used to access the space corresponding to the clock address on behalf of the virtual machine and feed back the access result to the virtual machine.

7. The operating system according to claim 1, characterized in that: When the microkernel layer is started, it is used to modify the interrupt routing through the encapsulation interface related to the interrupt controller virtualization provided by the abstraction layer, so that the interrupt allocated to each virtual machine is directly routed to the virtual machine when it is generated.

8. The operating system according to claim 7, characterized in that: When the computing node is an ARM system, when the microkernel layer is started, it is specifically used to clear the IMO bit and AMO bit of the HCR_EL2 register through the encapsulation interface related to the interrupt controller virtualization provided by the abstract layer.

9. The operating system according to claim 1, characterized in that: When the microkernel layer is started, it is used to allocate resources to each virtual machine according to the device tree of the microkernel and the virtual machine, and the device tree of the microkernel and the virtual machine is generated through the visual interface of the external SDC; wherein, resources are configured for the microkernel and each virtual machine on the visual interface, and the device tree of the microkernel and the virtual machine is generated according to the original device tree obtained from the computing node and the configured resources.

10. The operating system according to claim 1, characterized in that: The microkernel layer sets the libvirt interface of Open Stack, runs the Nova-Compute service on a non-real-time virtual machine of the computing node, and the Nova-Compute service starts other virtual machines on the computing node through the libvirt interface and manages the started virtual machines. The libvirt interface encapsulates the virtual machine management of the microkernel layer.

11. A signal system cloud platform, characterized in that: include: A management node and a plurality of computing nodes, each computing node running an operating system as claimed in any one of claims 1 to 10; The management node is used to schedule the corresponding computing nodes for the application of the signal system, start the corresponding virtual machines on the scheduled computing nodes, and deploy the application on the started virtual machines; The computing node scheduled for the safety application of the signal system meets the real-time requirement of the safety application, and the corresponding virtual machine started on the virtual machine is a real-time virtual machine.

12. The cloud platform according to claim 11, characterized in that: Each computing node is provided with a management agent of the management node on the computing node; the management node is also used to manage the virtual machines on the computing node through the management agent on each computing node.

13. The cloud platform according to claim 12, characterized in that: The management node is also used to manage the resources of each virtual machine on each computing node in one of the following ways through the management agent on the computing node: When any resource load of the virtual machine reaches a preset threshold, an alarm is triggered; When the virtual machine is running, protecting the resources of the virtual machine; When the idle time of the virtual machine exceeds a threshold, deleting the virtual machine; After the virtual machine is deleted, the resources of the virtual machine are reclaimed.

14. The cloud platform according to claim 13, characterized in that: When the microkernel layer of the operating system of each computing node sets the libvirt interface of Open Stack and runs the Nova-Compute service on a non-real-time virtual machine of each computing node, the Nova-Compute service is the management agent of the computing node, and the management node includes a control node based on Open Stack; The control node is used to schedule a computing node for each application of the signal system according to the real-time requirements of the application, and use the Nova-Compute service on the scheduled computing node to start and manage the corresponding virtual machine through the libvirt interface of the computing node.

15. The cloud platform according to claim 11, characterized in that: Each of the safety applications is deployed on a corresponding real-time virtual machine through 2 times 2 take 2 redundancy, and the corresponding real-time virtual machine is deployed on at least 2 computing nodes.

16. The cloud platform according to claim 11, characterized in that: Each computing node communicates with the management node and each computing node communicates with each other via the TSN protocol; and / or The management node is also used to manage the virtual network between the virtual machines on each computing node, and the management includes at least one of the following: defining the topology of the virtual network, configuring the network parameters and network security policy of the virtual network, monitoring the performance of the virtual network, and troubleshooting the virtual network.

17. The cloud platform according to any one of claims 11 to 16, characterized in that: The cloud platform is used for rail transit signal control, and the safety application implements at least one of the following functions: ATP, interlocking, and control of trackside switches and / or signal machines.

18. The cloud platform according to claim 17, characterized in that: The safety application is specifically used to control the trackside turnouts and / or the signal machines through the equipment controller of the station; or The safety application is specifically used to control the trackside turnouts through the turnout controller at the station and / or to control the trackside signals through the signal controller at the station; or The safety application is specifically used to control the trackside turnout through the trackside turnout controller and / or to control the trackside signal through the trackside signal controller, wherein the cloud platform is connected to the turnout controller and the signal controller through a 5G network.

19. A computing device, characterized in that include, bus; A communication interface connected to the bus; at least one processor connected to the bus; as well as At least one memory is connected to the bus and stores program instructions, and when the program instructions are executed by the at least one processor, the operating system according to any one of claims 1 to 10 is installed on the computing device.

20. A computer-readable storage medium, characterized in that: Program instructions are stored thereon, and when the program instructions are executed by a computer, the operating system according to any one of claims 1 to 10 is installed on the computer.

Images