Data clustering processing method and system for AMR battery charging management

Abstract

The invention discloses a data clustering processing method and system for AMR battery charging management, and relates to the technical field of logistics transportation, and the method comprises the steps: receiving an AMR service request and corresponding report data; storing the reported data in a pre-constructed standardized data dictionary; screening a candidate server set according with the AMR service request type according to the AMR service request, calculating the health score of the candidate server according to the CPU utilization rate, the available memory and the network delay of the candidate server, and updating the initial weight of the candidate server according to the health score, determining actual priorities according to the newest weights and health scores of the candidate servers, and taking the candidate server with the highest actual priority as a target processing node; and extracting the reported data from the standardized data dictionary and storing the reported data to the selected target processing node. The problem of uneven cold and heat in traditional polling is effectively avoided, and the overall resource utilization rate of the cluster is improved.

Description

Technical Field

[0001] The present invention relates to the field of logistics and transportation technology, and in particular to a data clustering processing method and system for AMR battery charging management. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] With the increasing automation in industrial production, a large number of intelligent logistics AMR (Autonomous Mobile Robot) devices have been widely used. However, the internal power batteries of AMR devices can be difficult to detect potential faults, posing a challenge to daily inspections. Furthermore, the lack of uniformity in battery management systems across different suppliers further complicates battery maintenance and management.

[0004] Traditional AMR control systems, however, cannot meet the business demands of large-scale applications. This is partly because their controller systems were initially designed with the scale of AMR applications in mind. Therefore, the computing power of a single server is already saturated, unable to meet the demands of high availability, high-frequency, and massive requests. Furthermore, AMR manufacturers are limited by their experimental scenarios, making it difficult for them to simulate real-world industrial environments, especially those required for large-scale applications. Consequently, their control systems are unable to meet these requirements.

[0005] The emergence of clustering technology addresses the various challenges faced by AMRs in large-scale deployment. Clustering management fully leverages the capabilities of each service node, transforming a single AMR control server into a cluster of multiple servers with diverse functions. This addresses the high availability and high-frequency performance requirements of AMR control systems. However, existing clustering management load distribution strategies suffer from uneven load distribution due to the traditional round-robin distribution process, leading to overloaded servers and idle resources on other servers, thus reducing resource utilization. Summary of the Invention

[0006] To solve the above problems, the present invention proposes a data clustering processing method and system for AMR battery charging management. According to the performance and health score of the candidate servers, the priority of each candidate server is dynamically adjusted to dynamically allocate AMR service requests, effectively avoiding the hot and cold unevenness problem of traditional polling and improving the overall resource utilization of the cluster.

[0007] In order to achieve the above object, the present invention adopts the following technical solutions: In a first aspect, the present invention provides a data clustering processing method for AMR battery charging management, comprising: Receive AMR service requests and corresponding reported data; The reported data is stored in a pre-built standardized data dictionary after format standardization. The standardized data dictionary uses the AMR number as the key and the data status as the value to build a memory hash table. The memory hash table is updated based on the preset logic to determine whether the reported data has any status change. Based on the AMR service request, a set of candidate servers that meet the AMR service request type is screened. The health score of the candidate server is calculated based on the CPU utilization, available memory, and network latency of the candidate server. The initial weight of the candidate server is updated based on the health score. The actual priority of the candidate server is determined based on the latest weight and health score of the candidate server. The candidate server with the highest actual priority is selected as the target processing node. The reported data is retrieved from the standardized data dictionary and stored in the selected target processing node.

[0008] As an optional implementation, the process of determining whether the reported data has a status change includes: If it is the first time data is reported, it will be unconditionally determined to be a status change; If the data is not reported for the first time, the voltage change, temperature change and operating status change are compared in turn. When the absolute value of the voltage difference exceeds the set threshold, it is determined to be a valid change; when the temperature change amplitude exceeds the set threshold, it is determined to be a valid change; when the operating status switches, it is determined to be a valid change; When there is at least one valid change, it is determined that a state change has occurred.

[0009] As an optional implementation, the format standardization of the reported data is to convert the reported data into a prescribed data format through a data dump service and store it in a standardized data dictionary; It includes: parsing heterogeneous data, being compatible with protocols from different manufacturers, and mapping them to unified fields through template configuration; aggregating time windows, and only retaining the first and last data in the window if the same status is reported continuously; and hierarchical storage of different types of data.

[0010] As an optional embodiment, The health scores of the candidate servers are: ; in, 、 and Respectively CPU utilization, remaining memory, and network latency of each candidate server; 、 and Respectively The weights of CPU utilization, remaining memory, and network latency of the candidate servers, and .

[0011] As an optional implementation method, the process of updating the initial weight of the candidate server includes: determining whether the health score of the current candidate server is less than the set score threshold; if so, downgrading the current candidate server and recalculating the health score; if not, taking the product of the current weight of the current candidate server and the health score as the actual priority of the current candidate server.

