Data communication method between hybrid deployment operating systems and industrial control equipment

Abstract

The embodiment of the invention provides a data communication method between hybrid deployment operating systems and industrial control equipment. The method comprises the steps of determining a target NUMA node in alternative NUMA nodes based on addresses of shared memories of a first operating system and a second operating system; wherein the first operating system and the second operating system are deployed on the same industrial control equipment; the target NUMA node is the NUMA node corresponding to the address of the shared memory in the alternative NUMA nodes; and executing data communication between the first operating system and the second operating system through the first processor and the second processor corresponding to the target NUMA node. According to the embodiment of the invention, the target NUMA node can be determined based on the shared memory, then the processor corresponding to the target NUMA node is utilized to perform data communication, and the data transmission path can be limited in the corresponding target NUMA node in the shared memory, so that the communication time delay can be reduced, and the data transmission efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of industrial control technology, and in particular to a data communication method and industrial control equipment for hybrid deployment of operating systems. Background Art

[0002] In industrial operating systems, the hybrid deployment of real-time operating systems (RTOS) and non-real-time operating systems (such as Linux) is a common scenario. In this scenario, the non-real-time and real-time operating systems transmit data through inter-operating system communication interfaces. For example, applications running in the non-real-time operating system send control commands to applications in the real-time operating system domain through the communication interface to control the start, stop, and speed of servo motors; applications in the real-time operating system can return collected I / O data to applications on the non-real-time side through the communication interface.

[0003] In related technologies, non-real-time operating systems, such as Linux, use Linux's default memmap to reserve memory for RTOS, which leads to communication latency issues caused by cross-NUMA access in the current communication path between RTOS and Linux. Summary of the Invention

[0004] This application provides a data communication method and industrial control equipment for hybrid deployed operating systems. It can reduce communication latency between hybrid deployed operating systems.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a data communication method between hybrid deployed operating systems, comprising: determining a target NUMA node from candidate non-consistent memory access NUMA nodes based on the address of shared memory of a first operating system and a second operating system, wherein the first operating system and the second operating system are deployed on the same industrial control device; the first operating system is a non-real-time operating system; the second operating system is a real-time operating system; the target NUMA node is the NUMA node corresponding to the address of shared memory among the candidate NUMA nodes; and performing data communication between the first operating system and the second operating system through a first processor and a second processor corresponding to the target NUMA node.

[0007] Based on this solution, for application scenarios where the first and second operating systems are deployed on the same industrial control equipment, the first operating system first determines the NUMA node corresponding to the shared memory address from the candidate NUMA nodes, i.e., the target NUMA node. Then, it determines the first and second processors corresponding to the target NUMA node, and finally uses the first and second processors to perform data communication between the first and second operating systems. Since each NUMA node in a NUMA system has local memory and a processor, the path for the processor to access local memory (i.e., memory within the same NUMA node) is shorter and does not require traversing interconnect channels between different nodes. Therefore, the communication latency between the first and second operating systems can be reduced.

[0008] In one possible implementation, before data communication between the first operating system and the second operating system is performed via the first processor and the second processor, the method further includes: binding a first thread and the first processor, and binding a second thread and the second processor; wherein the first thread is a thread in the first operating system used to perform communication with the second operating system; and the second thread is a thread in the second operating system used to perform communication with the first operating system.

[0009] Based on this scheme, the first thread and the first processor can be bound together. This allows the first processor to execute the first thread, enabling communication with the second operating system, while avoiding the need to use other processors to execute the first thread. Since the first processor has a faster speed in accessing shared memory, this improves the speed of data communication between the first and second operating systems via shared memory. Similarly, binding the second thread and the second processor improves the speed of data communication between the second and first operating systems via shared memory.

[0010] In another possible implementation, the method also includes adjusting the first thread and the second thread to be processed with priority.

[0011] Based on this scheme, the first and second threads have higher priority. Even if other tasks exist in the system, the processor will prioritize processing the first and second threads. This ensures that the first and second threads are processed in a timely manner, thereby improving the real-time performance of data communication and further reducing communication latency.

[0012] In another possible implementation, before performing data communication between the first operating system and the second operating system through the first and second processors corresponding to the target NUMA node, the method further includes: determining the first processor and the second processor from the target NUMA node.

[0013] Based on this scheme, after determining the target NUMA node, a first processor and a second processor are selected from the target NUMA node to perform data communication tasks between the first and second operating systems. This ensures that data communication occurs within the target NUMA node, fully utilizing the advantages of the NUMA architecture, reducing latency caused by cross-NUMA node access, and thus improving the communication efficiency between the first and second operating systems.

[0014] In another possible implementation, determining the first processor and the second processor from the target NUMA node includes: determining the first processor from the target NUMA node; writing the identification information of the processor corresponding to the target NUMA node into shared memory using the first processor; using the identification information of the processor corresponding to the target NUMA node to indicate the processor corresponding to the target NUMA node; obtaining the third processor running the second operating system; and determining the second processor based on the processor of the target NUMA node and the third processor.

[0015] Based on this scheme, after determining the first processor for the first operating system within the target NUMA node, the first processor writes the identification information of the processor corresponding to the target NUMA node into the shared memory. This allows the second operating system to identify the processor within the target NUMA node based on the identification information when reading the shared memory. Therefore, based on the processor within the target NUMA node and the third processor of the second operating system, the second processor for the second operating system is determined. Subsequently, the second operating system can communicate with the first operating system through the second processor. This ensures that data communication occurs within the target NUMA node, reducing latency caused by cross-NUMA node access.

[0016] In another possible implementation, the second processor is determined based on the processor and the third processor of the target NUMA node, including: determining the second processor from a subset of the processor and the third processor of the target NUMA node.

[0017] Based on this scheme, the intersection of the processor set formed by the processors of the target processor node and the processor set formed by the third processor is calculated, and the second processor is determined within the intersection. This ensures that the second processor is the processor corresponding to the target NUMA node, thus improving data communication speed and reducing communication latency; at the same time, it also ensures that the second processor is the processor of the second operating system, thus enabling the second operating system to successfully execute corresponding tasks through the second processor.

[0018] In another possible implementation, writing the identifier of the processor of the target NUMA node into the shared memory by the first processor includes: writing the target message into the shared memory by the first processor; wherein the target message includes data and the identifier information of the processor of the target NUMA node.

