Data acquisition system based on contact lens production line

Abstract

The present application relates to the technical field of production line data management, in particular to a data acquisition system based on a contact lens production line, aiming at the problems of equipment information island, insufficient data real-time performance, poor storage reliability and the like existing in traditional data acquisition methods, through multi-source heterogeneous data standardized access, edge computing real-time processing and distributed database technology, the collection efficiency and completeness of key data such as process parameters, equipment state and disc circulation information are significantly improved. Through the industrial-grade hot standby redundant transmission channel and the persistent storage mechanism, the data loss risk caused by network fluctuation or equipment failure in the prior art is solved, the high reliability storage of high-frequency dynamic parameters such as pad printing positioning accuracy, filling pressure and mold temperature is ensured, and a stable data basis is provided for production tracing and process optimization. At the same time, a load balancing module is provided to ensure the load balancing of the server nodes receiving data and ensure the stable and reliable working environment of the subsequent links.

Description

Technical Field

[0001] This invention relates to the field of production line data management technology, specifically a data acquisition system based on a contact lens production line. Background Technology

[0002] Modern contact lens manufacturing processes involve complex steps such as pad printing, filling and molding, hydration and curing, and automatic testing. The process involves multiple process parameters such as ink mixing, filling pressure, curing temperature, curing time, and testing parameters for pad printing. At the same time, it is necessary to monitor key data such as equipment operating status, carrier plate flow information, and production cycle in real time.

[0003] As the core carrier in lens production, the location and circulation status of the lens carrier are crucial for product traceability and production process control. Traditional discrete data acquisition methods suffer from problems such as isolated equipment information, insufficient data real-time performance, and poor storage reliability, leading to delayed production process optimization and inefficient fault response. Furthermore, traditional data acquisition and distribution mechanisms lack suitable load balancing methods, potentially resulting in uneven load distribution across server nodes. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a data acquisition system based on a contact lens production line to solve the problems in the background art.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] The data acquisition system based on a contact lens production line of the present invention includes:

[0007] The task creation module is used to create collection tasks based on a hot standby architecture, wherein the collection tasks include subscription tasks, active polling tasks, and passive callback tasks.

[0008] The standardization processing module is used to establish a deduplication mechanism for the data collection task and collect raw data from the contact lens production line based on the data collection task with the deduplication mechanism; the raw data is then processed in a structured manner to obtain standard data with traceability tags.

[0009] The load balancing module is used to obtain the health information of each node in the backend processor cluster, filter healthy nodes based on the health information and build a healthy node pool, filter target nodes from the healthy node pool based on the load algorithm, and distribute the standard data to the target nodes.

[0010] The storage interaction module is used to perform data cleaning and aggregation on the standard data based on the business logic of the standard data source device, and store the cleaned and aggregated standard data in the database.

[0011] The output module is used to generate a result data table with status codes based on the standard data and then write it back when the type of the standard data is a target type that requires real-time feedback.

[0012] In one embodiment of this application, it further includes:

[0013] The initialization module is used to initialize the data acquisition system before creating an acquisition task. The initialization configuration includes system resource initialization, data deduplication module initialization, hot standby channel module initialization, device communication module initialization, callback server initialization, acquisition, and interactive task initialization.

[0014] In one embodiment of this application, creating a data acquisition task based on a hot standby architecture includes:

[0015] Parse the subscription task configuration; create a Subscription object based on the OPC UA protocol, configure the PublishingInterval and LifetimeCount parameters; and create a Client instance based on the MQTT protocol, configure the QoS level and KeepAlive interval parameters to complete the subscription task establishment;

[0016] Parse the parameters of the active polling task, obtain available connections from the connection pool, and create an active polling task based on the available connections;

[0017] Start the callback data processing thread pool, start the callback server and enable the service, listen to the message queue, and complete the construction of the passive callback task.

[0018] In one embodiment of this application, a deduplication mechanism for the acquisition task is established, and raw data from the contact lens production line is acquired based on the acquisition task with the deduplication mechanism, including:

[0019] Based on the subscription task, initial raw data is collected. When a device status change is received, the initial raw data of the two paths under the hot standby architecture is compared. When the unique encoding of the collection source of the initial raw data of the two paths is consistent and the difference of the timestamp does not exceed the preset threshold, it is determined that the initial raw data of the two paths is duplicated. Based on the pre-configured priority rules, one of the initial raw data paths is retained to obtain the raw data. The initial raw data of the two paths under the hot standby architecture comes from the master server node and the slave server node, respectively.

[0020] In any polling cycle, when the master server node and the slave server node construct a polling task to poll devices with the same unique source code, they calculate the timestamp difference between the task construction timestamp of the master server node and the task construction timestamp of the slave server node; and when the timestamp difference does not exceed a preset threshold, they select one of the master server node and the slave server node to create a polling task based on a pre-configured priority rule; and obtain raw data based on the polling task of each polling cycle.

[0021] The message queue uploaded through the callback task is obtained, and the single consumer mode of the message queue is used to ensure that the same data is only received by the server node with the highest current priority among the master server node and the slave server node, thus obtaining the original data. The priorities of the master server node and the slave server node are determined based on pre-configured priority rules, which include: when the master server node is in a normal state, the priority of the master server node is higher than that of the slave server node; when the master server node is in an abnormal state and the slave server node is in a normal state, the priority of the master server node is lower than that of the slave server node.

[0022] In one embodiment of this application, the health information of each node in the backend processor cluster is obtained, and healthy nodes are selected and a healthy node pool is constructed based on the health information, including:

[0023] Periodically send health check requests to multiple server nodes in the backend processor cluster;

[0024] When receiving passive or active feedback information from multiple server nodes, the response status code and timestamp are extracted from the active feedback information, or the response time, error rate, CPU usage and memory usage are extracted from the passive feedback information. The passive feedback information is generated based on the health check request, and the active feedback information is information uploaded by the server nodes at regular intervals.

[0025] Calculate the time difference between the timestamp and the current time, and take the response status code corresponding to the timestamp where the time difference is less than a threshold as the valid response status code, and determine the availability status of the server node based on the valid response status code;

[0026] The response time is compared with a preset response time threshold, the error rate is compared with a preset error rate threshold, and the CPU utilization and memory utilization are compared with preset utilization thresholds respectively. When all of the following conditions are met simultaneously: the response time is less than or equal to the preset response time threshold, the error rate is less than or equal to the preset error rate threshold, and both the CPU utilization and memory utilization are less than the preset utilization thresholds, the corresponding server node is marked as available.

[0027] A healthy node pool is built based on all currently available server nodes.

