Electric fork truck equipment state determination method, device, equipment and medium

Abstract

The application relates to the field of industrial Internet of Things data collection and processing, in particular to a method and device for determining the state of an electric forklift, equipment and medium. The method comprises the following steps: first, acquiring multi-source heterogeneous data generated by the electric forklift; then, performing unified field mapping processing on the multi-source heterogeneous data to obtain standardized data; finally, performing equipment running state calculation based on the standardized data to determine the corresponding equipment comprehensive state. By adopting the scheme, a unified data expression basis can be established, the heterogeneous equipment access and analysis adaptation capability is improved, the accuracy and stability of equipment state identification are enhanced, the platform maintenance cost is reduced, and the reliability of equipment monitoring and operation management is improved.

Description

Technical Field

[0001] This application relates to the field of electric forklift data processing technology, and in particular to a method, apparatus, equipment and medium for determining the status of an electric forklift. Background Technology

[0002] Electric forklifts, as core operating equipment in modern warehousing and logistics systems, are widely used in manufacturing, e-commerce warehousing, cold chain logistics, and port terminals. Their operational efficiency and safety directly affect the overall efficiency of logistics operations. Accurate perception and determination of equipment operating status are fundamental prerequisites for achieving intelligent forklift scheduling, health management, fault early warning, and refined operation and maintenance. Only by accurately understanding the forklift's operating condition can we effectively support higher-level applications such as battery life prediction, operational efficiency statistics, charging strategy optimization, and safety alarm classification. However, as a complex mechatronic system, the status information of electric forklifts is dispersed across multiple electronic control units, including the vehicle controller (VCU), battery management system (BMS), and motor controller (MCU). Furthermore, data from each unit is exchanged and transmitted via a CAN bus in multi-frame message format, naturally posing a challenge to the fusion of multi-source heterogeneous data in determining the equipment's status. Therefore, how to collaboratively analyze the multi-source heterogeneous operating data of electric forklifts and accurately perceive the real-time comprehensive status of the equipment has become a crucial technical problem urgently needing to be solved in this field.

[0003] In the existing technology, the way to determine the operating status of electric forklifts is to collect message data on the CAN bus through the vehicle terminal, extract discrete parameters such as vehicle speed, motor speed, and battery voltage after protocol parsing, and display them independently on the monitoring interface.

[0004] However, existing solutions cannot accurately determine the overall status of the equipment, and are prone to status misjudgment or status flickering problems. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for determining the status of electric forklift equipment, in order to solve the problem in the prior art that it is impossible to accurately determine the overall status of the equipment, and that it is easy to produce status misjudgment or status flashing.

[0006] In a first aspect, embodiments of this application provide a method for determining the status of an electric forklift, including:

[0007] Acquire multi-source heterogeneous data generated by electric forklifts;

[0008] The multi-source heterogeneous data is subjected to unified field mapping processing to obtain standardized data;

[0009] Based on the standardized data, the equipment operating status is calculated to determine the corresponding overall equipment status.

[0010] In one possible implementation, the multi-source heterogeneous data includes at least the original field identifier and the data type;

[0011] The process of performing unified field mapping on the multi-source heterogeneous data to obtain standardized data includes:

[0012] Obtain a preset field mapping configuration table, which includes multiple mapping configuration items. Each mapping configuration item includes at least the original field identifier, the field mapping identifier, and the correspondence between data formats, and establishes a corresponding mapping index according to the data type.

[0013] The corresponding mapping index is determined based on the data type in the multi-source heterogeneous data, and the field mapping identifier and data format corresponding to the multi-source heterogeneous data are determined based on the mapping index, the original field identifier, and the field mapping configuration table.

[0014] Standardized data is generated based on the field mapping identifier and data format.

[0015] In one possible implementation, the step of calculating the equipment operating status based on the standardized data to determine the corresponding overall equipment status includes:

[0016] Read the drive speed field from the standardized data, and calculate the vehicle controller status based on the speed field;

[0017] Read the charging mode field from the standardized data, and calculate the battery management system status based on the charging mode field:

[0018] The alarm fields are read from the standardized data, and the alarm fields are matched for faults according to the preset alarm classification configuration table to obtain the fault warning status.

[0019] According to a preset priority sequence, the vehicle controller status, the battery management system status, and the fault warning status are combined and calculated, and the status with the highest priority is selected as the overall equipment status.

[0020] In one possible implementation, before calculating the equipment operating status based on the standardized data and determining the corresponding overall equipment status, the method further includes:

[0021] Convert the multi-source heterogeneous data from a hexadecimal string into a byte array;

[0022] The frame type of the multi-source heterogeneous data is determined according to the preset byte identifier in the byte array, and the frame type is one of CAN frame, position frame, and lock frame;

[0023] When the frame type is a CAN frame, the CAN identifier field in the byte array is extracted, and the corresponding controller type is obtained according to the CAN identifier and the mapping relationship. The mapping relationship includes the correspondence between the CAN identifier and the controller type. The controller type includes the vehicle controller and the battery management system.

[0024] According to the parsing rules corresponding to the controller type, the original values ​​of each field are extracted from the byte array in a predetermined byte order to generate the device operation data of the vehicle controller and the battery management system respectively.

[0025] In one possible implementation, the method further includes:

[0026] When receiving device operation data containing only the battery management system, retrieve the pre-cached vehicle controller state and its timestamp from the previous moment;

[0027] Determine whether the cache time corresponding to the timestamp meets the preset valid time condition;

[0028] If the preset valid time condition is met, the vehicle controller status is fused with the currently acquired battery management system equipment operation data, and the overall equipment status is recalculated.

[0029] If the preset valid time condition is not met, the vehicle controller status is determined to be invalid, and the overall device status is determined based on the currently acquired battery management system device operation data.

[0030] In one possible implementation, after determining the corresponding overall device status, the method further includes:

[0031] Obtain the location data from the multi-source heterogeneous data;

[0032] Determine whether there is associated device operation data within the time range corresponding to the location data;

[0033] When there is associated device operation data, the location data is stored in association with the device operation data;

[0034] When there is no associated device operation data, the location data is stored as an independent data record.

[0035] In one possible implementation, the method further includes:

[0036] Write the device's operating data and overall device status into the cache database;

[0037] When the amount of data to be stored in the cache database reaches the preset batch condition, check whether the data field corresponding to the standardized data exists in the time series database;

[0038] When the data field is detected to exist in the time series database, the data to be stored is written into the time series database;

[0039] When it is detected that the data field does not exist in the time series database, a corresponding data field is created in the time series database according to the field mapping identifier and data type in the standardized data, and the data to be stored is written into the time series database.

[0040] Secondly, embodiments of this application provide an electric forklift equipment status determination device, comprising:

[0041] The acquisition module is used to acquire multi-source heterogeneous data generated by electric forklifts;

[0042] The processing module is used to perform unified field mapping processing on the multi-source heterogeneous data to obtain standardized data;

[0043] The determination module is used to calculate the equipment operating status based on the standardized data and determine the corresponding overall equipment status.

[0044] In one possible implementation, the multi-source heterogeneous data includes at least the original field identifier and the data type;

[0045] The processing module is specifically used for:

[0046] Obtain a preset field mapping configuration table, which includes multiple mapping configuration items. Each mapping configuration item includes at least the original field identifier, the field mapping identifier, and the correspondence between data formats, and establishes a corresponding mapping index according to the data type.