[0019] Based on this scheme, the first processor encapsulates the data and the target NUMA node processor identification information into a target message, and then writes it into shared memory. Thus, when the second operating system reads the target message from shared memory, it can directly parse out the data and the target NUMA node's processor identification information, and then determine the second processor based on the processor's identification information. This simplifies the process of determining the second processor and improves data communication efficiency.

[0020] In another possible implementation, the identifier information of the processor of the target NUMA node is set in the header of the target message.

[0021] Based on this scheme, by setting the identifier information of the target NUMA node's processor in the message header, the second operating system can prioritize identifying the identifier information of the target NUMA node's processor when parsing the target message. In this way, the second operating system can quickly determine the second processor to be used in the second operating system.

[0022] In another possible implementation, the processor identification information of the target NUMA node includes a CPU bitmap; the CPU bitmap is used to indicate the CPU corresponding to the target NUMA node.

[0023] Based on this scheme, the processor identification information of the target NUMA node includes a CPU bitmap, which uses bits to represent the state of each processor in the target NUMA node. In this way, the second operating system can quickly identify the processors in the target NUMA node that are in an available state based on the CPU bitmap, and then determine the second processor from among the available processors.

[0024] Secondly, embodiments of this application also provide a data communication device for hybrid deployed operating systems, the device comprising:

[0025] The NUMA node determination module determines the target NUMA node from among the candidate non-consistent memory access NUMA nodes based on the address of the shared memory of the first operating system and the second operating system; wherein the first operating system and the second operating system are deployed on the same industrial control equipment; the first operating system is a non-real-time operating system; the second operating system is a real-time operating system; the target NUMA node is the NUMA node corresponding to the address of the shared memory among the candidate NUMA nodes; the data communication module is used to perform data communication between the first operating system and the second operating system through the first processor and the second processor corresponding to the target NUMA node.

[0026] Thirdly, embodiments of this application also provide an industrial control device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to invoke the program instructions to cause the industrial control device to perform the method as described in any of the first aspects above.

[0027] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0028] Fifthly, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects.

[0029] It is understood that the beneficial effects that the technical solutions provided in the second to fifth aspects above can achieve can be referred to the beneficial effects in the first aspect and any of its implementation methods, and will not be repeated here. Attached Figure Description

[0030] Figure 1 This is a system architecture diagram of a hybrid operating system provided in an embodiment of this application.

[0031] Figure 2A This is a flowchart of a data communication method between hybrid deployed operating systems provided in an embodiment of this application.

[0032] Figure 2B This is a schematic diagram illustrating the correspondence between memory addresses, NUMA nodes, and CPUs provided in the embodiments of this application.

[0033] Figure 2C This is another flowchart of the data communication method between hybrid deployment operating systems provided in the embodiments of this application.

[0034] Figure 2D This is another flowchart of the data communication method between hybrid deployment operating systems provided in the embodiments of this application.

[0035] Figure 2E This is another flowchart of the data communication method between hybrid deployment operating systems provided in the embodiments of this application.

[0036] Figure 2F This is another flowchart of the data communication method between hybrid deployment operating systems provided in the embodiments of this application.

[0037] Figure 3 This is a communication interaction diagram of the first operating system and the second operating system provided in the embodiments of this application.

[0038] Figure 4 This is another communication interaction diagram of the first operating system and the second operating system provided in the embodiments of this application.

[0039] Figure 5A This is a communication interaction diagram of a system architecture based on a first operating system and a second operating system provided in an embodiment of this application.

[0040] Figure 5B This is another communication interaction diagram of the system architecture based on the first operating system and the second operating system provided in the embodiments of this application.

[0041] Figure 6 This is a schematic diagram of a data communication device between hybrid operating systems provided in an embodiment of this application.

[0042] Figure 7 This is a schematic diagram of an industrial control device provided in an embodiment of this application. DETAILED DESCRIPTION

[0043] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0044] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0045] Hybrid operating system deployment: refers to running multiple different types of operating systems on the same hardware platform. For example, a server may run both a non-real-time operating system and a real-time operating system simultaneously.

[0046] Communication latency: The time required for information to travel from the sending end to the receiving end during transmission. In inter-operating system communication, latency is mainly determined by factors such as hardware interfaces and network transmission.

[0047] Non-uniform memory access (NUMA) is a memory design used in multiprocessor computers. In NUMA systems, processors can access local memory faster, while accessing remote memory takes longer.

[0048] Shared memory: A segment of memory allocated by the operating system that can be accessed by different processors (hereinafter referred to as CPUs). It can be used for inter-process communication within a program, and multiple programs can also exchange information through shared memory.

[0049] Central processing unit bitmap (CPU bitmap): A data structure used to represent CPU usage. Each bit corresponds to a CPU; if a bit is set, it indicates that the corresponding CPU is being used.

[0050] Core binding: This involves binding a specific thread or process to a specific CPU to run on. This avoids frequent switching between different CPUs, improving system performance.

[0051] Scheduling priority: In an operating system, the execution order of threads or processes is determined by their scheduling priority. Threads or processes with higher priority will be executed first.

[0052] The following is combined Figure 1 This example illustrates a hybrid deployment of operating systems.

[0053] Figure 1 This is a system architecture diagram of a hybrid operating system provided in an embodiment of this application.

[0054] like Figure 1As shown, the industrial control equipment deploys two operating systems: a non-real-time domain operating system (hereinafter referred to as the first operating system) and a real-time domain operating system (hereinafter referred to as the second operating system). The industrial control equipment can be a server, workstation, etc.; the first operating system can be a non-real-time operating system, such as Linux, on which target applications, such as industrial applications, can be deployed to control the start, stop, and operation of the industrial equipment; the second operating system can be a real-time operating system on which real-time side applications can be deployed to achieve real-time monitoring and rapid response of the industrial equipment. A hybrid service process runs within the first operating system. A hybrid service process is a service process that runs different types of operating systems simultaneously within the same industrial control equipment, enabling the first and second operating systems to work collaboratively. For example, the first operating system can send adjustment parameters to the second operating system. After receiving the adjustment parameters, the second operating system can adjust the parameters of the industrial equipment through industrial applications. Furthermore, the second operating system can monitor the adjusted equipment operating status in real time and send the equipment operating status data back to the first operating system.

[0055] It should be noted that, Figure 1 Taking the deployment of two operating systems in industrial control equipment as an example, in some implementations, more operating systems can be deployed in industrial control equipment, such as one primary operating system and two secondary operating systems.

