An industrial host computer remote operation fault tracing system and method

Abstract

The application provides an industrial host computer remote operation fault tracing system and method. The system comprises: a remote communication interface, which establishes a communication connection with a lower computer, receives running state data and communication link state data uploaded by the lower computer, and issues a remote instruction to the lower computer, instructing the lower computer to perform a remote operation action; a log storage, which is connected with the remote communication interface, generates and stores log records in response to communication interaction behavior of the remote communication interface; the log records are used to record operation behavior of the issued remote instruction, and comprise a time stamp, an operator identity, an operation address, a written value and an execution result; a fault diagnosis and tracing processor, which is connected with the log storage, extracts log records within a preset time window with a trigger time of a fault event and a corresponding operation address as search conditions, and generates a fault tracing chain in association when a fault event is detected. The application realizes full-process tracing and rapid positioning of a fault of remote operation, and improves operation and maintenance efficiency.

Description

Technical Field

[0001] This invention relates to the field of industrial control, and specifically to an industrial host computer remote operation fault tracing system and method. Background Technology

[0002] In the field of industrial control, host computer software, as the core hub for human-machine interaction and equipment control, undertakes critical tasks such as parameter configuration, operation monitoring, calibration, and data recording. With the increasing variety of industrial equipment and the growing complexity of on-site deployment environments, host computers need to communicate with different types of controllers, parse their respective parameter protocols, and support calibration, configuration, and debugging operations in remote maintenance scenarios. However, existing host computer systems still have significant shortcomings in parameter adaptation, remote control, and safety traceability.

[0003] Specifically, the current technology suffers from the following main shortcomings: First, parameter parsing rules heavily rely on manual pre-configuration. The system cannot automatically recognize the communication protocol formats of different devices and models. Each time a new device is connected, the parsing template must be manually written or adjusted, resulting in high adaptation costs and poor versatility, severely restricting the rapid deployment and maintenance efficiency of various types of equipment. Second, core operations such as axial calibration, parameter configuration, and time synchronization can usually only be performed locally, lacking comprehensive remote operation capabilities. This makes it difficult to meet the urgent needs of centralized operation and maintenance and remote debugging of distributed equipment. Maintenance personnel often have to be on-site, significantly extending fault response time. Third, the system lacks a complete operation log and fault tracing mechanism. After an anomaly occurs, it is impossible to quickly locate the cause, operator, and abnormal node. The troubleshooting process relies on experience and is inefficient. Fourth, operation permissions are not subject to hierarchical management. The operational boundaries of different roles are blurred, posing risks of misoperation, unauthorized operation, and illegal parameter modification, which may compromise equipment safety and production stability.

[0004] In summary, the most prominent technical problem with existing host computer systems is the lack of full-process log recording and automatic fault tracing mechanisms during remote operations, resulting in low operation and maintenance efficiency and difficulty in troubleshooting. Summary of the Invention

[0005] In view of this, it is necessary to propose an industrial host computer remote operation fault tracing system and method to solve the problems of lack of remote operation log records leading to untraceable faults and low efficiency due to reliance on manual experience for fault diagnosis in the existing technology.

[0006] In a first aspect, the present invention provides an industrial host computer remote operation fault tracing system, comprising: The remote communication interface is used to establish a communication connection with the lower-level machine, receive the running status data and communication link status data uploaded by the lower-level machine, and send remote commands to the lower-level machine to instruct the lower-level machine to perform remote operation actions. A log storage device, connected to the remote communication interface, is used to respond to the communication interaction behavior of the remote communication interface, generate and store log records based on the running status data; the log records are used to record the operation behavior of issuing the remote command, and include timestamp, operator identity, operation address, written value and execution result; The fault diagnosis and tracing processor is connected to the remote communication interface and the log storage. When a fault event is detected based on the communication link status data, it automatically extracts the log records within a preset time window from the log storage using the trigger time of the fault event and the corresponding operation address as search conditions, and associates and generates a fault tracing chain.

[0007] In one possible implementation, the operation address is the device address or register address of the lower-level machine, and the preset time window is a preset time period that traces back from the time the fault event was triggered.

[0008] In one possible implementation, the operating status data uploaded by the lower-level machine and received by the remote communication interface includes device status data, current data, position and speed data, and fault information data. The device status data is uploaded by the lower-level machine according to a first preset cycle; The current data is uploaded by the lower-level machine according to a second preset cycle; The position and velocity data are uploaded by the lower-level machine according to a third preset cycle; The fault information data is reported immediately by the lower-level machine when a fault event is triggered; The first preset period, the second preset period, and the third preset period are configured by the host computer.

[0009] In one possible implementation, the log storage uses an embedded database to store the log records and employs a time-based round-robin cleanup strategy and / or a capacity threshold cleanup strategy to automatically clean up the stored log records.

[0010] In one possible implementation, the system further includes: The permission management register, connected to the remote communication interface, is used to store and verify the permission level of the current operator; The permission levels include at least a first permission level and a second permission level, where the first permission level is higher than the second permission level; the remote communication interface is only allowed to issue the remote command when the current operator's permission is not lower than a preset permission threshold.

[0011] In one possible implementation, the remote communication interface is configured to perform remote operations as follows: In response to the remote command triggered by the user, the permission management register is invoked to verify the current operator's permission level and to determine whether the communication link status data and the running status data uploaded by the lower-level machine meet the preset working conditions. When the permission verification is successful and the preset working conditions are met, the remote instruction is encapsulated into a communication frame and sent to the lower-level machine. Receive the calibration status and real-time position and speed data uploaded by the lower-level device, and refresh the display; Receive the calibration completion status code uploaded by the lower-level machine and store the calibration result.

[0012] In one possible implementation, the remote communication interface communicates with the lower-level machine via a CAN bus, and the communication frame is an 8-byte fixed-length data frame; the communication frame includes an uplink request frame sent by the upper-level machine to the lower-level machine, and a downlink response frame uploaded by the lower-level machine to the upper-level machine; The uplink request frame contains, in sequence: 1 byte instruction code, 1 byte reserved bit, 2 bytes parameter address, 2 bytes write data, 1 byte reserved bit and 1 byte checksum; The downlink response frame contains, in sequence: 1 byte of response code, 1 byte of execution result, 2 bytes of parameter address, 2 bytes of read data, 1 byte of device status, and 1 byte of checksum. After receiving the uplink request frame, the lower-level machine parses its message identifier and responds to the uplink request frame; after receiving the downlink response frame, the remote communication interface parses its message identifier and processes the downlink response frame.

