Citation
A microprocessor-based, graphics-oriented knowledge system for real time EEG analysis

Material Information

Title:
A microprocessor-based, graphics-oriented knowledge system for real time EEG analysis
Creator:
Phillips, David Francis
Publication Date:
Language:
English
Physical Description:
96 leaves : illustrations, charts ; 28 cm

Subjects

Subjects / Keywords:
Electroencephalography ( lcsh )
Expert systems (Computer science) ( lcsh )
Electroencephalography ( fast )
Expert systems (Computer science) ( fast )
Genre:
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Bibliography:
Includes bibliographical references (leaves 57-60).
General Note:
Submitted in partial fulfillment of the requirements for the degree, Master of Science, Department of Electrical Engineering, Department of Computer Science and Engineering.
Statement of Responsibility:
by David Francis Phillips.

Record Information

Source Institution:
University of Colorado Denver
Holding Location:
Auraria Library
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
19719683 ( OCLC )
ocm19719683

Full Text
A MICRDFHXESSCR-BASED, QIAHIICS-CRIENTED
KNOWLEDGE SYSTTM PCR REAL TINE EEE ANALYSIS
toy
DAVID FRANCIS HTITIJPS
B.S.E.E., University of Colorado at Denver, 1986
A thesis submitted to the
Faculty of the Graduate School of the
University of Colorado in partial fulfillment
of the requirements for the degree of
Master of Science
Department of Electrical Engineering and Gcnputer Science
1988


This thesis for the Master of Science degree by
David Francis Fhillips
has been approved for the
Department of
Electrical Engineering and Computer Science
by
Daniel F. Michaels
John R. Clark


Ill
Phillips, David Francis (M.S., Electrical Engineering)
A Microprocessor-Based, Graphics-Oriented Knowledge System for
Real-Time EEG Analysis
Thesis directed by Associate Professor Daniel F. Michaels
Symbolic programming and relevant languages are discussed
with respect to knowledge systems design, graphical data abstraction
and dynamic process implementation. Multitasking and multiprocess-
ing are explored as alternative analysis module design considera-
tions. Recent innovations in EEG medical data acquisition and
analysis units are examined, with particular attention to micropro-
cessor-based real time feasibility, versatility and output clarity.
A Smalltalk/V-based knowledge system for EEG analysis with a graph-
ics-oriented user interface is developed. This final system is
detailed from initial design strategy through simulation, testing
and evaluation of its real-time analysis potential.


uMiuns
CHAPTER
I. INIRODUCITON............................................... 1
EEG Analysis Environment................................. 2
II. TECHNICAL AND HISTORICAL BACKGROUND........................ 8
Symbolic Programming..................................... 8
Artificial Intelligence............................... 14
Search Strategies and Heuristics.................... 14
Frames.............................................. 16
Ihe General Usage Machine........................... 17
Knowledge Systems..................................... 17
Dynamic Processes....................................... 19
Alternative Processing Configurations................... 20
Multitasking.......................................... 20
Multiprocessing....................................... 22
Existing Implementations................................ 24
Microprocessor-Based Data Analysis Systems............ 24
Medical Knowledge Systems............................. 25
Suggested Improvements to Existing Systems............ 28


V
III. A SMAT.TTATX/V KNOWLEDGE SYSTEM.......................... 30
Design Approach......................................... 30
System Configuration................................. 30
Hardware Description.................................. 32
Software Description.................................. 32
Input Module........................................ 32
Analysis Module..................................... 32
Prolog Inference Engine........................... 38
Display Module...................................... 41
User Interface...................................... 43
Automatic Weighting Coefficient Generator........... 45
IV. SYSTEM EVALUATION........................................ 47
Test Results............................................ 47
Display Clarity....................................... 49
Energy Levels......................................... 50
Asymmetries........................................... 50
Time Trends........................................... 51
States, Pathological Conditions and Artifacts......... 51
Operating Speed....................................... 51
Comparison of the Newly Developed System with Previous
Implementations......................................... 52
V. CONCLUSIONS.............................................. 54
BIBLLOGRAFHY.................................................... 57
APPENDICES
A. WEIGHTING MATRICES FOR SELECTED CONDITIONS............... 61
B. SOURCE CODE LISTINGS.................................... 65


vi
TOHTES
Table
1. Human and Machine Analyses of the Test Data............... 48
2. Comparison of Human and Machine Analysis Statistics....... 50


Vll
FIGURES
Figure
1. Time Domain Analysis Output............................... 3
2. Spatial Analysis Output (Compressed Spectral Array)......... 4
3. Power Spectra Analysis Output............................... 5
4. EEG Sensor Layout and Frequency Band Conposition............ 6
5. Selected SmallTalk Class Hierarchy......................... 13
6. Frame Environment......................................... 17
7. Process Visualization Environment........................ 19
8. Multitasking Configuration................................. 21
9. Shared-Memory Multiprocessing Configuration................ 23
10. Block Diagram of the Overall System........................ 31
11. Block Diagram of the Designed System....................... 33
12. Individual Module Procedural Hierarchies................... 34
13. Designed System Display.................................... 42
14. Display with Rulebase Editor Window........................ 44
15. Display with User File Editor Window....................... 44
16. Matrix Coefficient Generator Utility...................... 46


CHAPTER I
nnroDOdicN
The electroencephalogram, or EEG, is one of the most poten-
tially useful tools available to modem medicine and is, at the same
time, one of the most difficult tools to use. Employed in the diag-
nosis of pathological disorders such as epilepsy and tumor, and as
support for the neurologist during surgery, the potential usefulness
of the EEG is not questioned. Interpretations of the data produced
by EEG analysis, however, are argued continually: Expert encephalo-
graphers generally interpret EEGs subjectively, as there is little
standardization in the field. [1] In addition, the numerous methods
available to cbserve EEG data each possess particular advantages,
but none clearly surpasses the others in terms of overall camprdien-
sive utility. In attempting to use many available methods simultan-
eously, the information density generated often reaches a level at
which the observer is inundated by data, usually far too much to be
absorbed at once. Attempting to analyze the data in real time wor-
sens the situation: Real-time analysis not only requires the system
to process the incoming data in real time, but the human observer to
absorb the processed data in real time as well.
Also debated is the practical significance of the data (the
EEG data indicates brain activity of a certain nature in a certain
area, but what exactly does this mean?) as well as whether, once


2
programmed, the human brain will respond to a given stimulus in a
consistent manner.[1]
m developing automated EEG analysis, human experts must
agree over their interpretations of the data: Without this consen-
sus, any medical knowledge system1 interpreting EEG data merely
mimics its developer (and consultant medical experts) and not neces-
sarily the encephalography community as a whole. Since the level of
standardization necessary for general consistency does not yet
exist, the effective analysis system at best will reflect the opin-
ions of a fairly significant portion of the appropriate expert com-
munity. On the other hand, even if an analysis system does not
prove successful or feasible, the attempt itself may aid the stan-
dardization effort.
EEG Analysis Environment
Electroencepha 1 ographic data can be observed in three funda-
mental domains: Time, frequency and space. Time domain analysis is
essentially the direct observation of between four and thirty-two
channels of data, and can yield identifications of temporal inten-
sity trends, eye and muscle artifacts, and temporal interference
effects such as heartbeat and electrode noise. [2] Identification of
frequency trends, longer-term phenomena or the relationships between
symmetric channel pairs is difficult, tut the level of detail at-
1The terms "expert system" and "knowledge system" are often
used interchangeably. The latter term is used in this thesis fol-
lowing the philosophy that the system does not actually "think" as
an expert, but merely makes inferences based upon the available
knowledge base.


3
tainable with direct observation is often desirable, even though the
output from this type of observation is often cryptic, as seen in
figure 1:
Figure 1= Tiro nmrn'n analysis Output
(Courtesy D. F. Wunk[33])
Frequency domain analysis involves transformation of the
data from each electrode into its component power spectra, commonly
plotted in a compressed spectral array, or CSA. This type of output
displays both time and frequency data on the same screen, but is


