Multi-dimensional self-defined JSON configuration embedded menu generation and fault-tolerant method

Abstract

The application provides a multi-dimensional self-defined JSON configuration embedded menu generation and fault-tolerant method, which comprises the following steps: an upper computer maintenance tool receives multi-dimensional self-defined input data for an embedded menu, generates a JSON structured configuration file, and performs integrity verification; the tool performs offline verification on the JSON configuration file, and transmits the verified JSON configuration file to a target embedded terminal; the embedded terminal loads the JSON configuration file, filters a target menu item set to be displayed from a full menu database, and constructs a tree menu structure to drive screen rendering; when the verification fails, the parsing of the configuration file is blocked, and a bottom menu data structure is called to display; the behavior data of a user is captured, and based on the matching degree between the behavior data and the current menu structure, an optimization adjustment instruction for the current JSON configuration structure is generated; the application aims to solve the problems of insufficient self-defined dimensions, complicated maintenance and debugging, and weak fault-tolerant bottoming capacity in the prior art.

Description

Technical Field

[0001] This invention relates to the field of embedded human-computer interaction technology, and in particular to a method for generating and fault-tolerant embedded menus with multi-dimensional custom JSON configuration. Background Technology

[0002] Embedded human-machine interfaces (HMIs) are the core windows for information interaction between users and devices in products such as industrial equipment, medical instruments, automotive dashboards, and smart home appliances. As embedded systems become increasingly complex, menu systems, as the primary carrier of HMI, directly impact user efficiency and the user experience due to their structural complexity, customization flexibility, and operational stability. Early embedded menu systems typically used hard-coding, directly embedding menu names, hierarchical relationships, display order, and corresponding function callbacks into the program code. While this approach offers high execution efficiency and simple logic, each adjustment to the menu structure (e.g., adding menu items, changing display order, adapting to different regional user habits) necessitates modifying the source code, recompiling the firmware, and performing complete regression testing. This process is time-consuming, costly, and demands high programming skills from maintenance personnel, failing to meet end-users' rapid iteration needs for personalized menu configurations. To address the aforementioned issues, menu generation technologies based on configuration files have emerged in recent years. Among these, JSON format, due to its lightweight, readable, and cross-platform characteristics, has been widely used in the field of embedded menu configuration. Existing JSON configuration schemes allow users to define some attributes of the menu, such as menu name and display order, by editing the JSON file, thus initially realizing the idea of ​​configuration-driven display. However, in practical applications, existing solutions still have the following significant drawbacks: First, the customization dimensions are limited. Most solutions only support configuration of menu names or simple levels, and cannot achieve deep customization of fixed-value interfaces (i.e., displaying multiple parameter items with units, ranges, and steps) and menu attributes (such as operation permissions, whether they are editable, and whether they trigger linked actions). When devices need to adapt to the personalized needs of different regions and user groups, code modifications are often still required, resulting in insufficient adaptability. Second, existing solutions usually require users to directly write JSON files, as the JSON format is limited by the constraints of configuration files. The use of symbols such as commas and semicolons is sensitive, and manual editing is prone to syntax or logical errors (such as mismatched parent and child IDs, or missing required fields). Furthermore, the lack of dedicated verification tools and visual preview functions means errors are often only discovered when the embedded terminal loads the program, and the terminal can only indicate configuration errors, not pinpoint the specific error location, making debugging cumbersome and time-consuming. Thirdly, many solutions rigidly map menu structures to fields in configuration files, failing to allow for flexible filtering of displayed content based on configuration. For example, if the firmware has 100 pre-defined menu items, but the user only wants to display 20, existing solutions often require modifying firmware code to disable the remaining items, making dynamic configuration control impossible. Fourthly, when configuration files are missing or incorrect, existing solutions typically only output an error message, preventing the device from displaying the menu correctly, leading to interrupted human-machine interaction and severely impacting device availability. This is especially problematic in unattended industrial environments, where equipment failure due to configuration issues after startup can have serious consequences. Therefore, there is an urgent need in this field for a multi-dimensional, customizable JSON configuration embedded menu generation and fault-tolerant method to solve the above problems. Summary of the Invention

[0003] This invention provides a multi-dimensional customizable JSON configuration embedded menu generation and fault tolerance method, aiming to solve the problems of insufficient customization dimensions, cumbersome maintenance and debugging, and weak fault tolerance capabilities in existing solutions. It realizes flexible configuration of menus in all dimensions, collaborative optimization with dedicated tools, and intelligent fault tolerance closed loop, thereby improving the adaptability, maintainability, and stability of embedded human-computer interaction systems.