[0013] In one possible implementation, the system further includes: a disconnection protection controller connected to the remote communication interface; the disconnection protection controller includes: The first-level early warning unit is used to trigger a communication link early warning when no response data is received from the lower-level machine for more than a first preset time. The second-level disconnection protection unit is used to determine that the communication link has timed out and disconnected when no response data is received from the lower-level machine for more than a second preset time; the second preset time is longer than the first preset time. The third-level hardware disconnection protection unit is used to determine the physical layer hardware disconnection when no differential signal is detected between the high-level line CAN_H and the low-level line CAN_L of the CAN bus, lock the device status and prohibit remote operation.

[0014] In one possible implementation, the system further includes: A parameter parser, connected to the remote communication interface, is used to receive raw data frames uploaded by the lower-level machine, automatically identify parameter types based on address ranges and / or numerical value ranges, and match the corresponding parsing strategy to parse the raw data frames to form the running status data. When the address range contains a year address and a number address, and the data conforms to the combination format of the year field and the number field, the parameter parser determines that the data in the original data frame is the device number, and parses the data in the original data frame into a device number string; When the address segment is a preset time register address segment, and the values ​​of each field in the original data frame fall within the preset legal time range corresponding to seconds, minutes, hours, days, months, and years, the parameter parser determines that the data in the original data frame is real-time clock data and parses the data in the original data frame into standard time data. When the physical range of the value in the original data frame falls within the preset range of current parameters, position parameters, or PID parameters, the parameter parser determines that the data is the corresponding current parameter, position parameter, or PID parameter, and parses the value in the original data frame into the engineering value of the corresponding physical quantity.

[0015] Secondly, the present invention also provides a method for tracing faults in remote operation of an industrial host computer, which is executed using the industrial host computer remote operation fault tracing system described in any of the above implementations, including: The permission management register responds to remote commands triggered by the user and verifies the permission level of the current operator; the remote communication interface determines whether the communication link status data between the operator and the lower-level machine and the running status data uploaded by the lower-level machine meet the preset operating conditions. When the permission verification is successful and the preset working conditions are met, the remote communication interface encapsulates the remote instruction into a communication frame and sends it to the lower-level machine to instruct the lower-level machine to perform a remote operation; the log storage generates and stores log records. During the remote operation performed by the lower-level machine, the remote communication interface receives the calibration status and real-time position and speed data periodically uploaded by the lower-level machine, and refreshes the display. During the entire process of performing remote operation, the disconnection protection controller continuously monitors the status data of the communication link. When no response data is received from the lower-level machine for more than a second preset time, it determines that the communication link has timed out and disconnects. It automatically generates an emergency stop command and sends it to the lower-level machine to terminate the remote operation. When a fault diagnosis and tracing processor detects a fault event, it uses the trigger time of the fault event and the corresponding operation address as search conditions to extract log records within a preset time window from the log storage, associates the log records with the fault event, and generates a fault tracing chain.

[0016] The beneficial effects of this invention are as follows: The industrial host computer remote operation fault tracing system provided by this invention firstly establishes a communication connection with the slave computer through a remote communication interface, receives the operating status data and communication link status data uploaded by the slave computer, and sends remote commands to the slave computer to instruct it to perform remote operation actions. This breaks through the geographical limitations of local operation and realizes remote operation and maintenance and debugging of distributed devices. Maintenance personnel can complete core operations such as calibration and parameter configuration without being physically present on-site, significantly shortening fault response time. Secondly, the system responds to the communication interaction behavior of the remote communication interface through a log storage system, generating and storing operation data containing key fields such as timestamp, operator identification, operation address, written value, and execution result based on the operating status data. Log recording enables complete and traceable recording of all remote command issuance operations, providing comprehensive data support for post-event auditing and accountability. Finally, when a fault event is detected based on communication link status data, the fault diagnosis and tracing processor automatically extracts log records within a preset time window from the log storage and generates a fault tracing chain by using the trigger time and corresponding operation address of the fault event as search criteria. This allows the system to automatically associate relevant operation logs after a fault occurs, quickly locate the cause of the fault, the operator, and the abnormal node, thereby effectively solving the problems of untraceable remote operation and low efficiency of fault diagnosis relying on manual experience in existing host computer systems, significantly improving the operation and maintenance efficiency and fault response capability of industrial host computer systems. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram of an embodiment of the industrial host computer remote calibration fault tracing system provided by the present invention; Figure 2This is a schematic diagram of another embodiment of the industrial host computer remote calibration fault tracing system provided by the present invention; Figure 3 This is a schematic flowchart of an embodiment of the industrial host computer remote calibration fault tracing method provided by the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention 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 the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0020] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0021] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] Before demonstrating the embodiments, the following terms will be explained.

[0024] Host computer: In an industrial control system, the upper-level computer device responsible for sending operation commands, receiving and processing data transmitted back from the lower-level computer.

[0025] Lower-level controller: In an industrial control system, the underlying controller directly controls field devices, executes instructions from the upper-level controller, and collects field data.

[0026] CAN bus: Controller Area Network, a serial communication protocol widely used in industrial control and automotive electronics.

[0027] Communication frame: A complete data unit transmitted on the CAN bus, containing a message identifier and an 8-byte data segment.

[0028] Differential signal: A method of transmitting data through the voltage difference between the two wires CAN_H and CAN_L.

[0029] Register address: An address number used internally by the lower-level machine to identify the storage location of different parameters.

[0030] MBC Controller (Multi-loop Controller): In this invention, the automatic matching and parsing of different controllers is achieved by identifying this number.

[0031] PID (Proportional-Integral-Derivative) parameters: In this invention, precise control of the current loop, speed loop, and position loop of the equipment is achieved by analyzing these parameters.

[0032] RTC (Real-Time Clock) time: is the time maintained by an independent hardware chip on the motherboard of a computer or electronic device, which continues to run even when the power is off.

[0033] This invention provides an industrial host computer remote operation fault tracing system and method, which are described below.

[0034] Figure 1 This is a schematic diagram of an embodiment of the industrial host computer remote operation fault tracing system provided by the present invention; the industrial host computer remote operation fault tracing system 100, as shown... Figure 1 As shown, it includes: The remote communication interface 101 is used to establish a communication connection with the lower-level machine, receive the running status data and communication link status data uploaded by the lower-level machine, and send remote commands to the lower-level machine to instruct the lower-level machine to perform remote operation actions. The log storage 102 is connected to the remote communication interface 101 and is used to respond to the communication interaction behavior of the remote communication interface. It generates and stores log records of operation behavior based on the running status data. The log records are used to record the operation behavior of issuing remote instructions and include timestamp, operator identity, operation address, written value and execution result. The fault diagnosis and tracing processor 103 is connected to the remote communication interface 101 and the log storage 102. When a fault event is detected based on the communication link status data, it automatically extracts log records within a preset time window from the log storage, associates them, and generates a fault tracing chain, using the trigger time of the fault event and the corresponding operation address as search conditions.

