A low-code-based multi-post personalized digital workbench visual configuration method

Abstract

This invention discloses a low-code, multi-position personalized digital workbench visualization configuration method. This method, centered on the job, builds job templates based on job parameter profiles within a workbench meta-model architecture, supports personalized overlays, uses semantic alias mapping for data binding and decoupling, and links alarm display and handling process configuration. The method includes the following steps: Step 1: Establish a workbench configuration baseline model of job—work target—equipment object domain—page skeleton; generate a job profile parameter set within the framework of the baseline model; Step 2: Construct an equipment object model; establish an equipment semantic dictionary based on the equipment object model; construct a mapping relationship table between the semantic dictionary and data points; and register the real data source for each semantic alias in the semantic dictionary.

Description

Technical Field

[0001] This invention relates to a low-code, multi-position personalized digital workbench visualization configuration method, specifically for building personalized digital workbenches for multiple positions in coal mine electromechanical systems. It belongs to the field of digital workbench construction technology. In particular, it relates to a low-code digital workbench visualization configuration method centered on positions, which, within the framework of a workbench meta-model, builds position templates based on position parameter profiles while supporting personalized overlays. This method uses semantic alias mapping for data binding and decoupling, and links alarm display and handling process configuration. Background Technology

[0002] In coal mine production and operation, the electromechanical system involves multiple professional systems such as power supply, transportation, drainage, ventilation, and hoisting. With a large number of devices, complex operating conditions, and frequent alarms, the system demands high real-time performance, accuracy, and operability from its information system. As coal mine intelligent construction progresses, electromechanical information systems have gradually evolved from single monitoring functions into comprehensive platforms integrating data acquisition, status monitoring, alarm management, operation and maintenance, and decision support. However, in actual production management, there are significant differences in the responsibilities, focus, and operational behaviors of personnel in different positions within the electromechanical system. For example, on-duty personnel focus more on real-time operating status and alarm handling, maintenance personnel focus more on historical equipment trends and fault location, while management personnel focus more on statistical indicators, operational performance, and risk status. This difference in roles necessitates that the electromechanical information system have clear job-specific characteristics in its presentation methods and data granularity. Currently, the digital workbench used in coal mine electromechanical information systems is generally configured as a fixed workbench, typically within the system... During the construction phase, developers design a unified workbench page structure based on common requirements, which remains unchanged long-term after the system goes live. Another type is a parameterized or lightly configurable workbench, which allows control over the content displayed on certain pages through configuration parameters, such as whether to display a certain type of equipment or whether to enable certain alarm modules. However, the overall page structure, data binding logic, and interaction methods are still pre-fixed, and the configuration capabilities are mainly limited to the "switch level" or "list level." These two types of workbench mean that personnel in different positions often face the same or highly similar interfaces, resulting in serious information redundancy and a lack of emphasis on key content for each position, affecting the focus of individual work. Furthermore, existing workbenches are often directly bound to real data sources such as specific location addresses, database fields, or interface parameters. Once the data changes, the page structure and component logic need to be reconfigured. The workbench has low portability and reusability, especially in coal mining systems where positions need to be migrated between different mines, resulting in high costs and poor adaptability.

[0003] Publication No. CN116774977A discloses a design method for a low-code-based coal mine industrial IoT development platform, including: constructing a low-code component toolbox; constructing the technical system of the low-code coal mine industrial IoT development platform; and constructing the architecture of the coal mine industrial IoT development platform. By using visual modeling technology to define the relationships between data, business processing logic, and construct an HMI (Human-Machine Interface), applications can be developed and delivered quickly, and data fusion can be achieved conveniently and flexibly. Publication No. CN118484184A discloses a design method for a low-code-based coal mine workflow development platform. Low-code workflow development includes: a business data model design module, a data interface design module, a visual form design module, a visual process design module, a process engine module, and a function release module. The business data model design module is used to define the business data model; the data interface design module is used to develop the interfaces required for the business; the visual form design module is used to design business forms; the visual process design module is used to design workflows; the process engine module is used to drive the workflow; and the function release module is used to release and deploy the developed functions. The aforementioned patents focus on using low-code platforms for the development and operation of coal mine business processes. The configuration objects are concentrated on data models, interfaces, and process nodes, lacking a configuration mechanism based on job responsibilities. This results in personnel in different positions often facing the same or highly similar interfaces, leading to serious information redundancy and a lack of emphasis on key job-related content, which affects the focus of individual positions. Summary of the Invention