[0047] The corresponding mapping index is determined based on the data type in the multi-source heterogeneous data, and the field mapping identifier and data format corresponding to the multi-source heterogeneous data are determined based on the mapping index, the original field identifier, and the field mapping configuration table.

[0048] Standardized data is generated based on the field mapping identifier and data format.

[0049] In one possible implementation, the determining module is specifically used for:

[0050] Read the drive speed field from the standardized data, and calculate the vehicle controller status based on the speed field;

[0051] Read the charging mode field from the standardized data, and calculate the battery management system status based on the charging mode field:

[0052] The alarm fields are read from the standardized data, and the alarm fields are matched for faults according to the preset alarm classification configuration table to obtain the fault warning status.

[0053] According to a preset priority sequence, the vehicle controller status, the battery management system status, and the fault warning status are combined and calculated, and the status with the highest priority is selected as the overall equipment status.

[0054] In one possible implementation, the apparatus further includes a generation module, which, before calculating the equipment operating status based on the standardized data and determining the corresponding comprehensive equipment status, is configured to:

[0055] Convert the multi-source heterogeneous data from a hexadecimal string into a byte array;

[0056] The frame type of the multi-source heterogeneous data is determined according to the preset byte identifier in the byte array, and the frame type is one of CAN frame, position frame, and lock frame;

[0057] When the frame type is a CAN frame, the CAN identifier field in the byte array is extracted, and the corresponding controller type is obtained according to the CAN identifier and the mapping relationship. The mapping relationship includes the correspondence between the CAN identifier and the controller type. The controller type includes the vehicle controller and the battery management system.

[0058] According to the parsing rules corresponding to the controller type, the original values ​​of each field are extracted from the byte array in a predetermined byte order to generate the device operation data of the vehicle controller and the battery management system respectively.

[0059] In one possible implementation, the device further includes a computing module for:

[0060] When receiving device operation data containing only the battery management system, retrieve the pre-cached vehicle controller state and its timestamp from the previous moment;

[0061] Determine whether the cache time corresponding to the timestamp meets the preset valid time condition;

[0062] If the preset valid time condition is met, the vehicle controller status is fused with the currently acquired battery management system equipment operation data, and the overall equipment status is recalculated.

[0063] If the preset valid time condition is not met, the vehicle controller status is determined to be invalid, and the overall device status is determined based on the currently acquired battery management system device operation data.

[0064] In one possible implementation, after determining the corresponding overall device status, the processing module is further configured to:

[0065] Obtain the location data from the multi-source heterogeneous data;

[0066] Determine whether there is associated device operation data within the time range corresponding to the location data;

[0067] When there is associated device operation data, the location data is stored in association with the device operation data;

[0068] When there is no associated device operation data, the location data is stored as an independent data record.

[0069] In one possible implementation, the processing module is further configured to:

[0070] Write the device's operating data and overall device status into the cache database;

[0071] When the amount of data to be stored in the cache database reaches the preset batch condition, check whether the data field corresponding to the standardized data exists in the time series database;

[0072] When the data field is detected to exist in the time series database, the data to be stored is written into the time series database;

[0073] When it is detected that the data field does not exist in the time series database, a corresponding data field is created in the time series database according to the field mapping identifier and data type in the standardized data, and the data to be stored is written into the time series database.

[0074] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0075] The memory stores computer-executed instructions;

[0076] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0077] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0078] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0079] The electric forklift equipment status determination method, apparatus, equipment, and medium provided in this application first acquire multi-source heterogeneous data generated during the operation of the electric forklift. This multi-source heterogeneous data may include operating parameter data collected by the vehicle controller, battery status data collected by the battery management system, and motor operating data collected by the drive system. Because different data sources have different data acquisition protocols, data formats, and data field definitions, it is difficult to directly correlate and analyze various types of data. Therefore, after acquiring the multi-source heterogeneous data, a unified field mapping process is performed. This involves converting the data field names, data types, data formats, and data expression formats from different sources according to preset data field mapping rules, mapping the heterogeneous data from different data sources to a unified data description system to obtain standardized data. Through this unified field mapping process, the differences in data expression between different data sources can be eliminated, improving the correlation and consistency between multi-source data, and enabling comprehensive analysis of different types of operating parameters under the same data dimension. After obtaining standardized data, the equipment operating status is calculated based on the standardized data. By extracting key feature parameters that reflect the operating status of the electric forklift from the standardized data, and performing fusion analysis on each feature parameter according to the preset status evaluation model or status calculation rules, the current comprehensive status of the electric forklift is determined. By performing comprehensive status calculation based on standardized data, the status judgment bias caused by single sensor data can be avoided, and a multi-dimensional assessment of the overall operating status of the electric forklift can be achieved, improving the accuracy and reliability of equipment status identification. At the same time, it can provide effective data support for subsequent equipment maintenance, fault warning and operation optimization. Attached Figure Description

[0080] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0081] Figure 1 A flowchart illustrating the method for determining the status of an electric forklift provided in this application embodiment. Figure 1 ;

[0082] Figure 2 A flowchart illustrating the method for determining the status of an electric forklift provided in this application embodiment. Figure 2 ;

[0083] Figure 3 This is a schematic diagram of the structure of the electric forklift equipment status determination device provided in the embodiments of this application;

[0084] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0085] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0086] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0087] Electric forklifts, as core equipment in modern warehousing and logistics systems, are widely used in manufacturing, e-commerce warehousing, and cold chain logistics. With the rapid development of Industrial Internet of Things (IIoT) technology, the demand for digitalization and intelligentization of electric forklifts is increasingly urgent. For example, in large warehousing centers, hundreds of electric forklifts need to upload real-time data on their operating status (such as location, speed, and battery level), fault information, and charging status to achieve functions such as equipment scheduling optimization, energy consumption management, and fault early warning. However, the current control systems (VCU, BMS, and GPS modules) of electric forklifts are developed by different manufacturers, and their CAN bus protocols and data field definitions differ significantly. This necessitates the development of custom parsing code for each protocol in the data acquisition system, resulting in high maintenance costs. Furthermore, during operation, forklifts may only send BMS or GPS data due to charging or shutdown scenarios, lacking VCU status information, making it difficult for existing systems to continuously track equipment status. Simultaneously, the storage of massive amounts of time-series data faces limitations due to fixed table structures. When controller firmware upgrades add new fields, traditional databases require manual modification of the table structure, severely impacting system scalability. Therefore, there is an urgent need for an electric forklift data acquisition and processing solution that is compatible with multiple protocols, enables refined state perception, and supports dynamic storage, in order to support the deep needs of the Industrial Internet of Things for equipment lifecycle management.

[0088] In the existing technology, the way to determine the operating status of electric forklifts is to collect message data on the CAN bus through the vehicle terminal, extract discrete parameters such as vehicle speed, motor speed, and battery voltage after protocol parsing, and display them independently on the monitoring interface.