[0035] It should be noted that, in this invention, the industrial host computer remote operation fault tracing system refers to the host computer itself. The host computer integrates functional units such as a remote communication interface, a log storage device, and a fault diagnosis and tracing processor. Through the collaborative work of these units, remote operation, log recording, and fault tracing are achieved.

[0036] In one embodiment of the present invention, the log storage uses an embedded SQLite database to store log records. The field definitions of the log record table are shown in Table 1 below: Table 1: Operation Log Records

[0037] The corresponding table creation statement is as follows: CREATE TABLE operation_log ( id BIGINT NOT NULL PRIMARY KEY AUTO_INCREMENT, timestamp BIGINT NOT NULL, operator VARCHAR(32) NOT NULL, op_addr INT NOT NULL, write_value FLOAT NOT NULL, exec_result TINYINT NOT NULL, fault_code INT NOT NULL ); It should be noted that the example execution result values ​​from 0 to 6 cover all status types of the execution result (pending execution, success, timeout failure, physical disconnection, insufficient permissions, unmet working conditions, and over-limit protection triggered).

[0038] This embodiment uses an embedded SQLite database to store structured log records, enabling the system to achieve efficient log reading and writing without the need for a separate database service, thus reducing deployment complexity. Through standardized log field definitions and unified execution result status code encoding rules, it provides the fault diagnosis and tracing processor with structured log data that can be quickly retrieved and filtered, making it possible to trace the entire process of remote operation and quickly locate faults.

[0039] In some embodiments of this invention, the host computer uses an industrial control computer as the main control hardware platform, possessing characteristics of wide-temperature operation, vibration resistance, electromagnetic interference resistance, and long-term stable operation, making it suitable for complex working conditions such as industrial sites. In terms of hardware configuration, the host computer uses a standard x86 architecture industrial control motherboard, with a standard memory of no less than 4GB and a local solid-state drive of no less than 128GB, meeting the performance requirements for program execution, log storage, data processing, and interface rendering. The host computer runs a Windows 10 or Windows 11 industrial edition operating system, offering strong system compatibility and a complete graphical interface. It can stably run the host computer software, device drivers, and database programs of this invention, and supports background services, scheduled tasks, and asynchronous log read / write functions.

[0040] The industrial host computer remote operation fault tracing system provided in this embodiment of the invention first establishes a communication connection with the slave computer through a remote communication interface, receives the operating status data and communication link status data uploaded by the slave computer, and sends remote commands to the slave computer to instruct it to perform remote operation actions. This breaks through the geographical limitations of local operation, enabling remote operation and maintenance of distributed devices. Maintenance personnel can complete core operations such as calibration and parameter configuration without being physically present on-site, significantly shortening fault response time. Secondly, the system responds to the communication interaction behavior of the remote communication interface through a log storage system, generating and storing operation logs based on the operating status data, including key fields such as timestamp, operator identification, operation address, written values, and execution results. The system records and tracks all remote command operations throughout the entire process, providing comprehensive data support for post-event auditing and accountability. Finally, when a fault event is detected based on communication link status data, the fault diagnosis and tracing processor automatically extracts log records within a preset time window from the log storage, using the trigger time and corresponding operation address as search criteria, and generates a fault tracing chain. This allows the system to automatically link relevant operation logs after a fault occurs, quickly locating the cause of the fault, the operator, and the abnormal node. This effectively solves the problems of untraceable remote operations and low efficiency in fault diagnosis relying on manual experience in existing host computer systems, significantly improving the operational efficiency and fault response capabilities of industrial host computer systems.

[0041] In some embodiments of the present invention, the operation address is the device address or register address of the lower-level machine, and the preset time window is a preset time period that traces backward from the time the fault event is triggered.

[0042] In some embodiments of the present invention, the fault diagnosis and tracing processor automatically binds fault events to operation logs through the following association algorithm.

[0043] When the system detects a fault event, the fault diagnosis and tracing processor uses the fault occurrence time as the center and extracts a fixed time window as the search range. This time window is the aforementioned "preset time period for tracing back from the fault event trigger time." Simultaneously, using the operation address corresponding to the fault event as the filtering condition, which is the aforementioned "lower-level device address or register address," all operation logs related to the faulty device within this time window are retrieved from the log storage. Then, all relevant operation logs within this time window are associated with the current fault event, and the association results are stored in the fault record table, realizing a tracing chain where "one fault corresponds to a set of associated operation logs."

[0044] The query logic corresponding to the above association algorithm is as follows: Starting with 1000ms prior to the fault occurrence time, and ending with the fault occurrence time, all relevant operation logs within this time window are queried using the operation address of the faulty device as a filter condition, and then sorted in reverse chronological order. In one embodiment, this query statement can be expressed as: SELECT log.timestamp, log.operator, log.op_addr, log.write_value,log.exec_result, log.fault_code FROM operation_log log WHERE log.timestamp>= (fault_timestamp - 1000) AND log.timestamp<= fault_timestamp AND log.op_addr = fault_device_addr ORDER BY log.timestamp DESC; Where fault_timestamp is the timestamp of the fault occurrence, and fault_device_addr is the operation address corresponding to the fault event. The length of the above time window is preset by the host computer, which is 1000ms in a preferred embodiment, and can be adjusted to different durations such as 2000ms or 500ms in other embodiments according to actual needs.

[0045] Compared to simply relying on fault code indexing or fuzzy matching, the above association algorithm does not depend on a predefined fault-log mapping table. The fault diagnosis and tracing processor uses the spatiotemporal attributes of the fault event itself (occurrence time and operation address) as the retrieval conditions. It actively associates logs through dual filtering of time window and device address, which can cover undefined fault types. Moreover, the same set of operation logs can be associated with different fault events multiple times without the need to establish a correspondence between fault codes and log types in advance.

[0046] This embodiment uses the trigger time and operation address of the fault event as search conditions and combines a preset time window to actively associate log records, enabling the fault diagnosis and tracing processor to automatically complete log binding without relying on a predefined fault-log mapping table. The dual filtering mechanism of time window and device address can cover undefined fault types, and the same set of operation logs can be associated with different fault events multiple times, improving the flexibility and accuracy of fault tracing and thus effectively shortening the fault investigation time.

[0047] In some embodiments of the present invention, the operating status data uploaded by the lower-level machine and received by the remote communication interface includes device status data, current data, position and speed data, and fault information data. Device status data is uploaded by the lower-level machine according to the first preset cycle; The current data is uploaded by the lower-level machine according to the second preset cycle; Position and velocity data are uploaded by the lower-level computer according to the third preset cycle; Fault information data is reported immediately by the lower-level machine when a fault event is triggered; The first, second, and third preset cycles are configured by the host computer.