[0056] The following, with reference to the accompanying drawings, illustrates the process of a data communication method between hybrid operating systems.

[0057] First, combined Figures 2A to 2F The following is an example illustrating the flow of a data communication method between hybrid operating systems applied to a first operating system.

[0058] Figure 2A This is a flowchart of a data communication method between hybrid deployed operating systems provided in an embodiment of this application.

[0059] like Figure 2A As shown, this embodiment includes the following steps S11-S12:

[0060] S11: Based on the shared memory address of the first and second operating systems, determine the target NUMA node from the candidate non-uniform memory access NUMA nodes.

[0061] In step S11, both the first operating system and the second operating system are deployed on the same industrial control device, wherein the first operating system is a non-real-time operating system, and the second operating system is a real-time operating system. When the second operating system starts, the industrial control device reserves a segment of memory for the second operating system, which is the shared memory in this embodiment.

[0062] Considering that industrial control equipment allocates memory addresses to NUMA nodes, there is a certain correspondence between memory addresses and NUMA nodes; that is, each NUMA node corresponds to a range of memory addresses. Based on this, the first operating system can determine the NUMA node corresponding to the shared memory address from at least one candidate NUMA node in the industrial control equipment, based on the correspondence between memory addresses and NUMA nodes, and use it as the target NUMA node.

[0063] The following is combined Figure 2B This example illustrates the process of determining the target NUMA node based on the correspondence between memory addresses and NUMA nodes.

[0064] Figure 2B This is a schematic diagram illustrating the correspondence between memory addresses, NUMA nodes, and CPUs provided in the embodiments of this application.

[0065] like Figure 2B As shown, the industrial control equipment allocates memory addresses 0x00000000-0x3FFFFFFF to NUMA node 0, memory addresses 0x40000000-0x7FFFFFFF to NUMA node 1, memory addresses 0x80000000-0xBFFFFFFF to NUMA node 2 (not shown in the figure), and memory addresses 0xC0000000-0xFFFFFFFF to NUMA node 3. Thus, if the shared memory address is 0x40000000-0x7FFFFFFF, the first operating system can determine NUMA node 1 as the target NUMA node.

[0066] In one embodiment, the shared memory address can be obtained through a first interface.

[0067] The first interface is the data transmission interface corresponding to the target application in the first operating system. Specifically, the first interface interfaces with the management platform corresponding to the target application to realize data transmission between the target application and the management platform. For example, in the case of an industrial application, the first interface can be used to realize data transmission between the industrial application and the manufacturing execution system (MES), such as transmitting real-time status and task logs of industrial equipment to the MES system.

[0068] In this embodiment, the first operating system can obtain the shared memory address through the first interface. Specifically, when the first operating system needs to obtain the shared memory address, it can send an address acquisition request to the first interface, and the first interface responds to the address acquisition request by obtaining the shared memory address from the kernel of the first operating system.

[0069] It's understandable that in practical applications, shared memory is reserved using physical addresses, while the target application typically only operates on virtual memory addresses. Based on this, the target application maps the reserved physical memory address of the shared memory to the virtual memory address and returns the target NUMA node corresponding to that virtual address. In this way, the first operating system inputs the physical memory address into a pre-designed interface function to obtain the target NUMA node corresponding to the virtual memory address, and then uses the target NUMA node to obtain the target CPU in subsequent steps.

[0070] Figure 2C This is another flowchart of the data communication method between hybrid deployment operating systems provided in the embodiments of this application.

[0071] like Figure 2C As shown, in one embodiment, after step S11, step S13 can be executed first, followed by step S12:

[0072] S13: Determine the first and second processors from the target NUMA node.

[0073] In step S13, considering that the target NUMA node can correspond to multiple processors, in order to improve communication efficiency, two processors need to be selected from the target NUMA node as the first processor and the second processor, respectively, to perform communication operations in subsequent steps.

[0074] In this embodiment, step S13, after determining the target NUMA node, selects a first processor and a second processor from the target NUMA node to execute the data communication task between the first operating system and the second operating system. This ensures that data communication occurs within the target NUMA node, fully utilizing the advantages of the NUMA architecture, reducing latency caused by cross-NUMA node access, and thus improving the communication efficiency between the first operating system and the second operating system.

[0075] The following is combined Figure 2D Step S13 will be further described below.

[0076] Figure 2D This is another flowchart of the data communication method between hybrid deployment operating systems provided in the embodiments of this application.

[0077] like Figure 2D As shown, in one embodiment, step S13 includes the following steps S131-S134:

[0078] S131, determine the first processor from the target NUMA node.

[0079] In step S131, considering that industrial control equipment allocates multiple processors to each NUMA node, there is a certain correspondence between NUMA nodes and processors; that is, each NUMA corresponds to at least one processor. Based on this, the first operating system can determine the first processor from the target NUMA based on the correspondence between NUMA nodes and processors. Specifically, it determines the first processor from at least one processor corresponding to the target NUMA node. The processor can be a CPU.

[0080] The following is combined Figure 2B This example illustrates the process of determining the first processor based on the correspondence between NUMA nodes and CPUs.

[0081] Please refer to the above. Figure 2B ,like Figure 2B As shown, the industrial control equipment assigns CPU0-CPU31 to NUMA node 0, CPU32-CPU63 to NUMA node 1, CPU64-CPU95 to NUMA node 2 (not shown in the figure), and CPU96-CPU127 to NUMA node 3. In this way, the first operating system can determine the multiple CPUs corresponding to the target NUMA node, including CPU32-CPU63, and then determine the first CPU among CPU32-CPU63; for example, CPU33 can be determined as the first CPU.

[0082] Furthermore, if the shared memory address is a virtual memory address, the first operating system can call a pre-set interface function through the first interface to obtain the processor corresponding to the target NUMA node. Specifically, the first operating system inputs the virtual memory address into the interface function, and in addition to obtaining the target NUMA node corresponding to the virtual memory address, it also obtains at least one processor corresponding to the target NUMA node.

[0083] S132: The first processor writes the identification information of the processor corresponding to the target NUMA node into the shared memory.

[0084] In step S132, the first operating system, through the first processor, writes the identification information of the processor corresponding to the target NUMA node into shared memory. This identification information indicates the processor corresponding to the target NUMA node. In this way, the second operating system can retrieve this identification information from the shared memory and select a second processor from the processors corresponding to the target NUMA node indicated by the identification information, thereby using the second processor to perform data communication with the first operating system.