4
often difficult to interpret and, as with time domain analysis, does
not easily permit comparison of the asymmetric channel-pair rela-
tionships that are often significant.
Spatial analysis employs compressed spectral arrays and
histograms to detect spatial relationships between channel-pairs,
but information about frequency-band content is often difficult to
interpret in these output formats. Figure 2 displays a ccirpressed-
spectral array output:
Gain: 100 E0F* aihazell.ave Tine 1:48: 0
0 4 8 12 16 4 8 12 16 4 8 12 16 4 8 12 16 hz
Ch. 1 Ch. 5 Ch. 3 Ch. 7
Figure 2: Spatial Analysis Outpit(Oc (From D. F. Wtink[33])
The power spectra can be divided into frequency sub-ranges,
or bands (usually four to eight), and the power over each band
integrated. [3] This results in one discrete value for each band
defined per channel, and consequently a much smaller amount of data


5
to assimilate. Unfortunately, much detail is lost, but comparisons
between symmetric channel-pairs are simplified, as seen in figure 3.
Figure 4 illustrates both a typical bipolar electrode montage and a
canmon four-band frequency division scheme. While the loss of
detail prevents certain observations, enough information is retained
to identify many time- and frequency-related trends, with a minimum
of computational overhead.
EEG data are occasionally time averaged to identify the
longer-term EBG trends encountered. Detail is again lost, but the
effects of erratic signal behavior are reduced.
Figure 3: Rawer Soectra Analysis Output
(Courtesy D. F. Wurik[33])


6
Figure 4; (a)EPE Spnsnr Tavraifc and fb)Frequency Rand (Traprrei-Hcgl
Each of these analysis methods possesses both strong and
weak points, and the use of a combination of these methods is usual-
ly advantageous. Unfortunately, this combination often leads to the
extremely high information density referred to earlier, and another
approach needs to be considered: The goal of an observation method
is to abstract the raw data toward certain purposes, and a system
needs to be developed to further abstract this already transformed
data into a format immediately comprehensive. This system should
not only display all relevant raw data, but should make decisions
concerning the significance of observed relationships so as not to
burden the operator by displaying large amounts of unnecessary
information.
In this thesis a microprocessor-based medical analysis
system is developed, incorporating the data abstraction capabilities
mentioned above, and designed to operate in real time. Chapter II
explores the software and hardware alternatives that have been
considered in this development, as well as a sampling of previously
developed systems and suggested improvements to those systems.
Chapter III describes the design approach used in the proposed
system and includes a detailed analysis of the software developed.
Chapter IV provides test results and an evaluation of the perfor-


7
nance of the designed system, with comparisons to previously devel-
oped systems. Chapter V presents conclusions based on the test
results, and suggestions for further development directions for the
designed system.


CB&HLKK H
TECHNICAL AND HISTCRICAL BACTORCUND
Symbolic Proarammiro
In designing knowledge systems, list processing and symbol
manipulation are generally encountered more frequently than arith-
metic operations, although seme applications can be computationally
intensive. Consequently, specialized languages have evolved to
manipulate symbols more efficiently than conventional programming
languages. Lisp, Prolog and Smalltalk are the most common of these
symbolic languages, each with its cwn technique for expressing a
particular problem. For example, an algorithm to determine whether
a given object is contained in a given list of objects might be
coded in Pascal as a function:
function mother (atom: symbol; list: list_of_symbols): boolean;
var i; integer;
begin
for i := 1 to size (list) do
if atan = list[i] then member := true;
member := false;
end;
This function advances through "list"1 and attempts at each
iteration of "i" to equate "atom"* 2 with the indexed list element.
The Pascal requirement for strict variable typing presents an obsta-
^The function "size" is assumed to exist here for clarity.
2,,Atcm" is the common notation in symbolic languages for a
single data element.


9
cle here: The data type of both "atari" and the list must be rigidly
specified, and these types cannot be changed at a later time.
The most commonly used symbolic language is Lisp (for list
Processing), a recursive list-processing language, developed with
the goal of abstracting list data structures for easier manipula-
tion. Notational convenience and computational functionality are
not necessarily related, but the ability to easily code applications
and experiment with them adds greatly to the understanding of the
application itself. [4] The "member" algorithm earlier defined in
Pascal could be implemented as a Lisp function[5]:
(defun (member (atan list)
(card ( (null list) nil)
((equal atom (car list)) t)
(t (member atom (cdr list)) )
))
Slightly cryptic at first, the function merely advances through the
list and attempts to successfully evaluate "atom" and the element at
the head of the list to the same expression, two advantages of the
Lisp function over its Pascal counterpart are immediately evident:
(l)the list size is not needed, as the function merely continues
recursively until the list-end is encountered, and (2) "atan" and
"list" can be any conbination of character, integer, real data type
or even a structureLisp only compares the form of the variables,
not their specific type or value.
A popular alternative to LISP is Prolog (for FPOgramming in
LOGic), another recursive language, more natural than LISP in its
approach to program coding. This language incorporates a built-in


10
backtracking mechanism to direct program execution. [6] "Member"
could be implemented as a Prolog procedure[7]:
member (atan, [atan|_]).
member (atom, [_| rest_of_list]) member(atan,restjof_list).
While similar to Lisp in recursive mechanics, Prolog code provides a
more intuitive look at the problem: If "atom" does not match the
first element of the list, the first "clause" fails, and the second
clause is attempted with the rest of the list until a match is found
or the list is exhausted.
Another advantage of Prolog is the ease with which the
clauses of a procedure can be arranged in a hierarchical fashion,
streamlining the program flow and reducing needless computation. As
in Lisp, list size and the types of the atom and list contents need
not be kncwn in advance. Prolog "instantiates", or binds, "atom" to
one temporary variable, the list element to another, and attempts to
"unify", or equate, the two. It should be noted here that both
"atom" and the list element do not have to be instantiated at all at
the point of the unification attempt; identical structure (or lack
of structure) is sufficient for unification success.
Although recursive languages generally allow much simpler
expression of list and symbol processing procedures, recursive
processes engender their own peculiar difficulties: Sequential pro-
cedures use only the stack and program memory necessary for local
amputation, but recursive algorithms, to allcw for later backtrack-
ing, must store all the information from virtually every step of a


11
search path until the algorithm has terminated.3 Recursive al-
gorithms will therefore rapidly exhaust all available memory unless
they are carefully controlled. [9]
Compromise must be reached in every application, and in many
cases the best solution is to link math-intensive tasks written in a
language such as C with more symbol-oriented and less efficient
tasks written in a language such as Prolog. In this way, the natur-
al symbolic expression found in Prolog is exploited as is the effi-
cient computational ability and compact execution code generation of
C.
One such "hybrid" system is Smalltalk 80, an object-oriented
programming environment. Smalltalk/V, a virtual memory-based ver-
sion of Smalltalk 80 developed for microcomputers, also incorporates
as an option a Prolog engine containing a superset of the Edinburgh
standard. [10] In this environment, math-intensive tasks can be
coded in Smalltalk/V's Pascal-like syntax, while more symbol-
oriented tasks can be coded in Smalltalk/V1 s Prolog. Procedure
calls, or "messages", from one language to the other are easily
implemented. While the Smalltalk code resembles Pascal, with cor-
responding variable declarations, the variable type and structure
are "dynamically bound": They can be changed at any point in the
algorithm, eliminating the strict variable-typing drawbacks of
Pascal.
3There are exceptions, for example the "cut" feature of
Prolog, which truncates the fail-point stack and reduces the impact
of recursive stack-building.[8]


12
Developed in the 1970s, Smalltalk provides extensive control
over graphics, I/O and program development, and is actually a pre-
decessor to the Apple Macintosh interface. Individual methods are
incrementally compiled upon integration into the environment, while
the top level of this windowing environment operates as an inter-
preter. The environment interacts directly with the programmer, but
the operating speed is less than optimal; the entire environment
must be present to run any partwith its corresponding operating
overhead. [11] Incremental compilation, however, provides that only
the method being currently developed need be recompiled after every
modification, making program development less time-consuming and en-
couraging very modular program construction.
Objects in Smalltalk are similar to records in Pascal,
containing variables and a structure, but Smalltalk objects also
contain the methods used in the performance of that object, calls to
other methods, inherited characteristics and local knowledge.[12,13]
Class inheritance is clearly defined in Smalltalk: While
clause hierarchy in Prolog essentially allows one procedure to
"inherit" the attributes of other procedures higher in the program
hierarchy, this inheritance is implicit: Only characteristics
passed in the procedure call statement are inherited. Figure 5
shews a significant subset of the Smalltalk class hierarchy with the
Prolog and multiprocessing extensions, and the special classes added
for the system developed in this thesis. Smalltalk methods are in-
stalled explicitly into the class hierarchy and inherit formally
defined characteristics, class variables and methods. Even in the



t
Object
BitBlt
CharacterScanner
Pen
Boolean
True
False
ClassHierarchyBrowser
1---LogicBrcwser *-----
----Dispatcher
I---GraphDispatcher
---- ScreenDispatcher
1---TopDispatcher
DisplayObject
1---DisplayMedium
1---Form
1---ColorForm
Dos <-------------------
FFK <--------------------
Non-Standard
----EEGdisplay *-
----EEGexpert *
'---EEGgenerate-*-
File
logic
Prolog
1---EBGruleBase *----
Magnitude
I Character
'---Number
1---Integer
1---Smalllnteger
Menu
Pane
SubPane
I---GraphPane
*- TextPane
TopPane
ErocessScheduler *------
Prompter
Rectangle
Semaphore
Stream
I---WriteStream
'---FileStream
Figure 5: Selected Small TalV (Tlas-c: Hierarchy
(Adapted from Goldberg and Robson[11], p.14)


14
Prolog engine of Smalltalk classes can be defined as subclasses of
other classes, rigidly determining inheritance: From figure 5, it
can be seen that EEGruleBase inherits from Prolog which in turn
inherits from Logic which inherits from the superclass Object.
Artificial Intelligence
Artificial intelligence is a strategic implementation of the
appropriate software: An artificially intelligent piece of software
by definition exhibits behavior that emulates human reasoning. [14]
search strategies and Heuristics. At the simplest level, an
artificially intelligent application, or production system, is sub-
ject to certain control regimes. These regimes fall into two basic
categories: (1) irrevocable regimes which allow only deterministic
solutions, and (2)tentative regimes which permit the local selection
of a search path but reserve the ability to backtrack and redirect
the search direction at any point. Of the two, tentative control
strategies are most commonly used because of the flexibility they
contribute to a production system. These strategies can take the
form of straightforward pattern-matching algorithms, backtracking
algorithms, hill-climb strategies or graph-search algorithms, each
with its own particular strengths. [8]
These strategies are all known as "uninformed" search stra-
tegies: Given a basic criteria to satisfy, they can proceed along a
search path making use of the local knowledge at any given point,
but they can make no assumptions based on "global knowledge" (or the


15
larger picture) to select a perhaps more efficient route to the
intended goal. Higher-level, "informed" evaluation strategies are
called "heuristic" algorithms, and separate artificially intelligent
production systems fron sirrple pattern-matching algorithms. For
example, if each step tcward the satisfaction of a certain goal
includes with it a known cost, and a minimal total cost is desir-
able, an heuristic algorithm might compute the cost of all currently
explored search paths, extrapolate each path cost to the intended
goal thereby estimating the total cost of that path, and select the
next step along the search path that minimizes the total cost es-
timate. While an uninformed search algorithm might be able to
decide, at each individual step, the most cost-efficient next step,
it would be unable to take a less efficient step for the sake of
later minimizing the total cost of the search. [14]
These heuristic algorithms combine a variety of depth-first,
breadth-first and other search strategies to select the most advan-
tageous path while the search is progressingunlike algorithms that
exhaustively explore every possible search path and then select the
most optimal path foundso-called "plodding" procedures, which are
generally useful only when time, cost and memory are not considered
valuable. [14] In fact, many critics claim that the majority of the
popular heuristic algorithms such as A*, AD*, B*, afi or minimax are
of limited value, contending that, while a certain algorithm might
prove effective in a specific application, none of the algorithms'
apparent benefits cure supported by theoretical models. [15,16]


16
Shrewdly selected heuristic methods in a data analysis sys-
tem can direct the system to explore only areas of the data deter-
mined to be interesting, but the benefits of these methods must be
weighed against the overhead required for heuristic decision. In
the system designed for this thesis, the normal depth of the search-
path is insufficient to justify extensive heuristics, but the use of
limited heuristic techniques improves system efficiency.
Frames. Kncwledge-based system data structures can be
extended beyond simple lists into "frames", or domain-sensitive
representations. These frames not only provide a clear representa-
tion of the data but support search and analysis algorithms that
make special use of the frames' context-sensitive information;
frames are, in fact, a form of class inheritance. Each frame con-
tains slots defining specific attributes, behavior or even a proto-
type description of the frame identity. [17] These slots are easily
accessed by search algorithms because of their highly organized
information format.
Frames can be easily implemented in Smalltalk (or already
are implemented in a sense), since the class hierarchy of Smalltalk
closely resembles that of frames and slots. A class (or object) in
Smalltalk resembles a frame, and a slot in Smalltalk takes the form
of an instance variable, while attributes are equivalent to
methods.[18]
Figure 6 represents the frame-slot-attribute relationship in
the Smalltalk class hierarchy. Frame-based systems generally use


17
less code to implement an application. Since the analysis system
designed for this thesis is intended to function in real time, the
more efficient frame-based relationships of Smalltalk are desirable.
OBJECT
(class)
I-------1------1

ATTRIBUTE DICTIONARY
(method) (pool dictionaries)
I-------1---------1
T
FRAME SLOT
(class) (instance variable)
Figure 6: Fran** iftnHrcnpent
(Adapted fran Rettig[18], p.16)
The General Usage Machine. Although most of the attention
on artificial intelligence has been focused upon software develop-
ment, AI hardware has also undergone seme major design and philos-
ophy changes: While until recently hardware tended to be manu-
factured specifically for the application at hand, hardware devel-
opers are new exploring the "general usage machine", one that will
perform most tasks well enough to justify its use over faster and
more efficient, but more expensive, specialized machines. Such a
machine would certainly be more flexible and less expensive than its
single-task counterparts, although it would not be able to perform
seme specific tasks as efficiently as those counterparts.[19]
Knowledge Systems
A knowledge system is an attempt by computer systems to emu-
late the reasoning of human experts in a specific field. It follows


18
that the human reasoning process must be explored first. Knowledge
acquisition has in fact become as sophisticated as that of knowledge
system design. This process tends to be a circular one, the know-
ledge engineer acquiring knowledge, gradually developing a percep-
tion of the process and gaining a better viewpoint from which to ask
further, better informed questions, acquiring further knowledge. [20]
Knowledge acquisition has become formalized in seme cases:
Cook and McDonald[21] suggest that many of the problems inherent in
the knowledge acquisition process might be overcome by more formal
procedures. Not only are some processes poorly communicated verbal-
ly, but the interpretation of the expert by the knowledge engineer
is necessarily subjective. Human experts often organize their
knowledge differently than do novices, and this expert knowledge may
not easily take the form of the "if-then rules that are the founda-
tion of most current systems.
Gaps in this knowledge base often cause a system either to
crash or to provide erroneous output when attempting to perform at
the extreme limits of its ability. Contributing factors are (l)the
lack of "deep knowledge", or rules and facts defining the underlying
principles concerned and (2) inability of the system to detect when
it is approaching the limits of its knowledge base and intended
inferencing domain.[22] This lack of deep knowledge is often over-
looked by system developers because the addition of deep rules and
facts would be too costly, or because the problem being addressed is
too ill-defined or little understood to provide the deep knowledge
in the first place.


19
Dynamic Processes
When discussing real-time applications, dynamic processes
must be considered. Graphical presentations are most frequently
used for displays, since they are symbolic by nature and easily
interpreted, and these displays must be updated dynamically. [23]
If a process is dynamic, it must be able to change effi-
ciently: Seme means must be vised to sense what part of a display
must be changed, and then to change only that part. Otherwise, the
entire display is overwritten every update cycle, a waste of memory
and processing time. Typical display changes include color, loca-
tion and labelling of a area of the display. A common dynamic
process view is diagrammed in figure 7:
Figure 7: Prooefig vigniizaticn Envircrment
(Adapted from Foley and McMath[23], p.17)
The dynamic process accesses a database of the variables
that are occasionally updated, as well as their location and present


20
state. These variables are changed and flagged as changed by other
processes when necessary. As the visualization process scans the
database, it determines which variables have changed and updates the
process view, which is in turn observed via the user interface.
Real-time applications must address difficulties of their
own peculiar nature. Frame notation is often considered here since
it provides a very efficient data-system interface. The knowledge
system should identify and access only the rules and facts that
apply to a given situation, eliminating costly searches of non-
relevant areas of the knowledge base.[24] Control strategy is, in
fact, the current primary focus of real-time optimization techni-
ques. [25]
ATrTRRNATTVF PROCESSOR CONFIGURATIONS
While microprocessor-based systems are rapidly increasing in
speed and process-handling ability, there are occasions where this
speed is not sufficient in itself; more innovative programming or
processor configurations will greatly improve the performance of a
given system under suitable conditions. [27] Explored here are
multitasking executives and multiprocessor hardware configurations.
Multitasking.
Multitasking is the apparently simultaneous performance by
one processor of several tasks, or processes. While several tasks
are performed in tandem, only one task is actually performed at any
given time. [28] A configuration for a multitasker is diagrammed in


21
figure 8. Once a process has been started, it enters a queue and
awaits activation. Upon activation, a process retains control of
the processor until it either voluntarily yields that control (in a
non-pre-emptive multitasker) or is blocked by the CHJ (in a pre-
emptive multitasker). Upon suspension, a process re-enters the
queue and resumes waiting for its next turn.4
Figure 8; Mhl-HtasirinfT Configuration
Pre-emptive, or time-slicing, multitaskers allocate prede-
termined amounts of processor time to each process without actually
relinquishing irrevocable control to that process. Non-pre-emptive,
or dedicated, multitaskers will actually allow a single process to
retain control of the system until it is completed, unless that
process voluntarily returns to the queue and allows the next process
to be serviced. Tasks relinquish control at "yield-points" so that
all tasks are ensured of being processed. Yield-point placement can
4Same multitaskers allow different tasks to be assigned dif-
ferent priorities, and a task at the head of the queue is activated
only if all waiting tasks are of the same or lcwer priority.


22
greatly affect the overall performance of the system: Infrequent
placing of yield-points results in poor performance of seme tasks,
while placing yield-points too frequently allocates an inordinate
amount of time to queue processing, context switching, etcthere is
a fair amount of operating overhead in a multitasker.
Processor speed must be considered in the decision to lose a
multitasking executive: While several tasks are performed at the
same time, the processing times for all tasks being performed add
up, potentially resulting in slower performance of each task than
would be optimal.
Multiprocessing
An alternative to a multitasking system is the use of
several "coprocessors", each coprocessor performing its designated
task, exchanging data as necessary (as opposed to a parallel proces-
sing arrangement, where a single task is portioned out to several
coprocessors [28-30]). A typical multiprocessor configuration is
displayed in figure 9.
Shared-memory multiprocessing configurations allcw each
coprocessor access to a common memory area, allowing easy exchange
of data. Scone multiprocessors also provide a small memory "cache"
for scone coprocessors for their exclusive use, either for organiza-
tional advantages or because a particular coprocessor requires high-
er-speed memory than does the rest of the system.
While the interconnection and synchronization of such a
system is more complicated than it is with a multitasker, this


23
approach significantly reduces the load on the CHJ and each of the
coprocessors. Another advantage of this configuration is the
ability to make use of highly specialized coprocessors, such as
high-speed graphics, data acquisition or signal processing subsys-
tems, greatly increasing the performance of the overall system. The
disadvantage is the hardware complexity involved, making this choice
feasible only if the task to be allocated to a coprocessor is suffi-
ciently important or time-consuming to justify the added complexity.
|| Central ||
* Processing *
II anlt I
Graphics
Processor
li T Til
-------------- Main Memory *-------------------
11 11
Figure 9: gviTBdrHFmnrv ifciltinmnpBsincf Configuration
From the discussion above, it is apparent that a combina-
tion of the appropriate techniques would benefit any system requir-
ing speed and flexibility. For example, a multitasker could be
implemented on a CHJ, juggling memory management and housekeeping
routines, while more important, time-consuming or speed-intensive
tasks such as graphics and signal processing could be delegated to
coprocessors. Appropriate languages should also be chosen for both
speed and convenience.
Data
Acquisition
Processor
-------a-----
Floating
Point
Processor
----A------


24
EXISTING IMPTrMHJTWTTfiMS
Several systems have been implemented for EEG analysis, both
in microprocessor-based architectures and on mainframes. These
systems range from relatively simple data acquisition systems to
full-fledged knowledge systems capable of rendering diagnoses based
upon the data acquired. While the focus of this thesis is upon
microprocessor-based systems, attention is also given here to mini-
computer- and mainframe-based systems, since these possess levels of
sophistication previously attainable only on larger machines, but
new available on microprocessors. The following is a representative
sampling of systems developed to date:
Microprocessor-Based Data Analysis Systems
An example of a microprocessor-based EEG processing unit is
the system developed by D.F.Wunk[33] in 1985 using a standard IEM
PC-XT running at 4.77MHz and a coprocessor subsystem built using a
Texas Instruments TMS32010 reduced instruction-set chip. This
system is capable of computing a 256-point complex FFT every 8
seconds, processing frequencies from 0-16Hz. Outputs are available
in real-time or playback modes, where the real-time node allows user
observation of the processed data in a compressed spectral array,
printing of the processed data, or disk storage.
While this system is very fast in data processing, addi-
tional options for more advanced analysis are limited. The com-
pressed spectral array provides excellent frequency trend identifi-
cation, but there is no provision for automatic identification of


artifacts, anomalies, etc. This system could be used as a prepro-
cessor or coprocessor in a more comprehensive analysis system.
25
Medical Knowledge Systems
When developing an EGG analysis knowledge system, the first
obstacle to be overcome (after the choice of hardware and programm-
ing languages) is the selection of data structures; data must be
organized in an efficient manner to be efficiently processed.
Two fundamental approaches are encountered most often in EEG
expert systems: (1) systems that scan the data for a feist, surface
interpretation, emulating the way an encephalographer might make an
initial evaluation, and (2) systems that are stochastically inten-
sive, with methods ranging from autocorrelation analysis to autore-
gressive modeling. Data is also modeled as a string and syntac-
tically analyzed with string and character manipulations. [34]
As stated before, in evaluating the performance of a know-
ledge system, the conformance of the system analysis to the response
of a group of human experts is a measure of effectiveness; regard-
less of hew accurate the interpretation of a knowledge system seems,
it should agree with a large number of humans expert in the area
targeted by the system. In EEG analysis, an 89% conformance rate
among human experts is a considered excellent [1], therefore any
figure above this in a knowledge system is not relevantit merely
indicates that the system agrees closely with the opinions of its
designer, and not necessarily the medical community concerned as a
whole. Since medical systems are especially useful in borderline


26
analyses because of their consistency, this conformance is all the
more important.[35]
A knowledge system designed by J.R.Boume et.al. [36] in 1980
involved a nationwide effort to acquire data from renal patients and
provide a quantitative set of guidelines for treatment. The system
was implemented on two PDP-11 minicomputers and written in C. Each
computer was assigned specific tasks, in a multiprocessor configura-
tion: A PDP-11/34 was used for data processing and management, and
a PDP-11/03 was assigned sampling duties. The C programming lan-
guage was selected because of its high speed and compact code gener-
ation. This system does not operate in real time, its primary
purpose being to compile data from nationwide centers and produce
quantitative dialysis treatment guidelines from that data. Three to
four EEGs were processed per hour, identifying slewing, average peak
frequency and seme artifacts. No conformance figures were given for
this system.
With a different group, Bourne[37] developed a syntactical
analysis system. In this system, pewer spectra of the data are
classified into a set of token character labels. Spatial and tem-
poral characteristic analyses, as well as some stochastic analyses,
are implemented, with the output printed on a representation of the
original EEG machine output. Again, this system does not operate
real-time, but its analysis repertoire is superior to the earlier
implementation. Conformance figures are not given for this system
either.[36]


27
With still a different group, Boume[38] in 1983 continued
research into semantic evaluation with the Semantic EEG Evaluation
Regimen, or SEER-1. This system, running on a VAX11/750 and written
in Franslisp, has achieved the very high conformance figure of 79%
with human experts. While the Lisp code is far less efficient than
C, its greater built-in list processing capabilities and the faster
VAX minicomputer make it an acceptable language selection, although
the system still does not operate real-time.
In mainframe implementations, the MYCIN system is probably
the most widely kncwn. Written in Lisp, it is a combination consul-
tation/explanation knowledge system. [39] Using stochastic analysis
rules, this system not only returns an analysis of data but a con-
fidence figure as a measure of hew sure MYCIN is of its analysis.
While this system is without doubt one of the most sophisticated (or
at least complex) analysis units in operation it is, again, non-
real-time, and extremely bulky. Questions can be posed and explana-
tions returned, but no direct eperator/system interaction at the
time of data input is provided. At present, the primary focus of
the MYCIN system is diagnosis of infective diseases from patient
records, and administrative functions.
Returning to microprocessor-based instrumentation, Bourne,
with L. Baas [40], in 1984 adapted the Lisp-based inference engine
initially developed for SEER-1 to a Motorola MC6801, with the al-
gorithm now coded in C and assembler. Number crunching is imple-
mented on an AM9511 arithmetic coprocessor for greater speed. This
system, with a further-refined rulebase, now achieves an 88% confor-


28
nance figure with human experts. 500 to 600 rules now mate up the
rulebase, with a analysis using 40 rules achieved in approximately
50 milliseconds, but the user must direct which rules are to be
used in this case. This system is compact, fast enough for seme
real-time applications, and possesses an extensive rulebase, but the
output, as in the case of most of these expert systems, is nearly as
difficult to interpret as the original data: This output consists
of abbreviated comments printed over a replica of the EEG machine
output. The format is cluttered, and the relationships between
symmetric channel-pairs are not easily recognized.
Suggested Improvements to Existing Systems
There are seme common drawbacks in the Systems described
above: The systems with the greatest complexity have been main-
frame- or minicomputer-based and correspondingly bulky and expensive
to operate and maintain, while the microprocessor-based systems
generally lack the sophistication necessary for complete analysis.
In addition, the output from these systems is often as difficult to
interpret as the original data. There is need for a more directly,
quickly (perhaps even more intuitively) understandable form of
output that can be updated rapidly enough for real-time usage.
Processor speed is no longer a problem: The new Intel 80386
and Motorola MC68020 microprocessors are significantly faster than
their predecessors, as are the Zorain signal processing chips and
the Texas Instruments TMS34010 graphics chips. The equipment is
available and is becoming aompetitively priced.


29
Output format is another problem: With power spectra, cam-
pressed spectral arrays, time-domain output and knowledge system
diagnoses all being output simultaneously, the output from an know-
ledge system must be straightforward enough that the operator can
absorb pertinent information in real time. Graphical output is
suggested here as an appropriate form of simplification; properly
employed graphics are perceived and interpreted almost instantly,
and can provide an enormous amount of information without overwhelm-
ing the observer. Also, if the knowledge system itself decides what
to display, and only displays data it determines to be significant,
the display is simplified even more, and can be used even more
efficiently.


CHAPTER TTT
a anuaAuyv fncwizege system
Design Approach
Hie designed system is implemented in Smalltalk/V, a PC-
based version of Smalltalk-80, with EGA color, multitasking and
Prolog extensions installed. This package was chosen because of its
object-oriented environment, graphics control capabilities and
extension packages. [42] For speed, flexibility and feasibility, the
preposed system combines different software and hardware design ap-
proaches.
System Configuration
Hie overall system consists of (l)an EEG machine, (2) an
interrupt-driven acquisition routine, (3) a data acquisition copro-
cessor subsystem and (4) an IEM-canpatible PC with the Smalltalk en-
vironment installed and active. Hie system designed in this thesis
is part 4, the actual analysis module. Hie block diagram of the
overall system is shewn in figure 10, showing the previously devel-
oped modules and the system designed here. Hie overall system
consists, therefore, of a combination of multitasker and multipro-
cessor.


31
Figure 10: Block Diagram of thp> Overall SvKfrrn
Eight channels are analyzed, arranged in a bipolar montage
with the following connections:
Channel 1: F7-T3
Channel 2: T3-T5
Channel 3 : F3-C3
Channel 4: C3-P3
Channel 5: FB-T4
Channel 6; T4-T6
Channel 7: F4-C4
Channel 8: C4-P4
The channels and frequency bands are organized as in figure
4, and the data are analyzed in epochs, or sampling periods. These
data are then processed with a fast Fourier transform, computing the
power spectra. The spectra are separated into the frequency bands
previously specified (see figure 4), and the power in each band is
integrated. The resulting thirty-two values are loaded into memory
by the knowledge system.


32
Hardware Description
Hie data acquisition coprocessor subsystem is based on the
Texas Instruments IMS32010 system developed by Wunk. [35] Hie main
processing unit is a Compaq Deskpro 386 running at 16MHz, with MS
Dos 3.2 installed and running Smalltalk/V.
Software Description
Figure 11 shews a more detailed block diagram of the de-
signed system. As illustrated, input can be selected from either
disk data file, input port or memory location. Hie individual
software module hierarchies are outlined in figure 12. There are
three main modules concerned with graphics, data acquisition and
data analysis, the graphics module driven by the other two. Data
acquisition and data analysis are implemented with a multitasker and
run simultaneously, communicating via semaphores when necessary.
Input Module. Hie data input module inputs integer data
from either a specified port, a memory location or a data file and
transfers this data, in the form of a 32-element array, into program
memory. It then signals the analysis module by semaphore and waits
until the current data array has been loaded by the analysis module
before repeating the cycle. This module also drives the graphics
module to display the user variable settings and the name of the
analysis subject.
Analysis Module. Hie analysis module waits for the sema-
phore from the input module, moves the current data array from


33
Display
Figure Ti; Klrrtr niaqram nf *-he Designed Svgfr**w


34
MAIN METHOD
[Initiated by user)
--- initialize:
I-- input-output file parameters
'--display
start concurrent processes:
I Data Input Method
'--Data Analysis Method
wait until Check Done flag set
anat.vsts MEnHJDfConcurrent Process)
[initiated by Main Method)
---- repeat until Input Done flag set:
I wait for Data Ready flag set from Data Input Method
--- move next epoch into local memory
--- set Data Taken flag
---check for:
---channel/band side-to-side asymmetries
--- channel average lew levels
--- time trends
--- context-dependent anomalies
1--activate Prolog engine if necessary
--- update:
---channel/band data displays through Display Method
--- trend and level displays through Display Method
--- diagnosis display through Display Method
---- set Check Done flag
DATA INH7T MEmPDfConcurrent Process)
[initiated by Main Method)
----repeat until End-Of-Input is signaled by Acquisition Routine:
I wait for Data Taken flag set from Analysis Method
---
---move next epoch into program memory
---update input display through Display Method
--- set Data Ready flag
---- set Input Done flag
DISPLAY OCWmDL METHOD
(initiated by Analysis and Data Input Methods)
f--check each channel/band display status for changes
'--update changed displays
DATA ACOUISnTCN RCtnTNE
initiated try Data Input Method)
repeat until end-of-irput is reached:
wait for Input Ready flag set from Processing Unit
load epoch into main system memory
signal End-Of-Irput