[0048] In one embodiment of the present invention, the specific content, format, transmission period, and communication frame ID of the running status data uploaded by the lower-level machine received by the remote communication interface are shown in Table 2 below: Table 2: Data types and transmission parameters of running status uploaded by the lower-level machine

[0049] The operating status data received by the lower-level machine via the remote communication interface is transmitted in the following manner: Device status data uses a custom binary frame format, with communication frame ID 0x01, and is uploaded by the lower-level machine at a fixed period of 100ms. Three-phase current data uses a custom binary frame format, with communication frame ID 0x02, and is uploaded by the lower-level machine at a fixed period of 10ms. Position and speed data uses a custom binary frame format, with communication frame ID 0x03, and is uploaded by the lower-level machine at a fixed period of 20ms. Fault information data uses a custom binary frame format, with communication frame ID 0x04, and is reported immediately by the lower-level machine when a fault event is triggered, without being limited by a fixed period. The first preset period (100ms), second preset period (10ms), and third preset period (20ms) mentioned above are all configured by the upper-level machine to the lower-level machine via the remote communication interface.

[0050] This embodiment configures different fixed upload cycles for different types of data such as device status, current, position, and speed, and distributes them uniformly by the host computer. This allows the host computer to flexibly adjust the transmission frequency according to the real-time requirements of various types of data, avoiding the waste of bus bandwidth. Fault information data adopts an event-triggered real-time reporting method to ensure that abnormal states can be obtained by the host computer as soon as possible and trigger disconnection protection or fault tracing process, thereby improving the real-time performance of status monitoring and system response speed during remote operation.

[0051] In one embodiment of the present invention, the log storage uses an embedded SQLite database to store log records. SQLite features no independent service process, cross-platform deployment, low power consumption, and high read / write efficiency, making it suitable for the localized log storage needs of host computers in both offline and online operating scenarios, and meeting the persistent log storage requirements of industrial equipment.

[0052] The log records contain six fixed fields: timestamp, operator identification, operation address, written value, execution result, and fault code. They are stored in a structured binary and text hybrid format. The average size of a single log record is 64 bytes, with the timestamp occupying 8 bytes, the operator identification 16 bytes, the operation address 2 bytes, the written value 4 bytes, the execution result 1 byte, and the fault code 2 bytes. The indexing and storage overhead is approximately 31 bytes.

[0053] Based on the storage capacity of the SQLite database, the theoretical maximum capacity of a single database is 128TB. This system is designed to store a maximum of 10 million log entries, corresponding to a maximum storage space of approximately 640MB, which can meet the high-density log storage requirements during long-term operation of the equipment.

[0054] This embodiment uses an embedded SQLite database as the log storage solution, enabling the system to achieve efficient log reading and writing without the need for a separate database service process, reducing deployment complexity and resource consumption. Through standardized definitions of six fixed fields and optimized field length allocation, the average size of a single log record is only 64 bytes, and up to 10 million log records can be stored in a limited storage space, meeting the needs of high-density log storage and fast querying during long-term operation of industrial equipment.

[0055] In some embodiments of the present invention, the log storage uses an embedded database to store log records and employs a time-based round-robin cleanup strategy and / or a capacity threshold cleanup strategy to automatically clean up the stored log records.

[0056] In some embodiments of the present invention, to ensure efficient utilization of storage resources, the log storage employs a dual cleanup mechanism combining a time-based round-robin cleanup strategy and a capacity threshold cleanup strategy. When both strategies are enabled simultaneously, a cleanup operation is executed whenever either strategy meets its trigger condition. The time-based round-robin cleanup strategy retains log records from the most recent 30 days by default, and logs older than 30 days are automatically deleted by the system. The capacity threshold cleanup strategy automatically cleans up the oldest 20% of log records when the log file size reaches a set upper limit of 640MB or the total number of log entries reaches 10 million, ensuring that the database is always in a healthy operating state. The above cleanup operations are executed asynchronously in the background and do not affect the normal communication, display, and remote operation functions of the host computer.

[0057] This embodiment employs a dual cleanup mechanism combining time rotation and capacity thresholds to ensure the log database remains in a healthy operating state from both time and storage capacity perspectives. The cleanup operation is performed asynchronously in the background, without affecting the normal remote operation and communication functions of the host computer, thus achieving a balance between the long-term stable operation of log storage and system availability.

[0058] In some embodiments of the present invention, such as Figure 2 As shown, the system also includes: The permission management register 104 is connected to the remote communication interface and is used to store and verify the permission level of the current operator; The permission levels include at least a first permission level and a second permission level, with the first permission level being higher than the second permission level; the remote communication interface is only allowed to issue remote commands when the current operator's permissions are not lower than the preset permission threshold.

[0059] In one embodiment of the present invention, the permission levels stored and verified in the permission management register include two levels: administrator permissions and operator permissions.

[0060] Administrator privileges are at the highest level, granting full access to all system functions. Administrators can view all tabs, including advanced debugging, parameter tuning, modal analysis, FFT analysis, linearity testing, fault logs, and system configuration. They can arbitrarily modify and access generator control parameters, including PID parameters, loop parameters, control modes, reference positions, and protection limits. Administrators can initiate advanced operations such as device self-calibration, self-centering, and RTC time read / write calibration. They can view all operating logs, fault alarm logs, and historical records. Administrators can access high-risk functions such as low-level configuration, CAN communication configuration, and system parameter initialization. They also have full access to full-screen mode, logout, and basic system settings.

[0061] Operator privileges are at the second level, granting only read-only and basic operation permissions, with all advanced configuration and debugging functions disabled. Under operator privileges, the system automatically disables specialized configuration pages such as the debugging page, modal analysis page, FFT analysis page, and linearity test page, retaining only the equipment operation monitoring and basic status viewing pages. Operators are only allowed to view real-time equipment operating data, including speed, current, voltage, position, and fault status; manual modification of any core control parameters is prohibited. Operators are prohibited from initiating high-risk operations such as self-alignment calibration, RTC calibration writing, and PID parameter modification. Operators can only view basic fault prompts and cannot view complete fault code logs or low-level debugging logs. Operators lack high-risk operation permissions such as system configuration, communication configuration, and parameter initialization; they can only use basic viewing functions and cannot modify any control logic or tuning parameters of the equipment.

[0062] This embodiment sets up two levels of permissions for administrators and operators to implement hierarchical control over remote operation functions, preventing unauthorized personnel from accidentally operating or modifying key parameters. Administrators have full functional permissions to ensure system maintainability, while operators only have read-only and basic monitoring permissions to ensure on-site operation safety, thereby achieving a balance between operational flexibility and equipment security.

