Real-Time Knowledge-Based Systems for Enterprise Decision Support and Systems Analysis

Albert M. K. Cheng

Real-Time Systems Laboratory

University of Houston, USA

Motivations Real-time systems must meet stringent timing and

logical correctness requirements, and must guarantee quality-of-service (QoS)

Enterprise information systems (EISs) satisfy meet similar requirements but at a slower and more flexible scale

Economic and organizational impact of EISs require rigorous specification and analysis of these systems

Presentation Outline Introduction to real-time systems (RTSs)

and real-time rule-based systems (RTRBSs)s

Using RTRBSs for decision support Modeling EISs as finite-state systems Modeling EISs as rule-based systems Specification, analysis, and verification

A Real-Time System

A

D

X Y

S

Sensorinput

Decision,action

State

Real-Time Scheduling Earliest-Deadline-First (EDF) scheduler is optimal in

uniprocessor system (or single-person project) EDF scheduler is not optimal in multiprocessor system

(multi-person project) Example: task 1 2 3 (2 processors) deadline 3 2 2 computation 3 1 1 feasible schedule processor 1: 1 1 1 processor 2: 2 3 time: 0 1 2 3…

Multiprocessors: EDF is not optimal

Example (continued):

processor 1: 2 1 1 1 Note: each task must be

processor 2: 3 executed sequentially

time: 0 1 2 3 …

s

Task 1 misses deadline at time 3 (it needs 1 more time unit of computation from time 3 to 4)

Enterprise Information System External inputs (may be from another EIS) Outputs from EIS (may be to another EIS) Communication between internal

components of the EIS Feedback (as external inputs or feedback

inputs) from previous outputs Data organization, mining, and validity

Knowledge-Based SystemsIF condition THEN action/decision

Examples:

OPS5:LHS condition RHS action/decision

EQL: action/decision if conditions