Figure 32: individual Mnrhilp PmnprtTrai Hierarchies


35
the input nodule into local memory and signals the input module to
continue.
Hie analysis module is based upon a two-level hierarchy:
(l)the low-level data analysis package written in Smalltalk that
performs most of the computation and makes most of the decisions
leading to graphical output, and (2) the high-level inference engine
written in Prolog that attempts, when directed, to identify the more
complex relationships occurring in the data. With this configura-
tion, the low-level computation is performed at a higher speed while
the more detailed yet less efficient high-level work is performed
only as necessary.
Ihe first relationships examined are the amounts of asym-
metry between identical frequency bands in laterally opposed chan-
nels: Asymmetries of this nature usually indicate abnormal energy
imbalances and are therefore significant. If a percent asymmetry
greater than a user-defined threshold is observed, the information
necessary for graphical display is sent to the display module: I
I Efe,c,b " I > threshold
where D = input data value at the indicated channel and band
e = epoch from which the data was taken
c = data channel
b = frequency band
Ihe average energy level of each channel is examined next.
Levels are categorized by user-defined thresholds into lew, medium
and high ranges. Ihe necessary data is sent to the display module
to display these average levels:


36
average channel level^Q =
1
4
4
^fC^b
b=l
Time trends are analyzed next, through a five-epoch window.
These trends are computed by averaging the five-epoch energy level
changes for each of the four frequency bands of each channel, then
comparing this average to another user-defined threshold:
4
1
time trended = ^>| (Pe,b Pe-5,b)
b=l
Since the observation window is five epochs wide, four changes occur
during that window. Trends are then categorized as positive or
negative, and are displayed in a manner similar to the average
energy levels of each channel.
The most complex part of the analysis module examines the
data for energy patterns which potentially indicate the subject's
state or pathological condition, or artifacts caused by eye move-
ment, muscle movement, etc. These conditions are evaluated by a
two-stage process: First, an "alarm condition" is evaluated at the
Smalltalk level, composed of a subset of the condition being
analyzed. For example, if "slewing" is the condition being inves-
tigated, a condition characterized by low-frequency (<5) activity in
localized areas, the 6 components of all channels are averaged, and
the average is compared to an "alarm threshold". If this average is
greater than the alarm threshold, large amounts of low-frequency


37
activity are present, and the Prolog-based high-level inference
engine is called upon to try to localize this low-frequency content.
The Prolog engine is called from the Smalltalk code by the state-
ment:
(alarmValue
ifTrue:
- alanflhreshold)
[RuleBase :?
returnCcrriitioriString,
retumOcnfidenoe)
]
where AlarmValue = alarm condition evaluation result
alarrrilhreshold = user-specified alarm threshold
epochData = Prolog-style list of the current
data
retumConditionString = return string describing the
condition identified
retumConfidence = figure indicating hew confident
the system is of its identifica-
tion
This statement is Smalltalk code until the "RuleBase" term,
at which time the statement becomes a query to the Prolog inter-
preter. For example, success in identifying left frontal slowing
might return:
(epochData, 'If slowing', 567)
where 'If slowing' = the condition identified
567 = the confidence of the identification.
Since the average defined above is much more easily and
quickly computed than all of the comparisons necessary to localize
any "slowing", it is more efficient to follow this path than to
blindly evaluate all possible comparisons, by either deterministic
Smalltalk procedures or by Prolog backtracking methods, in the hope
that localized slowing will be identified.


38
Prolog Inference Encrine. The Prolog engine inputs an epoch
of data in Prolog list-notation and attempts to discern significant
patterns from that data. These patterns can take the form of
general distributions of a certain frequency band, as in identifica-
tion of relaxed, alert or asleep states, or very specific patterns
as in the identification of movement artifacts.
The data structure selected for the Prolog engine is a
simple 8x4 matrix containing the individual power values, or-
ganized by channel and frequency band in the same way as the system
display (see figure 4). Each entry in the matrix is multiplied by a
coefficient in a "weighting matrix", and the sum of the weighted
values is compared to a threshold value. Success occurs if the
weighted sum exceeds the threshold value, at which time the pro-
cedure returns this sum and a quoted string indicating the success
condition. Upon failure, the procedure returns simply "nil".
c=l b=l
where W = matrix of weighting coefficients
In this way, a rule for a new patient state can be added by simply
return string and adjusting the weighting matrix coefficients to
apply to the desired situation.
For example, if "left frontal slewing" is the condition
which must be identified, the weighting matrix might be configured
8 4
copying an existing Prolog rule under a new name, modifying the


