Distributed industrial computer based on openharmony system and data collaboration method thereof

Abstract

The application relates to the technical field of industrial personal computers, and discloses a distributed industrial personal computer based on an OpenHarmony system and a data cooperation method thereof.The method comprises the following steps: registering an industrial runtime service instance and receiving a shared memory access request of an application process, transferring a service end file descriptor copy to the application process to obtain a client file descriptor; the application process performs mmap mapping on the client file descriptor to obtain a client mapping address, and initializes a global write position counter and a read position counter array; a service process updates the global write position counter and writes industrial data, the application process updates a self read position counter value in the read position counter array, and sends a data check sum through a distributed soft bus or broadcasts complete data to a remote industrial personal computer node through a distributed data management framework.The application realizes unified and efficient response of the OpenHarmony industrial control system to local real-time data transmission and distributed cooperative work.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of industrial personal computers, and in particular relates to a distributed industrial personal computer based on an OpenHarmony system and a data collaboration method thereof. BACKGROUND

[0002] In the industrial field multi-industrial personal computer collaborative work scenario, high-frequency data collected by sensors need to be transmitted in real time between application processes and industrial runtime service processes. The traditional OpenHarmony system uses the serialization copy mechanism of the Binder IPC framework, and the data needs to undergo a double copy process from the application process heap memory to the kernel Binder buffer and then to the service process heap memory, resulting in a transmission delay of millisecond-level sampling data of more than 800 microseconds. The existing distributed industrial control system generally adopts a unified data synchronization strategy, which transmits all industrial data across devices through a distributed database or a message queue. The mixed transmission of high-frequency mutation data and low-frequency state data leads to high network bandwidth occupation, and there is a lack of differentiated transmission paths for different data dynamic characteristics, which cannot balance between local real-time performance and distributed collaboration. SUMMARY

[0003] The main purpose of the present application is to provide a distributed industrial personal computer based on an OpenHarmony system and a data collaboration method thereof. The present application realizes the unified and efficient response of the OpenHarmony industrial control system to local real-time data transmission and distributed collaborative work.

[0004] To achieve the above purpose, the present application provides a distributed industrial personal computer data collaboration method based on an OpenHarmony system, comprising the following steps:

[0005] Registering an industrial runtime service instance and performing mmap mapping to obtain a service file descriptor and a service mapping base address;

[0006] Receiving a shared memory access request of an application process, transmitting a copy of the service file descriptor to the application process to obtain a client file descriptor;

[0007] The application process performs mmap mapping on the client file descriptor to obtain a client mapping address corresponding to the service mapping base address, and initializes a global write position counter and a read position counter array;

[0008] The service process updates the global write position counter and writes industrial data at the service mapping base address, and the application process updates the value of its own read position counter in the read position counter array, and sends a data checksum through a distributed soft bus or broadcasts complete data to a remote industrial personal computer node through a distributed data management framework.

[0009] Optionally, in the first implementation manner of the first aspect, the registering the industrial runtime service instance and performing the mmap mapping to obtain the server file descriptor and the server mapping base address comprises:

[0010] The Init process parses an industrial runtime service configuration file to obtain a service capability identifier, creates a service process by a fork system call and loads a service dynamic library to construct the industrial runtime service instance, and calls an AddSystemAbility interface to complete service registration;

[0011] The industrial runtime service instance opens an Ashmem device node to obtain an Ashmem device file descriptor, sets a shared memory region parameter by an ioctl system call, and obtains the server file descriptor;

[0012] The mmap system call is performed on the server file descriptor to pass in a read-write permission flag and a shared mapping flag, and the server mapping base address is obtained.

[0013] Optionally, in the second implementation manner of the first aspect, the receiving a shared memory access request of an application process, passing the server file descriptor copy to the application process to obtain a client file descriptor comprises:

[0014] The shared memory access request of the application process is received, the application process loads an SDK dynamic library to obtain a remote object proxy of the industrial runtime service instance, a request data packet of a MessageParcel type is constructed, and a Binder IPC transaction is triggered by a SendRequest interface;

[0015] After the industrial runtime service instance receives the request data packet, a shared memory handle structure body containing a server file descriptor, an offset, a length and a timestamp field is constructed;

[0016] The WriteFileDescriptor interface of a reply data packet is called to write the server file descriptor, the Binder driver allocates the server file descriptor copy in a file descriptor table of the application process and points to the same kernel file object, and the application process reads the server file descriptor copy by the ReadFileDescriptor interface to obtain the client file descriptor.

[0017] Optionally, in the third implementation manner of the first aspect, the mmap mapping is performed on the client file descriptor by the application process to obtain a client mapping address corresponding to the server mapping base address, and a global write position counter and a read position counter array are initialized, comprising:

[0018] The application process reads the client file descriptor through the ReadFileDescriptor interface and executes a dup system call to solidify to a file descriptor table, reads the shared memory handle structure through the ReadRawData interface and parses the length field and the offset field;

[0019] The application process calls an mmap system call to pass in the client file descriptor, the length field, a read permission flag and a shared mapping flag, and the kernel calls a callback function of the Ashmem driver to extract an array of physical page frame numbers;

[0020] The kernel calls a remap_pfn_range function to establish a mapping relationship between a virtual address and the array of physical page frame numbers in the application process page table, the virtual address points to the same physical page frame as the server mapping base address, and the client mapping address is obtained;

[0021] The global write position counter and the read position counter array are initialized at the start page frame position of the server mapping base address.

[0022] Optionally, in a fourth implementation manner of the first aspect of the application, the initialization of the global write position counter and the read position counter array at the start page frame position of the server mapping base address comprises:

[0023] The service process constructs a ring buffer index table structure at the start page frame position of the server mapping base address, and the ring buffer index table structure comprises a global write position counter field of an atomic type, a read position counter array field, a client count field and a mutex field;

[0024] The atomic_init function is called for the global write position counter field and each element of the read position counter array field to initialize to zero, and the pthread_mutex_init function is called for the mutex field to complete mutex creation;

[0025] After the application process obtains the client file descriptor, the application process locks through the mutex field and increments the client count field after taking the current value of the client count field as a client identifier, the service process obtains the application process identifier and inserts the client identifier into a client mapping table to establish a mapping relationship, and the initialization of the global write position counter and the read position counter array is completed.

[0026] Optionally, in the fifth implementation form of the first aspect of the present application, the service process updates the global write position counter and writes the industrial data at the service end mapping base address, the application process updates its own read position counter value in the read position counter array, and sends a data checksum through the distributed soft bus or broadcasts complete data to the remote industrial computer node through the distributed data management framework, including:

[0027] The service process receives the industrial data and obtains the current value of the global write position counter, iterates through the read position counter array to determine whether there is a write pointer chasing read pointer situation, notifies the corresponding application process to accelerate reading if there is, and calculates the write physical address and writes the industrial data and updates the global write position counter if there is not;

[0028] The application process loads its own read position counter value from the read position counter array through the client identifier, compares it with the global write position counter to determine whether there is unread data, calculates the read physical address and reads the industrial data from the client mapping address and updates the own read position counter value if there is, and calculates the read physical address and reads the industrial data from the client mapping address and updates the own read position counter value if there is not;

[0029] The service process stores the information entropy value of the latest written industrial data sampling point, sends the data checksum through the distributed soft bus when the information entropy value is greater than a preset threshold, and broadcasts complete data to the remote industrial computer node through the distributed data management framework when the information entropy value is less than or equal to the preset threshold.