[0012] As an optional implementation method, the process of constructing the standardized data dictionary includes: parsing the original data format of each manufacturer's AMR, analyzing the field naming rules and units, generating a manufacturer agreement comparison table, thereby designing a unified field naming, data type and unit, and mapping the manufacturer's original data to the standardized data dictionary.

[0013] In a second aspect, the present invention provides a data clustering processing system for AMR battery charging management, comprising: A receiving module configured to receive an AMR service request and corresponding reported data; A storage module is configured to store the reported data after format standardization in a pre-built standardized data dictionary, wherein the standardized data dictionary uses the AMR number as a key and the data status as a value to construct a memory hash table, and determines whether there is a status change of the reported data according to a preset logic to update the memory hash table; a selection module configured to screen a set of candidate servers that meet the type of the AMR service request according to the AMR service request, calculate a health score of the candidate server according to the CPU utilization, available memory, and network latency of the candidate server, update an initial weight of the candidate server according to the health score, determine an actual priority according to the latest weight and health score of the candidate server, and select the candidate server with the highest actual priority as the target processing node; The distribution module is configured to retrieve the reported data from the standardized data dictionary and store it in the selected target processing node.

[0014] In a third aspect, the present invention provides an electronic device comprising a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.

[0015] In a fourth aspect, the present invention provides a computer-readable storage medium for storing computer instructions, wherein when the computer instructions are executed by a processor, the method described in the first aspect is performed.

[0016] In a fifth aspect, the present invention provides a computer program product, comprising a computer program, which implements the method described in the first aspect when executed by a processor.

[0017] Compared with the prior art, the present invention has the following beneficial effects: The present invention proposes a data clustering processing method and system for AMR battery charging management. The method stores reported data in a pre-built standardized data dictionary after format standardization, and then persists the cached data in the standardized data dictionary and writes it to a designated server. This improves the system's responsiveness and breaks down a complex step into multiple actions, thereby ensuring the system's rapid response capability. When selecting a server, the candidate server's health score is calculated based on its CPU utilization, available memory, and network latency. The candidate server's initial weight is updated based on the health score, and the actual priority is determined based on the candidate server's latest weight and health score. The candidate server with the highest actual priority is the target processing node. The priority of each candidate server is dynamically adjusted based on the candidate server's performance and health score to dynamically allocate AMR service requests. This strategy effectively avoids the hot and cold unevenness problem of traditional polling through periodic health detection and a weight feedback mechanism, thereby improving the overall resource utilization of the cluster.

[0018] Advantages of additional aspects of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0020] Figure 1 Flowchart of the data clustering processing method for AMR battery charging management provided in Example 1 of the present invention; Figure 2 This is an architecture diagram of the data clustering processing system for AMR battery charging management provided in Example 2 of the present invention. DETAILED DESCRIPTION

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

[0022] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present invention belongs.

[0023] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that the terms "include" and "comprise" and any variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0024] In the absence of conflict, the embodiments of the present invention and the features thereof may be combined with each other.

[0025] Example 1 like Figure 1 As shown, this embodiment provides a data clustering processing method for AMR battery charging management, including: S101: Receive an AMR service request and corresponding reporting data; S102: The reported data is stored in a pre-built standardized data dictionary after format standardization. The standardized data dictionary uses the AMR number as a key and the data status as a value to construct a memory hash table. The reported data is judged according to a preset logic whether there is a status change, so as to update the memory hash table. S103: Based on the AMR service request, a set of candidate servers that meet the AMR service request type is screened. A health score of the candidate server is calculated based on the CPU utilization, available memory, and network latency of the candidate server. The initial weight of the candidate server is updated based on the health score. The actual priority of the candidate server is determined based on the latest weight and health score of the candidate server. The candidate server with the highest actual priority is selected as the target processing node. S104: Retrieve the reported data from the standardized data dictionary and store it in the selected target processing node.

[0026] In this embodiment, the AMR stand-alone machine sends a service request to the control system service cluster, and the control system service cluster receives the AMR service request. The AMR service request includes: device management service, status monitoring service, system warning service, data collection service, data analysis service, data caching service and data writing service, etc.

[0027] In this embodiment, AMRs communicate with a control server in real time via Wi-Fi, shaving peaks and shifting valleys in the massive amounts of AMR battery charging-related data reported, ensuring system stability. This shaving is achieved through multi-level buffering and dynamic flow control, ensuring stable transmission of massive amounts of AMR reported data even during Wi-Fi network fluctuations or peak traffic.

[0028] The specific steps are as follows: (1) Data hierarchical buffering (multi-level queues).

[0029] On the front-end AMR side, each AMR has a built-in ring buffer (capacity of 1,000 data items) to temporarily store reported data when Wi-Fi is interrupted and retransmit it after Wi-Fi is restored. Priority is also marked, with urgent data (such as high temperature alarms) transmitted first and common data (such as location updates) allowed to be delayed.

