Industrial equipment operation data acquisition method and device, electronic equipment and medium

Abstract

The invention discloses an industrial equipment operation data acquisition method and device, electronic equipment and a medium. The method comprises the following steps: acquiring equipment state data of industrial equipment; the equipment state data is input to a preset target responsibility chain, the target responsibility chain comprises M state processors, each state processor corresponds to the operation state of the industrial equipment, and M is an integer larger than 1; and processing the equipment state data through each state processor in the target responsibility chain. By adopting the technical scheme, the probability of data omission during state transition of the industrial equipment can be effectively reduced, and the integrity of data acquisition is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to a method, apparatus, electronic device, and medium for collecting operational data of industrial equipment. Background Technology

[0002] Existing industrial equipment, such as loaders, are often unmanned operating equipment that integrates technologies such as automatic navigation, intelligent sensing, and autonomous decision-making. They are widely used in industrial scenarios such as mines, ports, and warehousing and logistics, and are usually required to perform repetitive tasks such as loading, transporting, and unloading materials in complex environments.

[0003] Existing technologies typically employ a single-state machine model when collecting data on the operation of industrial equipment. However, industrial equipment operates in multiple states, such as idle, working, faulty, and manually controlled. A single-state machine model can only collect data for one state, which can easily lead to data omissions during state transitions of industrial equipment. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and medium for collecting industrial equipment operation data, which can effectively reduce the probability of data loss during state transitions of industrial equipment and improve the integrity of data collection.

[0005] In a first aspect, embodiments of this application provide a method for collecting industrial equipment operation data, including: Acquire equipment status data from industrial equipment; The device status data is input into a pre-set target responsibility chain, wherein the target responsibility chain includes M status processors, each status processor corresponding to the operating status of the industrial equipment, and M is an integer greater than 1; The device state data is processed by each state processor in the target responsibility chain.

[0006] Secondly, embodiments of this application provide an industrial equipment operation data acquisition device, comprising: The data acquisition module is used to acquire equipment status data of industrial equipment; The data transmission module is used to input the device status data to a pre-set target responsibility chain, wherein the target responsibility chain includes M status processors, each status processor corresponding to the operating status of the industrial equipment, and M is an integer greater than 1; The data processing module is used to process the device status data through each status processor in the target responsibility chain.

[0007] Thirdly, embodiments of this application also provide an electronic device, including a memory storing multiple instructions; a processor loads instructions from the memory to execute the steps of any of the industrial equipment operation data acquisition methods provided in embodiments of this application.

[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing multiple instructions adapted for loading by a processor to execute the steps of any of the industrial equipment operation data acquisition methods provided in embodiments of this application.

[0009] Fifthly, embodiments of this application also provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in any of the industrial equipment operation data acquisition methods provided in embodiments of this application.

[0010] The solution adopted in this application embodiment can acquire equipment status data of industrial equipment; input the equipment status data into a pre-set target responsibility chain, wherein the target responsibility chain includes M state processors, each state processor corresponding to the operating state of the industrial equipment, and M is an integer greater than 1; the equipment status data is processed by each state processor in the target responsibility chain; in this embodiment of the invention, by adopting a target responsibility chain containing M state processors, where M>1, and each state processor corresponds to an operating state of industrial equipment, when multiple equipment status data are received simultaneously, multiple state processors can process multiple equipment status data in parallel, thereby supporting the simultaneous processing of equipment status data of multiple operating states, helping to reduce the probability of data omission during the state transition process of industrial equipment, and effectively improving the integrity and efficiency of data acquisition. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of an embodiment of the method for collecting industrial equipment operation data provided in this application. Figure 2 This is a schematic diagram of one embodiment of the target responsibility chain provided in this application; Figure 3 This is a schematic diagram of one embodiment of the dual-layer storage architecture provided in this application. Figure 4This is a schematic diagram of the structure of the industrial equipment operation data acquisition device provided in the embodiments of this application; Figure 5 This is a system architecture diagram of the industrial equipment operation data collection and statistics system provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. At the same time, in the description of the embodiments of this application, the terms "first," "second," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0014] This application provides a method, apparatus, electronic device, and computer-readable storage medium for collecting industrial equipment operation data.

[0015] Specifically, this embodiment will be described from the perspective of an industrial equipment operation data acquisition device. This industrial equipment operation data acquisition device can be integrated into an electronic device. That is, the industrial equipment operation data acquisition method of this embodiment can be executed by an electronic device. Optionally, the electronic device may include a terminal device. The terminal device may be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, game console, or personal computer (PC), etc.

[0016] The industrial equipment operation data acquisition method provided in this application embodiment can be applied to systems such as industrial equipment operation data acquisition systems. This system may include a terminal device and a server. The terminal device may be a device including receiving and transmitting hardware, i.e., a device with receiving and transmitting hardware capable of performing bidirectional communication over a bidirectional communication link. The terminal device and the server can communicate bidirectionally via a network.

[0017] Optionally, the server can be a standalone server, or a server network or server cluster, including but not limited to computers, network hosts, single network servers, multiple network server sets, or cloud servers composed of multiple servers. Cloud servers consist of a large number of computers or network servers based on cloud computing.

[0018] The following detailed description, in conjunction with the accompanying drawings, illustrates the process. In this embodiment, the executing entity is a server. It should be noted that the order of description in the following embodiments is not intended to limit the preferred order of the embodiments. Although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown in the accompanying drawings.

[0019] Existing technologies that use a single state machine to collect the device status of industrial equipment typically only record data during state transitions. For example, when the current state of an industrial device changes from state A to state B, the duration of state A is recorded by the single state machine. However, since a single state machine can only collect one device state, but industrial equipment may exist in multiple states simultaneously, such as being in motion and having low battery, the single state machine cannot accurately record the current state of the industrial equipment. Furthermore, when the state of industrial equipment changes rapidly, the single state machine needs to collect the state of the industrial equipment at intervals, which means that data is usually collected some time after the change, which can easily lead to data omissions.

[0020] In the embodiments of this specification, industrial equipment may be, for example, loaders and cranes, and may be applied to industrial scenarios such as mines, ports, and warehousing and logistics.

[0021] The industrial equipment operation data acquisition method of this application adopts a target responsibility chain containing M state processors, where M>1, and each state processor corresponds to an industrial equipment operation state. This allows multiple equipment status data to be received simultaneously, and multiple state processors can process multiple equipment status data in parallel. This supports the simultaneous processing of equipment status data in multiple operation states, helps reduce the probability of data loss during industrial equipment state transitions, and effectively improves the integrity and efficiency of data acquisition.

