Visual multi-protocol instruction management system and method

Abstract

The invention provides a visual multi-protocol instruction management system and method, and relates to the technical field of Internet of Things, and the system comprises a UI display layer for a user to input a multi-line instruction; the service arrangement layer transmits each row of instructions to a Hex instruction obtained by processing of the protocol processing layer, and the service arrangement layer issues the Hex instruction to an exclusive theme of the to-be-tested Internet of Things equipment through an MQTT client of the communication and operation and maintenance layer; the MQTT client receives an original Hex string responded by the to-be-tested Internet of Things equipment; the service arrangement layer distributes the original Hex string to a protocol processing layer for basic analysis to obtain an analysis field list, and triggers the protocol processing layer to perform deep analysis based on the analysis field list to generate a JSON tree when a user inputs a deep analysis instruction; and the data and security layer stores full-process interaction data of the layered architecture. The method has the advantages that a user can complete debugging operation on a single interface, switching among multiple tools is not needed, and convenience and continuity of debugging operation are greatly improved.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a visual multi-protocol command management system and method. Background Technology

[0002] The rapid development of IoT technology has driven the large-scale R&D and testing of various IoT devices (such as eSIM modules, smart sensors, and industrial controllers). During the device R&D and testing phase, engineers are crucial in completing key tasks such as protocol command construction and distribution, device response parsing, and remote operation and maintenance debugging. This involves constructing and distributing protocol commands based on standards such as APDU to achieve device configuration / control, receiving hexadecimal responses from the device and performing semantic parsing, and remotely verifying the device's network connection, eSIM status, logs, and other terminal system status. However, current toolchains for IoT device protocol interaction and remote debugging suffer from functional fragmentation, low automation, and poor user experience, making it difficult to meet the needs of efficient R&D and testing. Specifically, this manifests in the following aspects: 1. Existing technical solutions are mostly single-function tools, requiring switching between different tools / environments for each stage of operation, thus failing to form an integrated debugging process. Specific manifestations are as follows: 1.1) General MQTT clients (desktop or web-based) only support basic message publishing / subscription and can only display raw payload data. They lack the ability to construct structured instructions, parse versioned instructions, and display semantically for complex binary protocols such as APDU, and cannot handle the instruction adaptation requirements of multiple protocol versions. 1.2) Although the command-line APDU generation tool can output hexadecimal instructions based on parameters, it lacks a graphical interface, does not support multi-line dynamic editing, real-time instruction preview and automatic length verification, and cannot be linked with device response results. 1.3) The standalone ASN.1 parser requires manual input of data, execution of scripts and output of plain text results. It lacks a visual version switching function and cannot generate a hierarchical JSON tree structure. When adapting to different protocol versions such as SGP22 / SGP32, different scripts need to be switched, making the operation cumbersome.

[0003] 2. Existing tools lack intelligent protocol processing capabilities, and core processes rely on manual operation, which is not only inefficient but also prone to errors, as specifically manifested in the following ways: 2.1) During the protocol instruction construction phase, instruction length calculation and data type conversion (such as string to hexadecimal) need to be done manually. Tag truncation, length field calculation and data boundary determination often result in errors, leading to instruction issuance failure. 2.2) During the device response parsing phase, third-party tools only output raw hexadecimal strings. Testers need to manually truncate and translate each tag by referring to the protocol document, which can easily lead to problems such as field misalignment and semantic misunderstanding. Furthermore, it lacks the TLV+ASN.1 dual-layer structured parsing capability and cannot intuitively present the hierarchical relationship of nested fields. 2.3) When adding new tags, protocol commands, or adapting to new protocol versions, script code needs to be modified, resulting in high expansion costs and a lack of a unified visual configuration interface, leading to low adaptation efficiency.

[0004] In summary, existing technical solutions generally suffer from defects such as functional silos, fragmented interactions, low automation, and lack of data visibility. They cannot meet the core requirements of intelligent protocol construction and real-time structured parsing in the research and development and testing of IoT devices. There is an urgent need for a solution that can integrate capabilities from multiple stages and achieve full-process visualization and automation. Summary of the Invention

[0005] To address the problems existing in the prior art, this invention provides a visual multi-protocol command management system, which adopts a layered architecture. Each layer forms a hierarchical dependency relationship in the following order: UI display layer, service orchestration layer, protocol processing layer, communication and operation and maintenance layer, and data and security layer. The UI presentation layer is used to allow users to input multiple lines of instructions and generate instruction construction requests according to the protocol interaction test requirements of the IoT device under test. The service orchestration layer is used to transmit each line of the instructions to the protocol processing layer according to the instruction construction request. Then, the protocol processing layer processes each line of the instructions to generate a release request based on the Hex instructions obtained from the received instructions, and publishes it to the dedicated topic of the IoT device under test through the MQTT client of the communication and operation layer. The MQTT client is also used to receive the raw Hex string of the response from the IoT device under test and send it to the service orchestration layer; The service orchestration layer is also used to distribute the original Hex string to the protocol processing layer for basic parsing to obtain a list of parsed fields and to visualize it on the UI display layer. When the user inputs a deep parsing command through the UI display layer, the protocol processing layer is triggered to perform deep parsing based on the list of parsed fields to generate a JSON tree and to visualize it on the UI display layer. The data and security layer is used to store the entire process of interaction data of the layered architecture.