[0004] This invention provides a method for generating and fault-tolerant embedded menus with multi-dimensional custom JSON configuration, comprising the following steps: Step 1: The host computer maintenance tool receives multi-dimensional custom input data for the embedded menu, generates a JSON structured configuration file, and attaches an integrity verification credential calculated based on the file content to the configuration file. Step 2: The host computer maintenance tool performs offline verification on the JSON configuration file. The offline verification includes at least syntax correctness verification, logical integrity verification, and self-consistency verification of the integrity verification certificate. After the verification is passed, the JSON configuration file is transmitted to the target embedded terminal. Step 3: During the startup phase, the embedded terminal loads the JSON configuration file, parses the display filtering field and hierarchical association field contained therein, filters out the set of target menu items to be displayed from the full menu database pre-installed in the terminal firmware, and recursively constructs a tree menu structure based on the hierarchical association field to drive screen rendering. Step 4: If the JSON configuration file is missing before loading or the verification and transmission steps fail, the embedded terminal blocks the parsing of the configuration file and instead calls the pre-set fallback menu data structure in the internal fixed storage area for display, and records the corresponding error information. Step 5: During menu operation, the embedded terminal continuously captures the user's time-series operation behavior data. Based on the degree of matching between the time-series operation behavior data and the menu structure defined in the current JSON configuration file, an interaction state evaluation value is calculated. When the interaction state evaluation value meets the preset correction trigger condition, an optimization adjustment instruction for the current JSON configuration structure is generated, and the instruction is transmitted to the host computer maintenance tool to guide the user to iteratively modify the configuration file.

[0005] Compared with the prior art, the beneficial effects achieved by the present invention are as follows: 1. This invention not only supports customization of basic information such as menu name and display order, but also enables unlimited nested configuration by introducing hierarchical association fields (parent menu ID - child menu ID); it supports personalized combination and sorting of fixed-value items through fixed-value configuration fields; and it supports customization of menu attributes such as operation permissions, editability, and linked actions through attribute configuration fields. This system breaks through the limitation of limited customization dimensions in existing solutions, allowing users to adapt to personalized menu needs in different scenarios without modifying program code.

[0006] 2. The dedicated maintenance tool of this invention provides functions such as a visual editing interface, automatic syntax and logic verification, verification code generation and anti-counterfeiting, offline preview and error location, which greatly reduces the threshold for non-professionals to configure the menu; compared with the manual editing mode of the existing solution, it reduces the configuration error rate and debugging and maintenance time.

[0007] 3. This invention designs a hierarchical response mechanism for different anomaly types such as no configuration file, failed credential verification, syntax errors, and missing required fields. This mechanism automatically generates a default JSON file, calls the fixed static menu, and completes missing fields, ensuring that the device can start normally and display the available menu under any abnormal scenario.

[0008] 4. Based on traditional static configuration, this invention adds steps such as capturing user operation behavior, evaluating interaction state entropy, and generating menu structure optimization suggestions. It can automatically detect unreasonable layouts such as frequently used functions being hidden too deeply, and present specific migration or folding suggestions in the host computer maintenance tool to guide users to iteratively optimize the configuration file. This mechanism enables the menu structure to continuously adapt to the user's actual operating habits, further improving the friendliness of human-computer interaction and operating efficiency.

[0009] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0010] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention, but do not constitute a limitation thereof; in the drawings: Figure 1 This is a flowchart illustrating a multi-dimensional custom JSON configuration embedded menu generation and fault tolerance method provided by the present invention. Detailed Implementation

[0011] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention. Example 1:

[0012] This invention provides a method for generating and fault-tolerant embedded menus with multi-dimensional custom JSON configuration. Please refer to [link / reference]. Figure 1 This includes the following steps: Step 1: The host computer maintenance tool receives multi-dimensional custom input data for the embedded menu, generates a JSON structured configuration file, and attaches an integrity verification credential calculated based on the file content to the configuration file. Step 2: The host computer maintenance tool performs offline verification on the JSON configuration file. The offline verification includes at least syntax correctness verification, logical integrity verification, and self-consistency verification of integrity verification credentials. After the verification is passed, the JSON configuration file is transmitted to the target embedded terminal. Step 3: During the startup phase, the embedded terminal loads the JSON configuration file, parses the display filtering fields and hierarchical association fields contained therein, filters out the set of target menu items to be displayed from the full menu database pre-installed in the terminal firmware, and recursively constructs a tree menu structure based on the hierarchical association fields to drive screen rendering. Step 4: If the JSON configuration file is missing before loading or the verification and transmission steps fail, the embedded terminal blocks the parsing of the configuration file and instead calls the pre-set fallback menu data structure in the internal fixed storage area for display and records the corresponding error information. Step 5: During menu operation, the embedded terminal continuously captures the user's timing operation behavior data. Based on the degree of matching between the timing operation behavior data and the menu structure defined in the current JSON configuration file, the interaction state evaluation value is calculated. When the interaction state evaluation value meets the preset correction trigger condition, an optimization adjustment instruction for the current JSON configuration structure is generated and the instruction is transmitted to the host computer maintenance tool to guide the user to iteratively modify the configuration file.

