Hierarchical Workflow Planning With GUI Goal-State Specification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing hierarchical planning methods for technical system workflows are error-prone and lack intuitive graphical support, making it difficult for non-expert users to specify goal states accurately, which can lead to suboptimal or infeasible execution plans.
Innovation Solution
A goal-state-specifying-process using a graphical-user-interface-based approach, where users specify workflow-related goal states through consecutive steps involving initial goal state selection, abstraction level choice, and iterative checking of execution plans, ensuring precise and less error-prone goal state definition.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If manual text file specification of goal states is used, then expert-level precision can be achieved, but the process becomes time-consuming and lacks intuitive support
Solution Approach 1:
A graphical user interface acts as an intermediary between the user and the planning system. The GUI provides visual elements (buttons, sliders, drag-and-drop interfaces) that mediate the complex task of goal state specification, making it more intuitive while maintaining precision through structured data validation and automatic translation to planning domain formats.
Solution Approach 2:
The manual text-based specification process is replaced with a graphical interface system that uses visual metaphors and interactive elements. This substitution transforms the mechanical act of editing text files into an intuitive graphical interaction paradigm, reducing the time required while maintaining specification accuracy through built-in validation and guidance.
2Measurement precision
If a too-detailed model is used for goal specification, then precision is improved, but the planner's degrees of freedom are unnecessarily restricted
Solution Approach 1:
The goal specification system dynamically adjusts the level of detail based on user input and context. The graphical interface allows users to specify only the necessary attributes for their particular task, with the system adaptively determining which parameters require precise values and which can remain flexible. This dynamic approach maintains precision where needed while preserving planner flexibility elsewhere.
Solution Approach 2:
Different levels of detail are applied to different aspects of the goal state specification. The graphical interface enables users to specify precise values for critical parameters (local precision) while leaving other parameters more general or flexible. This local differentiation of quality allows the planner to have sufficient guidance on important aspects while maintaining degrees of freedom for less critical elements.
3Adaptability or versatility
If a too-abstract model is used for goal specification, then planner flexibility is maintained, but undesired end configurations may result
Solution Approach 1:
The graphical interface performs preliminary validation and guidance during the goal specification process. Before the planning execution begins, the system checks the specified parameters, provides feedback on potential issues, and ensures that the goal state definition is sufficiently precise to achieve desired outcomes. This preliminary action prevents undesired configurations by catching specification errors early.
Solution Approach 2:
The system incorporates feedback mechanisms in the graphical interface that inform users about the implications of their goal specifications. The interface provides real-time validation, suggestions for improvement, and warnings about potentially problematic configurations. This feedback loop ensures that users achieve the desired level of precision without unnecessarily restricting planner flexibility.
4Reliability
If hierarchical planning is used to reduce complexity, then feasibility is improved, but optimality may be compromised
Solution Approach 1:
The planning problem is segmented into hierarchical levels, with the graphical interface operating at the upper levels for high-level goal specification and strategic decision-making. Lower levels handle detailed execution and optimization. This segmentation allows feasibility to be ensured at higher levels while optimality is pursued at lower levels, resolving the contradiction between the two objectives.
Solution Approach 2:
The hierarchical planning structure implements a nested doll approach where multiple planning layers are nested within each other. The graphical interface specifies goals at outer layers, which are then refined and optimized in inner layers. Each layer operates within the constraints of outer layers while contributing to overall optimality, allowing both feasibility and productivity to be achieved through the nested hierarchical structure.
Data Source
Figure 1
Figure 2~2A
Figure 2B
AI summary
In order to hierarchically plan executions of operation sequences (OPS1, OPS2) achieving goal states of technical system workflows and checking them through system simulation or hardware execution, by which allowed ranges of goal states before starting the actual planning are specified precisely and less error prone, it is proposed to implement a goal-state-specifying-process (GSSP) for the hierarchically planning and the checking, wherein <1> for a workflow (WF) of a technical system (TS) a workflow related planning domain (PDWF) is given by deploying (dpl) workflow related facts (FCWF), which are based on a digital twin (DT) and each a workflow related set of planning operators, <2> a workflow related goal state (GSWF) is specified (spf) by graphical-user-interface-based inputs of the goal-state-specifying-process given by consecutive steps, <3> a planning task (PT) is defined for the specified goal state and according to the deployed planning domain based on the facts and for at least one selected planning operator of the workflow related set of planning operators, and <4> by a planning approach (PA) according to the defined planning task <4a> executions of the at least one selected planning operator are checked iteratively in order to find a full plan (PLf) comprising first operation sequences (OPS1) to achieve the goal state by a primary query loop until (PQL) the full plan achieving the goal state is found or an error (ERR) of the technical system workflow is reached, and <4b> when in <4a> the full plan is found, the executions of the found full plan achieving the goal state are checked iteratively by a secondary query loop (SQL) until the goal state is achieved.