39
as follows: 1)weighting values in the left frontal channels for the
S and 0 bands would be largely positive, with the 6 band values
larger than the 0 band values. 2) 5 and 0 band weighting values
elsewhere in the matrix would be slightly negative as penalty for
low-frequency presence in areas other than the left frontal.
3) weighting values for the a and /3 bands would be negative every-
where, since significant high-frequency elements would by definition
eliminate the possibility of a slowing condition. The resulting
Prolog code for a rule might then take the form:
determi nePathOcnd (iMatrix,
threshold,
ocnditicnString,
confidence) :-
pathCbnd (vafetrix, aonditicnString),
dcMatrix(iMatrix, vMatrix, confidence)
gt (confidence, threshold).
where iMatrix = input iratrix of data
threshold = threshold for Prolog engine success
conditionstring = return string upon success
confidence = confidence figure generated
wMatrix = matrix of weighting coefficients
The facts used in the Prolog engine take the following form:
pathOond([ [ [ 20, 20, 1. 1 ]f
[ 12, 12, -Ir -l]f
[ "3, -3, -3, -3],
[ 3, -3, -3, -3] ],
[ [ -1, -1, If -l]f
[ -1, -1. -1, "l]f
( -3, -3, -3, -3],
[ -3, -3, -3, -3] ] ]
'If slowing ')
where 'If slowing' = the string returned upon success


40
Superimposition of this matrix over ary pattern other than
that of the matrix returns a small or negative weighted sum, while a
pattern similar to the matrix will return a positive sum. For
example, if the pattern to be identified is a black dot on a white
background, the weighting matrix might be:
-1 -1 -1
-1 8 -1
-1 -1 -1
If black is given a value of +1 and white a value of -1, super im-
position of the above matrix over an all-white or an all-black area
would return a value of zero, while a black dot centered in the
matrix with a white background would return a value of sixteen.
Placing the dot on an edge or comer of the matrix would return a
value between zero and sixteen.
Note that the weighting coefficients themselves sum to zero,
so that an equal energy distribution would produce a result of zero:
Depending upon the situation, the Prolog rules can be either
8
4
c=l b=l
purely deterministic or can make full use of the backward-chaining
mechanism of the Prolog engine. By coding both types of rules in
Prolog, a very small amount of efficiency is lost while much code


41
symnetry is achieved, enabling later programmers to more easily
modify the source code.
Display Module. The graphics module contains methods to
plot asymmetric channel/band1 pairs, channel average levels and
channel average time trends. Methods are also incorporated to
scroll individual channel/band displays, and to display a transcript
of the Prolog engine analysis in a separate windcw. Graphical
plotting and scrolling are managed with "BitBlt", or bit block-
transfer, operations, for rapid graphics control. Smalltalk makes
extensive use of this utility, and the methods required are easily
developed in this environment. Figure 13 shews the system display
with data being processed. Asymmetries, average channel levels,
time trends and the high-level inference engine analysis are dis-
played.
An asymmetry greater than a user-specified threshold is
indicated by a back-to-back plot of the pewer spectra in the two
frequency bands concerned, located in the channel windew of the band
containing the greater pewer of the two. This system uses color-
coded bands, defined as follcws:
5(0- 3Hz) = red
0(4- 7Hz) = yellow
a ( 8 13Hz) = green
fi (14 3GHz) = blue
kthe term "channel/band" is used to indicate the frequency
band of a certain channel.


42
These plots are scrolled every epoch, so that the data displayed at
the lower edge of a channel/bard window is always current.
The average pcwer level of a channel is displayed in a
separate window by a circle in blue (high average level), green
(medium average level) or red (lew average level) at the location of
the channel concerned.
Time trends for a given channel are displayed in another
separate window by a circular plot in blue (upward trend) or red
(downward trend) at the location of the channel concerned.
A transcript of the Prolog engine analysis is displayed in
the lower-right comer of the system display, indicating the condi-
tion identified and the confidence with which that identification
Weis made.
Figure 13; Designed System Display


43
User Interface. The primary user interface is a mouse,
since this is the most efficient method available in Sroalltalk/V for
selection and user-interaction. The selection bar in the display
(see figure 13) includes the selection areas "analyze", "test
graphics", "rulebase", "userfile", and "select".
If the mouse is clicked in the area around the word
"analyze", a pull-down menu appears allowing the user to select
analysis input from either a data file, a port or a memory location.
Any selection results in prompter windows asking for file names,
port numbers, or any other pertinent information. Analysis of the
data from the specified source is then initiated.
The "test graphics" option initiates a graphics-testing
method which exercises all plotting, scrolling and screen clearing
procedures.
The "rulebase" option opens a "LogicBrowser" window, allow-
ing the user to modify the Prolog rulebase, or to add rules for new
conditions as required. Figure 14 shows the active rulebase editor
window in the analyzer display.
Selection of "userfile" allows the user to view or modify
any user file, containing the threshold values for average levels,
asymmetries, time trends and Prolog engine success. The user is
prompted in this case for the number of the user file to be edited,
and a file with the name "eeg_user." is accessed. Figure 15
shows the active user file editor window.
"Select" prompts the user for a user file number, accesses
that file and updates the system parameters from that file. This


44
Figure 14: Display with Rulebase Editor Window
Figure 15: Display with User File Editor Window


45
feature allows the laser to easily select different sets of variables
for different situations.
Automatic Weighting Coefficient Generator. As stated
before, the data structure selected for the Prolog engine is an 8 X
4 matrix of weighting coefficients, one for each frequency band of
each channel. At first, the selection of these values was purely
subjective, and a more consistent approach was considered: An
algorithm that, supervised by the operator, develops a weighting
matrix from successive comparisons to actual data.
In operation, the utility functions as follows:
1) The user specifies an input data file.
2) The weighting matrix is initialized to zeros.
3) An epoch of data is iiput into the system and displayed in
graphical form with blue = high energy, green = medium energy
and red = low energy.
4) The input values are multiplied by the weighting coefficients,
and a confidence factor is returned:
5) The user is asked to rate the returned confidence with a "cor-
rectness" factor of frcan -5 (very poor) to +5 (very good).
6) The mean of the iiput data is computed, then subtracted frcan
each value of the input data, normalizing the data so that
E[A]=0. Each normalized input data value is then multiplied
by the correctness factor.
7) Each corrected input value is added to its corresponding
weighting coefficient, scaled by the maximum of all of the
resultants, and the total figure is averaged over the number
8 4
C=1 b=l


of epochs viewed. The net effect of this process is the
adjustment of the coefficients to reflect the data patterns.
46
1 ^efCfb e e 2
i=l
where CF^ =
Ac,b =
W(max) =
Ac. b (max) =
E[f>i]
e
W(max)
-------- (Wc,b,i + CFi(Et,b/i EtDi]))
Ac#b<>
correctness factor for the current epoch
new, adjusted weighting coefficient
user-specified maximum allowable coefficient
value
current maximum weighting coefficient
expected value of all of the input data values
for the current epoch
current epoch
8) The system returns to step 3.
Figure 16: Matrix Coefficient Generator Utility
Operation of the coefficient generating system is very
efficient, and the graphical displays provide a great amount of data
in an easily absorbed format.


CHAPQR IV
SYSTEM EVAIIJATICN
Test Results
The system tests were conducted using disk files of actual
EEX5 data taken from earlier patient recording sessions. These data
were formatted into the appropriate eight-channel, four-band arrays
of integrated energy levels. Nineteen test cases were interpreted
by a human expert and then by the analysis system, for a total of
1093 epochs of data. Areas of interest were: (l)does the system
address the essential areas of asymmetry, frequency content and
energy levels? (2)are asymmetries, energy levels and time trends
recognized and displayed in an easily interpreted manner? (3)does
the Prolog engine recognize the states, trends, pathological condi-
tions and artifacts present? (4) does the system operate quickly
enough to function in real time?
Part 4 of the test criteria, for the purposes of the test
data vised, was irrelevant: The test data consisted of 15-epoch
averages, or two-minute periods. Real-time operation in this ap-
plication is assured. The average analysis-time per epoch was
computed, however, to determine the system speed and real-time
potential.
Table 1 displays both the human and machine analyses of the
test data for comparison. In general, the analysis system matched