[0006] Preferably, the UI presentation layer includes: A console panel is provided for the user to input multiple lines of the aforementioned commands; APDU translator panel, used for the user to input the deep parsing commands.

[0007] Preferably, the service orchestration layer provides an instruction building controller, a message receiving scheduler, and a parsing process coordinator; The service orchestration layer transmits each line of instructions to the protocol processing layer by scheduling the instruction construction controller; The service orchestration layer verifies the validity of Hex commands through the message receiving scheduler, and generates a publish request and receives the original Hex string after the verification is successful. The service orchestration layer distributes the original Hex string to the protocol processing layer through the parsing process coordinator.

[0008] Preferably, each line of the instruction includes a data tag field, a data content field, and a data type field, wherein the data type field is a string or hexadecimal type; the protocol processing layer includes: An APDU builder is used to convert the string type in each line of the instruction to hexadecimal according to the instruction construction request, and to normalize the hexadecimal type to obtain the processed instruction. Then, it calculates the length of each line of the processed instruction and concatenates the data tag field, the length and the data content field to form a concatenation field. Then, it merges each concatenation field in line order to form the Hex instruction. A Hex instruction translator is used to sequentially scan the original Hex string, read the data tag field and the length therein, and extract the corresponding data content field according to the length. Then, the data content field is converted into ASCII characters, and the data tag field is annotated with semantics through dictionary mapping to generate a parsed field list containing the data tag field and its corresponding semantics, the data content field and its corresponding length and ASCII characters. An ASN.1 parser is used to load the protocol parsing rule set corresponding to the protocol version according to the deep parsing instruction containing the protocol version input by the user, and recursively decompose the data content fields in the parsing field list according to the protocol parsing rule set to generate the standardized JSON tree.

[0009] Preferably, the data and security layer includes: The shared message storage module is used to create thread-safe message storage to record data throughout the entire protocol interaction test process. A dictionary caching module is used to map the semantics through a dictionary cache for use by the Hex instruction translator. The logging module is used to record log data for the entire process of protocol interaction testing.

[0010] Preferably, the UI display layer includes an ADB tool panel, which allows the user to initiate maintenance and debugging requests after the protocol interaction test is completed; The service orchestration layer provides an ADB scheduler to convert the operation and maintenance debugging requests into ADB command strings; The communication and operation and maintenance layer provides an ADB executor for executing the ADB command string and capturing the execution results. When the execution result indicates successful execution, the execution result is structured, and when the execution result indicates failure, an error record is generated. The data and security layer is also used to write the structured operation and maintenance results into the operation and maintenance result set and associate it with the parsed field list and the JSON tree.

[0011] Preferably, the service orchestration layer provides a message receiving scheduler, which is used to retrieve the full-process interaction data of the same debugging session in the data and security layer after the operation and maintenance debugging is completed; The protocol processing layer is also used to compare the consistency between the data label field of the instruction constructed in the full-process interaction data and the data label field in the parsed field list, as well as the consistency between the key attributes of the JSON tree and the operation and maintenance results. When they are consistent or there are acceptable differences, a success log is recorded; otherwise, an exception is marked and a debugging report is generated and visualized in the UI display layer.

[0012] This invention also provides a visual multi-protocol command management method, applied to the aforementioned visual multi-protocol command management system, the visual multi-protocol command management method comprising: Step S1: The user inputs multiple lines of instructions through the UI display layer and generates an instruction build request based on the protocol interaction test requirements of the IoT device to be tested. Step S2: The service orchestration layer transmits each line of instructions to the protocol processing layer according to the instruction construction request. Then, it generates a release request based on the Hex instructions obtained by processing each line of instructions by the received protocol processing layer, and publishes it to the dedicated topic of the IoT device under test through the MQTT client of the communication and operation layer. Step S3: The MQTT client receives the original Hex string of the response from the IoT device under test and sends it to the service orchestration layer; In step S4, the service orchestration layer distributes the original Hex string to the protocol processing layer for basic parsing to obtain a list of parsed fields, which is then visualized on the UI display layer. When the user inputs a deep parsing command through the UI display layer, the protocol processing layer is triggered to perform deep parsing based on the list of parsed fields to generate a JSON tree, which is then visualized on the UI display layer.

[0013] Preferably, after performing step S4, the process further includes an operation and maintenance debugging process, including: Step S5: The user initiates an operation and maintenance debugging request through the UI display layer; Step S6: The service orchestration layer converts the operation and maintenance debugging request into an ADB command string; Step S7: The communication and operation layer executes the ADB command string and captures the execution result. When the execution result indicates that the execution was successful, the execution result is structured. When the execution result indicates that the execution failed, an error record is generated. Step S8: The data and security layer writes the structured operation and maintenance results into the operation and maintenance result set and associates them with the parsed field list and the JSON tree.

[0014] Preferably, after performing step S8, the process further includes verification and exception handling, including: Step S9: After the operation and maintenance debugging is completed, the service orchestration layer retrieves the full-process interaction data of the same debugging session from the data and security layer; Step S10: The protocol processing layer compares the consistency between the data tag field of the instruction constructed in the full-process interaction data and the data tag field in the parsed field list, as well as the consistency between the key attributes of the JSON tree and the operation and maintenance results. If they are consistent or there is an acceptable difference, a success log is recorded; otherwise, an exception is marked and a debugging report is generated and visualized in the UI display layer.

