This section describes the concept of states analysis and its implememtation in the Oracle Reconstruction Rules.

Reconstruction as a System.
---------------------------

The Reconstruction rules may be tought of as a System, an aggregation of rules so combined programmatically to form an integral whole, or a regularly interdependent group of rules forming a unified whole.  There are two salient features in the latter sentence: first, the Reconstruction rules consist of interacting components (the rules), and, second, the Reconstruction system is associated with a "function" it is presumaably intended to perform.  Further more, the Reconstruction system may be classified as a Dynamic System, that is one where the output generally depends on past values of the input.  Because we have the ability to predict at input time all future behavior of our system, assuming knowledge of the input, the Reconstruction System may be classified as deterministic since its output is not random.

The concepts of state and event.
--------------------------------

The state of a system at a time t describes its behavior at that instant in some measurable way.  The state of the Reconstruction rules constitutes the cornerstone of any modeling or analytical examination of the rules.  With the idea of a system state in mind, we are now in a position to enhance the modeling of the Reconstruction rules.  In addition to providing input variables to theReconstruction system (the names of which rules to execute), we also identify state variables (real numbers) which uniquely describe each rule of the system.  The conbination of the states of all the rules in the system is precisely the state of the system, a unique fingerprint of the system that may be recognize and looked out for.

Since the state of the reconstruction system is naturally described by a discreat set like {0,1,2,...}, and state transitions are only observed at discrete points in time, we associate these transitions with "events" and talk about a "discreate event system".  A Discrete Event System is a discrete-state, event-driven system, that is, its state evolution depends entirely on the occurence of asynchronous discrete events over time.  An event may be identified with a specific action taken (e.g., somebody presses a button); it may be viewed as a spontaneous occurrence dictated by nature or it may be the result of several conditions which are suddenly met.  In the reconstruction rules application, an event should be tought as occuring instantaneously and causing transitions from one discrete state value to another.
The concept of control.
-----------------------

The definition of the Reconstruction system contained the idea of performing a particular function.  In order for such a funtion to be performed the system needs to be controlled by selecting the right input (which rules will execute) so as to achieve some "desired behavior".  For example, in driving a car, we control the position, speed, and accelaration of the vehicle by selecting the right input through the steering wheel and the accelerator and brake pedals.  The desirable behavior in this case is keeping the car on the road a reasonable speed.

To control the behavior of the Reconstruction rules we have assigned a switch to each rule which may be one of two values: 0 or 1.  Before invoking reconstruction one may alter the behavior of a system by manupulating the switch settings of the rules that make up the system.  Only those rules that have a switch setting of 1 will be executed.  Thus the input to the Reconstruction system may be viewed as a control signal aimed at achieving a desired behavior.

The concept of feedback.
------------------------

The idea of feedback is intuitively simple: use any available information about the system behavior to continuously adjust the control input.  Feedback is used in our everyday lives in a multitude of forms.  In a conversation, we speak when the other party is silent and switch to listening when the other party is beginning to talk.  As far as the Reconstruction system is concerned, there are two types of feedback it provides us, upon which we can act.

During an ongoing reconstruction session, messages describing exactly the state of the system are outputed to a file as events occur and these may be continuously monitored to keep abreast of the system state.

Also during an ongoing reconstruction session, the state of each reconstruction rule is continuously posted in a database table appropriate called SYSTEM_STATE.  As table SYSTEM_STATE is being updated, its contents are dynamically plotted through a Graphical User Interface which queries the database at a poll rate specified by the analyst (default system_state poll rate = 10 seconds).  For the precise type of plots provided by the graphical user interface, see the section titled State Space.

State Space.
------------

The state space of a system is the set of all possible values that the state may take.  

Each reconstruction rules has a finite enumerated number of states that it may ever find itself in.  A summarry of the state of all the reconstruction rules and their worded description is stored in table ALL_STATES.  The state of each rule precisely tells us what happened when the rule was executed, or programmatically speaking, what "if block" was true during the rule's execution.  Each reconstruction rule may have no more than nine states (nine "if bloks" that are kept track of), else it is broken down into subrules (nine here represents an agreed upon limit).  

Lets suppose a rule has nine states and at after the rule's execution they are all enumerated as follows from the last state to the first state: 000101010.  As can be noted by this example, each"if block" whithin each rule is assigned a binary integer: 0 or 1.  0 means that no, this block of code was not executed and 1 means that yes, this block of code was executed.  At the end of the rule's execution the above number "000101010" is transformed into an integer that unique describes the overall state of the rule as follows:  

000101010 = 0 x 2 EXP 0 + 1 x 2 EXP 1 + 0 x 2 EXP 2 + 1 x 2 EXP 3 + 0 x 2 EXP 4 +
            1 x 2 EXP 5 + 0 x 2 EXP 6 + 0 x 2 EXP 7 + 0 x 2 EXP 8 
000101010 = 42

Therefore we use a function we call BINTOINT (binary to integer) to covert the individual states whithin a rule to an overall state of the rule.

BINTOINT (abcd) = d x 2 EXP 0 + c x 2 EXP 1 + b x 2 EXP 2 + a x 2 EXP 3

With the above concept in mind, the state space of the Reconstruction system is the combination of all possible integer values that all rules' states may have.  

The Reconstruction system dinamically tracks the following state dimensions: 
    -  a running count of the number number of events that have thus far occured,
    -  the number of the rule that just executed,
    -  the state of the rule that just executed,
    -  the time datetime at wich the rule began executing (to seconds precision),
    -  and the number of seconds elapsed during the rule's execution (to one hundreth of seconds precision).

The above System state dimensions enable us the provide the following six plots of the system stae through a Graphical user interface that appears in the foreground as reconstrution is executing (six types of feedback):
    - event versus rule,
    - rule versus state,
    - event versus state,
    - rule versus use count,
    - rule versus elapsed time,
    - and, current UTC time versus rule.

The combination of all the above plots, along which the specific switch setting of the rules provide a unique fingerprint of the data processed, one that helps in identifiying specific anomalies in data and once recognized, prescribed remedies for the anomalies may be taken.  

When looking at the rule versus state plot for example, one may at the click of a button get the worded description of the state of any rule. 

Reasons for the Reconstruction System state.
--------------------------------------------

Modeling and analysis.  This is the first step toward understanding how an existing system actually works.  We develop a model in order to see if we can reproduce the physical system.  If the model is accurate, we may study the behavior of the system under different conditions, for example, different parameter values or input.

Control.  We may now select the input functions that will ensure the system will behave as desired under a viriety of (possibly adverse) operating conditions.  To test this we need a model we can work with in testing and validating various control approaches we may come up with.  In addition, we need techniques which make the process of selecting the right control as efficient as possible.

Performance evaluation.  After a system has been designed and controlled so as to ensured proper behavior, we may address issues such as "how well is the system really performing?", "what are theexpensive rules in the system and can they be improved?"  

Optimization.  Given that a system can be designed and controlled to achieve some disirable performance, it is natural to ask " how can we control it so as to achieve the best possible performance?" This goal requires the development of additional analytical or experimental techniques for efficiently determining the optimal system behavior and the means for attaining it.
