Generic Task Routine Design

Outline Routine Design Definition. Problem Decomposition & Specialists Hierarchy. Routine Design Agents. Specialist, Plan, Task, Step, Plan Sponsor, Constraint, and Table Matcher. Routine Design Structure. Routine Design Algorithm. Multiple Design Definition. The Differences Between Single and Multiple Designs. Design Tree, Design Limiter, Specialist Selector Interacting, and Table Matcher. Case Storing & Loading. Mapping.

Routine Design Definition It is a problem solver that has been identified for the solution of planning or more generally designed problems. Design Constraints: Set of input attributes. Design Specification: Set of output attributes. Design Constraints Routine Design Design Specification Information processing task of Routine design

Problem Decomposition & Specialists Hierarchy Any problem can be decomposed into a set of simpler sub-problems and each sub-problem can be also decomposed into another set of simpler sub-problems and so on. The Routine design approach is based on hierarchy of cooperating specialists, each responsible for an identified part of a complete design (solving a specific problem). The decomposition of a design problem solver into a hierarchy of specialists mirrors the decomposition of the design problem into sub-problems.

Problem Decomposition Sub-Problem Sub-Problem Problem Problem Decomposition More Conceptual Aspects of the design process Specialist Specialist Specialist More Parametric Aspects of the design process Specialist Hierarchy

Routine Design Agents 1. Specialist Specialist Initial constraints It is a place holder for the design plans and the selection mechanism for selecting among the different plans. One plan is chosen by a selector according to the input data and/or the current problem solving status. The selector consults sponsors of different plans and decides which plan to invoke. Each specialist has a plan selector, a set of plans to choose from, and maybe contains initial and final constraints. Initial constraints Specialist Selector Sponsor Plan2 Sponsor Plan1 Final constraints

2. Plan: - It specifies the course of action to be taken to pursue the design from the current status. It may contains other specialists, tasks, constraints, and other Problem Solvers in an order dependent upon the problem being solved. Specialists Tasks Plan Constraints Problem Solvers

It is a collection of related steps. 3. Task: - It is a collection of related steps. Task Step n Step 1 : 4. Step: - It is the basic design action in Routine Design. It is responsible for setting the value of one design attribute. It maybe uses a table matcher or calls another problem solver. Step Table Matcher Problem Solver OR

5. Plan Sponsor: - 6. Constraint: - Plan Sponsor Table Matcher It determines if its plan is suitable (and how suitable). It tags its plan belonging to one of the following four categories: - Perfect for the current situation. Suitable for the current situation. Not sure. Not applicable for the current situation. Plan Sponsor Table Matcher 6. Constraint: - It is in the form of a comparison between the values of two design attributes. If the result of this comparison is false then the current agent will fail.

6. Table Matcher (Pattern Matcher): - It consists of a set of rows, each row consists of condition side and action side. The condition side is a conjunction form in set of attributes and the action side assigns a value for some output attribute. Action Part Condition Part

Routine Design Algorithm 1. Collect the input attributes and display it. 2. Set the selected attributes in the current case with their values. 3. Invoke the top level specialist. 4. The top level specialist checks its initial constraints (if any exist). 5. The top level specialist requests its selector to select a plan. 6. The selector asks the sponsors of the different plans to assess the applicability of their respective plans. 7. The sponsors examine the current design status and the input data and assign applicability ratings to their plans. 8. The selector examines the applicability ratings and selects a plan. 9. Invoke the chosen plan that will take one or more of the following actions:- (a) Invoke other specialists, then each one will follow a scenario similar to that followed by top level specialist. (b) Execute tasks. These tasks consists of steps each of which a computation or uses a table matcher to assign a value to a design attribute. (c) Check constraints. 10. The top level specialist checks its final constraints (if any exist). 11. Collect the output attributes and display it.

Multiple Design Definition It is an approach for generating multiple designs (solutions) satisfying a common set of design requirements and constraints. Multiple Design Requirements & Constraints Set of Designs Design (Solution) is a set of values for some output attributes.

The Differences Between Single and Multiple Designs Design Database (Tree) For a given set inputs ( design requirements ) a multiple design system generates a group of trees, where each node represents a value for a design attribute. Each path from a root to a leaf node represents a complete design (solution). The Multiple Design deals with the design tree on behalf of the current case to satisfy each design alone. Att1 = V1a Att2 = V2a Att2 = V2b Att3 = V3d Att3 = V3a Att3 = V3b Att3 = V3c A graphic representation of a typical multiple design output