[0015] The above technical solution has the following advantages or beneficial effects: Through the collaborative work of a five-layer architecture, this invention comprehensively improves the efficiency, accuracy, and convenience of IoT device protocol interaction and remote debugging, effectively solving problems such as functional fragmentation, large human operation errors, and difficulty in data traceability in traditional technologies, and meeting the actual needs of IoT device research and development and testing processes. 1) By leveraging the UI presentation layer to provide users with a unified operation entry point, and combining the scheduling capabilities of the service orchestration layer, functions such as instruction construction, message sending and receiving, and protocol parsing are integrated, breaking the status quo of the traditional toolchain's fragmented functions. Users can complete operations such as inputting multiple lines of instructions, generating instruction construction requests, viewing parsing results, and issuing in-depth parsing instructions in a single interface without having to switch between multiple tools, greatly improving the convenience and consistency of debugging operations; 2) The service orchestration layer completes core scheduling tasks such as instruction transmission, Hex instruction release request generation, and raw Hex string distribution based on instruction construction requests. The protocol processing layer cooperates to implement Hex instruction processing, basic parsing and deep parsing of raw Hex strings, realizing fully automated processing from instruction construction and distribution to device response parsing. Compared with the traditional technology that relies on manual instruction encoding and response decomposition, this effectively reduces errors caused by manual operation and improves the accuracy and efficiency of protocol interaction. 3) The MQTT client in the communication and operations layer not only publishes Hex commands to the IoT devices under test on specific topics, but also receives the original Hex strings from the devices. Furthermore, by collaborating with the service orchestration layer and the protocol processing layer, it achieves seamless integration of protocol interaction and parsing. The system can automatically visualize the list of parsed fields obtained from basic parsing and the JSON tree generated from deep parsing in the UI, allowing users to intuitively obtain structured information from the device responses without the need for manual translation of each field from the protocol documentation, thus reducing reliance on users' professional skills.

[0016] 4) The data and security layer provides unified storage for all interactive data across the layered architecture, offering data support for tracing and verifying the debugging process. Compared to the problems of scattered data storage and difficulty in tracing in traditional technologies, this invention achieves centralized management of all process data, facilitating users to review and verify the debugging process and improving the traceability and reliability of debugging work. Attached Figure Description

[0017] Figure 1 A preferred embodiment of the present invention is a schematic diagram of a layered architecture for a visual multi-protocol instruction management system; Figure 2 A flowchart illustrating the visualization of the multi-protocol instruction management method is provided in a preferred embodiment of the present invention. Figure 3 This is a flowchart illustrating the operation and maintenance debugging process in a preferred embodiment of the present invention. Figure 4 This is a flowchart illustrating the verification and exception handling process in a preferred embodiment of the present invention. Detailed Implementation

[0018] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. The present invention is not limited to this embodiment; other embodiments that conform to the spirit of the present invention may also fall within the scope of the present invention.

[0019] In a preferred embodiment of the present invention, based on the above-mentioned problems existing in the prior art, a visual multi-protocol instruction management system is provided, such as... Figure 1As shown, a layered architecture is adopted, with each layer forming a dependency relationship in the following order: UI presentation layer 1, service orchestration layer 2, protocol processing layer 3, communication and operation layer 4, and data and security layer 5. UI presentation layer 1 is used to allow users to input multiple lines of instructions and generate instruction build requests according to the protocol interaction test requirements of the IoT device under test; Service orchestration layer 2 is used to pass each line of instructions to the protocol processing layer according to the instruction construction request. Then, according to the Hex instructions obtained by the received protocol processing layer 3, a release request is generated and published to the dedicated topic of the IoT device under test through the MQTT client 41 of the communication and operation layer 4. MQTT client 41 is also used to receive the raw Hex string of the response from the IoT device under test and send it to the service orchestration layer 2; Service orchestration layer 2 is also used to distribute the raw Hex string to protocol processing layer 3 for basic parsing to obtain a list of parsed fields and to visualize it on UI display layer 1. When the user inputs a deep parsing command through UI display layer 1, it triggers protocol processing layer 3 to perform deep parsing based on the list of parsed fields to generate a JSON tree and to visualize it on UI display layer 1. The data and security layer 5 is used to store the entire process of interactive data in the hierarchical architecture.

[0020] Specifically, the visual multi-protocol command management system provided by this invention constructs a five-layer collaborative architecture consisting of a UI display layer 1, a service orchestration layer 2, a protocol processing layer 3, a communication and maintenance layer 4, and a data and security layer 5. Through the close inter-layer dependencies, it integrates operations that traditionally require multiple tools (MQTT client, command-line APDU tool, independent ASN.1 parser, ADB terminal) into a closed-loop process within a single system. It also designs refined functional modules around the entire process of command construction, issuance, parsing, storage, and display, thus systematically optimizing the pain points of traditional IoT device protocol interaction and remote debugging, such as functional fragmentation, heavy reliance on manual intervention, low parsing efficiency, lack of data visibility, and poor maintainability.

[0021] More specifically, this invention is an integrated visualization tool for the research and development and testing of IoT devices, which can be used for full-link testing of IoT devices under test, including protocol interaction testing, remote operation and maintenance debugging, and closed-loop verification.