[0013] Specifically, step 1 is completed by the host computer (PC-based maintenance tool). The user inputs multi-dimensional custom information such as menu name, hierarchy, display order, and attributes (such as whether it is editable) through a graphical interface. The tool converts this information into a standard JSON format file and calculates a unique verification credential based on the file content (such as text, timestamp, size, etc.), which is then appended to the end of the file for subsequent anti-tampering verification.

[0014] Step 2 is also executed on the host computer, performing a triple offline validation on the generated JSON file: first, syntax correctness (e.g., matching brackets, valid key-value pairs); second, logical integrity (e.g., whether the parent menu ID exists, whether required fields are complete); and third, voucher consistency (i.e., recalculating the voucher and comparing it with the voucher attached to the file). Only if all three checks pass can the file be transferred to the embedded terminal.

[0015] Step 3 is executed when the embedded terminal (such as a power distribution terminal or HMI device) starts up. The terminal firmware has all possible menu items pre-set (full menu database, such as 100 basic menu items), but only the items marked as true in the JSON configuration file are displayed (i.e., "display":1). At the same time, a tree structure is recursively built according to the "parent-child ID" relationship, and the LCD screen is driven to render.

[0016] It should be noted that each menu item in the JSON configuration contains a "parent_id" field (for example, the parent_id of a submenu points to the ID of the parent menu); the terminal starts from the root node (parent_id is empty or 0) and recursively searches for all child nodes. For the current node, it traverses the collection to be rendered, and takes all items whose parent_id is equal to the ID of the current node as its child nodes. This process is repeated for each child node until there are no deeper nodes; finally, a complete multi-level menu tree is formed.

[0017] If there is no JSON file in the preset path, or if the verification in steps 2-3 fails (such as a mismatch in uniqueness verification credentials or missing fields), the system will not attempt to parse the problematic configuration. Instead, it will directly use a set of basic menus (such as "Running Information", "Settings View", "Event Log" and other fixed items) that are embedded in the device's read-only memory to ensure that the device is always operable, while recording the error type, time, etc. in the log.

[0018] During normal operation, the terminal records time-series behavioral data such as the number of times each menu item is clicked / selected, the operation time interval, and the page turning depth. Then, it calculates an interaction state evaluation value to measure the degree of matching between the current menu structure and the user's actual operating habits. If the evaluation value exceeds the threshold (for example, if the user frequently enters a deep menu, it means that the menu should be moved up), it automatically generates optimization suggestions (such as "It is recommended to modify the value from the third-level menu to the first-level menu"), which will be presented to the user the next time the host computer connects, guiding them to modify the JSON configuration.

[0019] In one specific implementation, in step 1, the integrity verification certificate is generated in the following manner: The text string content (Content), Unix timestamp (file creation time), file size (Size), and line count (Lines) of the JSON configuration file are extracted, concatenated sequentially using a one-way hash function, and then a digest value is calculated. The one-way hash function is: Summary value The integrity verification credential is written to the end of the JSON configuration file; the embedded terminal recalculates and compares it before loading, and if they are inconsistent, the verification is deemed to have failed.

[0020] Specifically, Content is the complete text string of the JSON file, obtained by directly reading the file; Timestamp is the Unix timestamp when the file was generated, provided by the host computer's system clock; Size is the file size in bytes, obtained through the operating system's file interface; Lines is the total number of lines in the file, obtained by counting newline characters. Concatenate the four parameters above into a string in sequence using delimiters (such as vertical bars | or direct concatenation), and then input it into a one-way hash function (such as MD5, SHA-1, or SHA-256). The characteristic of a one-way hash function is that it takes data of any length as input and outputs a digest value of a fixed length. It is also impossible to deduce the original text from the digest. Any slight change to the input data will cause the digest value to change drastically. Hash the timestamp, size, number of lines, and content together to prevent attackers from modifying the file content and then recalculating the hash and replacing the original hash (because metadata such as timestamps are also involved in the calculation, and if the timestamp is modified, it will not match the actual time when the file was generated). When the embedded terminal loads, it rereads the file and extracts the same four parameters, calculates a new hash value using the same algorithm, and compares it with the hash value stored at the end of the file: if they match, the verification passes; otherwise, the verification fails, triggering the fallback process in step 4. In practical engineering, SHA-256 is preferred as the hash function, as it is more secure than MD5. The hash value is appended to the last line of the JSON file in hexadecimal string form. This does not affect the JSON parser's reading of the main content. Comment lines can be ignored or the verification block can be read separately during parsing. In one specific implementation, step 3, the process of filtering out the set of target menu items to be displayed, includes: Determine the total set of all menu items pre-installed in the firmware as follows: The JSON configuration file defines the display flags corresponding to each menu item. ; The first stage involves selecting a set of valid identifiers. ; The second stage performs reachability filtering based on the parent-child mapping relationship defined by the hierarchical association field: if the parent menu identifier specified by a menu item is in the set... If a menu item does not exist in the parent menu and its identifier is not empty, then the menu item is removed from the rendering sequence, ultimately resulting in a display set containing the root node and valid link nodes. ; Specifically, this embodiment describes the two-stage filtering logic from the full menu to the actual displayed menu in configuration-driven dynamic display, which solves the problem that the display flag may be 1 but the parent menu is hidden, ensuring that the final displayed menu tree is complete and reachable; Full menu collection The firmware pre-builds all possible menu items, each with a unique identifier (e.g., ID=101 for "fixed value modification" and ID=202 for "event logging"); regardless of the JSON configuration, the device will not display menu items beyond this set. A full menu database pre-installed in the embedded terminal firmware The i-th menu item; display flag. A boolean field ("display":1) is defined for each menu item in the JSON configuration file. This indicates that the user wants this menu item to be displayed. Indicates hiding; first stage of filtering These are the menu items that all users explicitly request to be displayed; In the second phase, each menu item configuration typically includes a parent menu ID field to define its position in the menu tree (e.g., "parent_id":101); if a menu item The menu item corresponding to the parent menu ID is not present. If the parent menu is hidden by the user or does not exist at all, and the parent menu ID is not the root node (not empty), then... These will become orphan nodes and cannot be reached through normal navigation in the menu tree; in this stage, these orphan nodes will be removed from the display set, retaining only those nodes whose paths originate from the root node and pass through consecutive parent nodes. Menu items in; This embodiment is used to avoid the logical contradiction that the user configures the display of a submenu but hides its parent menu, making the submenu inaccessible forever. At the same time, removing orphan nodes can simplify the recursive logic of the rendering engine and prevent invalid nodes from occupying display resources. In the actual code implementation, you can first build a mapping table from menu IDs to their parent IDs, and then perform a breadth-first traversal starting from the root node (usually with a parent ID of 0 or null), adding only those menu items whose parent nodes have been confirmed to be retained to the final display set. Isolated nodes that are not traversed are discarded directly, and a warning message is recorded in the log.