[0030] On the control server side: a message queue (Kafka) is set up to receive the original reported data from the AMR, and the data is divided into topics (such as voltage_data and alert_data) according to service type. At the same time, the consumption rate of each topic is limited (for example, the alarm topic is limited to 5000 messages / second to prevent downstream overload) to perform traffic shaping.

[0031] (2) Dynamic flow control algorithm.

[0032] Token bucket-based rate limiting: Each AMR group (such as grouping by workshop) is allocated a token bucket, and the token generation rate is dynamically adjusted according to the network status; the token generation rate is: ; in, is the basic rate (such as 100 packets / second); C is the network quality threshold (such as C=1 when the packet loss rate is <5%); k is the smoothing coefficient (the default is 0.5).

[0033] Wi-Fi channel optimization: Using TDMA (time division multiple access) scheduling, different AMR groups are assigned different time slots to send data, reducing conflicts.

[0034] (3) Data aggregation and compression.

[0035] Time window aggregation: For high-frequency but low-value data (such as location updates per second), aggregate it into one record within a 10-second window (retaining the maximum / average value).

[0036] Binary encoding: Use Protocol Buffers instead of JSON, saving 50% bandwidth.

[0037] (4) Elastic consumption and load balancing.

[0038] Kafka Consumer Group: The data analysis service launches multiple consumer instances to process data in parallel by partition. When the message backlog exceeds a threshold (e.g., 100,000), new consumer instances are automatically added to achieve dynamic scaling.

[0039] Degradation strategy: When the system load is >80%, non-critical data (such as historical statistics) is temporarily stored on disk, and real-time alarms are prioritized.

[0040] (5) Real-time monitoring and feedback; monitor Wi-Fi channel utilization, AMR online rate, data latency, etc.; when the Wi-Fi packet loss rate is less than 5%, switch to the 5G backup link; when the Kafka message backlog is less than 10,000, trigger consumer expansion; when the control server CPU load is less than 70%, downgrade non-core services.

[0041] In this embodiment, the reported data of the AMR is stored in the message queue. The reported data in the message queue is retrieved through the data dump service, converted into a specified data format, and stored in a standardized data dictionary.

[0042] Among them, data dump services include: (1) Message consumption and decoupling: Start multi-threaded consumers and pull Kafka messages in parallel by partition to avoid single point bottlenecks.

[0043] (2) Data format standardization; Protocol conversion engine: Heterogeneous data parsing: compatible with JSON / XML / binary protocols from different vendors, mapped to unified fields through template configuration.

[0044] Data validation: Check required fields (such as amr_id and timestamp) and discard invalid data (validation failure rate <0.1%).

[0045] (3) Time window aggregation; Duplicate data filtering: If the AMR continuously reports the same status (such as standby), only the first and last data in the window are retained.

[0046] Compression rate: The storage volume of standby data is reduced by 70%.

[0047] (4) Hierarchical storage routing; Storage policy decisions include: For data types such as real-time monitoring data, the storage target is Redis Cluster, and the judgment condition is data.access_frequency > 10 times / second; For time series data, the storage target is InfluxDB, and the judgment condition is data.metric_typein ["temp", "voltage"]; For data types such as operation logs and storage targets such as Elasticsearch, the judgment condition is data.type == "audit_log".

[0048] In this embodiment, a standardized data dictionary is used to unify the data formats of AMRs from different manufacturers to solve the compatibility problem of heterogeneous devices; The construction of the standardized data dictionary is as follows: (1) Data collection and protocol analysis, the goal is to parse the original data format (JSON / XML / binary, etc.) of each manufacturer's AMR. The steps include: Manufacturer agreement research: Collect data field definitions from each manufacturer (e.g. voltage may be voltage, V, U, etc.).

[0049] Data sampling: Capture the raw data samples actually reported by the AMR and analyze the field naming rules and units (for example, the temperature unit may be ℃ or ℉).

[0050] Protocol documentation: Generate a manufacturer protocol comparison table; as shown in Table 1.

[0051] Table 1 Manufacturer Agreement Comparison Table

[0052] (2) Define a standardized data dictionary. The goal is to design unified field names, data types, and units. Mandatory fields such as amr_id and timestamp must exist, and the units must be standardized, such as voltage → V, temperature → °C, and time → UTC.

[0053] Examples of core fields are shown in Table 2; Table 2 Core fields

[0054] (3) Data conversion engine development. Its goal is to map the manufacturer's original data to a standardized dictionary. Implementation methods include: Configuration-driven conversion: Use YAML / JSON configuration files to define field mapping rules.

[0055] Exception handling: Missing fields: Fill with default values ​​or mark as null. Unit conversion: Temperature ℉→℃, formula: (x- 32) / 1.8.

[0056] (4) Data verification and cleaning, whose goal is to ensure that the converted data conforms to standard specifications.