48
Table 1; HiTiran and Machine Analyses of the Test Data
File(#eDOchs) Human Analysis Machine Analysis
hadam2(65) no hi-frequency at start RF asymmetry:0,a LP asymmetry:all LF slewing,asleep;eyemove RF asymmetry:,a, 6 LP asymmetry:a, 6;med energy
ebassl(47) hi-frequency activity hi-frequency activity(3,4) R asymmetry (MED) :all
cbeckl(22) hi-frequency activity LF asymmetry:9,a,/3 trends;asleep L asymmetry:all
gbcwes(50) IP asymmetry: all L asymmetry:(5,0;asleep
gclift(61) hi-frequency activity RF asymmetry:9,a RP asymmetry:,/3 RF asymmetry: all LP slewing ;med energy
hcoxxl(38) hi-frequency activity LP asymmetry:all RF asymmetry: all LP asymmetry:all RP slewing
efair(76) global slowing LF slewing;asleep
ogarll(53) trends LP asymmetry (IAT) :all RP asymmetry (MED) :all RP slowing LP asymmetry (IAT) :5,,a RP asymmetry (MED) :all
rjerm(44) L asymmetry (IAT) :9,a LP asymmetry:all LF slowing;eyemove
hking2(64) hi-frequency activity trends LF asymmetry:6,0,0 LF slewing;hi energy
skipl(78) trends hi-frequency activity LF slewing
mcneel(58) RF asymmetry:,a LP asymmetry:,a RF asymmetry:mostly LP asymmetry: all
amemor(46) L asymmetry: L asymmetry: RF slewing trends:,S
emilll(71) global slowing LF slewing;asleep
melsl(70) trends LP asymmetry:,a LF slowing;eyemove LP asymmetry: all RP slowing
rpayne(90) hi-frequency activity RF asymmetry: all LP asymmetry:all RF asymmetry:a,j0, IP asymmetry: 6 ;hi energy
freel(31) hi-frequency activity L asymmetry (IAT): S RP slewing strong L asymmetry:,a
jsher(69) hi-frequency activity trends LP asymmetry:all RF asymmetry:all hi S activity ;med energy
ctreel(60) bad channel:2 bad channel:2 L asymmetry:all
L = left; R = right; F = frontal; P = posterior; 1,2.. = channel
IAT = lateral; MED = medial


49
the human response very well, although in seme areas there were
discrepancies: The analysis system makes use of several thresholds,
and the selection of these thresholds proved critical to system
performance. For example, a time trend is displayed only if that
trend exceeds the user threshold. The user must then be very aware
of the relationship between the programmed threshold and their own
"interest threshold" for time trends. If the system is programmed
to recognize only a trend of greater than five normalized units per
epoch, but the user is interested in lesser trends, those lesser
trends will not be observed. Asymmetry thresholds are subject to
the same consideration. Conversely, selection of lower threshold
values causes more data to be displayed, but the user must determine
the significance of that data.
Display Clarity. The displays for asymmetry, average chan-
nel level and the Prolog engine analysis are very readable and
informative. Asymmetry displays in particular allow instant recog-
nition of not only specific energy imbalances but time trends.
Average energy level displays provide the user at any given time
with an idea of the general signal levels being received. This
information can be indicative of either the general condition of the
patient, or of the gain of the ERG machine-generated signal. The
output of Prolog engine is simply text, stating the conditions that
have been identified, along with a confidence figure for that iden-
tification.


50
Table 2 shews a statistical comparison of the human and
machine analyses of the test data. The "+/-M column indicates the
relative effectiveness of the two analyses: Positive figures indi-
cate that the machine analysis has produced more identifications in
the data for that category, while negative figures favor the human
analysis:
Tfelble 2: Onrrarisnn of Human and Machine Analysis Statishins
Number of Identifications
Category Human Analysis Machine Analvsis +/-
energy levels 10 4 - 6
asymmetries 15 24 + 9
trends 5 2 - 3
states 0 5 + 5
slewing 2 13 +11
artifacts 0 3 + 3
(1093 total epochs of data)
Energy Levels. The average energy level of any given chan-
nel, much less all 32 channels, is a figure human analysts cannot
compute in real time. The machine can easily compute this figure in
real time, and the display is easily readable. The drawback here is
that the system display represents only the energy levels for the
current epoch, and there is no ability to view longer-term trends.
The +/- figures show a corresponding bias toward human analysis for
this category.
Asymmetries. While compressed spectral arrays can be used
to identify lateral asymmetries by the human analyst, the presence
of many asymmetries simultaneously may not be identified. The


51
asymmetry displays of this system, however, allow the user to ob-
serve several lateral asymmetries without difficulty. While the +/-
figures for this category shew identifications on the parts of both
human and machine analyses (see table 1) are generally more
specific.
Time Trends. While the time trend display provides the user
at a given time with the trend information for all channels, the
specific nature of longer-term trends cannot be observed except in
the asymmetry plots. If the asymmetry threshold is sufficiently lew
to display all data concerning these trends there is no problem, but
other displays might be better equipped for time trend observation.
Consequently, the +/- figures for this category shew in favor of
human analysis.
States. Pathological Conditions and Artifacts. The ability
of the analysis system to identify more complex relationships and
patterns in real time is its most potentially useful feature. The
+/ figures are weighted heavily in favor of the machine in these
cases, partially because of the rapid identification of the rela-
tionships, but also because of the completely consistent interpreta-
tion of the data by the nachine.
Operating Speed. While the test data consisted of 15-epoch
averages, and would in practice require the system to perform an
analysis only every two minutes, the average analysis time per epoch


52
during testing was only 4.85 seconds. At this pace, the system can
easily perform real-time analysis on 8 second epochs of raw data.
Comparison of the Newlv Developed System
with Previous Implementations
Analytically, the system compares very well with previous
implementations. When run on a 80386-based machine, real-time
operation is achieved, with excellent results. Time trends and
average channel levels are easily identified and displayed clearly,
while asymmetries greater than the user-programmable threshold are
displayed in back-to-back plots, easily interpreted by the user.
Since the system operates in the EGA mode, making full use of the 16
colors available, the different frequency bands of each channel are
clearly identified. The display developed for this system is
definitely more complete and instantly readable than any of the
analysis systems discussed earlier. Although this system does not
contain extensive signal processing abilities itself, the intent was
to interface this analysis module with another, previously designed
data acquisition system (see Wunk[33]).
Band plot scrolling is very quick, and all of the display
items have been arranged to inform the user without the use of dis-
tracting, rapidly flashing panels and indicatorsa feature used
earlier in the design process, then discarded: Earlier displays
incorporated far too many moving graphics and color changes, and
proved extremely discomforting to the user. As the design of the
system evolved, displays were simplified, and more responsibility


53
was delegated to the knowledge system to determine which data would
be displayed.
For example, initial display designs used the channel outer-
frame (see figure 13) to indicate the average power in that channel:
red, green or blue. Rapid color changes in so large an area of the
screen was irritating to the eyes and distracting. In later ver-
sions, the average-level display was moved to the present small oval
in the upper right comer of the screen, with smaller circles in-
dicating the channel average levels. Thus, a much smaller visual
area is affected, but the data is still effectively displayed.
Determination of the weighting coefficients for the high-
level inference engine proved to be one of the more difficult and
interesting tasks in the development of this system. Even with the
use of the automatic coefficient generator described in chapter 3,
much of the process was subjective: While the coefficient generator
followed strict guidelines in operation, the decision whether an op-
timum matrix had been generated was left to the user. Also, in each
cycle of the matrix generation, the user was required to evaluate
the "correctness" of the weighting matrix coefficients with respect
to the graphical data observedanother subjective decision. The
test results, however, indicate that the coefficients chosen were
acceptable, since the system proved effective in identifying many of
the conditions also identified by human experts.


CHAPQR V
OCNCXIJBICtG
While the system at present is capable of real-time perfor-
mance, it is extended nearly to its operational limits: At 16Mhz,
the 80386-based machine on which this system is run is operating at
70% duty-cycle when analyzing eight-second epochs of data in real
time. Changing to shorter analysis epochs or adding more analysis
methods could overload the CTO, virtually eliminating this real-time
capability. Also, while the 80386 machine presently runs the Small-
talk environment with enough speed to achieve real-time operation,
16Mhz machines are not yet common, and an analysis system capable of
performing in real time on an 8-, 10- or 12-MHz AT-type machine
would be preferable.
Smalltalk is an excellent programming environment for
project development, but it is inherently slow and clumsy: Since no
executable file is created, applications must be run on an active
Smalltalk environment, with all of the included overhead (Smalltalk
requires 640k of ram with the EGA extension), arid virtual memory
object-swapping often further slews program execution.
A faster successor to this system would incorporate lower-
level algorithms re-coded in C linked with higher-level algorithms
in compiled Prolog. While re-coding the actual analysis methods
would be essentially trivial, the graphics methods would require


55
considerable redevelopment.1 The result, hcwever, would be a more
compact, faster system without the shortcomings described above.
While seme C compilers allow direct linkage with Prolog code
(Turbo C and Turbo Prolog by Borland Software, for example), the
Prolog part of the Smalltalk system could be coded in C as well,
gaining even more of a speed advantage over the current system. It
would be preferable, hcwever, to leave the Prolog code unaltered for
easier expansion and greater clarity, and to take full advantage of
the backtracking capabilities of Prolog. Some versions of Prolog,
such as Arity Prolog version 5.0, incorporate an imbedded C compiler
in the main Prolog engine, allcwing easy mixture of C and Prolog
inside the Prolog environment.
Other, more involved statistical analysis and modeling
methods were explored, such as autocorrelation analysis of the
data[42] and autoregressive modeling[43], but these processes proved
extremely time-consuming and the results were not useful: A simple
time-averaging scheme is used to identify time trends over five-
epoch windows, and has proved much more efficient than an autocor-
relation algorithm or a slower autoregressive model requiring fifty
or more epochs of data to produce results.
An option considered but not implemented was an interface to
allow the user to modify the features of the system without being a
Smalltalk programmer. There are at present interfaces for rulebase
1While several graphics libraries are presently available
for C compilers, Smalltalk graphics methods are superior, and a
substantial amount of development would be required to produce
the same level of sophistication in C.


56
and user file modification, but it was felt that, to retain as much
execution speed as possible, the code itself should be optimized as
much as possible. This optimization precluded modification by a
novice. Also, this system was designed for a specific application
with specific capabilities, and as such would not be a target for
modification.
Due to the "template" orientation of the system code, hcw-
ever, the basic concepts implemented here could easily be used as
the bases for other applications desiring intelligent, graphics-
oriented displays. The template-based, highly modular construction
of this system was, in fact, designed with this purpose in mind.
Finally, an increasing concern in the use of knowledge
systems is the extent of legal responsibility inherent in the use of
such a system. Zeide and Liebcwitz[44] state that while knowledge
systems have yet to experience much in the way of legal trouble,
"great litigious potential exists over their use, misuse, and nonuse
(potential that will soon be realized)." The non-use of a knowledge
system by a professional who commonly uses that system could be
grounds for prosecution, as could the use of a system improperly
fitted to an application. In conclusion, Zeide and Liebcwitz state
that "as knowledge-based technology becomes more commonplace, public
expectations of expert systems must be put into proper scope.
Otherwise exaggerated expectations will create an even more
litigious society."


hi m .TrraAPHV
[ 1]J. S. Barlow, "Computerized Clinical Electroencephalography in
Perspective", i kkk Transactions on Biomedical Engineering. Vol.
26 NO. 7, pp. 377-388, JUL 1979.
[ 2]---, Design of Microprocessor-Based Medical Instrumentation.
W. J. Tompkins and J. G. Webster, Ed., New York: Prentice-Hall,
1981.
[ 3]T. C. Karselis, Descriptive Medical Electronics and
Instrumentation. New Jersey: Charles B. Slack Inc, 1973.
[ 4]J. Allen, Anatorw of Lisp. New York: McGraw-Hill, 1978.
[ 5]J. McCarthy, P. W. Abrahams, D. J. Edwards, T. P. Hart and M. I.
Levin, Lisp 1.5 Programmers Mannal. Cambridge: The M.I.T.
Press, 1985.
[ 6]E. P. Stabler Jr., "Object-Oriented Programming in Prolog", IEEE
AI Expert. Vol.l No. 3, pp.46-57, Fall 1986.
[ 7]W. F. Clocks in and C. S. Mellish, Programming in Prolog. New
York: Springer-Verlag, 1984.
[ 8]F. KLuzniak and S. Szpakowicz, Prolog for Programmers. London:
The Academic Press, 1985.
[ 9]L. Sterling and E. Shapiro The Art of Prolog: Advanced
Programming Techniques. Cambridge, MA: The MIT Press, 1986.
[10] T. Rensch, "Object Oriented Programming", SIGFLAN Notices.
Vol.17 No.9, pp.51-57, SEP 1982.
[11] A. Goldberg and D. Robson, Smalltalk 80: The language and its
Implementation. London: Addison-Wesley, 1983.
[12] T. Kaehler and D. Patterson, "A Small Taste of Smalltalk", Byte,
Vol. 11 No.8, pp. 145-159, AUG 1986.
[13] E. R. Tello, "Smalltalk/V", Dr. DobbS Journal Vol. 12 No.8,
pp. 128-134, ADG 1987.
[14] N. J. Nilsson, Principles of Artificial Intelligence. Los
Altos, CA: Morgan-Kaufman, 1980.
[15] P. H. Winston, Artificial Intelligence. Reading, MA:
Addison-Wiesley, 1984.


58
[16] J. Pearl, "Scare Recent Results in Heuristic Search Theory", trek
Transactions on Pa-t-tem Analysis and Machine Intelligence. Vol.6
No.l, pp.1-12, JAN 1984.
[17] R. Fites and T. Kehler, "The Role of Frame-Based Representation
in Reasoning", Communications of the Association for Computing
Machinery. Vol.28 No.9, pp.904-920, SEP 1985.
[18] M. Rettig, "Using Smalltalk to Implement Frames", tree at
Expert. Vol.l No.4 pp.15-18, Winter 1987.
[19] D. E. Shaw, "On the Range of Applicability of an Artificial
Intelligence Machine", Artificial Intelligence. Vol.32 No. 2,
May 1987.
[20] C. Tcwnsend and D. Feutiht, Designing and Prcarammina Personal
Expert Systems. Blue Ridge Summit, PA: TAB Books, Inc, 1986.
[21] N. M. Cooke and J. E. McDonald, "A Formal Methodology for
Acquiring and Representing Expert Knowledge", ikee Pnnnppdinn=;.
Vol.74 No.10, OCT 1986, pp.1422-1430.
[22] P. K. Firik, J. C. Lusth and J. W. Duran, "A General Expert
System for Diagnostic Problem Solving", ikkk Transactions on
Pattern Analysis and Machine Intelligence. Vol.7 No.5, pp.553-
560, SEP 1985.
[23] J. D. Foley and C. F. McMath, "Dynamic Process Visualization",
Ikkk Ccmputer Graphics and Applications. Vol.6 No.2, pp.16-25,
MAR 1986.
[24] A. Wolfe, "An Easier Way to Build a Real-Time Expert System",
Electronics. Vol.60 No.5, pp.71-73, MAR 1985.
[25] R. L. Moore, "Adding Real-Time Expert System Capabilities to
large Distributed Control Systems", Control Engineering. Vol.32
No.4, AIR 1985.
[26] M. Ben-Ari, Principles of Concurrent Programming. London:
Prentice-Hall, 1982.
[27] D. D. Gajski and J. Pier, "Essential Issues in Multiprocessor
Systems", ikkk Ccmputer. Vol.l No. 18, pp.9-27, JUN 1985.
[28] P. C. Burkimsher, "Combination-Reduction in a Shared-Memory
Multiprocessor", The Ccmputer Journal. Vol.30 No.3, pp.214-221,
Mar 1987.
[29]A. H. Karp, "Programming for Parallelism", tree Computer. Vol.20
No.5, pp.43-55, MAY 1987.


59
[30] V. Zakharov, "Parallelism and Array Processing", IEEE
Transactions on Computers. Vol.23 No.l, pp.45-78, JAN 1984.
[31] R. H. Eckhouse and L. R. Morris, Minicomputer Systems:
Organization. Programming and Applications. Englewood Cliffs,
NJ: Prentice-Hall, 1979.
[32] Y. Liu and G. A. Gibson, Microcomputer Systems: The 8086/8088
Family. Englewood Cliffs, NJ: Prentice-Hall, 1986.
[33] D. F. WUnk, "Realtime EEG Processing Using a High-Speed
Coprocessor", ikkk Frontiers of Engineering and Computing in
Health Care. Vol.l C3.1, pp.108-111, 1985.
[34] A. C. Sanderson, J. Segen and E. Richey, "Hierarchical Modeling
of EEG Signals", ikkK Transactions on Pattern Analysis and
Machine Intelligence. Vol.2 No.5, pp.405-414, SEP 1980.
[35] D. L. Hudson and M. E. Cohen, "The Impact of Reasoning with
Uncertainty in a Medical Expert System", Symposium on Computer
Applications in Medical Care, pp.43-48, 1987.
[36] J. R. Bourne, B. Hamel, D. Giese, J. W. Ward and P. E. Teschan,
"The EEG Analysis System of the National Cooperative Dialysis
Study", tree Transactions on Biomedical Engineering. Vol.27
No.11, pp.656-663, NOV 1980.
[37] J. R. Bourne, V. Jagannathan, B. Giese and J. W. Ward, A
Software System for Syntactic Analysis of the EEG", Computer
Programs in Medicine 11. pp. 190-200, 1980.
[38] J. R. Bourne, M. Matousek, S. Friberg and A. Arvidssen, "SEER-I:
The Semantic EEG Evaluation Regimen", tree Transactions on
Biomedical Engineering. Vol.30 No.4, pp.239-244, AIR 1983.
[39] --, Rule-Based Expert Systems: The MYCIN Experiments of the
Stanford Heuristic Programming Project. B. G. Buchanan and
E. H. Shortliffe, Ed., Reading, MA: Addison-Wesley, 1984.
[40] L. Baas and J. R. Bourne, "A Rule-Based Microcomputer System for
Electroencephalogram Evaluation", .ieee Transactions on
Biomedical Engineering. Vol.31 No.10, pp.659-663, OCT 1984.
[41] --, Smalltalk/V Tutorial and Programming Handhook. Los
Angeles: Digitalk, Inc, 1986.
[42] C. W. Helstrom, Probability and stochastic Processes for
Engineers. New York: MacMillan Publishing Company, 1984.
[43] A. Pahkratz, Forecasting With Univariate Box-Jenkins Models.
New York: Wiley, 1983.


60
[44]J. S. Zeide and J. Liebowitz, "Using Expert Systems: The Legal
Perspective", TEEE AI Expert. Vol.2 No.l, pp.19-21, Spring 1987.


APPENDIX A
WEIGHTING MAURICES FOR SETKCTim (XNDinCNS
Hie following matrices are the machine-generated weighting
coefficient matrices used in the Prolog inference engine for
analysis purposes.
1.State; Alert.
-8 -8 -8 -8
-8 -8 -8 -8
3 3 3 3
6 6 6 6
-8 -8 -8 -8
-8 -8 -8 -8
3 3 3 3
20 20 20 20
2.State: Asleep.
20 20 20 20
3 3 3 3
-8 -8 -8 -8
-8 -8 -8 -8
6 6 6 6
3 3 3 3
-8 -8 -8 -8
-8 -8 -8 -8
3.State: Relaxed.
-8 -8 -8 -8
-8 -8 -8 -8
6 6 6 6
3 3 3 3
-8 -8 -8 -8
-8 -8 -8 -8
20 20 20 20
3 3 3 3


62
4.Artifact: Eve Movement.
-6 20 20 -6
0 0 0 0
0 0 0 0
0 0 0 0
-5 -9 -9 -5
0 0 0 0
0 0 0 0
0 0 0 0
5.Artifact: Muscle Movement.
0 0 0 0
0 0 0 0
0 0 0 0
20 -20 -20 20
0 0 0 0
0 0 0 0
0 0 0 0
20 -20 -20 20
6.Condition: Slcwina. Left Frontal
20 20 1 1
12 12 -1 -1
-3 -3 -3 -3
-3 -3 -3 -3
-1 -1 -1 -1
-1 -1 -1 -1
-4 -4 -4 -4
-4 -4 -4 -4
7.Condition: Slewing. Right Frontal.
1 1 20 20
-1 -1 12 12
-3 -3 -3 -3
-3 -3 -3 -3
-1 -1 -1 -1
-1 -1 -1 -1
-4 -4 -4 -4
-4 -4 -4 -4


63
8. Condition: Slcwincr. Left Posterior.
-1 -1 -1 -1
-1 -1 -1 -1
-4 -4 -4 -4
-4 -4 -4 -4
20 20 1 1
12 12 -1 -1
-3 -3 -3 -3
-3 -3 -3 -3
9.Condition: Slowina. Riaht Posterior,
-1 -1 -1 -1
-1 -1 -1 -1
-4 -4 -4 -4
-4 -4 -4 -4
1 1 20 20
-1 -1 12 12
-3 -3 -3 -3
-3 -3 -3 -3 ,
10.Condition: Slcwina. Frontal.
20 20 20 20
10 10 10 10
-5 -5 -5 -5
-5 -5 -5 -5
-2 -2 -2 -2
-2 -2 -2 -2
-8 -8 -8 -8
-8 -8 -8 -8
n.Condition: Slowing. Posterior.
-2 -2 -2 -2
-2 -2 -2 -2
-8 -8 -8 -8
-8 -8 -8 -8
20 20 20 20
10 10 10 10
-5 -5 -5 -5
-5 -5 -5 -5


64
Condition: Slowlncr. Global.
20 20 20 20
6 6 6 6
-13 -13 -13 -13
-13 -13 -13 -13
20 20 20 20
6 6 6 6
-13 13 -13 -13
-13 -13 -13 -13


APmcnx b
SOURCE OOCE USEENGS
Hie following source code is listed in the actual output format of
Smalltalk class files:
Object subclass: #EEG
instanceVariableNames: '1
classVariableNames:
'RuleBase Expertstream Delta Ioval Threshold Analyst User Screen
Hival SlcpeMin '
poolDictionaries:
'CharacterConstants !
!EEG class methods !
!EEG methods !
editUserVars
"Edit the current user variable file."
FileBrowser new cpenQn:
(Disk file: (File fileName: 'eegjaser'
extension: User printstring) )!
performAnalysis: source
"Initiate EEG analysis of data from a specified source."
Analyst analyze: source printstring!
readUserVars
"Read in the user variable values from a specified user file."
| input temp |
input := Disk file:
temp := $ .
(File fileName: 'eeg_user'
extension: User printstring).
[terrp = $=] whileFalse: [temp := input next].
Loval := Analyst readlnteger: input.
[terrp = $=] whileFalse: [temp := irput next].
Hival := Analyst readlnteger: irput.
[tenp = $=] whileFalse: [tenp := irput next].
Delta := Analyst readlnteger: irput.


66
[temp = $=] whileFalse: [temp := input next].
SlcpeMin := Analyst readlnteger: input.
[temp = $=] whileFalse: [temp := input next].
Threshold := Analyst readlnteger: input.
CharacterScanner new
initialize: Display boundingBox font: Font fourteenLine;
setForeColor: 11 backColor: 8;
display: (Hival printPaddedTo:
display: (Ioval printPaddedTo:
display: (Delta pr intPaddedTo:
display: (SlcpeMin printPaddedTo:
3) at: 377 @ 161;
3) at: 377 @ 175;
3) at: 377 @ 189;
3) at: 377 @ 203!
selectUserVars
"Select a new user variable file."
User := Prompter prompt: 'user file number:'
defaultExpression: User printstring,
self readUserVars! !
"Additional EEG methods." !
! EGG methods !
initialize
"Initialize the expert and display instances and open the
analysis top pane. (This method is located in the file
EEG_SUP.CLS because it makes references to classes installed
after EEG. CIS)"
Screen := EEGdisplay new.
Analyst := EBGexpert new.
RuleBase := EEGruleBase new.
User := 0.
Transcript cr.Transcript show:
'Filing in Prolog rules'.
(Disk file: 'rules.eeg') fileln.
Transcript cr. Transcript show:
'Filing in Prolog facts'.
(Disk file: 'facts.eeg') fileln.
Screen cpenWindow!
editRuleBase
"Edit the rulebase used for high-level inferencing. (This
method is located in the file EBG_SUP.CIS because it makes
references to classes installed after EGG.CIS)"
IogicBrowser new cpenOn: (Array with: EEGruleBase)!
INITIAL USER FIIE______________
SmallTalk user variables: Enter any comments and/or explanations,


67
but DO NOT change the order in which the variables appear and DO NOT
use an 'equals' sign anywhere else in this file.
Ioval = 10
Hival = 40
Delta = 50
SlcpeMin = 5
Thresholds 1500
average channel low value threshold
average channel high value threshold
channel/band asymmetry threshold
average time slope threshold
high-level inferencer threshold
EEG subclass: #EEGdisplay
instanceVariableNames: ''
classVariableNames:
'ExpertPane TimeFlags LevelFlags PlotPoints FramePoints '
poolDictionaries: '' !
lEEGdisplay class methods !
lEEGdisplay methods 1
blanKWindcw: aChannel band: aBand
"Black-out the indicated channel/band window."
(ColorForm new width: 88
height: 25
initialColor: 16)
displayAt: (((PlotPoints at: aChannel)
at: aBand)
at: 1)
@ (((PlotPoints at: aChannel)
at: aBand)
at: 2)!
displayBrainicon
"Display the brain/sensor placement icon."
| channelArray |
channelArray := #(1 3 7 5 2 4 8 6).
Pen new
place: (212 @ 188);
ellipse: 59 aspect: 4/7;
ellipse: 58 aspect: 4/7;
mask: (BiColorForm color: 3);
solidEllipse: 57 aspect: 4/7.
0 to: 3 do: [:chamel|
Pen new
place: 176 + (channel 24) @ 179;
ellipse: 10 aspect: 1;
place: 176 + (channel 24) @ 197;


68
ellipse: 10 aspect: 1;
mask: (BiColorForm color: 11);
fillAt: 176 + (channel 26) @ 179;
fillAt: 176 + (channel 26) @ 197.
CharacterScanner new
initialize: Display boundingBox font: Font fourteenLine;
setForeColor: 16 backColor: 11;
display: (channelArray at: (channel + 1)) printstring
at: 172 + (channel 24) @ 173;
display: (channelArray at: (channel + 5)) printstring
at: 172 + (channel 24) @ 191
displaylegends
"Display the band/color, warning and user selection legends."
CharacterScanner new
initialize: Display boundingBox font: Font fourteenLine;
setForeColor: 12 backColor: 8;
display: 'delta' at: 60 @ 161;
setForeColor: 14 backColor: 8;
display: 'theta' at: 60 @ 175;
setForeColor: 10 backColor: 8;
display: 'alpha' at: 60 @ 189;
setForeColor: 9 backColor: 8;
display: 'beta' at: 60 @ 203;
setForeColor: 11 backColor: 8;
display: ' Hival:' at: 302 @ 161;
display: ' Ioval:' at: 302 @ 175;
display: ' Delta:' at: 302 § 189;
display: 'SlcpeMin:' at: 302 @ 203;
setForeColor: 16 backColor: 8;
display:
' analyze test graphics rulebase userfile select '
at: 2 @ 21!
displaylevel: aChannel level: levelColor
"Plot the channel-level indicator (lc&F=red, medium=green,
high=3Dlue) in the appropriate display."
| levelFoints |
levelPoints := #( (530 90) (530 110) (550 90) (550 110)
(590 90) (590 110) (570 90) (570 110) ).
((LevelFlags at: aChannel) = levelColor)


69
ifFalse: [LevelFlags at: aChannel put: levelColor.
Pen new
mask: (BiColorForm color: levelColor);
place: ((levelPoints at: aChannel) at: 1)
§ ((levelPoints at: aChannel) at: 2);
solidEllipse: 6 aspect: 1
]l
displayTrendlcons
"Display the frequency- and time-trend icons."
Pen new
place: (560 @ 50);
solidEllipse: 52 aspect: 4/7;
place: (560 @ 100);
solidEllipse: 52 aspect: 4/7.
QiaracterScanner new
initialize: Display boundingBox font: Font fourteenLine;
setForeColor: 11 backColor: 8;
display: 't trends:' at: 435 § 44;
display: 1 levels:' at: 435 @ 94;
setForeColor: 12 backColor: 8;
display: 'd' at: 620 @ 53;
display: '1' at: 620 @ 108;
setForeColor: 9 backColor: 8;
display: 'u' at: 620 @ 35;
display: 'h' at: 620 @ 80;
setForeColor: 10 backColor: 8;
display: 'm' at: 620 § 94!
displayTtrend: aChannel direction: trendColor
"Plot the time-trend indicator (up=blue, down=red) in
the appropriate display."
| tTrendPoints |
tTrendPoints := #( (530 40) (530 60) (550 40) (550 60)
(590 40) (590 60) (570 40) (570 60) ).
((TimeFlags at: aChannel) = trendColor)
ifFalse: [TimeFlags at: aChannel put: trendColor.
Pen new
mask: (BiColorForm color: trendColor);
place: ((tTrendPoints at: aChannel) at: 1)
@ ((tTrendPoints at: aChannel) at: 2);
solidEllipse: 6 aspect: 1
]!