[0085] The second processor can be a different processor than the first processor. Specifically, before sending the identification information of the processor corresponding to the target NUMA node to the second operating system, the first operating system can remove the first processor from the list of processors corresponding to the target NUMA node. In this way, the processor indicated by the identification information does not include the first processor, which can prevent the second operating system from identifying the first processor as the second processor, thus ensuring that the second processor is different from the first processor.

[0086] Please refer to the above. Figure 2B ,like Figure 2B As shown, the target NUMA node corresponds to multiple target CPUs including CPU32-CPU63, and the first operating system identifies CPU33 as the first processor. In this case, the identification information can indicate CPU32 and CPUs34-CPU63, but not CPU33.

[0087] Step S132 is described in detail below.

[0088] In one embodiment, step S132 includes the following steps:

[0089] The target message is written to shared memory via the first processor.

[0090] In this embodiment, the first operating system writes the target message into shared memory through the first processor. In this way, the second operating system can read the target message from the shared memory, and then obtain the processor of the target NUMA node based on the target message, and determine the second processor.

[0091] The target message includes data and identification information of the processor of the target NUMA node. The data can be data to be transmitted from the first operating system to the second operating system. Thus, when the first operating system sends data to the second operating system for the first time, it can encapsulate the data to be sent along with the identification information into a target message and write it to shared memory. The second operating system can then read the target message from shared memory, determine the second processor based on the information in the target message, and execute it during subsequent data communication. In some embodiments, the data and the identification information of the target NUMA node's processor can be stored in different fields. For example, the target message may include a data field and an identification information field, where the data field stores the data and the identification information field stores the identification information of the target NUMA node's processor. Thus, when the second operating system reads the target message, it can parse the data field and the identification information field to obtain the data and the identification information of the target NUMA node's processor, respectively.

[0092] In another embodiment, the target data may also include only the identification information of the processor of the target NUMA node.

[0093] In one embodiment, the identification information of the processor of the target NUMA node is set in the header of the target message.

[0094] In this embodiment, the identification information is set in the header of the target message (hereinafter referred to as the message header), and the data is set in the message body. The second operating system does not need to read the entire message body; it only needs to parse the message header to obtain the identification information of the processor of the target NUMA node. In this way, after determining the second processor based on the identification information, the second operating system can use the second processor to read the data in the message body. Therefore, this not only facilitates the second operating system to quickly determine the second processor but also enables it to use the second processor to read data, improving the efficiency of data communication.

[0095] In one embodiment, the identification information of the processor of the target NUMA node includes a central processing unit (CPU) bitmap; the CPU bitmap is used to indicate the CPU corresponding to the target NUMA node.

[0096] In this embodiment, the target message may include a CPU bitmap, which can be used to indicate the CPU corresponding to the target NUMA node. Specifically, the first operating system uses the status bits of each CPU in the CPU bitmap to indicate the CPUs in an available state corresponding to the target NUMA node. For example, regarding the aforementioned... Figure 2B In the illustrated embodiment, the CPU bitmap may include CPUs 32-63, where CPU 33 has a status position of 1, and CPUs 32 and 34-63 have status positions of 0. Thus, the CPU bitmap can indicate the CPUs 32-63 corresponding to the target NUMA node, and can indicate that CPUs 32 and 34-63 are in an available state, while CPU 33 is in an unavailable state. Based on the information indicated by the CPU bitmap, the second operating system can select a second processor from CPUs 32 and 34-63 with status positions of 0, such as selecting CPU 63 as the second processor.

[0097] It is understood that in other embodiments, the status bits of CPU33, CPU32 and CPU34-CPU63 may also be set to other values, such as the status bit of CPU33 being set to 0 and the status bit of CPU32 and CPU34-CPU63 being set to 1.

[0098] In this embodiment, the second operating system can quickly identify the processors in the target NUMA node that are in an available state based on the CPU bitmap, and then determine the second processor from among the available processors. This avoids the second operating system misidentifying the first processor as the second processor, thus preventing the second and first operating systems from using the same processor for data communication. Compared to using the same processor, this embodiment utilizes the first and second processors respectively to perform data write and read operations from the first and second operating systems to shared memory, improving the parallelism of data transmission, thereby increasing the communication efficiency between the first and second operating systems and improving system performance.

[0099] S133, acquire a third processor running the second operating system.

[0100] In step S133, when the second operating system starts, the industrial control equipment reserves multiple processors for the second operating system, namely the third processors in this embodiment, so that the second operating system can use the third processors to perform various tasks. In some embodiments, the multiple third processors may correspond to different NUMA nodes, so that no matter which NUMA node the first operating system determines as the target NUMA node, the second operating system can find the third processor corresponding to the target NUMA node. That is, the third processor includes at least one processor corresponding to the target NUMA node. The number and performance of the third processors can be determined according to the needs of the second operating system and the configuration of the industrial control equipment.

[0101] S134: Determine the second processor based on the processor and the third processor of the target NUMA node.

[0102] In step S134, to improve the data communication speed between the second operating system and the first operating system, the second processor can be one of the processors in the target NUMA node; to ensure that the second operating system can utilize the second processor to perform data communication operations, the second processor can be a processor reserved for the second operating system by the industrial control equipment, that is, the second processor can be one of the third processors. Based on this, the second processor can be determined according to the processor of the target NUMA node and the third processor.

[0103] In this embodiment, after determining the first processor for the first operating system in the target NUMA node through steps S131-S134, the first processor writes the identification information of the processor corresponding to the target NUMA node into the shared memory. This allows the second operating system to identify the processor within the target NUMA node based on the identification information when reading the shared memory. Based on the processor within the target NUMA node and the third processor of the second operating system, the second processor for the second operating system is then determined. Subsequently, the second operating system can communicate with the first operating system through the second processor. This ensures that data communication occurs within the target NUMA node, reducing latency caused by cross-NUMA node access.

[0104] Step S134 is described in detail below.

[0105] In one embodiment, step S134 includes the following steps:

[0106] The second processor is determined from the subset of the processors in the target NUMA node and the third processor.

[0107] In this embodiment, a first set of processors forming a target NUMA node and a second set of processors forming a third set can be determined, and then a second processor can be determined from the intersection of the first set and the second set.

[0108] For example, if the processors of the target NUMA node form a first set {CPU32, CPU34, CPU35, CPU36, ..., CPU63}, and the third processors form a second set {CPU30, CPU31, CPU62, CPU63, CPU94, CPU95, CPU136, CPU137}, then the second operating system can determine the second processor from the intersection of the first set and the second set {CPU62, CPU63}. For example, CPU63 can be determined as the second processor.