[0057] Verification rules: Range check: voltage (0-1000V), temperature (-20~100℃). Type check: timestamp must be a valid ISO timestamp.

[0058] (5) Dictionary storage and index construction: Its goal is to efficiently store standardized data and support fast queries. Specifically, it reduces query complexity by building hash indexes for frequently queried fields (such as amr_id).

[0059] (6) Dynamic protocol extension: Its goal is to support new vendors without code modifications. The implementation process includes: storing vendor protocol configurations in a database and dynamically loading them. When adding a new vendor, only one configuration record needs to be added.

[0060] (7) Monitoring and tuning: The goal is to ensure the stability and performance of the conversion service. Monitoring metrics include: conversion success rate (≥99.9%); average latency (<50ms / item); and storage compression ratio (e.g., Parquet format compression ratio >5:1).

[0061] In this embodiment, the data dump service analyzes the latest status data in the dictionary in real time. If the status of the AMR changes, it is recorded immediately. Otherwise, the AMR is considered to be on standby at the same place and no repeated records are made. The repeated standby status is filtered out through the time window aggregation algorithm to reduce invalid data storage (typical compression rate can reach more than 70%).

[0062] The process of real-time analysis of the latest status data in the dictionary includes: In the standardized data dictionary, an in-memory hash table is constructed with the AMR number as the key and the data status as the value. The in-memory hash table is used to store the latest AMR status. When new data arrives, the following logic is used to determine whether to record it: (1) Initial data reporting processing: When the first data report of an AMR device is detected, it is unconditionally determined to be a state change and forced to be recorded to ensure that all devices can establish an initial state baseline.

[0063] (2) Detection of key parameter changes: For data that is not reported for the first time, compare the changes in the following core parameters in turn: Voltage change: When the absolute value of the voltage difference between the new and old data exceeds 0.1 volt, it is considered a valid change; Temperature change: When the temperature reading changes by more than 0.5 degrees Celsius, it is considered a valid change; Operating status: When the device's operating status changes (for example, from "charging" to "standby"), it is directly determined to have changed.

[0064] (3) Composite judgment principle: The three detection conditions above are in an "OR" logical relationship. As long as any one of the conditions is met, a state change is considered to have occurred. This design ensures that the system can capture various important state changes, including: sudden voltage fluctuations; abnormal temperature rise; and device operating mode switching.

[0065] The above technical implementation features include: floating threshold mechanism: different change thresholds can be configured for different device types; time decay compensation: devices that have not been updated for a long time will automatically lower the change judgment standard; data verification: eliminates false changes caused by sensor false alarms; through refined state change detection, while ensuring data integrity, storage efficiency and anomaly detection sensitivity are significantly improved.

[0066] In this embodiment, the time window aggregation algorithm significantly improves the storage efficiency of standby state data through intelligent compression technology. Its workflow is as follows: (1) Data window management mechanism; A separate time window (10 minutes by default) is maintained for each AMR device. Newly arriving monitoring data is added to the corresponding device's window in real time. When the window contains insufficient data (fewer than 2 records), the processing flow is temporarily deactivated to ensure sufficient data samples for analysis.

[0067] (2) Intelligent judgment of standby status; When the window data meets the processing conditions, deep state analysis is performed: first, the earliest and latest two key data records in the time window are extracted; then the operating status fields of all data points in the window are fully scanned; if and only if the status of all data points is "Standby", it is determined to be in a continuous standby state.

[0068] (3) Optimize storage processing; For confirmed continuous standby state windows, intelligent compression storage is enabled. Specifically, only two complete data records are retained, namely the start and end times of the window; the start and end timestamps of the standby period are accurately recorded (ISO 8601 format); all redundant standby state data points in the middle are automatically discarded; and the data window corresponding to the device is cleared to prepare for receiving new data.

[0069] (4) Abnormal state handling; When any non-standby state data is detected in the window, the aggregation processing of the current window is terminated immediately, all original data records are completely saved, and the window is maintained to continue collecting subsequent data.

[0070] The technical advantages of the above process are: improved storage efficiency: the standby data within 10 minutes is compressed from 600 to 2, with a compression rate of 99.67%; time accuracy preservation: by accurately recording the start and end times, it does not affect the statistical analysis of subsequent usage duration; low resource consumption: a single processing consumes only 0.5ms of CPU time on average; adaptive adjustment: the window size can be dynamically configured according to the device type (5-30 minutes).

[0071] In this embodiment, after the system is started, the AMR data of the corresponding manufacturer is actively collected through the API interface provided by the manufacturer. At the same time, modular permission allocation is implemented based on the RBAC (role-based access control) model to meet the multi-level user operation requirements and provide users with an entry to the system modules and permissions. At the same time, clustered storage and management strategies are adopted to store data on the designated server. Storing on the designated server means persisting the data cached in the standardized data dictionary and writing it to the designated server hard disk. Due to the huge amount of data, during the processing process, the data is first stored in the standardized data dictionary, and then taken out of the standardized data dictionary and persisted to the designated server. The purpose of using this method is to improve the system's responsiveness and decompose a complex step into multiple actions, thereby ensuring that the system has a rapid response capability.