[0030] Optionally, in the sixth implementation form of the first aspect of the present application, the service process stores the information entropy value of the latest written industrial data sampling point, sends the data checksum through the distributed soft bus when the information entropy value is greater than a preset threshold, and broadcasts complete data to the remote industrial computer node through the distributed data management framework when the information entropy value is less than or equal to the preset threshold, including:

[0031] The service process creates a fixed-length double-ended queue to store the sampling point structure, inserts a sampling point instance containing a variable identifier, a value and a timestamp each time the industrial data is written, removes the oldest sampling point at the head of the queue when the queue length exceeds a preset window size, and obtains a data buffer queue;

[0032] Iterate through the data buffer queue to extract the value field to form a value sequence, calculate the maximum value and the minimum value to obtain a value range, and divide the value range by a preset quantization interval number to obtain an equal-width interval step, iterate through the value sequence to calculate the interval index and increment the corresponding sample count to obtain a sample count array;

[0033] Calculate the probability value of each interval by traversing the sample count array, and calculate the logarithmic value by calling the log2 function. Multiply the logarithmic value by the probability value and take the negative value to obtain the information entropy value;

[0034] When the information entropy value is greater than the preset threshold value, the data checksum of the industrial data is calculated, the local device identifier is obtained, and a metadata structure is constructed. The metadata structure is sent to the remote industrial computer node through the distributed soft bus to trigger data pulling;

[0035] When the information entropy value is less than or equal to the preset threshold value, the industrial data is constructed as a key-value pair and a JSON format string is generated. The unique key and the JSON format string are broadcast to the remote industrial computer node through the distributed data management framework and trigger data writing to the service end mapping base address.

[0036] Optionally, in a seventh implementation manner of the first aspect of the present application, the distributed industrial computer data collaboration method based on the OpenHarmony system further includes:

[0037] When each remote industrial computer node is initialized, a vector clock mapping table is created with the device identifier as the key and the logical clock counter as the value. The local device identifier is obtained and the corresponding logical clock counter is initialized to zero. The device identifier list of other remote industrial computer nodes is obtained and the corresponding logical clock counter is initialized to zero.

[0038] When the industrial runtime service performs a data write operation, the logical clock counter corresponding to the local device identifier in the vector clock mapping table is incremented. A synchronization message structure is constructed, which includes the local device identifier, the variable identifier, the data content, and a copy of the vector clock mapping table. The synchronization message structure is sent to the remote industrial computer node through the SendData interface.

[0039] After the remote industrial computer node receives the synchronization message structure, the vector clock is extracted as the receiving vector clock. It is determined whether the sender's logical clock value is equal to the local recorded logical clock value plus one and whether the logical clock values of other devices are not greater than the local recorded logical clock value.

[0040] When both conditions are met, the data content is extracted and written to the service end mapping base address through the memcpy function. The maximum value update operation is performed on the vector clock mapping table.

[0041] When it is judged that the condition is not met, the synchronization message structure is inserted into a pending queue of a priority queue type sorted according to the vector clock partial order relationship, a periodic timer is created to call a pending queue processing function, the pending queue processing function accesses the head synchronization message and repeatedly performs a vector clock comparison judgment, when the condition is met, the head synchronization message is removed and the data is written, otherwise it is retained in the pending queue and waits for the next period to retry.

[0042] Optionally, in an eighth implementation form of the first aspect of the application, after the remote industrial computer node receives the synchronization message structure, the vector clock is extracted as a receiving vector clock, and it is judged whether the sender logical clock value is equal to the local recorded logical clock value plus one and whether the logical clock values of other devices are not greater than the local recorded logical clock value, comprising:

[0043] The industrial runtime service of the remote industrial computer node obtains the synchronization message structure through a receiving callback function of the distributed soft bus, deserializes the receiving vector clock mapping table from the vector clock field, extracts the local device identifier field as a sender device identifier and reads the corresponding logical clock counter value as the sender logical clock value;

[0044] The local vector clock mapping table is searched for the logical clock counter value corresponding to the sender device identifier as the local recorded logical clock value, the local recorded logical clock value plus one is calculated to obtain an expected logical clock value, and it is judged whether the sender logical clock value is equal to the expected logical clock value to obtain a sender clock satisfaction flag;

[0045] All key-value pairs of the receiving vector clock mapping table are traversed, and for each non-sender device identifier, the corresponding local logical clock counter value is searched in the local vector clock mapping table, and it is judged whether the logical clock counter value of the device identifier in the receiving vector clock mapping table is not greater than the local logical clock counter value.

[0046] The application further provides a distributed industrial computer based on an OpenHarmony system, comprising:

[0047] A registration module is configured to register an industrial runtime service instance and perform mmap mapping to obtain a server file descriptor and a server mapping base address;

[0048] A receiving module is configured to receive a shared memory access request of an application process, transfer a copy of the server file descriptor to the application process to obtain a client file descriptor;

[0049] A mapping module is configured to perform mmap mapping on the client file descriptor by the application process to obtain a client mapping address corresponding to the server mapping base address, and initialize a global write position counter and a read position counter array;

[0050] A writing module is configured to update the global write position counter by the service process and write industrial data at the server mapping base address, update a self read position counter value in the read position counter array by the application process, and send a data checksum through the distributed soft bus or broadcast complete data to a remote industrial computer node through the distributed data management framework.

[0051] To sum up, the application registers an industrial runtime service through an OpenHarmony system service framework and calls an Ashmem driver to create an anonymous shared memory region, uses a file descriptor transmission mechanism of Binder IPC to map virtual addresses of the service process and the application process to the same physical page frame, realizes cross-process data access with zero copy, reduces data transmission delay from 800 microseconds in the traditional Binder serialization mode to within 50 microseconds, and meets the real-time transmission requirement of millisecond-level high-frequency sampling data in an industrial field. An index table of a ring buffer including an atomic type global write position counter and a read position counter array is constructed in the shared memory region, lock-free multi-process concurrent access is realized by using CPU instruction level atomicity of C11 atomic operations, and the kernel mode trap overhead of the traditional mutual exclusion lock or semaphore synchronization mechanism is avoided. The information entropy value of the industrial data is calculated based on the Shannon entropy formula and compared with a preset threshold value, local shared memory transmission or a distributed soft bus synchronization path is dynamically selected, high-frequency mutation data is only sent for checksum triggering remote on-demand pulling, and low-frequency state data is directly broadcasted for complete content, so that the distributed synchronization bandwidth occupation is reduced by 65%. A vector clock mapping table is maintained in each industrial computer node, and the causal dependence is detected by comparing the partial order relationship of the logical clock counter, a synchronization message that does not meet the causal condition is inserted into a to-be-processed queue sorted by the vector clock and periodically retried, and the causal consistency of cross-device data synchronization is guaranteed only by a single round of message transmission, so that the OpenHarmony industrial control system realizes unified and efficient response to local real-time data transmission and distributed collaborative work. BRIEF DESCRIPTION OF DRAWINGS

[0052] Figure 1 is a distributed industrial computer data collaboration method step schematic diagram based on the OpenHarmony system in an embodiment of the application;

[0053] Figure 2 is a distributed industrial computer structure block diagram based on the OpenHarmony system in an embodiment of the application.

[0054] The implementation, functional features and advantages of the application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0055] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not to limit the present application.

[0056] With reference to Figure 1 The embodiment provides a distributed industrial computer data collaboration method based on an OpenHarmony system, and the method comprises the following steps:

[0057] S1, register an industrial runtime service instance and perform mmap mapping to obtain a server file descriptor and a server mapping base address;