[0021] In one specific implementation, the display order of multiple sub-menu items under the same parent node is based on the display priority coefficient defined in the JSON configuration file. Sort in descending order and display priority coefficients. The calculation formula is: in, A positive integer sorting value specified by the user; the smaller the value, the earlier the expected display position. This represents the depth of the menu item within the nested tree structure. and This is a preset positive constant adjustment factor in the firmware; if the calculated values ​​from multiple menu items are... If they are equal, a deterministic decision is made based on the secondary auxiliary sorting field in the JSON configuration file or the default physical storage index.

[0022] Specifically, this embodiment is used to solve the problem of displaying and sorting multiple sub-menus within the same level. It introduces a priority coefficient that takes into account both the user-specified order and the menu depth, making the sorting more reasonable.

[0023] In the formula, This specifies the sorting value for each menu item as configured by the user in the JSON configuration. For example, "order":1 means the item should be first, and "order":2 means second. This value is obtained from user input by the host computer tool and is a positive integer. This represents the nesting depth of the menu item in the final tree structure. The root node has a depth of 0, its direct child nodes have a depth of 1, and so on. This value is recursively calculated by the embedded terminal when resolving the hierarchical relationship. , These are two positive adjustment factors, pre-written into the firmware code, for example, taking... =0.5, =0.2. Used to control the sensitivity of the user-specified order to sorting (the higher the value, the more significant the difference in order). Used to control the intensity of depth decay (the greater the intensity, the faster the priority of deep menu items decreases).

[0024] The formula consists of the multiplication of two parts, where The output value is based on the positive integer 'order' specified by the user; the smaller 'order' is, the larger the output value. The items are ranked based on their depth; the deeper the menu, the smaller the item. This naturally lowers the priority of deeper menus compared to shallower menus. The larger the value, the higher the menu item appears in the sorting (descending order).

[0025] Users can force the order of menu items at the same level using the `order` property, but when two menus have the same `order`, the menu that is shallower in depth will receive a higher priority. This allows frequently used menu items to be placed at the top of the list; this avoids conflicts that may result from relying entirely on user input, while also encouraging the design of frequently used menu items in shallower layers.

[0026] A deterministic decision means that if the priority coefficients of the two menus are equal... If they are completely equal (theoretically the probability is extremely low, but it may happen due to floating-point precision), then the secondary sorting fields in the JSON are compared in turn or the physical storage index of the menu in the full firmware database (such as ID size) is used directly to determine the order, ensuring that the sorting result is uniquely determined.

[0027] Preset in firmware =0.3, =0.1, using double-precision floating-point numbers for calculation. Before sorting, apply this formula to the sub-menu lists under the same parent node to calculate the priority coefficient for each item. Then call the standard library's stable sorting algorithm according to priority coefficients. Sort in descending order.

