Knowledge-Based Supervisory & Expert Control

Knowledge-based control turns operational expertise into executable decision logic. A rule may state when to change operating mode, which recovery procedure is admissible, how to retune a bounded parameter, or which diagnostic hypothesis deserves the next test. This is not the same job as a fast feedback law: expert reasoning is usually discrete, stateful, and explanation-oriented, so it belongs in a supervisory layer with explicit authority over lower controllers.

Separate knowledge, inference, and actuation #

flowchart TD
  S[Sensors and controller status] --> F[Validated facts and temporal state]
  F --> M[Pattern matching]
  K[Versioned knowledge base] --> M
  M --> C[Conflict set and priorities]
  C --> I[Inference and explanation trace]
  I --> V[Command validator]
  V --> L[Local controller or procedure engine]
  L --> P[Physical process]
  P --> S

The knowledge base contains domain rules and supporting definitions. The inference engine decides which rules are applicable. The command validator enforces authority, units, modes, ranges, and temporal constraints before any selected action reaches the process.

This separation answers three different questions:

• What is believed? Facts, state estimates, equipment modes, and their provenance.
• Why was a decision selected? Triggered rules, priorities, and conflict resolution.
• What may actually happen? Commands allowed by the current control and safety envelope.

Production rules need operational semantics #

A production rule has the form

IF pump_A is running
AND discharge_pressure is low for 5 s
AND suction_pressure is valid
THEN request diagnostic_mode = hydraulic_restriction_check

The natural-language shape hides important semantics. “For 5 s” needs a clock and interruption rule. “Valid” needs data-quality criteria. The action is a request to a mode manager, not an unmediated actuator write.

In forward chaining, changed facts trigger all matching rules. In backward chaining, a goal causes the engine to search for rules and facts that could establish it. Real-time supervisory systems often use forward chaining because plant events arrive continuously, but they must bound the work performed on each cycle.

Conflict resolution is part of the control law #

Several rules may fire simultaneously. An agenda may rank them by:

• safety or authority class;
• specificity of the antecedent;
• explicit priority;
• freshness of supporting facts;
• recency or repetition suppression;
• declared mutual exclusion.

If this ordering is implicit in source-file order or hash iteration, the controller has an undocumented control law. Priorities and tie behavior must be testable and visible in the explanation trace.

Rules require temporal state #

Physical processes do not consist of isolated snapshots. Useful rule systems need constructs for:

• persistence: a condition holds continuously for a duration;
• sequencing: event B follows event A within a window;
• hysteresis: entry and exit thresholds differ;
• debounce and dwell time: repeated transitions are suppressed;
• latching and acknowledgement: a state persists until an explicit condition clears it;
• stale-data handling: a fact expires when its evidence ages out.

Encoding these semantics as ad hoc booleans scattered across rules makes contradictory state likely. A mode or temporal-state machine should own them centrally.

Expert control is strongest at the supervisory level #

Good uses include:

• selecting among already verified controller modes;
• generating bounded setpoints or trajectories;
• coordinating diagnostic tests;
• sequencing startup, shutdown, and recovery procedures;
• recommending operator actions with an explanation;
• choosing which model or estimator is applicable to the current regime.

Weak uses include closing a high-bandwidth analog loop, replacing deterministic protection, or issuing commands whose safety cannot be checked independently.

Knowledge acquisition is an engineering process #

Interviewed expertise is not automatically correct or complete. Capture each rule with:

1. its operational purpose;
2. source and owner;
3. assumed equipment configuration and units;
4. positive and negative examples;
5. interaction with higher-priority rules;
6. expected action and termination condition;
7. revision history and validation evidence.

Two experts may disagree because they assume different operating modes. Making those contexts explicit is more valuable than averaging their rules.

Test the rule space, not only examples #

Scenario replay is useful but cannot enumerate a large rule space. Combine representative traces with static rule analysis, model-based generation of reachable states, and property checks such as “a shutdown request can never be overridden by an optimization rule.”

Explanations are control evidence #

An explanation should record the observation version, rules considered, rules fired, conflict-resolution result, selected action, validator decision, and resulting mode transition. It should not merely restate the final rule in prose.

Knowledge-based control earns its place when decisions truly depend on discrete operational knowledge that conventional equations do not express well. It should coordinate verified mechanisms, not become an opaque path around them.