[0028] In one embodiment of this application, selecting target nodes from the healthy node pool based on a load balancing algorithm includes:

[0029] Send test requests multiple times to all server nodes in the healthy node pool;

[0030] Upon receiving test feedback information from the server node, extract various core resource metrics from the test feedback information. The test values, wherein the various core resource metrics include CPU utilization, memory utilization, GPU utilization, and current connection count, and the test feedback information is generated based on the test request. It is a natural number;

[0031] Task types are extracted from the standard data, and target weight sequences are selected based on the task types in the standard data and a pre-built indicator weight database. The indicator weight database includes weight sequences for multiple task types, and the weight sequences include weights for multiple core resource indicators.

[0032] Calculate the variance of multiple test values ​​for each core resource metric. and average And filter out the maximum variance for each server node. ;

[0033] Maximum variance across multiple server nodes Average value of each core resource indicator Normalization is performed to obtain the normalized maximum variance. and the normalized average of each core resource metric Based on the maximum variance Average value of each core resource indicator And calculate the load score for each server node using the target weight sequence. The load rating The mathematical expression is:

[0034]

[0035] In the formula, For the first in the target weight sequence Individual rights;

[0036] Load scoring from multiple server nodes Filter for lowest load score and the lowest load score The corresponding server node is used as the target node.

[0037] In one embodiment of this application, the method for constructing the indicator weight database includes:

[0038] Obtain a historical running data sample set from multiple server nodes, wherein the historical running data sample set includes running data samples from multiple sampling time points, and the running data samples include the values ​​of running tasks and core resource indicators;

[0039] The running data sample set is divided into multiple data units based on the type of the running task, wherein each data unit corresponds to a task type;

[0040] The values ​​of core resource metrics for multiple running data samples in each data unit. Normalization is performed to obtain normalized core resource indicator values. ,in, Indicates the sequence number of the running data sample;

[0041] Based on the normalized core resource index values Calculate each core resource metric Information entropy The information entropy The mathematical expression is:

[0042]

[0043]

[0044] In the formula, This indicates the number of multiple running data samples in a data unit. Represents a probability distribution;

[0045] Calculate core resource indicators Redundancy , And according to the redundancy Calculate core resource indicators weight Among them, core resource indicators weight The mathematical expression is:

[0046]

[0047] In the formula, Indicates the quantity of core resource indicators;

[0048] Weights based on multiple core resource metrics for each task type Construct a weight sequence and build an indicator weight database based on the weight sequences of multiple task types.

[0049] In one embodiment of this application, distributing the standard data to the target node includes:

[0050] Establish a long-lived TCP connection between the load balancing module and the target node;

[0051] The standard data is packaged into a JSON data packet; and the JSON data packet is sent to the target node via the TCP long connection.

[0052] In one embodiment of this application, constructing a long-lived TCP connection between the load balancing module and the target node includes:

[0053] S1, a connection request is sent to the current target node based on the load balancing module;

[0054] S2, upon receiving a response from the current target node, a TCP long connection is established based on the response; if no response is received from the current target node after the target time has elapsed, or if an error code is received from the current target node, a new target node is selected from the healthy node pool based on a load balancing algorithm, wherein both the response and the error code are generated based on the connection request;

[0055] S3, take the new target node as the current target node, and return to step S1 until a TCP long connection is established; or, until the number of reconnections exceeds a preset reconnection threshold; when the number of reconnections exceeds the preset reconnection threshold, trigger an alarm mechanism and record an error log.

[0056] In one embodiment of this application, storing the cleaned and aggregated standard data in a database includes: recording the original data through a time-series database and persisting the structured statistical processing results through a relational database.

[0057] The beneficial effects of this invention are as follows: The data acquisition system based on a contact lens production line of this invention, based on a hot standby architecture, ensures the security of data acquisition under the dual-channel redundant acquisition structure of the hot standby architecture. Simultaneously, for the multi-source heterogeneous data generated by the contact lens production line, this application adapts and acquires data by creating subscription tasks, active polling tasks, and passive callback tasks. The acquired data undergoes deduplication and structuring processing to obtain labeled data with traceability tags, unifying the multi-source heterogeneous data structure while also meeting auditing and traceability requirements. This application addresses the problems of equipment information silos, insufficient data real-time performance, and poor storage reliability in traditional data acquisition methods. Through standardized access to multi-source heterogeneous data, real-time edge computing processing, and distributed database technology, it significantly improves the acquisition efficiency and completeness of key data such as process parameters, equipment status, and tray transfer information. Through industrial-grade hot standby redundant transmission channels and persistent storage mechanisms, it solves the risk of data loss due to network fluctuations or equipment failures in existing technologies, ensuring high-reliability storage of high-frequency dynamic parameters such as pad printing positioning accuracy, filling pressure, and mold closing temperature, providing a stable data foundation for production traceability and process optimization. At the same time, a load balancing module is provided to ensure load balancing of the server nodes receiving data, thus ensuring a stable and reliable working environment for subsequent processes. Attached Figure Description

[0058] The present invention will be further described below with reference to the accompanying drawings and embodiments:

[0059] Figure 1 This is a structural diagram of a data acquisition system based on a contact lens production line shown in one embodiment of this application;

[0060] Figure 2 This is a flowchart illustrating the initialization configuration of a data acquisition system according to an embodiment of this application;

[0061] Figure 3 A flowchart illustrating PLC device communication and multi-type data acquisition device configuration in one embodiment of this application;

[0062] Figure 4 This is a schematic diagram illustrating the construction process of various types of data acquisition tasks in one embodiment of this application;

[0063] Figure 5 This is a schematic diagram of a standardized processing flow in one embodiment of this application;

[0064] Figure 6 This is a schematic diagram of the dynamic allocation process in one embodiment of this application;

[0065] Figure 7 This is a flowchart illustrating the processing of a standard request in one embodiment of this application;

[0066] Figure 8This is a schematic diagram of the output process in one embodiment of this application. Detailed Implementation

[0067] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0068] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the layers related to the present invention and are not drawn according to the actual number, shape and size of the layers in the actual implementation. In the actual implementation, the form, number and proportion of each layer can be arbitrarily changed, and the layer layout may also be more complex.

[0069] Numerous details are explored in the following description to provide a more thorough explanation of embodiments of the invention; however, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details.

[0070] The core design concept of this system is to manage and schedule the entire lifecycle of data during the data acquisition process in a task-oriented and workflow-oriented manner.