[0004] To improve the above situation, the present invention provides a low-code, multi-position personalized digital workbench visualization configuration method. This method provides a low-code digital workbench visualization configuration method centered on the job, which builds job templates based on job parameter profiles under the architecture of the workbench meta-model, supports personalized overlay, performs data binding and decoupling through semantic alias mapping, and links alarm display and handling process configuration.

[0005] The present invention provides a low-code-based method for visually configuring a multi-position personalized digital workbench, which includes the following steps: Step 1: Establish a workbench configuration baseline model encompassing job roles, work objectives, equipment object domains, and page skeletons. Within this baseline model framework, generate a job profile parameter set. Preferably, the job profile parameter set includes a pre-set set of job types and job target parameters, equipment object domain parameters, and page skeleton parameters defined for each job in the set of job types. Preferably, the job types in the set include, but are not limited to, electromechanical shift workers, power supply shift workers, transportation shift workers, maintenance team leaders, and electromechanical department managers. Preferably, the operational target parameters include, but are not limited to, the scope of attention indicators, key alarm types, common work order types, and typical handling actions. Preferably, the device object domain parameters include, but are not limited to, device system scope, regional scope, key device list, and device grouping rules. Preferably, the page skeleton parameters include, but are not limited to, page set, page layout grid, default component set, refresh strategy, and alarm subscription strategy. Step 2: Construct a device object model, build a device semantic dictionary based on the device object model, construct a mapping table between the semantic dictionary and data points, and register the actual data source for each semantic alias in the semantic dictionary. Preferably, the device object model is defined as {device, component, measurement point / state, event, R}, where R is the set of relationships between the four types of entity elements: device, component, measurement point / state, and event. Preferably, the method for establishing the device semantic dictionary includes: extracting referenceable elements from the device object model, and then generating and registering semantic aliases for each element. Preferably, the referenceable elements include, but are not limited to: measurement points, states, events, and metrics, wherein the metrics are derived from measurement points, states, and events according to actual business rules. Preferably, the semantic alias adopts a segmented structure of domain.device object.meaning. Preferably, while generating and registering a semantic alias for each element, the additional attributes of that element are also registered. These additional attributes include, but are not limited to, data type, unit, recommendation aggregation method, default display time window, and threshold. Step 3: Establish a workbench metamodel. Within the metamodel framework, visualize and configure the digital workbench for each job based on the job profile parameter set, output a job template, allow users to perform secondary personalized configurations on the job template, and output a user workbench instance. Preferably, the workbench metamodel includes at least: a Workspace (workbench instance) submodel, a PageSet (page set) submodel, a Widget (component instance) submodel, a DataBinding (data binding) submodel, an Interaction (interaction orchestration) submodel, a RulePack (rule pack) submodel, a WorkflowLink (workflow linkage) submodel, and a PermissionScope (permission scope) submodel. Preferably, the Workspace sub-model includes, but is not limited to, the workstation's assigned position, assigned user, applicable device object domain, and configuration version information. The PageSet sub-model includes, but is not limited to, overview pages, diagnostic pages, and action pages. The PageSet sub-model defines the page organization structure of the Workspace sub-model. The Widget (component instance) sub-model includes, but is not limited to, component type, page layout position, component attribute parameters, and refresh and subscription strategies. The Widget (component instance) sub-model defines the configuration method for specific display units within the PageSet (page collection) sub-model page. Preferably, the component types include, but are not limited to, trend charts, alarm lists, and to-do cards. The DataBinding sub-model includes, but is not limited to, semantic alias references, data filtering conditions, time windows, data aggregation methods, and threshold reference information. The DataBinding sub-model is subordinate to the Widget sub-model, achieving decoupling between component and data point binding. The Interaction (interaction orchestration) sub-model includes, but is not limited to, page drill-down, component linkage filtering, pop-up triggering, page navigation, and command triggering actions. The Interaction (interaction orchestration) sub-model is associated with the PageSet (page set) sub-model and the Widget (component instance) sub-model, defining the interactive behavior logic under user operations. The RulePack sub-model includes, but is not limited to, trigger conditions, alarm suppression rules, alarm escalation rules, merging rules, and rule configurations associated with handling actions. The RulePack sub-model is associated with the DataBinding sub-model, and performs rule-based processing on the data corresponding to the bound semantic aliases. The WorkflowLink sub-model includes, but is not limited to, interface configurations for work order creation, task assignment, handling review, and result archiving. The WorkflowLink sub-model is associated with the Interaction sub-model and the RulePack sub-model, driving process execution when rules are triggered or user actions are performed. The PermissionScope submodule includes, but is not limited to, device object domain permissions, data field access permissions, and operation behavior permissions. The PermissionScope submodule is associated with the Workspace submodel, PageSet submodel, and Widget submodel, and controls the pages, components, and operations of the workspace at runtime. Preferably, the workbench metamodel adopts JSON or DSL serialization format. Preferably, the user performs secondary personalized configuration on the job template to form a personal overlay layer. Preferably, the personal overlay can only be modified within the authorized scope, which includes at least component sorting, device object domain attention list, threshold subscription, quick action entry, and addition / deletion of page cards. Step 4: In the visual editor of the user workbench instance, introduce the semantic binding wizard and rule orchestration wizard to assist in completing the detailed configuration of data binding and rule linkage, and write back to the meta-model. Preferably, the semantic binding wizard is used to generate DataBinding configurations for Widgets in the workbench metamodel without exposing actual location addresses or underlying fields, etc., which are real data sources. The semantic binding wizard only displays semantic aliases, device objects, and indicator scope items, and automatically filters optional data semantic alias items based on the device object domain parameters and PermissionScope of the job position. Preferably, the rule orchestration wizard is used to generate RulePack configurations in a visual manner, and to generate action reference relationships between Interactions and WorkflowLinks when needed. Step 5: Establish an event-driven closed-loop processing chain for the user workbench. Preferably, the event-driven closed-loop handling process includes: alarm events entering the event access and distribution channel → the user workbench receiving and running alarm events, performing merging, suppression, or escalation according to RulePack → generating handling tasks → generating to-do cards → clicking on the to-do card to link to the corresponding diagnostic page → entering handling records into the form and submitting → writing back and archiving handling records → writing back and updating metrics. Preferably, the generated disposal task is linked to a responsible position or work group. Step 6: Establish a configuration release mechanism for versioned deployment, canary releases, and rollbacks, and establish job-level auditing. Preferably, the versioned release means that each change to the job template or user workbench instance is based on the workbench metamodel to generate a corresponding configuration version number and its corresponding release order. The release order includes at least the change differences, applicable scope, release time, and rollback point. Step 7: When the user workbench is running, it interprets and executes the workbench configuration based on the device object domain permissions and subscription policies, and renders the interpretation and execution results into a workbench interface for the current job and user. Beneficial effects