[0022] Please refer to Figure 1 The specific process for collecting operational data from this industrial equipment can be summarized in steps 101-102, where: Step 101: Obtain equipment status data for industrial equipment; In some embodiments, taking the server as the execution subject of the method for collecting industrial equipment operation data, when collecting the operation data of industrial equipment, data can be collected through event-driven data embedding to obtain equipment status data. When the industrial equipment triggers a status event related to the equipment status data, the status event is reported to the server so that the server can obtain the equipment status data of the industrial equipment.

[0023] In some embodiments, the industrial equipment can be any industrial equipment required for use in the current industrial scenario.

[0024] Step 102: Input the equipment status data into the pre-set target responsibility chain, wherein the target responsibility chain includes M status processors, each status processor corresponds to the operating status of the industrial equipment, and M is an integer greater than 1; In some embodiments, a target responsibility chain is pre-set in the server for the industrial equipment. After receiving equipment status data, the server can input the equipment status data into the pre-set target responsibility chain based on the industrial equipment's identifier. The target responsibility chain includes M status processors, where the value of M is determined based on the number of operating states of the industrial equipment. Each of the M status processors corresponds one-to-one with one of the M operating states of the industrial equipment. For example, if the number of operating states of the industrial equipment is 3, then the target responsibility chain includes 3 status processors, each corresponding to one of the 3 operating states.

[0025] In some embodiments, since industrial equipment typically needs to track multiple operating states, such as 2, 4, 6, and 8, the value of M is the same as the number of operating states. Taking 4 operating states as an example, the 4 operating states of industrial equipment include idle state, error state, local state, and abnormal state. The target responsibility chain includes 4 state processors: idle state processor, error state processor, local mode processor, and abnormal state processor. The idle state processor is an independent processor that encapsulates the processing logic for idle states; the error state processor is an independent processor that encapsulates the processing logic for error states; the local mode processor is an independent processor that encapsulates the processing logic for local states; and the abnormal state processor is an independent processor that encapsulates the processing logic for abnormal states. Specifically, local state indicates that the industrial equipment is in a manually controlled state; idle state indicates that the industrial equipment is in a standby state; error state indicates that the industrial equipment is in a fault state; and abnormal state indicates an abnormal state during task execution, such as an abnormal state during automatic task execution.

[0026] In some embodiments, since industrial equipment typically needs to statistically analyze multiple operating states, and there is a one-to-one correspondence between state processors and operating states, M in the M state processors is an integer greater than 1.

[0027] In some embodiments, the M state processors may be at least two of the following: idle state processor, error state processor, local mode processor, and abnormal state processor.

[0028] In some embodiments, different running state processing logics are encapsulated as independent state processors, so that each state processor is responsible for detecting and processing a running state without interfering with each other, and data flow between state processors is achieved through chaining.

[0029] In some embodiments, taking M state processors as an example—an idle state processor, an error state processor, a local mode processor, and an abnormal state processor—the idle state processor (Loader Idling BI Handler) is used to detect the duration of the industrial equipment in standby mode and record the start time, end time, and cumulative duration of the idle state. The error state processor (Loader Error BI Handler) is used to detect the duration of the industrial equipment in fault mode and record the error type, error message, and fault duration. The local mode processor (Loader Local Mode Handler) is used to detect the duration of the industrial equipment in manual takeover mode and record the takeover reason, takeover task, and takeover duration. The abnormal state processor (Loader Automatic Mode Error BI Handler) is used to detect abnormal states during automatic task execution and record the start time, end time, and abnormal duration of the abnormal state.

[0030] Step 103: Process the device status data through each state processor in the target responsibility chain.

[0031] In some embodiments, the device status data of industrial equipment is received in real time through the target responsibility chain. If the device status data is received, for each status processor, it is determined whether the conditions of the device operating state corresponding to the status processor are met based on the device status data. If the conditions are met, a session object corresponding to the status processor is created or updated to record the duration of the device operating state. If the conditions are not met, no creation or update operation is performed.

[0032] In some embodiments, the M state processors are arranged in a preset order, and after each state processor finishes processing, it passes the device state data to the next state processor.

[0033] In some embodiments, the M state processors are pre-sorted in the target responsibility chain to obtain a preset order for each state processor. After receiving the preset order, the device state data is processed sequentially through the corresponding state processors along the target responsibility chain according to the preset order. After each state processor finishes processing, the device state data is passed to the next state processor until each of the M state processors has finished processing.

[0034] In some embodiments, for each state processor, the operating state corresponding to the device state data is first identified. If the operating state corresponding to the device state data is consistent with the device operating state corresponding to the state processor, it is determined that the device state data meets the conditions of the device operating state corresponding to the state processor. If the operating state corresponding to the device state data is inconsistent with the device operating state corresponding to the state processor, it is determined that the device state data does not meet the conditions of the device operating state corresponding to the state processor.

[0035] In some embodiments, for each state processor, it is determined whether the conditions of the device operating state corresponding to the state processor are met based on the device state data; if the conditions are met and there is no session object corresponding to the state processor, a session object corresponding to the state processor is created; if the conditions are met and there is a session object corresponding to the state processor, the session object corresponding to the state processor is updated.

[0036] In some embodiments, a session object includes at least one of a session object identifier, a session state, device state characteristic data, a session object start time, and a session object end time. Specifically, a session object includes all or some parameters such as a session object identifier, a session state, device state characteristic data, and a session object start time and end time. The session state can be active, transitional, or completed, etc., and the session object identifier is usually unique to avoid confusion.

[0037] Specifically, the session object is denoted as Session and can contain the following parameters: {uuid: string, start_time: float, last_record_date: str, state: string), [state_specific_data]}. Here, uuid represents the unique identifier of the session; start_time represents the session start timestamp; last_record_date represents the date and time of the last record; state represents the session state, which can be active, transitional, or completed; [state_specific_data] represents device state characteristic data, which records specific contextual information related to the device state. This device state characteristic data contains different information depending on the operating state. For example, when the operating state is error state, the device state characteristic data can include error codes, error messages, or severity; when the operating state is idle state, the device state characteristic data can include the reason for idleness, device location, or battery level; when the operating state is local state, the device state characteristic data can include operator identification or takeover reason; and when the operating state is abnormal state, the device state characteristic data can include the abnormality type, number of retries, or recovery strategy.