[0071] Specifically, for the typical scenario of device status acquisition, when a device status change triggers a acquisition request, or when an acquisition operation is initiated according to a preset cycle, the system will encapsulate it as an independent acquisition task and use the data as the starting node of the corresponding workflow. If there are high availability requirements (such as hot standby scenarios), the system will automatically generate two parallel acquisition tasks or workflow instances, achieving redundant backup through a dual-path data acquisition mechanism. Subsequently, the dual-path data will be precisely deduplicated according to preset business logic rules (such as timestamp consistency verification, device identifier matching, etc.) to ensure data uniqueness and accuracy.

[0072] For each independent data unit or set of related data changes during the data flow process, the system adopts a task-based encapsulation mechanism, assigning it a unique task identifier and specifying the processing node and execution sequence. This architectural design gives the system strong configurability: users can customize task triggering conditions (such as status change thresholds, collection cycle parameters), workflow node relationships, data processing rules, etc., through a visual configuration interface, adapting to different production scenario requirements without modifying the underlying code. Meanwhile, based on the modular design of tasks and workflows, the system has excellent scalability. When adding new device types, collection parameters, or third-party system interfaces, only the corresponding task templates and workflow node configurations need to be added to achieve functional expansion, effectively reducing system iteration costs. The specific solution based on the above ideas is as follows.

[0073] Figure 1 This is a structural diagram of a data acquisition system based on a contact lens production line, as shown in one embodiment of this application. Figure 1 As shown, the data acquisition system based on the contact lens production line in this embodiment includes an initialization module 110, a task creation module 120, a standardization processing module 130, a load balancing module 140, a storage interaction module 150, and an output module 160. The functions and principles of each module are described below:

[0074] The initialization module 110 is used to initialize the data acquisition system before creating an acquisition task. The initialization configuration includes system resource initialization, data deduplication module initialization, hot standby channel module initialization, device communication module initialization, callback server initialization, acquisition, and interactive task initialization.

[0075] Specifically, in this embodiment, the initialization module 110 is responsible for initializing and configuring the data acquisition system, including setting system operating parameters, configuring PLC device communication parameters (such as IP address, port number, and protocol type), adapting access protocols for multiple types of data acquisition devices (such as sensors and IoT devices), and calibrating parameters. Through standardized configuration template loading, environment variable verification, and redundant channel pre-start, a stable basic environment is provided for subsequent data acquisition.

[0076] The task creation module 120 is used to create acquisition tasks based on a hot standby architecture, wherein the acquisition tasks include subscription tasks, active polling tasks, and passive callback tasks.

[0077] Specifically, the task creation module 120 utilizes a multi-protocol adaptation engine, including OPC UA, ModBus, TCP / IP, and API, and employs a dual-channel hot standby mechanism to achieve data acquisition. It supports a hybrid mode of subscription-based real-time push (such as OPC UA Pub / Sub) and periodic polling (such as ModBus RTU / TCP), enabling high-concurrency reading of PLC registers, device status bits, and sensor values. It outputs raw data sets (Raw_Data) according to data type and ensures continuous acquisition through heartbeat detection, fault switching, and redundant acquisition.

[0078] The standardization processing module 130 is used to establish a deduplication mechanism for the acquisition task and to acquire raw data of the contact lens production line based on the acquisition task with the deduplication mechanism; and to perform structured processing on the raw data to obtain standard data with traceability tags.

[0079] Specifically, the standardization processing module 130 is responsible for deduplicating Raw_Data (based on timestamps, devices, and data types) and standardizing its format.

[0080] The load balancing module 140 is used to obtain the health information of each node in the backend processor cluster, filter healthy nodes based on the health information and build a healthy node pool, filter target nodes from the healthy node pool based on the load algorithm, and distribute the standard data to the target nodes.

[0081] Specifically, the load balancing module 140 distributes data streams to multiple hot standby processor nodes in real time using a load balancing algorithm. It supports elastic scaling, automatically migrates tasks to standby nodes when a node fails, and outputs distribution logs and load status monitoring signals.

[0082] The storage interaction module 150 is used to perform data cleaning and aggregation on the standard data based on the business logic of the standard data source device, and store the cleaned and aggregated standard data in the database.

[0083] Specifically, the storage interaction module 150 performs data cleaning and aggregation operations based on pre-defined business logic, and achieves hot backup storage of data through a dual-write mechanism. It uses a time-series database (such as QuestDB) to record raw data and a relational database (such as MySQL) to persist structured statistical processing results. It also supports API interaction with third-party systems (such as MES and SCADA) to output the required structured data.

[0084] The output module 160 is used to generate a result data table with status codes based on the standard data and then write it back when the type of the standard data is a target type that requires real-time feedback.

[0085] Specifically, the output module 160 uses low-latency channel interaction (such as OPC UA, ModBus, TCP / IP) to reverse-write the final result data packet (Result_Packet) with status code for data that needs to be fed back in real time (such as PLC control signals and production parameters).

[0086] The specific implementation methods of the above functional modules are as follows:

[0087] (1) Initialization module

[0088] The initialization module is responsible for initializing and configuring the data acquisition system, including setting system operating parameters, configuring PLC device communication parameters (such as IP address, port number, and protocol type), adapting access protocols for various types of data acquisition devices (such as sensors and IoT devices), and calibrating parameters. Through standardized configuration template loading, environment variable verification, and redundant channel pre-start, it provides a stable foundation for subsequent data acquisition.

[0089] Figure 2 This is a flowchart illustrating the initialization configuration of a data acquisition system according to one embodiment of this application. Figure 3 This is a flowchart illustrating the PLC device communication and multi-type data acquisition device configuration in one embodiment of this application, as follows: Figure 2 and Figure 3 As shown, the main functions of the initialization module are system initialization configuration, PLC device communication, and initialization configuration of multiple types of data acquisition devices, specifically including:

[0090] (1-1) System initialization configuration

[0091] (1-1-1) System resource module initialization:

[0092] (1-1-1a) Configuration Document Loading and Verification: Load the configuration file in a unified format, verify the compatibility between the system version and the configuration file, verify the validity and connectivity of the IP address, verify the validity of the parameter range, and verify the legality of the data collection task. Before the data collection system officially starts working, ensure that the configuration is correct and the network environment is normal.

[0093] (1-1-1b) Pre-allocate system resource pool: allocate fixed memory blocks, set thread pool limits, and set collection work limits to ensure that no resource contention occurs during high-concurrency collection and that no failures occur due to exceeding system resource limits.

[0094] (1-1-1c) Load basic service components: Start the log engine, upload server anomaly information to the client, and upload system anomaly detection information to the client. Monitor system and server anomalies in real time.

[0095] (1-1-2) Initialization of the data deduplication module:

[0096] (1-1-2a) Redis basic test: Test whether the Redis account, password, port, etc. are normal, and ensure that Redis starts and runs successfully.

[0097] (1-1-2c) Redis infrastructure configuration: Initialize Redis, and use Redis's atomicity to ensure the uniqueness of interactive or data collection tasks, while limiting the frequency of data collection and interaction.

[0098] (1-1-3) Initialization of the hot standby channel module:

[0099] (1-1-3a) RabbitMQ basic test: Test whether the RabbitMQ account, password, port, etc. are normal, and ensure that RabbitMQ starts up and runs successfully.

[0100] (1-1-3b) RabbitMQ infrastructure configuration: Create a persistent message queue and enable single consumer mode, and set reasonable message lifecycle control to ensure that data on the same device is always processed by a fixed consumer.

[0101] (1-2) PLC device communication and initialization configuration of multiple types of data acquisition devices

[0102] (1-2-1) Device communication module initialization:

[0103] (1-2-1a) Loading Protocol Stack Driver Library: Based on the device type and communication configuration, load the built-in industrial protocol parsing engines such as ModBus, Snap7 (Siemens S7), OPC UA, MQTT, and RESTful, and perform connection tests to provide basic communication support for subsequent data acquisition and interaction tasks. At the same time, enable connection testing and fault reconnection.

[0104] (1-2-2) Callback server initialization:

[0105] (1-2-2a) Callback queue creation: Independent queues are divided according to the system, device, task type and other dimensions by configuration, providing different task queue support for different collection task types, and configuring dead letter queues to handle abnormal requests.

[0106] (1-2-2b) Callback service startup: Enable unified callback service, which allows third-party systems to make real-time interface call requests or query the current status of the system.

[0107] (1-2-3) Data Acquisition and Interaction Task Initialization:

[0108] (1-2-3a) Breakdown of the three core tasks of the contact lens production line:

[0109] Interactive task types include: process interaction tasks (such as the distribution of production information and process parameters), pallet scanning tasks (binding and unbinding operations of various pallets), and AGV transfer tasks (dynamic control and transfer of various semi-finished materials), etc.

[0110] Data collection types include: equipment parameter collection (such as equipment status, temperature, etc.), environmental parameter collection (such as workshop temperature, humidity, etc.), etc.

[0111] Statistical tasks include: reporting quality inspection results (such as transfer printing pattern detection, mold closing inspection, full inspection and sealing inspection, etc.), and operator work reporting (such as production work reporting and anomaly reporting).

[0112] (1-2-3b) Task Interaction Types

[0113] Active polling establishes a long-lived connection session pool and initiates requests at preset intervals. The polling mechanism is as follows:

[0114] Interval triggers: These execute cyclically at fixed time intervals, such as when polling temperature data or process parameters.

[0115] crontab triggers: triggered periodically at specific times, such as daily report generation or hourly equipment production data collection.

[0116] Passive reception, primarily using Flask service and RabbitMQ message queue subscription for message receiving and processing.

[0117] Message subscription: Message subscription and reception processing methods primarily based on OPC, UA, Pub / Sub, and MQTT.

[0118] Task creation: Create and initialize specific tasks based on interaction methods, task interaction types, configuration parameters, etc.

[0119] (2) Task creation module

[0120] The task creation module utilizes a multi-protocol adaptation engine, including OPC UA, ModBus, TCP / IP, and API, and employs a dual-channel hot standby mechanism for data acquisition. It supports a hybrid mode of subscription-based real-time push (e.g., OPC UA Pub / Sub) and periodic polling (e.g., ModBusRTU / TCP), enabling high-concurrency readings of PLC registers, device status bits, and sensor values. It outputs raw data sets (Raw_Data) according to data type and ensures continuous acquisition through heartbeat detection, fault switching, and redundant acquisition. Figure 4 This is a schematic diagram illustrating the construction process of various types of data acquisition tasks in one embodiment of this application, such as... Figure 4 As shown, it specifically includes:

[0121] (2-1) Subscription task:

[0122] (2-1-1) Parse the subscription task configuration (terminal URL, security policy, subscription parameters, etc.);

[0123] (2-1-2) Create a Subscription object based on the OPC UA protocol and configure the PublishingInterval and LifetimeCount parameters;

[0124] (2-1-3) and create a Client instance based on the MQTT protocol, configure the QoS level and KeepAlive interval parameters, and complete the subscription task establishment;

[0125] (2-2) Active polling task:

[0126] (2-2-1) Parse the parameters of the active polling task (polling type, polling period, access path, data type mapping, etc.);

[0127] (2-2-2) Obtain available connections from the connection pool and create an active polling task based on the available connections;

[0128] (2-3) Callback Task:

[0129] (2-3-1) Start the callback data processing thread pool;

[0130] (2-3-2) Start the callback server and enable the service

[0131] (2-3-3) Listen to the message queue (initialize the message queue, security check, heartbeat check, etc.) and complete the construction of the passive callback task.

[0132] (3) Standardization processing module

[0133] The standardization processing module is used to configure a deduplication mechanism for data collection, or to perform data deduplication (based on timestamps, device and task type), preprocessing and format standardization on the raw data (Raw_Data) that has already been collected.

[0134] The manufacturing process of contact lenses is highly precise and complex, involving multiple core processes such as injection molding, color printing, liquid injection and mold closing, curing and molding, mold separation, hydration, and quality inspection. The types of data that need to be collected in each process are significantly different, and the core processes also differ between different production processes. At the same time, the diverse characteristics of the production environment further increase the difficulty of data collection: some equipment is located in high-temperature curing chambers, hydration tanks, and other environments, and must cope with temperature, humidity, and media interference; the environmental monitoring system needs to collect environmental parameters such as temperature, humidity, and particulate concentration in the cleanroom in real time, and the data sources include various types of equipment such as PLC controllers, IoT sensors, and precision testing instruments, with inherent heterogeneity in interface protocols and data formats.

[0135] The core design idea of ​​this system is to manage and schedule the entire lifecycle of data during the data acquisition process in a task-oriented and workflow-oriented manner. Therefore, multi-source heterogeneous scenarios are implemented as different forms of acquisition tasks according to the interaction mode.

[0136] Figure 5 This is a schematic diagram of a standardized processing flow in one embodiment of this application, such as... Figure 5 The following are included:

[0137] (3-1) Data deduplication for subscription tasks

[0138] (3-1-1) Based on the subscription task, the initial raw data is collected, and when a change in device status is received, the initial raw data of the dual-path under the hot standby architecture is compared;