[0028] In one specific implementation, step 4, which involves calling a pre-defined fallback menu data structure in the internal hardened storage area, also includes a graded response mechanism based on error type: The set of error types should include at least the following: missing file, failed credential verification, syntax error, and missing required field. If the error type is file missing, the embedded terminal will actively call the preset generation function to generate a default JSON file based on the full menu database and store it in the specified path before attempting to reload it. If the error type is credential verification failure or syntax error, the embedded terminal directly skips external storage reading and displays the static menu array mapped in the fixed storage area. If the error type is "required field missing", the embedded terminal calls the completion function to fill the missing field with preset safe default values ​​and then continues to execute the parsing process.

[0029] Specifically, this embodiment adopts differentiated recovery strategies for different error types, rather than using a fixed menu indiscriminately. Among them, missing file means that there is no JSON configuration file in the preset path; credential verification failure means that the file exists, but the calculated hash value is inconsistent with the hash value stored in the file; syntax structure error means that the JSON format does not conform to the standard (such as missing commas or mismatched parentheses), causing the parser to throw an exception; missing required fields means that the JSON syntax is correct, but some key fields are missing (for example, a menu item does not have an id field or does not have a parent_id field). When a file is missing, the terminal automatically calls a pre-defined function that iterates through the full menu set in the firmware. The system generates a complete JSON file according to the preset default rules (such as displaying all menus, default order by ID in ascending order, and depth automatically built according to parent-child relationship) and writes it to the preset path. Then, it re-executes the loading process in step 3. After this process, the device is equivalent to self-healing to the factory state, and the generated configuration file can be used directly after a subsequent restart. When credential verification fails or a syntax error occurs, these two errors indicate that the configuration file may be corrupted or tampered with, and the automatic generation of the default JSON file may also fail due to storage space issues; therefore, the safest approach is to directly ignore the external configuration file, map the static menu array in the read-only storage area, and display it immediately to ensure that the core functions of the device are available. When a required field is missing, this is a relatively mild error, which may simply be that the user has omitted a non-critical attribute in their configuration. In this case, the completion function is called to assign a safe default value to the missing field (for example, if the "visible" field is missing, it is set to true by default; if the "order" field is missing, it is set to 999 by default, etc.), and then the subsequent parsing process continues to be executed, avoiding the complete discarding of other valid configurations from the user. It should be noted that tiered response can preserve user configuration to the greatest extent while ensuring that the device will not black out or crash under any abnormal circumstances; automatically generating a default JSON file when a file is missing is better than directly using a static array, because the generated file can be modified by the user later, while a static array cannot be replaced externally; In the specific implementation, in the embedded Linux system, the error log is recorded in / var / log / menu_errors.log, which includes the timestamp, error type, and specific reason (such as "missing field 'parent_id' atline42"). For missing required fields, the completion function can be designed as follows: if parent_id is missing, it is set to 0 (root node); if display is missing, it is set to 1. After completion, a warning log is generated, but loading is not interrupted.

[0030] In one specific implementation, in step 5, the interaction state evaluation value is the instantaneous operation entropy of the current menu interface. : in, This represents the number of menu items currently visible on the screen. Deadline No. The cumulative frequency distribution of user operations on each menu item; This is an ideal interaction probability distribution derived from the current JSON configuration file structure, whose values ​​are determined by the menu item hierarchy depth. and configure the specified display order Confirmed, satisfied ,and ; This is a preset, minimal positive number smoothing term.

[0031] Specifically, this embodiment proposes a quantitative formula for measuring the degree of matching between the menu structure and the user's actual operating habits; this entropy value The smaller the value, the closer the actual operation distribution is to the ideal distribution (the more reasonable the menu structure), and the lower the entropy value. The larger the value, the greater the deviation between user operation and expectation, and the menu may need optimization. In the formula, The number of menu items visible on the current menu interface (e.g., a currently displayed menu page); To the current moment Up to now, the The percentage of times a menu item is operated by the user (e.g., clicked, selected, or entered) out of the total number of operations on all menu items; for example, if there are 3 menu items with operation counts of 10, 20, and 70 respectively, then p = [0.1, 0.2, 0.7]; this distribution is obtained by real-time cumulative statistics from the embedded terminal; The ideal interaction probability distribution is determined by the structure of the current JSON configuration file and is independent of the actual user actions; its calculation formula is... middle, For the first The depth of each menu item (same as above) (i.e., the depth of the menu item in the tree-like nested structure). The display order value specified by the user for this menu item in the JSON (same as above). (i.e., the positive integer sorting value specified by the user). With priority coefficient Attenuation factor in the calculation formula Same; the shallower the depth, the earlier the user-specified order appears. The smaller the menu item, the higher its ideal probability. The larger the value, the more frequently shallow and prominent the menu items should be used, according to the view that a good menu structure should allow shallower, more prominent menu items to be used more often. ; To be a very small positive number, to prevent When the logarithm is zero, the logarithmic operation results in infinity, while ensuring... The stability when =0 is actually It won't be 0, because all visible menu items... All are greater than 0; This formula is a variation of the KL divergence, used to measure the difference between two probability distributions. and Differences; This reflects the degree to which the actual user activity distribution deviates from the ideal distribution. The greater the deviation, the more likely it is that the menu items frequently used by users are not the high-frequency items the designer intended (for example, deeply hidden menus are used frequently). In this case, the menu structure needs to be adjusted through continuous monitoring. It can automatically detect unreasonable menu layouts after users have used it for a period of time; preferably, the embedded terminal recalculates every 30 seconds or every 10 operations. .