[0058] In this embodiment, in the starting stage of the industrial personal computer device, the OpenHarmony kernel starts the Init process, the Init process automatically parses the industrial runtime service configuration file jicruntime.cfg located in the / system / etc / init path, and the industrial runtime service configuration file contains parameter information such as a service ability identifier (SAID), a process name, a starting mode, and an SELinux security context. After parsing the configuration file, the Init process executes a fork system call according to the service process name set therein to create an independent child process, loads an industrial runtime service dynamic link library in a specified path, for example, / system / lib64 / libjicruntime_server.z.so, in the child process, and after loading is completed, calls a pre-defined entry function SystemAbilityMain() in the dynamic library to construct a core class instance JICRuntimeService of the industrial runtime service. The service class inherits from the SystemAbility base class in the OpenHarmony system service framework, and the constructor binds the service with a service ability ID of 3301 to the independently running process by calling SystemAbility(3301, true), thereby obtaining a system ability manager object through SystemAbilityManagerClient::GetInstance().GetSystemAbilityManager(), and registering the current service to the service table of the OpenHarmony core service manager samgr through the AddSystemAbility(3301, this) interface, to complete formal registration and publishing of the runtime service. After registration is completed, the service process performs a shared memory area creation operation, specifically, calling open(" / dev / ashmem", O_RDWR) to open an Ashmem anonymous shared memory device node and obtain an Ashmem device file descriptor, setting the shared memory name (ASHMEM_SET_NAME) through an ioctl system call to facilitate debugging identification, and then calling ASHMEM_SET_SIZE to set the actual size of the shared memory, for example, 512 KB. The operating system allocates contiguous page frames in the physical memory and associates them to the device file descriptor. After completing device parameter setting, the service process calls the mmap system call to take the device file descriptor as a mapping source, and transmits a read-write permission flag and a shared mapping flag, to require mapping the corresponding physical memory area to the virtual address space of the current service process. The mapping relationship between the virtual address and the physical page frame is established through the MMU page table management mechanism, and finally the virtual address base address of the shared memory segment, that is, the server mapping base address, is returned.

[0059] S2, receive the shared memory access request of the application process, pass the service end file descriptor copy to the application process to obtain the client file descriptor;

[0060] In this embodiment, the JICRuntimeClient::getInstance()->getShmem() interface is called through the SDK dynamic library (such as libjicruntime.z.so), which internally acquires the remote object proxy of the industrial runtime service instance with the SAID value of 3301 through SystemAbilityManagerClient::GetInstance(). After the remote object proxy is acquired, the application process constructs a request data packet of the MessageParcel type, writes an interface token identifier used for interface verification in the request data packet, and sends the request data packet to the service end through the SendRequest interface with a predefined command code, to trigger the Binder driver to perform the cross-process IPC transaction. After the Binder driver receives the IPC request in the kernel mode, the request data is copied from the user space to the kernel buffer, and is delivered to the service end runtime service process for processing by the Binder thread pool. After the OnRemoteRequest callback function of the service end is activated, the IPC request is identified as a shared memory handle request according to the command code, and a shared memory handle structure containing the service end file descriptor is constructed, which is defined as the ShmemHandle structure and contains the file descriptor field, the memory offset field, the effective length field, and the timestamp field generated by the monotonic clock. The service process calls the WriteFileDescriptor interface of the reply data packet to write the Ashmem file descriptor held by the service end into the IPC reply channel. At this time, the OpenHarmony Binder IPC bottom layer allocates a new file descriptor number in the file descriptor table of the application process based on the binder_translate_fd kernel function, and the file descriptor number is a copy of the service end file descriptor, which essentially points to the same kernel file object as the file descriptor held by the service process, thereby realizing the cross-process file handle redirection. In this process, the Binder driver makes the file descriptor numbers of two different processes refer to the same physical shared memory resource, and points to the unified physical page frame address through the private_data field of the file structure, thereby having cross-address space visibility. The application process extracts the file descriptor copy automatically allocated by the kernel, that is, the client file descriptor, by reading the Binder reply data packet and calling the ReadFileDescriptor interface.

[0061] S3, the application process performs mmap mapping on the client file descriptor, obtains the client mapping address corresponding to the server mapping base address, and initializes the global write position counter and the read position counter array;

[0062] In this embodiment, after receiving the Binder reply data packet from the server, the application process obtains a copy of the server shared memory file descriptor through the ReadFileDescriptor interface. The copy has completed fd mapping in the Binder driver layer and points to the same kernel file object as the server. The application process calls the dup system call to fix the client file descriptor copy to its own file descriptor table, avoiding invalidation of the file descriptor due to handle life cycle limitation. The application process reads the shared memory handle structure returned by the server through the ReadRawData interface, and parses the offset field and the length field of the shared memory region from the structure, which are used to indicate the mapping start offset and the size of the valid data region, respectively. The application process calls the mmap system call with the client file descriptor as a parameter, and simultaneously inputs the parsed length field, the read permission flag PROT_READ, and the shared mapping flag MAP_SHARED, to request mapping of the physical memory region corresponding to the file to its own virtual address space. After receiving the mmap call request, the kernel triggers the mmap callback function ashmem_mmap registered by the Ashmem driver, which extracts the array of continuous physical page frame numbers allocated by Ashmem when creating the file object from the private_data field of the corresponding file object, and calls the kernel API remap_pfn_range function to establish the page table mapping relationship from the applied virtual address to these physical page frame numbers in the page table of the application process. Since the page table entries of the service process and the application process point to the same physical page frame, the client mapping address returned by the mmap of the application process points to the same physical storage region as the server mapping base address, realizing zero-copy sharing. After the mapping is completed, the application process accesses the start page frame of the shared region, and converts the shared region to the defined structure pointer type RingIndex* by type casting, and performs initialization operation on the global write position counter write_pos field and the read position counter array read_pos[MAX_CLIENTS] field in the structure. The atomic_init function is used to set the initial value of the write_pos field to 0, and simultaneously perform atomic initialization of each element of the read_pos array to 0, ensuring the independent read pointer management logic when multiple clients access.

[0063] S4, the service process updates the global write position counter and writes the industrial data at the service end mapping base address, the application process updates the self read position counter value in the read position counter array, and sends the data checksum through the distributed soft bus or broadcasts the complete data to the remote industrial computer node through the distributed data management framework.

[0064] In this embodiment, after the service process receives real-time industrial data through an OPC-UA, MQTT or local PLC bus interface, the current value of the global write position counter in the shared memory start page frame is read. The read operation is implemented through an atomic operation function to ensure concurrent safety. The service process traverses the read pointer values of all active clients in the read position counter array to determine whether there is a situation where a write pointer is about to catch up with a read pointer, that is, to execute the ring buffer full detection logic. When it is detected that the write pointer is about to coincide with any read pointer, it means that there is a risk of buffer coverage. At this time, the service process notifies the corresponding application process through a callback interface to speed up the reading speed or temporarily block the write operation to wait for the consumer to process the data. If there is enough space between the read pointers of all clients and the current write pointer, the service process calculates the physical write address based on the current write position, locates the write area through the offset pointer, and writes the industrial data structure into the mapping memory. Then, the write pointer is advanced by atomically updating the write position counter value. On the application process side, the client identifier obtained through the SDK registration process is used as the array subscript to atomically load the self read position counter value from the read position counter array and compare it with the current write pointer. If it is found that there is new data that has not been read, the application process calculates the read address and reads the data from the mapping address. After the reading is completed, the self read pointer is updated through an atomic operation to ensure that the old data is not read repeatedly. At the same time, the service process performs sliding window maintenance on the industrial data sampling points of each round of writing and calculates the information entropy value as a measure of data volatility. The entropy value is solved through interval quantization and statistical methods. If the current entropy value is greater than the preset threshold, it means that the data belongs to the high-frequency mutation class. The service process calculates the checksum based on the data block and broadcasts the checksum to the remote industrial computer node through the OpenHarmony distributed soft bus interface. The remote node compares the hash value to decide whether to actively pull the complete data. If the entropy value is less than or equal to the threshold, it means that the data changes are relatively stable. The service process calls the broadcast interface of the distributed data management framework to broadcast the complete data in a standardized format to all subscribed nodes.