[0006] First, establish a baseline model for workbench configuration centered on job positions. Under the meta-model architecture, visualize the configuration of the digital workbench for each job position based on job profile parameters. This allows the digital workbench for different positions to be presented differently based on job characteristics, highlighting content related to job responsibilities and avoiding information redundancy.

[0007] Second, bind the data required by the workbench to semantic aliases, and then establish a mapping between the semantic aliases and the real data source. When the data changes, only the mapping relationship needs to be modified, without reconfiguring the page structure and component logic, which significantly enhances portability and reusability.

[0008] Third, through a low-code visual editor, semantic binding wizard, and rule orchestration wizard, non-R&D personnel can adjust and optimize the corresponding workbench within the authorized scope without writing code. Detailed Implementation

[0009] The present invention provides a low-code-based method for visually configuring a multi-position personalized digital workbench, which includes the following steps: Step 1: Establish a workbench configuration baseline model encompassing job roles, work objectives, equipment object domains, and page skeletons. Within this baseline model framework, generate a job profile parameter set. Preferably, the job profile parameter set includes a pre-set set of job types and job target parameters, equipment object domain parameters, and page skeleton parameters defined for each job in the set of job types. Preferably, the job types in the set include, but are not limited to, electromechanical shift workers, power supply shift workers, transportation shift workers, maintenance team leaders, and electromechanical department managers. Preferably, the operational target parameters include, but are not limited to, the scope of attention indicators, key alarm types, common work order types, and typical handling actions. Preferably, the device object domain parameters include, but are not limited to, device system scope, regional scope, key device list, and device grouping rules. Preferably, the page skeleton parameters include, but are not limited to, page set, page layout grid, default component set, refresh strategy, and alarm subscription strategy. Step 2: Construct a device object model, build a device semantic dictionary based on the device object model, construct a mapping table between the semantic dictionary and data points, and register the actual data source for each semantic alias in the semantic dictionary. Preferably, the device object model is defined as {device, component, measurement point / state, event, R}, where R is the set of relationships between the four types of entity elements: device, component, measurement point / state, and event. Preferably, the method for establishing the device semantic dictionary includes: extracting referenceable elements from the device object model, and then generating and registering semantic aliases for each element. Preferably, the referenceable elements include, but are not limited to: measurement points, states, events, and metrics, wherein the metrics are derived from measurement points, states, and events according to actual business rules. Preferably, the semantic alias adopts a segmented structure of domain.device object.meaning. Preferably, while generating and registering a semantic alias for each element, the additional attributes of that element are also registered. These additional attributes include, but are not limited to, data type, unit, recommendation aggregation method, default display time window, and threshold. Step 3: Establish a workbench metamodel. Within the metamodel framework, visualize and configure the digital workbench for each job based on the job profile parameter set, output a job template, allow users to perform secondary personalized configurations on the job template, and output a user workbench instance. Preferably, the workbench metamodel includes at least: a Workspace (workbench instance) submodel, a PageSet (page set) submodel, a Widget (component instance) submodel, a DataBinding (data binding) submodel, an Interaction (interaction orchestration) submodel, a RulePack (rule pack) submodel, a WorkflowLink (workflow linkage) submodel, and a PermissionScope (permission scope) submodel. Preferably, the Workspace sub-model includes, but is not limited to, the workstation's assigned position, assigned user, applicable device object domain, and configuration version information. The PageSet sub-model includes, but is not limited to, overview pages, diagnostic pages, and action pages. The PageSet sub-model defines the page organization structure of the Workspace sub-model. The Widget (component instance) sub-model includes, but is not limited to, component type, page layout position, component attribute parameters, and refresh and subscription strategies. The Widget (component instance) sub-model defines the configuration method for specific display units within the PageSet (page collection) sub-model page. Preferably, the component types include, but are not limited to, trend charts, alarm lists, and to-do cards. The DataBinding sub-model includes, but is not limited to, semantic alias references, data filtering conditions, time windows, data aggregation methods, and threshold reference information. The DataBinding sub-model is subordinate to the Widget sub-model, achieving decoupling between component and data point binding. The Interaction (interaction orchestration) sub-model includes, but is not limited to, page drill-down, component linkage filtering, pop-up triggering, page navigation, and command triggering actions. The Interaction (interaction orchestration) sub-model is associated with the PageSet (page set) sub-model and the Widget (component instance) sub-model, defining the interactive behavior logic under user operations. The RulePack sub-model includes, but is not limited to, trigger conditions, alarm suppression rules, alarm escalation rules, merging rules, and rule configurations associated with handling actions. The RulePack sub-model is associated with the DataBinding sub-model, and performs rule-based processing on the data corresponding to the bound semantic aliases. The WorkflowLink sub-model includes, but is not limited to, interface configurations for work order creation, task assignment, handling review, and result archiving. The WorkflowLink sub-model is associated with the Interaction sub-model and the RulePack sub-model, driving process execution when rules are triggered or user actions are performed. The PermissionScope submodule includes, but is not limited to, device object domain permissions, data field access permissions, and operation behavior permissions. The PermissionScope submodule is associated with the Workspace submodel, PageSet submodel, and Widget submodel, and controls the pages, components, and operations of the workspace at runtime. Preferably, the workbench metamodel adopts JSON or DSL serialization format. Preferably, the user performs secondary personalized configuration on the job template to form a personal overlay layer. Preferably, the personal overlay can only be modified within the authorized scope, which includes at least component sorting, device object domain attention list, threshold subscription, quick action entry, and addition / deletion of page cards. Step 4: In the visual editor of the user workbench instance, introduce the semantic binding wizard and rule orchestration wizard to assist in completing the detailed configuration of data binding and rule linkage, and write back to the meta-model. Preferably, the semantic binding wizard is used to generate DataBinding configurations for Widgets in the workbench metamodel without exposing actual location addresses or underlying fields, etc., which are real data sources. The semantic binding wizard only displays semantic aliases, device objects, and indicator scope items, and automatically filters optional data semantic alias items based on the device object domain parameters and PermissionScope of the job position. Preferably, the rule orchestration wizard is used to generate RulePack configurations in a visual manner, and to generate action reference relationships between Interactions and WorkflowLinks when needed. Step 5: Establish an event-driven closed-loop processing chain for the user workbench. Preferably, the event-driven closed-loop handling process includes: alarm events entering the event access and distribution channel → the user workbench receiving and running alarm events, performing merging, suppression, or escalation according to RulePack → generating handling tasks → generating to-do cards → clicking on the to-do card to link to the corresponding diagnostic page → entering handling records into the form and submitting → writing back and archiving handling records → writing back and updating metrics. Preferably, the generated disposal task is linked to a responsible position or work group. Preferably, the event-driven closed-loop processing chain is implemented by calling various sub-modules of the workbench meta-model. Step 6: Establish a configuration release mechanism for versioned deployment, canary releases, and rollbacks, and establish job-level auditing. Preferably, the versioned release means that each change to the job template or user workbench instance is based on the workbench metamodel to generate a corresponding configuration version number and its corresponding release order. The release order includes at least the change differences, applicable scope, release time, and rollback point. Step 7: During user workbench runtime, the workbench configuration is interpreted and executed based on device object domain permissions and subscription policies, and the interpretation and execution results are rendered into a workbench interface for the current role and user. Preferably, the subscription strategy includes, but is not limited to, semantic aliases, i.e., accessed data, data filtering conditions, time windows, data aggregation methods, etc. In step 7, after loading the Workspace, the workbench first clips the pages in the PageSet and the widgets under each page according to the PermissionScope defined in the metamodel, retaining only the configuration content that is visible and operable to the current user within their job and object domain permissions. Then, based on the DataBinding configuration, semantic aliases, object domain filtering conditions, time windows, and aggregation methods are interpreted as specific data access requests, including historical data query requests for page initialization and data subscription requests for real-time refresh. Then, based on the Interaction configuration, a linkage relationship is established between the page and components, including page navigation, inter-component linkage filtering, drill-down paths, and pop-up triggering, so that users can complete the diagnosis and handling according to the expected path during the operation. Based on the RulePack configuration, the received alarm events are then evaluated according to the rules, thereby triggering corresponding handling actions or linkage processes. After completing the above permission trimming, data binding, interaction mounting, and rule loading, the workbench runtime will interpret and render the execution results into a workbench interface for the current job and user. When the configuration version is switched, the workbench runtime will reload the corresponding metamodel version and take effect immediately without stopping the system.