[0032] In one specific implementation, the preset correction trigger condition is: When instantaneous operational entropy The value exceeds the preset upper limit threshold for disorder tolerance. Furthermore, the duration of this threshold-exceeding state exceeds the preset confirmation time window. If the system determines that the current menu structure layout is in significant conflict with the user's actual operating habits, it will trigger the generation process of optimization and adjustment instructions.

[0033] Specifically, This is the upper limit threshold for tolerance of disorder, a positive real number, for example, 0.5 by default. When > At that time, it was considered that the current deviation was too large. To confirm the time window, for example, a preset time span of 2 hours or the time span after 100 cumulative operations, it is required that the state exceeding the threshold continues for more than [a certain period]. Rather than a brief period of time exceeding that limit.

[0034] User actions can be accidental. For example, a deep menu might be heavily tested on a particular day but not used regularly. If optimizations are triggered as soon as the threshold is exceeded, it can lead to frequent prompts and inconvenience the user. By using a time window for confirmation, short-term fluctuations can be filtered out, and only long-term structural deviations will be reported.

[0035] Preset in firmware =0.6, =24 hours (or a cumulative total of 200 operations). The terminal maintains a state machine internally, when... Record the start time when it first exceeds 0.6. ; in subsequent calculations if Still greater than 0.6 and at the current time If the time limit is reached within 24 hours, an optimization instruction will be generated. If the value drops below 0.6, the timer will be reset.

[0036] In one specific implementation, the process of generating optimization adjustment instructions for the current JSON configuration structure includes: Calculate the interaction potential gradient field of each menu item in the currently displayed set. , where menu items are defined The interaction potential energy is , This represents the normalized operation frequency of the menu item. Based on gradient field The direction and amplitude generate specific human-computer interaction prompts: If the gradient field has a positive component exceeding a preset threshold in the direction of decreasing depth, a suggestion is generated to migrate the corresponding high-frequency menu item in the deep layer to the shallow navigation layer. If the gradient field exhibits a dispersion exceeding a preset threshold in its breadth distribution, a suggestion is generated to perform default collapse and hiding of low-frequency menu items. The prompt will be visually displayed the next time the host computer maintenance tool establishes a connection with the embedded terminal, to guide the user in iteratively correcting the JSON configuration file.

[0037] Specifically, this embodiment demonstrates how to generate concrete and actionable optimization suggestions from operational data, rather than simply outputting an entropy value. Specifically, for each menu item... Interactive potential energy , To normalize the operation frequency, which is the proportion of the number of operations on this menu item to the total number of operations on all menu items, compared with the above... The meaning is the same, namely, the deadline. No. The cumulative frequency distribution of user operations on each menu item, but here we are referring to menu items across all display sets. This represents the menu depth. In this formula, the higher the potential energy, the more frequently the menu item is accessed, but the deeper it is. This means that users often have to scroll through many menus to access it, which is unreasonable.

[0038] gradient field The menu tree is viewed as a graph, with each node having a potential energy value. The gradient field describes the rate of change of potential energy in the tree structure. In specific calculations, the potential energy difference between the parent node and the child node can be compared.

[0039] The direction of decreasing depth represents the direction from the deep child node to the shallow parent node. If the gradient field has a positive component exceeding the threshold in this direction (i.e., the potential energy of the child node is significantly greater than that of the parent node), it indicates that the deep menu is more frequently used than the shallow menu, and it is recommended to move the child node (or the entire subtree) to a shallower level.

[0040] The breadth distribution dispersion represents the significant difference in potential energy among child nodes under the same parent node (e.g., one node has a potential energy of 0.8, while other nodes have a potential energy less than 0.1), indicating the presence of extremely high-frequency menu items mixed with a large number of low-frequency menu items. In this case, it is recommended to collapse the low-frequency menu items by default (i.e., place them in a secondary menu or hide them, requiring the user to click "More" to display them) to simplify the main interface.

[0041] This embodiment provides specific operational suggestions for "migration" or "folding", allowing maintenance personnel to quickly optimize JSON configurations without analyzing the original data.

[0042] In one specific implementation, in step 1, the multi-dimensional custom input data also includes operation attribute definitions for menu items, and the operation attribute definitions include at least an editability identifier; In step 3, when the embedded terminal parses the editability identifier of a menu item as being in a prohibited state, it will forcibly disable the parameter input control in the interface corresponding to that menu item, regardless of the current login account's permission level.