OPS5 Knowledge-Based Systems Set of rules (p rule-name (condition-elem-1) : (condition-elem-m) (action-1) : (action-n)

Database of assertions

(class-name ^attribute-1 value-1)

(class-name ^attribute-2 value-2)

:

(class-name ^attribute-p value-p)

Example: Processing wind-speed information(p wind-scan ; an OPS5 rule

(region-scan1 ^sensor high-wind-speed)

;positive condition element

(region-scan2 ^sensor high-wind-speed)

;positive condition element

(status-check ^status normal) ;positive condition el

- (interrupt ^status on ; negative condition elem

{<Uninitialized-configuration> ;positive condition el (configuration ^high-wind 0 }

-->

(modify <Uninitialized-configuration> ^high-wind 1)) ; action

Example EQL Rule-Based Program(* 1 *) object_detected := true IF sensor_a =

1 AND sensor_a_status = good (* 2 *) []object_detected := true IF sensor_b

= 1 AND sensor_b_status = good(* 3 *) []object_detected := false IF sensor_a

= 0 AND sensor_a_status = good(* 4 *) []object_detected := false IF sensor_b

= 0 AND sensor_b_status = good

Representing EIS as Finite-State Graph for Model Checking

EIS specificationrepresented asa labeledfinite-stateGraph (Kripkestructure)

Safety assertionwritten as temporallogic formula

Is the finite-state grapha model of the temporallogic formula?

Example: EIS for processing bank automated-teller-machine (ATM) transactions (deposit functions only)

System with 2 ATMs Ensure that 2 concurrent deposits to the same

account at different locations yield correct result Solution requires enforcement of mutual

exclusions Notations: N = no deposit

T = want to make deposit

C = making deposit

Example: EIS for processing bank automated-teller-machine (ATM) transactions (finite-state graph spec)

N1,N2

T1,N2

C1,T2

N1,T2

C1,N2 T1,T2 T1,T2 N1,C2

T1,C2

Computation Tree Logic CTL Propositional,

branching-time temporal logic

Next-time operator X, Until operator U

A(E)X f : f holds in every (some) immediate successor of current state

A(E)[f1 U f2] : for every (some) computation path, there exists an initial prefix of the path such that f2 holds at the last state of the prefix and f1 holds at all other states along the prefix

Representing EIS as a Rule-Based System Execution of a rule-based system can be

modeled by a finite-state graph A finite-state graph can derive a rule-based

system An EIS can be modeled as a finite-state-

graph, and hence as a rule-based system

Example: Information on machine operators requiring mutual exclusion in an assembly line

N operators in assembly line 1 assembly unit is shared Each operator spends only a fraction of

time actually assembling components; remainder of time obtaining components and waiting

Ensure only 1 operator using assembly unit

Example: Solution to machine operators requiring mutual exclusion in assembly line (rule-based spec)

PROGRAM mutual_exclusion_algorithm_a;

INIT

request := empty,

ticked := true,

queue_head := empty,

queue_tail := 0,

queue_0 := empty,

:

:

queue_n_1 := empty,

timer := 0

Example: Timing-based solution in EQLRULES(* rules to encode add-request-to-queue operations *)

[] queue_0 := request ! queue_head := 0 ! queue_tail := 1

IF request <> empty AND queue_head = empty

AND queue_tail = 0 : :

[] queue_n_1 := request ! queue_tail := 0 IF request <> empty AND

queue_tail = n-1

Example: continued(* rule to simulate clock tick *)

[] timer := timer - 1 ! ticked := true IF tick = true AND timer > 0

(* rules to encode grant operation to first request in queue *)

[] queue_head := 1 ! timer := (m+l) DIV c1 + 1 ! ticked := false

IF queue_head = 0 AND queue_0 = 0 AND timer <= 0 AND ticked = true : :

Example: Continued[] queue_head := 0 ! timer := (m+l) DIV c1 + 1 ! ticked

:= false IF queue_head = n-1 AND queue_n_1 = 0 AND timer <= 0 AND ticked = true : : :[] queue_head := 1 ! timer := (m+l) DIV c1 + 1 ! ticked

:= false IF queue_head = 0 AND queue_0 = n-1 AND timer <= 0 AND ticked = true : :

Example: continued[] queue_head := 0 ! timer := (m+l) DIV c1 + 1 !

ticked := false

IF queue_head = n-1 AND queue_n_1 = n-1

AND timer <= 0 AND ticked = true

[] ticked := false

IF queue_head = empty OR timer > 0 OR ticked = false

OR queue_head = queue_tail

END.

Analysis of Rule-Based Systems The RULES section is composed of a finite set of

rules each of which is of the form: a1 := b1 ! a2 := b2 ! … ! am := bm IF enabling condition VAR = set of variables on left-hand side of the

assignment, i.e., the ai’s VAL = expressions on right-hand side of

assignment, i.e., the bi’s EC = enabling condition

State Space RepresentationA

D

E F

GH

FP1 FP2

C

L

J

K

B

I

M

N

P

FP3

Problem Complexity In general, the analysis problem is

undecidable if the program variables can have infinite domains, i.e., there is no general procedure for answering all instances of the decision problem.

Proof Outline Any two-counter machine can be encoded by an

equational rule-based program that uses only `+' and `-' as operations on integer variables and `>', `=' as atomic predicates such that a two-counter machine accepts an input if and only if the corresponding equational rule-based program can reach a fixed point from an initial condition determined by the input to the two-counter machine.

Analysis Problem is Solvable for some Cases All the variables of an equational rule-

based program range over finite domains. Set of variables in VAR and set of

variables in VAL and EC are disjoint.

Enabling conditions are mutually exclusive.

Only constants are assigned to variables in VAR.

Compatibility of RulesLet L_x denote the set of

variables appearing in LHS of rule x.

Two rules a and b are said to be compatible iff at least one of the following conditions holds:

(CR1) Test a and test b are mutually exclusive.

(CR2) L_a and L_b are disjoint.

(CR3) Suppose L_a and L_b are not disjoint . Then for every common variable v in L_a and L_b, the same expression must be assigned to v in both rule a and b.

Special Form ALet L and T be sets of variables in VAR and

EC of rules. A set of rules are in special form A if the following conditions hold:

(1) Constant terms are assigned to all the variables in L.

(2) All of the rules are compatible pairwise.

(3) L and T are disjoint.

Example1. a1 := true IF b = true AND c = true 2. [] a1 := true IF b = true AND c = false 3. [] a2 := false IF c = true

Rules 1 and 2 are compatible by conditions CR1 and CR3. Rules 1 and 3 are compatible by condition CR2. Rules 2 and 3 are compatible by condition CR2.

General Analysis StrategyRule-based program

Simpler programs

Rule rewriterState-space analyzer

Special formrecognizer

No independentruleset in special form

Independent rulsetsin special form(s)

Exampleinput: read(b, c)1. a1 := true IF b = true AND c

= true2.[]a1 := true IF b = true

AND c = false3.[]a2 := false IF c = true4.[]a3 := true IF a1 = true

AND a2 = false 5.[]a4 := true IF a1 = false

AND a2 = false6.[]a4 := false IF a1 = false

AND a2 = true

input: read(b, c)

1. a1 := true IF b = true AND c = true

2.[]a1 := true IF b = true AND c = false

3.[]a2 := false IF c = true

Applications of Analysis Tools Cryogenic Hydrogen Pressure Malfunction

Procedure in the Pressure Control System of the Space Shuttle Vehicle

Integrated Status Assessment Expert System

Fuel Cell Expert System Orbital Maneuvering and Reaction Control

System

Ongoing Work Modeling of EISs and other non-rule-based

systems using rule-based analytic techniques Automating this modeling by developing

mechanical encoding algorithms from EIS specification to rule-based representation

Applying real-time scheduling principles to a real Houston company with data-intensive team projects

New Textbook Albert Cheng - Real-Time Systems: Scheduling,

Analysis, and Verification (John Wiley & Sons) ISBN # 0471-184063, 2002. www.cs.uh.edu/~acheng/~acheng.html

For senior-level undergraduate/first-year graduate courses in real-time systems, embedded systems (software and hardware) engineering, and formal methods. Serves as a supplement to courses in operating systems and system design, as well as a reference for practitioners and researchers.