[0022] First testing phase: Protocol interaction testing First, the visual multi-protocol command management system of this invention is launched. Upon system startup, the configuration (Broker, port, TLS certificate, identity credentials, dictionary file, protocol version) is loaded. (Schema), complete the instantiation of the five-layer structure: - UI Presentation Layer 1: Register each tab component, including: Console panel 11 is used for users to input multiple lines of commands; APDU translator panel 12 is used for users to input deep parsing commands; ADB Tool Panel 13 is used to allow users to initiate maintenance and debugging requests after the protocol interaction test is completed.

[0023] - Service Orchestration Layer 2: Binding Instruction Builder 21, Message Receiving Scheduler 22, Parsing Process Coordinator 23, ADB Scheduler 24.

[0024] - Protocol processing layer 3: instantiated APDU builder 31, Hex instruction translator 32, ASN.1 parser 33 (lazy loading schema, reducing system startup resource consumption).

[0025] - Communication and Operations Layer 4: Establish an MQTT client object 41 (optional TLS to ensure communication security) and prepare an ADB executor 42.

[0026] - Data and Security Layer 5: Creates a shared message storage module 51, a dictionary cache module 52, and a log recording module 53, and initializes data storage and security mechanisms. Among them, the shared message storage module 51 is used to create thread-safe message storage to record the entire process data of protocol interaction testing; the dictionary cache module 52 is used to map semantics through the dictionary cache for use by the Hex instruction translator; and the log recording module 53 is used to record the entire process log data of protocol interaction testing.

[0027] After the system is instantiated, according to the protocol interaction test requirements, users can add or edit multiple lines of instructions in the console panel 11 provided by UI display layer 1. Each line of instructions includes a data tag field tag, a data content field data, and a data type field type. The data type field type is either string type str or hexadecimal type Hex.

[0028] After the user completes the input, the service orchestration layer 2 uses the scheduling instruction to construct the controller 21, which then transmits each line of instructions to the protocol processing layer 3; the protocol processing layer 3 includes: APDU builder 31 is used to convert the string type in each line of instruction to hexadecimal according to the instruction construction request and to normalize the hexadecimal type to obtain the processed instruction. Then, it calculates the length of each line of processed instruction and concatenates the data label field, length and data content field to form a concatenation field. Then, it merges the concatenation fields in line order to form Hex instruction. Specifically, for each line of instruction, if the corresponding data type field `type` is a string (`str`), it is converted to hexadecimal using UTF-8 encoding. If the corresponding data type field `type` is a hexadecimal (`Hex`) line, it is normalized to obtain the processed instruction. This normalization includes, but is not limited to, removing spaces, unifying case, and validating even-numbered bytes to avoid errors such as character omissions and inconsistent case values ​​that occur in traditional manual conversion. The length of each line of processed instruction can then be calculated based on the following expression: length_hex = format(len(data_hex) / 2, '02x') Where length_hex represents the length of the processed instruction, len(data_hex) / 2 represents half the length of the data content field, format represents converting half the length of the data content field into a hexadecimal string, and the 02x specification requires the output to be at least two digits, padding with zeros if necessary.

[0029] Alternatively, the length field can be extended to two bytes depending on the protocol, and 1 / 2 byte length fields can be configured, eliminating the need for manual calculation of the length field.

[0030] The data tag field, length field, and data content field are then concatenated to form the concatenation field SEG, where SEG = tag / len / data. These concatenation fields are then merged line by line to form a complete Hex instruction. Service orchestration layer 2 uses message receiving scheduler 22 to perform validity checks on the Hex instruction (including but not limited to verifying field completeness, length matching, total length threshold, and disabling illegal characters). Upon successful verification, a publish request is generated and published to the specified MQTT topic via MQTT client 41. Log entries (type = publish, content = HEX, timestamp) are recorded by logging module 53.

[0031] When MQTT client 41 receives the response payload pushed by the Broker, the on_message callback triggers message receiving scheduler 22. The original Hex string is then distributed to Hex instruction translator 32 via parsing process coordinator 23. Subsequently, Hex instruction translator 32 sequentially scans the original Hex string, reads the data tag field and length, and extracts the corresponding data content field according to the length. The data content field is then converted into ASCII characters, and the data tag field is semantically annotated using a dictionary mapping to generate a parsed field list containing the data tag field and its corresponding semantics, the data content field and its corresponding length and ASCII characters.

[0032] Specifically, the data tag field (tag) is preferably read according to the agreed-upon length or variable-length rules. The length field (Length) is read and its range is validated. Then, the corresponding data content field (data) is truncated based on the length. When converting the data content field to ASCII characters, non-printable characters are used as placeholders. When annotating semantics using dictionary mapping, unknown characters are marked as UNKNOWN and registered for future expansion. The final parsed field list object includes tag, semantic, length, data_hex, and ascii, automating basic parsing and avoiding issues such as tag truncation errors and data truncation deviations.

[0033] If users need to perform in-depth parsing, they can select the protocol version (including but not limited to SGP22 / SGP32) on the APDU translator panel 12 and submit the list of parsing fields. The ASN.1 parser 33 loads the corresponding protocol parsing rule set VersionedSchema (delayed initialization is performed if not loaded), identifies the constructed / primitive types according to the TLV / BER rules, recursively calls parseChild to generate the APDUNode tree for constructed type nodes, and performs decode_primitive (including enumeration value mapping) for primitive type nodes. Finally, it aggregates and generates a standardized JSON tree containing "tag, type, length, value / children, and offset position". This process does not require manual parsing script writing. When adapting to different protocol versions such as SGP22 / SGP32, only the version selection needs to be switched. This solves the problem that traditional independent ASN.1 parser programs require script modification for version adaptation and output plain text without structure, greatly shortening the multi-version parsing adaptation cycle.

