General upper computer communication method and system

Abstract

The invention relates to upper computer communication, and provides a universal upper computer communication method, which comprises the following steps of: acquiring current user permission data to allow loading of a communication configuration file and a protocol definition file; initializing a communication engine according to the communication configuration file, establishing connection with lower computer equipment, and limiting the application permission of a functional module according to the current user permission data in the initialization process; the communication engine performs frame matching, data extraction and engineering value conversion work on the lower computer equipment according to the protocol definition file so as to generate and upload response data to the upper computer equipment; and allowing the user to access and / or modify the response data according to the current user permission. Therefore, by acquiring the current user permission data, initializing the communication engine, performing frame matching and data conversion and allowing access to the modified response data, the method has the advantages of improving system universality, enhancing operation safety and simplifying configuration maintenance.

Description

Technical Field

[0001] This invention relates to the field of host computer communication technology, and in particular to a general host computer communication method and system. Background Technology

[0002] In the current field of industrial control and data acquisition, host computer software typically needs to communicate with various slave devices via serial ports or networks. However, most existing technical solutions are custom-developed for specific devices or communication protocols, resulting in a single software program being compatible with only a single protocol or device type. This often lacks fine-grained operation permission control mechanisms and exhibits poor versatility. Furthermore, its communication parameters and data parsing rules are often deeply coupled to the main program body through hard-coded syntax, preventing users from flexibly adapting to different devices without modifying the source code. This leads to rigid configurations, high maintenance costs, and difficulty in dynamically restricting system function access based on different user roles. Summary of the Invention

[0003] The purpose of this invention is to provide a universal host computer communication method to solve the problems mentioned in the background art.

[0004] The technical solution of the present invention to solve the above-mentioned technical problems is as follows:

[0005] The purpose of this application is to provide a general host computer communication method and system, which has the advantages of improving system versatility, enhancing operational security, and simplifying configuration and maintenance.

[0006] This application provides a general host computer communication method, the technical solution of which is as follows:

[0007] A general host computer communication method includes:

[0008] Obtain current user permission data to allow loading of communication configuration files and protocol definition files;

[0009] The communication engine is initialized according to the communication configuration file, a connection is established with the lower-level device, and the application permissions of the functional modules are restricted according to the current user permission data during the initialization process.

[0010] The communication engine performs frame matching, data extraction, and engineering value conversion on the lower-level device according to the protocol definition file to generate and upload response data to the upper-level device.

[0011] Based on the current user permissions, allow the user to access and / or modify the response data.

[0012] Furthermore, this application also proposes a general host computer communication method, the steps of which include obtaining user permission data to allow loading of communication configuration files and protocol definition files, and the following:

[0013] When a user requests access to stored data, multi-level authentication is performed.

[0014] After successful authentication, the corresponding level of permission configuration file is loaded based on the user's identity to determine the current user's permission data.

[0015] Furthermore, this application also proposes a general host computer communication method that restricts the application permissions of functional modules based on current user permission data, specifically including:

[0016] Parse the permission configuration file to obtain the current user role and its corresponding permission bitmap. The permission bitmap includes operation permissions for configuration modification, device control, data export, and viewing historical logs.

[0017] In the graphical user interface of the host computer device, the interface controls are dynamically rendered according to the permission bitmap, and operation buttons or menu items without permission are disabled or hidden.

[0018] Furthermore, this application also proposes a general host computer communication method. The communication engine performs frame matching, data extraction, and engineering value conversion on the lower-level device according to the protocol definition file to generate and upload response data to the host computer device. The steps include:

[0019] Based on the frame structure rules defined in the protocol definition file, identify and extract complete data frames from the received raw byte stream;

[0020] Based on the data point table pre-configured in the protocol definition file, the original byte values ​​of each data item are extracted from the data frame according to the address offset and length specified in the data point table;

[0021] Based on the transformation parameters defined for each data item in the data point table, the raw byte values ​​are converted into engineered values ​​to form response data.

[0022] Furthermore, this application also proposes a general host computer communication method, which includes the step of extracting the original byte values ​​of each data item from the data frame according to the address offset and length specified in the data point table, based on a pre-configured data point table in the protocol definition file.

[0023] Retrieve the security policy identifier from the communication configuration file;

[0024] If the security policy requires encrypted communication, the system receives the raw byte stream from the lower-level device for decryption and / or integrity verification. After successful verification, frame matching and data extraction are performed.

[0025] Furthermore, this application also proposes a general host computer communication method, wherein the steps of allowing a user to access and / or modify response data according to the current user permissions include:

[0026] In the graphical user interface, the state of the data display and editing controls is controlled based on the current user permission data.

[0027] When the current user's permission data includes data access permission, the editing controls in the interface will be disabled, and all modification operation requests will be intercepted in the background logic and recorded as unauthorized events.

[0028] And / or when the current user permission data includes data modification permission, allow the user to perform online correction, parameter setting, or command issuance operations on the response data in the interface;

[0029] All successfully executed user operations are associated with the current user's identity and recorded in the audit log.

[0030] Furthermore, this application also proposes a general host computer communication method, which further includes:

[0031] Monitor the process of frame matching, data extraction, and engineering value conversion to capture anomalies and business alarm information;

[0032] The captured anomalies and alarms are tagged according to the format of timestamps, relevant data frames, and context information, and then stored in an error knowledge lookup table.

[0033] Furthermore, this application also proposes a general host computer communication method, which includes, after the step of marking the captured anomalies and alarm information according to the format of timestamps, relevant data frames, and context information, and classifying and storing them in an error database, further comprising:

[0034] Once a new anomaly or alarm is stored in the error knowledge query table, a matching query is performed in the error knowledge base based on the error type or characteristics. The error knowledge query table contains data records of several diagnostic rules or historical cases, and each data record is associated with at least one error type and its corresponding handling suggestion.

[0035] If a match is found, the corresponding processing suggestions will be proactively pushed to the graphical user interface.

[0036] Furthermore, this application also proposes a general host computer communication method, wherein the protocol definition file is an editable spreadsheet file, in which a data point table is defined in tabular form, and the columns of the data point table include: data point name, address, data type, data length, conversion factor, offset, engineering unit and upper and lower limits of data.

[0037] Furthermore, this application also proposes a universal host computer communication control system, which includes: a memory, a processor, and a universal host computer communication program stored in the memory and executable on the processor. The universal host computer communication program is configured to implement the steps of the universal host computer communication method described above.

[0038] As can be seen from the above, the general host computer communication method and system provided in this application solves the problems of insufficient universality, defective permission management and rigid configuration in the prior art by obtaining the current user permission data, initializing the communication engine, performing frame matching and data conversion and allowing access to modify response data. It has the advantages of improving system universality, enhancing operational security and simplifying configuration and maintenance. Attached Figure Description

[0039] Figure 1 This is a flowchart illustrating one embodiment of a general host computer communication method according to this application;

[0040] Figure 2 This is a schematic diagram of a sub-process of step S100 in one embodiment of a general host computer communication method of this application;