[0010] The goal is to enable the creation of job templates based on job parameter profiles within the framework of the workbench metamodel, while supporting personalized overlays, data binding and decoupling through semantic alias mapping, and linkage between alarm display and handling process configuration.

[0011] Other similar embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art that are not disclosed herein.

[0012] The above embodiments are preferred embodiments of the present invention. Due to space limitations, the applicant has not used other embodiments, but this is not intended to limit the scope of the present invention. Any person skilled in the art can make some modifications without departing from the scope of the present invention; that is, all equivalent modifications made in accordance with the present invention should be covered by the scope of the present invention.

Claims

1. A low-code-based method for visually configuring a multi-position personalized digital workbench, characterized in that: Includes the following steps: Step 1: Establish a workbench configuration baseline model encompassing job roles, work objectives, equipment object domains, and page skeletons. Within this baseline model framework, generate a job profile parameter set. Step 2: Construct a device object model, build a device semantic dictionary based on the device object model, construct a mapping table between the semantic dictionary and data points, and register the actual data source for each semantic alias in the semantic dictionary. Step 3: Establish a workbench metamodel. Within the metamodel framework, visualize and configure the digital workbench for each job based on the job profile parameter set, output a job template, allow users to perform secondary personalized configurations on the job template, and output a user workbench instance. Step 4: In the visual editor of the user workbench instance, introduce the semantic binding wizard and rule orchestration wizard to assist in completing the detailed configuration of data binding and rule linkage, and write back to the meta-model. Step 5: Establish an event-driven closed-loop processing chain for the user workbench. Step 6: Establish a configuration release mechanism for versioned deployment, canary releases, and rollbacks, and establish job-level auditing. Step 7: When the user workbench is running, it interprets and executes the workbench configuration based on the device object domain permissions and subscription policies, and renders the interpretation and execution results into a workbench interface for the current job and user.