[0139] (3-1-2) When the unique encoding of the acquisition source of the two initial raw data is consistent and the difference of the timestamp does not exceed the preset threshold, it is determined that the two initial raw data are duplicated;

[0140] (3-1-3) Based on the pre-configured priority rules, one of the initial raw data is retained to obtain the raw data, wherein the dual initial raw data under the hot standby architecture comes from the master server node and the slave server node respectively;

[0141] Subscription-type tasks (e.g., OPC / UA / subscription): In a hot standby architecture, both master and slave server nodes simultaneously subscribe to change notifications from the target data source. For example, when a device's status changes, both nodes will synchronously receive the changed data.

[0142] The system uses a pre-defined deduplication mechanism (based on task type identifier + unique source code + timestamp + data feature value). For example, if both the master and slave servers subscribe to the device status of a certain pad printing device [unique source code] [task type identifier], they can obtain the changes in device status [data feature value] almost simultaneously.

[0143] Specifically, based on Redis timestamp atomic operations, the data from both sources is compared, retaining only the unique valid data entry and generating a single processing task. This mechanism ensures redundant backup capabilities for data collection while avoiding duplicate task creation due to dual-node reception, thus guaranteeing both high availability and improved processing efficiency.

[0144] (3-2) Polling task deduplication mechanism

[0145] (3-2-1) In any polling cycle, when the master server node and the slave server node construct a polling task to poll devices with the same unique source code, the timestamp difference between the task construction timestamp of the master server node and the task construction timestamp of the slave server node is calculated.

[0146] (3-2-2) And when the timestamp difference does not exceed a preset threshold, a polling task is created by selecting one of the master server node and the slave server node based on the pre-configured priority rules;

[0147] (3-2-3) Obtain raw data based on the polling task of each polling cycle;

[0148] Active polling types (e.g., ModBus, TCP / IP, API interfaces): For data requiring periodic collection, both master and slave server nodes generate polling tasks based on a preset period. However, the system uses a distributed task coordination mechanism to deduplicatize tasks (based on task type identifier + unique source code + polling time window; for example, both master and slave servers need to poll for the temperature of a solidified chamber [unique source code] [task type identifier], with a polling interval of 10 seconds, and task creation is limited by Redis timestamp atomic operations [polling time window]). Within the same time window, only the master node is allowed to perform the actual polling operation, while the slave node tasks enter a standby state. If the master node fails, the slave node can immediately activate the task to take over the polling, ensuring continuous collection while avoiding duplicate access pressure on the underlying devices.

[0149] (3-3) Deduplication of callback task data

[0150] (3-3-1) Obtain the message queue uploaded through the callback task, and ensure that the same data is received only by the server node with the highest current priority among the master server node and the slave server node through the single consumer mode of the message queue, so as to obtain the original data.

[0151] Passive callback type (e.g., API callback, MQTT upload): For data actively pushed by third-party systems (e.g., optical inspection results from quality inspection equipment), hot backup is achieved using the exclusive consumption mechanism of message queues (e.g., RabbitMQ).

[0152] The master and slave server nodes simultaneously subscribe to the same message queue. The single consumer mode of the queue ensures that the same data message is processed by only one node (the master node consumes it first under normal conditions). When the master node fails, the message queue automatically distributes unconsumed messages to the slave nodes. The slave nodes immediately take over the consumption tasks after detecting the loss of the master node's heartbeat, achieving seamless switching and ensuring data integrity and timely processing in passive receiving scenarios.

[0153] In the above process, the priorities of the master server node and the slave server node are determined based on pre-configured priority rules. The priority rules include: when the master server node is in a normal state, the priority of the master server node is higher than that of the slave server node; when the master server node is in an abnormal state and the slave server node is in a normal state, the priority of the master server node is lower than that of the slave server node.

[0154] (3-4) Standardized format processing

[0155] Finally, it is uniformly converted into a standardized structure with quality labels, including five core fields: device ID, timestamp, task type identifier, data value and auxiliary information, to eliminate the heterogeneity of multi-source data.

[0156] (4) Load balancing module

[0157] The system includes an Nginx load balancer, which distributes tasks to the backend processor cluster in real time based on node health and load balancing algorithms. During distribution, TCP long connection reuse and automatic retry mechanisms are enabled. Simultaneously, the load status of each node is monitored in real time. When a node failure is detected, tasks are automatically migrated to a backup node. Detailed logs containing the distribution path, processing node, and status codes are generated throughout the process, and load balancing monitoring signals are output. Figure 6 This is a schematic diagram of the dynamic allocation process in one embodiment of this application, as shown below. Figure 6 As shown, it specifically includes:

[0158] (4-1) Health monitoring mechanism

[0159] (4-1-1) Proactive Probe: Periodically send health check requests (such as the HTTP / health interface) to multiple server nodes in the backend processor cluster, and determine whether the node is available based on the feedback information.

[0160] (4-1-2) Real-time feedback: Backend nodes actively report their own status (such as response status codes), and the load balancer summarizes this information as the basis for judging health status.

[0161] (4-1-3) Health monitoring:

[0162] (4-1-3a) When receiving passive or active feedback information from multiple server nodes, extract the response status code and timestamp from the active feedback information, or extract the response time, error rate, CPU usage and memory usage from the passive feedback information, wherein the passive feedback information is generated based on the health check request, and the active feedback information is information uploaded by the server nodes periodically;

[0163] (4-1-3b) Calculate the time difference between the timestamp and the current time, and take the response status code corresponding to the timestamp whose time difference is less than the threshold as the valid response status code, and determine the availability status of the server node based on the valid response status code;

[0164] Backend nodes actively report their own status at specific timestamps. If these timestamps are too far removed from the current time, the corresponding status cannot be used as a reference for judgment. Therefore, this application uses timestamps to filter valid response status codes, and then determines the usability status based on the response status code; for example, 200 indicates normal operation.

[0165] (4-1-3c) Compare the response time with a preset response time threshold, compare the error rate with a preset error rate threshold, and compare the CPU utilization and memory utilization with preset utilization thresholds respectively; when all of the following conditions are met simultaneously: the response time is less than or equal to the preset response time threshold, the error rate is less than or equal to the preset error rate threshold, and both the CPU utilization and memory utilization are less than the preset utilization thresholds, mark the corresponding server node as available;

[0166] For the feedback information obtained by active detection, this application compares the parameter values ​​in the feedback information with a threshold. If the value is less than the threshold (90%), it means that the server node is available.

[0167] (4-1-3d) Build a healthy node pool based on all currently available server nodes.