[0041] Figure 3 This is a schematic diagram of a sub-process of step S200 in one embodiment of a general host computer communication method of this application;

[0042] Figure 4 This is a schematic diagram of a sub-process of step S300 in one embodiment of a general host computer communication method of this application;

[0043] Figure 5 This is a schematic diagram of a sub-process of step S320 in one embodiment of a general host computer communication method of this application;

[0044] Figure 6 This is a schematic diagram of a sub-process of step S400 in one embodiment of a general host computer communication method of this application;

[0045] Figure 7 This is a flowchart illustrating another embodiment of a general host computer communication method according to this application;

[0046] Figure 8 This is a schematic diagram of the structure of a general host computer communication system according to this application. Detailed Implementation

[0047] It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of this invention can be combined with each other. The technical solutions of this invention will be further described below with reference to the accompanying drawings of the embodiments of this invention. This invention is not limited to the specific embodiments described below.

[0048] It should be understood that the same or similar reference numerals in the accompanying drawings of the embodiments correspond to the same or similar components. In the description of this invention, it should be understood that if terms such as "upper," "lower," "front," "rear," "left," "right," "top," and "bottom" indicate orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, they are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or component referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms describing positional relationships in the accompanying drawings are for illustrative purposes only and should not be construed as limiting this patent. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0049] In the current field of industrial control and data acquisition, host computer software typically needs to communicate with various slave devices via serial ports or networks. However, most existing technical solutions are custom-developed for specific devices or communication protocols, resulting in a single software program being compatible with only a single protocol or device type. This often lacks fine-grained operation permission control mechanisms and exhibits poor versatility. Communication parameters and data parsing rules are frequently hard-coded and deeply coupled with the main program, preventing users from flexibly adapting to different devices without modifying the source code. This leads to rigid configurations, high maintenance costs, and difficulty in dynamically restricting system function access based on different user roles. Furthermore, error handling is usually limited to simple prompts, lacking structured recording, classification analysis, and intelligent diagnostic support for error information. This results in inefficient problem localization and insufficient system maintainability.

[0050] refer to Figures 1 to 7 In response, this application proposes a general host computer communication method, which includes:

[0051] Step S100: Obtain current user permission data to allow loading of communication configuration files and protocol definition files;

[0052] Step S200: Initialize the communication engine according to the communication configuration file, establish a connection with the lower-level device, and restrict the application permissions of the functional modules according to the current user permission data during the initialization process;

[0053] In step S300, the communication engine performs frame matching, data extraction, and engineering value conversion on the lower-level device according to the protocol definition file to generate and upload response data to the upper-level device.

[0054] Step S400: Based on the current user permissions, allow the user to access and / or modify the response data.

[0055] For ease of understanding, the following explains some key terms in this embodiment:

[0056] A communication configuration file, which can be an external file containing parameters such as communication port settings, baud rate, data bits, stop bits, parity bits, IP address, and port number, is used to guide the communication engine in establishing a physical or logical connection with the lower-level device. This file is typically stored in text, XML, or JSON format, allowing users to adjust communication parameters without modifying the program code.

[0057] A protocol definition file is an external file that describes the data structure and parsing rules of a specific communication protocol. For example, it defines the start and end markers of a data frame, the data length, the checksum method, and the position, data type, and conversion rules of each data point within the frame. This file enables the communication engine to parse and convert the received raw data according to preset rules.

[0058] The communication engine, which can be a software module or component, is responsible for managing the communication process with the lower-level device, including core functions such as connection establishment and maintenance, data transmission and reception, protocol parsing, and data conversion. This engine acts as a data bridge between the host computer and the lower-level device, enabling bidirectional data flow and processing.

[0059] Lower-level devices typically refer to hardware devices such as controllers, sensors, and actuators in industrial settings, including programmable logic controllers (PLCs), distributed control systems (DCS) modules, and smart meters. They interact with upper-level devices through specific communication protocols.

[0060] The host computer device, which usually refers to a computer system that runs monitoring, management and control software, such as an industrial PC, server or workstation, interacts with the slave device through a communication engine to realize the monitoring of industrial processes, data acquisition, parameter setting and command issuance.

[0061] Frame matching refers to the process by which a communication engine identifies and extracts a complete and valid data frame from a continuous stream of raw bytes, based on the frame structure rules preset in the protocol definition file. This typically involves the detection of identifiers such as frame headers, frame trailers, and frame lengths.

[0062] Data extraction refers to the process by which, after frame matching is completed, the communication engine accurately retrieves the raw byte values ​​of each data item from the identified data frame according to the data point table specified in the protocol definition file. This typically requires operations based on address offsets and data lengths.

[0063] Engineering value conversion refers to converting the raw byte values ​​extracted from the data frame into numerical values ​​with actual physical meaning and engineering units, according to the conversion parameters (such as scaling factor, offset, data type, etc.) set for each data item in the protocol definition file.

[0064] Response data refers to the data set generated and prepared for uploading to the host computer device by the communication engine after completing frame matching, data extraction, and engineering value conversion. This data set includes the real-time status, measurement values, alarm information, etc. of the lower-level device, presented in the form of engineering values.

[0065] User permission data refers to the set of data that identifies the operations and functionalities a user is authorized to perform within the system. This data is typically determined by a permission configuration file loaded after user authentication and is used to restrict application permissions for functional modules, as well as data access and modification permissions.

[0066] Specifically, the general host computer communication method of this application can be implemented in the following manner:

[0067] When obtaining current user permission data to allow loading communication configuration files (such as INI files) and protocol definition files (such as Excel files), the system can preset a low-level default user permission at startup, or use a simple login interface where the user enters a fixed username and password, and the system loads a predefined permission level accordingly. For example, the system could simply check if the user has provided any credentials; if so, grant them basic "guest" permissions, allowing loading of preset communication configuration files and protocol definition files, but these permissions may not be modifiable. Alternatively, the user can manually select a permission configuration file before system startup, or the system can load a default permission configuration file from a fixed path. This configuration file directly contains information about which communication configuration files and protocol definition files are allowed to be loaded. For example, a file named "config_loader.ini" might list the following entries:

[0068] "allow_load_comm_config=true" and "allow_load_protocol_def=true"

[0069] When initializing the communication engine based on the communication configuration file, establishing a connection with the lower-level device, and restricting the application permissions of functional modules according to the current user permission data during initialization, the communication engine can read a static communication configuration file, such as a text file, at startup. This file contains basic parameters such as the serial port number and baud rate. Based on these parameters, the communication engine attempts to establish a connection with the lower-level device. Regarding restricting the application permissions of functional modules, after the communication engine initialization is complete, a global variable or flag can be used to indicate the current user's permission level, such as "read-only" or "full control." When other functional modules attempt to perform operations, they will simply check this global variable; if it is "read-only," all modification or control-related operation buttons will be disabled. Alternatively, the initialization parameters of the communication engine can be partially hard-coded in the program, such as the default IP address and port. When the user permission data indicates low permissions, the program logic will directly disable certain functional modules. For example, if the user permission is "operator," modules related to device firmware upgrades or advanced diagnostics will be set to unavailable during program compilation, or these modules will be skipped at runtime through simple conditional checks.