Design Tree Construction Algorithm There are two variables are used in this algorithm. They are Current_Nodes and Current_Agent to store the current nodes and current agent respectively. 1. First, the input attributes branch is built. 2. Current_Nodes = last node in the above branch. While ( Agents Relation is executed ) do step 3. 3. If ( Current_Agent = Specialist ) Then {Pass Current_Nodes to the selected plan in an order. } Else If ( Current_Agent = Plan OR Task ) Then { Pass Current_Nodes to its first item, then the returned nodes from this item are sent to the next item and so on. } Else If ( Current_Agent = Step ) Then { Check each row of Current_Agent’s table matcher against each of the paths ending at the nodes passed to it, adding the result of the row to the paths satisfying the conditions of that row. }. 4. Filter the design tree from input attributes. Design Tree Construction Algorithm

Example: - This example describes how the design tree is constructed. Specialist Plan1 Plan2 Task11 Task12 Task21 Task22 Step111 Step112 Step121 Step211 Step221 Design Tree Construction steps Spec. Call Plan1( [ N1 ] ) Plan1 Call Task11( [ N1 ] , [ N4 ] ) Task11 Call Step111( [ N1 ] , [ N2 , N3 ] ) Task11 Call Step112( [ N2 , N3 ] , [ N4 ] ) Plan1 Call Task12( [ N4 ] , [ N5 , N6 ] ) Task12 Call Step121( [ N4 ] , [ N5 , N6 ] ) Spec. Call Plan2( [ N1 ] ) Plan2 Call Task21( [ N1 ] , [ N7 , N8 ] ) Task21 Call Step211( [ N1 ] , [ N7 , N8 ] ) Plan2 Call Task22( [ N7 , N8 ] , [ N9 , N10 ] ) Task22 Call Step221( [ N7 , N8 ] , [ N9 , N10 ] ) Agents Hierarchy

The Constructed Design Tree Spec. Call Plan1( [ N1 ] ) Plan1 Call Task11( [ N1 ] , [ N4 ] ) Task11 Call Step111( [ N1 ] , [ N2 , N3 ] ) Task11 Call Step112( [ N2 , N3 ] , [ N4 ] ) Plan1 Call Task12( [ N4 ] , [ N5 , N6 ] ) Task12 Call Step121( [ N4 ] , [ N5 , N6 ] ) Spec. Call Plan2( [ N1 ] ) Plan2 Call Task21( [ N1 ] , [ N7 , N8 ] ) Task21 Call Step211( [ N1 ] , [ N7 , N8 ] ) Plan2 Call Task22( [ N7 , N8 ] , [ N9 , N10 ] ) Task22 Call Step221( [ N7 , N8 ] , [ N9 , N10 ] ) N1 N2 N3 N7 N8 N4 N9 N10 N5 N6 Output Design Tree

Design Limiter Definition: - - It is in the form of a table matcher and it is used to exclude the designs (solutions) that are known from experience to not be favorable if other designs exist. It is invoked at two levels, step and task levels. N1 N3 N7 N4 N9 N10 N5 N6

Specialist Sponsor Interacting If (all returned plans within a ranking category fail) Then { The next ranking category are used and so on } If (all plans fail) Then { This specialist will fail } Specialist Selector Set of Plans Call Set of highest category plans

Table Matcher In Multiple Design Condition Part Action Part Example Single Design Multiple Design

New Case Directory Structure Case Storing & Loading Each Problem Solver accesses its current case. So, when we will be storing the Neper’s current case, we must store the other current cases of other Problem Solvers. We changed the case file format to avoid the compiler error and the directory structure that will be used in storing as shown in the next figure. < selected directory> <case name>Neper.case “Neper’s case” <case name>_subs “New Folder” <case name>Planting.case “Planting’s case” . . . . . . . . <case name>Harvest.case “Harvest’s case” New Case Directory Structure Note that:- The selected directory must be ended with “\”.

Mapping It is an important feature that allows the Problem Solvers to interchange the values of their attributes. Example: - Neper Planting Irrigation Input output