[0043] Specifically, this embodiment strengthens the security control of menu attributes, allowing certain menu items to be configured as "read-only", and this restriction is not affected by the login account permissions, making it suitable for scenarios that require strict prevention of accidental operation.

[0044] The editability flag adds a field to the JSON configuration for each menu item, for example, "editable":false. Users generate this flag by checking "Disable modification" using a host computer tool. Forced disabling means that when the embedded terminal renders the interface corresponding to this menu item, all input controls (such as numeric input boxes, dropdown selections, and toggle buttons) are uniformly disabled (grayed out and unclickable). Even if the currently logged-in administrator account cannot modify it. This is because in some industrial applications (such as power protection devices), certain settings, once set, cannot be modified during runtime and can only be changed by the manufacturer through special methods. By solidifying the "non-editable" attribute at the configuration level, it is more reliable than relying on account permissions (account permissions can be compromised or misassigned).

[0045] In one specific implementation, before step 2 is executed, the host computer maintenance tool simulates and constructs a menu topology tree in memory based on the JSON configuration file. If a circular reference or a dangling or isolated node is detected in the topology tree, the error branch is highlighted in the graphical interface of the host computer maintenance tool, and the generation of integrity verification credentials and subsequent file transfer processes are prohibited.

[0046] Specifically, this embodiment adds a preprocessing interceptor to the host computer tool. Before the formal verification and transmission, logical errors are detected in advance by simulating the construction of a menu tree, thus avoiding the distribution of invalid configurations to the terminal.

[0047] The simulated menu topology tree is constructed by the host computer tool reading the JSON configuration and building a tree in memory according to the parent_id relationship, without relying on the terminal firmware.

[0048] A circular reference means that, for example, menu A's parent ID is B, B's parent ID is C, and C's parent ID is A, forming a loop. This structure cannot be properly parsed by a recursive rendering engine, leading to stack overflow or an infinite loop. A dangling orphan means that the parent ID specified by some menu items does not exist in any menu item (and is not the root node), causing these nodes to be unable to be attached to the tree.

[0049] Once the above error is detected, the tool immediately highlights the erroneous menu item or association in red in the graphical interface and displays an error message box. Simultaneously, hash generation (i.e., no verification credentials are generated) and file transfer to the terminal are prohibited (e.g., the "Download" button is disabled).

[0050] This embodiment intercepts errors during the configuration phase, preventing the terminal from repeatedly failing verifications and entering fallback mode, thus improving user experience and configuration efficiency.

[0051] It should be noted that the specific algorithm can use disjoint-set data structure to detect loops, or use Depth-First Search (DFS) to mark access status; when a circular reference is detected, the tool not only highlights it, but also automatically suggests repairs (such as changing the parent ID of a certain item in the loop to 0), and can suggest that users delete or add parent menus for hanging orphaned nodes.

[0052] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for generating and fault-tolerant embedded menus with multi-dimensional custom JSON configuration, characterized in that, Includes the following steps: Step 1: The host computer maintenance tool receives multi-dimensional custom input data for the embedded menu, generates a JSON structured configuration file, and attaches an integrity verification credential calculated based on the file content to the configuration file. Step 2: The host computer maintenance tool performs offline verification on the JSON configuration file. The offline verification includes at least syntax correctness verification, logical integrity verification, and self-consistency verification of the integrity verification certificate. After the verification is passed, the JSON configuration file is transmitted to the target embedded terminal. Step 3: During the startup phase, the embedded terminal loads the JSON configuration file, parses the display filtering field and hierarchical association field contained therein, filters out the set of target menu items to be displayed from the full menu database pre-installed in the terminal firmware, and recursively constructs a tree menu structure based on the hierarchical association field to drive screen rendering. Step 4: If the JSON configuration file is missing before loading or the verification and transmission steps fail, the embedded terminal blocks the parsing of the configuration file and instead calls the pre-set fallback menu data structure in the internal fixed storage area for display, and records the corresponding error information. Step 5: During menu operation, the embedded terminal continuously captures the user's time-series operation behavior data. Based on the degree of matching between the time-series operation behavior data and the menu structure defined in the current JSON configuration file, an interaction state evaluation value is calculated. When the interaction state evaluation value meets the preset correction trigger condition, an optimization adjustment instruction for the current JSON configuration structure is generated, and the instruction is transmitted to the host computer maintenance tool to guide the user to iteratively modify the configuration file.

2. The method for generating and fault-tolerant multi-dimensional customized JSON configuration embedded menus according to claim 1, characterized in that, In step 1, the integrity verification certificate is generated in the following manner: The text string content (Content), Unix timestamp (file creation time), file size (Size), and line count (Lines) of the JSON configuration file are extracted, concatenated sequentially using a one-way hash function, and then a digest value is calculated. The one-way hash function is: The summary value The integrity verification credential is written to the end of the JSON configuration file; the embedded terminal recalculates and compares the credential before loading, and if they are inconsistent, the verification is deemed to have failed.