2. The method for visually configuring a multi-position personalized digital workbench based on low-code as described in claim 1, characterized in that... In step 1, the job profile parameter set includes a pre-set set of job types and job target parameters, equipment object domain parameters, and page skeleton parameters defined for each job in the set of job types. The jobs in the set of job types include, but are not limited to, electromechanical shift workers, power supply shift workers, transportation shift workers, maintenance team leaders, and electromechanical department managers. The job target parameters include, but are not limited to, the scope of attention indicators, key alarm types, common work order types, and typical handling actions. The equipment object domain parameters include, but are not limited to, the scope of equipment systems, the scope of regions, the list of key equipment, and equipment grouping rules. The page skeleton parameters include, but are not limited to, the page set, the page layout grid, the default component set, the refresh strategy, and the alarm subscription strategy.

3. The method for visually configuring a multi-position personalized digital workbench based on low-code as described in claim 1, characterized in that... In step 2, the device object model is defined as {device, component, measurement point / status, event, R}, where R is the set of relationships among the four types of entity elements: device, component, measurement point / status, and event. The method for establishing the device semantic dictionary includes: extracting referenceable elements from the device object model, generating and registering semantic aliases for each element, including but not limited to: measurement points, status, events, and metrics. The metrics are derived from measurement points, status, and events according to actual business rules. The semantic aliases adopt a segmented structure of domain.device object.meaning. While generating and registering semantic aliases for each element, the additional attributes of that element are also registered. The additional attributes include but are not limited to: data type, unit, recommended aggregation method, default display time window, and threshold.