[0072] In this embodiment, due to the large number of AMR devices, there are many concurrent requests at the same time. In the process of responding to AMR service requests, the AMR service requests are evenly distributed to different background application servers through a load balancing strategy.

[0073] The application server is used to deploy various microservice systems and provide basic services and computing power support for system operation. The application server determines the data storage server to which the AMR service should be redirected based on the currently requested AMR service. The core of the specific judgment logic is dynamic routing based on service type identification and data characteristics.

[0074] Among them, a hierarchical decision-making mechanism is adopted; For real-time monitoring requests, which require frequent access and are latency-sensitive, the system automatically routes these requests to a Redis in-memory database cluster. This design prioritizes the millisecond-level response characteristics of in-memory storage, ensuring that the real-time requirements of monitoring data are met.

[0075] Data analysis requests, specifically batch computing and large-scale data analysis tasks, are directed to the Hadoop Distributed File System (HDFS) cluster. This routing option leverages HDFS's high throughput and batch processing advantages, making it suitable for processing massive amounts of historical data.

[0076] For alarm event processing, data with time series characteristics is specifically routed to the time series database InfluxDB. This specially optimized storage solution efficiently handles continuous records with timestamps, supporting fast time range queries and aggregate analysis.

[0077] For default request processing, which refers to regular requests that do not fall into the aforementioned special categories, a conservative strategy is adopted, routing them to a standard relational database cluster (such as SQL Server). This ensures the baseline storage requirements of various businesses while maintaining system compatibility and stability.

[0078] The technical features of this routing mechanism are: it adopts a multi-level decision tree structure, and the judgment process is efficient and fast; each routing branch is optimized for storage of specific data types; the default routing ensures that the system has complete fault tolerance capabilities.

[0079] The detailed judgment dimensions of the hierarchical decision-making mechanism are shown in Table 3.

[0080] Table 3 Judgment Dimensions

[0081] Secondly, it also involves a high-speed cache read server, which is used to store various frequently read hot data. It builds a distributed cache based on RedisCluster to support millisecond-level hot data response.

[0082] The specific implementation steps are as follows: (1) Hot data identification and caching strategy; Data classification: Thermal data: AMR real-time status (such as voltage and temperature) and frequently accessed configuration parameters (such as charging threshold).

[0083] Cold data: historical charging records (not accessed for more than 24 hours).

[0084] (2) Redis Cluster deployment; Node planning: At least six nodes (three active and three passive), deployed across racks to avoid single points of failure. Each active node is configured with 16GB of memory and SSD persistence.

[0085] Data sharding: CRC16 hash slot (16384 slots) is used for sharding.

[0086] (3) Highly concurrent read and write processes; Writing process (data synchronization): AMR reports data → data is written to the server → written to the master Redis → asynchronously copied to the slave Redis → write success is returned.

[0087] Strong consistency: Enable the WAIT 1 command for critical data (such as alarm status) to ensure that at least one slave node completes synchronization.

[0088] Performance indicators: Cache hit: ≤1ms (Redis memory operation); cache miss: 10-50ms (database query + cache backfill).

[0089] For the data write server, it is used to implement data writing services, synchronize the latest data to the cache read server, and ensure data persistence and high availability through WAL (write-ahead log).

[0090] In this embodiment, the process of extracting the reported data from the standardized data dictionary and storing it in the selected target processing node includes: First, the received AMR service request can be classified; the specific classification logic includes: (1) High priority request determination: Determine whether the current AMR service request is "status monitoring service" or "system warning service"; If the current AMR service request type belongs to "status monitoring service" or "system warning service", the AMR service request will be automatically marked as the highest priority (HIGH); this type of AMR service request usually involves key business functions such as real-time equipment status tracking and safety warnings.

[0091] (2) Normal priority request determination: If the type of the current AMR service request does not belong to "status monitoring service" or "system warning service", the AMR service request will be uniformly classified as normal priority (NORMAL). This type of AMR service request is a non-real-time business request.

[0092] The design features of this classification mechanism are: using a whitelist approach to define key business types to ensure that system resources prioritize core functions; achieving rapid classification through simple conditional judgments, with processing delays of less than 1 millisecond; supporting dynamic expansion, and new business types can be added to the priority rule library through configuration.

[0093] Secondly, a set of qualified candidate servers is screened from the resource pool based on the service type of the AMR service request (such as real-time monitoring, data analysis, etc.). These candidate servers have the same service capabilities but may be in different operating states.

[0094] Then, based on the detection indicators of CPU utilization, remaining memory and network delay of each candidate server, the health score of the candidate server is calculated to detect the health status of the candidate server.