3. The method for generating and fault-tolerant multi-dimensional customized JSON configuration embedded menus according to claim 1, characterized in that, Step 3, the process of filtering out the set of target menu items to be displayed includes: Determine the total set of all menu items pre-installed in the firmware as follows: The JSON configuration file defines display flags corresponding to each menu item. ; The first stage involves selecting a set of valid identifiers. ; The second stage performs reachability filtering based on the parent-child mapping relationship defined by the hierarchical association fields: if the parent menu identifier specified by a menu item is in the set... If a menu item does not exist in the parent menu and its identifier is not empty, then the menu item is removed from the rendering sequence, ultimately resulting in a display set containing the root node and valid link nodes. .

4. The method for generating and fault-tolerant multi-dimensional customized JSON configuration embedded menus according to claim 3, characterized in that, For multiple sub-menu items under the same parent node, their display order is based on the display priority coefficient defined in the JSON configuration file. Sort in descending order, the display priority coefficient The calculation formula is: in, A positive integer sorting value specified by the user; the smaller the value, the earlier the expected display position. This represents the depth of the menu item within the nested tree structure. and This is a preset positive constant adjustment factor in the firmware; if the calculated values ​​from multiple menu items are... If they are equal, a deterministic decision is made based on the secondary auxiliary sorting field in the JSON configuration file or the default physical storage index.

5. The method for generating and fault-tolerant multi-dimensional customized JSON configuration embedded menus according to claim 1, characterized in that, In step 4, the process of calling the pre-set fallback menu data structure in the internal fixed storage area also includes a hierarchical response mechanism based on error type: The set of error types should include at least the following: missing file, failed credential verification, syntax error, and missing required field. If the error type is file missing, the embedded terminal actively calls the preset generation function to generate a default JSON file based on the full menu database and stores it in the specified path before attempting to reload it. If the error type is credential verification failure or syntax error, the embedded terminal directly skips external storage reading and displays the static menu array mapped in the fixed storage area. If the error type is "required field missing", the embedded terminal calls the completion function to fill the missing field with a preset security default value and then continues to execute the parsing process.

6. The method for generating and fault-tolerant multi-dimensional customized JSON configuration embedded menus according to claim 1, characterized in that, In step 5, the interaction state evaluation value is the real-time operation entropy of the current menu interface. : in, This represents the number of menu items currently visible on the screen. Deadline No. The cumulative frequency distribution of user operations on each menu item; This is an ideal interaction probability distribution derived from the current JSON configuration file structure, whose values ​​are determined by the menu item hierarchy depth. and configure the specified display order Confirmed, satisfied ,and ; This is a preset, minimal positive number smoothing term.

7. The method for generating and fault-tolerant multi-dimensional customized JSON configuration embedded menus according to claim 6, characterized in that, The preset correction trigger condition is: When the instantaneous operational entropy The value exceeds the preset upper limit threshold for disorder tolerance. Furthermore, the duration of this threshold-exceeding state exceeds the preset confirmation time window. If the system determines that the current menu structure layout is in significant conflict with the user's actual operating habits, it will trigger the generation process of optimization and adjustment instructions.

8. The method for generating and fault-tolerant multi-dimensional customized JSON configuration embedded menus according to claim 7, characterized in that, The process of generating optimization and adjustment instructions for the current JSON configuration structure includes: Calculate the interaction potential gradient field of each menu item in the currently displayed set. , where menu items are defined The interaction potential energy is , This represents the normalized operation frequency of the menu item. Based on the gradient field The direction and amplitude generate specific human-computer interaction prompts: If the gradient field has a positive component exceeding a preset threshold in the direction of decreasing depth, a suggestion is generated to migrate the corresponding high-frequency menu item in the deep layer to the shallow navigation layer. If the gradient field exhibits a dispersion exceeding a preset threshold in its breadth distribution, a suggestion is generated to perform default collapse and hiding of low-frequency menu items. The prompt is visually presented when the host computer maintenance tool establishes a connection with the embedded terminal again, in order to guide the user to iteratively correct the JSON configuration file.

9. The method for generating and fault-tolerant multi-dimensional customized JSON configuration embedded menus according to claim 1, characterized in that, In step 1, the multi-dimensional custom input data also includes operation attribute definitions for menu items, and the operation attribute definitions include at least an editability identifier; In step 3, when the embedded terminal parses the editability identifier of a menu item as being in a prohibited state, it will forcibly disable the parameter input control in the interface corresponding to that menu item, regardless of the current login account's permission level.

10. The method for generating and fault-tolerant multi-dimensional customized JSON configuration embedded menus according to claim 1, characterized in that, Before step 2 is executed, the host computer maintenance tool simulates and constructs a menu topology tree in memory based on the JSON configuration file. If a circular reference or a dangling or isolated node is detected in the topology tree, the error branch is highlighted in the graphical interface of the host computer maintenance tool, and the generation of the integrity verification certificate and subsequent file transfer process are prohibited.

Images