frame: aChannel
"Draw the channel frame (color = 8 (dark gray))."
0 to: 1 do: [:i|
(ColorForm new width: 4
height: 123
initialColor: 8)
displayAt:
(i 94 + ((FtameFoints at: aChannel)
at: 1) + 1)
0 (((FrameFoints at: aChannel)
at: 2) + 1)
]
0 to: 4 do: [:i|
(ColorForm new width: 90
height: 3
initialColor: 8)
displayAt: (((FrameFoints at: aChannel)
at: 1) + 5)
0 (i 30 + ((FrameFoints at: aChannel)
at: 2) + 1)
]!
graphChange: aPoint
"Pull-down menu controller."
(aPoint between: 1 @ 21 and: 75 § 35)
ifTrue: [self graphPik: (self graphMenu popUpAt: 50 @ 59) ]
(aPoint between: 76 0 21 and: 195 0 35)
ifTrue: [self test].
(aPoint between: 196 0 21 and: 275 § 35)
ifTrue: [super editRuleBase].
(aPoint between: 276 § 21 and: 355 0 35)
ifTrue: [super editUserVars].
(aPoint between: 356 0 21 and: 425 0 35)
ifTrue: [super selectUserVars]!
graphMenu
"Answer the menu for the graphics pane."
"Menu
labels: ,memory\data file\port' withers
lines: #()
selectors: #(m d p)!
graphPanell: box
"Set up the background form for the main analysis window
display, and answer the form."
Screen initializeDisplay.
(ColorForm new width: box width
height: box height


J
71
initialColor: 8)
displayAt: 3 @ 21.
1 to: 8 do: [:channel|
(ColorForm new width: 100
height: 125
initialColor: 16)
displayAt: ((FramePoints at: channel)
at: 1)
@ ((FramePoints at: channel)
at: 2).
self frame: channel
]
self displayBrainlcon;
displaylegends.
super readUserVars.
"ColorForm new width: box width
height: box height
initialColor: 8!
graphPanel2: box
"Set up the background form for the secondary analysis window
display, and answer the form."
(ColorForm new width: box width
height: box height
initialColor: 8)
displayAt: box origin,
self displayTrendlcons.
"ColorForm new width: box width
height: box height
initialColor: 8!
graphPik: source
(source = nil)
ifFalse: [super performAnalysis: source]1
initializeDisplay
"Initialize the graphics location arrays and indicator flags."
FramePoints := #( ( 5 35) ( 5 217) (110 35) (110 217)
(320 35) (320 217) (215 35) (215 217) ).
:= #( ( ( 11 40) ( 11 70) ( 11 100) ( 11 130) )
( ( 11 222) ( 11 252) ( 11 282) ( 11 312) )
( (116 40) (116 70) (116 100) (116 130) )
( (116 222) (116 252) (116 282) (116 312) )
( (326 40) (326 70) (326 100) (326 130) )
( (326 222) (326 252) (326 282) (326 312) )
( (221 40) (221 70) (221 100) (221 130) )
( (221 222) (221 252) (221 282) (221 312) ) )
ExpertStream := ExpertPane dispatcher.