[0095] No. The health scores of the candidate servers are: ; in, 、 and Respectively CPU utilization, remaining memory, and network latency of each candidate server; 、 and Respectively The weights of CPU utilization, remaining memory, and network latency of the candidate servers, and ,for example 、 and They are 0.4, 0.3, and 0.3 respectively.

[0096] For each candidate server, a dynamic comprehensive evaluation value is calculated, which is determined by two key factors: Basic weight: reflects the inherent processing power of the server, which is usually determined by the hardware configuration (such as the number of CPU cores and memory size). It is a pre-set static parameter.

[0097] Health score: reflects the current operating status of the server in real time, with a value between 0 and 1, calculated based on multiple dynamic indicators.

[0098] Therefore, an initial weight is assigned to each candidate server based on its performance, such as a high-performance server is given a weight of 3 and a common server is given a weight of 1; Determine whether the health score of the current candidate server is less than the set score threshold; If not, the product of the current weight of the current candidate server and the health score is used as the actual priority of the current candidate server; If so, the current candidate server is downgraded and the health score is calculated again; AMR service requests are processed in order of priority; and for the current AMR service request, the candidate server with the highest actual priority is selected to process the current AMR service request based on the actual priority of the candidate servers, to ensure that high-performance or high-availability nodes bear more load.

[0099] For example, a candidate server with a weight of 3 and a health score of 0.9 has an actual priority of 2.7, which is much higher than a candidate server with a weight of 1 and a health score of 0.7 (priority 0.7).

[0100] This embodiment's method uses the maximization principle, selecting the server with the highest comprehensive evaluation value (basic weight × health score) as the target processing node. This multiplication method ensures that high-configuration servers are prioritized when they are in good health; even servers with lower configurations may be selected when they are in excellent health; and servers with abnormal health (health scores approaching 0) are automatically avoided.

[0101] This method dynamically adjusts the priority of each candidate server based on its performance and health score, effectively allocating AMR service requests. This strategy, through periodic health checks and a weighted feedback mechanism (such as triggering downgrades for consecutively low scores), effectively avoids the "hot / cold" problem of traditional polling and improves overall cluster resource utilization. Tests show that this method reduces server load variation from ±40% to ±15% in a concurrent scenario with 5,000 AMRs, significantly improving response stability.

[0102] The above method can update the health score of the candidate server at regular intervals (such as 5 seconds). If the health score of a candidate server is less than the score threshold for multiple consecutive times (such as 3 times), it will be directly reduced to 0, realizing real-time dynamic feedback adjustment and overload protection.

[0103] In this embodiment, the advantages of the above process are: Real-time: The health score is updated every 30 seconds to ensure that routing decisions are based on the latest status; Fairness: This takes into account both hardware capability differences and real-time load conditions. Fault tolerance: Automatically avoid faulty or overloaded nodes to improve overall system reliability; This dynamic weight routing mechanism effectively solves the "hot and cold unevenness" problem caused by the traditional polling algorithm and achieves optimal resource utilization.

[0104] In this embodiment, an exception handling mechanism is designed, including: Failover: If the target server becomes unresponsive (3 seconds timeout), it will automatically switch to a backup node of the same type.

[0105] Data consistency: WAL (write-ahead log) ensures write atomicity before and after redirection.

[0106] The technical advantages include: Maximum performance: Hot data is routed to the in-memory repository, while cold data is archived to low-cost storage. Elastic scalability: Adding new storage nodes only requires updating the routing table without downtime. Fault isolation: A single storage failure does not affect other services (e.g., a Redis outage only affects real-time monitoring).

[0107] As you can understand, high-performance servers are servers that excel at handling complex computing tasks, boasting high computing power, stability, and reliability. They are typically equipped with high-performance CPUs, GPUs, or other processing units, enabling them to quickly process large amounts of data and complex computing tasks, such as artificial intelligence computing, deep learning, and large-scale data processing. Conventional servers are used to meet a variety of computing needs, such as web serving, database management, and file sharing. They primarily utilize a CPU as their primary chip.

[0108] As an optional implementation, when the AMR service request is for data analysis services, which are intensive and require high-CPU servers, request redirection is performed. This includes selecting a server group specifically configured for computing from the currently available server cluster; evaluating the real-time resource status of these servers; and selecting the application server with the highest CPU utilization as the target processing node.

[0109] As an optional implementation method, when the AMR service request is a data write service, the data write service is an I / O intensive request and a high-memory server should be used to perform a request redirection operation; including: screening out a data write server group for writing data from the currently available server cluster; and evaluating the memory of these servers, and selecting the server with the largest remaining memory as the target processing node.

[0110] Technical features of this routing strategy include: dynamic load awareness, which selects the optimal node based on real-time monitoring data, rather than fixed allocations; resource optimization, which ensures that compute-intensive tasks always receive the best computing resources, and I / O-intensive tasks always receive the best storage resources; and health status integration, which considers the server's overall health score during evaluation. Exception handling mechanisms include automatic downgrade to a suboptimal node when the preferred server is unavailable, and automatic capacity expansion when resource warning thresholds are triggered.