[0109] The embodiments of this application can ensure that the second processor is the processor corresponding to the target NUMA node, thus improving the speed of data communication and reducing communication latency; at the same time, it can also ensure that the second processor is the processor of the second operating system, thus enabling the second operating system to successfully execute the corresponding tasks through the second processor.

[0110] Figure 2E This is another flowchart of the data communication method between hybrid deployment operating systems provided in the embodiments of this application.

[0111] like Figure 2E As shown, in one embodiment, after step S11, step S14 can be executed first, followed by step S12:

[0112] S14: Bind the first thread and the first processor, and bind the second thread and the second processor.

[0113] In step S14, during the data communication process between the first operating system and the second operating system, in order to improve the data communication speed, the first operating system can perform data access operations for shared memory through the first processor.

[0114] It's understandable that determining the target NUMA node and then the first processor based on the shared memory address before each data communication operation is cumbersome and inefficient. Therefore, the first thread and the first processor can be bound together. This way, during data communication, the first thread can directly perform data read and write operations through the first processor.

[0115] In this context, the first thread is a thread within a mixed-deployment service process, which is a service process that runs different types of operating systems simultaneously within the same industrial control device. The first thread resides within the first operating system and is used to perform communication with the second operating system, specifically for data access between the first operating system and shared memory. In one embodiment, the first thread may be a process.

[0116] In this embodiment, step S14 binds the first thread and the first processor, allowing the first processor to execute the first thread and enable communication with the second operating system, thus avoiding the need for other processors to execute the first thread. Since the first processor accesses shared memory faster, this improves the speed of data communication between the first and second operating systems via shared content. Similarly, binding the second thread and the second processor improves the speed of data communication between the second and first operating systems via shared memory.

[0117] In one implementation, the specific steps for binding the first thread and the first target processor are as follows: create the first thread and determine the default processor that has a mapping relationship with the first thread, wherein the default processor is the processor in the industrial control equipment; if the default processor is the same as the first processor, then bind the first thread and the default processor based on the mapping relationship, otherwise bind the first thread and the first processor.

[0118] In this implementation, the first operating system pre-assigns a corresponding default processor to each thread. Thus, after determining the first processor corresponding to the first thread, it can determine whether the first processor is the same as the default processor based on the mapping relationship between the first thread and the default processor. If they are the same, a core binding operation is performed based on the mapping relationship; if they are different, the mapping relationship is updated, and a core binding operation is performed based on the updated mapping relationship to bind the first thread and the first processor.

[0119] Similarly, a second thread and a second processor can also be bound. This second thread is also a thread within the mixed-service process. The second thread runs in a second operating system and is used to perform communication with the first operating system, specifically to perform data access between the second operating system and shared memory. In one embodiment, the second thread can be a process.

[0120] It should be noted that the embodiments in this application only illustrate the case where the second operating system has one real-time application communicating with the first operating system. In other embodiments, the second operating system may have multiple real-time applications communicating with the first operating system. In this case, a second processor can be determined for each real-time application, and a second thread can be created, thereby binding the second thread to the second processor.

[0121] In one embodiment, after creating the first and second threads, their priority relative to other threads can be increased. This prioritizes the first and second threads, ensuring they are processed promptly, thereby improving the real-time performance of data communication between the first and second operating systems and further reducing communication latency.

[0122] It can be understood that, in one embodiment, after step S11, steps S13 and S14 may be executed sequentially, and then step S12 may be executed.

[0123] S12: Perform data communication between the first operating system and the second operating system through the first and second processors corresponding to the target NUMA node.

[0124] In step S12, the first operating system and the second operating system perform data communication operations through the first processor and the second processor mentioned in the preceding steps. Specifically, either operating system writes the data to be transmitted into shared memory, and the other operating system reads the data to be transmitted from the shared memory, thereby realizing data communication between the two operating systems.

[0125] In this embodiment, steps S11-S12 utilize a first processor and a second processor corresponding to the target NUMA node to perform data communication between the first operating system and the second operating system. At this time, the first and second processors correspond to the target NUMA node, which is an NUMA node corresponding to a shared memory address. Since each NUMA node in a NUMA system has local memory and a processor, the path for a processor to access local memory (i.e., memory within the same NUMA node) is shorter and does not require traversing interconnect channels between different nodes. Therefore, when the first and second processors access the shared memory within the target NUMA node, the data transmission distance and intermediate steps can be reduced, thereby reducing memory access latency and significantly improving the data communication speed between the first and second operating systems.

[0126] The following is combined Figure 2F Step S12 will be further described below.

[0127] Figure 2F This is another flowchart of the data communication method between hybrid deployment operating systems provided in the embodiments of this application.

[0128] like Figure 2F As shown, in one embodiment, step S12 specifically includes the following steps S121-S125:

[0129] S121, the first operating system writes the first data into the shared memory through the first processor.

[0130] In step S121, the first operating system can write the first data to be transferred into shared memory through the first processor, so that the second operating system can read the first data from the shared memory. Specifically, after performing a core binding operation on the first thread and the first processor, the first operating system can use the first processor to run the first thread and write the first data into shared memory.

[0131] The first data can be control commands output by the target application, used to control the start, stop, and operation of industrial equipment. For example, the first data can be a robotic arm posture control command output by the target application. The first operating system uses the first processor to write the first data into shared memory. In this way, the second operating system can read the first data from the shared memory and perform corresponding operations based on the first data, such as adjusting the posture of the robotic arm according to the robotic arm posture control command.

[0132] In this embodiment, the first operating system includes a second interface, which is a data transmission interface corresponding to the first thread. Since the first thread is used to perform data communication between the first and second operating systems, the first interface can serve as a data transmission channel between them. Specifically, first data in the first operating system can be transmitted to shared memory through the first interface.

[0133] Based on this, in some implementations, a core-binding processing flow can be integrated into the second interface, and then the first data can be bound to the first processor using the core-binding processing flow so that the first processor can process the first data. Specifically, the first data is written to shared memory through the second interface.

[0134] S122: The second operating system reads the first data from the shared memory through the second processor.

[0135] In step S122, the second operating system reads the first data written by the first operating system from the shared memory via the second processor. Specifically, after performing a core binding operation on the second thread and the second processor, the second operating system can use the second processor to run the second thread and read the first data from the shared memory.