[0168] Finally, a healthy node pool is built from all server nodes that are in an available state.

[0169] (4-2) Dynamic allocation

[0170] The purpose of dynamic allocation in this embodiment is to perform load balancing on multiple server nodes. A load balancing algorithm is used to determine the current state, and target nodes are selected from the healthy node pool based on the load balancing algorithm, including:

[0171] (4-2-1) Send test requests multiple times to all server nodes in the healthy node pool;

[0172] The purpose of sending a test request is to receive information about the load on the server nodes.

[0173] (4-2-2) Upon receiving test feedback information from the server node, extract multiple core resource indicators from the test feedback information. The test values, wherein the various core resource metrics include CPU utilization, memory utilization, GPU utilization, and current connection count, and the test feedback information is generated based on the test request. It is a natural number;

[0174] Among them, CPU utilization, memory utilization, GPU utilization, and the number of current connections all affect the execution of the task. Therefore, when the server node receives a test request, it immediately collects the values ​​of various core resource indicators and returns them to the load balancer nginx.

[0175] (4-2-3) Extract task types from the standard data, and select target weight sequences based on the task types in the standard data and the pre-built indicator weight database, wherein the indicator weight database includes weight sequences for multiple task types and the weight sequences include weights for multiple core resource indicators;

[0176] Different tasks require different core resources. For example, computationally intensive tasks (image analysis, defect detection) place more emphasis on CPU and GPU utilization, while memory-intensive tasks (such as big data analysis, database queries) place more emphasis on memory utilization, and network-intensive tasks (such as API services) place more emphasis on the current number of connections. Therefore, this application pre-constructs a database of indicator weights to determine the resource indicator bias for each task type.

[0177] In this embodiment, the original data is parsed from the standardized data. The task type is determined, and then the corresponding target weight sequence is queried from the indicator weight database.

[0178] (4-2-4) Calculate the variance of multiple test values ​​for each core resource indicator. and average And filter out the maximum variance for each server node. ;

[0179] Among them, variance This is used to reflect the stability of the indicator when tested multiple times. If the stability is poor, there may be an abnormal situation that makes it unusable.

[0180] (4-2-5) Maximum variance over multiple server nodes Average value of each core resource indicator Normalization is performed to obtain the normalized maximum variance. and the normalized average of each core resource metric Based on the maximum variance Average value of each core resource indicator And calculate the load score for each server node using the target weight sequence. The load rating The mathematical expression is:

[0181]

[0182] In the formula, For the first in the target weight sequence Individual rights;

[0183] In this embodiment, the normalization method used is the min-max normalization method.

[0184] in, This involves using a weighted sequence to weight the average values ​​of various core resource indicators. This is a stability evaluation parameter. Since stability and reliability are more important when performing tasks, the exponential change is used to amplify the impact of stability on the overall score.

[0185] (4-2-6) Load scoring from multiple server nodes Filter for lowest load score and the lowest load score The corresponding server node is used as the target node.

[0186] Final minimum load score This represents the most suitable approach for processing the current raw data. The server node.

[0187] In the above process, the indicator weight database uses historical data combined with the information entropy method for analysis. The entropy method is an objective weighting method based on information theory, which determines the weight of each resource indicator by calculating its information entropy. The specific steps and examples are as follows:

[0188] S1, Obtain a historical running data sample set from multiple server nodes, wherein the historical running data sample set includes running data samples from multiple sampling time points, and the running data samples include the values ​​of running tasks and core resource indicators;

[0189] If we need to analyze the weights of CPU utilization, memory utilization, GPU utilization, and connection count, then we need to collect runtime data samples that include task type, CPU utilization, memory utilization, GPU utilization, and connection count. Multiple runtime data samples constitute the historical runtime data sample set.

[0190] S2, the running data sample set is divided into multiple data units based on the type of the running task, wherein each data unit corresponds to a task type;

[0191] S3 represents the values ​​of core resource indicators for multiple running data samples in each data unit. Normalization is performed to obtain normalized core resource indicator values. ,in, Indicates the sequence number of the running data sample;

[0192] The normalization also uses the min-max normalization method.

[0193] S4, based on the normalized core resource index value Calculate each core resource metric Information entropy The information entropy The mathematical expression is:

[0194]

[0195]

[0196] In the formula, This indicates the number of multiple running data samples in a data unit. Represents a probability distribution;

[0197] The lower the information entropy, the more concentrated the data distribution of the indicator (i.e., the more significant its impact on the task), and therefore the higher its weight; conversely, the higher the information entropy, the lower its weight.

[0198] S5, calculates core resource metrics Redundancy , And according to the redundancy Calculate core resource indicators weight Among them, core resource indicators weight The mathematical expression is:

[0199]

[0200] In the formula, Indicates the quantity of core resource indicators;

[0201] Finally, the information entropy is processed and transformed to obtain the weight of each resource indicator corresponding to each task type.

[0202] S6, based on the weights of multiple core resource metrics for each task type. Construct a weight sequence and build an indicator weight database based on the weight sequences of multiple task types.

[0203] The above analysis process can objectively quantify the importance of each resource indicator to different tasks, serving as the data basis for the above load algorithm.

[0204] (4-3) Data distribution

[0205] (4-3-1) TCP long connection: Establish a TCP long connection between the load balancing module and the target node;

[0206] This application aims to avoid frequent TCP connection establishment and closure, reduce handshake overhead, and improve transmission efficiency; while maintaining connection stability, making it suitable for high-frequency data interaction scenarios. When request distribution fails (e.g., due to sudden node failure or network interruption), a healthy node is automatically selected for retrying, ensuring no task is lost and improving system fault tolerance.

[0207] Specific construction methods include:

[0208] S1, a connection request is sent to the current target node based on the load balancing module;

[0209] S2, upon receiving a response from the current target node, a TCP long connection is established based on the response; if no response is received from the current target node after the target time has elapsed, or if an error code is received from the current target node, a new target node is selected from the healthy node pool based on a load balancing algorithm, wherein both the response and the error code are generated based on the connection request;

[0210] S3, take the new target node as the current target node, and return to step S1 until a TCP long connection is established; or, until the number of reconnections exceeds a preset reconnection threshold; when the number of reconnections exceeds the preset reconnection threshold, trigger an alarm mechanism and record an error log.

[0211] When the load balancer sends a request to the target node, if no response is received within a timeout period or an error code (such as 5xx) is received, the distribution is considered a failure. A new node is immediately selected from the healthy node pool (using a load balancer algorithm). The original request is resent to the new node, with a configurable number of retries (e.g., a maximum of 3 retries). If multiple retries fail, an alarm mechanism is triggered and an error log is recorded.