[0070] When the communication engine performs frame matching, data extraction, and engineering value conversion on the lower-level device according to the protocol definition file to generate and upload response data to the upper-level device, the communication engine can have one or more fixed communication protocol parsing logic built-in. Upon receiving the raw byte stream from the lower-level device, the engine performs frame matching according to a preset fixed protocol format, then extracts data based on hard-coded data point definitions, and performs simple linear engineering value conversion. Finally, it packages these converted data into a simple structure and uploads it as response data. Alternatively, the protocol definition file can be a simple template file that defines a general structure for data frames, such as all frames starting with STX and ending with ETX. The communication engine performs frame matching based on this template. Data extraction and engineering value conversion are accomplished through preset fixed positions and conversion formulas in the template. For example, if the template specifies that temperature data is in the Xth to Yth bytes of the frame, the conversion formula is (original value × A + B).

[0071] When allowing a user to access and / or modify the response data based on the current user permissions, the graphical user interface of the host computer can easily control the state of the data display and editing controls according to the current user permission data. For example, if the user permission is "Guest," only the response data is displayed, but all input boxes or buttons related to data modification (such as parameter settings and command issuance) are set to a grayed-out, unavailable state. Any attempt to modify the data will be directly rejected by the program, and a "Permission Insufficient" prompt box may pop up. As another implementation method, the system can provide completely different interface views for users with different permissions. For example, for users with "Viewer" permissions, the system loads an interface containing only data display components; for users with "Administrator" permissions, the system loads an interface containing both data display and data editing components. This method physically isolates access and modification functions by loading different interface layouts.

[0072] The general host computer communication method proposed in this application decouples the communication protocol from the program logic by driving the communication engine through an external configuration file, significantly improving the system's adaptability to different lower-level devices and communication protocols. Simultaneously, the integrated user permission management mechanism dynamically restricts the application permissions of functional modules and the access and modification of response data based on user roles, effectively enhancing the system's security and controllability. Therefore, this method reduces the complexity of system configuration and maintenance, and improves the overall operation and maintenance efficiency of industrial control and data acquisition systems.

[0073] In the aforementioned general host computer communication method, it is necessary to obtain the current user's permission data to allow loading of communication configuration files and protocol definition files. However, if the process of obtaining permission data lacks sufficient security guarantees, unauthorized users may access or modify critical communication configurations and protocol definitions, thereby introducing system security risks or causing communication failures.

[0074] In this regard, this application further proposes step S100, the step of obtaining user permission data to allow loading of communication configuration files and protocol definition files, including:

[0075] Step S110: When a user requests access to stored data, multi-level authentication is performed;

[0076] Step S120: After successful authentication, load the corresponding level of permission configuration file based on the user's identity identifier to determine the current user's permission data.

[0077] Step S110 aims to ensure that only rigorously authenticated users can further operate functions involving communication configuration files and protocol definition files. Multi-level authentication can employ various combinations of methods. For example, the first level of authentication can be traditional username and password verification, where the user enters preset credentials for identity confirmation; the second level of authentication can introduce biometric technologies, such as fingerprint or facial recognition, or use hardware tokens, dynamic verification codes, etc., to provide a higher level of security. When a user attempts to perform operations such as opening, editing, or saving communication configuration files or protocol definition files, or attempts to establish a connection with a lower-level device, the system triggers this authentication process to prevent unauthorized access.

[0078] After successful authentication, the system loads the corresponding level of permission configuration file based on the user's identity to determine the current user's permission data. After a user successfully passes multi-level authentication, the system obtains the user's unique identity identifier, such as a user ID or their assigned role group information. Based on this identifier, the system loads the permission configuration file corresponding to the user's identity or role from a preset storage location (such as a database, local file system, or network server). This permission configuration file defines in detail the scope of operations and access levels that the user is allowed to perform within the system. By parsing this configuration file, the system can accurately determine the current user's permission data, such as which functional modules can be accessed and which data can be modified, thus providing a basis for subsequent functional restrictions.

[0079] By introducing a multi-level authentication mechanism, this application effectively enhances the security of the host computer communication method, ensuring that only strictly verified legitimate users can access and operate sensitive communication configuration files and protocol definition files, thereby avoiding unauthorized access and potential configuration tampering risks. Furthermore, after successful authentication, the system can load the corresponding level of permission configuration file based on the user's identity, achieving fine-grained permission management. This allows different user roles to obtain the minimum set of permissions matching their responsibilities, effectively preventing permission abuse and unauthorized operations, and reducing the possibility of system failures due to misoperation or malicious behavior. This scheme provides a reliable and secure source of permission data for subsequently restricting the application permissions of functional modules, significantly enhancing the stability and controllability of the entire general host computer communication method.

[0080] In some embodiments described above, this application proposes determining current user permissions by acquiring user permission data and performing multi-level authentication, thereby allowing the loading of communication configuration files and protocol definition files. However, in practical applications, merely determining the user's permission level is insufficient to effectively prevent users from attempting to access or execute functional modules they are not authorized to operate on the host computer's interface. This limitation may lead to user errors, potentially causing security risks and affecting system stability and data integrity.

[0081] In response, this application further proposes step S200, which restricts the application permissions of functional modules according to the current user permission data during the initialization of the communication engine and the establishment of a connection with the lower-level device. Specifically, this includes:

[0082] Step S210: Parse the permission configuration file to obtain the current user role and its corresponding permission bitmap. The permission bitmap includes operation permissions for configuration modification, device control, data export, and viewing historical logs.

[0083] Step S220: In the graphical user interface of the host computer device, the interface controls are dynamically rendered according to the permission bitmap, and operation buttons or menu items without permission are disabled or hidden.

[0084] Specifically, after a user successfully logs into the system through multi-level authentication, the system loads the corresponding permission configuration file based on their identity. This permission configuration file is parsed to identify the current user's role and the specific operation permissions they possess. These permissions are typically represented in the form of a permission bitmap, where each bit or bit group corresponds to a specific operation permission, such as configuration modification, device control, data export, or viewing historical logs. Through this bitmap representation, the system can efficiently determine the user's access permissions for various functions.

[0085] Based on this, the graphical user interface (GUI) of the host computer device will dynamically adjust according to the obtained permission bitmap. This means that various interactive controls on the interface, such as buttons, menu items, and input boxes, will be rendered in real time according to the user's permissions. If the permission bitmap indicates that the user does not have permission for a certain operation, such as not having "device control" permission, then the operation buttons or menu items related to device control will be disabled (i.e., displayed as grayed out and unclickable) or hidden directly, making them invisible on the interface.

[0086] Through the above technical solution, the system extends user permission management from the backend logic level to the frontend user interface level. This mechanism of dynamically rendering interface controls effectively prevents users from seeing or attempting to execute functions they are not authorized to perform, thus eliminating misoperations or illegal operations caused by insufficient permissions at the source. This not only significantly improves the system's security, stability, and usability, ensuring that only authorized users can perform specific tasks, but also optimizes the user experience, making the user interface more concise and clear, displaying only functions related to the current user's permissions, thereby improving operational efficiency and the overall reliability of the system.