[0089] When determining the operating status of an electric forklift, the onboard terminal typically collects message data from the CAN bus and extracts individual operating parameters such as vehicle speed, motor speed, and battery voltage through protocol parsing. These parameters are then displayed independently on the monitoring interface. However, this method primarily focuses on collecting and displaying single parameters, lacking analysis of the relationships between different data sources. It fails to comprehensively reflect the overall operating status of the electric forklift. Furthermore, inconsistencies in data formats, field definitions, and parameter dimensions arising from different control modules lead to reliance on human experience in determining equipment status, making it difficult to accurately identify potential anomalies. To address these issues, the inventors, based on the principle of multi-source data fusion analysis, and considering that the operating status of an electric forklift is not determined by a single parameter but is characterized by multiple dimensions of parameters, including the power system, battery system, control system, and operating environment, have proposed a new method for determining the equipment status of an electric forklift. Specifically, the process begins by collecting multi-source heterogeneous data generated by different functional modules during the operation of the electric forklift, including vehicle control parameters, battery status parameters, and motor operating parameters. Then, addressing the differences in data format and inconsistent fields between different data sources, a unified field mapping rule is established to convert data fields from different sources accordingly. Further data format normalization, anomaly correction, and data completion processing are performed to transform various heterogeneous data into standardized data with a unified data structure. Based on this, multi-dimensional state features are extracted from the standardized data and, combined with a pre-set equipment state calculation model, different dimensions of operating parameters are fused and analyzed to obtain a comprehensive equipment state that characterizes the overall operation of the electric forklift. This method achieves a shift from traditional single-parameter monitoring to multi-dimensional comprehensive state assessment, fully utilizing the correlation information between different data sources to improve the accuracy and reliability of equipment operating state identification. It also enables the early detection of abnormal trends during equipment operation, providing effective data support for fault warning, maintenance decisions, and operational optimization of the electric forklift.

[0090] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0091] Figure 1A flowchart illustrating the method for determining the status of an electric forklift provided in this application embodiment. Figure 1 ;like Figure 1 As shown, the method includes:

[0092] S101. Acquire multi-source heterogeneous data generated by the electric forklift.

[0093] Among them, multi-source heterogeneous data includes at least the original field identifier and data type.

[0094] In this step, multi-source heterogeneous data serves as the input data source for this method, carrying the original business information generated during the operation of the electric forklift. Specifically, this includes data sets from different sources, in different formats, and with different field definitions. This data can originate from different onboard modules or related devices of the electric forklift; in terms of data representation, it can be message data, key-value pairs converted through protocols, structured data, or binary transcoded data; in terms of field definitions, different brands and models of forklifts may use different field identifiers for the same physical quantity, therefore unified access needs to be completed first. In this application, the executing entity can be a platform-side data access server or an edge gateway with parsing capabilities. The onboard networking device continuously monitors the internal data of the electric forklift and encapsulates the collected data according to device identification, collection time, and data source information before uploading. Specifically, upon receiving the upload message, the data acquisition side completes data unpacking, device identity verification, and time sequence organization to generate raw data records to be processed.

[0095] In one specific implementation, the electric forklift connects to the vehicle's CAN bus network via an onboard communication device (such as a T-Box or intelligent onboard terminal) to monitor and collect CAN message data from multiple electronic control units, including the VCU vehicle controller, BMS battery management system, and MCU motor controller, in real time. The onboard communication device encapsulates the collected CAN messages into UDP data packets according to a predetermined format and uploads them to the message queue middleware of the cloud platform via a 4G / 5G cellular network. In this embodiment, the message queue is deployed using multiple server clusters, employing a multi-partition and multi-replica mechanism to ensure high availability of data access. The acquisition service, acting as a server consumer, subscribes to the corresponding Topic and pulls forklift data messages in real time. Each raw data message contains at least the original field identifier (e.g., "In0001" or "c0cff0008_00"), the corresponding value of the field (e.g., RPM 1250), and the data type of the field (VCU, BMS, or GPS). The message queue does not immediately process the received data but acts as a buffer layer to temporarily store the raw data, ensuring decoupling between data reception and processing logic and preventing data loss due to downstream processing jitter. Because the CAN protocol field definitions differ significantly between different manufacturers and vehicle models, the original field identifiers suffer from inconsistent naming rules and inconsistent field meanings. Therefore, a unified standardized mapping process needs to be performed in subsequent steps to provide a consistent field access interface for upper-layer state calculations.

[0096] Based on the above analysis, it is clear that acquiring multi-source heterogeneous data generated by electric forklifts does not simply refer to receiving single data points, but rather to the continuous collection and aggregation of multiple types of raw data related to the equipment status during forklift operation. To ensure the usability of subsequent status calculations, this step also includes a completeness check on the accessed data. Specifically, this involves verifying whether each data entry contains the equipment identifier, collection time, and source information; data lacking any of these items is marked as an incomplete record. For multiple data entries received from the same equipment within the same sampling period, they can be organized in chronological order for use in the next step of unified field mapping processing. Through the above collection and aggregation process, raw data generated by forklifts of different brands and models are placed in a unified access framework, providing an input basis for subsequent unified representation. The direct result is the generation of a multi-source raw data set organized by equipment dimension, triggering the unified field mapping processing flow. It should be understood that the above example is for demonstration purposes only and is not a limitation.

[0097] S102. Perform unified field mapping processing on multi-source heterogeneous data to obtain standardized data.

[0098] In one possible implementation, a preset field mapping configuration table is first obtained; then, the corresponding mapping index is determined according to the data type in the multi-source heterogeneous data, and the field mapping identifier and data format corresponding to the multi-source heterogeneous data are determined according to the mapping index, the original field identifier, and the field mapping configuration table; finally, standardized data is generated according to the field mapping identifier and data format.

[0099] The field mapping configuration table includes multiple mapping configuration items. Each mapping configuration item includes at least the original field identifier, the field mapping identifier, and the correspondence between data formats, and establishes a corresponding mapping index according to the data type.

[0100] In this step, the unified field mapping process is used to convert data from different sources and with different representations into a unified and processable data format. Its core lies in converting the different field expressions in the original data into data expressions under a unified semantics. Standardized data is a structured data set formed by mapping multi-source heterogeneous data. Its field names, value types, and semantic expressions are consistent, and it can be used as a unified input for subsequent calculations of device operating status.

[0101] It should be understood that, during implementation, data from different data types can first be organized into a unified intermediate format, with each data record carrying the original field identifier and data type. When the platform pre-establishes a field mapping configuration table, multiple mapping configuration items under the same data type are grouped into the corresponding mapping index. The mapping configuration item records the correspondence between the original field identifier, the field mapping identifier, and the data format. Upon receiving heterogeneous data from multiple sources, the system first locates the corresponding mapping index based on the data type, and then searches for a matching item in the field mapping configuration table based on the original field identifier, thereby determining the field mapping identifier and its data format in the standardized expression. Subsequently, the system performs format consistency processing according to the data format and assembles the field mapping identifier and the processed field into standardized data.

[0102] In this approach, data type limits the selection range of the mapping index, original field identifiers precisely locate specific fields, and data format constrains the expression of fields, ultimately forming standardized data that can be directly called by subsequent status calculation modules. By uniformly mapping data from different sources to consistent field representations, subsequent equipment operating status calculations can be processed based on the same data semantics, forming a stable connection with the comprehensive status determination process of electric forklifts.

[0103] In one specific implementation, the system preloads a field mapping configuration table into memory upon startup. This field mapping configuration table is stored in a tabular file format, containing three columns: "FieldId," "MappingId," and "DataType," with mapping indexes created for each of the three data types: VCU, BMS, and GPS. The following is a specific example:

[0104]

[0105] When the data acquisition service receives a data message from the server, it first reads the original field identifier (e.g., "In0001") from the message and automatically identifies the protocol type of the current data by detecting a predetermined prefix in the field name. Specifically, fields starting with "In" or "Nu" are identified as vendor A protocol format, fields starting with "c0cff" are identified as vendor B protocol format, and so on, achieving automatic identification of multi-vendor protocols. Subsequently, the system determines the corresponding mapping index based on the data type (e.g., VCU) and queries the mapping index using the original field identifier (e.g., "In0001") as the key. It then looks up the corresponding mapping identifier (e.g., "DriveMCU1_Speed") and data format (e.g., "float") in the field mapping configuration table. The system transparently replaces the field identifier "In0001" in the original data with the unified semantic field name "DriveMCU1_Speed" and binds the field with the data format "float", ultimately generating standardized data with the following data structure: {Field mapping identifier: "DriveMCU1_Speed", Data format: "float", Data type: "VCU"}. This standardized data is provided in a unified data structure for use by the subsequent state calculation module. The state calculation module does not need to care about the original field names and protocol differences of the underlying data, and can directly read the required data through unified field names such as "DriveMCU1_Speed".

[0106] Understandably, through the field mapping mechanism driven by the configuration table described above, when connecting a new model of forklift or equipment from a new manufacturer, maintenance personnel only need to add a new mapping entry to the configuration table, mapping the original field identifier of the new manufacturer to the existing unified semantic field name. No business code needs to be modified, and there is no need to recompile or deploy the data collection and parsing service. The access cycle is shortened from the traditional several weeks to several hours, and the amount of code is reduced to one-fifth of the traditional hard-coded method. At the same time, the automatic protocol identification mechanism based on field naming prefixes eliminates the need for manual configuration of protocol types, reducing operational complexity and the risk of misconfiguration, and giving the system good scalability and maintainability.

[0107] S103. Calculate the equipment operating status based on standardized data to determine the corresponding comprehensive equipment status.

[0108] It should be understood that the equipment operating status calculation is used to determine the current state of the electric forklift based on the equipment operation-related field information in the standardized data and output the final comprehensive equipment status. The comprehensive equipment status is used to represent the current status output of the electric forklift. In specific implementation, information related to vehicle operation, power supply, and alarms is extracted from the standardized data, the current operating status of the equipment is analyzed, and the corresponding comprehensive equipment status is determined based on the analysis results.

[0109] In one possible embodiment, the platform can combine multiple standardized fields to comprehensively determine the device status. When the standardized data can reflect different states such as the device being in operation, standby, charging, or abnormal, it can output the comprehensive device status corresponding to the current state. When key fields are missing or cannot support effective determination, an undetermined status can be output. After the comprehensive status is determined, the result, along with the device identifier and status time, can be recorded for subsequent querying or use. Based on the above analysis, this step uses standardized data as a unified input to calculate the electric forklift status and output the corresponding comprehensive status, enabling multi-source data to participate in status determination and reducing status bias caused by relying solely on local fields. It should be understood that the above example is only for demonstration and not a limitation.

[0110] It should be noted that the specific implementation method of this embodiment is described in this application. Figure 2 The embodiments are described in detail, and will not be repeated in this embodiment.

[0111] It should also be noted that before calculating the device's operating status based on standardized data and determining the corresponding overall device status, it is necessary to obtain device operating data. It is important to clarify that field mapping and message parsing are two parallel data processing pipelines, each processing the same raw data from different dimensions. Field mapping (S102) focuses on the standardization of "field names"—converting original field identifiers from different manufacturers (such as "In0001" or "c0cff0008_00") into a unified semantic field name common to the system (such as "DriveMCU1_Speed"). The purpose is to allow upper-layer business logic (such as status calculation) to access data using a unified field name, without needing to concern itself with differences in the underlying protocol. The message parsing (this step) focuses on restoring the "field values"—the values ​​in the original multi-source heterogeneous data are transmitted in hexadecimal string format, which needs to be converted into a byte array readable by the program. Then, the controller type to which the message belongs (such as vehicle controller or battery management system) is determined according to the CAN-ID. Then, according to the data frame structure and parsing rules corresponding to the controller type, the original values ​​of each field are extracted from the byte array in a specified byte order. For example, the current value in the BMS message occupies two bytes and is stored in little-endian byte order. The two bytes need to be concatenated, multiplied by a precision coefficient, and the offset subtracted to restore the actual current value; the fault code field is parsed from a single byte to extract multiple fault states through bit field extraction. Only after the above parsing steps restore the hexadecimal message to structured values, and then combined with the unified field names obtained from field mapping, can complete equipment operation data be formed. This data is then used by the status calculation module to read the corresponding values ​​based on unified field names such as "DriveMCU1_Speed" to determine the VCU status, BMS status, and fault warning status.

[0112] Therefore, it is understandable that field mapping solves the problem of what the field is named, while message parsing solves the problem of what the field value is. Together, they constitute the conversion link from raw multi-source heterogeneous data to complete device operation data.

[0113] Specifically: First, the multi-source heterogeneous data is converted from hexadecimal strings into byte arrays; then, the frame type of the multi-source heterogeneous data is determined according to the preset byte identifiers in the byte array; then, when the frame type is a CAN frame, the CAN identifier field in the byte array is extracted, and the corresponding controller type is obtained according to the CAN identifier and the mapping relationship; finally, according to the parsing rules corresponding to the controller type, the original values ​​of each field are extracted from the byte array according to the predetermined byte order, and the equipment operation data of the vehicle controller and the battery management system are generated respectively.

[0114] Among them, the frame type is CAN frame, and the mapping relationship between position frame and lock frame includes the correspondence between CAN identifier and controller type. The controller type includes vehicle controller and battery management system.

[0115] In one specific implementation, the CAN messages of the electric forklift are transmitted to the cloud platform via UDP protocol in hexadecimal string format. After receiving the multi-source heterogeneous data, the data acquisition service first needs to perform message parsing to extract the equipment operation data. The specific parsing process is as follows:

[0116] The first step is to convert the multi-source heterogeneous data from hexadecimal strings into byte arrays. The system uses a byte-by-byte conversion method, converting every two hexadecimal characters into one byte value, which is then sequentially filled into the byte array for subsequent parsing.

[0117] The second step is to determine the frame type based on the preset byte identifiers in the byte array. The system reads the byte value at a specific position in the byte array as the frame type identifier: for example, the byte prefix "303030" identifies a CAN frame, "303031" identifies a location frame (GPS frame), and "303032" identifies a lock frame. Different frame types correspond to different parsing paths. Among them, CAN frames carry vehicle control data and battery data, location frames carry positioning information such as latitude, longitude, speed, and direction, and lock frames carry device lock status information.

[0118] The third step involves extracting the CAN identifier (CAN-ID) field from the byte array when the frame type is CAN frame. The CAN-ID is an 11-bit or 29-bit identifier used to uniquely identify the data source and type of the message. The system determines the corresponding controller type based on the CAN-ID and a preset mapping relationship. In this embodiment, the mapping relationship includes, but is not limited to: CAN-ID 0x0CFF0008 corresponding to driver MCU1, 0x18FF5060 corresponding to BMS, and 0x0CFF0010 corresponding to pump control MCU. Through this mapping relationship, the system can determine whether the current message originates from the vehicle controller, battery management system, or other controllers.