[0136] In this embodiment, steps S121-S122 involve using a first processor to write data to shared memory and a second processor to read data from shared memory. This shortens the data writing and reading times, improving data transmission efficiency. In this way, the first operating system can quickly send control commands and other first data to the second operating system, enabling the second operating system to control the industrial equipment promptly, thereby achieving precise control and efficient management of the industrial equipment.

[0137] In this embodiment, the second operating system includes a third interface, which is a data transmission interface corresponding to the second thread. Since the second thread is used to perform data communication between the second and first operating systems, the third interface can serve as a data transmission channel between them. Specifically, the second operating system can read data from shared memory through the third interface.

[0138] Based on this, in some embodiments, a core-binding processing flow can also be integrated into the third interface, and then the first data can be bound to the second processor using the core-binding processing flow so that the second processor can process the second data. Specifically, the second data is read from the shared memory and transmitted to the second system through the third interface.

[0139] S123: The second operating system generates the second data based on the first data.

[0140] In step S123, the second operating system generates second data based on the first data. Specifically, the second operating system can parse the first data to obtain its specific content, and then perform corresponding operations based on the specific content of the first data to generate the second data.

[0141] The second data can be data corresponding to the first data. For example, if the first data is a robotic arm posture control command, the second operating system can parse the first data, then execute the robotic arm posture adjustment operation according to the robotic arm posture control command, and generate the current posture information of the robotic arm based on the adjusted robotic arm posture, as the second data.

[0142] S124: The second operating system writes the second data into the shared memory through the second processor.

[0143] For a detailed explanation of step S124, please refer to step S121 above, which will not be repeated here.

[0144] Furthermore, in some embodiments, the second operating system can write the second data into the shared memory via a third interface.

[0145] S125: The first operating system reads second data from shared memory through the first processor.

[0146] In step S125, after the second operating system writes the second data to the shared memory, the first operating system uses the first processor to read the second data written by the second operating system from the shared memory. The specific process of reading the second data is detailed in step S122 above and will not be repeated here.

[0147] In this embodiment of the application, through steps S124-S125, the first operating system can quickly receive the second data sent by the second operating system, so that the first operating system can respond in a timely manner based on the second data, thereby realizing precise control and efficient management of industrial equipment.

[0148] Finally, combine Figure 3 Figure 5 illustrates, from the perspective of system interaction, the communication process between the first operating system and the second operating system based on the data communication method between the hybrid deployed operating systems.

[0149] Figure 3 This is a communication interaction diagram of the first operating system and the second operating system provided in the embodiments of this application.

[0150] like Figure 3 As shown, when the first operating system and the second operating system communicate based on the data communication method between hybrid deployed operating systems, the following steps are performed:

[0151] Step S301: The first operating system determines the target NUMA node from the candidate NUMA nodes based on the shared memory address of the first operating system and the second operating system.

[0152] Step S302: The first operating system determines the first processor in the target NUMA node.

[0153] Step S303: The first operating system writes the target message into the shared memory through the first processor, wherein the target message includes first data and the identification information of the processor of the target NUMA node.

[0154] Step S304: The second operating system reads the identification information from the shared memory.

[0155] Step S305: Determine the third processor of the second operating system.

[0156] Step S306: Determine the second processor based on the third processor and the processor of the target NUMA node.

[0157] Step S307: The second operating system reads the first data from the shared memory through the second processor.

[0158] Step S308: The second operating system generates second data based on the first data.

[0159] Step S309: The second operating system writes second data into the shared memory through the second processor.

[0160] For a detailed explanation of steps S301-S309, please refer to the foregoing embodiments, which will not be repeated here.

[0161] Figure 4 This is another communication interaction diagram of the first operating system and the second operating system provided in the embodiments of this application.

[0162] Figure 5A This is a communication interaction diagram of a system architecture based on a first operating system and a second operating system provided in an embodiment of this application.

[0163] like Figure 4 As shown, when the first operating system and the second operating system communicate based on the data communication method between hybrid deployed operating systems, the following steps are performed:

[0164] Step S401: The first operating system obtains the shared memory address through the first interface.

[0165] Step S402: The first operating system determines the target NUMA node from the candidate NUMA nodes based on the shared memory address of the first operating system and the second operating system.

[0166] Please see Figure 5A The target application is deployed in the first operating system. The first interface is the data transmission interface corresponding to the target application, used to realize data transmission between the target application and the management platform. When the shared memory address is a virtual memory address, the first interface calls the interface function in the kernel driver, inputting the virtual memory address into the interface function, and obtains the target NUMA node corresponding to the virtual memory address output by the interface function. Figure 5A NMUA node 1.

[0167] Step S403: The first operating system determines the first processor in the processor of the target NUMA node.

[0168] Please see Figure 5A When the shared memory address is a virtual memory address, the first interface calls the interface function in the kernel driver, inputs the virtual memory address into the interface function, and can also obtain the processor of the target NUMA node output by the interface function, which is... Figure 5A CPU32-CPU63. Thus, the first operating system determines the first processor (CPU32-CPU63) within the target MNUA node 1. Figure 5A CPU33.

[0169] Step S404: Bind the first thread and the first processor.

[0170] Please see Figure 5A The first operating system creates a first thread for performing data communication between the first and second operating systems, and binds the first thread to the first processor (CPU33). In this way, the core binding process can be integrated into the second interface corresponding to the first thread, and then the first data can be bound to the first processor (CPU33) using the core binding process, so that the first processor (CPU33) can write the first data to shared memory.

[0171] Furthermore, the first operating system can also create a third thread (not shown in the figure) for performing data communication between the target application and the management platform corresponding to the target application, and bind the third thread to the third processor (CPU32). In this way, the core binding process can be integrated into the first interface corresponding to the third thread, and then the core binding process can be used to bind the data to be transmitted by the third thread to the third processor (CPU32), so that the third processor (CPU32) can be used to perform data transmission between the target application and the management platform.

[0172] Step S405: With the first thread and the first target processor bound together, the first operating system uses the first target processor to write the first data transmitted through the first interface into the shared memory.

[0173] Please see Figure 5A The first data may include data generated by the target application, such as... Figure 5A The first data may include data acquisition instructions generated by the target application's data acquisition thread and / or motor control thread. For example, the first data may include data acquisition instructions generated by the target application's data acquisition thread.

[0174] Step S406: The first operating system writes the identification information into the shared memory.