[0087] In the aforementioned general host computer communication method, the communication engine needs to perform frame matching, data extraction, and engineering value conversion on the lower-level device according to the protocol definition file to generate and upload response data. However, in practical applications, the data format of the lower-level device may be complex and diverse. Without a clear and efficient data processing mechanism, the communication engine may face problems such as inaccurate data frame identification, difficulty in data item extraction, and inconsistencies in the conversion from raw values ​​to engineering values ​​when processing the raw byte stream, thereby affecting the accuracy and reliability of the response data.

[0088] In response, this application further proposes step S300, in which the communication engine performs frame matching, data extraction, and engineering value conversion on the lower-level device according to the protocol definition file, in order to generate and upload response data to the upper-level device. The steps include:

[0089] Step S310: Identify and extract complete data frames from the received raw byte stream according to the frame structure rules defined in the protocol definition file;

[0090] Step S320: Based on the data point table pre-configured in the protocol definition file, extract the original byte values ​​of each data item from the data frame according to the address offset and length specified in the data point table;

[0091] Step S330: Based on the conversion parameters defined for each data item in the data point table, the original byte values ​​are converted into engineered values ​​to form response data according to the engineered values.

[0092] Specifically, this step, when identifying and extracting complete data frames from the received raw byte stream, aims to ensure the accurate separation of independent, complete data packets from the continuous raw byte stream. In industrial communication, data is typically transmitted in frames, each containing specific start symbols, length information, data content, checksums, and end symbols. The communication engine locates the boundaries of data frames by parsing the predefined frame structure rules in the protocol definition file, such as frame headers, frame trailers, length fields, or specific synchronization sequences. Once the start and end of a frame are identified, all bytes of that frame can be accurately extracted, laying the foundation for subsequent data parsing. For example, for the Modbus protocol, the integrity of a frame can be determined based on the function code and data length field; for custom protocols, it may rely on specific frame headers and checksums.

[0093] After successfully capturing a complete data frame, this step involves extracting the raw byte values ​​of each data item from the data frame according to the pre-configured data point table in the protocol definition file, based on the address offsets and lengths specified in the data point table. The data point table in the protocol definition file records in detail the position (address offset) and the number of bytes (length) occupied by each data item within the data frame. Based on this pre-configured information, the communication engine precisely reads the byte sequence at the corresponding position from the captured data frame to obtain the raw byte value of each data item. For example, if the data point table indicates that a temperature value starts from the 5th byte of the frame and has a length of 2 bytes, the communication engine will extract these 2 bytes as the raw temperature value. This process ensures accurate acquisition of the required data even with complex data frame structures.

[0094] When converting raw byte values ​​into engineered values ​​based on the conversion parameters defined for each data item in the data point table to form response data, the raw byte values ​​are typically represented in binary or hexadecimal and do not directly correspond to actual physical quantities. The purpose of this step is to convert these raw values ​​into engineered values ​​that are understandable and usable by the user. The data point table defines specific conversion parameters for each data item, such as the slope and offset of linear conversions, mapping relationships for enumerated values, or parsing rules for bit fields. The communication engine uses these parameters to perform mathematical operations or logical mappings on the extracted raw byte values ​​to obtain engineered values ​​with actual physical meaning (such as temperature in degrees Celsius, pressure in MPa, etc.). Finally, these converted engineered values ​​are organized to form the response data required by the host computer for display, analysis, or control.

[0095] Through the above technical solution, the communication engine can efficiently and accurately identify and extract complete data frames from the received raw byte stream according to the frame structure rules explicitly defined in the protocol definition file, effectively solving the problem of unclear data frame boundaries in the raw data stream. Furthermore, by accurately extracting the raw byte values ​​of each data item according to a pre-configured data point table and specified address offsets and lengths, the accuracy of data acquisition from complex data frames is ensured, avoiding data misalignment or omission. Finally, using the conversion parameters defined for each data item in the data point table, the raw byte values ​​are converted into engineering values ​​with actual physical meaning, enabling the host computer device to directly understand and utilize this data. This significantly improves the accuracy, reliability, and automation of the general host computer communication method when processing data from the slave device, providing a high-quality data foundation for subsequent user access and modification of response data.

[0096] In some embodiments described above, a communication engine performs frame matching, data extraction, and engineering value conversion on the lower-level device according to a protocol definition file to generate and upload response data to the upper-level device. However, in actual industrial control or data acquisition scenarios, communication between the lower-level and upper-level devices may face the risk of data leakage or tampering. Directly performing frame matching and data extraction on the raw byte stream without security processing may lead to inaccurate data or system security vulnerabilities, thereby affecting the reliability and security of the entire system.

[0097] In response, this application further proposes that step S320, which involves extracting the original byte values ​​of each data item from the data frame according to the data point table pre-configured in the protocol definition file and the address offset and length specified in the data point table, also includes...

[0098] Step S321: Obtain the security policy identifier in the communication configuration file;

[0099] Step S322: If the security policy identifier requires communication encryption, receive the raw byte stream from the lower-level device for decryption and / or integrity verification. After successful verification, perform frame matching and data extraction.

[0100] Specifically, after the communication engine initializes or establishes a connection, the system first retrieves the security policy identifier from the communication configuration file. This security policy identifier is a key parameter used to indicate whether the current communication link requires encryption or data integrity verification. For example, this identifier can be a boolean flag, such as "require_encryption," where a true value indicates encryption is required and a false value indicates it is not; or it can be an enumeration type, such as "security_level," whose values ​​can include "no security," "encryption only," "integrity verification only," or "encryption and integrity verification." When loading the communication configuration file, the communication engine parses and reads this identifier as the basis for subsequent data processing.

[0101] When the communication engine determines that communication encryption is required based on the acquired security policy identifier, it does not immediately perform frame matching upon receiving the raw byte stream from the lower-level device. Instead, it first performs a decryption operation on the raw byte stream. The decryption process typically involves using a preset encryption algorithm (such as AES, DES, etc.) and a key to restore the ciphertext data to plaintext data. Simultaneously, or independently, if the security policy identifier requires integrity verification, the communication engine performs integrity verification on the received raw byte stream. This can be achieved by calculating the data checksum, cyclic redundancy check (CRC), or message authentication code (MAC). The lower-level device appends corresponding verification information when sending data, and the upper-level device recalculates and compares it with the received verification information. If the calculated result is inconsistent with the received verification information, it indicates that the data may have been tampered with or corrupted during transmission. Only when the above decryption and / or integrity verification process is successful—that is, the data is correctly decrypted and the integrity verification is error-free—will the communication engine pass the processed data stream to the subsequent frame matching module. This means that any raw byte stream that fails security verification will be rejected or marked as abnormal and will not proceed to the data parsing stage. For example, if decryption fails or integrity verification fails, the system can trigger an alarm, log an error, and choose to discard the data frame or request the lower-level device to retransmit, thereby effectively preventing insecure or erroneous data from entering subsequent processing.