[0119] The fourth step involves extracting the original values ​​of each field from the byte array according to the parsing rules corresponding to the controller type and in a predetermined byte order. Different controller types correspond to different data frame structures and parsing rules: for multi-byte numerical fields (such as speed, voltage, current, etc.), the system combines multiple bytes to restore the complete value in little-endian byte order. For example, the total current field in the BMS message occupies bytes 4 and 5, stored in little-endian byte order, and the system extracts the original values ​​of each field from the byte array according to the predetermined byte order. "The formula calculates the actual current value (unit: amperes, accuracy 0.1A, offset 1000A); the total voltage field occupies bytes 6 and 7, according to..." The formula calculates the actual voltage value (unit: volts, accuracy 0.1V); the SOC field takes the value of byte 3 and multiplies it by 0.4% to calculate the actual state of charge (accuracy 0.4% / bit); the individual cell voltage is calculated according to… Extract (unit: volts, accuracy 0.001V); cell temperature is calculated according to "buf[n]-40" (unit: degrees Celsius, range -40℃ to 100℃). Furthermore, for individual cell data in the battery management system, the system automatically enumerates all data in the target data object starting with "buf[n]-40" using a reflection mechanism. Attributes starting with "(individual unit voltage) and those starting with " The system extracts and assigns values ​​to attributes starting with "" (cell temperature) sequentially from the message byte array, allowing it to adapt to battery packs with different numbers of cells (up to 30 cells) without modifying the code. After the above parsing steps, the system generates structured equipment operation data for both the vehicle controller and the battery management system, which are then used by the subsequent state calculation module.

[0120] Understandably, through the aforementioned refined CAN message parsing process, the system can accurately reconstruct various operating parameters of the vehicle controller and battery management system from the original hexadecimal UDP payload. Bit-field fault code parsing enables a single byte to carry eight types of fault states, significantly improving data transmission efficiency; little-endian byte order conversion ensures that multi-byte values ​​can still be correctly restored after cross-platform transmission; the multi-cell parallel parsing capability of the reflection mechanism allows the system to adapt to battery pack configurations with different numbers of cells without modifying the code, providing excellent configuration flexibility and scalability.

[0121] The method for determining the status of an electric forklift provided in this application first acquires multi-source heterogeneous data generated during the operation of the electric forklift. This multi-source heterogeneous data may include operating parameter data collected by the vehicle controller, battery status data collected by the battery management system, and motor operating data collected by the drive system. Because different data sources have different data acquisition protocols, data formats, and data field definitions, it is difficult to directly correlate and analyze various types of data. Therefore, after acquiring the multi-source heterogeneous data, a unified field mapping process is performed. This involves converting the data field names, data types, data formats, and data expression formats from different sources according to preset data field mapping rules, mapping the heterogeneous data from different data sources to a unified data description system to obtain standardized data. Through this unified field mapping process, the differences in data expression between different data sources can be eliminated, improving the correlation and consistency between multi-source data, and enabling comprehensive analysis of different types of operating parameters under the same data dimension. After obtaining standardized data, the equipment operating status is calculated based on the standardized data. By extracting key feature parameters that reflect the operating status of the electric forklift from the standardized data, and performing fusion analysis on each feature parameter according to the preset status evaluation model or status calculation rules, the current comprehensive status of the electric forklift is determined. By performing comprehensive status calculation based on standardized data, the status judgment bias caused by single sensor data can be avoided, and a multi-dimensional assessment of the overall operating status of the electric forklift can be achieved, improving the accuracy and reliability of equipment status identification. At the same time, it can provide effective data support for subsequent equipment maintenance, fault warning and operation optimization.

[0122] Figure 2 A flowchart illustrating the method for determining the status of an electric forklift provided in this application embodiment. Figure 2 ;like Figure 2 As shown, in this embodiment... Figure 1 Based on the embodiments, the process of determining the overall status of the equipment is described in detail. The method includes:

[0123] S201. Read the drive speed field from the standardized data and calculate the vehicle controller status based on the speed field.

[0124] In one specific implementation, the calculation of the vehicle control unit (VCU) status relies on speed-related fields in standardized data. The system reads the drive speed field (mapped as "DriveMCU1_Speed") and the lifting speed field (mapped as "Pump_Speed") from the standardized data. The specific judgment logic of the VCU status is as follows: First, it checks whether the current device status data structure contains a valid drive speed field. If the device status Map does not contain the "DriveMCU1_Speed" field, the VCU status is directly set to "UNKNOWN". If the field is contained, it further determines whether the absolute value of the lifting speed or the walking speed is greater than zero. If the absolute value of either "DriveMCU1_Speed" or "Pump_Speed" is greater than zero, it indicates that the vehicle is currently performing walking or lifting operations, and the VCU status is determined to be "RUN". If both absolute values ​​are zero, the VCU status is determined to be "IDLE", and the duration of the idle state is recorded for subsequent determination of the shutdown state. For example, if the value of the "DriveMCU1_Speed" field in the current standardized data of a forklift is 0 and the value of the "Pump_Speed" field is also 0, the system determines that the VCU state is "IDLE" and accumulates the idle time from the end of the last running state; if the value of the "DriveMCU1_Speed" field is 1250 (representing the current speed of the drive motor) and the absolute value is greater than 0, the system determines that the VCU state is "RUN".

[0125] Understandably, by accurately judging the speed field mentioned above, the system can accurately distinguish between the running and idle states of the forklift. Compared with the coarse-grained state division in traditional solutions, this method can accurately capture the instantaneous operating state of the vehicle, providing accurate basic state data for subsequent charging strategy optimization and operation efficiency statistics.

[0126] S202. Read the charging mode field from the standardized data and calculate the battery management system status based on the charging mode field.

[0127] In one specific implementation, the calculation of the Battery Management System (BMS) status relies on the charging mode field (mapped as "BMS_Chg_Mode") in the standardized data. The system reads the value of this field from the standardized data and determines the BMS status according to a preset numerical meaning mapping rule: when the charging mode field value is 0, the BMS status is determined to be "DISCONNECT," indicating that the forklift is not currently connected to the charging device; when the field value is 1, the BMS status is determined to be "Charging," indicating that the forklift is charging; when the field value is 2, the BMS status is determined to be "ChargeFinished," indicating that the charging process has been completed. For example, in a nighttime charging scenario, the "BMS_Chg_Mode" field value in the standardized data is 1, and the system determines the BMS status to be "Charging" accordingly; after charging is completed, the field value changes to 2, and the system automatically switches the BMS status to "ChargeFinished." In addition, the system also uses the VCU status to assist in determining the shutdown status: when the VCU status is "IDLE" and the continuous idle time exceeds 3 minutes, the system further determines the equipment status as "SHUTDOWN", indicating that the vehicle has been in a non-operational state for a long time and may have been powered off or in standby mode.

[0128] Understandably, through the fine analysis of the charging mode field, the system can accurately identify the forklift's detailed states such as charging in progress, charging complete, and not connected. This overcomes the shortcomings of traditional solutions that can only distinguish between three coarse-grained states: working, faulty, and idle. It provides fine-grained state data support for battery health management, charging strategy optimization, and energy consumption analysis.