[0038] For example, taking loader A as an industrial piece of equipment, and loader A is performing an automated transportation task from the material yard to the unloading point, during the automated transportation task, loader A's battery management system reports a "battery level below 20% warning" and sends the warning information to the responsibility chain B corresponding to loader A. The M state processors in responsibility chain B are ordered as follows: idle state processor B1, error state processor B2, local mode processor B3, and abnormal state processor B4. Thus, after the warning information enters responsibility chain B, it first reaches B1 and is checked by B1. Since the warning information does not indicate that loader A has entered an idle state, it is determined that the warning information does not meet the idle state condition corresponding to B1, and the warning information is passed to B2. Then, the warning information is checked by B2. Since the warning information does not indicate that loader A has entered an error state, it is determined that the warning information does not meet the fault state condition corresponding to B2, and the warning information is passed to B3. Finally, the warning information is checked by B3. Since the warning information does not indicate that loader A has entered a manual takeover state, it is determined that... If the warning information does not meet the conditions for manual takeover status corresponding to B3, the warning information is passed to B4. Then, B4 checks the warning information and determines that the warning information indicates that loader A has entered an abnormal state. If the warning information meets the conditions for abnormal state corresponding to B4, then B4 is used to process the warning information. If no session object corresponding to B4 exists, a session object corresponding to B4 is created, and the start time, end time, and duration of loader A's abnormal state are recorded through the session object. If a session object corresponding to B4 exists, the session object is updated, and the duration of loader A's abnormal state is recorded.

[0039] For example, taking loader A and chain of responsibility B as an example, at time T1, loader A enters an idle state due to waiting for task completion. Loader A reports an idle state event to chain of responsibility B, causing chain of responsibility B to receive the idle state event. After entering chain of responsibility B, the idle state event first reaches B1. B1 checks the idle state event and finds that the idle state event indicates that loader A has entered an idle state. Therefore, it is determined that the idle state event meets the idle state conditions corresponding to B1. If there is no session object corresponding to B1, a session object corresponding to B1 is created, for example, an idle session B11. The session object records the start time, end time, and duration of loader A's idle state. If there is a session object corresponding to B1, the session object is updated, and the duration of loader A's idle state is recorded. After creating or updating the session object corresponding to B1, the idle state event is sequentially passed to B2, B3, and B4.

[0040] Furthermore, at time T2, following time T1, a sensor malfunction occurs in loader A, such as the lidar sensor going offline, and a sensor malfunction event is reported to the responsibility chain B. Upon receiving the sensor malfunction event, the event first reaches B1. B1 checks the sensor malfunction event and finds that it does not indicate that loader A has entered an idle state. Therefore, the sensor malfunction event does not meet the idle state condition corresponding to B1 and is passed to B2. Then, B2 checks the sensor malfunction event. Since the sensor malfunction event indicates that loader A has entered a fault state, it is determined that the sensor malfunction event meets the fault state condition corresponding to B2. A session object corresponding to B2 is then created or updated, for example, an error session B21. After creating or updating the session object corresponding to B2, the sensor malfunction event is sequentially passed to B2, B3, and B4. At this time, loader A has two active sessions: idle session B11 and error session B21. These two sessions are completely independent and exist in parallel, managed by different state processors. This ensures the independence of multiple state processors in processing multiple device state data in parallel, enabling the parallel collection of device state data for multiple operating states. This ensures that during state transitions, the corresponding device state data will still be processed by different state processors without any omissions. Consequently, this effectively reduces the probability of data omissions during loader state transitions and improves the integrity of data collection.

[0041] For example, see Figure 2 The target responsibility chain includes M state processors ordered as follows: idle state processor 201, error state processor 202, local mode processor 203, and abnormal state processor 204. After the target responsibility chain receives the device status data, it sequentially calls the corresponding state processors along the target responsibility chain to process the device status data.

[0042] In some embodiments, each state processor independently determines whether device state data needs to be processed, and state processors pass requests through chained calls. State processors can also be dynamically added or removed without affecting other state processors. For example, when there are M state processors including an idle state processor B1, an error state processor B2, a local mode processor B3, and an abnormal state processor B4, if it is necessary to remove the idle state processor B1, B1 in the chain of responsibility B can be removed. Since each of the M state processors is independent, it will not affect B2, B3, and B4. Of course, a working state processor B5 can also be added, which will also not affect B1 to B4 of the M state processors. The amount of code that needs to be modified for the newly added working state processor B5 is minimal, which can effectively improve the scalability of the system. Moreover, the state judgment logic of each state processor is clear and easy to debug and maintain.

[0043] In some embodiments, each state processor is used to manage the lifecycle of a state session, including session creation, session update, and session termination. Session creation management includes creating a session when the state begins, generating a universally unique identifier (UUID), and recording the start time, etc. Session update management includes periodically updating the last recorded time of the session during the state duration. Session termination management includes closing the session when the state ends and calculating the total duration, etc.

[0044] In some embodiments, for each state processor, after creating a session object corresponding to that state processor, the industrial equipment operation data acquisition method can synchronously store the target session data generated by the session object corresponding to that state processor in a pre-set memory and a distributed cache; if the session object corresponding to that state processor has ended, the target session data generated by the session object corresponding to that state processor is stored in a set database.

[0045] Specifically, a two-tier storage architecture of memory and distributed cache can be used to store the target session data generated by each session object. The target session data can be written to memory in real time and synchronously written to the distributed cache. The data in the distributed cache will be written to a designated database at regular intervals. The designated database is usually set up on the server for long-term storage to facilitate subsequent queries and analysis. The distributed cache can be Memcached, Redis, or Alluxio, etc.

[0046] For example, see Figure 3First, the target session data is stored in memory 30 in real time to enable fast access and real-time updates. While the target session data is stored in memory 30, it is simultaneously stored in a distributed cache 31. The distributed cache 31 is used for persistent backup, such as backups for 12, 24, or 48 hours. Thus, if memory 30 is interrupted due to system restart or failure, the distributed cache 31 can be used to restore the target session data after restarting. The target session data stored in the distributed cache 31 is written to a designated database 32 at regular intervals, such as 1 minute or 2 minutes. The designated database 32 is used for long-term storage of target session data, such as storage for 3 months, 6 months, or 12 months.

[0047] In some embodiments, for each state processor, when the session object corresponding to the state processor is created, the target session data generated during the creation of the session object is written to memory and a distributed cache in real time. When the session object corresponding to the state processor is updated, the session data in memory is updated, and the session data in the distributed cache is updated synchronously. Furthermore, when the meeting of the session object corresponding to the state processor ends, the target session data generated by the session object corresponding to the state processor in memory is cleared. At this time, the target session data in the distributed cache can also be cleared, ensuring that all target session data has been written to the designated database. Alternatively, when the meeting of the session object corresponding to the state processor ends, the target session data in the distributed cache can be backed up for a set backup duration before being cleared. The set backup duration can be set according to actual needs, such as 12, 24, or 48 hours.

[0048] In some embodiments, after a memory service interruption, in response to the storage service provided by memory, active session data is read from a distributed cache, wherein the active session data is session data generated by an unfinished session object before the memory service interruption; an active session object corresponding to the active session data is generated in memory; interruption completion data is generated based on the time in the active session data, and the interruption completion data is added to the active session object.