[0102] The above technical solution introduces the acquisition of security policy identifiers within the communication configuration file before data extraction from the lower-level device. This allows the communication engine to dynamically process the received raw byte stream according to preset security requirements. When the security policy identifier requires communication encryption, the raw byte stream is decrypted, ensuring the confidentiality of data transmission and effectively preventing the leakage of sensitive information during transmission. Simultaneously, integrity verification effectively detects whether data has been tampered with or corrupted during transmission, ensuring data integrity and reliability. Only after decryption and / or integrity verification are passed is subsequent frame matching and data extraction performed, thus preventing insecure or erroneous data from entering the system at the source. This significantly improves the security and accuracy of the entire general-purpose upper-level computer communication method, avoids system failures or misoperations caused by data security issues, and ensures that the response data received by the upper-level device is reliable.

[0103] In general host computer communication methods, although access to or modification of response data can be allowed based on user permissions, the lack of a fine-grained permission control mechanism may result in the user interface not being able to intuitively reflect the user's operating permissions, posing a risk of unauthorized operations, and making it difficult to effectively trace and audit user behavior, thereby affecting the security and stability of the system.

[0104] In this regard, this application further proposes step S400, which, based on the current user permissions, allows the user to access and / or modify the response data, including:

[0105] Step S410: In the graphical user interface, based on the current user permission data, control the state of the data display control and the editing control;

[0106] Step S420: When the current user permission data includes data access permission, the editing controls in the interface will be disabled, and all modification operation requests will be intercepted in the background logic and recorded as unauthorized events.

[0107] Step S430, and / or when the current user permission data includes data modification permission, allow the user to perform online correction, parameter setting, or command issuance operations on the response data in the interface;

[0108] Step S440: All successfully executed user operations are associated with the current user's identity and recorded in the audit log.

[0109] Specifically, in the graphical user interface (GUI), the state of data display controls and editing controls is controlled based on the current user permission data. This aims to ensure that the GUI can intuitively and dynamically reflect the current user's operational permissions, preventing users from attempting unauthorized operations and improving user experience and system security. The host computer application obtains the current user permission data upon startup or user login. When building or refreshing the GUI, the state of data display controls (such as text boxes, tables, charts, etc.) and editing controls (such as input boxes, buttons, drop-down menus, sliders, etc.) on the interface is adjusted according to this permission data. For example, if the user only has viewing permissions, the editing control may be set to read-only, disabled, or hidden; if the user has modification permissions, the editing control may be activated. This control can be completed all at once when the interface loads, or it can be dynamically updated when user permissions change.

[0110] When the current user permission data includes data access permission, the editing controls in the interface will be disabled, and all modification requests will be intercepted and recorded as unauthorized events in the background logic. This is to strictly enforce data access permissions, prevent users from modifying data with only viewing permissions, and record any unauthorized attempts to enhance the system's security auditing capabilities. When the system recognizes that the current user permission data only includes data access permission (i.e., no data modification permission), all editing controls on the graphical user interface (such as text boxes for entering new values, adjusting parameters, buttons, etc.) will be disabled, making them unusable by the user. Furthermore, even if the interface layer fails to completely disable editing controls for some reason, or if the user attempts to initiate a data modification request through other means, the background logic layer will still perform permission verification on all received modification requests. Once a request is found to be inconsistent with the current user's permissions (i.e., the user does not have modification permissions), the request will be immediately intercepted, and no actual data modification operation will be performed. Simultaneously, this attempt will be recorded as an unauthorized event, including detailed information such as user identity, attempted operation, and timestamp, for subsequent auditing and analysis.

[0111] And / or when the current user permission data includes data modification permission, the user is allowed to perform online correction, parameter setting, or command issuance operations on the response data in the interface. This aims to empower users with corresponding permissions to intervene and control the data of the lower-level device in real time, meeting the actual needs in production, debugging, or maintenance processes. When the current user permission data explicitly includes data modification permission, the editing controls in the upper-level computer's graphical user interface will be activated. Users can directly operate on the response data obtained from the lower-level device through these controls. For example, users can directly modify the data values ​​displayed on the interface, such as correcting the reading deviation of a sensor; users can adjust the operating parameters of the lower-level device, such as setting the target temperature of the temperature controller, adjusting the PID parameters of the motor speed, etc.; users can trigger specific control commands through the interface, such as starting / stopping the device, switching operating modes, executing calibration programs, etc. These operation requests are sent to the lower-level device through the communication engine to achieve real-time control of the device.

[0112] All successfully executed user operations are associated with the current user's identity and recorded in the audit log. This aims to establish a complete audit chain for user operations, ensuring that all modifications to system data or device status are traceable, meet compliance requirements, and provide a basis for troubleshooting and liability determination. Whether a user performs online corrections, parameter settings, or command issuance, as long as these operations are successfully processed and executed in the background logic, the system automatically captures detailed information about these operations. This information includes, but is not limited to, the operation type, data values ​​before and after the operation, the operation time, the affected data points or devices, and the current user's identity. These detailed records are stored in a dedicated audit log file, which typically has tamper-proof mechanisms to ensure the authenticity and completeness of the records. Through the audit log, administrators can trace the source and impact of any operation at any time.

[0113] Through the above technical solution, this application can significantly improve the security, controllability, and traceability of the general host computer communication method. In the general host computer communication method, by introducing fine-grained permission control for accessing and modifying response data, the system can dynamically adjust the interactive capabilities of the graphical user interface according to the user's specific permissions. When the user only has data access permission, the editing controls on the interface are disabled, visually informing the user of their operational scope. Simultaneously, the background logic layer acts as a security barrier, intercepting and recording any unauthorized modification attempts to ensure data integrity and system security. Conversely, when the user has data modification permission, the system activates the corresponding editing controls, allowing the user to perform critical operations such as online data correction, parameter setting, or command issuance, thereby achieving effective control and management of the lower-level devices. Furthermore, all successfully executed operations are associated with the user's identity and recorded in detail in the audit log, constructing a complete operation traceability chain. The user interface intuitively reflects the current user's operational permissions, effectively avoiding misoperations or unauthorized operations caused by unclear permissions. The strict verification and unauthorized event recording mechanism of the background logic further strengthens the system's security defenses, ensuring the integrity of data and device status. Meanwhile, the granular operation permissions granted to authorized users ensure that the system maintains high flexibility and usability while meeting security requirements, supporting critical online correction and device control functions. The introduction of audit logs provides the system with powerful post-event traceability capabilities, greatly facilitating fault diagnosis, responsibility identification, and compliance review, thereby comprehensively improving the management level and reliability of the entire host computer communication system.

[0114] In the implementation of the aforementioned general host computer communication method, the communication engine needs to perform complex data processing tasks on the slave device, such as frame matching, data extraction, and engineering value conversion. However, various abnormal situations or business alarms may occur during these data processing stages. If these information is not detected and managed effectively in a timely manner, it may lead to communication interruption, data errors, or system instability, thereby affecting the reliability and efficiency of communication between the host computer and the slave device.

