Knowledge-Based Action Execution
This page describes Figure 9 of the ADS-IDAC manual: the Knowledge-Based Action Execution flowchart. This process is activated when the Decision Maker (ODM) selects the "Troubleshooting" problem-solving strategy.
Figure 9 from original manual: "Knowledge-Based Action Execution"
Overview
The overall objective of the knowledge-based action execution process is to select appropriate actions based on the ODM's situational assessment. The situational assessment is a diagnostic process that identifies functional degradations in reactor plant thermal-hydraulic processes.
These functional degradations are called Imbalance Events because they are generally associated with mass, energy, or momentum imbalances in the main reactor plant systems. For example, during a loss-of-coolant accident, an operator may perceive functional degradations associated with:
- Maintenance of reactor coolant inventory
- Core energy removal
The KB_ODM_Diagnosis_Actions.txt input file links each imbalance event to a set of potential corrective actions. The ODM selects an appropriate action based on:
- The relative priority of the action
- The status of the prerequisites associated with the action
ODM Exclusive
Knowledge-based reasoning is exclusive to the Decision Maker (ODM). The Action Taker (OAT) does not perform this process. Once the ODM identifies a corrective action, it is issued to the OAT as an ordered activity via the blackboard.
Flowchart
Block Descriptions
Block 1 — Start Knowledge-Based Actions
The knowledge-based action execution process is activated when the ODM selects the "Troubleshooting" problem-solving strategy.
Block 2 — Select Highest Priority Imbalance Event Diagnosis
A search of all Imbalance type diagnosis events listed in KB_ODM_Event_Matrix.txt is conducted to identify the imbalance event with the highest confidence level. This event becomes the primary driver for selecting a knowledge-based corrective action.
Block 3 — Diagnosis Found?
The confidence level of the highest-priority imbalance event must exceed the minimum cutoff level:
Minimum Confidence Threshold
The minimum confidence level is 0.5, hard-coded as highest_confidence in DiagnosisActionModule::getPtrToHighPriorityDiagnosisActionUnit() (DiagnosisActionModule.cpp). It is not configurable from any input file; changing it requires editing the source and rebuilding.
- If the highest-priority imbalance event confidence does not exceed 0.5, no knowledge-based actions are performed and the process terminates.
- Termination in this manner does not preclude future execution of knowledge-based actions if new information increases an imbalance diagnosis confidence above the threshold.
Block 4 — Is Diagnosis Blocked?
Each imbalance diagnosis listed in KB_ODM_Diagnosis_Actions.txt includes a reset delay time. This timer prevents the highest-priority imbalance diagnosis from monopolizing the ODM's attention and blocking response to lower-priority events.
After the ODM selects an action group for an imbalance event, future re-activation of that same imbalance event is blocked until the reset timer expires.
If the reset delay is blocking the highest-priority diagnosis, the process returns to Block 3 to find the next highest-priority unblocked diagnosis. This repeats until either:
- The highest-priority unblocked imbalance event is found, or
- No unblocked imbalance event exceeds the minimum confidence threshold
Tuning Crew Resource Allocation
By adjusting the reset delay time in KB_ODM_Diagnosis_Actions.txt, the analyst can control how the ODM distributes attention between higher- and lower-priority imbalance events.
Block 5 — Select Next Highest Priority Diagnosis
If the highest-priority diagnosis is blocked (reset timer still running), the ODM attempts to select the next highest-priority diagnosis.
Block 6 — Reset Event Diagnosis Blocking Timer
The reset delay timer for the selected high-priority imbalance diagnosis is reset. The imbalance diagnosis is blocked from further activation until the new reset timer expires.
Block 7 — Select Highest Priority Action for Current Diagnosis
Each imbalance event can be associated with one or more possible actions (defined in KB_ODM_Diagnosis_Actions.txt). Actions are assigned:
- A priority level
- Optional prerequisite conditions
During this step, all actions associated with the imbalance event are reviewed and the action with the highest priority is selected. If two or more actions are tied for the highest priority level, the action listed first in KB_ODM_Diagnosis_Actions.txt is selected.
Block 8 — Action Found?
If an imbalance event is not associated with any knowledge-based actions, no action can be executed and the knowledge-based action process terminates for this time step. However, on the next ADS-IDAC time step, if the reset delay allows a different high-priority diagnosis to be identified, an appropriate action might be found.
Block 9 — Is Control at Limit?
Some actions are associated with physical limits that either preclude execution or make the action unnecessary. Examples:
- A control valve that is already fully open — executing an open action would have no effect
- A reactor that has already tripped — executing a reactor trip is redundant
Knowledge-based actions are verified to confirm that execution would result in a change in reactor plant state. If the control is at its limit (no state change would occur), an alternate action is selected (Block 10).
Block 10 — Select Next Highest Priority Action
This block is entered when:
- The current action would not change the reactor plant state (control at limit), or
- The associated prerequisite conditions are not met
An alternate (lower-priority) action is selected and re-evaluated from Block 8.
Block 11 — Evaluate Action Prerequisites
Each knowledge-based action can be associated with a set of prerequisite conditions. All prerequisites must be satisfied before the action can be executed. Prerequisites are evaluated using AND/OR Boolean logic trees.
Prerequisite Logic Trees
Prerequisites can be structured as Boolean AND/OR trees, as illustrated in Figure 17 of the original ADS-IDAC manual. Each leaf node in the tree represents a specific condition (e.g., a parameter value threshold, alarm state, component state, or mental belief). All leaf conditions connected by AND must be satisfied; any one leaf condition connected by OR is sufficient.
Block 12 — Are Prerequisites Met?
- Yes: The action is eligible for execution. Proceed to Block 13.
- No: The action cannot be performed. An alternate action is selected (Block 10).
Block 13 — Execute Action
The selected knowledge-based corrective action is executed. The action is issued to the Action Taker as an ordered activity via the blackboard.
Timing and Control Value Branches
Knowledge-based action execution can generate branches related to:
| Branch Type | Description | Input File |
|---|---|---|
| Action timing branch | Models variability in the time taken to initiate or complete an action | ProcedureActionTimeBranches.txt |
| Control value branch | Models variability in the target value set when manipulating a control | ProcedureControlValueBranches.txt |
When such branches are configured, two or more branches of the same branch type may be generated during a single time step, causing the ADS-IDAC scheduler to split the current accident sequence into multiple paths (generating a DDET branching event). See ADS-IDAC Process Overview – Block 14 for the general branching logic.
Key Input Files
| File | Role |
|---|---|
KB_ODM_Event_Matrix.txt | Defines imbalance events and their classification types |
KB_ODM_Diagnosis_Actions.txt | Links imbalance events to prioritized action packages; specifies reset delay times |
KB_ODM_System_Decomposition.txt | Defines system-level decomposition used in situational assessment |