[0049] Specifically, since the memory stores not only the target session data generated by multiple session objects of a single industrial device, but also the session data of multiple industrial devices, after a memory service interruption, when the memory service is detected to be providing storage services again, in response to the storage services provided by the memory, the distributed cache is first checked to see if there is active session data. If there is active session data, the active session data is deserialized, an active session object corresponding to the active session data is generated in memory, and interrupt completion data is generated according to the time in the active session data and added to the active session object.

[0050] In some embodiments, when generating interrupted completion data, the last recorded time can be extracted from the time in the active session data, and the time difference between the last recorded time and the current time can be obtained to generate interrupted completion data. The interrupted completion data is then added to the active session object. In this way, if there are multiple active session data in the distributed cache, the above operation is performed for each active session data, thereby enabling data recovery through the active session data in the distributed cache. This greatly reduces the data loss rate and further ensures the integrity and accuracy of the collected data.

[0051] In some embodiments, after obtaining the time difference between the last recorded time and the current time, it can also be detected whether the time difference is greater than a set interruption time. If it is greater than the set interruption time, it can be determined that the interruption is caused by a restart. At this time, the interruption period is determined based on the time difference; then, interruption completion data is generated based on the interruption period, and the interruption completion data is added to the active session object. The set interruption time can be set according to implementation requirements, such as 5 minutes, 10 minutes, or 15 minutes.

[0052] Furthermore, when the detected time difference is no greater than the set interruption time, there may be network delays or brief failures. In this case, it is not necessary to obtain interruption data to complete the process, and the corresponding device status data can continue to be processed through the active session object.

[0053] For example, taking loader A and chain of responsibility B as an example, loader A malfunctions at 2:00 PM. The state processor B2 in chain of responsibility B creates an error session C1. At 2:05 PM, an unexpected power outage in the server room causes the service to crash. Power is restored at 2:15 PM, and the service restarts. After the service crash, all data in memory is lost. Distributed storage, such as Redis, stores the last snapshot of error session C1, with the last recorded time being 2:05 PM. The system at 2:15 PM... After restarting, the memory resumes providing storage services. At this point, it automatically scans Redis for active session data. It detects the erroneous session data of loader A and reads a snapshot of loader A's erroneous session C1 stored in Redis. It then deserializes the snapshot of loader A's erroneous session C1 and creates loader A's erroneous session C2 in memory. C2's state is completely identical to that just before the crash, including the same session ID, with a start time of 14:00 and a last recorded time of 14:05, and a status of "active." Based on the last recorded time of 14:05 and the current system time of 2:15, the time difference is determined to be 10 minutes. Since 10 minutes... The clock timeout is greater than 5 minutes. Therefore, it is determined that the service has been interrupted. Based on 10 minutes, a virtual interruption data is generated, which reads "The erroneous session of loader A lasted for 10 minutes from 14:05 to 14:15". The interruption data is added to the erroneous session C2, and monitoring continues. Loader A is repaired at 2:20. At this time, the erroneous session C2 will be terminated, and the session data will be stored in the set database. The session data generated by the erroneous session C2 can be deleted immediately in Redis, or it can be saved for a set time, such as 12 hours or 24 hours, and then deleted. The session data generated by the erroneous session C2 includes the first record from 14:00 to 14:05 for 5 minutes, the second record from 14:05 to 14:15 for 10 minutes, and the third record from 14:15 to 14:20 for 5 minutes. The total duration of the industrial equipment in a fault state is 20 minutes.

[0054] In this way, data integrity can be effectively provided by interrupting the data. Even though the service was interrupted for 10 minutes, key indicators such as the "monthly cumulative failure time" of loader A in the statistical report are still accurate, reducing the probability of data black holes. In addition, the entire recovery process is completed automatically without manual intervention, realizing seamless recovery of the business side and greatly improving the robustness of the system.

[0055] In some embodiments, clock consistency checks can also be performed during data recovery to ensure the accuracy of the recovered data and prevent data anomalies caused by server clock adjustments; and the reasonableness of timestamps can also be checked during session recovery to ensure that the session recovery is consistent with the actual situation.

[0056] In some embodiments, for each state processor, if the duration of the session object corresponding to the state processor reaches a set time statistics boundary within the duration of the session object corresponding to the state processor, then according to the time statistics boundary, the target session data corresponding to the state processor is split into multiple time segment corresponding record data, wherein the target session data is generated by the session object corresponding to the state processor.

[0057] Specifically, for each state processor, we can first obtain the time boundary point corresponding to the session object of the state processor based on the time statistics boundary; then, based on the time boundary point, we can split the target session data corresponding to the state processor into record data corresponding to multiple time segments.

[0058] In the embodiments of this specification, the time statistics boundary can be set according to actual needs. The time statistics boundary can be, for example, 1 hour, 2 hours, 30 minutes or 1 day.

[0059] In some embodiments, a time boundary detection algorithm can be used to detect when the duration of the session object corresponding to the state processor reaches a set time statistical boundary; then, a boundary point calculation algorithm can be used to determine the time boundary point.

[0060] Specifically, taking an hourly boundary as an example of time statistics boundary, the process first checks whether the duration of the session object corresponding to the state processor crosses the hourly boundary. If it does, the time boundary point is determined according to the boundary point calculation algorithm, and the target session data corresponding to the state processor is then split into record data corresponding to multiple time segments based on the time boundary point. Similarly, taking a day-crossing boundary as an example of time statistics boundary, the process first checks whether the duration of the session object corresponding to the state processor crosses the day-crossing boundary. If it does, the time boundary point is determined according to the boundary point calculation algorithm, and the target session data corresponding to the state processor is then split into record data corresponding to multiple time segments based on the time boundary point.

[0061] For example, taking the session time of a session object corresponding to a certain state processor as 14:20 to 16:10 as an example, if the time statistics boundary is 1 hour, then according to the boundary point calculation algorithm, the time boundary points are determined to be 14:20, 15:00, 16:00 and 16:10. Based on the time boundary points, record data for each hour segment is generated. The record data includes record 1, record 2 and record 3. The time period corresponding to record 1 is 14:20-15:00 (lasting 40 minutes), and record 1 belongs to the 14:00 time period. The time period corresponding to record 2 is 15:00-16:00 (lasting 60 minutes), and record 2 belongs to the 15:00 time period. The time period corresponding to record 3 is 16:00-16:10 (lasting 10 minutes), and record 3 belongs to the 16:00 time period.