[0129] S203. Read the alarm fields from the standardized data, perform fault matching on the alarm fields according to the preset alarm classification configuration table, and obtain the fault warning status.

[0130] In one specific implementation, the calculation of the fault warning status relies on the alarm fault code field (mapping identifiers such as "BMS_Fault_Code", "VCU_Fault_Code", etc.) in the standardized data. The system reads the values ​​of various fault codes from the standardized data and matches them with a pre-set alarm classification configuration table. This alarm classification configuration table predefines the severity level and response level of various fault codes, classifying all faults into two main categories: "shutdown faults" and "minor faults". Among them, shutdown faults indicate that the equipment has serious abnormalities (such as battery overheating, insulation failure, motor overcurrent, etc.), requiring immediate shutdown and triggering the highest priority response; minor faults indicate that the equipment has general alarms (such as large individual unit voltage differential, temperature warning, etc.), which do not affect continued operation but require attention. In the fault code parsing stage, the system uses bit-field extraction to parse multiple fault states from a single byte. For example, the lower two bits (bit0-bit1) of a byte encode individual unit voltage over / under voltage faults, bits 2-bit3 encode charging overcurrent / discharging overcurrent faults, bits 4-bit5 encode total voltage over / under voltage faults, and bits 6-bit7 encode insulation faults. Up to eight types of fault information are extracted from a single byte through bitmasking operations. When the system detects any fault code, it matches the fault code with the alarm classification configuration table. If a shutdown fault is matched, the fault warning status is determined as "ALARM (shutdown fault)"; if only a minor fault is matched, the fault warning status is determined as "WARNING (minor fault alarm)"; if no fault is matched, the fault warning status is determined as "NORMAL (normal)".

[0131] Understandably, the alarm classification configuration table enables hierarchical management of downtime faults and minor faults, allowing maintenance personnel to quickly determine response priorities based on fault levels. This avoids the problem of low alarm response efficiency caused by mixing downtime faults and minor faults in the same processing logic, and significantly improves fault handling efficiency and the accuracy of maintenance decisions.

[0132] S204. Based on the preset priority sequence, the vehicle controller status, battery management system status, and fault warning status are combined and calculated, and the status with the highest priority is selected as the overall equipment status.

[0133] In one specific implementation, after calculating the vehicle controller (VCU) status, battery management system (BMS) status, and fault warning status separately, the system performs a combined calculation according to a preset seven-level priority sequence, selecting the highest priority status as the overall device status output. This seven-level priority sequence, from highest to lowest, is: ALARM (shutdown fault) > RUN (running) > Charging (charging in progress) > ChargeFinished (charging complete) > SHUTDOWN (power off) > IDLE (idle) > UNKNOWN (unknown). The specific combined calculation logic is as follows: The system first checks the fault warning status. If the fault warning status is "ALARM" (i.e., a shutdown fault has been triggered), the overall status is directly determined to be "ALARM," and subsequent priority comparisons are stopped, because shutdown faults have the highest priority. If no shutdown fault has been triggered, the system compares the positions of the VCU status and BMS status in the priority sequence, selecting the state with the higher position (i.e., higher priority) as the overall status. For example, if a forklift's current VCU status is "RUN", BMS status is "Charging", and fault warning status is "NORMAL", then "RUN" has a higher priority than "Charging" in the priority sequence, and the system outputs the overall device status as "RUN". As another example, if another forklift's current VCU status is "IDLE", BMS status is "Charging", and fault warning status is "ALARM", then because "ALARM" has the highest priority, the system outputs the overall device status as "ALARM".

[0134] Through the aforementioned seven-level priority merging mechanism, the system can collaboratively integrate heterogeneous status information scattered across multiple electronic control units such as VCU and BMS. This overcomes the shortcomings of traditional solutions that rely on a single data source, leading to inaccurate status judgments. It ensures that the overall equipment status output at any given time represents the highest priority and true operating condition. This refined multi-level status division capability provides an accurate and reliable status data foundation for forklift scheduling, charging management, fault warning, and maintenance decision-making.

[0135] In one possible implementation, when receiving device operation data containing only the battery management system, the vehicle controller state and its timestamp from the previous moment are obtained from a pre-cached cache; then, it is determined whether the cache time corresponding to the timestamp meets a preset valid time condition; if the preset valid time condition is met, the vehicle controller state is merged with the currently obtained device operation data of the battery management system, and the overall device state is recalculated; if the preset valid time condition is not met, the vehicle controller state is determined to be invalid, and the overall device state is determined based on the currently obtained device operation data of the battery management system.

[0136] In one specific implementation, for scenarios where electric forklifts only send BMS data and not VCU data during certain periods of actual operation (e.g., during charging, the vehicle controller may be in a sleep or power-off state, with only the battery management system continuously uploading charging status data), this application designs a VCU state cache reuse mechanism. The system maintains a dedicated VCU state cache key (key format: "device:{deviceId}:vcu_state_cache") in the database's first-level cache. Each time VCU data is successfully parsed and a valid VCU state is obtained, the current VCU state and its corresponding timestamp are written to this cache, and the time-to-live (TTL) is set to 60 seconds.

[0137] When the system receives a message containing only BMS data (excluding VCU data), it first queries the VCU status cache of the device in the database. If the cache is hit, it further checks whether the difference between the current time and the cached timestamp is within the preset valid time condition (i.e., whether it is ≤60 seconds). If the difference is ≤60 seconds, it means that the cached VCU status is still valid. The system uses the cached VCU status as the current VCU status and merges it with the BMS status parsed from the current BMS data, recalculating the overall device status according to the aforementioned seven-level priority sequence. For example, if a forklift's VCU status is "IDLE" at the last moment before charging, and then enters the charging state, the system only receives BMS data. At this time, the cached database retains the VCU status as "IDLE" with a timestamp of 30 seconds ago, which meets the valid time condition. The system compares the priority of the cached "IDLE" with the current BMS status "Charging" and selects the higher-priority "Charging" as the overall status output.

[0138] If a cache miss occurs, or the difference between the current time and the cache timestamp exceeds the 60-second expiration threshold, it indicates that the cached VCU status has expired. The system will determine the VCU status as "UNKNOWN" and determine the overall device status solely based on the current BMS data. For example, if a forklift has been parked for an extended period, and the VCU status cache in the cache database has expired (exceeding 60 seconds), the system will only receive BMS data reports and will therefore consider the VCU status as "UNKNOWN." The overall status will be determined solely based on the BMS status and fault warning status.

[0139] Understandably, through the VCU state caching reuse mechanism described above, this method effectively eliminates the device state flickering problem caused by the lack of VCU data in BMS independent message scenarios, ensuring that the overall device state remains accurate and stable during the brief period of VCU data absence, and significantly improving the robustness of the system and user experience.

[0140] In one possible implementation, after determining the corresponding overall device status, the method further includes:

[0141] First, obtain location data from the multi-source heterogeneous data; then determine whether there is associated device operation data within the time range corresponding to the location data; when associated device operation data exists, store the location data and device operation data together; when no associated device operation data exists, store the location data as an independent data record.