[0115] In this regard, this application further proposes that the general host computer communication method also includes:

[0116] Step S500: Monitor the frame matching, data extraction, and engineering value conversion processes to capture anomaly and business alarm information;

[0117] In step S600, the captured anomalies and alarm information are marked according to the format of timestamp, related data frame and context information, and stored in the error knowledge query table.

[0118] Specifically, monitoring the processes of frame matching, data extraction, and engineering value conversion aims to detect any deviations from expected behavior or exceeding preset thresholds in these core data processing steps in real time. For example, during frame matching, it can monitor whether the received raw byte stream conforms to the frame structure rules specified in the protocol definition file, such as whether the checksum is correct, whether the frame header or frame tail matches, and whether the frame length is abnormal. During data extraction, it can verify whether the raw byte values ​​of each data item extracted from the data frame are within a reasonable range, or whether the data type conversion is successful. During engineering value conversion, it can check whether the converted engineering value exceeds the preset physical range, or whether there are mathematical errors such as overflow or division by zero during the conversion process. In addition to purely technical anomalies, it can also capture business-level alarms, such as a critical data point not being updated for a long time, or abnormal status of lower-level devices (such as excessively high temperature or excessively low pressure). These alarms are usually based on business logic judgments. Capturing these anomalies and business alarm information can be achieved by setting event listeners, hook functions, or logging mechanisms at key processing points within the communication engine. When specific conditions are triggered, corresponding anomaly or alarm events are generated.

[0119] The captured anomalies and alarms need to be structured, tagged, and categorized for storage to facilitate subsequent analysis and diagnosis. Tagged based on timestamps record the exact time the anomaly or alarm occurred, typically accurate to milliseconds or microseconds, crucial for event tracing and time-series analysis. Tagged based on relevant data frames store the original data frame or key portions that caused the anomaly or alarm, enabling the reproduction of the problem scenario or analysis of the data source during diagnosis. Tagged based on contextual information records the system state, communication parameters, currently processed data point name, communication port number, lower-level device ID, communication protocol type, error code, and error description at the time of the anomaly, providing a more comprehensive diagnostic basis. This tagged information is then categorized and stored in an error knowledge lookup table, which can be a dedicated database table, a structured log file, or an error management module. Categorization criteria can include anomaly type (e.g., communication error, data parsing error, out-of-bounds value), alarm level (e.g., severe, warning, informational), occurring module (e.g., frame matching module, data extraction module), and lower-level device ID, facilitating subsequent querying, statistics, analysis, and automated diagnosis.

[0120] By monitoring key processes such as frame matching, data extraction, and engineering value conversion in real time, this application can promptly capture and identify various anomalies and service alarms that may occur during communication. This captured information is systematically tagged with timestamps, relevant data frames, and contextual information, and categorized and stored in an error knowledge lookup table, thus constructing a comprehensive foundation for error diagnosis. This enables technicians to quickly pinpoint the time, cause, and specific data of problems, greatly improving the efficiency and accuracy of troubleshooting, effectively avoiding communication interruptions or data errors caused by untimely detection of anomalies, and significantly enhancing the stability and reliability of general-purpose host computer communication methods.

[0121] In some of the embodiments described above in this application, a process of monitoring frame matching, data extraction, and engineering value conversion is proposed to capture anomaly and business alarm information. This information is then marked according to the format of timestamps, relevant data frames, and context information, and stored in an error knowledge lookup table. However, in practical applications, simply storing anomaly and alarm information cannot directly provide users with effective guidance for fault diagnosis and handling. When faced with system anomalies, users still need to manually query error codes, consult manuals, or rely on professionals for analysis, which reduces the efficiency and timeliness of fault handling and may lead to production interruptions or data processing delays.

[0122] In response, this application further proposes step S600, which, after the step of marking the captured anomalies and alarm information according to the format of timestamps, relevant data frames, and context information, and classifying and storing them in the error database, also includes:

[0123] Step S700: After a new anomaly or alarm is stored in the error knowledge query table, a matching query is performed in the error knowledge query table based on the error type or characteristics. The error knowledge query table contains several data records of diagnostic rules or historical cases, and each data record is associated with at least one error type and the corresponding processing suggestion.

[0124] In step S800, if a match is successful, the corresponding processing suggestion is actively pushed to the graphical user interface.

[0125] Specifically, when the system captures new exceptions or alarm information and stores it in the error knowledge lookup table according to a predetermined format (e.g., including timestamps, relevant data frames, and context information), a diagnostic process is triggered. This triggering mechanism can be an event listener that monitors write operations to the error knowledge lookup table in real time; or a background service that periodically scans the error knowledge lookup table to identify newly added unprocessed records.

[0126] Once a new anomaly or alarm record is detected, the system extracts key error types or features from the record. These features can be error codes, error message text, the module identifier where the error occurred, a specific range of data values, or a sequence of operations that led to the anomaly. The system then uses these extracted error types or features to perform a matching query in an error knowledge query table. This error knowledge query table is a structured knowledge base that pre-stores a large number of diagnostic rules or historical case records. Each record describes a known error situation in detail and is associated with at least one error type and detailed handling suggestions for that error situation. For example, a diagnostic rule can be defined as "If error code X occurs in module Y, then Z is recommended," while historical cases record the symptoms, cause analysis, and actual solution steps for a specific error in the past. The matching query process can be implemented using various technologies, such as keyword-based text matching, rule-based inference engines, pattern recognition algorithms, or finding the closest match by comparing the similarity of error feature vectors.

[0127] If a diagnostic rule or historical case data record matching the current anomaly or alarm information is successfully found in the error knowledge query table, the system will extract the associated processing suggestions from that matching record. Subsequently, the system will proactively push these processing suggestions to the graphical user interface of the host computer device. This push can be a pop-up notification, displaying detailed information in a specific diagnostic area, or providing a brief prompt in the status bar with a link to view details. Users can obtain professional handling guidance for the current problem immediately without manual searching.

[0128] Through the above technical solution, this application combines the storage of anomaly and alarm information with intelligent diagnostic processing. When a system anomaly occurs, it no longer merely records and stores the information, but automatically analyzes it based on a pre-set knowledge base and promptly provides users with specific handling suggestions. This greatly improves the efficiency and accuracy of fault diagnosis, reduces the time and effort required for users to manually troubleshoot problems, thereby effectively reducing system downtime and ensuring the stability and reliability of the communication process. Simultaneously, by linking user operations with audit logs, it also provides valuable data support for subsequent system optimization and fault tracing.

[0129] In the aforementioned general host computer communication method, the communication engine needs to perform frame matching, data extraction, and engineering value conversion on the slave device according to the protocol definition file. However, if the protocol definition file has a complex structure, is difficult to edit and maintain, or its data point definitions are not intuitive and standardized, it will lead to inefficient protocol configuration, be prone to errors, and affect the flexibility and reliability of the communication system.