[0034] Furthermore, the parsed field list and JSON tree are preferably presented through a table (including semantic columns) in UI display layer 1 and a collapsible JSON tree rendering. Users can intuitively view the tag semantics, the ASCII values ​​of data, and the hierarchical relationship of nested fields without having to manually memorize the meaning of protocol tags or look up documents, effectively improving the efficiency of data interpretation.

[0035] Subsequently, the system packages the message scheduling results and (optionally) ASN.1 tree into a standardized MessageObj (structure: MessageObj = {timestamp, topic, raw_hex, fields [], apdu_tree?, version?, status?}), and writes it to the shared message list through the shared message storage module 51 with locking to avoid concurrent data conflicts. At the same time, the log recording module 53 automatically records logs for key nodes such as instruction issuance (publish type, including Hex and timestamp), response reception (receive type), and parsing results (parse type). The logs contain timestamps, operation types, and core data. When tracing the source of subsequent problems, the entire process can be traced back directly through the logs without the need for manual sorting of scattered data. The UI display layer 1 reads a snapshot (deep copy) of the shared message list through a front-end timer or manual refresh event, and renders the parsed field list table, semantic columns, and JSON folded tree to realize the visualization of multi-dimensional data, allowing users to intuitively obtain the structured information of device responses. In addition, the dictionary caching module 52 caches the tag semantic mapping dictionary. The Hex instruction translator 32 directly calls the cached dictionary during parsing, avoiding repeated file reading. It also supports the registration of unknown tags for future expansion. When adding new tags in the future, only the dictionary file needs to be updated, without modifying the parsing logic, thus improving system maintainability.

[0036] Second testing phase: Remote operation and maintenance debugging The UI presentation layer 1 further integrates the ADB tool panel 13, forming a unified interactive interface with the console panel 11 and the APDU translator panel 12. This allows users to directly initiate device operation and maintenance debugging requests (such as chip status verification, network verification, log capture, etc.) after completing protocol interaction testing. This breaks down the barriers between protocol interaction tools and device operation and maintenance tools in traditional technologies. Users can complete the entire debugging process of protocol command issuance, response parsing, and operation and maintenance verification on the same interface without switching to a separate terminal or additional script environment, significantly improving operational continuity and debugging efficiency.

[0037] To achieve precise scheduling and execution of maintenance requests, Service Orchestration Layer 2 provides an ADB scheduler 24, which automatically converts user-triggered visual maintenance actions (such as clicking the "Check Chip and Network Status" button) into ADB command strings (including AT commands, shell commands, etc.) that the device can recognize. The ADB scheduler 24 has a built-in action command mapping table, eliminating the need for users to manually write complex commands. This not only reduces reliance on user expertise but also avoids syntax errors caused by manual command input. It supports execution in a preset order or batch processing mode, significantly reducing the cost of repetitive operations.

[0038] Furthermore, the communication and operations layer 4 is configured with an ADB executor 41, which receives the ADB command string transmitted by the service orchestration layer 2 and sends it to the IoT device under test through a remote communication channel. Simultaneously, it captures all key information about the command execution in real time, including standard output (stdout, i.e., valid business data from normal command execution), standard error (stderr, i.e., the reason for command failure), execution time, and return code (rc, 0 for success, non-zero for failure). The ADB executor 41 performs differentiated processing on the execution results: if the return code is 0 (successful execution), it automatically breaks down the scattered output in stdout into structured instruction blocks of command, output, and status, avoiding the tedious manual sorting; if the return code is non-zero (failure), it automatically encapsulates the error information in stderr into standardized error records (including error type, triggering command, and timestamp) and marks the error level, facilitating quick problem identification for users.

[0039] After receiving the structured operation and maintenance results transmitted by the communication and operation and maintenance layer 4, the data and security layer 5 will write them into a dedicated operation and maintenance result set (adbOps []) and establish an association with the list of parsed fields (TLV basic parsing results) and JSON tree (ASN.1 deep parsing results) in the same debugging process through the session ID. This solves the pain point that the protocol parsing results and the actual status of the device cannot be synchronously verified in traditional technologies, and quickly verifies the execution effect of protocol commands without the need for manual cross-tool data backtracking.

[0040] In addition, the system supports one-click export of operation and maintenance output results and associated protocol parsing data (raw Hex strings, parsed field lists, JSON trees) to standardized formats (such as txt / JSON). The exported file automatically retains the data association and debugging session information, which facilitates subsequent problem tracing and provides complete reference data for regression testing. This solves the problem of scattered storage and difficulty in archiving of operation and maintenance data and protocol data in traditional technologies.

[0041] Third testing phase: Closed-loop verification In a preferred embodiment of the present invention, the service orchestration layer 2 provides a message receiving scheduler 22, which is used to retrieve the full-process interactive data of the same debugging session in the data and security layer 5 after the operation and maintenance debugging is completed. Protocol processing layer 3 is also used to compare the consistency between the data label fields of the instructions constructed in the full-process interactive data and the data label fields in the parsed field list, as well as the consistency between the key attributes of the JSON tree and the operation and maintenance results. When they are consistent or there are acceptable differences, a success log is recorded; otherwise, an exception is marked and a debug report is generated and visualized in UI display layer 1.