[0063] In some embodiments of the present invention, the remote communication interface 101 is configured to perform remote operations as follows: In response to a remote command triggered by the user, the permission management register is invoked to verify the current operator's permission level and to determine whether the communication link status data and the running status data uploaded by the lower-level machine meet the preset working conditions. When the permission verification is successful and the preset working conditions are met, the remote instruction is encapsulated into a communication frame and sent to the lower-level machine. Receive calibration status and real-time position and velocity data uploaded by the lower-level device, and refresh the display; Receive the calibration completion status code uploaded by the lower-level device and store the calibration result.

[0064] In some embodiments of the present invention, such as Figure 2 As shown, the remote communication interface 101 communicates with the lower-level machine 200 via a CAN bus. The communication frame is an 8-byte fixed-length data frame. The communication frame includes an uplink request frame sent from the upper-level machine to the lower-level machine and a downlink response frame uploaded from the lower-level machine to the upper-level machine. The uplink request frame contains, in sequence: 1 byte instruction code, 1 byte reserved bit, 2 bytes parameter address, 2 bytes write data, 1 byte reserved bit and 1 byte checksum; The downlink response frame contains, in sequence: 1 byte of response code, 1 byte of execution result, 2 bytes of parameter address, 2 bytes of read data, 1 byte of device status, and 1 byte of checksum. After receiving an uplink request frame, the lower-level device parses its message identifier and responds to the uplink request frame; after receiving a downlink response frame, the remote communication interface parses its message identifier and processes the downlink response frame.

[0065] It should be noted that in this invention, all data frames transmitted between the host computer and the slave computer are collectively referred to as communication frames. The communication frames uploaded by the slave computer are not parsed before being input to the parameter parser; their original binary form is called the raw data frame (represented in hexadecimal form in the description), which is used by the parameter parser for parameter type identification and engineering value conversion. The resulting runtime status data is used by the log storage and the fault diagnosis and tracing processor.

[0066] In some embodiments of the present invention, the remote communication interface communicates with the lower-level computer via a CAN bus. The industrial control computer extends the CAN physical interface through the host USB port via an external USB-CAN adapter, conforming to the CAN 2.0A protocol standard. The bus uses twisted-pair cabling, and 120Ω terminating resistors are configured at both ends of the bus to ensure the stability of differential signal transmission. This interface is used to transmit operating status data, communication link status data, and to issue remote commands. Auxiliary interfaces include a USB interface and a network port. The USB interface is used to connect CAN converter devices, peripheral debugging, and program upgrades, while the network port is used for remote log export and remote program updates, and is not used as the main channel for real-time control.

[0067] This embodiment expands the CAN physical interface through a USB-CAN adapter, and ensures the stability of differential signal transmission by using twisted-pair cabling and terminating resistor configuration. The USB auxiliary interface is used for peripheral debugging and program upgrades, and the network port is used for log export and remote updates. This separation from the CAN interface, which serves as the main channel for real-time control, gives the system flexible hardware expansion capabilities.

[0068] In some embodiments of the present invention, the host computer and the slave computer communicate via a CAN bus, and the communication frame is an 8-byte fixed-length data frame. The message format of the uplink request frame (the request sent by the host computer to the slave computer) is shown in Table 3 below: Table 3: Message format of uplink request frames

[0069] The command code values ​​include: 0x01 for reading parameters, 0x02 for writing parameters, 0x10 for starting calibration, and 0x11 for stopping calibration. The written data is a configuration or control value. The checksum is obtained by XORing bytes 0 to 6 and is used to detect whether errors have occurred during the transmission of the communication frame.

[0070] The message format of the downlink response frame (the response returned by the lower-level machine to the upper-level machine) is shown in Table 4 below: Table 4: Message Format of Downlink Response Frames

[0071] The response code corresponds to the command code in the uplink request frame and is used to identify which request command the response frame replied to. The execution result can take the following values: 0 for success, 1 for failure, and 2 for busy. The XOR checksum is the same as that of the uplink request frame.

[0072] In one specific embodiment, the host computer sends a zero-point calibration command to the slave computer. The corresponding uplink request frame has the following ID: 0x10, and the data segment is [0x10, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x11]. Byte 0 (0x10) is the command code, indicating calibration start; bytes 2-3 (0x00, 0x01) are the parameter address, representing the axial travel calibration register; and byte 7 (0x11) is the XOR checksum of the first 7 bytes. Upon receiving the request frame, the slave computer parses its message identifier and responds. The corresponding downlink response frame has the ID 0x11, and its data segment includes fields such as the acknowledgment code, execution result, read data, and device status.

[0073] This embodiment uses 8-byte fixed-length communication frames and unified field definitions to provide a clear data structure for instruction interaction between the host computer and the slave computer. The combination of instruction code, parameter address and XOR check code takes into account the extended needs of various operation types and communication error detection, ensuring the reliability of remote instruction transmission and the consistency of the protocol.

[0074] In some embodiments of the present invention, such as Figure 2 As shown, the system also includes: Disconnection protection controller 105 is connected to a remote communication interface; the disconnection protection controller includes: The first-level early warning unit is used to trigger a communication link early warning when no response data is received from the lower-level machine for more than a first preset time. The second-level disconnection protection unit is used to determine that the communication link has timed out and disconnected when no response data is received from the lower-level machine for more than a second preset time. It automatically generates an emergency stop command and sends it to the lower-level machine. The second preset time is longer than the first preset time. The third-level hardware disconnection protection unit is used to determine the physical layer hardware disconnection when no differential signal is detected between the high-level line CAN_H and the low-level line CAN_L of the CAN bus, lock the device status and prohibit remote operation.

[0075] In some embodiments of the present invention, the disconnection protection controller 105 performs disconnection detection and protection actions according to the following three-level protection mechanism, as shown in Table 5: Table 5: Triggering conditions and corresponding actions of the three-level protection of the disconnection protection controller

[0076] This embodiment divides disconnection protection into three levels: Level 1 early warning, Level 2 disconnection, and Level 3 hardware disconnection. Different trigger conditions and protection actions are configured for different levels of anomalies, realizing a step-by-step response from link fluctuations to physical disconnection. This avoids overreaction to transient interference and ensures equipment safety under serious faults. The host computer and the slave computer work together to execute their respective protection actions, improving system security and maintainability in remote operation scenarios when communication is abnormal.