[0065] In one example, an industrial runtime service instance is registered and mmap mapping is performed to obtain a service end file descriptor and a service end mapping base address, including:

[0066] The Init process parses the industrial runtime service configuration file to obtain a service capability identifier, creates a service process by using a fork system call, loads a service dynamic library to construct an industrial runtime service instance, and calls an AddSystemAbility interface to complete service registration;

[0067] The industrial runtime service instance opens an Ashmem device node to obtain an Ashmem device file descriptor, sets a shared memory region parameter by using an ioctl system call, and obtains a server file descriptor;

[0068] An mmap system call is performed on the server file descriptor, read-write permission flags and a shared mapping flag are input, and a server mapping base address is obtained.

[0069] In this example, the system startup is responsible for completing the initialization loading of the system service by the Init process in the OpenHarmony framework. The Init process automatically parses the industrial runtime service configuration file under the configuration path / system / etc / init directory at the early stage of running. The configuration file contains key fields such as service capability identifier, service process name, startup mode, and SELinux security context. The service capability identifier is used to uniquely identify the location of the runtime service in the system service registry. After parsing the configuration file, the Init process derives a new child process through the fork system call to carry the service logic. The child process loads the service dynamic link library file specified in the configuration file, such as the shared object file at the path / system / lib64 / libjicruntime_server.z.so, and calls the entry function SystemAbilityMain defined therein to construct the main class JICRuntimeService of the runtime service. The main class inherits from the SystemAbility base class of the OpenHarmony system, and binds the parsed service capability identifier through the SystemAbility constructor during construction and specifies that the service runs in an independent process. After completing the service instance construction, the service instance obtains the proxy of the system capability manager object through the SystemAbilityManagerClient, and registers the current service with the specified capability identifier in the system service manager samgr through the AddSystemAbility interface. After the service registration is completed, the service has the ability to be discovered and accessed by other processes. After completing the service registration, the service process performs shared memory initialization operation, opens the anonymous shared memory driver device by calling the open system call and passing in the device node path / dev / ashmem, and obtains the file descriptor corresponding to the Ashmem device. After successfully opening the device, the service process calls the ioctl system call, passes in the command parameter for setting the shared memory name and shared memory size, and sets the shared memory region in the physical memory and binds it with the current file descriptor after the setting is completed. The physical memory mapping resource managed by the kernel is formed. The service process calls the mmap system call with the Ashmem device file descriptor as input, and passes in the read-write permission flag and shared mapping flag. The operating system opens a continuous region in the virtual address space of the current process, and maps it to the allocated physical page frame through the MMU page table mechanism. The returned is the server mapping base address.

[0070] In one example, a shared memory access request of an application process is received, and a copy of the server file descriptor is passed to the application process to obtain a client file descriptor, including:

[0071] The application process receives a shared memory access request, loads an SDK dynamic library to obtain a remote object proxy of an industrial runtime service instance, constructs a request data packet of MessageParcel type, and triggers a Binder IPC transaction through a SendRequest interface;

[0072] After the industrial runtime service instance receives the request data packet, a shared memory handle structure containing a server file descriptor, an offset, a length, and a timestamp field is constructed;

[0073] The WriteFileDescriptor interface of the reply data packet is called to write the server file descriptor, the Binder driver allocates a server file descriptor copy in the application process file descriptor table and points to the same kernel file object, and the application process reads the server file descriptor copy through the ReadFileDescriptor interface to obtain the client file descriptor.

[0074] In this example, when an industrial application process such as an HMI interface or a data recording program needs to access the server shared memory, the dynamic link library file encapsulated by the SDK, such as libjicruntime.z.so, is loaded locally, and a shared memory access request is initiated through the SDK interface JICRuntimeClient::getInstance()->getShmem(). The SDK interface internally obtains the remote object proxy of the industrial runtime service instance previously registered through SystemAbilityManagerClient::GetInstance(). The proxy object is an abstract reference to the service registered in the SystemAbility framework corresponding to the SAID service, and has cross-process communication capability. After the application process obtains the remote proxy object, a request data packet of the MessageParcel type is created, and the WriteInterfaceToken method is called to write the interface verification identifier to ensure the legality of the IPC call. Then, the SendRequest interface is used to send the request data packet, and a command code is attached to identify the request type, triggering a Binder transaction. At this time, the Binder driver copies the request from the application process user space to the kernel buffer and passes it to the Binder thread pool of the industrial runtime service process. After the OnRemoteRequest callback function in the service side identifies that the request is a shared memory access request, a shared memory handle structure is created, which includes the shared memory file descriptor, offset field, length field and current timestamp field held by the service side. The timestamp is used for version control and synchronization consistency judgment. The service side calls the WriteFileDescriptor interface of MessageParcel to write the Ashmem file descriptor it holds into the reply data packet. In this process, the Binder driver allocates a new free file descriptor number in the file descriptor table of the application process through its internal binder_translate_fd kernel function, and points it to the same kernel file object as the service side file descriptor, realizing the sharing of the access channel of the same physical memory page frame between the two processes. After completing the descriptor transfer, the service side serializes the shared memory handle structure and writes it into the reply data packet and returns it to the application process. After receiving the Binder reply data packet, the application process reads out the file descriptor copy automatically allocated by the Binder kernel through the ReadFileDescriptor interface. The file descriptor copy is the client file descriptor that the client can use for mmap mapping locally, and shares the underlying kernel file structure with the service side descriptor, and has complete equal physical page access authority.

[0075] In one example, the application process performs mmap mapping on the client file descriptor, gets the client mapping address corresponding to the server mapping base address, and initializes the global write position counter and the read position counter array, including:

[0076] The application process reads the client file descriptor through the ReadFileDescriptor interface and performs the dup system call to solidify to the file descriptor table, reads the shared memory handle structure through the ReadRawData interface, and parses the length field and the offset field;

[0077] The application process calls the mmap system call to pass in the client file descriptor, the length field, the read permission flag, and the shared mapping flag, and the kernel calls the callback function of the Ashmem driver to extract the physical page frame number array;

[0078] The kernel calls the remap_pfn_range function to establish a mapping relationship between the virtual address and the physical page frame number array in the application process page table, and the virtual address points to the same physical page frame as the server mapping base address, to get the client mapping address;

[0079] The global write position counter and the read position counter array are initialized at the starting page frame position of the server mapping base address.