[0175] Please see Figure 5A After binding the first thread to the first processor (CPU33) and the third thread to the third processor (CPU32), the first operating system can send identification information of the processor of the target NUMA node to the second operating system. The identification information can indicate the processor of the target NUMA node other than the first processor (CPU33) and the third processor (CPU32), namely CPU34-CPU63.

[0176] In some embodiments, the first data and identification information can be encapsulated into a target message, and the first operating system can write the target message into shared memory. For example, the identification information can be encapsulated in the message header of the target message, and the first data can be encapsulated in the message body of the target message. In this way, the second operating system only needs to read the message header to determine the processor of the target NUMA node indicated by the identification information, and after determining the second processor, it can read the first data in the message body through the second processor.

[0177] Step S407: The second operating system reads the identification information from the shared memory.

[0178] Step S408: The second operating system determines the second target processor based on the third processor of the second operating system and the processor of the target NUMA node indicated by the identification information.

[0179] Please see Figure 5A After receiving the target message instructing CPU34-CPU63, the second operating system determines the second processor within CPU34-CPU63 based on the third processor of the second operating system. Figure 5A CPU63.

[0180] Step S409: The second operating system creates a second thread and binds the second thread to the second processor.

[0181] Please see Figure 5AThe second operating system creates a second thread for performing data communication between the second operating system and the first operating system, and binds the second thread to the second processor (CPU63). In this way, a core-binding process can be integrated into the third interface corresponding to the second thread. Then, using the core-binding process, after determining that the first data will be read through the third interface, the first data is bound to the second processor (CPU63), so that the second processor (CPU63) can read the first data from shared memory to the second operating system through the third interface.

[0182] S410: When the second thread and the second processor are bound together, the second operating system responds to the first operating system writing the first data into the shared memory, and uses the second processor to read the first data from the shared memory through the third interface.

[0183] Step S411: The second operating system generates second data based on the first data.

[0184] Please see Figure 5A The second operating system transmits the first data to the real-time application. The real-time application can parse the first data, obtain the specific content in the first data, and then perform corresponding operations based on the specific content in the first data to generate the second data.

[0185] Step S412: With the second thread and the second target processor bound together, the second operating system writes the second data into the shared memory through the second processor.

[0186] Please see Figure 5A The second operating system writes the second data to shared memory via the third interface through the second processor (CPU63) bound to the second thread.

[0187] Step S413: When the first thread and the first processor are bound together, the first operating system responds to the second operating system writing second data into the shared memory, and uses the first processor to read the second data from the shared memory through the first interface.

[0188] Please see Figure 5A The first operating system uses the first processor (CPU33) bound to the first thread to read the second data from shared memory and then reads the second data into the first system via the second interface.

[0189] It should be noted that the aforementioned Figure 5A The illustrated embodiment only illustrates the deployment of two operating systems in an industrial control device. In some implementations, more operating systems can be deployed in the industrial control device, such as one first operating system and two second operating systems.

[0190] The following is combined Figure 5BThis paper introduces the communication process between the first operating system and the second operating system based on a data communication method between the hybrid operating systems in an industrial control device with one first operating system and two second operating systems deployed.

[0191] Figure 5B This is another communication interaction diagram of the system architecture based on the first operating system and the second operating system provided in the embodiments of this application.

[0192] like Figure 5B As shown, a second operating system a and a second operating system b are deployed simultaneously in the industrial control equipment, and both second operating systems a and b communicate with the first operating system. In this case, the method described in the previous embodiments can be executed on the first and second operating systems a to achieve communication between them; the method described in the previous embodiments can also be executed on the first and second operating systems b to achieve communication between them.

[0193] Specifically, the method described in the foregoing embodiments can be executed on the first operating system and the second operating system a. In this way, the first operating system determines a first processor a (i.e., ...) for data transfer with the second operating system a. Figure 5B The first operating system can bind the first thread a to CPU 33, and then use CPU 33 to write the first data a transmitted through the second interface a into shared memory a. The second operating system a determines the second processor a (i.e., CPU 33) based on the target message a sent by the first operating system. Figure 5B CPU63 is used to bind the second thread a to CPU63, and then CPU63 is used to read the first data a from shared memory a through the third interface a.

[0194] The method described in the foregoing embodiments can be executed on the first operating system and the second operating system b. The specific method is similar to that in the foregoing embodiments, except that the second processor a corresponding to the second operating system a and the second processor b corresponding to the second operating system b are different second target CPUs. For example, the second operating system b can determine that CPU 62 (not shown in the figure) is the second processor b based on the target message b sent by the first operating system.

[0195] To ensure that the second operating system a and the second operating system b correspond to different second processors, either second operating system can send a message to the first operating system after determining the second processor. This allows the first operating system to generate a target message to be sent to the other second operating system based on the message sent by either second operating system. For example, if second operating system a determines that CPU 63 is the second processor a, it can send a message to the first operating system informing it that CPU 63 is already in use. In this way, the first operating system can generate a target message b to be sent to the second operating system b, and the processor identification information of the target NUMA node contained in the target message b will not indicate CPU 63. For example, in the CPU bitmap contained in the target message b, the status bit of CPU 63 will be set to 1.

[0196] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention. For example, the steps described in the above embodiments can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in the present invention can be achieved, the present invention does not limit this.

[0197] Corresponding to the aforementioned embodiments of the data communication method between hybrid operating systems, this application also provides embodiments of a data communication apparatus between hybrid operating systems.

[0198] Figure 6 This is a schematic diagram of a data communication device between hybrid operating systems provided in an embodiment of this application.

[0199] like Figure 6 As shown, the data communication device 600 between the hybrid deployment operating systems is applied to the first operating system and may include a NUMA node determination module 610 and a data communication module 620.

[0200] The NUMA node determination module 610 determines the target NUMA node from among the candidate non-consistent memory access NUMA nodes based on the address of the shared memory of the first operating system and the second operating system; wherein the first operating system and the second operating system are deployed on the same industrial control equipment; the first operating system is a non-real-time operating system; the second operating system is a real-time operating system; and the target NUMA node is the NUMA node corresponding to the address of the shared memory among the candidate NUMA nodes.

[0201] The data communication module 620 is used to perform data communication between the first operating system and the second operating system through the first processor and the second processor corresponding to the target NUMA node.

[0202] In one possible implementation, the data communication device 600 for hybrid deployment of operating systems further includes a core-binding module for binding a first thread and a first processor, and binding a second thread and a second processor; wherein the first thread is a thread in the first operating system used to perform communication with the second operating system; and the second thread is a thread in the second operating system used to perform communication with the first operating system.