[0130] In this regard, this application further proposes that the protocol definition file is an editable spreadsheet file, in which a data point table is defined in tabular form. The columns of the data point table include: data point name, address, data type, data length, conversion factor, offset, engineering unit, and upper and lower limits of the data.

[0131] Specifically, the protocol definition file can be in a common spreadsheet format, such as a Microsoft Excel file (.xlsx), a CSV file, or an OpenDocument Spreadsheet file (.ods). This format allows users to directly open, view, and edit the protocol definition using standard office software (such as Microsoft Excel, WPS Spreadsheet, etc.) without relying on specific development tools or programming environments. This editability greatly lowers the barrier to protocol configuration and maintenance, making it easy for non-professional programmers to manage communication protocols.

[0132] The editable spreadsheet file defines a data point table in tabular form. This data point table is the core of the protocol definition, clearly listing all the data points that need to be exchanged between the host computer and the slave device. Typically, each row in the data point table represents an independent data point, while each column defines the specific attributes or parameters of that data point.

[0133] The columns of the data point table define in detail the key information for each data point, including:

[0134] Data point name: A name used to uniquely identify and describe the data point, such as "motor speed" or "temperature sensor 1", to facilitate user understanding and reference.

[0135] Address: Indicates the physical or logical address of the data point in the lower-level device, such as Modbus register address, CAN message ID, and byte offset, etc. The communication engine uses this to locate the original data.

[0136] Data type: Defines the encoding format of the raw data, such as unsigned integer (UINT), signed integer (INT), floating point (FLOAT), boolean (BOOL), or string (STRING), etc., so that the communication engine can correctly parse the raw byte stream.

[0137] Data length: Specifies the number of bytes or bits occupied by this data point, ensuring that the communication engine can accurately capture the data.

[0138] Conversion factor: A multiplier used when converting raw values ​​read from lower-level devices into engineering values ​​with actual physical meaning.

[0139] Offset: An additive offset required when converting raw values ​​to engineered values. By using conversion factors and offset, raw data (such as ADC values) reported by lower-level devices can be accurately mapped to actual engineered unit values.

[0140] Engineering units: Physical units that represent engineering values, such as "℃", "rpm", "V", etc., which improve the readability and usability of the data.

[0141] Data upper and lower limits: Define the valid range of the engineering value of the data point, which can be used for data verification, anomaly detection or alarm triggering.

[0142] The above technical solution designs the protocol definition file as an editable spreadsheet file, clearly defining a data point table in tabular form, containing detailed parameters such as data point name, address, data type, data length, conversion factor, offset, engineering units, and upper and lower limits. This application greatly simplifies the configuration and maintenance of the communication protocol. Users do not need professional programming knowledge; they can intuitively view, edit, and update the protocol definition using familiar spreadsheet software, significantly improving the efficiency and accuracy of protocol configuration. This standardized and easy-to-understand definition method ensures that the communication engine can accurately parse the data from the lower-level device during frame matching, data extraction, and engineering value conversion, thereby improving the flexibility, reliability, and ease of use of the entire upper-level communication system.

[0143] The aforementioned general host computer communication method details the process of data interaction, access control, and exception handling between the host computer and the slave device. However, in order for this method to actually run and function, it needs to be converted into an executable form and provided with a stable platform for deployment and use.

[0144] refer to Figure 8 In this regard, this application further proposes a general host computer communication control system, which includes: a memory 10, a processor 20, and a general host computer communication program stored in the memory 10 and executable on the processor 20. The general host computer communication program is configured to implement the steps of the general host computer communication method as described above.

[0145] Specifically, the general-purpose host computer communication control system refers to a physical carrier capable of recording and saving data or programs. Memory 10 refers to a medium that can be read and written by a computer system; it can be transient or non-transient. Common types of memory 10 include, but are not limited to, hard disk drives, solid-state drives, flash memory (such as USB flash drives, SD cards), and optical discs (such as CD-ROMs, DVDs, Blu-ray discs). These media provide persistent storage space for computer programs, ensuring that the program is retained even after power loss. The computer program is a collection of instructions designed to guide the computer in performing specific tasks or operations. In this application, the computer program contains all the logic, algorithms, and data structures required to implement the aforementioned general-purpose host computer communication method. It encapsulates the various steps of the method, such as obtaining user permission data, initializing the communication engine, performing frame matching and data extraction, and allowing users to access and / or modify response data, in the form of machine-executable code. Processor 20, typically referring to a central processing unit 20 or other dedicated processing unit, is the core component of the computer system, responsible for interpreting and executing the instructions in the computer program. When the computer program is executed by the processor 20, the processor 20 processes the instructions one by one according to the preset order and logic in the program, thereby driving the entire host computer communication method to run. This includes reading program instructions from the memory 10, loading data into memory, performing calculations and logical judgments, and controlling external devices (such as network interfaces) to communicate.

[0146] Through the above technical solution, the complex general host computer communication method is embedded in the memory 10 as a computer program, enabling the processor 20 to execute the method efficiently and accurately. This not only provides a convenient and reliable way to deploy and distribute the host computer communication method, but also ensures that the method maintains consistent operating logic and performance in different computing environments. Users or system administrators do not need to manually configure complex communication logic; they only need to load and run the program on the memory 10 to achieve secure, efficient, and controllable data interaction between the host computer and the slave device, greatly improving system availability and deployment efficiency.

[0147] The following example will provide a more detailed explanation of the above technical solution:

[0148] In an industrial automation scenario, a factory needs a universal host computer software to monitor and control various slave devices in the workshop, such as different models of PLCs, smart sensors, and actuators. Existing solutions typically require custom software development for each device or protocol, resulting in high maintenance costs and limited functionality. The method provided in this application aims to solve these problems.

[0149] First, when an operator (e.g., user A) attempts to log in to the host computer system, the system initiates a multi-level authentication process, such as requiring user A to enter a username and password, and possibly performing secondary verification. Upon successful authentication, the system loads a pre-defined "operator-level" permission configuration file based on user A's identity, thereby determining user A's current user permission data. This permission data clearly defines which system resources user A can access and modify. Based on this permission data, the system allows loading specific communication configuration files and protocol definition files; for example, it allows loading configuration files and corresponding Modbus protocol definition files for communication with Modbus TCP protocol PLCs within the workshop.