[0077] In some embodiments of the present invention, such as Figure 2 As shown, the system also includes: The parameter parser 106 is connected to the remote communication interface and is used to receive the raw data frame uploaded by the lower-level machine. It automatically identifies the parameter type based on the address range and / or the value range, and matches the corresponding parsing strategy to parse the raw data frame to form running status data. When the address range contains a year address and a number address, and the data conforms to the combination format of the year field and the number field, the parameter parser 106 determines that the data in the original data frame is the device number and parses the data in the original data frame into a device number string; When the address segment is the preset time register address segment, and the values ​​of each field in the original data frame fall within the preset legal time range corresponding to seconds, minutes, hours, days, months, and years, the parameter parser 106 determines that the data in the original data frame is real-time clock data and parses the data in the original data frame into standard time data. When the physical range of the value in the original data frame falls within the preset range of current parameter, position parameter, or PID parameter, the parameter parser 106 determines that the data is the corresponding current parameter, position parameter, or PID parameter, and parses the value in the original data frame into the engineering value of the corresponding physical quantity.

[0078] It should be noted that: raw data frames, operating status data, and communication link status data are three different types of data received by the remote communication interface from the lower-level machine. Among them, raw data frames are unparsed messages containing raw binary information such as device number, RTC time, current / position / PID parameters, etc. After being parsed by the parameter parser, they are converted into operating status data for use by the log storage and fault diagnosis and tracing processor. Communication link status data is independent of the above two types of data and is directly transmitted to the disconnection protection controller for communication link health monitoring.

[0079] In some embodiments of the present invention, the parameter parser 106 automatically identifies and parses the raw data frames uploaded by the lower-level machine according to the following rules: For device serial numbers, the parameter parser first checks if the address range contains a year address and a serial number address. When data is read from address ranges CAN_ADDR_MBC_YEAR, CAN_ADDR_MBC_NUM1, and CAN_ADDR_MBC_NUM2, and the year value is between 00 and 99, and the serial number is an 8-digit number that, when combined with the high 4 bits and low 4 bits, meets the format "2-digit year + MBC + 8-digit number", the parameter parser determines this data as the MBC controller serial number. When data is read from address ranges CAN_ADDR_ROT_YEAR, CAN_ADDR_ROT_NUM1, CAN_ADDR_ROT_NUM2, and CAN_ADDR_ROT_NUM3, and the data conforms to the format "3-digit year + 12-digit number", with the 12-digit number concatenated in three segments of 4+4+4 to form a complete serial number, the parameter parser determines this data as the rotor serial number.

[0080] In this embodiment, by detecting address segments and matching numerical formats, the parameter parser can automatically identify the MBC controller number and rotor number without the need to pre-configure parsing rules for different equipment models, thus reducing the manual cost of adapting the host computer system to new equipment. At the same time, the two number recognition logics have clear judgment conditions, ensuring the accuracy and consistency of parameter type recognition.

[0081] For RTC time, the parameter parser detects data in address ranges 0x0194 to 0x0197. When the second value falls between 0 and 59, the minute value between 0 and 59, the hour value between 0 and 23, the day value between 1 and 31, the month value between 1 and 12, and the year value between 2000 and 2100, the parameter parser identifies the data as real-time clock data. For current, position, and PID parameters, the parameter parser automatically matches the corresponding parsing method based on the address, name, and preset physical range assigned to different parameters by the lower-level machine, converting the raw values ​​into the corresponding engineering values ​​of the physical quantities.

[0082] This embodiment automatically determines the RTC time by pre-setting a legal time range, and automatically identifies and converts current, position, and PID parameters by matching address, name, and physical range. This allows the parameter parser to automatically identify and parse various industrial parameters without pre-configuring parsing rules for different parameter types, thus improving the compatibility of the host computer system with different types of parameters.

[0083] In some embodiments of the present invention, to ensure device control security, when the original data frame cannot match any of the above-mentioned identification rules, the parameter parser does not perform approximate matching, does not guess the protocol, and does not request manual intervention. Instead, it executes according to the following backup processing mechanism. First, the parameter parser marks the data as an unknown parameter type, retains its original address, original value, and timestamp, but does not parse it or display it as a valid engineering value. Second, the unknown data is securely shielded, does not participate in any control loop, does not participate in calibration operations, and does not participate in parameter writing, thus avoiding control risks caused by mis-parsing at the source. Simultaneously, the log storage automatically records the fault log of the unknown data, storing it as black box data. The host computer interface only provides silent prompts and does not use pop-up windows to interfere with operators.

[0084] This embodiment avoids the risk of misjudgment caused by approximate matching or guesswork analysis of unidentifiable data through a backup processing mechanism of "marking unknown + security shielding + logging + silent prompting", ensuring that unknown data does not participate in any control loop; at the same time, silent prompting avoids interference with operators and maintains the continuity of host computer operation while ensuring the safe operation of the equipment.

[0085] In some embodiments of the present invention, the parameter parser supports the CANopen protocol and can recognize and parse industrial parameters of various data types, including 16-bit unsigned integers, 32-bit unsigned integers, 64-bit unsigned integers, and 32-bit single-precision floating-point numbers. Taking MBC controller number recognition as an example, after receiving the original message 0x1234#08 00 00 00 0000 00 00, the parameter parser identifies its address range and numerical format, and parses it as 25MBC00001234. Taking rotor number recognition as an example, after receiving the original message 0x1235#00 01 00 02 00 03 00 00, the parameter parser parses it as R001-000100020003. The above two examples respectively demonstrate the specific process by which the parameter parser converts the original binary message into a readable MBC controller number string and rotor number string.

[0086] The parameter parser in this embodiment supports the CANopen protocol and various data types, enabling the host computer to be compatible with industrial parameters of different formats. Two specific parsing examples (MBC controller number and rotor number) demonstrate the process of converting the original binary message into a readable string, verifying the feasibility of the recognition rules.

[0087] In some embodiments of the present invention, the host computer adopts a layered modular architecture, combining a unified abstract interface layer and a plug-in driver mechanism to achieve adaptive compatibility with multiple devices and multiple protocols, as shown in Table 6.

[0088] Table 6: Layered Modular Architecture for Multi-Device, Multi-Protocol Adaptive Compatibility

[0089] The protocol adaptation layer works in conjunction with the parameter parser. When the parameter parser receives a raw data frame, the protocol adaptation layer automatically identifies the currently used protocol type based on the frame structure characteristics. The driver plugin layer then calls the parsing strategy corresponding to that device model, and the parameter parser completes the actual data parsing. When a new device model or protocol type needs to be added, only the parsing plugin in the driver plugin layer and the parsing strategy in the protocol adaptation layer need to be extended; there is no need to modify the existing code in the UI business layer and the unified abstract interface layer, ensuring good system scalability and compatibility.