[0203] In one possible implementation, the data communication device 600 between the hybrid operating systems further includes a scheduling module for adjusting the priority of the first thread and the second thread to be processed first.

[0204] In one possible implementation, the data communication device 600 for hybrid deployment of operating systems further includes a processor determination module for determining a first processor and a second processor from the target NUMA node.

[0205] In one possible implementation, the processor determination module is used to: determine a first processor from the target NUMA node; write the identification information of the processor corresponding to the target NUMA node into shared memory using the first processor; use the identification information of the processor corresponding to the target NUMA node to indicate the processor corresponding to the target NUMA node; obtain a third processor running a second operating system; and determine a second processor based on the processor of the target NUMA node and the third processor.

[0206] In one possible implementation, the processor determination module is used to determine a second processor from a subset of the processors and the third processor of the target NUMA node.

[0207] In one possible implementation, the processor determination module is used to write a target message into shared memory via a first processor; wherein the target message includes data and identification information of the processor of the target NUMA node.

[0208] In one possible implementation, the identification information of the processor of the target NUMA node is set in the header of the target message.

[0209] In one possible implementation, the processor identification information of the target NUMA node includes a central processing unit (CPU) bitmap; the CPU bitmap is used to indicate the CPU corresponding to the target NUMA node.

[0210] Figure 7 This is a schematic diagram of an industrial control device provided in an embodiment of this application.

[0211] like Figure 7As shown, the industrial control device 700 includes a processor 701 and a memory 702. Exemplarily, the industrial control device 700 may also include a communications interface 703 and a communications bus 704.

[0212] Among them, industrial control equipment 700 can be servers, such as rack servers, high-density servers, AI servers, and full rack servers.

[0213] The processor 701, memory 702, and communication interface 703 communicate with each other via communication bus 704. The communication interface 703 may include a transmitter and receiver for communicating with other devices or communication networks, and may be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0214] In some embodiments, the processor 701 is used to execute program 705, which specifically performs the relevant steps in the above method embodiments. Specifically, program 705 may include program code, which includes computer-executable instructions.

[0215] For example, processor 701 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Industrial control device 700 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0216] In some embodiments, memory 702 is used to store program 705. Memory 702 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0217] Specifically, program 705 can be called by processor 701 to enable industrial control device 700 to perform inference task execution method operations.

[0218] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on an industrial control device 700, causes the industrial control device 700 to perform the data communication method between hybrid deployed operating systems described in the above embodiments.

[0219] The executable instructions can be used to enable the industrial control equipment 700 to perform data communication methods between hybrid deployed operating systems.

[0220] For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0221] Some embodiments of this application provide a chip device applied to a server. The chip device includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits are used to receive signals from the server's memory and send signals to the processors, the signals including computer instructions stored in the memory. When the server processor executes the computer instructions, the server performs various steps in the data communication method between hybrid deployed operating systems shown in the above-described method embodiments.

[0222] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects in the corresponding data communication method between hybrid deployment operating systems provided above, and will not be repeated here.

[0223] It should be noted that in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0224] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0225] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution apparatus, device, or equipment (such as a computer-based device, a processor-included device, or other device that can fetch and execute instructions from, an instruction execution apparatus, device, or equipment).

[0226] For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by or in conjunction with an instruction execution means, apparatus, or device.

[0227] More specific examples (a non-exhaustive list) of computer-readable media include the following: electrical connections having one or more wires (electronic devices), portable computer disks (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM).

[0228] Furthermore, the computer-readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory. It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof.

[0229] In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution device. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc. The embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of this application should be included within the scope of protection of this application.

Claims

1. A method for data communication between hybrid deployed operating systems, characterized in that, The method includes: Based on the addresses of shared memory between the first and second operating systems, the target NUMA node is determined from the candidate non-uniform memory access NUMA nodes. The first operating system and the second operating system are deployed on the same industrial control equipment; the first operating system is a non-real-time operating system; the second operating system is a real-time operating system; the target NUMA node is the NUMA node corresponding to the address of the shared memory among the candidate NUMA nodes; The first and second processors corresponding to the target NUMA node perform data communication between the first operating system and the second operating system.

2. The method according to claim 1, characterized in that, Before performing data communication between the first operating system and the second operating system through the first processor and the second processor corresponding to the target NUMA node, the method includes: Bind the first thread to the first processor, and bind the second thread to the second processor; Wherein, the first thread is a thread in the first operating system used to perform communication with the second operating system; the second thread is a thread in the second operating system used to perform communication with the first operating system.

3. The method according to claim 2, characterized in that, The method further includes adjusting the first thread and the second thread to be processed with priority.

4. The method according to any one of claims 1-3, characterized in that, Before performing data communication between the first operating system and the second operating system via the first processor and the second processor corresponding to the target NUMA node, the method further includes: The first processor and the second processor are determined from the target NUMA node.

5. The method according to claim 4, characterized in that, The step of determining the first processor and the second processor from the target NUMA node includes: Determine the first processor from the target NUMA node; The first processor writes the identification information of the processor corresponding to the target NUMA node into the shared memory; the identification information of the processor corresponding to the target NUMA node is used to indicate the processor corresponding to the target NUMA node. Obtain a third processor running the second operating system; The second processor is determined based on the processor of the target NUMA node and the third processor.

6. The method according to claim 5, characterized in that, The determination of the second processor based on the processor and the third processor of the target NUMA node includes: The second processor is determined from a subset of the processors of the target NUMA node and the third processor.

7. The method according to claim 5 or 6, characterized in that, The step of writing the processor identifier of the target NUMA node into the shared memory via the first processor includes: The first processor writes the target message into the shared memory; wherein the target message includes the data and the identification information of the processor of the target NUMA node.

8. The method according to claim 7, characterized in that, The identification information of the processor of the target NUMA node is set in the header of the target message.

9. The method according to any one of claims 5-8, characterized in that, The identification information of the processor of the target NUMA node includes a CPU bitmap; the CPU bitmap is used to indicate the CPU corresponding to the target NUMA node.

10. An industrial control device, characterized in that, The industrial control device includes a memory and a processor; the memory and the processor are coupled. The memory is used to store program instructions; The processor is used to invoke the program instructions to cause the industrial control equipment to execute the data communication method between hybrid deployment operating systems as described in any one of claims 1 to 9.

Images