[0142] In one specific implementation, after determining the overall status of the equipment, the positioning data undergoes further specialized processing. The GPS / BeiDou positioning module equipped on the electric forklift uploads location data in real time, including latitude, longitude, speed, and direction information. This location data, as part of multi-source heterogeneous data, is identified through the "303031" frame header identifier in the UDP packet. The system maintains the timestamp of the last CAN frame data received by each device in the database using a hash table structure (key format "device:{deviceId}:last_can_time").

[0143] When a location frame data is received, the system first reads the timestamp of the last CAN data from the hash table for the corresponding device and calculates the difference between the current time and that timestamp. If the difference exceeds a preset time threshold (set to 300 seconds, or 5 minutes, in this embodiment), it indicates that the device has not sent any CAN data in the last 5 minutes and may be parked, powered off, or in a CAN bus silent state. In this case, the system writes the location frame data directly to the time-series database as an independent record, without merging it with any historical CAN data, ensuring that the location data can be independently saved and queried. If the difference does not exceed 300 seconds, it indicates that the device is still sending CAN data normally. The system merges and appends the GPS coordinates (latitude, longitude, speed, and direction) to the current device status object and writes it to the time-series database along with the device's operating data and overall status.

[0144] Understandably, through the aforementioned GPS timeout detection and isolation persistence strategy, this application ensures that the location data of the electric forklift can still be continuously recorded during the CAN bus silence period (such as nighttime parking or standby state), avoiding the defect of losing GPS information due to lack of CAN data, ensuring the complete restoration capability of the vehicle's driving trajectory, and providing complete data support for vehicle scheduling, route planning, and historical trajectory playback.

[0145] In one possible implementation, the method further includes:

[0146] First, the device operation data and overall device status are written to the cache database. Then, when the data to be stored in the cache database reaches the preset batch condition, it is checked whether the data field corresponding to the standardized data exists in the time series database. When the data field exists in the time series database, the data to be stored is written to the time series database. When the data field does not exist in the time series database, the corresponding data field is created in the time series database according to the field mapping identifier and data type in the standardized data, and the data to be stored is written to the time series database.

[0147] In one specific implementation, the system employs a dual-database persistence architecture that combines a first-level cache and a second-level time-series database. Each processed device operation data record and its corresponding overall device status are first written to the cache database. The cache database performs three functions: First, as a batch buffer, the system maintains independent batch queues for each data type (VCU, BMS, GPS), with each processed data record appended to the end of the corresponding type's list in JSON format; second, as a latest status cache, storing the latest overall status of each device in a hash format for real-time status queries by applications such as monitoring dashboards, with a read latency of less than 1 millisecond; and third, as a VCU status cache (using the VCU status cache reuse mechanism described above).

[0148] When the amount of data in the batch queue corresponding to any data type in the cache database reaches the preset batch condition (50 records by default in this embodiment), a batch write operation is triggered to write the batch data to the time series database. Before the batch write, the system automatically executes a dynamic column detection process: First, it extracts all field mapping identifiers from the batch data and performs a difference comparison with the current column structure of the target data table in the time series database to determine whether there are any new fields that have not yet been defined in the table. If there are new fields, the system automatically infers the database data type of the time series database based on the data type corresponding to the field in the standardized data: specifically, if the field value contains a decimal point, it is inferred to be of type Float64; if it is a pure integer, it is inferred to be of type Int64; if it is a "true" / "false" boolean value, it is inferred to be of type UInt8; otherwise, it is uniformly inferred to be of type String. Subsequently, the system performs a dynamic column addition operation (ALTER TABLE ADD COLUMN) to add the new field and its corresponding data type to the time series database table, and then resubmits the write request. If there are no new fields, the write request is submitted directly.

[0149] All write operations employ an exponential backoff retry strategy to ensure write reliability: when a write operation fails, the system retryes at intervals of 1 second, 2 seconds, and 4 seconds, up to a maximum of 3 retries. If the write operation still fails after 3 retries, the system writes the batch of data to a dead-letter queue and triggers an alarm, prompting maintenance personnel to intervene and ensure zero data loss.

[0150] Through the aforementioned dual-database collaborative persistence architecture, this application achieves dual support for real-time querying and historical analysis. Simultaneously, the dynamic column auto-expansion capability of the time-series database allows the system to seamlessly adapt to new fields introduced by controller firmware upgrades, eliminating the need for manual intervention in database structure changes and significantly reducing operational costs. The exponential backoff retry strategy, combined with a batch write mechanism, ensures near-zero data loss rate under abnormal scenarios such as network jitter, meeting industrial-grade reliability requirements.

[0151] Figure 3 This is a schematic diagram of the structure of the electric forklift equipment status determination device provided in the embodiments of this application; as shown below. Figure 3 As shown, the device includes:

[0152] The acquisition module 301 is used to acquire multi-source heterogeneous data generated by the electric forklift;

[0153] Processing module 302 is used to perform unified field mapping processing on multi-source heterogeneous data to obtain standardized data;

[0154] The determination module 303 is used to calculate the equipment operating status based on standardized data and determine the corresponding comprehensive equipment status.

[0155] In one possible implementation, the multi-source heterogeneous data includes at least the original field identifier and the data type; the processing module 302 is specifically used for:

[0156] Obtain the preset field mapping configuration table. The field mapping configuration table includes multiple mapping configuration items. Each mapping configuration item includes at least the original field identifier, the field mapping identifier, and the correspondence between data formats. And establish the corresponding mapping index according to the data type.

[0157] The corresponding mapping index is determined based on the data type in the multi-source heterogeneous data. Based on the mapping index, the original field identifier, and the field mapping configuration table, the field mapping identifier and data format corresponding to the multi-source heterogeneous data are determined.

[0158] Standardized data is generated based on field mapping identifiers and data formats.

[0159] In one possible implementation, the determining module 303 is specifically used for:

[0160] Read the drive speed field from the standardized data, and calculate the vehicle controller status based on the speed field;

[0161] Read the charging mode field from the standardized data, and calculate the battery management system status based on the charging mode field:

[0162] Read alarm fields from standardized data, perform fault matching on alarm fields according to preset alarm classification configuration table, and obtain fault warning status;

[0163] Based on a preset priority sequence, the vehicle controller status, battery management system status, and fault warning status are combined and calculated, and the status with the highest priority is selected as the overall equipment status.

[0164] In one possible implementation, the apparatus further includes a generation module, which, before calculating the equipment operating status based on standardized data and determining the corresponding overall equipment status, is used to:

[0165] Convert multi-source heterogeneous data from hexadecimal strings into byte arrays;

[0166] The frame type of the multi-source heterogeneous data is determined based on the preset byte identifier in the byte array. The frame type is one of CAN frame, position frame, or lock frame.

[0167] When the frame type is CAN frame, the CAN identifier field in the byte array is extracted, and the corresponding controller type is obtained according to the CAN identifier and the mapping relationship. The mapping relationship includes the correspondence between the CAN identifier and the controller type. The controller type includes the vehicle controller and the battery management system.

[0168] Based on the parsing rules corresponding to the controller type, the original values ​​of each field are extracted from the byte array according to the predetermined byte order, and the equipment operation data of the vehicle controller and the battery management system are generated respectively.

[0169] In one possible implementation, the device further includes a computing module for:

[0170] When receiving device operation data containing only the battery management system, retrieve the pre-cached vehicle controller state and its timestamp from the previous moment;