[0042] Specifically, in this embodiment, after the operation and maintenance debugging is completed, the message receiving scheduler 22, based on the unique identifier of the current debugging session (such as session_id: 20251223_esim_002), retrieves the entire process interaction data of the session at once from the shared message storage module 51 of the data and security layer 5 and the operation and maintenance result set. This includes the expected tag / sequence of the build command, the original Hex instructions, the list of parsed fields, the JSON tree, and the ADB operation and maintenance results. During the data retrieval process, the system automatically associates data through the session ID, eliminating the need for manual filtering by the user and ensuring the integrity and relevance of the compared data.

[0043] Furthermore, the system automatically performs a two-dimensional comparison within the same debugging session to ensure consistency between protocol interaction and device status: Dimension 1: Constructing command fields and receiving parsed fields Protocol processing layer 3 compares the expected tag, order, and length of the construction command with the actual tag, order, and length in the parsed field list, such as verifying whether the order of Tag=07 (target ICCID) in the construction command is consistent with the parsing result, and whether the expected length matches the actual data segment length, to avoid interaction failures caused by field misalignment or length truncation during the command issuance process.

[0044] Dimension Two: Key APDU Tree Attributes and Operational Values Protocol processing layer 3 extracts core business attributes (such as eimTransactionId, activateImsi, and slotIndex) from the JSON tree and compares them precisely with the corresponding values ​​in the ADB operation and maintenance results. For example, it compares the activateIccid value in the JSON tree with the ICCID value obtained from ADB to verify whether the eSIM activation command is truly effective; it compares slotIndex: 1 in the JSON tree with the SIM card slot status obtained from ADB to verify whether the SIM card slot configuration meets expectations.

[0045] If the system detects a discrepancy (such as a missing field, mismatched values, abnormal length, or unexpected status code), it will immediately perform the following actions: 1) Standardize exception objects: Generate exception objects in the format {type, field, expected, actual, severity}. The severity field is divided into three levels—high, medium, and low—based on the degree of impact of the difference, allowing users to prioritize the handling of critical issues.

[0046] 2) Support for anomaly repair and regression testing: The system provides two anomaly handling paths. One is that users can trigger the resending of instructions in the UI display layer 1, and the service orchestration layer 2 will regenerate the Hex instructions based on the original build commands and issue them to achieve rapid repair. The other is that the system automatically records the replay entries and stores the full data of the debugging session (including the anomaly object) in the data and security layer 5 for subsequent regression testing to ensure that similar problems do not recur.

[0047] Furthermore, the data and security layer 5 periodically generates immutable snapshot copies of the entire process interaction data (such as MessageObj and operation and maintenance results). Each tab component in the UI presentation layer 1 is an independent interactive component. When a user switches tabs, only the UI presentation layer 1 is triggered to read the snapshot data, without interrupting any operations in the background (service orchestration layer, communication and operation and maintenance layer, etc.). This avoids interface lag caused by conflicts between UI operations and background data writing, while ensuring that the background continuously receives MQTT messages and stores data, preventing the loss of critical information due to user tab switching. For example, after a user sends a command in the console panel 11 and switches to the ADB tool panel to initiate an operation and maintenance request, the background will still continuously receive and store the device's response Hex serial-to-parallel data, without interruption due to tab switching. As can be seen, the front-end UI presentation layer 1 is only responsible for user interaction and snapshot data rendering, and does not perform any time-consuming operations (such as protocol parsing and command execution), ensuring that there is no delay in interface operation; the other layers continuously consume MQTT callbacks (such as the on_message event of device response) through independent threads to automate operations such as command issuance, message reception, and operation and maintenance execution, which completely solves the problems of UI freezing due to time-consuming parsing and data loss due to untimely message reception in traditional tools. Even in high-frequency message interaction scenarios, users can still switch tabs and initiate operations smoothly.

[0048] Furthermore, after receiving the raw Hex string from the device response, the background automatically performs basic parsing to generate a list of parsed fields, meeting the user's basic needs for structured data. It also adopts a lazy parsing mode, loading the corresponding VersionedSchema and generating a JSON tree only when the user actively selects the protocol version in the APDU translator panel and triggers the deep parsing command. This significantly reduces system resource consumption, especially in multi-device, multi-protocol debugging scenarios, avoiding the problem of excessive memory consumption caused by performing deep parsing on all device responses, while ensuring that users can quickly obtain the visualization results of nested structures when needed.

[0049] This invention also provides a visual multi-protocol instruction management method, applied to the aforementioned visual multi-protocol instruction management system, such as... Figure 2 As shown, the visualization method for managing multi-protocol commands includes: Step S1: The user inputs multiple lines of instructions through the UI display layer and generates an instruction build request based on the protocol interaction test requirements of the IoT device to be tested. In step S2, the service orchestration layer transmits each line of instructions to the protocol processing layer according to the instruction construction request. Then, the protocol processing layer processes each line of instructions to generate a release request based on the Hex instructions obtained from the received instructions, and publishes it to the dedicated topic of the IoT device under test through the MQTT client of the communication and operation layer. Step S3: The MQTT client receives the raw Hex string of the response from the IoT device under test and sends it to the service orchestration layer. In step S4, the service orchestration layer distributes the original Hex string to the protocol processing layer for basic parsing to obtain a list of parsed fields, which is then visualized on the UI display layer. When the user inputs a deep parsing command through the UI display layer, the protocol processing layer is triggered to perform deep parsing based on the list of parsed fields to generate a JSON tree, which is then visualized on the UI display layer.