[0062] For example, taking the session time of a session object corresponding to a certain state processor as being from 23:50 on October 31st to 00:10 on November 1st, if the time statistics boundary is a cross-day boundary, then according to the boundary point calculation algorithm, the time boundary points are determined to be 23:50 on October 31st, 00:00 on November 1st, and 00:10 on November 1st. Then, record data for each hour segment is generated based on the time boundary points. Among them, the record data includes record 4 and record 5. The time period corresponding to record 4 is from 23:50 on October 31st to 00:00 on November 1st (lasting 10 minutes), and record 4 belongs to the time period of 23:00 on October 31st; the time period corresponding to record 5 is from 00:00 on November 1st to 00:10 on November 1st (lasting 10 minutes), and record 5 belongs to the time period of 00:00 on November 1st.

[0063] In practical applications, for each state processor, during each data report in the corresponding session object, the current time is compared with the last recorded time to determine whether it crosses an hourly boundary (different hours) or a day boundary (different dates). If it crosses a boundary, the boundary crossing time is calculated, and the last recorded time of the session is generated to complete the record and start a new time segment. In this way, by using time statistical boundaries and time boundary points to split the target session data into record data corresponding to multiple time segments, sessions of any length can be split, and even sessions spanning different days can be accurately counted, effectively improving the accuracy of the statistics.

[0064] In some embodiments, a query time parameter for querying device status data may also be received, the query time parameter including start time and end time; a target statistical granularity matching the query time parameter is determined from a plurality of pre-set statistical granularities; a query time range corresponding to the query time parameter is determined based on the target statistical granularity; and the target device status data corresponding to the query time parameter is searched from the corresponding set database based on the query time range.

[0065] In some embodiments, the target statistical granularity may include at least one of hourly granularity, daily granularity, and minute granularity.

[0066] Specifically, after receiving the query time parameter, the system identifies the time format of the parameter, determines the target statistical granularity matching it, and then determines the query time range based on the target statistical granularity. Finally, it retrieves the target device status data from the designated database. For example, the granularity determination rule can be set based on the input format of the query time parameter. If the input format is YYYY-MM-DD, the target statistical granularity is determined to be daily granularity; if the input format is YYYY-MM-DD HH:MM:SS, the target statistical granularity is determined to be hourly granularity.

[0067] In some embodiments, if the target statistical granularity is daily, the query time range corresponding to the query time parameter can be expanded based on the query time parameter. For example, if the query time parameter is start=2024-10-14, end=2024-10-15; since the target statistical granularity of the query time parameter is daily, the expanded query time range is start=2024-10-14 00:00:00, end=2024-10-15 23:59:59.

[0068] For example, if the query time parameters are start_time=2024-10-14, end_time=2024-10-20, then it will automatically expand to 2024-10-14 00:00:00 to 2024-10-20 23:59:59, and the returned target device status data will be 7 records, one record per day.

[0069] In some embodiments, if the target statistical granularity is hourly, the query time parameter is used as the query time range for precise searching. For example, if the query time parameter is start=2024-10-14 14:00:00, end=2024-10-14 18:00:00; since the target statistical granularity of the query time parameter is hourly, the query time range is also start=2024-10-14 14:00:00, end=2024-10-14 18:00:00, and precise searching is performed based on the query time range.

[0070] For example, if the query time parameters are start_time=2024-10-14 14:00:00, end_time=2024-10-14 18:00:00, since the target statistical granularity of the query time parameters is hourly, the returned target device status data will be 5 records, one record per hour. Of course, aggregation can also be performed according to actual needs, such as returning 3 records, one record per hour.

[0071] In some embodiments, after retrieving the target device status data, the target device status data can be processed according to the target statistical granularity. If the target statistical granularity is daily, the data is grouped by date, aggregating all hourly data within the same day; if the target statistical granularity is hourly, hourly data within a specific time range is precisely filtered.

[0072] In some embodiments, cross-day hourly queries can also be performed. If the query time parameter is start=2024-10-14 22:00:00, end=2024-10-15 02:00:00, then the target statistical granularity is determined to be hourly. Then, the records for each hour from 2024-10-14 22:00:00 to 2024-10-15 02:00:00 are queried, and then the records from 2024-10-14 22:00:00-23:59 and 2024-10-15 00:00-02:00 are filtered out and displayed separately, thereby accurately aggregating data across day boundaries.

[0073] In some embodiments, after creating or updating a session object corresponding to each state processor, a target lock is added to the session object corresponding to the state processor, wherein the target lock includes at least one of a state lock, a transition lock, and an identity lock.

[0074] Specifically, the target lock can be a distributed lock, which can be implemented through distributed caching. The target lock can include three types of locks: state lock, transition lock, and identity lock, or one or two of the above three types. Among them, the state lock can include state type, project identifier, device identifier, and session object identifier. The state type represents the operating state of the industrial equipment. For example, the lock key format of the state lock can be {state_type}::{project_id}::{loader_id}::{uuid}, where state_type represents the state type identifier, project_id represents the project identifier to which the industrial equipment belongs, loader_id represents the device identifier of the industrial equipment, and uuid represents the session object identifier.

[0075] For example, if loader A, belonging to project mine_01, experiences a sensor malfunction, an error session with UUID err_sess_001 is created through the state processor. The corresponding state lock for this error session is ERROR::mine_01::loader_A::err_sess_001. This state lock locks loader A's error session err_sess_001 within project mine_01, while other error sessions of loader A remain unaffected. Loader A's idle session or local mode session can be updated simultaneously. The lock duration can be set according to actual needs, such as 10 seconds or 15 seconds. Thus, the state lock prevents the same state from being recorded repeatedly.

[0076] In some embodiments, the transition lock may include a project identifier and a device identifier. The lock key format of the transition lock may be, for example, transition::{project_id}::{loader_id}, where transition is a fixed prefix used to identify the state transition lock; project_id represents the project identifier to which the industrial equipment belongs, and loader_id represents the device identifier of the industrial equipment.

[0077] For example, if loader A is transitioning from an "idle" state to a "working" state, the generated transition lock key is `transition::mine_01::loader_A`. This transition lock can lock all state transitions of loader A. During the lock's duration, loader A cannot simultaneously begin transitioning from "working" to "error," but updates to loader A's existing state (such as updating the last recorded time of an error session) are unaffected. Therefore, transition locks can achieve all state transitions for the same device, and the lock duration can be set according to actual needs, such as 30 seconds or 45 seconds. In this way, state locks ensure the atomicity of state transitions for each industrial device.

[0078] In some embodiments, the identification lock may include a session object identifier, wherein the identification lock may be, for example, a UUID idempotent lock, and its corresponding lock key format may be idempotent::{uuid}::start, where idempotent is a fixed prefix used to identify the UUID idempotent lock, and uuid represents the session object identifier.