[0090] This embodiment encapsulates protocol identification and device parsing functions in the protocol adaptation layer and driver plugin layer through a layered modular architecture and plug-in driver mechanism. This allows the system to only need to extend the corresponding plugins and parsing strategies when adding new device models or protocol types, without modifying the upper-layer business logic. This reduces system maintenance and expansion costs and improves compatibility and scalability in multi-device and multi-protocol scenarios.

[0091] To better implement the industrial host computer remote operation fault tracing system in this embodiment of the invention, correspondingly, such as Figure 3 As shown, this embodiment of the invention also provides a method for tracing faults in remote operation of an industrial host computer, which is executed using the industrial host computer remote operation fault tracing system described in the above embodiments, including: S301, the permission management register responds to remote commands triggered by the user and verifies the current operator's permission level; the remote communication interface determines whether the communication link status data between the remote operator and the lower-level machine and the running status data uploaded by the lower-level machine meet the preset operating conditions. S302. When the permission verification is successful and the preset working conditions are met, the remote communication interface encapsulates the remote command into a communication frame and sends it to the lower-level machine to instruct the lower-level machine to perform remote operation actions; the log storage generates and stores log records. S303, the remote communication interface receives the calibration status and real-time position and speed data periodically uploaded by the lower-level machine during the execution of remote operation actions, and refreshes the display accordingly; S304 The disconnection protection controller continuously monitors the communication link status data throughout the entire process of performing remote operation. When no response data is received from the lower-level machine for more than the second preset time, it determines that the communication link has timed out and disconnects. It automatically generates an emergency stop command and sends it to the lower-level machine to terminate the remote operation. When the S305 fault diagnosis and tracing processor detects a fault event, it uses the trigger time of the fault event and the corresponding operation address as search conditions to extract log records within a preset time window from the log storage, associates the log records with the fault event, and generates a fault tracing chain.

[0092] This embodiment transforms the core functions of the system embodiment into a method flow, enabling remote operation permission verification, working condition determination, command issuance, status monitoring, disconnection protection, and fault tracing to form a complete logical closed loop. This verifies the collaborative working mechanism of each hardware unit in the system when performing remote operations, thereby providing a complete operation flow for industrial host computer remote operation from command initiation to exception handling and tracing.

[0093] In a preferred embodiment of the present invention, the remote operation is specifically a remote calibration operation, which is executed by a remote communication interface, and the detailed steps are as follows: (1) After logging into the system operation interface and entering the equipment remote calibration function page, the user clicks the axial travel remote calibration start button to submit a calibration start request to the host computer. The host computer captures this operation event, initializes the calibration status, timer counter and communication monitoring flag, and prepares to enter the verification stage.

[0094] (2) The host computer first reads the currently logged-in account information and verifies the permissions of the current operator. Only authorized accounts have remote calibration operation permissions. After the permission verification is passed, the host computer determines the CAN bus connection status. If the device is offline, the calibration is terminated and the device is not connected to the network. After the communication link verification is passed, the host computer reads the operating data uploaded by the slave computer and verifies the device's operating condition. The device must simultaneously meet three conditions: levitation ready, low-speed motor stationary, and no hardware fault alarms before it can continue. If there is an operating load or fault error, the calibration start is directly rejected.

[0095] (3) After all the above verifications are passed, the host computer encapsulates a standard CAN communication frame, fills in the axial travel calibration start address code and start command value, and calls the bus sending interface to send the calibration start command to the lower computer controller. The host computer also records the sending log locally, and the interface updates the status to "calibration command has been sent, waiting for lower computer response".

[0096] (4) After receiving the CAN message, the lower computer parses and identifies the axial calibration command, switches the device to the dedicated calibration working mode, and sequentially performs automatic zero-finding positioning, forward limit position walking and reverse limit position walking actions, collects the limit coordinate data at both ends, automatically calculates the actual effective axial stroke, and stores the original calibration data.

[0097] (5) During the calibration process, the lower-level computer transmits three types of data back to the upper-level computer via the CAN bus at fixed intervals: calibration operation steps, real-time axial position, and temporary stroke parameters. The upper-level computer receives the messages by polling with a timer, parses the data, and refreshes the interface status text and position values ​​in real time for operators to view the calibration progress.

[0098] (6) The host computer monitors the CAN communication heartbeat signal throughout the entire calibration process and sets a data reception judgment period. If no feedback message is received from the slave computer within the judgment period, it is judged as a communication abnormality and disconnection. An emergency stop command is immediately issued to terminate all calibration actions, and a pop-up window on the interface indicates that the communication is disconnected and the abnormal event is recorded. At the same time, the host computer also executes multiple abnormal protection logics: a maximum calibration time is set. If the running time exceeds the threshold, it is judged that the slave computer is stuck and unresponsive, and the calibration is forcibly terminated and an alarm is triggered; the running position is monitored in real time. If the equipment exceeds the preset safe travel range, the motion output is immediately cut off, the limit protection is triggered, and the calibration operation is stopped; if a current, voltage, or mechanical fault code occurs during operation, the machine is stopped instantly and the calibration is abandoned, and the fault type is reported.

[0099] (7) After the lower-level computer completes the full-process stroke calculation, it generates the final axial stroke calibration result, encapsulates the status code and parameter message, and uploads it to the upper-level computer. After the upper-level computer recognizes the completion instruction, it stops status monitoring and timing statistics, and the interface prompts that the calibration is successful. The upper-level computer locally stores the calibration parameters, operation logs, and operation records, and compares them with the standard parameters to determine the calibration validity. After the operator verifies the calibration data, they manually confirm the archiving, the equipment exits the calibration mode, and restores the normal control state. This remote calibration operation is now complete.

[0100] This embodiment integrates the complete remote calibration process into the remote communication interface, realizing the entire process of remote execution from authorization verification, working condition determination, command issuance, status feedback to anomaly protection and result confirmation. This allows operators to complete axial travel calibration without being physically present on-site. Multiple anomaly protection logic monitors the communication status, runtime, and position over-limit in real time during the calibration process. Once an anomaly occurs, protection actions are triggered immediately, effectively improving the security and reliability of remote calibration.

[0101] It should be noted that: steps S301 to S305 in the embodiment of the method correspond to the core process of the host computer operation. In actual implementation, those skilled in the art can add other auxiliary operations before and after the core steps according to the specific application scenario (such as the disconnection detection in step S304 including but not limited to a second preset time period as a determination method, and the fault tracing in step S305 can also be combined with the fault code index for supplementary verification, etc.). These additional operations do not depart from the core protection scope of the present invention.