[0212] (4-3-2) Package the standard data into a JSON data packet; and send the JSON data packet to the target node based on the TCP long connection.

[0213] TCP long connections allow for reuse and transmission, specifically including:

[0214] The load balancer establishes a persistent TCP connection with the backend nodes (maintaining the connection by configuring the keepalive parameter).

[0215] The first request is sent through a new connection, and subsequent requests reuse the established connection without the need for a three-way handshake.

[0216] Regularly check connection activity; if a connection fails, close it and re-establish a new connection.

[0217] In another embodiment of this application, the process of real-time distribution based on node health status and load algorithm is as follows:

[0218] Access request: The standardized JSON data packet arrives at the nginx load balancer via the RESTful API.

[0219] Health status filtering: The load balancer first filters out nodes that are in an unhealthy state (such as nodes that have been marked as faulty or timed out), and only retains the pool of healthy nodes.

[0220] Load balancing algorithm scheduling: Based on the healthy node pool, a preset load balancing algorithm (such as minimum number of connections) is applied to calculate the optimal target node.

[0221] Request forwarding: Forwards the JSON data packet to the selected backend processor node.

[0222] Dynamic adjustment: Monitor node load status in real time (such as CPU utilization, memory usage, etc.). If the node load is too high or the health status changes, update the node pool immediately and adjust the distribution strategy for the next time.

[0223] (5) Storage interaction module: Based on pre-set business logic, it performs data cleaning, aggregation, and other operations, and realizes hot backup storage of data through a dual-write mechanism. It uses a time-series database (such as QuestDB) to record raw data and uses a relational database (such as MySQL) to persist structured statistical processing results. It also supports API interaction with third-party systems (such as MES, SCADA) to output the required structured data (Structured_Data).

[0224] Specifically, cleaning and aggregation need to be based on business logic. For example, the inspection results uploaded from the quality inspection station may be invalid (due to on-site debugging, system abnormalities, algorithm timeouts, etc.) and need to be cleaned. The total result obtained by merging multiple inspection results is the inspection status of a lens.

[0225] Figure 7 This is a flowchart illustrating the standard request processing in one embodiment of this application, such as... Figure 7As shown, when a request is received from the load balancer Nginx, the backend server processes the request, outputs structured data by calling a third-party API and responds to the load balancer Nginx, and finally responds to the client.

[0226] (6) Output module: For data that needs to be fed back in real time (such as PLC control signals and production parameters), a low-latency channel interaction (such as OPC UA, ModBus, TCP / IP) is used to reverse write the final result data packet (Result_Packet) with status code. Figure 8 This is a schematic diagram of the output process in one embodiment of this application, such as... Figure 8 As shown, upon receiving a response, the JSON data packet corresponding to the response information is unpacked, and then a specific communication method is selected. The data is then written back according to the selected communication method.

[0227] This invention relates to a data acquisition system for a contact lens production line. Based on a hot standby architecture, the system ensures data acquisition security through a dual-channel redundant acquisition structure. Simultaneously, for the multi-source heterogeneous data generated by the contact lens production line, this application adapts and acquires data by creating subscription tasks, active polling tasks, and passive callback tasks. The acquired data undergoes deduplication and structuring processing to obtain labeled data with traceability tags, unifying the multi-source heterogeneous data structure while meeting auditing and traceability requirements. Addressing the problems of equipment information silos, insufficient data real-time performance, and poor storage reliability inherent in traditional data acquisition methods, this application significantly improves the acquisition efficiency and completeness of key data such as process parameters, equipment status, and tray transfer information through standardized access to multi-source heterogeneous data, real-time edge computing processing, and distributed database technology. By employing industrial-grade hot standby redundant transmission channels and persistent storage mechanisms, the system mitigates the risk of data loss due to network fluctuations or equipment failures in existing technologies, ensuring highly reliable storage of high-frequency dynamic parameters such as pad printing positioning accuracy, filling pressure, and mold closing temperature, providing a stable data foundation for production traceability and process optimization. At the same time, a load balancing module is provided to ensure load balancing of the server nodes receiving data, thus ensuring a stable and reliable working environment for subsequent processes.

[0228] This embodiment also provides an electronic terminal, including: a processor and a memory;

[0229] The memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory so that the terminal performs any of the methods in this embodiment.

[0230] As will be understood by those skilled in the art, the computer-readable storage medium described in this embodiment allows for the implementation of all or part of the steps in the above method embodiments by computer program-related hardware. The aforementioned computer program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0231] The electronic terminal provided in this embodiment includes a processor, a memory, a transceiver, and a communication interface. The memory and the communication interface are connected to the processor and the transceiver and complete communication between them. The memory is used to store computer programs, the communication interface is used to perform communication, and the processor and the transceiver are used to run the computer programs, so that the electronic terminal performs the steps of the above method.

[0232] In this embodiment, the memory may include random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device.

[0233] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0234] In the above embodiments, although the invention has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. The embodiments of the invention are intended to cover all such substitutions, modifications, and variations falling within the broad scope of the appended description.

[0235] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the present invention.

Claims

1. A data acquisition system based on a contact lens production line, characterized in that, include: The task creation module is used to create collection tasks based on a hot standby architecture, wherein the collection tasks include subscription tasks, active polling tasks, and passive callback tasks. The standardization processing module is used to establish a deduplication mechanism for the data collection task and collect raw data from the contact lens production line based on the data collection task with the deduplication mechanism; the raw data is then processed in a structured manner to obtain standard data with traceability tags. A load balancing module is used to obtain health information of each node in the backend processor cluster, filter healthy nodes based on the health information and construct a healthy node pool, filter target nodes from the healthy node pool based on a load balancing algorithm, and distribute the standard data to the target nodes. The filtering of target nodes from the healthy node pool based on the load balancing algorithm includes: sending a test request to all server nodes in the health node pool multiple times; extracting multiple core resource indicators from test feedback information received from the server nodes, wherein the multiple core resource indicators include CPU occupancy, memory occupancy, GPU occupancy, and current connection number, and the test feedback information is generated based on the test request , wherein the multiple core resource indicators include CPU occupancy, memory occupancy, GPU occupancy, and current connection number, and the test feedback information is generated based on the test request is a natural number; extracting a task type from the standard data, and selecting a target weight sequence based on the task type in the standard data and a pre-constructed index weight database, wherein the index weight database includes weight sequences of multiple task types, and a weight sequence includes weights of multiple core resource indicators; calculating the variance and the average of the multiple test values of each core resource indicator ; and screening out the maximum variance of each server node; normalizing the maximum variance , the average of each core resource indicator of multiple server nodes to obtain normalized maximum variance and normalized average of each core resource indicator , and calculating the load score of each server node based on the maximum variance , the average of each core resource indicator , and the target weight sequence , wherein the mathematical expression of the load score is​ wherein, is the i-th weight in the target weight sequence; the load score of each server node is calculated according to the load score calculation formula: the corresponding server node is taken as the target node.​​​ The storage interaction module is used to perform data cleaning and aggregation on the standard data based on the business logic of the standard data source device, and store the cleaned and aggregated standard data in the database. The output module is used to generate a result data table with status codes based on the standard data and then write it back when the type of the standard data is a target type that requires real-time feedback.