LevelFlags := Array new: 8.
TimeFlags := Array new: 8.
1 to: 8 do: [:i|
LevelFlags at: i put: 1.
TimeFlags at: i put: 1
initializeForms
"Display the initial-state plot, level and trend forms."
self initializeDisplay.
ExpertPane cancel.
QiaracterScanner new
initialize: Display boundingBox font: Font sixteenLine;
setForeColor: 11 backColor: 16;
display: ' ' at: 500 @ 130.
1 to: 8 do: [:channel|
self displayLevel: channel level: 16;
displayTtrend: channel direction: 16.
1 to: 4 do: [:band|
self blankWindow: channel band: band
]
]!
nullMenu
"Answer null menu."
"Menu
labels: ''
lines: #()
selectors: #()!
nullPanel
"Answer the null expert system header for the expert pane."
openWindow
"Open the analysis top pane window with sub panes."
| topPane |
topPane := TopPane new
label: 1EEG Analysis1;
backColor: 16;
foreColor: 3;
menu: #tcpMenu;
model: self;
yourself.
topPane addSubpane: (GraphPane new
model: self;


73
name: #graphPanell:;
menu: #nullMenu;
change: #graphChange:;
framingRatio: (0 @0
comer: 2/3 § 1) ).
topPane addSubpane: (GraphPane new
model: self;
name: #graphPanel2:;
menu: #nullMenu;
change: #graphChange:;
framingRatio: (2/3 @ 0
comer: 1 § (1/3)) ).
tcpPane addSubpane: (GraphPane new
model: self;
name: #subjectPanel:;
menu: #nullMenu;
change: #graphChange:;
framingRatio: (2/3 0 (1/3)
comer: 1 0 (128/330)) ).
tcpPane addSubpane: (ExpertPane := TextPane new
model: self;
name: #nullPanel;
menu: #nullMenu;
framingRatio: (2/3 § (128/330)
comer: 10 1 ) ).
tcpPane reframe: (Display boundingBox).
tcpPane dispatcher openWindcw scheduleWindcw!
plot: IChannel band: aBand
UPoint: UDataPoint lrPoint: lrDataPoint
rlPoint: rlDataPoint rrPoint: rrDataPoint
"Plot the next epoch of data."
| bandColorArray plotColor rChannel llPlot lrPlot rlPlot rrPlot |
bandColorArray := #(12 14 10 9).
plotColor := bandColorArray at: aBand.
rChannel := IChannel + 4.
llPlot := UDataPoint 43 // 100.
lrPlot := lrDataPoint 43 // 100.
rlPlot := rlDataPoint 43 // 100.
rrPlot := rrDataPoint 43 // 100.
llPlot > 43 ifTrue: [llPlot := 43].
lrPlot > 43 ifTrue: [lrPlot := 43].
rlPlot > 43 ifTrue: [rlPlot := 43].
rrPlot > 43 ifTrue: [rrPlot := 43].
(ColorForm new width: llPlot
height: 1
initialColor: plotColor)
displayAt: ((((PlotPoints at: IChannel)


74
at:
at:
@ ((((PlotPoints at:
at:
at:
(ColorForm new width: lrPlcrt
height: 1
initialColor: plotColor)
displayAt: ((((PlotPoints at:
at:
at:
@ ((((PlotPoints at:
at:
at:
(ColorForm new width: rlPlot
height: 1
initialColor: plotColor)
displayAt: ((((PlotPoints at:
at:
at:
@ ((((PlotPoints at:
at:
at:
(COlorForm new width: rrPlot
height: 1
initialColor: plotColor)
displayAt: ((((PlotPoints at:
at:
at:
@ ((((PlotPoints at:
at:
at:
aBand)
1) + 43 llPlot)
lChannel)
aBand)
2) + 24).
lChannel)
aBand)
1) + 45)
lChannel)
aBand)
2) + 24).
rChannel)
aBand)
1) + 43 rlPlot)
rChannel)
aBand)
2) + 24).
rChannel)
aBand)
1) + 45)
rChannel)
aBand)
2) + 24)!
scroll
"Scroll the displays."
| yPosArray |
yPosArray := #(41 71 101 131 223 253 283 313).
yPosArray do: [:yPos|
BitBlt new
destForm: Display sourceForm: Display;
extent: 405 @ 24;
destOrigin: 10 @ yPos;
sourceOrigin: 10 @ (yPos + 1);
ccpyBits
]
subjectPanel: box
"Answer the subject header for the subject pane."


75
(ColorForm new width: box width
height: box height
initialColor: 16)
displayAt: box origin.
CharacterScanner new
initialize: Display boundingBox font: Font fourteenLine;
setForeColor: 11 badcColor: 16;
display: 'subject:' at: 430 0 130.
self initializeForms.
"ColorForm new width: box width
height: box height
initialColor: 16!
test
"Exercise all graphics methods."
| IChannel rChannel |
Screen initializeDisplay;
initializeForms.
1 to: 4 do: [:channel|
IChannel := channel.
rChannel := channel + 4.
1 to: 4 do: [:band|
1 to: 25 do: [:i|
self plotScroll: IChannel band: band
llFoint: (4 i) IrFoint: (100 (4 i))
rlFoint: (4 i) rrFoint: (100 (4 i));
displayTtrend: IChannel direction: 12;
displayTtrend: rChannel direction: 9;
displayLevel: IChannel level: 9;
displaylevel: rChannel level: 12
]
]
].
Menu message: 'continue'.
1 to: 4 do: [:channel|
IChannel := channel.
rChannel := channel + 4.
1 to: 4 do: [:band|
self blarikWindcw: IChannel band: band;
blankWindow: rChannel band: band;
displayTtrend: IChannel direction: 16;
displayTtrend: rChannel direction: 16;
displaylevel: IChannel level: 10;
displaylevel: rChannel level: 9
]
].
Menu message: 'end graphics test'!


76
tcpMenu
"Answer the menu for the top pane."
"Menu
labels: 'close' withers
lines: #()
selectors: #(close!t)! !
EEG subclass: #EEGexpert
instanceVariableNames:
'epoch epochSanple segment offset inputPort inputFile
outputFile '
classVar iableNames:
'InputDone TrendValues DataReady DataTaken CheckDone '
poolDictionaries: '' !
lEEEexpert class methods !
lEEGexpert methods !
alarmArtifact: sanple data: data
"Determine what type of artifact the subject is displaying."
| alarmEye alamtfove state stateData eyeLevel xnoveLevel |
stateData := data.
eyeLevel := 20.
moveLevel := 20.
"eye-movement artifacts are indicated by increased high-
frequency activity in the forward medial electrodes:"
alarmEye := ((sample at: 3) at: 1) +
((sanple at: 7) at: 1) > eyeLevel.
"muscle-movemertt artifacts are indicated by increased high-
frequency activity in the lateral electrodes:"
alarmMove := ((sample at: 1) at: 4) +
((sample at: 2) at: 4) +
((sanple at: 5) at: 4) +
((sanple at: 6) at: 4) > moveLevel.
(alarmMove or: [alarrrMove])
ifTrue: [state := RuleBase :?
determineArtifact(stateData, Threshold,
retumCondition, confidence).
(state = nil)
ifFalse: [self displayAlarm: (state at: 1)]
]l
alarmSlowing: sanple data: data


77
"Determine if any type of slewing is present."
| lcwFreq state stateData slcwLevel slowing |
lcwFreq := 0.
stateData := data.
slcwLsvel := 20.
slewing := false.
"slowing is indicated by large amounts of lew-frequency
activity:"
1 to: 8 do: [:channel|
lcwFreq := lcwFreq + ((sample at: channel) at: 1)
].
(lcwFreq > slcwLevel)
ifTrue: [state := RuleBase :?
determinePathCond (stateData, Threshold,
retumCondition, confidence).
(state = nil)
ifFalse: [self displayAlarm: (state at: 1).
slewing := true
]
].
"slowing!
alarmState: sample data: data
"Determine the state of the subject."
| alarmAlert alarmAsleep alarmRelaxed state stateData |
stateData := data.
"alert state is indicated by high beta activity in the rearward
electrodes:"
alarmAlert := ((sample at: 2) at: 4) +
((sample at: 4) at: 4) +
((sample at: 8) at: 4) +
((sample at: 6) at: 4) // 4 > Hival.
"relaxed state is indicated by high alpha activity in the
rearward electrodes:"
alarmRelaxed := ((saitple at: 2) at: 3) +
((saitple at: 4) at: 3) +
((sample at: 8) at: 3) +
((sample at: 6) at: 3) // 4 > loval.
"asleep state is indicated by high delta activity in the frontal
electrodes:"
alarmAsleep := ((sample at: 1) at: 1) +
((sample at: 3) at: 1) +
((sample at: 7) at: 1) +


78
((sample at: 5) at: 1) // 4 > Loval.
(alarmAlert or: [alarmRelaxed or: [alarmAsleep]])
ifTrue: [state := RuleBase :?
detemineState (stateData, Threshold,
retumCondition, confidence).
(state = nil)
ifFalse: [self displayAlarm: (state at: 1)]
analyze: source
"Analyze data from the specified source."
Screen initializeForms.
ExpertStream nextPutAll: ('Expert System Analysis:');
cr.
self initializeExpert: source.
[self inputData: source] fork. "Concurrent Process"
[self checkData ] fork. "Concurrent Process"
[CheckDone]
vhileFalse: [].
outputFile nextPutAll: ExpertStream contents;
close.
Menu message: 'analysis completed'!
asymmetric: leftSample and: rightSample
"Answer vhether the indicated channel/bard pair is
asymmetric."
((leftSample > rightSample) and:
[ (leftSample rightSample // (rightSample + 1) 100) > Delta])
ifTrue: [*#left].
((rightSample > leftSairple) and:
[ (rightSample leftSauple // (leftSairple +1) * 100) > Delta])
ifTrue: [*#right].
"#neither!
checkData
"CONCURRENT PROCESS: Check successive epochs of data for
trends, low levels and asymmetries."
| sample |
DataTaken signal.
Processor yield.
[InputDone]
whileFalse: [DataReady wait.
sample := epochSample.
DataTaken signal,
self checkSample: sample


].
CheckDone := true!
79
checkSample: sample
"Check the sample for trends, lot/ levels, asymmetries, states,
artifacts and pathological conditions."
| leftSairple rightSample IChannel rChannel
UTemp IrTemp rlTerrp rrTemp ltDir rtDir lfDir rfDir |
i
1 to: 4 do: [:channel|
IChannel := channel.
rChannel := channel + 4.
ltDir := 0.rtDir := 0.lfDir := 0.rfDir := 0.
1 to: 4 do: [:band|
UTemp := O.lrTemp := O.rlTemp := 0.rrTemp := 0.
leftSample := (sample at: IChannel) at: band.
rightSample := (saitple at: rChannel) at: band.
self timeTrerd: IChannel band: band value: leftSample;
timeTrerd: rChannel band: band value: rightSample.
((self asymmetric: leftSairple and: rightSample) = #left)
ifTrue: [UTenp := leftSairple.
IrTenp := rightSample
].
((self asymmetric: leftSairple and: rightSample) =#right)
ifTrue: [rlTemp := leftSairple.
rrTenp := rightSample
]
Screen plot: IChannel band: band
llFoint: UTenp lrPoint: IrTenp
rlPoint: rlTeirp rrPoint: rrTenp.
Processor yield
]
Screen displayTtrend: IChannel
direction: (self totalTimeTrend: IChannel);
displayTtrend: rChannel
direction: (self totalTimeTrend: rChannel);
display Level: IChannel
level: (self level: (saitple at: IChannel));
displaylevel: rChannel
level: (self level: (sample at: rChannel))
].
Screen scroll.
self lowlnfer: saitple!
displayAlarm: retumArray
"Display the alarm type and its probability on the


80
ExpertStream."
| confidence retumCondition |
confidence := retumArray at: (retumArray size).
retumCondition := retumArray at: (retumArray size 1).
(confidence > Threshold)
ifTrue: [ExpertStream nextPutAll: retumCondition,
(confidence printPaddedTo: 5);
cr]!
initializeExpert: source
"Initialize the user variables and the input/output file
specifications required by the indicated source."
| subject |
InputDone := false.
CheckDone := false.
DataReady := Semaphore new.
DataTaken := Semaphore new.
epoch := 0.
epochSample := #((0000) (0000) (0000) (000 0)
(0000) (0000) (0000) (0000)).
TrendValues := Array new: 8.
1 to: 8 do: [:channel|
TrendValues at: channel put: (Array new: 4).
1 to: 4 do: [:band|
(TrendValues at: channel) at: band
put: #(000000)
]
]
"datafile input:"
source = 'd'
ifTrue: [subject
inputFile
outputFile
]
Prompter prompt: 'filespec:'
default: ''.
Disk file: subject.
Disk newFile:
(File fileName: (subject fileName)
extension: 'exp').
"memory input:"
source = 'm'
ifTrue: [subject := Prompter prompt: 'subject:1
default: '1.
outputFile := Disk newFile:
(File fileName: subject
extension: 'exp').
segment := 303.


81
offset := 303.
Dos new setReg: 0 to: segment;
setReg: l to: offset;
interrupt: 62
].
"port input:"
source = 'p'
ifTrue: [subject := Prompter prcnpt: 'subject:'
default: ''.
outputFile := Disk newFile:
(File filename: subject
extension: 'exp').
inputPort := Prompter
prompt: 'input port: 16r(hex #):'
defaultExpression: '16r301'
].
CharacterScanner new
initialize: Display boundingBox font: Font fourteenLine;
setForeColor: 11 backColor: 16;
display: subject at: 500 @ 1301
inputData: source
"CONCURRENT PROCESS: Input successive epochs of data from
the specified source until end-of-input is reached."
DataTaken wait.
[IrputDone]
vdiileFalse: [epoch := epoch + 1.
IrputDone := self readSanple: source.
DataReady signal.
DataTaken wait
]!
level: channelValues
"Answer whether the indicated channel average is low (red),
medium (green) or high(blue)."
| channelAve |
channelAve := 0.
1 to: 4 do: [:band|
channelAve := channelAve + (channelValues at: band)
]
channelAve := channelAve // 4.
((channelAve > Lcval) and: [channelAve < Hival])
ifTrue: [10].
(channelAve <= Lcval)


82
"91
ifTrue: ["12].
lcwlnfer: sample
'Determine a state alarm condition exists, and activate a
high-level inferencer if it does."
| stateData abnormal |
abnormal := false.
stateData := self makeList: sample.
self alarmArtifact: sample data: stateData.
(self alarmSlowing: sample data: stateData)
ifTrue: [abnormal := true].
"ignore subject's state if pathological conditions exist:"
"abnormal
ifFalse: ["self alarmState: sample data: stateData"]"!
makeList: sanple
"Answer a Prolog-type list made from a SmallTalk-type
array."
| sTemp cArrayl cArray2 |
sTerrp := Array new: 8.
cArrayl := #(1 3 7 5).
cArray2 := #(2 4 8 6). 1
1 to: 4 do: [:band|
STerrp at: band
put: (List with:
with:
with:
with:
)
to: 4 do: [:band|
sTerrp at: (band + 4)
put: (List with:
with:
with:
with:
((sample at:
((sample at:
((sanple at:
((sanple at:
((sample at:
((sanple at:
((sample at:
((sanple at:
]
"List
with: (List with: (STerrp at: 1)
with: (STerrp at: 2)
with: (STerrp at: 3)
with: (STerrp at: 4) )
with: (List with: (STerrp at: 5)
(cArrayl at: 1)) at: band)
(cArrayl at: 2)) at: band)
(cArrayl at: 3)) at: band)
(cArrayl at: 4)) at: band)
(cArray2 at: 1)) at: band)
(cArray2 at: 2)) at: band)
(cArray2 at: 3)) at: band)
(cArray2 at: 4)) at: band)


83
with: (sflemp at: 6)
with: (gTenp at: 7)
with: (sffenp at: 8) )!
readlnteger: input
"Answer an integer (maximum size = digits) from an ASCII
data file."
| decade digits size integer tl 12 |
decade := 1.
digits := 5.
size := 0.
integer := 10.
tl := Array new: digits.
12 := Array new: digits.
1 to: digits do: [:i|
tl at: i put: 0.
t2 at: i put: 0.
decade := decade 10
].
decade := decade // 10.
[(integer between: 0 and: 9) or: [input atEnd]]
whileFalse: [integer := input next asciiValue 48].
[integer between: 0 and: 9]
whileTrue: [size := size + 1.
tl at: size put: integer,
integer := input next asciiValue 48
] 1
1 to: size do: [:i|
t2 at: (digits size + i) put: (tl at: i)
]
integer := 0.
1 to: digits do: [:i|
integer := integer + ((t2 at: i) decade).
decade := decade // 10
]
input atEnd ifTrue: [integer := 0].
"integer!
readSample: source
"Read in the next epoch of EEG data from the specified source,
and answer whether the end-of-input has been reached."
| eof pointer datum |
eof := 999.


pointer := offset.
1 to: 8 do: [:channel|
1 to: 4 do: [:band|
(source = 'd') "datafile"
ifTrue: [inputFile atEnd ifTrue: [true].
(epochSairple at: channel) at: band
put: (self readlnteger: inputFile).
]
(source = 'm') "memory address"
ifTrue: [datum := (Dos new peekFrcm:
segment § pointer).
(datum = eof) ifTrue: [true].
(epochSample at: channel) at: band
put: datum.
pointer := pointer + 1
]
(source = 'p')"port address"
ifTrue: [datum := (Dos new inByteFrcm: inputPort)
(datum = eof) ifTrue: [true].
(epochSample at: channel) at: band
put: datum
]
Processor yield
]
]'
false!
timeTrend: aChannel band: aBand value: nextValue
"Determine the time trend-slope of the channel/band,
viewed over a 5-epoch window."
| slope |
slope := 0.
1 to: 4 do: [:i|
((TrendValues at: aChannel) at: aBand) at: i put:
(((TrendValues at: aChannel) at: aBand) at: (i + l)).
]
((TrendValues at: aChannel) at: aBand) at: 5 put: nextValue.
slope := nextValue
- (((TrendValues at: aChannel) at: aBand) at: 1).
(slope abs < SlopeMin) ifTrue: [slope := 0].
((TrendValues at: aChannel) at: aBand) at: 6 put: slope!
totalTimeTrend: aChannel


"Answer the total slope, including all bands, of the
channel."
| slope |
slope := 0.
1 to: 4 do: [:band|
slope := slope
+ (((TrendValues at: aChannel) at: band) at: 6)
]
(slope > 0) ifTrue: [A9].
(slope < 0) ifTrue: ["12].
"16! !
Prolog subclass: #EEGruleBase
instanceVariableNames: 1'
classVariableNames: "
poolDictionaries: 1' !
lEEGruleBase class logicMethods !
lEEGruleBase logicMethods !
"Produce the weighted sum from the weighting and input matrices.
dcMatrix( [ [ [ild, i3d, i7d, i5d], [ilt, i3t, i7t, i5t],
[ila, i3a, i7a, i5a], [ilb, i3b, i7b, i5b]],
[[i2d, i4d, i8d, i6d], [i2t, i4t, i8t, i6t],
[i2a, i4a, i8a, i6a], [i2b, i4b, i8b, i6b]]],
[[[Wld, w3d, w7d, w5d], [wit, W3t, w7t, W5t],
[wla, w3a, w7a, w5a], [wlb, w3b, w7b, w5b] ],
[ [W2d, w4d, w8d, w6d], [w2t, w4t, W8t, w6t],
[w2a, w4a, w8a, w6a], [w2b, w4b, w8b, w6b]]],
confidence)
is(confidence,
(wld * ild) + (W3d * i3d) + (w7d * i7d) + (w5d * i5d) +
(wit * ilt) + (w3t * i3t) + (w7t * i7t) + (w5t * i5t) +
(wla * ila) + (w3a * i3a) + (w7a * i7a) + (w5a * i5a) +
(wlb * ilb) + (w3b * i3b) + (w7b * i7b) + (w5b * i5b) +
(w2d * i2d) + (w4d * i4d) + (w8d * i8d) + (w6d * i6d) +
(w2t * i2t) + (w4t * i4t) + (w8t * i8t) + (w6t * i6t) +
(w2a * i2a) + (w4a * i4a) + (w8a * i8a) + (w6a * i6a) +
(w2b * i2b) + (w4b * i4b) + (w8b * i8b) + (w6b * i6b)
lEEXlruleBase logicMethods !
"FACTS FOR EEC ANALYSIS:


Template:
condition([ [ [ dl, d3, d7, d5],
[ tl, t3, t7, t5],
[ al, a3, a7, a5],
[ bl, b3, b7, b5] ],
t [ d2, d4, d8, d6],
[ t2, t4, t8, t6],
[ a2, a4, a8, a6],
[ b2, b4, b8, b6] ] ]
'returnstring ')
"Facts for artifact determination."
artifact ([ [ [ -6, 20, 20, -6],
[ o, o, o, 0],
t o, o, o, 0],
[ o, o, o, 0] ],
[ [ -5, "9, -9, -5],
[ o, o, o, 0],
[ o, o, o, 0],
[ o, o, o, 0] ] ],
'eye movement ')
artifact([ [ [ o, o, o, 0],
[ o, o, o, 0],
[ o, o, o, 0],
[ 20, -20, -20, 20] ],
[ [ o, o, o, 0],
[ o, o, o, 0],
[ o, o, o, 0],
[ 20, -20, 20, -20] ] ],
'muscle movement ').!
"Facts for determination of pathological condition existence.
pathCond([ [ [ 20, 20, 1, 1],
t 12, 12, -1, -1],
[ -3, -3, -3, 3],
[ -3, -3, -3, -3] ],
[ [ "I, -1, -1, -1],
t "I, -1, -1, -1],
[ -4, -4, -4, -4],
[ -4, -4, -4, -4] ] ]
If slewing ')
pathCond([ [ [ 1, 1, 20, 20],
[ -1, -1, 12, 12],


87
[ -3, -3, 3, -3],
[ 3, -3, -3, -3] ],
t [ -1, -1, -1, -1],
[ -1, -1, -1, -1],
[ -4, -4, -4, -4],
[ "4, -4, -4, -4] ] ],
'rf slewing ')
pathCond([ [ [ 20, 20, 20, 20],
[ 10, 10, 10, 10],
[ -5, -5, -5, -5],
[ -5, -5, 5, -5] ],
[ [ 2, -2, -2, -2],
[ -2, -2, -2, -2],
[ "8, -8, -8, -8],
[ -8, -8, -8, -8] ] ],
'f slowing ')
pathCond([ [ [ -1, -1, 1, -1],
[ -1, -1, -1, -1],
[ "4, -4, -4, -4],
[ -4, -4, 4, -4] ],
[ [ 20, 20, 1, 1],
[ 12, 12, -1, -1],
[ -3, -3, -3, -3],
[ -3, -3, -3, -3] ] ],
'lp slewing ')
pathCond([ [ [ "I, 1, -1, -1],
[ -1, -1, -1, -1],
[ -4, -4, -4, -4],
[ -4, -4, -4, -4] ],
[ [ 1, 1, 20, 20],
t -1, 1, 12, 12],
[ "3, 3, -3, -3],
[ -3, "3, -3, -3] ] ],
'rp slewing ')
pathCond([ [ [ -2, -2, -2, -2],
C-2, 2, -2, -2],
[ "8, -8, -8, -8],
[ -8, 8, -8, -8] ],
[ [ 20, 20, 20, 20],
[ io, 10, 10, 10],
[ "5, -5, -5, -5],
[ -5, -5, -5, -5] ] ],
'p slewing ').


88
pathCond([ [ [ 20, 20, 20, 20],
[ 6, 6, 6, 6],
[-13, -13, - -13, -13],
[-13, -13, - -13, -13] ]
t [ 20, 20, 20, 20],
[ 6, 6, 6, 6],
[-13, -13, ' -13, -13],
[-13, -13, - -13, -13] ]
'global slowing ') i
"Facts for state determination."
state([ [ [ -8, -8, "8, -8],
[ -8, -8, "8, -8],
[ 3, 3, 3, 3],
[ 6, 6, 6, 6] ],
[ [ -8, -8, -8, -8],
[ "8, -8, -8, -8],
[ 3, 3, 3, 3],
[ 20, 20, 20, 20] ] ]
'alert ')
state([ [ [ 20, 20, 20, 20],
[ 3, 3, 3, 3],
[ -8, -8, -8, -8],
[ -8, "8, -8, -8] ],
[ [ 6, 6, 6, 6],
[ 3, 3, 3, 3],
[ -8, -8, -8, -8],
[ -8, -8, "8, -8] ] ]
'asleep )
state([ [ [ -8, -8, -8, -8],
[ "8, "8, -8, -8],
[ 6, 6, 6, 6],
[ 3, 3, 3, 3] ],
[ [ -8, -8, -8, -8],
[ "8, -8, "8, -8],
[ 20, 20, 20, 20],
[ 3, 3, 3, 3] ] ]
'relaxed ') .! !
!EEGruleBase logicMethods !
"RUIEBASE FOR EEG ANALYSIS:


Template:
determineCondition (IMatrix,
threshold,
conditionstring,
confidence)
condition (vMatrix, conditionString),
doMatrix (iMatrix, wMatrix, confidence),
ge(confidence, threshold)."
"Rule: Determine if an artifact exists."
determineArtifact (IMatrix,
threshold,
conditionstring,
confidence) :-
artifact (vMatrix, conditionstring),
dcMatrix( iMatrix, vMatrix, confidence),
ge(confidence, threshold).!
"Rule: Determine if a pathological condition exists."
determinePathCond (iMatrix,
threshold,
conditionstring,
confidence) :-
pathCond (vMatrix, conditionstring),
doMatrix(iMatrix, vMatrix, confidence),
ge(confidence, threshold).!
"Rule: Determine the state of the subject."
determineState (iMatrix,
threshold,
conditionstring,
confidence) :-
state (vMatrix, conditionstring),
doMatrix(iMatrix, vMatrix, confidence),
ge(confidence, threshold).!
EEC subclass: #EEGgenerate
instanceVariableNames:
'high medium lew loColor mdColor hiColor inputFile matrixFile
classVariableNames:
'MatrixStream IOPane IOStream WeightMatrix MatrixPane 1
poolDictionaries:
'Character-Constants !
lEEGgenerate class methods !
weights


90
"Begin the matrix coefficient generation process."
self new initialize! !
lEEGgenerate methods !
generateMatrix
''Use test datafiles to generate the coefficients in a
weighting matrix."
| runs correctness inputMatrix confidence |
nans := 0.
correctness := 'c'.
WeightMatrix := Array new: 8.
1 to: 8 do: [:channel|
WeightMatrix at: channel put: (Array new: 4).
1 to: 4 do: [:band|
(WeightMatrix at: channel) at: bard put: 0
]
]
self selectlO.
[(inputFile atEnd) or: [correctness = 9]]
whileFalse: [MatrixPane cancel.
runs := runs + 1.
self printMatrix: WeightMatrix.
inputMatrix := self readMatrix.
self plotMatrix: inputMatrix.
confidence := self wSum: WeightMatrix
and: inputMatrix.
IOStream nextPutAll: ('run:
(runs printPaddedTo: 3),
' confidence:',
(confidence
printPaddedTo: 5) );
cr.
correctness := Prompter prompt:
enter correctnesses. .5> or 9 (quit)'
defaultExpression: '1.
(correctness = 9)
ifFalse: [WeightMatrix :=
self modify: inputMatrix
degree: correctness
epochs: runs
]
]
MatrixStream contents printQn: natrixFile.
matrixFile close.
Menu message: 'calibo^ition terminated'!


91
initialize
"Initialize the instance variables for color, input and
output."
high := 70.
medium := 40.
low := 10.
hiColor := 9.
mdColor := 10.
loColor := 12.
self cperiWindow!
ioPanel
"Return environment for the matrix and io panes."
* '!
mainMenu
"Answer the menu for the calibration panes."
"Menu
labels: 'find coefficients' withers
lines: #()
selectors: #(generateMatrix)!
modify: inputMatrix degree: correctness epochs: epochs
"Modify the weighting matrix upon with the next input matrix."
| newIM newWM iTexnp wTemp mean max top |
newIM := inputMatrix.
newWM := WeightMatrix
mean := 0.
max := 0.
top := 30.
(correctness = o) ifFalse: [
1 to: 8 do: [:channel|
1 to: 4 do: [:band|
iTenp := ((newIM at: channel) at: band)
* correctness.
(newIM at: channel) at: band put: iTenp.
mean := mean + iTenp.
]
].
mean := mean // 32.
1 to: 8 do: [:channel|
1 to: 4 do: [:band]
iTenp := ((newIM at: channel) at: band) mean.
(iTenp = 0) ifTrue: [iTeitp := 1].
wTenp := (newWM at: channel) at: band.


92
WTemp := WTemp (epochs 1) + iTemp // epochs,
(max >= (WTenp abs))
ifFalse: [max := (WTenp abs) ].
(nevMM at: channel) at: band put: WTenp
]
]
1 to: 8 do: [:channel|
1 to: 4 do: [:band|
WTemp := (newWM at: channel) at: band.
WTeinp := WTenp top // max.
(newWM at: channel) at: band put: WTenp
]
]
]
*newWM!
cpenWindcw
"Open the calibration winders."
| tcpPane |
tcpPane := TcpPane new
label: 'Automatic Coefficient Generator';
backColor: 16;
foreColor: 3;
menu: #topMenu;
model: self;
yourself.
tcpPane addSubpane: (GraphPane new
model: self;
name: #pattemPanel:;
menu: #mainMenu;
change: #pattemChange:;
framingRatio: ( 1/2 @ 0
comer: 1 @ 1) ).
tcpPane addSubpane: (IOPane := TextPane new
model: self;
name: #ioPanel;
menu: #mainMenu;
framingRatio: ( 0 @ 0
comer: 1/2 @ (1/2) ) ).
tcpPane addSubpane: (MatrixPane := TextPane new
model: self;
name: # ioPanel;
menu: #mainMenu;
framingRatio: ( 0 @ (1/2)
comer: 1/2 @ 1 ) ).
MatrixStream := MatrixPane dispatcher.
IOStream := IOPane dispatcher.
tcpPane reframe: (Display boundingBox).
tcpPane dispatcher openWindcw scheduleWindcw!


93
pattemChange: box
"Null mouse return in pattern pane."
pattemPanel: box
| hArray vArray |
hArray := #(329 486 329 486).
vArray := #( 25 25 187 187).
(ColorForm new width: box width
height: box height
initialColor: 8)
displayAt: box origin.
1 to: 4 do: [:band|
(ColorForm new width: 144
height: 144
initialColor: 16)
displayAt: (hArray at: band) 8 (vArray at: band)
]
CharacterScanner new
initialize: Display boundingBox font: Font fourteenLine;
setForeColor: 11 backColor: 8;
display: 'delta' at: 380 8 170;
display: 'theta' at: 537 8 170;
display: 'alpha' at: 380 8 331;
display: 'beta' at: 537 8 331;
setForeColor: 12 backColor: 8;
display: '1' at: 445 8 170;
setForeColor: 10 backColor: 8;
display: 'm' at: 475 8 170;
setForeColor: 9 backColor: 8;
display: 'h' at: 505 8 170.
"ColorForm new width: box width
height: box height
initialColor: 8!
plotMatrix: matrix
"Plot the indicated matrix with the appropriate colors."
| sample |
1 to: 8 do: [:channel|
1 to: 4 do: [:band|
sample := (matrix at: channel) at: band.
(sairple < low)
ifTrue: [self plotValue: channel
band: band
level: 12
].