[0080] In this example, when the application process receives the copy of the shared memory file descriptor passed by the server through the ReadFileDescriptor interface in the Binder reply packet, it invokes the dup system call to solidify the client file descriptor into its own file descriptor table, so that the client file descriptor remains valid and available after the Binder transaction ends, avoiding the problem of resource invalidation due to handle recycling mechanism. The application process reads the shared memory handle structure returned together with the file descriptor through the ReadRawData interface, and parses the length field and offset field required for mapping memory from it. After completing the parsing, the application process invokes the mmap system call and passes in the client file descriptor, the shared memory length field, the read permission flag, and the shared mapping flag, to apply to the operating system for mapping the shared memory segment to its user-mode virtual address space. At this time, the kernel handles the mmap request by invoking the mmap callback function ashmem_mmap registered by the Ashmem driver, which extracts the corresponding physical page frame number array from the file structure's private_data. The physical page frame is uniformly allocated and registered by the kernel when creating the shared memory region on the server. After obtaining the page frame number array, the Ashmem driver passes it to the kernel memory management subsystem, which invokes the remap_pfn_range function to establish a mapping relationship from the requested virtual address range to the physical page frame number array in the application process's page table, so that the application process's virtual address space points to the same physical memory region as the server process's mapping space, implementing the shared memory mechanism of equal access between two processes. After the mapping is completed, the mmap return address obtained by the application process is the client mapping address. The application process accesses the starting page frame position of the shared memory and interprets it as a pointer to the defined RingIndex structure, and according to the communication protocol agreement of the industry runtime service, performs atomic initialization operation on the global write position counter field in the RingIndex structure, and initializes the read position counter array, for example, sets each array element to zero to indicate that no data has been read.

[0081] In one example, initializing the global write position counter and the read position counter array at the starting page frame position of the server mapping base address includes:

[0082] The server process constructs a ring buffer index table structure at the starting page frame position of the server mapping base address, which includes an atomic type global write position counter field, a read position counter array field, a client count field, and a mutex field.

[0083] The atomic_init function is called to initialize each element of the global write position counter field and the read position counter array field to zero value, and the pthread_mutex_init function is called to initialize the mutex field to complete mutex creation;

[0084] After the application process obtains the client file descriptor, it locks the mutex field and increments the client count field by the current value of the client count field as a client identifier. The service process obtains the application process identifier and inserts the client mapping table to establish a mapping relationship with the client identifier, and completes the initialization of the global write position counter and the read position counter array.

[0085] In this example, after the service process completes the creation of the Ashmem shared memory and the mmap mapping, the mapping start address is type-casted to a RingIndex structure pointer, and the structure members are initialized at the mapping start address location, including the atomic type field for global write position control, the read position counter array field for supporting independent reading progress of multiple clients, the client count field for recording the number of currently accessed clients, and the mutex field for protecting the client registration process. The service process initializes each element of the global write position counter field and the read position counter array field by calling the atomic_init function, and sets the value to zero. Before any data is written to the buffer, all position states are consistent. At the same time, the mutex field is initialized by the pthread_mutex_init function to create a thread synchronization primitive for guaranteeing the atomicity of client registration. After the initialization is completed, when an application process obtains a client file descriptor from the service and completes the mapping to access the shared memory access system, it accesses the RingIndex structure in the start page frame of the shared memory mapping area, and locks the mutex field by the pthread_mutex_lock function to avoid race conflicts caused by multiple application processes simultaneously competing for registration. After the lock is successful, the application process reads the value of the current client count field and uses it as its own client identifier, and increments the counter value by one to record the number of new access processes. Then the mutex is released to allow other processes to continue registration. At the same time, the service process calls the getCallingPid function based on the Binder transaction context to obtain the process identifier of the application process, and inserts the process identifier and the client identifier into the client mapping table in the form of key-value pair to form a mapping relationship from the system process identifier to the shared memory logical client number.

[0086] In one example, the service process updates the global write position counter and writes the industrial data at the service end mapping base address, the application process updates its own read position counter value in the read position counter array, sends the data checksum through the distributed soft bus or broadcasts the complete data to the remote industrial computer node through the distributed data management framework, including:

[0087] The service process receives the industrial data and obtains the current value of the global write position counter, traverses the read position counter array to determine whether there is a write pointer chasing read pointer situation, if there is, notifies the corresponding application process to accelerate reading, if not, calculates the write physical address and writes the industrial data and updates the global write position counter;

[0088] The application process loads its own read position counter value from the read position counter array through the client identifier, compares it with the global write position counter to determine whether there is unread data, if there is, calculates the read physical address and reads the industrial data from the client mapping address and updates its own read position counter value;

[0089] The service process stores the latest written industrial data sampling point calculation information entropy value, when the information entropy value is greater than the preset threshold, sends the data checksum through the distributed soft bus, when the information entropy value is less than or equal to the preset threshold, broadcasts the complete data to the remote industrial computer node through the distributed data management framework.

[0090] In this example, after receiving the industrial data, the service process reads the current value of the global write position counter from the shared memory starting from the page frame location, and judges whether there is space to continue writing according to the current value. The service process traverses each client read pointer value in the read position counter array, compares it with the current write pointer value, to determine whether there is a risk that the write pointer will catch up with any read pointer. When it is detected that the write position is about to cover the data area that has not been read by a certain client, it is inferred that the client is a slow consumer, at which time the service process sends a read acceleration instruction to the corresponding application process through a preset Binder callback interface or event notification mechanism, prompting it to complete data reading as soon as possible to release the ring buffer space; if there is a safe interval between the read pointer of all clients and the current write pointer, it means that there is no risk of coverage in the current buffer, then the service process calculates the write target physical address according to the current write position, and writes the newly collected industrial data directly into the shared memory region corresponding to the mapping base address of the service end, and then increments the global write position counter through atomic operation, completing the advancement of the write pointer. At the same time, the application process periodically polls or event-triggeredly loads the read position counter value of its own corresponding index position from the shared memory, and compares it with the current global write position counter. If it is judged that the write pointer has crossed the read pointer, it means that there is new data that has not been read, and the application process calculates the data reading physical address according to its own client identifier, extracts the industrial data content from the mapping region, and after successfully reading, performs atomic update operation on its own read position counter, so that the next reading starts from a new position, to maintain read-write consistency and prevent data from being read repeatedly. While the data read-write alternation process continues to run, the service process maintains a set of recently written industrial data sampling points in real time, and performs information entropy value calculation operation based on the industrial data sampling point set, to judge the dynamic change characteristics of the current data stream. When the calculated information entropy value exceeds the preset change threshold, it is determined that the current data belongs to the high-frequency mutation type, and the service process no longer broadcasts the complete data, but sends the data block checksum information to the remote industrial computer node through the distributed soft bus interface. After receiving the digest, the remote node judges whether to pull the original data through hash comparison, thereby avoiding network load caused by repeated transmission; when the information entropy value is less than or equal to the set threshold, it means that the data changes are relatively stable, and the service process directly serializes and distributes the complete industrial data to all remote subscription nodes through the distributed data management framework to synchronize the local shared memory state.

[0091] In one example, the service process stores the recently written industrial data sampling points to calculate the information entropy value. When the information entropy value is greater than the preset threshold, the data checksum is sent through the distributed soft bus; when the information entropy value is less than or equal to the preset threshold, the complete data is broadcast to the remote industrial computer node through the distributed data management framework, including:

[0092] The service process creates a fixed-length double-ended queue to store sample point structures, inserts a sample point instance containing a variable identifier, a numerical value, and a timestamp each time industrial data is written, removes the oldest sample point at the head of the queue when the queue length exceeds a preset window size, and obtains a data buffer queue;

[0093] The data buffer queue is traversed to extract the numerical value field to form a numerical sequence, the maximum and minimum values are calculated to obtain a numerical range, and the numerical range is divided by a preset quantization interval number to obtain an equal-width interval step size. The numerical sequence is traversed to calculate the interval index and increment the corresponding sample count to obtain a sample count array.