[0050] In a preferred embodiment of the present invention, such as Figure 3 As shown, after step S4, the operation and maintenance debugging process also includes: Step S5: The user initiates an operation and maintenance debugging request through the UI presentation layer; Step S6: The service orchestration layer converts the operation and maintenance debugging request into an ADB command string; Step S7: The communication and operation layer executes the ADB command string and captures the execution result. When the execution result indicates that the execution is successful, the execution result is processed in a structured manner, and when the execution result indicates that the execution fails, an error record is generated. In step S8, the data and security layer writes the structured operation and maintenance results into the operation and maintenance result set and associates the parsed field list and JSON tree.

[0051] In a preferred embodiment of the present invention, after performing step S8, a verification and exception handling process is further included, such as... Figure 4 As shown, it includes: Step S9: After the service orchestration layer completes the operation and maintenance debugging, it retrieves the full-process interaction data of the same debugging session in the data and security layer. Step S10: The protocol processing layer compares the consistency between the data label fields of the instructions constructed in the full-process interaction data and the data label fields in the parsed field list, as well as the consistency between the key attributes of the JSON tree and the operation and maintenance results. If they are consistent or there are acceptable differences, a success log is recorded; otherwise, an exception is marked and a debug report is generated and visualized in the UI display layer.

[0052] In summary, this invention achieves seamless integration through the collaborative work of a layered architecture, completely changing the traditional debugging mode. Engineers no longer need to switch between MQTT clients, script tools, and ADB terminals, nor do they need to manually disassemble Hex strings or calculate instruction lengths. They can complete the entire process of "protocol instruction construction - remote distribution - structured parsing - device status verification - closed-loop verification - report export" through a single visual interface, significantly improving the efficiency and accuracy of IoT device R&D testing and mass production debugging.

[0053] The various stages of the process are interconnected through standardized data objects: MessageObj (encapsulating message timestamps, topics, raw Hex, parsed field lists, APDU trees, etc.), APDUNode (the core data object in the deep parsing stage, used to describe the node attributes of the ASN.1 tree (tag, type, value / children, etc.), realizing the standardized expression of nested structures), adbOps (containing operation and maintenance commands, output results, execution status, etc., serving as a unified carrier of operation and maintenance data, realizing the association between operation and maintenance results and protocol parsing data), and DiffRecord (encapsulating exception types, fields, expected values, actual values, severity, etc., serving as the core data object in the closed-loop comparison stage, realizing the standardized marking and display of exceptions). This provides the system with extended capabilities such as protocol plug-in, operation and maintenance script expansion, automated playback, and intelligent semantic inference. For example, when adding a new protocol version, only the corresponding VersionedSchema plugin needs to be developed, without modifying the core code. Standardized data objects can be compatible with the parsing results of different protocols. When adding a new operation and maintenance action, only a new entry needs to be added to the action command mapping table. adbOps can encapsulate the new operation and maintenance result to achieve seamless integration. Based on data objects such as MessageObj and DiffRecord, automated playback of debugging sessions can be achieved for regression testing. Based on the semantic attribute in the parsed field list, AI models can be introduced to achieve intelligent semantic inference, further reducing the difficulty of interpretation for users.

[0054] Through actual operation and verification, the present invention has the following technical improvements compared with the traditional method:

[0055] The above description is merely a preferred embodiment of the present invention and does not limit the implementation and protection scope of the present invention. Those skilled in the art should realize that any equivalent substitutions and obvious changes made using the content of this specification and illustrations should be included within the protection scope of the present invention.

Claims

1. A visual multi-protocol instruction management system, characterized in that, A layered architecture is adopted, with each layer forming a dependency relationship in the following order: UI presentation layer, service orchestration layer, protocol processing layer, communication and operation and maintenance layer, and data and security layer. The UI presentation layer is used to allow users to input multiple lines of instructions and generate instruction construction requests according to the protocol interaction test requirements of the IoT device under test. The service orchestration layer is used to transmit each line of the instructions to the protocol processing layer according to the instruction construction request. Then, the protocol processing layer processes each line of the instructions to generate a release request based on the Hex instructions obtained from the received instructions, and publishes it to the dedicated topic of the IoT device under test through the MQTT client of the communication and operation layer. The MQTT client is also used to receive the raw Hex string of the response from the IoT device under test and send it to the service orchestration layer; The service orchestration layer is also used to distribute the original Hex string to the protocol processing layer for basic parsing to obtain a list of parsed fields and to visualize it on the UI display layer. When the user inputs a deep parsing command through the UI display layer, the protocol processing layer is triggered to perform deep parsing based on the list of parsed fields to generate a JSON tree and to visualize it on the UI display layer. The data and security layer is used to store the entire process of interaction data of the layered architecture.

2. The visual multi-protocol instruction management system according to claim 1, characterized in that, The UI presentation layer includes: A console panel is provided for the user to input multiple lines of the aforementioned commands; APDU translator panel, used for the user to input the deep parsing commands.