[0079] For example, if an error start event (UUID: err_sess_001) is received from loader A, an identifier lock key for the error session needs to be created, for example, idempotent::err_sess_001::start. This identifier lock ensures that the start record of the error session err_sess_001 is written only once. Even if the same event is repeatedly sent due to network issues, subsequent requests will fail to acquire the lock and will not affect the creation of other sessions (different UUIDs correspond to different locks). Therefore, an identifier lock can lock the start record of the same session, and the lock duration can be set according to actual needs, such as 10 minutes or 15 minutes. In this way, the identifier lock prevents the same session from repeatedly writing to the start record.

[0080] In some embodiments, when collecting operational data of industrial equipment, data can be collected through event-driven data tracking. In this case, lifecycle events can be set to cover the entire lifecycle of the industrial equipment. For example, 33 types of equipment lifecycle events can be predefined and the event types can be divided according to business scenarios. Asynchronous processing can be achieved so as not to block the main business logic, and dynamic registration and deregistration can also be achieved. Taking 33 equipment lifecycle events as an example, they can be divided into 5 major categories, including task flow events (9 types), such as INIT: task initialization, MOVE_LOAD: move to loading point, ENTER: enter warehouse, LOAD: loading operation, EXIT: leave warehouse, MOVE_UNLOAD: move to unloading point, UNLOAD: unloading operation, MOVE_INIT: return to initial point, and FINISH: task completion; and exception handling events (8 types), such as LOADER_CANCEL_TASK: task cancellation, LOADER_OFFLINE: equipment offline, LOADER_DEVICE_ERROR: equipment error, SOFT_EMERGENCY_STOP: soft emergency stop, TASK_FAILED: task failure, MAIN_ROAD_OCCUPIED: main roadway occupied, SILO_IS_OCCUPIED: hopper occupied, and other exceptions; and manual operation events (5 types), such as MANUAL_M OVE: Manual movement, MANUAL_LOAD: Manual loading, MANUAL_UNLOAD: Manual unloading, MANUAL_WAIT: Manual waiting, and MANUAL_MODE: Manual mode task; and special operation events (6 types), including LOADER_PARKING: Parking operation, LOADER_GO_INIT: Return to initial point, START_DYNAMIC_TOUR: Start dynamic inspection, FINISH_DYNAMIC_TOUR: Complete dynamic inspection, START_STATIC_CHECK: Start static inspection, and FINISH_STATIC_CHECK: Complete static inspection; and shutdown events (5 types), including LOADER_SHUTDOWN: Shutdown, MOVING_SHUTDOWN: Move to shutdown point, FINISH_SHUTDOWN: Shutdown completed, FINISH_PARKING: Parking completed, and FINISH_GO_INIT: Return to initial point completed.

[0081] Thus, after defining the above 33 device lifecycle events, the business code only needs to trigger the event and then distribute the triggered event to the subscriber through the event bus. If the subscriber includes a data acquisition module, the data acquisition module will automatically record the triggered event; if the subscriber includes a logging module, the logging module will automatically record the triggered data; if the subscriber includes a Business Intelligence (BI) statistics module, the BI statistics module will automatically update based on the triggered event.

[0082] In this embodiment of the invention, by employing a target responsibility chain comprising M state processors, where M>1, and each state processor corresponds to an operating state of an industrial device, multiple device status data can be received simultaneously and processed in parallel by the multiple state processors. This enables the simultaneous collection of device status data from multiple operating states, helps reduce the probability of data loss during state transitions of industrial devices, and ultimately improves the completeness and efficiency of data collection.

[0083] This application also provides an industrial equipment operation data acquisition device, such as... Figure 4 As shown, it includes: Data acquisition module 401 is used to acquire equipment status data of industrial equipment; The data transmission module 402 is used to input the device status data to a pre-set target responsibility chain, wherein the target responsibility chain includes M status processors, each status processor corresponds to the operating status of the industrial equipment, and M is an integer greater than 1; The data processing module 403 is used to process the device status data through each status processor in the target responsibility chain.

[0084] In some embodiments, the data processing module 403 is further configured to, for each state processor, determine whether the conditions of the device operating state corresponding to the state processor are met based on the device state data; if met, create or update the session object corresponding to the state processor to record the duration of the device operating state; if not met, do not perform the creation or update operation.

[0085] In some embodiments, the M state processors are arranged in a preset order, and after each state processor finishes processing, it passes the device state data to the next state processor.

[0086] In some embodiments, the data acquisition device further includes: The caching module is used to synchronously store the target session data generated by the session object of each state processor in memory and a distributed cache; if it is determined that the session object of the state processor has ended, the target session data generated by the session object of the state processor is stored in the designated database.

[0087] In some embodiments, the caching module is further configured to, after a memory service interruption, in response to the storage service provided by memory, read active session data from a distributed cache, wherein the active session data is session data generated by an unfinished session object in memory before the service interruption; in response to a deserialization operation, generate an active session object in memory corresponding to the active session data; generate interruption completion data based on the time in the active session data, and add the interruption completion data to the active session object.

[0088] In some embodiments, the data acquisition device further includes: The data splitting module is used to split the target session data corresponding to the state processor into multiple time segment record data according to the time statistical boundary if the duration of the session object corresponding to the state processor reaches the set time statistical boundary for each state processor. The target session data is generated by the session object corresponding to the state processor.

[0089] In some embodiments, the data splitting module is further configured to, for each state processor, obtain the time boundary point corresponding to the session object corresponding to the state processor based on the time statistical boundary; and, based on the time boundary point, split the target session data corresponding to the state processor into record data corresponding to multiple time segments.

[0090] In some embodiments, the data acquisition device further includes: The data query module receives query time parameters for querying device status data, including start and end times; determines a target statistical granularity matching the query time parameters from multiple pre-set statistical granularities; determines the query time range corresponding to the query time parameters based on the target statistical granularity; and searches for the target device status data corresponding to the query time parameters from the corresponding set database based on the query time range.

[0091] In some embodiments, the data acquisition device further includes: The control lock module is used to add a target lock to the session object corresponding to each state processor after creating or updating the session object corresponding to that state processor. The target lock includes at least one of a state lock, a transition lock, and an identity lock.

[0092] In some embodiments, the M state processors include at least two of the following: idle state processor, error state processor, local mode processor, and abnormal state processor.

[0093] In some embodiments, the session object includes at least one of session object identifier, device status feature data, session status, session object start time and end time.