2. The contact lens production line based data collection system of claim 1, wherein, Also includes: The initialization module is used to initialize the data acquisition system before creating an acquisition task. The initialization configuration includes system resource initialization, data deduplication module initialization, hot standby channel module initialization, device communication module initialization, callback server initialization, acquisition, and interactive task initialization.

3. The contact lens production line based data collection system of claim 1, wherein, Create a data acquisition task based on a hot standby architecture, including: Parse the subscription task configuration; create a Subscription object based on the OPC UA protocol, configure the PublishingInterval and LifetimeCount parameters; and create a Client instance based on the MQTT protocol, configure the QoS level and KeepAlive interval parameters to complete the subscription task establishment; Parse the parameters of the active polling task, obtain available connections from the connection pool, and create an active polling task based on the available connections; Start the callback data processing thread pool, start the callback server and enable the service, listen to the message queue, and complete the construction of the passive callback task.

4. The contact lens production line based data collection system of claim 1, wherein, Establish a deduplication mechanism for the data acquisition task, and acquire raw data from the contact lens production line based on the data acquisition task with the deduplication mechanism, including: Based on the subscription task, initial raw data is collected. When a device status change is received, the initial raw data of the two paths under the hot standby architecture is compared. When the unique encoding of the collection source of the initial raw data of the two paths is consistent and the difference of the timestamp does not exceed the preset threshold, it is determined that the initial raw data of the two paths is duplicated. Based on the pre-configured priority rules, one of the initial raw data paths is retained to obtain the raw data. The initial raw data of the two paths under the hot standby architecture comes from the master server node and the slave server node, respectively. In any polling cycle, the master server node and the slave server node build a polling task for polling devices with the same acquisition source unique code, calculate the timestamp difference between the task building timestamp of the master server node and the task building timestamp of the slave server node, and when the timestamp difference is not more than a preset threshold, select one of the master server node and the slave server node to create a polling task based on a preconfigured priority rule, and obtain raw data based on the polling task of each polling cycle; Obtain the message queue uploaded through the callback task, and ensure that the same data is only received by the server node with the highest priority among the master server node and the slave server node through the single consumer mode of the message queue, to obtain raw data, wherein the priority of the master server node and the slave server node is determined based on a preconfigured priority rule, and the priority rule includes: when the master server node is in a normal state, the priority of the master server node is higher than that of the slave server node, and when the master server node is in an abnormal state and the slave server node is in a normal state, the priority of the master server node is lower than that of the slave server node.

5. The contact lens production line based data collection system of claim 1, wherein, Obtain the health information of each node in the backend processor cluster, and filter healthy nodes based on the health information to build a healthy node pool, including: Sending a health check request to multiple server nodes in the backend processor cluster at a regular time; When receiving passive feedback information or active feedback information from the multiple server nodes, extracting a response status code and a timestamp from the active feedback information, or extracting a response time, an error rate, a CPU occupancy rate, and a memory occupancy rate from the passive feedback information, wherein the passive feedback information is generated based on the health check request, and the active feedback information is information uploaded by the server node at a regular time; Calculating the time difference between the timestamp and the current time point, and taking the response status code corresponding to the timestamp with a time difference less than a threshold as an effective response status code, and determining the available state of the server node based on the effective response status code; Comparing the response time with a preset response time threshold, comparing the error rate with a preset error rate threshold, and comparing the CPU occupancy rate and the memory occupancy rate with a preset occupancy rate threshold respectively; when the response time is less than or equal to the preset response time threshold, the error rate is less than or equal to the preset error rate threshold, and the CPU occupancy rate and the memory occupancy rate are both less than the preset occupancy rate threshold, the available state of the corresponding server node is marked as available; Building a healthy node pool based on all server nodes with an available state of available.

6. The contact lens production line based data collection system of claim 1, wherein, The method for building the index weight database includes: Obtaining a historical running data sample set from multiple server nodes, wherein the historical running data sample set includes running data samples at multiple sampling time points, and the running data sample includes a running task and a value of a core resource index; Dividing the running data sample set samples into multiple data units based on the type of the running task, wherein each data unit corresponds to a task type; values of the core resource indicator for a plurality of run data samples in each data unit performing normalization to obtain normalized core resource indicator values wherein denotes a sequence number of the run data sample; based on the normalized core resource index value calculating the information entropy of each core resource index wherein the mathematical expression of the information entropy is:​ wherein, denotes the number of running data samples in the data unit, denotes the probability distribution; core resource index redundancy , redundancy core resource index weight wherein the weight core resource index is mathematically expressed as wherein, denotes the number of core resource indicators; a weight of a plurality of core resource indicators based on each task type a weight sequence is constructed, and a database of indicator weights is constructed based on the weight sequence of the plurality of task types.

7. The contact lens production line based data collection system of claim 1, wherein, And distributing the standard data to the target node, including: Building a TCP long connection between the load balancing module and the target node; Packing the standard data into a JSON data packet; and sending the JSON data packet to the target node based on the TCP long connection.

8. The contact lens production line based data collection system of claim 7, wherein, Building a TCP long connection between the load balancing module and the target node, including: S1, sending a connection request to the current target node based on the load balancing module; S2, upon receiving a response from the current target node, building a TCP long connection based on the response; if a response from the current target node is still not received after a target time length, or if an error code is received from the current target node, selecting a new target node from the health node pool based on a load algorithm, wherein the response and the error code are both generated based on the connection request; S3, taking the new target node as the current target node, and returning to step S1 until the TCP long connection is built; or until the number of reconnections exceeds a preset reconnection threshold; when the number of reconnections exceeds the preset reconnection threshold, triggering an alarm mechanism and recording an error log.

9. The contact lens production line based data collection system of claim 1, wherein, Storing the cleaned and aggregated standard data into a database, including: Recording the original data through a time series database, and persisting the structured statistical processing results through a relational database.

Images