3. The visual multi-protocol instruction management system according to claim 1, characterized in that, The service orchestration layer provides an instruction building controller, a message receiving scheduler, and a parsing process coordinator; The service orchestration layer transmits each line of instructions to the protocol processing layer by scheduling the instruction construction controller; The service orchestration layer verifies the validity of Hex commands through the message receiving scheduler, and generates a publish request and receives the original Hex string after the verification is successful. The service orchestration layer distributes the original Hex string to the protocol processing layer through the parsing process coordinator.

4. The visual multi-protocol instruction management system according to claim 1, characterized in that, Each line of the instruction includes a data tag field, a data content field, and a data type field, wherein the data type field is a string type or a hexadecimal type; the protocol processing layer includes: An APDU builder is used to convert the string type in each line of the instruction to hexadecimal according to the instruction construction request, and to normalize the hexadecimal type to obtain the processed instruction. Then, it calculates the length of each line of the processed instruction and concatenates the data tag field, the length and the data content field to form a concatenation field. Then, it merges each concatenation field in line order to form the Hex instruction. A Hex instruction translator is used to sequentially scan the original Hex string, read the data tag field and the length therein, and extract the corresponding data content field according to the length. Then, the data content field is converted into ASCII characters, and the data tag field is annotated with semantics through dictionary mapping to generate a parsed field list containing the data tag field and its corresponding semantics, the data content field and its corresponding length and ASCII characters. An ASN.1 parser is used to load the protocol parsing rule set corresponding to the protocol version according to the deep parsing instruction containing the protocol version input by the user, and recursively decompose the data content fields in the parsing field list according to the protocol parsing rule set to generate the standardized JSON tree.

5. The visual multi-protocol instruction management system according to claim 4, characterized in that, The data and security layer includes: The shared message storage module is used to create thread-safe message storage to record data throughout the entire protocol interaction test process. A dictionary caching module is used to map the semantics through a dictionary cache for use by the Hex instruction translator. The logging module is used to record log data for the entire process of protocol interaction testing.

6. The visual multi-protocol instruction management system according to claim 1, characterized in that, The UI presentation layer includes an ADB tool panel, which allows the user to initiate maintenance and debugging requests after the protocol interaction test is completed; The service orchestration layer provides an ADB scheduler to convert the operation and maintenance debugging requests into ADB command strings; The communication and operation and maintenance layer provides an ADB executor for executing the ADB command string and capturing the execution results. When the execution result indicates successful execution, the execution result is structured, and when the execution result indicates failure, an error record is generated. The data and security layer is also used to write the structured operation and maintenance results into the operation and maintenance result set and associate it with the parsed field list and the JSON tree.

7. The visual multi-protocol instruction management system according to claim 6, characterized in that, The service orchestration layer provides a message receiving scheduler, which is used to retrieve the full-process interaction data of the same debugging session in the data and security layer after the operation and maintenance debugging is completed. The protocol processing layer is also used to compare the consistency between the data label field of the instruction constructed in the full-process interaction data and the data label field in the parsed field list, as well as the consistency between the key attributes of the JSON tree and the operation and maintenance results. When they are consistent or there are acceptable differences, a success log is recorded; otherwise, an exception is marked and a debugging report is generated and visualized in the UI display layer.

8. A visual multi-protocol command management method, characterized in that, The visual multi-protocol instruction management method, applied to any one of claims 1-7, comprises: Step S1: The user inputs multiple lines of instructions through the UI display layer and generates an instruction build request based on the protocol interaction test requirements of the IoT device to be tested. Step S2: The service orchestration layer transmits each line of instructions to the protocol processing layer according to the instruction construction request. Then, it generates a release request based on the Hex instructions obtained by processing each line of instructions by the received protocol processing layer, and publishes it to the dedicated topic of the IoT device under test through the MQTT client of the communication and operation layer. Step S3: The MQTT client receives the original Hex string of the response from the IoT device under test and sends it to the service orchestration layer; Step S4: The service orchestration layer distributes the original Hex string to the protocol processing layer for basic parsing to obtain a list of parsed fields and displays it visually on the UI display layer. When the user inputs a deep parsing command through the UI display layer, the protocol processing layer is triggered to perform deep parsing based on the list of parsed fields to generate a JSON tree and displays it visually on the UI display layer.

9. The visual multi-protocol instruction management method according to claim 8, characterized in that, After performing step S4, the process also includes operation and maintenance debugging, including: Step S5: The user initiates an operation and maintenance debugging request through the UI display layer; Step S6: The service orchestration layer converts the operation and maintenance debugging request into an ADB command string; Step S7: The communication and operation layer executes the ADB command string and captures the execution result. When the execution result indicates that the execution was successful, the execution result is structured. When the execution result indicates that the execution failed, an error record is generated. Step S8: The data and security layer writes the structured operation and maintenance results into the operation and maintenance result set and associates them with the parsed field list and the JSON tree.

10. The visual multi-protocol instruction management method according to claim 9, characterized in that, After performing step S8, the process further includes verification and exception handling, including: Step S9: After the operation and maintenance debugging is completed, the service orchestration layer retrieves the full-process interaction data of the same debugging session from the data and security layer; Step S10: The protocol processing layer compares the consistency between the data tag field of the instruction constructed in the full-process interaction data and the data tag field in the parsed field list, as well as the consistency between the key attributes of the JSON tree and the operation and maintenance results. If they are consistent or there is an acceptable difference, a success log is recorded; otherwise, an exception is marked and a debugging report is generated and visualized in the UI display layer.

Images