[0171] Determine whether the cache time corresponding to the timestamp meets the preset valid time condition;

[0172] If the preset valid time condition is met, the vehicle controller status will be merged with the currently acquired battery management system equipment operation data, and the overall equipment status will be recalculated.

[0173] If the preset valid time condition is not met, the vehicle controller status will be determined as invalid, and the overall device status will be determined based on the currently acquired battery management system device operation data.

[0174] In one possible implementation, after determining the corresponding overall device status, the processing module 302 is further configured to:

[0175] Acquire location data from multi-source heterogeneous data;

[0176] Determine whether there is related device operation data within the time range corresponding to the location data;

[0177] When there is associated device operation data, the location data will be stored in association with the device operation data;

[0178] When there is no associated device operation data, the location data is stored as an independent data record.

[0179] In one possible implementation, the processing module 302 is further configured to:

[0180] Write the device's operating data and overall device status into the cache database;

[0181] When the amount of data to be stored in the cache database reaches the preset batch condition, check whether the data field corresponding to the standardized data exists in the time series database;

[0182] When a data field is detected to exist in the time series database, the data to be stored is written to the time series database.

[0183] When a data field is detected not to exist in the time series database, the corresponding data field is created in the time series database according to the field mapping identifier and data type in the standardized data, and the data to be stored is written to the time series database.

[0184] The electric forklift equipment status determination device provided in this application embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0185] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 40 provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the device 40 further includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0186] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above-described method.

[0187] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0188] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0189] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0190] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0191] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0192] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0193] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0194] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0195] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0197] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0198] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0199] Based on the above disclosure, those skilled in the art will understand that the computer-readable storage medium and its related implementation methods provided in the embodiments of the present invention are not limited to the specific hardware or logical partitioning forms described above. In actual product or system deployments, computer execution instructions can be encapsulated in different software distribution packages or firmware modules and distributed via networks, optical discs, or mobile storage devices. When computer execution instructions are loaded and executed by one or more processors, in addition to implementing the aforementioned method steps, hardware resource configurations can be automatically identified according to specific application scenarios, and thread priorities or memory allocation strategies can be dynamically adjusted to optimize execution efficiency without manual intervention. Furthermore, the computer-readable storage medium can also be integrated into IoT terminals, edge computing nodes, or cloud servers to form a distributed instruction storage and collaborative execution system to meet differentiated needs such as high concurrency, low latency, or data privacy protection.

[0200] Furthermore, it should be emphasized that the logical functions corresponding to the methods, units, modules, and storage media in this application, without departing from the core idea of ​​this invention, allow developers to make equivalent refactoring, renaming, or re-division based on specific programming languages ​​(such as C++, Java, Python, etc.) or framework characteristics. For example, the functions of multiple "units" can be merged into a single service process, or message queues or pipe communication can be used instead of direct function calls. Even if these implementation details are not completely the same as the foregoing embodiments, as long as they ultimately achieve the same technical effect and no creative effort is required, they should all be considered to fall within the protection scope of this invention. Similarly, any intermediate data processing forms, exception handling mechanisms, or logging methods embodied in the instructions in the computer-readable storage medium when executed are also derivative technologies of this invention and should not be construed as substantial limitations on the original solution.

[0201] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0202] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for determining the status of an electric forklift, characterized in that, include: Acquire multi-source heterogeneous data generated by electric forklifts; The multi-source heterogeneous data is subjected to unified field mapping processing to obtain standardized data; Based on the standardized data, the equipment operating status is calculated to determine the corresponding overall equipment status.

2. The method according to claim 1, characterized in that, The multi-source heterogeneous data includes at least the original field identifier and the data type; The process of performing unified field mapping on the multi-source heterogeneous data to obtain standardized data includes: Obtain a preset field mapping configuration table, which includes multiple mapping configuration items. Each mapping configuration item includes at least the original field identifier, the field mapping identifier, and the correspondence between data formats, and establishes a corresponding mapping index according to the data type. The corresponding mapping index is determined based on the data type in the multi-source heterogeneous data, and the field mapping identifier and data format corresponding to the multi-source heterogeneous data are determined based on the mapping index, the original field identifier, and the field mapping configuration table. Standardized data is generated based on the field mapping identifier and data format.

3. The method according to claim 1, characterized in that, The step of calculating the equipment operating status based on the standardized data to determine the corresponding overall equipment status includes: Read the drive speed field from the standardized data, and calculate the vehicle controller status based on the speed field; Read the charging mode field from the standardized data, and calculate the battery management system status based on the charging mode field: The alarm fields are read from the standardized data, and the alarm fields are matched for faults according to the preset alarm classification configuration table to obtain the fault warning status. According to a preset priority sequence, the vehicle controller status, the battery management system status, and the fault warning status are combined and calculated, and the status with the highest priority is selected as the overall equipment status.

4. The method according to claim 2, characterized in that, Before calculating the equipment operating status based on the standardized data and determining the corresponding overall equipment status, the method further includes: Convert the multi-source heterogeneous data from a hexadecimal string into a byte array; The frame type of the multi-source heterogeneous data is determined according to the preset byte identifier in the byte array, and the frame type is one of CAN frame, position frame, and lock frame; When the frame type is a CAN frame, the CAN identifier field in the byte array is extracted, and the corresponding controller type is obtained according to the CAN identifier and the mapping relationship. The mapping relationship includes the correspondence between the CAN identifier and the controller type. The controller type includes the vehicle controller and the battery management system. According to the parsing rules corresponding to the controller type, the original values ​​of each field are extracted from the byte array in a predetermined byte order to generate the device operation data of the vehicle controller and the battery management system respectively.

5. The method according to claim 4, characterized in that, The method further includes: When receiving device operation data containing only the battery management system, retrieve the pre-cached vehicle controller state and its timestamp from the previous moment; Determine whether the cache time corresponding to the timestamp meets the preset valid time condition; If the preset valid time condition is met, the vehicle controller status is fused with the currently acquired battery management system equipment operation data, and the overall equipment status is recalculated. If the preset valid time condition is not met, the vehicle controller status is determined to be invalid, and the overall device status is determined based on the currently acquired battery management system device operation data.

6. The method according to claim 1, characterized in that, After determining the corresponding overall equipment status, the method further includes: Obtain the location data from the multi-source heterogeneous data; Determine whether there is associated device operation data within the time range corresponding to the location data; When there is associated device operation data, the location data is stored in association with the device operation data; When there is no associated device operation data, the location data is stored as an independent data record.

7. The method according to claim 6, characterized in that, The method further includes: Write the device's operating data and overall device status into the cache database; When the amount of data to be stored in the cache database reaches the preset batch condition, check whether the data field corresponding to the standardized data exists in the time series database; When the data field is detected to exist in the time series database, the data to be stored is written into the time series database; When it is detected that the data field does not exist in the time series database, a corresponding data field is created in the time series database according to the field mapping identifier and data type in the standardized data, and the data to be stored is written into the time series database.

8. A device for determining the status of an electric forklift, characterized in that, include: The acquisition module is used to acquire multi-source heterogeneous data generated by electric forklifts; The processing module is used to perform unified field mapping processing on the multi-source heterogeneous data to obtain standardized data; The determination module is used to calculate the equipment operating status based on the standardized data and determine the corresponding overall equipment status.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images