4. The method for visually configuring a multi-position personalized digital workbench based on low-code as described in claim 1, characterized in that... In step 3, the workbench metamodel includes at least the following sub-models: Workspace (workbench instance), PageSet (page set), Widget (component instance), DataBinding (data binding), Interaction (interaction orchestration), RulePack (rule pack), WorkflowLink (workflow linkage), and PermissionScope (permission scope).

5. The method for visually configuring a multi-position personalized digital workbench based on low-code as described in claim 1, characterized in that... In step 4, the semantic binding wizard is used to generate DataBinding configurations for Widgets in the workbench metamodel without exposing actual location addresses or underlying fields and other real data sources. The semantic binding wizard only displays semantic aliases, device objects, and indicator scope items, and automatically filters optional data semantic alias items based on the device object domain parameters of the job and PermissionScope. The rule orchestration wizard is used to generate RulePack configurations in a visual manner and generate action reference relationships of Interaction and WorkflowLink when needed.

6. The method for visually configuring a multi-position personalized digital workbench based on low-code as described in claim 1, characterized in that... In step 5, the event-driven closed-loop handling process includes: alarm events entering the event access and distribution channel → the user workbench receiving and running alarm events, executing merging, suppression, or escalation according to RulePack → generating handling tasks → generating to-do cards → clicking on the to-do card to link to the corresponding diagnostic page → handling record entry form and submission → handling record write-back and archiving → indicator write-back and update, wherein the generated handling tasks are bound to the responsible positions or work groups.