[0094] The sample count array is traversed to calculate the probability value of each interval and call the log2 function to calculate the logarithmic value. The logarithmic value is multiplied by the probability value to obtain the information entropy value.

[0095] When the information entropy value is greater than a preset threshold, the data checksum of the industrial data is calculated, the local device identifier is obtained, and a metadata structure is constructed. The metadata structure is sent to a remote industrial computer node through a distributed soft bus to trigger data pulling.

[0096] When the information entropy value is less than or equal to the preset threshold, the industrial data is constructed as a key-value pair and a JSON format string is generated. The unique key and the JSON format string are transmitted to the remote industrial computer node through a distributed data management framework and trigger data writing to the server mapping base address.

[0097] In this example, the service process constructs and maintains a fixed-length double-ended queue in the data writing process for storing sample point structures, which include three fields of variable identifier, actual value and sampling timestamp. After the service process receives industrial data and completes writing to shared memory, the corresponding sample point instance is inserted into the end of the double-ended queue. If the queue length exceeds the upper limit of the preset sliding window size, for example, 64 sample points, the service process removes the oldest sample point at the head of the queue to keep the queue length stable, obtaining a data buffer queue that continuously reflects the variable change trend in a period of time. The service process traverses the data buffer queue to extract the value field from each sample point and form an independent value sequence. The maximum and minimum values of the value sequence are calculated to obtain the value range, and the value range is divided by the preset quantization interval number, for example, 32, to calculate the step size of the equal-width interval. The value sequence is traversed to calculate the index position of each value in the distribution interval in turn, and the corresponding sample count is incremented accordingly to form a sample count array. The service process traverses the sample count array to calculate the probability value of each interval based on the ratio of the number of samples in each interval to the total length of the queue. Then, the logarithm of the probability value is calculated by the logarithm calculation function log2, the logarithm result is multiplied by the probability value, and the negative values contributed by all intervals are accumulated to obtain the Shannon information entropy value for measuring data volatility. Based on the Shannon information entropy value, the service process dynamically selects a remote synchronization path. If the currently calculated entropy value is greater than the set threshold, it indicates that the current variable is in a state of violent change, and the service process calculates the data checksum of the currently written industrial data and obtains the local device identifier of the industrial control node through the system interface. A metadata structure including the device identifier, variable number, data length, timestamp and checksum is constructed, and the metadata structure is sent to the remote industrial computer node through the distributed soft bus interface. After the remote node receives the metadata, it compares the local cache state according to the checksum information. If the hash values are inconsistent, the service process is requested to transmit the complete data through the data pull interface. If the entropy value is less than or equal to the set threshold, it indicates that the variable value changes smoothly, and the service process encapsulates the current industrial data as a group of standard key-value pairs and serializes a JSON format string. Then, the JSON format data is broadcasted to all subscribing remote nodes through the distributed data management framework interface with the variable number as the unique key. After receiving the broadcast data, the remote node directly completes the deserialization locally and writes the result to the shared memory pointed to by the mapping base address of the respective service side, realizing low-bandwidth and low-latency data consistency update.

[0098] In one example, the distributed industrial computer data collaboration method based on the OpenHarmony system further includes:

[0099] Each remote industrial PC node creates a vector clock mapping table with device identifiers as keys and logical clock counters as values when initializing, obtains the local device identifier and initializes the corresponding logical clock counter to zero, and obtains a list of device identifiers of other remote industrial PC nodes and initializes the corresponding logical clock counters to zero;

[0100] When the industrial runtime service performs a data write operation, the logical clock counter corresponding to the local device identifier in the vector clock mapping table is incremented, a synchronization message structure containing the local device identifier, the variable identifier, the data content, and a copy of the vector clock mapping table is constructed, and the synchronization message structure is sent to the remote industrial PC node through the SendData interface;

[0101] After the remote industrial PC node receives the synchronization message structure, the vector clock is extracted as the receiving vector clock, and it is determined whether the sending party's logical clock value is equal to the local recorded logical clock value plus one and whether the logical clock values of other devices are not greater than the local recorded logical clock value.

[0102] When both conditions are met, the data content is extracted and written to the server mapping base address through the memcpy function, and a maximum value update operation is performed on the vector clock mapping table;

[0103] When there is a condition that is not met, the synchronization message structure is inserted into a pending queue of a priority queue type sorted according to the vector clock partial order relationship, a periodic timer is created to call a pending queue processing function, the pending queue processing function accesses the head synchronization message and repeatedly performs vector clock comparison and judgment, removes the head synchronization message and writes the data when the conditions are met, or retains it in the pending queue for the next period of retry.

[0104] In this example, each remote industrial PC node creates a vector clock mapping table with device identifiers as keys and logical clock counters as values during the system initialization phase to record the operation progress status of itself and all discovered remote devices. Each node obtains its own device identifier by calling the device manager interface and inserts the corresponding key-value pair into the local vector clock mapping table, while initializing the local logical clock counter to zero. Then, the node obtains the device identifier list of other industrial PC nodes in the same LAN through the network discovery mechanism or the device discovery interface of the OpenHarmony distributed software bus, and inserts the identifier of each remote node into the vector clock mapping table in turn, while initializing the corresponding logical clock value of each remote node to zero. When the industrial runtime service performs a write operation on industrial data at a node, the logical clock value corresponding to the local device identifier is taken out from the vector clock mapping table, and the logical clock value is incremented to indicate the occurrence of a new local write operation. Then, a synchronization message structure is constructed, which encapsulates the local device identifier, the identifier of the written variable, the corresponding data content, and the complete vector clock mapping table copy into the structure, and calls the SendData interface to send the synchronization message structure to the specified remote industrial PC node. After receiving the synchronization message structure, the remote node extracts the vector clock copy from the structure as the received vector clock, and compares it with the locally maintained vector clock mapping table item by item to determine whether the logical clock value corresponding to the sender device identifier is exactly equal to the local recorded value plus one, and whether the logical clock values of other devices are all not greater than the local recorded value. Only when all the above conditions are met, it can be determined that the data contained in the synchronization message does not depend on other messages that have not arrived, thereby meeting the prerequisite of causal consistency. If the judgment is passed, the data content is extracted from the synchronization message and written to the shared memory region corresponding to the local service mapping base address through the memcpy function, and the clock value corresponding to each device in the local vector clock mapping table is updated to the larger one between the local current value and the corresponding value in the received vector clock, to maintain the global increment of the clock and the causal dependence loop. If the judgment is not passed, it means that the current synchronization message depends on the previous operation that has not arrived. The remote node inserts the message into a priority queue type of pending queue sorted by the vector clock partial order relationship, and the queue sorting is based on the vector clock partial order relationship between multiple synchronization messages, that is, message A is placed before message B if A is less than or equal to B in all dimensions. In order to ensure that the lagging message can be processed in time once the dependency condition is met, a periodic timer mechanism is created to trigger the call of the pending queue processing function periodically. In the processing function, the synchronization message at the head of the queue is accessed each time and the vector clock comparison judgment is repeated. If the judgment condition is met at this time, the message is removed from the queue and the data write operation and vector clock update are completed. If the judgment is still not met, the message is retained in the queue to wait for the next period to continue trying.

[0105] In one example, the remote industrial PC node extracts the vector clock as the receiving vector clock after receiving the synchronization message structure, and judges whether the sending side logical clock value is equal to the local recorded logical clock value plus one and whether the logical clock values of other devices are not greater than the local recorded logical clock value, comprising:

[0106] The industrial runtime service of the remote industrial PC node obtains the synchronization message structure through the receiving callback function of the distributed software bus, deserializes the receiving vector clock mapping table from the vector clock field, extracts the local device identifier field as the sending side device identifier, and reads the corresponding logical clock counter value as the sending side logical clock value;

[0107] The local recorded logical clock value is found in the local vector clock mapping table as the logical clock counter value corresponding to the sending side device identifier, the local recorded logical clock value plus one is calculated to obtain the expected logical clock value, and it is judged whether the sending side logical clock value is equal to the expected logical clock value to obtain the sending side clock satisfying flag;

[0108] All key-value pairs of the receiving vector clock mapping table are traversed, the corresponding local logical clock counter value is found in the local vector clock mapping table for each non-sending side device identifier, and it is judged whether the logical clock counter value of the device identifier in the receiving vector clock mapping table is not greater than the local logical clock counter value.

[0109] In this example, the industrial runtime service on the remote industrial PC node obtains the synchronization message structure sent from other nodes through the receiving callback function registered by the distributed soft bus, and the synchronization message structure contains the serialized vector clock field, data load, variable identifier, and sender device identifier, etc. Key information. After receiving the message, the industrial runtime service deserializes the vector clock field to recover a receiving vector clock mapping table composed of multiple device identifiers and corresponding logical clock values; at the same time, the local device identifier field representing the data source is extracted from the synchronization message, that is, the sender device identifier, and the corresponding logical clock value of the device identifier in the receiving vector clock mapping table is read as the sender logical clock value. The industrial runtime service looks up the local logical clock counter value corresponding to the sender device identifier in the local vector clock mapping table maintained by itself, takes it as the local record logical clock value, and obtains the expected logical clock value by adding one. In the current local context, if the synchronization message meets the causal consistency, its logical clock value should be exactly equal to the local record value plus one. At this time, the service process judges whether the sender logical clock value is equal to the expected logical clock value, and if equal, sets the sender clock satisfies the flag to true, otherwise to false, indicating whether the synchronization message meets the most basic causal order. In order to verify whether the synchronization message meets all the causal dependence conditions of non-sender dimensions, the service process traverses all key-value pairs in the receiving vector clock mapping table, and for each non-sender device identifier, the corresponding local logical clock counter value is found in the local vector clock mapping table, and compared with the logical clock value in the receiving vector clock mapping table with the same identifier to determine whether there is a clock value in the receiving vector that is greater than the local clock record. If the clock values of all non-sender devices are not greater than the local record value, it means that the synchronization message does not depend on future operations in all non-sender dimensions, that is, there is no pending message in advance, so the complete causal satisfaction condition can be constructed by combining the sender flag.

[0110] Referring to Figure 2 The embodiment provides a distributed industrial PC based on an OpenHarmony system, which comprises:

[0111] A registration module 1 is configured to register an industrial runtime service instance and perform mmap mapping to obtain a server file descriptor and a server mapping base address;

[0112] A receiving module 2 is configured to receive a shared memory access request of an application process, and transfer a server file descriptor copy to the application process to obtain a client file descriptor;

[0113] The mapping module 3 is configured to perform mmap mapping on the client file descriptor by the application process, to obtain a client mapping address corresponding to a server mapping base address, and to initialize a global write position counter and a read position counter array;

[0114] The writing module 4 is configured to update the global write position counter by the service process, to write industrial data at the server mapping base address, to update a self read position counter value in the read position counter array by the application process, and to send a data checksum through the distributed soft bus or to broadcast complete data to a remote industrial computer node through the distributed data management framework.

[0115] In this embodiment, the specific implementation of each unit in the above device embodiment is described above in the method embodiment, which will not be described here.

[0116] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments. Any reference to memory, storage, database or other medium provided by the present application and used in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM, etc.

[0117] It should be noted that in this paper, the term "include", "contain" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, device, article or method including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, device, article or method. Without more limitations, the element defined by the statement "including a" does not exclude the presence of another identical element in the process, device, article or method including the element.

[0118] The above merely provides the preferred embodiments of the present application, and is not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made according to the content of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A distributed industrial computer data collaboration method based on an OpenHarmony system, characterized in that, The method comprises the following steps: registering an industrial runtime service instance and performing mmap mapping to obtain a server file descriptor and a server mapping base address; receiving a shared memory access request of an application process, transmitting a server file descriptor copy to the application process to obtain a client file descriptor; the application process performing mmap mapping on the client file descriptor to obtain a client mapping address corresponding to the server mapping base address, and initializing a global write position counter and a read position counter array; the service process updating the global write position counter and writing industrial data at the server mapping base address, and the application process updating a self read position counter value in the read position counter array and sending a data checksum through a distributed soft bus or broadcasting complete data to a remote industrial computer node through a distributed data management framework; specifically, the service process receives the industrial data and obtains a current value of the global write position counter, traverses the read position counter array to determine whether there is a write pointer chasing read pointer situation, if there is, notifies the corresponding application process to accelerate reading, if not, calculates a write physical address and writes the industrial data and updates the global write position counter; the application process loads a self read position counter value from the read position counter array through a client identifier, compares the self read position counter value with the global write position counter to determine whether there is unread data, if there is, calculates a read physical address and reads the industrial data from the client mapping address and updates the self read position counter value; the service process stores a latest written industrial data sampling point calculation information entropy value, when the information entropy value is greater than a preset threshold, sends the data checksum through the distributed soft bus, when the information entropy value is less than or equal to the preset threshold, broadcasts complete data to the remote industrial computer node through the distributed data management framework.

2. The OpenHarmony system-based distributed industrial computer data collaboration method according to claim 1, characterized in that, The method of registering an industrial runtime service instance and performing mmap mapping to obtain a server file descriptor and a server mapping base address comprises the following steps: an Init process parses an industrial runtime service configuration file to obtain a service capability identifier, creates a service process through a fork system call and loads a service dynamic library to construct the industrial runtime service instance, and calls an AddSystemAbility interface to complete service registration; the industrial runtime service instance opens an Ashmem device node to obtain an Ashmem device file descriptor, sets a shared memory area parameter through an ioctl system call to obtain the server file descriptor; performing an mmap system call on the server file descriptor to pass in a read-write permission flag and a shared mapping flag to obtain the server mapping base address.

3. The OpenHarmony system-based distributed industrial computer data collaboration method according to claim 2, characterized in that, The method of receiving a shared memory access request of an application process, transmitting a server file descriptor copy to the application process to obtain a client file descriptor comprises the following steps: Receiving the shared memory access request of the application process, the application process loads the SDK dynamic library to obtain the remote object proxy of the industrial runtime service instance, constructs a request data packet of MessageParcel type and triggers a Binder IPC transaction through a SendRequest interface; After receiving the request data packet, the industrial runtime service instance constructs a shared memory handle structure body containing the service end file descriptor, offset, length and timestamp fields; Calling the WriteFileDescriptor interface of the reply data packet to write the service end file descriptor, the Binder driver allocates a service end file descriptor copy in the application process file descriptor table and points to the same kernel file object, and the application process reads the service end file descriptor copy through the ReadFileDescriptor interface to obtain the client file descriptor.