[0111] In this embodiment, data cluster management provides users with server cluster management configuration parameters. Through parameterized configuration, server resources can be elastically scaled to cope with peak business fluctuations. As core infrastructure, data cluster management is tightly coupled with upstream and downstream processes to form a closed-loop resource control system.

[0112] The following are the key connections: (1) Association with the data acquisition layer; Dynamic resource allocation: When the number of AMR devices increases suddenly (such as during e-commerce promotions), cluster management automatically expands the Kafka consumer instance through parameterized configuration to ensure high-concurrency data collection without packet loss.

[0113] Related parameters: collector_max_instances: Maximum number of instances of the collection service (default 50, adjustable to 200). network_bandwidth_per_node: Single node bandwidth quota (e.g. 1Gbps).

[0114] (2) Association with the data processing layer; Dynamic allocation of computing resources: When the real-time analysis service detects a surge in state changes (such as large-scale failure alarms), the cluster management automatically increases the parallelism of Spark / Flink jobs.

[0115] Related indicators: state_change_rate: The state change frequency (times / second), which triggers resource adjustments. cpu_reserve_ratio: The reserved resource ratio (default 20% to prevent sudden load).

[0116] (3) Association with the storage layer; Elastic expansion of storage nodes: When the memory usage of the Redis cluster exceeds 80%, new nodes are automatically added and hash slots are migrated.

[0117] Related parameters: redis_memory_threshold: memory warning threshold (default 80%). cold_data_ttl: cold data archiving period (e.g. 24 hours).

[0118] (4) Association with early warning services Resource priority scheduling: During business peaks, cluster management prioritizes CPU and bandwidth resources for early warning services, ensuring millisecond-level response.

[0119] Related parameters: alert_service_min_nodes: The minimum number of nodes for the alert service (to ensure high availability).

[0120] In this embodiment, server resources can be dynamically allocated through parameter configuration. Specifically: (1) Parameterized configuration system: the system predefines key parameters and manages them through configuration files or databases, such as Table 4; Table 4 Parameterized configuration

[0121] (2) Dynamic resource allocation process: real-time collection - policy engine decision - resource scheduling execution - feedback tuning.

[0122] (3) Implementation of key technologies; Horizontal expansion (Scale-Out); stateless services (such as data analysis microservices): Directly add Pod instances, and the load balancer automatically distributes requests. Parameter control: max_nodes prevents overscaling.

[0123] Vertical scalability (Scale-Up); Stateful services (such as databases): Dynamically adjust CPU / memory quotas (requires cloud platform support); Hot and cold resource pools, preheating strategy: configure min_ready_nodes to keep standby instances preheated, and prioritize releasing cold nodes when scaling down.

[0124] It should be noted that all data is obtained in compliance with laws and regulations and with user consent, and the data is used legally.

[0125] Example 2 like Figure 2 As shown, this embodiment provides a data clustering processing system for AMR battery charging management, including: The receiving module 201 is configured to receive an AMR service request and corresponding reporting data; The storage module 202 is configured to store the reported data after format standardization in a pre-built standardized data dictionary, wherein the standardized data dictionary uses the AMR number as the key and the data status as the value to construct a memory hash table, and determines whether there is a status change of the reported data according to a preset logic to update the memory hash table; The selection module 203 is configured to screen a set of candidate servers that meet the type of the AMR service request according to the AMR service request, calculate a health score of the candidate server according to the CPU utilization, available memory, and network latency of the candidate server, update the initial weight of the candidate server according to the health score, determine the actual priority of the candidate server according to the latest weight and health score of the candidate server, and select the candidate server with the highest actual priority as the target processing node; The distribution module 204 is configured to retrieve the reported data from the standardized data dictionary and store it in the selected target processing node.

[0126] It should be noted that the above modules correspond to the steps described in Example 1, and the examples and application scenarios implemented by the above modules and the corresponding steps are the same, but are not limited to the contents disclosed in the above Example 1. It should be noted that the above modules, as part of the system, can be executed in a computer system such as a set of computer-executable instructions.

[0127] In further embodiments, there is also provided: An electronic device includes a memory and a processor, and computer instructions stored in the memory and executed by the processor, wherein when the computer instructions are executed by the processor, the method described in Example 1 is performed. For the sake of brevity, no further details are given here.

[0128] It should be understood that in this embodiment, the processor may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), off-the-shelf field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0129] The memory may include a read-only memory and a random access memory, and provides instructions and data to the processor. A portion of the memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type.

[0130] A computer-readable storage medium is used to store computer instructions, and when the computer instructions are executed by a processor, the method described in Example 1 is performed.

[0131] The method in Example 1 can be directly implemented as a hardware processor, or can be implemented using a combination of hardware and software modules in the processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, it will not be described in detail here.