7. The method for visually configuring a multi-position personalized digital workbench based on low-code as described in claim 1, characterized in that... In step 6, each version release, i.e., each change to the job template or user workbench instance, generates a corresponding configuration version number and its corresponding release order based on the workbench metamodel. The release order includes at least the change difference, scope of application, release time, and rollback point.

8. A method for visually configuring a multi-position personalized digital workbench based on low-code, as described in claim 4, is characterized in that... In step 3, the Workspace sub-model includes, but is not limited to, the workstation's assigned position, assigned user, applicable device object domain, and configuration version information. The PageSet sub-model includes, but is not limited to, overview pages, diagnostic pages, and action pages. The PageSet sub-model defines the page organization structure of the Workspace sub-model. The Widget sub-model includes, but is not limited to, component type, page layout position, component attribute parameters, and refresh and subscription strategies. The Widget sub-model defines the configuration method of specific display units within the PageSet sub-model page. The component type includes, but is not limited to, trends. The DataBinding sub-model includes, but is not limited to, semantic alias references, data filtering conditions, time windows, data aggregation methods, and threshold reference information. The DataBinding sub-model is subordinate to the Widget sub-model, realizing the binding and decoupling of components and data points. The Interaction sub-model includes, but is not limited to, page drill-down, component linkage filtering, pop-up triggering, page jump, and command triggering actions. The Interaction sub-model is associated with the PageSet sub-model and the Widget sub-model, defining the interactive behavior logic under user operation.

9. A method for visually configuring a multi-position personalized digital workbench based on low-code, as described in claim 4, is characterized in that... In step 3, the RulePack sub-model includes, but is not limited to, trigger conditions, alarm suppression rules, alarm escalation rules, merging rules, and rule configurations associated with handling actions. The RulePack sub-model is associated with the DataBinding sub-model to perform rule-based processing on the data corresponding to the bound semantic aliases. The WorkflowLink sub-model includes, but is not limited to, interface configurations for work order creation, task dispatch, handling review, and result archiving. The WorkflowLink sub-model is associated with the Interaction sub-model and the RulePack sub-model to drive process execution when rules are triggered or users perform operations. The PermissionScope sub-module includes, but is not limited to, device object domain permissions, data field access permissions, and operation behavior permissions. The PermissionScope sub-module is associated with the Workspace sub-model, PageSet sub-model, and Widget sub-model to control the pages, components, and operations of the workspace at runtime.

10. A method for visually configuring a multi-position personalized digital workbench based on low-code, as described in claim 1, characterized in that... In step 3, the workbench metamodel adopts JSON or DSL serialization format. The user performs secondary personalized configuration on the job template to form a personal overlay. The personal overlay can only be modified within the authorized scope. The authorized scope includes at least component sorting, device object domain attention list, threshold subscription, quick action entry, and page card addition and deletion.