[0094] This application also provides an industrial equipment operation data acquisition and statistics system, such as... Figure 5 As shown, the system includes a data acquisition layer 51, a data processing layer 52, a session management layer 53, a time processing layer 54, a data persistence layer 55, and a statistical analysis layer 56. The data acquisition layer 51 is implemented based on an event-driven and chain-of-responsibility pattern, exhibiting low invasiveness and high scalability. The data processing layer 52 is implemented based on a target chain of responsibility and is used to process the device status data collected by the data acquisition layer 51. The session management layer 53 uses session objects and a dual-layer storage mechanism to record the data processed by the data processing layer 52, ensuring state independence and data recoverability. For example, each session state is isolated from each other, can be processed in parallel, and can still be recovered after a service restart. The time processing layer 54 is used to process the active session data generated by the session management layer 53 in a time dimension and stores the processed data in the data persistence layer 55. The data persistence layer 55 stores the processed data from the time processing layer 54, as well as the original data collected by the data acquisition layer 51. The statistical analysis layer 56, relying on time splitting and multi-granularity query capabilities, uses the data stored in the data persistence layer 55 to perform high-precision and highly flexible statistical analysis.

[0095] like Figure 5As shown, the data acquisition layer 51 includes a device connection manager 511, a status data receiver 512, and an event bus 513. The device connection manager 511 communicates with multiple industrial devices to receive raw data reported by each industrial device in real time. The status data receiver 512 parses the raw data according to a predefined data format, encapsulates the parsed status data into a unified format, and sends it to the event bus. For example, a loader sends a status data packet once per second, containing latitude and longitude, speed, engine speed, hydraulic pressure, etc. The status data receiver 512 parses this data, verifies its integrity and rationality, and then generates a status data event, which is published to the event bus 513. The event bus 513 is responsible for receiving events from the status data receiver 512 and distributing the events to the corresponding status processors in the data processing layer 52 that subscribe to the event. Furthermore, the data processing layer 52 includes a chain of responsibility consisting of an idle status processor 201, an error status processor 202, a local mode processor 203, and an abnormal status processor 204. When a device event enters the chain of responsibility, it is first passed to the idle status processor 201. Each processor checks whether the event falls within its processing scope: if it does, it creates or updates a session record to process the event and continues to pass it to the next processor in the chain after the event processing is complete; if it does not match, it is passed to the next processor in the chain.

[0096] See also Figure 5 The session management layer 53 includes a memory session management module 531, a Redis module 532, and a session recovery module 533. The session management layer 53 manages the complete lifecycle of all active sessions, employing a "memory + Redis" dual-layer storage architecture to ensure data reliability and service recoverability. The memory session management module 531 maintains all currently active session objects. When the state processor creates a new session, the memory manager allocates memory space and builds an index for quick lookup and updates. The Redis module 532 periodically synchronizes session data to a distributed cache. Whenever a session is created, updated, or terminated, changes are immediately synchronized to Redis. The session recovery module 533 automatically executes the recovery process when the service restarts. It first checks if there is any unfinished session data in Redis; if so, it reloads the unfinished session data into memory. During recovery, the session recovery module 533 checks the difference between the last recorded time and the current time for each session. If the difference exceeds a preset threshold (e.g., 5 minutes), it determines that the session continued during the service interruption and automatically generates supplementary records to ensure the continuity of statistical data.

[0097] Secondly, the time processing layer 54 includes a cross-time boundary detection module 541, a time segmentation module 542, and an hourly data generation module 543. The time processing layer 54 is responsible for accurately calculating the distribution of sessions across various time dimensions, ensuring the accuracy and flexibility of statistical data, especially supporting multi-granularity statistics by hour and by day. Specific implementations of the cross-time boundary detection module 541, the time segmentation module 542, and the hourly data generation module 543 can be found in the description of the foregoing embodiments; for the sake of brevity, they will not be repeated here.

[0098] Furthermore, the data persistence layer 55 includes an hourly BI data table 551, a task log table 552, and an industrial equipment log table 553. The data persistence layer 55 stores processed data in a relational database according to different uses and formats, supporting efficient querying and long-term statistical analysis. The hourly BI data table 551 stores hourly aggregated equipment operation data. One record is generated for each device every hour, containing metrics such as cumulative duration of various states, number of tasks, and workload within that hour. The task log table 552 records detailed information for each task. Whenever a device starts a new task, a task record is created, continuously updated as the task executes, and the final status is recorded upon task completion. Each record includes information such as task identifier, device identifier, start time, end time, task type, execution status, workload, and energy consumption. The data in the task log table 552 supports task-level efficiency analysis and problem tracing. The industrial equipment log table 554 records key events and status changes of the equipment. Unlike the BI data table, the log table records events in chronological order, rather than aggregating them by time. It includes various events such as equipment online / offline status, fault occurrence / recovery, mode switching, and maintenance operations. The log data in Industrial Equipment Log Table 554 is mainly used for fault diagnosis, behavior analysis, and compliance auditing.

[0099] Furthermore, the statistical analysis layer 56 includes a multi-dimensional query engine module 561, an indicator calculation module 562, and a data aggregation module 563. Based on persistent data, the statistical analysis layer 56 provides flexible querying and in-depth analysis capabilities, transforming raw data into valuable business insights to support management decisions. The query engine layer 561 provides a SQL-like query interface, supporting queries by multiple dimensions such as time, device, project, and status type. Users can specify query conditions with simple parameters, and the engine automatically generates the optimal query plan, retrieves data from the database, and returns formatted results. The indicator calculation module 562 has a built-in complete indicator system calculation logic, which can automatically calculate various key performance indicators based on basic data, such as equipment utilization rate, task success rate, energy efficiency, and manual intervention rate. The data aggregation module 563 is used to aggregate fine-grained data into higher-level summary data, such as aggregating by hour to day, week, or month; or by device to fleet, project, or region.

[0100] Accordingly, this application also provides an electronic device, which can be a terminal, such as a smartphone, tablet computer, laptop computer, touch screen, game console, personal computer (PC), personal digital assistant (PDA), or other terminal device. Alternatively, the electronic device can be a server.

[0101] like Figure 6 As shown, Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 1100 includes a processor 1101 with one or more processing cores, a memory 1102 with one or more computer-readable storage media, and a computer program stored on the memory 1102 and executable on the processor. The processor 1101 and the memory 1102 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0102] The processor 1101 is the control center of the electronic device 1100. It connects various parts of the electronic device 1100 via various interfaces and lines. By running or loading software programs and / or units stored in the memory 1102, and by calling data stored in the memory 1102, it executes various functions of the electronic device 1100 and processes data, thereby providing overall monitoring of the electronic device 1100. The processor 1101 can be a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), etc., and can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0103] In this embodiment, the processor 1101 in the electronic device 1100 loads the instructions corresponding to the processes of one or more applications into the memory 1102 according to the following steps, and the processor 1101 runs the applications stored in the memory 1102 to realize various functions, such as: acquiring equipment status data of industrial equipment; inputting the equipment status data into a pre-set target responsibility chain, wherein the target responsibility chain includes M status processors, each status processor corresponding to the operating status of the industrial equipment, and M is an integer greater than 1; and processing the equipment status data by each status processor in the target responsibility chain.