[0132] A computer program product includes a computer program, which implements the method described in embodiment 1 when executed by a processor.

[0133] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions contained in program modules, which are executed in a device on a real or virtual processor of a target to perform the process / method described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided between program modules as needed. The machine-executable instructions for the program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in local and remote storage media.

[0134] The computer program code for implementing the method of the present invention can be written in one or more programming languages. These computer program codes can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the computer or other programmable data processing device, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on a computer, partially on a computer, as an independent software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0135] In the context of the present invention, computer program code or related data can be carried by any appropriate carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals include electrical, optical, radio, acoustic, or other forms of propagated signals, such as carrier waves, infrared signals, and the like.

[0136] Those skilled in the art will appreciate that the units and algorithm steps of the various examples described in conjunction with this embodiment can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0137] Although the above describes the specific embodiments of the present invention in conjunction with the accompanying drawings, it is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art on the basis of the technical solution of the present invention without any creative work are still within the scope of protection of the present invention.

Claims

1. A data clustering processing method for AMR battery charging management, characterized in that: include: Receive AMR service requests and corresponding reported data; The reported data is stored in a pre-built standardized data dictionary after format standardization. The standardized data dictionary uses the AMR number as the key and the data status as the value to build a memory hash table. The memory hash table is updated based on the preset logic to determine whether the reported data has any status change. Based on the AMR service request, a set of candidate servers that meet the AMR service request type is screened. The health score of the candidate server is calculated based on the CPU utilization, available memory, and network latency of the candidate server. The initial weight of the candidate server is updated based on the health score. The actual priority of the candidate server is determined based on the latest weight and health score of the candidate server. The candidate server with the highest actual priority is selected as the target processing node. The reported data is retrieved from the standardized data dictionary and stored in the selected target processing node.

2. The data clustering processing method for AMR battery charging management according to claim 1, characterized in that: The process of determining whether the reported data has a status change includes: If it is the first time data is reported, it will be unconditionally determined to be a status change; If the data is not reported for the first time, the voltage change, temperature change and operating status change are compared in turn. When the absolute value of the voltage difference exceeds the set threshold, it is determined to be a valid change; when the temperature change amplitude exceeds the set threshold, it is determined to be a valid change; when the operating status switches, it is determined to be a valid change; When there is at least one valid change, it is determined that a state change has occurred.

3. The data clustering processing method for AMR battery charging management according to claim 1, characterized in that: The format of reported data is standardized by converting the reported data into the specified data format through data dump service and storing it in the standardized data dictionary; It includes: parsing heterogeneous data, being compatible with protocols from different manufacturers, and mapping them to unified fields through template configuration; aggregating time windows, and only retaining the first and last data in the window if the same status is reported continuously; and hierarchical storage of different types of data.

4. The data clustering processing method for AMR battery charging management according to claim 1, characterized in that: No. The health scores of the candidate servers are: ； in, 、 and Respectively CPU utilization, remaining memory, and network latency of each candidate server; 、 and Respectively The weights of CPU utilization, remaining memory, and network latency of the candidate servers, and .

5. The data clustering processing method for AMR battery charging management according to claim 1, characterized in that: The process of updating the initial weight of the candidate server includes: determining whether the health score of the current candidate server is less than the set score threshold; if so, downgrading the current candidate server and recalculating the health score; if not, taking the product of the current weight of the current candidate server and the health score as the actual priority of the current candidate server.

6. The data clustering processing method for AMR battery charging management according to claim 1, characterized in that: The process of constructing the standardized data dictionary includes: parsing the original data format of each manufacturer's AMR, analyzing the field naming rules and units, generating a manufacturer agreement comparison table, thereby designing a unified field naming, data type and unit, and mapping the manufacturer's original data to the standardized data dictionary.

7. A data cluster processing system for AMR battery charging management, characterized in that: include: A receiving module configured to receive an AMR service request and corresponding reported data; A storage module is configured to store the reported data after format standardization in a pre-built standardized data dictionary, wherein the standardized data dictionary uses the AMR number as a key and the data status as a value to construct a memory hash table, and determines whether there is a status change of the reported data according to a preset logic to update the memory hash table; a selection module configured to screen a set of candidate servers that meet the type of the AMR service request according to the AMR service request, calculate a health score of the candidate server according to the CPU utilization, available memory, and network latency of the candidate server, update an initial weight of the candidate server according to the health score, determine an actual priority according to the latest weight and health score of the candidate server, and select the candidate server with the highest actual priority as the target processing node; The distribution module is configured to retrieve the reported data from the standardized data dictionary and store it in the selected target processing node.

8. An electronic device, characterized in that: The method comprises a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method according to any one of claims 1 to 6 is completed.

9. A computer-readable storage medium, characterized in that Used to store computer instructions, which, when executed by a processor, complete the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that The invention comprises a computer program, which is used to implement the method according to any one of claims 1 to 6 when the computer program is executed by a processor.

Images