[0102] The above provides a detailed description of the industrial host computer remote operation fault tracing system and method provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. 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 the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. An industrial host computer remote operation fault tracing system, characterized in that, include: The remote communication interface is used to establish a communication connection with the lower-level machine, receive the running status data and communication link status data uploaded by the lower-level machine, and send remote commands to the lower-level machine to instruct the lower-level machine to perform remote operation actions. A log storage device, connected to the remote communication interface, is used to respond to the communication interaction behavior of the remote communication interface and generate and store log records based on the running status data; The log records are used to record the operation behavior of issuing the remote command, and include timestamp, operator identity, operation address, written value and execution result; The fault diagnosis and tracing processor is connected to the remote communication interface and the log storage. When a fault event is detected based on the communication link status data, it automatically extracts the log records within a preset time window from the log storage using the trigger time of the fault event and the corresponding operation address as search conditions, and associates and generates a fault tracing chain.

2. The industrial host computer remote operation fault tracing system according to claim 1, characterized in that, The operation address is the device address or register address of the lower-level machine, and the preset time window is a preset time period that traces back from the time the fault event was triggered.

3. The industrial host computer remote operation fault tracing system according to claim 1, characterized in that, The remote communication interface receives operating status data uploaded by the lower-level machine, including device status data, current data, position and speed data, and fault information data. The device status data is uploaded by the lower-level machine according to a first preset cycle; The current data is uploaded by the lower-level machine according to a second preset cycle; The position and velocity data are uploaded by the lower-level machine according to a third preset cycle; The fault information data is reported immediately by the lower-level machine when a fault event is triggered; The first preset period, the second preset period, and the third preset period are configured by the host computer.

4. The industrial host computer remote operation fault tracing system according to claim 1, characterized in that, The log storage uses an embedded database to store the log records and employs a time-based round-robin cleanup strategy and / or a capacity threshold cleanup strategy to automatically clean up the stored log records.

5. The industrial host computer remote operation fault tracing system according to claim 1, characterized in that, The system also includes: The permission management register, connected to the remote communication interface, is used to store and verify the permission level of the current operator; The permission levels include at least a first permission level and a second permission level, where the first permission level is higher than the second permission level; the remote communication interface is only allowed to issue the remote command when the current operator's permission is not lower than a preset permission threshold.

6. The industrial host computer remote operation fault tracing system according to claim 5, characterized in that, When performing remote operations, the remote communication interface is configured as follows: In response to the remote command triggered by the user, the permission management register is invoked to verify the current operator's permission level and to determine whether the communication link status data and the running status data uploaded by the lower-level machine meet the preset working conditions. When the permission verification is successful and the preset working conditions are met, the remote instruction is encapsulated into a communication frame and sent to the lower-level machine. Receive the calibration status and real-time position and speed data uploaded by the lower-level device, and refresh the display; Receive the calibration completion status code uploaded by the lower-level machine and store the calibration result.

7. The industrial host computer remote operation fault tracing system according to claim 1, characterized in that, The remote communication interface communicates with the lower-level machine via a CAN bus, and the communication frame is an 8-byte fixed-length data frame; the communication frame includes an uplink request frame sent by the upper-level machine to the lower-level machine, and a downlink response frame uploaded by the lower-level machine to the upper-level machine; The uplink request frame contains, in sequence: 1 byte instruction code, 1 byte reserved bit, 2 bytes parameter address, 2 bytes write data, 1 byte reserved bit and 1 byte checksum; The downlink response frame contains, in sequence: 1 byte of response code, 1 byte of execution result, 2 bytes of parameter address, 2 bytes of read data, 1 byte of device status, and 1 byte of checksum. After receiving the uplink request frame, the lower-level machine parses its message identifier and responds to the uplink request frame; after receiving the downlink response frame, the remote communication interface parses its message identifier and processes the downlink response frame.

8. The industrial host computer remote operation fault tracing system according to claim 7, characterized in that, The system further includes: a disconnection protection controller, connected to the remote communication interface; the disconnection protection controller includes: The first-level early warning unit is used to trigger a communication link early warning when no response data is received from the lower-level machine for more than a first preset time. The second-level disconnection protection unit is used to determine that the communication link has timed out and disconnected when no response data is received from the lower-level machine for more than a second preset time; the second preset time is longer than the first preset time. The third-level hardware disconnection protection unit is used to determine the physical layer hardware disconnection when no differential signal is detected between the high-level line CAN_H and the low-level line CAN_L of the CAN bus, lock the device status and prohibit remote operation.

9. The industrial host computer remote operation fault tracing system according to claim 1, characterized in that, The system also includes: A parameter parser, connected to the remote communication interface, is used to receive raw data frames uploaded by the lower-level machine, automatically identify parameter types based on address ranges and / or numerical value ranges, and match the corresponding parsing strategy to parse the raw data frames to form the running status data. When the address range contains a year address and a number address, and the data conforms to the combination format of the year field and the number field, the parameter parser determines that the data in the original data frame is the device number, and parses the data in the original data frame into a device number string; When the address segment is a preset time register address segment, and the values ​​of each field in the original data frame fall within the preset legal time range corresponding to seconds, minutes, hours, days, months, and years, the parameter parser determines that the data in the original data frame is real-time clock data and parses the data in the original data frame into standard time data. When the physical range of the value in the original data frame falls within the preset range of current parameters, position parameters, or PID parameters, the parameter parser determines that the data is the corresponding current parameter, position parameter, or PID parameter, and parses the value in the original data frame into the engineering value of the corresponding physical quantity.

10. A method for tracing faults in remote operation of an industrial host computer, characterized in that, The system is executed using the industrial host computer remote operation fault tracing system according to any one of claims 1 to 9, including: The permission management register responds to remote commands triggered by the user and verifies the permission level of the current operator; the remote communication interface determines whether the communication link status data between the operator and the lower-level machine and the running status data uploaded by the lower-level machine meet the preset operating conditions. When the permission verification is successful and the preset working conditions are met, the remote communication interface encapsulates the remote instruction into a communication frame and sends it to the lower-level machine to instruct the lower-level machine to perform a remote operation; the log storage generates and stores log records. During the remote operation performed by the lower-level machine, the remote communication interface receives the calibration status and real-time position and speed data periodically uploaded by the lower-level machine, and refreshes the display. During the entire process of performing remote operation, the disconnection protection controller continuously monitors the status data of the communication link. When no response data is received from the lower-level machine for more than a second preset time, it determines that the communication link has timed out and disconnects. It automatically generates an emergency stop command and sends it to the lower-level machine to terminate the remote operation. When a fault diagnosis and tracing processor detects a fault event, it uses the trigger time of the fault event and the corresponding operation address as search conditions to extract log records within a preset time window from the log storage, associates the log records with the fault event, and generates a fault tracing chain.

Images