4. The OpenHarmony system-based distributed industrial computer data collaboration method according to claim 3, characterized in that, The application process performs mmap mapping on the client file descriptor to obtain a client mapping address corresponding to the service end mapping base address, and initializes a global write position counter and a read position counter array, including: The application process reads the client file descriptor through the ReadFileDescriptor interface and performs a dup system call to solidify to the file descriptor table, reads the shared memory handle structure body through the ReadRawData interface and parses to obtain the length field and the offset field; The application process calls the mmap system call to pass in the client file descriptor, the length field, the read permission flag and the shared mapping flag, and the kernel calls the callback function of the Ashmem driver to extract the physical page frame number array; The kernel calls the remap_pfn_range function to establish a mapping relationship between the virtual address and the physical page frame number array in the application process page table, and the virtual address points to the same physical page frame as the service end mapping base address to obtain the client mapping address; Initializing the global write position counter and the read position counter array at the starting page frame position of the service end mapping base address.

5. The OpenHarmony system-based distributed industrial computer data collaboration method according to claim 4, characterized in that, The initializing the global write position counter and the read position counter array at the starting page frame position of the service end mapping base address includes: The service process constructs a ring buffer index table structure body at the starting page frame position of the service end mapping base address, and the ring buffer index table structure body contains a global write position counter field of atomic type, a read position counter array field, a client count field and a mutex field; Calling the atomic_init function on the global write position counter field and each element of the read position counter array field to initialize to zero value, and calling the pthread_mutex_init function on the mutex field to complete the creation of the mutex lock; The application process acquires the client file descriptor, locks through the mutex field, and increments the client count field after taking the current value of the client count field as a client identifier, the service process acquires an application process identifier and establishes a mapping relationship with the client identifier inserted into a client mapping table, and completes initialization of the global write position counter and the read position counter array.

6. The OpenHarmony system-based distributed industrial computer data collaboration method according to claim 1, characterized in that, The service process stores the latest written industrial data sample point calculation information entropy value, when the information entropy value is greater than a preset threshold, sends the data checksum through the distributed soft bus, when the information entropy value is less than or equal to the preset threshold, broadcasts complete data to the remote industrial computer node through the distributed data management framework, including: The service process creates a fixed-length double-ended queue to store sample point structures, inserts a sample point instance containing a variable identifier, a value and a timestamp each time the industrial data is written, removes the oldest sample point at the head of the queue when the queue length exceeds a preset window size, and obtains a data buffer queue; Traverse the data buffer queue to extract the value field to form a value sequence, calculate the maximum value and the minimum value to obtain a value range, and divide the value range by a preset quantization interval number to obtain an equal-width interval step, traverse the value sequence to calculate the interval index and increment the corresponding sample count to obtain a sample count array; Traverse the sample count array to calculate the probability value of each interval and call the log2 function to calculate the logarithmic value, multiply the logarithmic value by the probability value, and take the negative value to obtain the information entropy value; When the information entropy value is greater than the preset threshold, calculate the data checksum of the industrial data, obtain a local device identifier and construct a metadata structure, and send the metadata structure to the remote industrial computer node through the distributed soft bus to trigger data pulling; When the information entropy value is less than or equal to the preset threshold, construct the industrial data into a key-value pair and generate a JSON format string, and broadcast the unique key and the JSON format string to the remote industrial computer node through the distributed data management framework and trigger data writing to the service end mapping base address.

7. The OpenHarmony system-based distributed industrial computer data collaboration method according to claim 6, characterized in that, The distributed industrial computer data collaboration method based on the OpenHarmony system further includes: Each remote industrial computer node initializes to create a vector clock mapping table with a device identifier as a key and a logical clock counter as a value, obtains the local device identifier and initializes the corresponding logical clock counter to zero, and obtains a list of device identifiers of other remote industrial computer nodes and initializes the corresponding logical clock counter to zero; When the industrial runtime service performs a data write operation, the logical clock counter corresponding to the local device identifier in the vector clock mapping table is incremented, a synchronization message structure containing the local device identifier, the variable identifier, the data content and the vector clock mapping table copy is constructed, and the synchronization message structure is sent to the remote industrial computer node through the SendData interface; The remote industrial computer node extracts a vector clock as a receiving vector clock after receiving the synchronization message structure, and judges whether the sending party logical clock value is equal to the local recorded logical clock value plus one and whether the logical clock values of other devices are not greater than the local recorded logical clock value. When the judgment is met, the data content is extracted and written into the service end mapping base address through the memcpy function, and a maximum value update operation is performed on the vector clock mapping table. When the judgment is not met, the synchronization message structure is inserted into a priority queue type of a to-be-processed queue sorted according to the vector clock partial order relation, a periodic timer is created to call a to-be-processed queue processing function, the to-be-processed queue processing function accesses a head synchronization message and repeatedly performs vector clock comparison judgment, and when the condition is met, the head synchronization message is removed and data is written, otherwise, the head synchronization message is kept in the to-be-processed queue and waits for the next period of time to retry.

8. The OpenHarmony system-based distributed industrial computer data collaboration method according to claim 7, characterized in that, The remote industrial computer node extracts a vector clock as a receiving vector clock after receiving the synchronization message structure, and judges whether the sending party logical clock value is equal to the local recorded logical clock value plus one and whether the logical clock values of other devices are not greater than the local recorded logical clock value. The industrial runtime service of the remote industrial computer node obtains the synchronization message structure through the receiving callback function of the distributed soft bus, deserializes the receiving vector clock mapping table from the vector clock field, extracts the local device identifier field as the sending party device identifier and reads the corresponding logical clock counter value as the sending party logical clock value; The local vector clock mapping table is searched for the logical clock counter value corresponding to the sending party device identifier as the local recorded logical clock value, the local recorded logical clock value plus one is calculated to obtain an expected logical clock value, and it is judged whether the sending party logical clock value is equal to the expected logical clock value to obtain a sending party clock satisfaction flag; All key-value pairs of the receiving vector clock mapping table are traversed, and for each non-sending party device identifier, the corresponding local logical clock counter value is searched in the local vector clock mapping table, and it is judged whether the logical clock counter value of the device identifier in the receiving vector clock mapping table is not greater than the local logical clock counter value.

9. A distributed industrial computer based on an OpenHarmony system, characterized in that Steps for implementing the distributed industrial computer data collaboration method based on the OpenHarmony system in any one of claims 1 to 8, comprising: A registration module is configured to register an industrial runtime service instance and perform mmap mapping to obtain a service end file descriptor and a service end mapping base address; A receiving module is configured to receive a shared memory access request of an application process, and pass the service end file descriptor copy to the application process to obtain a client file descriptor; A mapping module is configured to perform mmap mapping on the client file descriptor by the application process to obtain a client mapping address corresponding to the service end mapping base address, and initialize a global write position counter and a read position counter array. The write module is used for the service process to update the global write position counter and write industrial data at the server mapping base address, the application process to update its own read position counter value in the read position counter array, and the distributed soft bus to send data checksum or the distributed data management framework to broadcast complete data to the remote industrial computer node; specifically comprising: the service process receives the industrial data and obtains the current value of the global write position counter, traverses the read position counter array to determine whether there is a write pointer chasing read pointer situation, notifies the corresponding application process to accelerate reading if there is, calculates the write physical address and writes the industrial data and updates the global write position counter if there is not; the application process loads its own read position counter value from the read position counter array through the client identifier, compares the global write position counter to determine whether there is unread data, calculates the read physical address and reads the industrial data from the client mapping address and updates the own read position counter value if there is; the service process stores the latest written industrial data sampling point calculation information entropy value, sends the data checksum through the distributed soft bus when the information entropy value is greater than the preset threshold value, and broadcasts complete data to the remote industrial computer node through the distributed data management framework when the information entropy value is less than or equal to the preset threshold value.

Images