[0150] During the communication engine initialization phase, the system establishes a connection with the lower-level device (e.g., a PLC) based on the loaded communication configuration file (which may contain information such as the PLC's IP address and port number). During this initialization process, the system parses user A's current user permission data. For example, the permission configuration file may contain a permission bitmap indicating that user A has permissions for "device control" and "viewing historical logs," but not for "configuration modification" and "data export." The upper-level device's graphical user interface dynamically renders based on this permission bitmap. For instance, buttons or menu items related to communication parameter modification and data export functions are disabled or hidden, while functions such as device start / stop and real-time data display remain available. This avoids the problem of insufficient fine-grained control over application permissions for functional modules in existing technologies.

[0151] Subsequently, the communication engine processes data from the lower-level device according to the loaded protocol definition file. The protocol definition file is an editable spreadsheet that defines a data point table, including data point names (e.g., "Temperature Sensor 1"), addresses (e.g., Modbus register address 40001), data types (e.g., floating-point numbers), data lengths, conversion factors, offsets, engineering units (e.g., "°C"), and upper and lower limits. After receiving the raw byte stream from the lower-level device, the communication engine identifies and extracts complete Modbus data frames according to the frame structure rules defined in the protocol definition file (e.g., Modbus TCP frame structure). If the security policy flag in the communication configuration file requires communication encryption (e.g., using TLS), the received raw byte stream is first decrypted and its integrity verified before frame matching and data extraction are performed. Then, based on the address offset and length specified for "Temperature Sensor 1" in the data point table, the communication engine extracts the corresponding raw byte values ​​from the data frames. Then, based on the conversion parameters defined for "Temperature Sensor 1" in the data point table (e.g., conversion coefficient 0.1, offset 0), the original byte value is converted into an engineered value (e.g., converting the original value 1000 to 100.0°C). These engineered values ​​ultimately form the response data and are uploaded to the host computer for user A to view. This method of driving data parsing through an externally editable file solves the problems of hard-coded communication parameters and data parsing rules and rigid configuration in existing technologies, significantly improving the system's flexibility and maintainability.

[0152] In the graphical user interface, the system controls the state of data display and editing controls based on user A's current user permission data. Since user A's permission data only includes data access permissions, not data modification permissions, all editing controls used to modify response data (e.g., setting temperature values) are disabled. Any request from user A to perform a modification operation is intercepted in the background logic and logged as an unauthorized event, ensuring system security. If another user (e.g., engineer B) logs in, and their permission data includes data modification permissions, engineer B can perform online corrections, parameter settings, or command issuance operations on the response data within the interface. All successfully executed user operations are associated with engineer B's identity and recorded in the audit log, enabling comprehensive traceability of operational behavior.

[0153] In addition, the system continuously monitors the entire process of frame matching, data extraction, and engineering value conversion to capture any anomalies or business alarms, such as communication timeouts, CRC check failures, or sensor data exceeding preset ranges. Once an anomaly or alarm is captured, the system marks it according to the format of timestamp, relevant data frame, and contextual information (e.g., device ID, data point name) and stores it in an error knowledge lookup table. When a new anomaly or alarm is added to the error knowledge lookup table, the system performs a matching query based on the error type or characteristics. The error knowledge lookup table contains several diagnostic rules or historical case records, each associated with at least one error type and a corresponding handling suggestion. If a match is successful (e.g., identifying "Modbus CRC check failure" and matching the suggestion "check physical connection or baud rate settings"), the system proactively pushes the corresponding handling suggestion to the graphical user interface, helping users quickly locate and resolve problems, significantly improving the efficiency of error handling in existing technologies. The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0154] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. A general host computer communication method, characterized by, The general host computer communication method includes: Obtain current user permission data to allow loading of communication configuration files and protocol definition files; The communication engine is initialized according to the communication configuration file, a connection with the lower-level device is established, and the application permissions of the functional modules are restricted according to the current user permission data during the initialization process. The communication engine performs frame matching, data extraction, and engineering value conversion on the lower-level device according to the protocol definition file, so as to generate and upload response data to the upper-level device. Based on the current user permissions, the user is allowed to access and / or modify the response data.

2. The method of claim 1, wherein, The step of obtaining user permission data to allow loading of communication configuration files and protocol definition files includes: When a user requests access to stored data, multi-level authentication is performed. After successful authentication, the corresponding level of permission configuration file is loaded based on the user's identity to determine the current user's permission data.

3. The general host computer communication method according to claim 2, characterized in that, The step of restricting the application permissions of functional modules based on the current user permission data includes: Parse the permission configuration file to obtain the current user role and its corresponding permission bitmap. The permission bitmap includes operation permissions for configuration modification, device control, data export, and viewing historical logs. In the graphical user interface of the host computer device, interface controls are dynamically rendered according to the permission bitmap, and operation buttons or menu items without permission are disabled or hidden.

4. The general host computer communication method according to claim 1, characterized in that, The communication engine performs frame matching, data extraction, and engineering value conversion on the lower-level device according to the protocol definition file to generate and upload response data to the upper-level device. The steps include: Based on the frame structure rules defined in the protocol definition file, identify and extract complete data frames from the received raw byte stream; Based on the data point table pre-configured in the protocol definition file, the original byte values ​​of each data item are extracted from the data frame according to the address offset and length specified in the data point table; The original byte values ​​are converted into engineered values ​​according to the conversion parameters defined for each data item in the data point table, so as to form the response data according to the engineered values.

5. The general host computer communication method according to claim 4, characterized in that, The step of extracting the original byte values ​​of each data item from the data frame according to the data point table pre-configured in the protocol definition file and the address offset and length specified in the data point table further includes: Obtain the security policy identifier within the communication configuration file; If the security policy identifier requires communication encryption, the raw byte stream from the lower-level device is received for decryption and / or integrity verification. After successful verification, the frame matching and data extraction are performed.

6. The general host computer communication method according to claim 1, characterized in that, The step of allowing the user to access and / or modify the response data based on the current user permissions includes: In the graphical user interface, the state of the data display control and the editing control are controlled based on the current user permission data; When the current user permission data includes data access permission, the editing controls in the interface will be disabled, and all modification operation requests will be intercepted in the background logic and recorded as unauthorized events. And / or when the current user permission data includes data modification permission, allow the user to perform online correction, parameter setting, or command issuance operations on the response data in the interface; All successfully executed user operations are associated with the current user's identity and recorded in the audit log.

7. The general host computer communication method according to claim 1, characterized in that, The general host computer communication method further includes: Monitor the frame matching, data extraction, and engineering value conversion processes to capture anomalies and business alarm information; The captured anomalies and alarms are tagged according to the format of timestamps, relevant data frames, and context information, and then stored in an error knowledge lookup table.

8. A general host computer communication method according to claim 7, characterized in that, The step of marking and classifying the captured anomalies and alarm information according to the format of timestamps, relevant data frames, and context information, and storing them in the error database, further includes: When a new anomaly or alarm is stored in the error knowledge query table, a matching query is performed in the error knowledge base based on the error type or characteristics. The error knowledge query table contains several data records of diagnostic rules or historical cases, and each data record is associated with at least one error type and the corresponding processing suggestion. If a match is found, the corresponding processing suggestions will be proactively pushed to the graphical user interface.

9. A general host computer communication method according to claim 1, characterized in that, The protocol definition file is an editable spreadsheet file, in which a data point table is defined in tabular form. The columns of the data point table include: data point name, address, data type, data length, conversion factor, offset, engineering units, and upper and lower limits of the data.

10. A general-purpose host computer communication control system, characterized in that, The general-purpose host computer communication control system includes: a memory, a processor, and a general-purpose host computer communication program stored in the memory and executable on the processor, wherein the general-purpose host computer communication program is configured to implement the steps of the general-purpose host computer communication method as described in any one of claims 1 to 9.

Images