[0104] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0105] Optional, such as Figure 6 As shown, the electronic device 1100 also includes: a touch display screen 1103, a radio frequency circuit 1104, an audio circuit 1105, an input unit 1106, and a power supply 1107. The processor 1101 is electrically connected to the touch display screen 1103, the radio frequency circuit 1104, the audio circuit 1105, the input unit 1106, and the power supply 1107. Those skilled in the art will understand that... Figure 6 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0106] The touch display screen 1103 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 1103 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 1101. It can also receive and execute commands from the processor 1101. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 1101 to determine the type of touch event. Subsequently, the processor 1101 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the touch display screen 1103 to achieve input and output functions. However, in some embodiments, the touch panel and the touch display screen 1103 can be implemented as two independent components to achieve input and output functions. That is, the touch display screen 1103 can also be used as part of the input unit 1106 to achieve input functions.

[0107] The radio frequency circuit 1104 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices.

[0108] Audio circuit 1105 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuit 1105 can convert received audio data into electrical signals and transmit them to the speaker, where the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuit 1105, converted back into audio data, and then processed by processor 1101 before being transmitted via radio frequency circuit 1104 to, for example, another electronic device, or output to memory 1102 for further processing. Audio circuit 1105 may also include an earphone jack to provide communication between peripheral headphones and electronic devices.

[0109] The input unit 1106 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0110] Power supply 1107 is used to supply power to various components of electronic device 1100. Optionally, power supply 1107 can be logically connected to processor 1101 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 1107 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0111] although Figure 6 As not shown in the diagram, electronic device 1100 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0112] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0113] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0114] To this end, embodiments of this application provide a computer-readable storage medium storing multiple computer programs. These computer programs can be loaded by a processor to execute any of the industrial equipment operation data acquisition methods provided in this application. The computer program can execute the following steps of the industrial equipment operation data acquisition method: acquiring equipment status data of the industrial equipment; inputting the equipment status data into a pre-set target responsibility chain, wherein the target responsibility chain includes M status processors, each status processor corresponding to the operating status of the industrial equipment, and M is an integer greater than 1; and processing the equipment status data through each status processor in the target responsibility chain.

[0115] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0116] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0117] Since the computer program stored in the computer-readable storage medium can execute any of the industrial equipment operation data acquisition methods provided in the embodiments of this application, the beneficial effects that any of the industrial equipment operation data acquisition methods provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0118] According to one aspect of this application, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in the various optional implementations of the above embodiments.

[0119] In the above embodiments of the industrial equipment operation data acquisition device, computer-readable storage medium, electronic device, and computer program product, the descriptions of each embodiment have different focuses. Parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process and beneficial effects of the above-described industrial equipment operation data acquisition device, computer-readable storage medium, computer program product, electronic device, and their corresponding units can be referred to the description of the industrial equipment operation data acquisition method in the above embodiments, and will not be repeated here.

[0120] The foregoing has provided a detailed description of a method, apparatus, electronic device, computer-readable storage medium, and computer program product for collecting industrial equipment operation data according to embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for collecting operational data of industrial equipment, characterized in that, include: Acquire equipment status data from industrial equipment; The device status data is input into a pre-set target responsibility chain, wherein the target responsibility chain includes M status processors, each status processor corresponding to the operating status of the industrial equipment, and M is an integer greater than 1; The device state data is processed by each state processor in the target responsibility chain.

2. The method as described in claim 1, characterized in that, The process of processing the device state data through each state processor in the target responsibility chain includes: For each state processor, determine whether the conditions of the device operating state corresponding to that state processor are met based on the device state data; If the conditions are met, a session object corresponding to the state processor is created or updated to record the duration of the device's operating state. If the conditions are not met, the creation or update operation will not be performed.

3. The method as described in claim 2, characterized in that, The M state processors are arranged in a preset order. After each state processor finishes processing, it passes the device state data to the next state processor.

4. The method as described in claim 2, characterized in that, The method further includes: For each state processor, the target session data generated by the session object of that state processor is synchronously stored in memory and a distributed cache; if it is determined that the session object of that state processor has ended, the target session data generated by the session object of that state processor is stored in the designated database.

5. The method as described in claim 4, characterized in that, The method further includes: After the memory service is interrupted, in response to the storage service provided by the memory, active session data is read from the distributed cache, wherein the active session data is session data generated by session objects that were not terminated before the memory service was interrupted; In response to the deserialization operation, an active session object corresponding to the active session data is generated in the memory; Based on the time in the active session data, interruption completion data is generated and added to the active session object.

6. The method as described in claim 2, characterized in that, The method further includes: For each state processor, if the duration of the session object corresponding to the state processor reaches a set time statistics boundary within the duration of the session object corresponding to the state processor, then according to the time statistics boundary, the target session data corresponding to the state processor is split into multiple time segment corresponding record data, wherein the target session data is generated by the session object corresponding to the state processor.

7. The method as described in claim 6, characterized in that, For each state processor, based on the time statistics boundary, the target session data corresponding to that state processor is split into multiple time segments of recorded data, including: For each state processor, based on the time statistics boundary, obtain the time boundary point corresponding to the session object of that state processor; Based on the time boundary points, the target session data corresponding to the state processor is split into record data corresponding to the multiple time segments.

8. The method as described in claim 1, characterized in that, The method further includes: Receive query time parameters for querying device status data, the query time parameters including start time and end time; Determine the target statistical granularity that matches the query time parameter from a set of pre-defined statistical granularities; Based on the target statistical granularity, determine the query time range corresponding to the query time parameter; Based on the query time range, the target device status data corresponding to the query time parameter is retrieved from the corresponding set database.

9. The method as described in claim 2, characterized in that, After creating or updating the session object corresponding to each state handler, the method further includes: For each state processor, a target lock is added to the session object corresponding to that state processor, wherein the target lock includes at least one of a state lock, a transition lock, and an identity lock.

10. The method according to any one of claims 1-9, characterized in that, The M state processors include at least two of the following: idle state processor, error state processor, local mode processor, and abnormal state processor.

11. A device for acquiring industrial equipment operation data, characterized in that, include: The data acquisition module is used to acquire equipment status data of industrial equipment; The data transmission module is used to input the device status data to a pre-set target responsibility chain, wherein the target responsibility chain includes M status processors, each status processor corresponding to the operating status of the industrial equipment, and M is an integer greater than 1; The data processing module is used to process the device status data through each status processor in the target responsibility chain.

12. An electronic device, characterized in that, It includes a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to execute the steps of the industrial equipment operation data acquisition method as claimed in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores multiple instructions adapted for loading by a processor to perform the steps of the method for acquiring industrial equipment operating data as claimed in any one of claims 1 to 10.

Images