Blackboard Systems at the Architecturemq853nj9727/mq853nj9727.pdf44 H.P.Nii FIGURE1....

Expert Systems With Applications, Vol. 7, pp.

43-54,

1994Printed in the USA.

0957-4174/94

$6.00

+ .00

©

1993 Pergamon Press Ltd.

INVITED PAPER

Blackboard Systems at the Architecture Level

H. PennyNiiKnowledge Systems Laboratory, Computer Science Department, Stanford University,

Stanford,

CA

Abstract—SinceHearsay-11, many applicationsystems using theblackboardarchitecturehavebeenbuilt. Some of these applications have been built using expert system shells or tools. These toolscontain theskeletalconstructs ofblackboard systems into which theuser addsthenecessaryinformationandknowledgefrom the applicationdomain to create an application system. Although the toolsareuseful in the implementationphase, they provide littlehelp in the design ofthe system, which mustnecessarilyprecedethe implementationphase. Thedeterminationofthe blackboard levels, theknowl-edgesources, and the details ofthe control strategy is a taskreservedfor the knowledge engineer/system designer. In order to automate the designprocess, one needs to understand therelationshipsbetween the architecturalconstructs and domain information thatprovide the semantics ofthe ar-chitecture. In thispaper theauthors explorethecomponentsofblackboard systemsfrom theperspectiveofthe type ofknowledge that goes into the makeupofblackboard systems at the architecture level.They describearesearch system,

KASE,

that captures the variousknowledge neededfor design andapplies theknowledge to aidknowledge engineers design blackboardsystems.

1. INTRODUCTIONThe terms "blackboard model," "blackboard archi-tecture," and "blackboard system" are associated witha particular class of software programs. An attemptwas made in Nii (1986) to distinguish the differencesbetween a model, a framework (or, an architecture),and an application system. The modelwas viewed asa conceptualproblem-solving entity consisting of twobasic components, a global data base called theblack-board, and knowledge sources that created and mod-ified the contents of the blackboard. The model in-cludes a description of its behavior. An attempt at ab-stracting the software constructs ofvarious applicationsystems resulted in a blackboard architecture. In ad-dition to theblackboard and the knowledge sources, ablackboard architecture includesa control componentthat enables the realization ofthe behavior in a serialcomputing environment (see Fig. 1). The applicationsystems can be described as the instances and/or spe-cializations ofthe architecture. The description oftheapplication task and the associated task domain servesto establish a vocabulary to describe the specifics of

Requests for reprints should be sent to H. Penny Nii, KnowledgeSystems Laboratory, Computer Science Department, Stanford Uni-versity,

Stanford,

CA 94305, USA.

the blackboard data structure, the knowledge sourcecontents, and theproblem-solving behavior ofthe dif-ferent systems.That is, the application domain providesthe semantics of the architecture.

There has been a steady increase in the number ofblackboard systems [a recent exampleis Springer, Butaetal. (1991); older examplescan befound in Engelmore& Morgan (1988); Corkill & Gallagher(1989); Jagan-nathan, Dodhiawala et al. (1989); Velthuijsen (1992)],but the designs of these systems continue to fit withinthe blackboard architecture describedearlier. Althoughthe implementationdetail maydiffer greatly, the basicarchitecture ofthe blackboard systemshas not changedover the years. This situation provides us with an op-portunity to study the various properties ofarchitec-ture, in particular, theblackboard architecture. Whatis an architecture? What is its form? What implicit in-formation is embedded within an architecture? And,of particular interest to the knowledge system com-munity, whatkinds ofknowledge are neededto designa system, and what roles do these differentkinds play?

KASE (Knowledge Assisted Software Engineering)is a research project whose goal is to build a set ofpower tools for software analysts and designers at thearchitecture level. The tools should contain sufficientknowledge about theartifact and thedesign process toenable the automation of many of the activities in-

44 H. P. Nii

FIGURE 1. Blackboard architecture.

volved in design. Although its focus has been on an-swering the questions posed abovefor architectures ingeneral, KASE has used a blackboard architecture asits first test bed. From the point ofview ofblackboardsystems, the project represents an attempt to codifyvarious kinds ofknowledge aboutblackboard systems.

In this paper we describe the constituent compo-nents ofan architecture in terms oftheknowledge do-mains neededto construct an architecture. In partic-ular, webegin with thecontents ofa genericblackboardarchitecture. We than describe a knowledge-basedtechnique for specializing the generic architecture tocreate application-specific architectures using domaininformation.

2. THE ARCHITECTURE LEVEL

A software architecture is an abstraction of softwaresystems. It comprises a topology of functional com-ponents, the interfaces between the components, andthe semantic contents of these constituent parts. Anarchitecture is usually describedhierarchically to showdifferent levels ofdetail, and at the most detailed levelit must have sufficient detail toserve as aguide or spec-ifications to the codingprocess.

Often, an architecture is treated as one ofmultipleviews of a system. In LaSSIE (Devanbu, Brachman etal. 1991), for example, the system is partitioned into adomain model view, an architectural view, a featureview, and a code view. Others, for example Iscoe, Wil-liams et al. (1991), focus on the domain model as abasis for softwaredesign. The difficultywith separatingthe domain model and the architecture is that the do-main information forms the basis for the semantics ofthe architecture and must be expressible in terms of,as well as within, the computational constructs thatmake up the architecture.

A software architecture is a product of integratingknowledge from multiple knowledge domains. In herstudy of human software designers, Guindon (1990)

found thatdesignersdrew on manykinds ofknowledge,including knowledge about the domain, knowledgeabout problem solutions and theirrepresentation, andknowledge about design schemas and computationalconstructs.

InKASE, an attempt has been made to identifyinvarious software architectures their constituent knowl-edge domains and to discovertherelationships amongthem. The objective is to rationalize software designsinorderto identifyusefulknowledge-based designtoolstohelp in theprocess of designsynthesis.KASE beginswith a generic architecture. A generic architecture isan abstract architecture designed to solve a particularclass ofproblems (Bhansali & Nii, 1992a). KASE hasbeen working with a class ofproblems called trackingproblems in which the task is to identify and trackobjects in space based on signaldata.

A generic architecture represents design decisionsand, by its very nature, is associated with certain ar-chitectural commitments. The design decisions areguided byknowledge in the following areas:1. A problem, ora task, class. The selection ofaprob-

lem class establishes an ontology of generic termswith which todescribe thetask, and the objects andthe operations in the problem class. Diagnostics,tracking, payroll,and transaction processingare ex-amplesofproblem classes.

2. A solution strategy. An architecture is a commit-mentto solve a problemusing a particularproblem-solving strategy. Thus, there may be more than onearchitecture associated with a problem class repre-senting different ways to solve the problem. Oneway to solve a tracking problem, for example, is tocumulate incrementally and opportunistically evi-dencefor the identityand thebehavior ofthe objectsbeing tracked.

3. Design schemas (architectural constructs). The so-lution strategy is realized using a variety of designschemas, such as pipelinesand layeredhierarchies.[See Shaw (1991) for a description of architecturalconstructs.] The incremental and opportunisticproblem-solvingstrategyfor tracking problemscanbe realized using a blackboard architecture, whichin turn is made up ofwhat Shaw calls "interpreter"constructs.Figure 2 shows how the decisions within these

knowledge domains determine the shape ofa genericarchitecture. In short, a genericarchitecture representscommitments to (1) a particularclass ofproblems, (2)a solution strategy for that class, and (3) the architec-tural constructs used to realize the strategy.

The process of designing a specific applicationis aprocess ofmapping domain information onto the ar-chitecture. To automate this process, the generic ar-chitecture needs two typesof associated knowledge.1. Customization knowledge. Associatedwith a generic

architecture isknowledge about how to customize

Blackboard Systems at theArchitecture Level 45

i

In this section we revisit blackboard systems in termsoftheconcepts justdescribed. We describe the variouscommitments inherent in blackboard systems by re-viewing thetaskcharacteristics thatare suited to black-board architecture. In Section 4 we discuss the differ-ences inblackboard architectures that can be attributedto different solution strategies. In Section 5 we discusssome of the ways in which the components of black-boardsystems can be designedsemi-automatically.Fi-nally, in Section 6 we describe, using two examplesfrom a trackingproblem class, automated tools from

One way to categorize a problem-solving approach isby determining whether it uses a search or arecognitionmethod of problem solving. Recognition is a termcoined by McDermott andNewell (1982)—"thecom-plete recognition does not search, it knows." At anyparticular computational state, instead of generatingand evaluating the possible nextstates as in search, arecognition system simply knows what the next stateshould be. A classic exampleof a blackboard systemthat uses search as its solution strategy is HEARSAY-II (Erman, Hayes-Roth et al., 1980), and one usingrecognition strategy is HASP (Nii, Feigenbaum et al.,

__._.__-—_—— ser

Problem |C»stomiz»Uon I Iclassy I Knowledge |>^ __JL^

\.^^^^^^^ yDesign/ A SpecificSolution ?S Get[eri<; h >T^s_ des'PX [architecture |strategy^ --jSS^. [^ TDesign/ \

schemas I _ fe s*~~ i n . imC!a _ |>(jnstantiate)-> Domammodel 1 n^ model

User

C3System provided CD Usercreated O Process

FIGURE 2. Constituentcomponents ofgeneric architectures and theirrelationships to application-specific architectures.

the architecture into application-specific architec- KASE for designing specific blackboard systemsfromtures. This knowledge includes how to instantiate a generic architecture,components ofthe architecture in terms ofthe spe-cificfunctionalities ofthe application domain. Cus-tomization knowledge captures design knowledge 3.1. Task Characteristicsthat is specific to the architecture. For example, the The applications for which the blackboard approachcustomization knowledge for the problems using has been useful

_ignal understandings vision?

the blackboard approach may include a heuristic: and situation assessment (Engeimore & Morgan, 1988;"Each intermediate data class needed to solve a Jagannathan) Dodhiawala et al. 1989). These appli-problem should be a level in the blackboard data share common characteristics:structure. j The probiems are complex and ill-structured with

2. Meta-model. Also associated with a generic archi- Jarge spaces Systematic generation ofso-tecture is an ontology of generic terms established lution candidates is neither possible nor feasible.by the commitment to a problem class. Called a 2 Jhe solutiom require situation-dependent,or op-meta-model, it contains the necessary vocabulary portimistic, invocation ofdiverse sources ofknowl-for describing the task and the domain. A domam edge Jhat control decisions are made while themodel for a specific application is built by mstan- problem {s solyed instead of using a prk)ritiating this ontology.For the trackingproblemclass, established control paths.the generic terms include "objects-to-be-tracked 3 oftenj problems demand both synthetic andand "signal-data," a. welUs thekgenericproperties, analytic processes These often translate into bot-such as, "location" and "speed." tom-up information fusion or composition, and top-An application-specific architecture can be defined down modd_based reasoning.

as a genericarchitecture instantiated with informationfrom the application domain (Figure 2).

3.2. Solution Strategies: Search vs. Recognition

3. BLACKBOARD SYSTEMS REVISITED „_ ___

+/

_ _+ "_

n

mMtw

,^^ a awwnQ^

;

c

46 H. P. Nii

I

1982). 881 is an exampleofa shell that allows for theuse ofboth strategies (Hayes-Roth, 1985).

In the search paradigm, eachstep in problem solvingrequires an evaluator to select from a pre-enumeratedor enumerable next state. Each problem-solving stepconsists ofa generationofoperatorsor state, followedby an evaluation, followed by a selection and an ap-plication of the state transforming operator. Often,evaluation precedes generation so that generation canoccur selectively. The generatorcan be algorithmic orheuristic; it can be a legal-move generatoror a plau-sible-move generator.The evaluator can beknowledge-poor (general and weak), or it can be knowledge-rich(task-specific). To date most programsthat use searchuse weak knowledge—the search paradigm is called aweak method.

In HEARSAY-II all the possible states were enu-merable by its knowledge sources. For example, givenagrammar, a table ofall legal adjacent words for eachword could be generated. Theevaluator,or the sched-uler, used weakcriteria. For example, criteria from se-lecting from a number of possible word sequencesmight use the number ofwords in the sequence. Theknowledge is weak, because it does not use task-specificcriteria,orwhen used, the task-specific criteria areverysimple. A hypothetical, knowledge-rich criterion mightbe: "select a word sequence beginning with a prepo-sition following a noun clause."

In the recognition paradigm, the knowledge basemust be scanned for a pieceofknowledge that can beapplied tothe current situation. This is called the matchstep. Each problem-solving step consists of a matchstepfollowed bytheapplication ofa state transformingoperator.If a piece ofknowledge is encoded as a con-ditional if-thenrule, then itcontains information aboutwhat the next state would be as well as the situationunderwhich the state transformation can occur. Mostcurrent expert systems are recognition systems. (Itshould be noted that if-then rules are not necessaryfor arecognition system, and conversely the mere useof if-then rules does not imply a recognition system.The problem-solving approach is independent of theknowledgerepresentation.)

In HASP the search paradigm was tried and failed,because there was no generatorof the solution space.It was one ofthe first complete recognition systems. Itconsisted of 40-50 knowledge sources, each with anaverageof 10 rules. The active knowledgesources con-sisted of domain- and situation-specific pieces ofknowledge that "knew" what to infer or what actionto takefor each intermediatesolution state. In addition,it had a plan for the application of theknowledge intheform ofcontrol knowledgesources.

In the next section we elaborate on the basic differ-ences in system architectures attributable to the differ-ences between the search andrecognition methods ofproblem solving.

4. ARCHITECTURAL IMPLICATIONS OFDIFFERENT SOLUTION STRATEGIES

4.1. Search

As stated earlier, searchrequires at least a generatorofthe solution space and an evaluator. The evaluationcan be of two types: a local look-ahead that evaluatespossible future states; anda global evaluator thatselectsthe best operatorbased on the information providedby the look-ahead or the overall state of the solution.In the HEARSAY-II architecture, the action part ofthe knowledge source was used as a generator(see Fig.3). Uponits execution, the action partofthe knowledgesource placed on the blackboard new hypotheses. Thecondition part served as a look-ahead for the actionpart. When executed, it determined the state changesthat would be produced if its action part were to beexecuted. Thescheduler decidedon the nextactivity—either to look-ahead or to generatechanges; that is, itdetermined the solution pathbyevaluating thecurrentstate ofthe solution and a set ofpossiblefuture states.

In HEARSAY-11, the global evaluation criteria washidden inside the scheduling module; that is, thescheduling module was a primitive module.

Within the search paradigm the quality of the so-lution may depend on the amountofsearchconducted,which is also a function ofthe quality oftheknowledgeavailable for evaluation. The premise in HEARSAY-II is that a favorable trade-off can be made betweenthe amount of control knowledge and knowledgesource activations—that is, spending time on evalua-tion pays off in reducing search and in improving thequalityofthe solution.

4.2. Recognition

The recognition problem-solving paradigm is concep-tually simpler than the search paradigm (see Fig. 4).Here, the knowledge base is scanned for a piece ofknowledge that can be applied to a state. Of course,

-^ Data flow _^ Control flowFIGURE 3. Control architecture for search.

47Blackboard Systems at theArchitectureLevel

r

.^ Data flow -_>> Control flow

FIGURE 4. Control architecturefor recognition.

theremaybe many pieces ofknowledge applicable fora given state, and a decision must be made whether toapply all the pieces ofknowledge or a subset of them.This control decision can be algorithmic (for example,first-in-first-out) or it can be knowledge-based. Whenthecontrol decision isknowledge-based, there is a cer-tain amount ofuniformitybetween the way decisionsare made about whichknowledge to apply and aboutthe manipulations ofthe solution space objects. In rec-ognition-oriented blackboard systems, the conditionpart of the knowledge source specifies the situationsunder which it can contribute to the solution state.The action part of the knowledge source changes thesolution state. Since the applicable knowledge sourcefor any given situation is predetermined, in the sensethatknowledge sources are alwaysassociated with sit-uations, the scheduler focuses on the selection of thebest region ofthe solution space (the specificsituation)toprocess next.

In theory, no distinction is made between controland domain-specific knowledge in recognition systems.However, since a domain knowledge source looks attheblackboard data, and a control knowledge sourcelooks at a description ofthe changes to the blackboardin addition to the specifics ofthe changes, theyare infact different. It might be said that the control knowl-edge source has wider scope. Because control knowl-edgeis different from otherknowledge sources, systemscan be designed to exploit the differences. Informalplans either can be built into thecontrol structure ordynamically generated. In 881 (Hayes-Roth, 1985)control plansfor the execution ofthe domainknowl-edge sources are dynamically created.

5. ARCHITECTURAL ALTERNATIVES

Some ofthe architectural differences between HEAR-SAY-like and HASP-like systems can be attributed tothe different computational methods inherent in theuse of search and recognition paradigms. There arealso variations in the structure of the components of

the architecture driven by the different needs within aproblem class or the specific application itself. Thesedifferent architectural schemas can be stored in a li-brary. The designer can select appropriate designschema for the various component parts of the archi-tecture. For example,as mentioned earlier,knowledgesource selection may be algorithmic or knowledge-based, and the library may contain several differentknowledge-selection modules. In this section we de-scribe some ofthe alternative constructs for the majorcomponentsofthe blackboard architecture.

5.1. The BlackboardIn addition to serving as a medium ofcommunication,and thus of cooperation, between the knowledgesources, theblackboard represents a design of the so-lution. Since it is a data structure, one could not quitecall it a problem-solving plan, yet in the process ofproblem formulation the structure of the blackboardserves as thebackbone ofthe system design. It is wherethe design process begins. The blackboard partitionsthe solution space, and these partitions dictate whatknowledge sources will be neededto solve the problem.What constitutes a solution, what intermediate solu-tions are needed or available,what relationships existamong hypotheses, must all be expressed within theblackboard structure.

From the standpoint ofstructure there is very littlevariability in the blackboard. The blackboard is orga-nized into levels corresponding to the solution spacepartitions. These form either abstraction or composi-tional hierarchies. The objects on a given level sharethe same properties, or vocabulary.

5.1.1. Levels. As a data structure, the level object holdsinformation about the nodeson its level. For example,it must keep the names of the attributes of the nodesand maintain housekeeping information, such as thenumber ofnodes on the level at any given time. Forthese reasons, it is often convenient to view the levelobject as a class, and the nodes on the level as theinstances ofthe class. This has the further advantagethat nodes can inherit default property values at nodecreation time. Also, operators (methods) associatedwith creation and destruction of nodes can be storedwith the level object.

5. 1 .2. Nodes. Nodes areobjects on alevel;for example,aparticular word in a sentence is a node on the wordlevel in HEARSAY-11. Nodes are created dynamicallyas they areneeded. The vocabulary relevant tothe levelofanalysis is represented as attributes and values;eachnode on the level shares thesame attributes. In an ob-ject-orientedprogramming languageslots andslot-val-ues can be used, and there is nothing topreclude theuse ofrecord structures available in other languages.

48 H. P. Nii

1

5.1.3. Attribute Values. The value ofan attribute canhave multiple fields; for example, credibility value and/or time stamps. Often it is useful to maintain valuehistory. This is especially true in continuous-input sig-nalunderstanding programs in which temporal trendsare important. In object-oriented systems, a value canbe representedas a method that computes it when theslot is accessed.

5.1.4. Panels. Panels are useful when more than onehierarchy is neededtorepresentthe solution statedata.The most common use of a second panel is to holdcontrol-related information, as in 881.

5.2. The Knowledge SourcesA knowledge source represents knowledge needed tosolve a sub-problem. All knowledge sources are event-triggered agents—the activation ofknowledge sourcesare solution-state-dependent,rather than beingprocess-dependent.The implication is that the mostimportantconsideration in the design ofthe knowledge source isitsabilitytoevaluate thecurrent stateoftheblackboard.

In all blackboard systems knowledgesources are de-signed with condition and action parts (Fig. 5).

5.2.1. Condition Part. The condition part can: (1)evaluate possible future states, or (2) make context-independent or context-dependentevaluation of thesituation on theblackboard. In HASP, possiblechangesto the blackboard were categorized into different"event" types. The name of the event type was usedto record a blackboard change. The event name wasalsoused as a triggering condition in thecondition partofthe knowledge sources. In this typeofconstruct thecondition partis context-independent—it doesnot takeinto consideration the specifics of the change. Alter-natively, the condition part can be a procedure thatevaluates the specifics ofthe change, making the trig-gering ofknowledge sources context-dependent as inHEARSAY-11.

One can think of the condition part as a filter forthe activation ofthe action part. In newer systems, thedesign of the condition part consists of multi-stagedfilters. The first stage, called the trigger, is usually acontext-independentfilter that is followed by a number

FIGURE 5. Use of filters in knowledge sources.

of context-dependent filters. If the action part of theknowledge source is a collection ofrules, then the con-dition part of the knowledge source can be viewed asa high-level filter for therule set. Rules have their owncondition parts that serve as more detailed filters fortherule actions.

5.2.2. Action Part. The action part of a knowledgesource makes modifications to the current blackboardstate. The action part canbe a procedure or a collectionofrules. The selection oftheknowledgerepresentationscheme is independent of the selection of solutionstrategies.

Each knowledge source can make one or morechanges to theblackboard. In a rule-based knowledgesource, multiple changes can come from multiple firingof rules, or from multiple actions on the right-hand-side of rules.

The changes to the blackboard are new solutioncandidates (and new data) or modifications to the ex-isting solution. Changesalso canbe made tothecontrolinformation, as in 881. In addition to changes to in-termediate solutions on theblackboard, state changescan occur from the posting of goals and sub-goals tobe achieved (Lesser & Corkill, 1983) or posting ofmodel-based expectations of changes to occur in thefuture, as in HASP.

5.3. The Control

Control is the most complex component ofthe black-boardarchitecture, and it can have manyarchitecturalvariations. The basic function of the control compo-nent is to select and apply knowledge sources in thecase ofrecognition-based systems, or the condition andaction components of knowledge sources in search-based systems. Major design differences occur in thefollowing areas: (1) schedulable entities—whetherpartsofthe knowledge sources are separate schedulable en-tities or not; (2) scheduling—whether thefocus of at-tention is based on events or on knowledge sources;(3) noticing—who notices the changes in the black-board; and (4) control data—where and in what formthe control data is stored.1 . Schedulable Entities: In a search-based architecture

thecondition and the action parts oftheknowledgesources are scheduled separately. In recognition-based architecture, eachknowledge source is sched-uled as a single entity. If the condition part is sat-isfied, than the action part is immediately executed.

One thing to note is that in the search-based ar-chitecture, theblackboard state maychangebetweenthe time a condition part and its action part areexecuted. In such asituation theconditionpart mustbe re-evaluated.

2. Scheduler: There are two bases on which to ap-proach the selection ofthe nextthing to do:

Knolwlege Source

Condition part Action partI Trigger I| If ...then... |

Conditionl if ...then...Condition 2

" * "

Blackboard Systems at the ArchitectureLevel 49

t

FIGURE 6. An event-orientedcontrol schema.

possible way to design a knowledge-orientedcontrol.

Aknowledge source, or knowledge sources, canbe selected on the basis of the current state oftheblackboard, or more specifically,on the latestchanges to the blackboard, which are calledevents. Called event-oriented scheduling, the fo-cus is on selecting the best solution island onwhich to base further computation. Most rec-ognition systems take this approach. Thebasicfunction of the scheduler is to decide where towork next. Figure 6 shows a simple event-ori-ented control schema.

a.

In reality, many problems can gain from a mixedstrategy of search and recognition, and 881, for ex-ample, allows for both event-oriented andknowledge-oriented scheduling.

5.3.1. Posting and Noticing Blackboard Changes.What changes areposted andwho notices thesechangesdiffer from systemto system. Often, insearch-orientedsystems, everychange to theblackboard is a candidatefor a solution, and there must be a knowledge sourceto evaluate each change. On the other hand, event-oriented recognition systems can process only thoseblackboard changesfor which there is availableknowl-edge. By making the event creation explicit, the rulewriter can control what blackboard changesmerit fur-theraction by the knowledge sources. For example, ifa newpiece ofevidence isfound to supporta hypothesisbut the only consequence is that the credibility ratingis increased, this change may not need tobe an event.

b. Aknowledgesource can be selectedon thebasisofwhat theknowledge source can contribute tothe current state. This approach, called knowl-edge-oriented scheduling, is taken most often insearch systems. The scheduler decidesamongthelook-ahead evaluators and the generatorsofthesolution space, and it applies the selected com-ponents to all the relevant data objects on theblackboard. Thebasic function ofthe scheduleris to decide what to do next. Figure 7 shows one

FIGURE 7. A knowledge-oriented control schema.

Control

, j , * il(Blackboard I -*

Select an eventi1' TControl panel " ' . x ,

Select KS fT T~ Ievent queu% (match event <- ' *%££?I 'f \ T,_ L . x sources

j 1\ &KSactions) I 1(Solution panel * TC

levels ExecuteKS Iaction partI » ' ■_>" Dataflow

I V 1 -_>. Control flow

ControluLn.ui_in___.-U-L-LrjjLn_____iY-_ii¥i_r~~"~~

""" ""

"■»-""«

.I , IBlackboard _j Select an activity |

■ ——| ORControl panel y EvaluatorY I■M_-H_M_M-n_^HMM-m-B-H-^-i-^n

activity queued ; Execute

■

■I __ 2£ condition part - - KnowledgeFT" ! 1%* I T> T w _,* sourcesSolution panel \ Generator y y I I

- , %

* Execute C-levels «<■ —.--"■ .. .I action part |I ' ' I V I "^ Dataflow

-^ Control flow

50 H. P. Nii

«

What blackboard changes should be events dependonthe application.

5.3.2. Control Data. Control information needed todrive the system alwaysresides outside theblackboardcontaining the solution state. In HASP different typesof changes to the blackboard (modification to nodes,expectationposting, and so on) werestored in separatedata structures. Each eventwas a recording ofthetypeofchange, thenode that was modified, the new values,the rule that made the modification. In HEARSAY-IIthe control data was stored on a global list, the sched-uling queue.The items on thequeuewere oftwotypes:information generated by the condition part thatpointed to its action part and all the places on theblackboard it could be applied to, and the names ofthecondition parts ofknowledge sources. Since HASP-like systemsfocus oneventscheduling, thecontrol dataareprimarily aboutevents;inHEARSAY-like systemsthat focus onknowledge source scheduling the controldata are primarily about knowledge sources.

In 881, control must determine what domainknowledge source to apply and to what object on theblackboard. The control problem is formulated as aplanning sub-problem, and its solution state appearson a separatecontrol panel. All data dealing with con-trol arepostedon thecontrol paneland are shared byboth thecontrol-planning and the domainknowledgesources.

5.3.3. Domain-specific Knowledge, Meta-knowledge,and Control Knowledge. The distinction between do-main-specific knowledge and meta-knowledge is notalways clear cut. Meta-knowledge, knowledge aboutknowledge, is often thought tobe weak, general, anddomain-independent. But, in both search and recog-nition systems, meta-knowledge is often treated ascontrol knowledge about what todo next,and this typeofknowledge isoften very domain-specific. In general,making distinctions between domain-specific and

meta-knowledge does not contribute much to the de-sign of the system; rather, it tends to distract. Insteadit is preferable to organize knowledge sources hierar-chically according to some control hierarchy. In mostsystems the control hierarchy partitions theknowledgesources into those that deal directlywith the emergingsolution states and those thatdeal with theprocess his-tory or problem-solving states, called control states.The knowledge sources that operate on control statesare called control knowledge sources.

6. DESIGNING APPLICATION SYSTEMSUSING A GENERIC ARCHITECTURE

Up to this point we have discussed the three types ofknowledge that are needed to create a generic black-board architecture—knowledge about the character-istics ofa class ofproblems, its solution strategies, andalternative design schemas torealize the solution strat-egy. As was shown in Figure 2, a generic architecturehas explicitely associated with it ( 1) ameta-model con-sisting of a set ofconcepts and objects to describe theclass of problems, and (2) knowledge about how tointegrate domain information with the generic archi-tecture to create application-specific architectures. Inthis section we describe these two items by means ofexamplesfrom work done on the KASE project.

6.1. A Generic Architecture For Tracking Problems6.1.1. The Tracking Problem. This class of problemscanbe describedsimply asfollows: Identify, track, andsometimes, infer the intentions ofobjects in space usingsignal information about the objects (see Fig. 8). Asexamples, we use the HASP and the ELINT (Brown,Schoen et al., 1986)problems. In HASP the objects tobe tracked are ships andsubmarines using passive sonarsignals. InELINT the objectstobe trackedareairplanesusingradar signals. In both problems, there are multiplesources of signal for each platform (engines and pro-

FIGURE 8. The tracking problem.

51Blackboard Systems at theArchitecture Level

*

FIGURE 9. A generic architecture fortracking problems (based on Figs. 4 and 6).

pellers on ships, for example), and the platforms maybe clustered together obviating individual platformidentification.

A generic architecture is most often created by ab-stracting common architectural constructs from severalapplications in a particular problem class. In the caseofblackboard systems, theblackboard architecture of-ten can be converted into a generic architecture for aproblem class by selecting the appropriate constructsfor the various components and renaming some ofthem to fit the application glass. Figure 9 shows a ge-neric architecture for tracking problemscreated in sucha manner. Thesolution strategyistouse therecognitionmethod with a simple context-independent,event-ori-ented control as shown in Figure 6. There are twoblackboard panels, one for the solution space and onefor control information.

6.1.2. Representation of Generic Architectures. InKASE, the generic architecture isrepresented as a col-lection ofhierarchicallyorganizedfunctional modules.Each module is an object describing services (opera-

tions andprocedures) thatit provides, that it has accessto, and that it needs to provide the promised services(see Fig. 10). Other relationships between the modulessuch asinput/output and controlrelationships, can bederived from the service information. For example, in-put to a module is the collection of data types of thearguments of the service functions that the moduleprovides, plus theresults ofthe services it uses.

In a genericarchitecture anyattribute ofthe modulescanbe abstractedas parameters.These parameters needto be instantiated with domain information. For thetrackingarchitecture the following operations andpro-cedures are treated as parameters: (1) the blackboardlevels and the properties of the objects on each level;(2) thecondition and the actionparts oftheknowledgesources; and (3) some control functions, such creatingeventtypesand selecting an eventfor focus ofattention.

In order to provide automated tools to help a de-signer instantiate the parameters, KASE needs infor-mation about the domain. As shown in Figure 2, thedomain information is acquired separately using theinformation in the meta-model.

supermodule a module thatcontains this module as a partsubmodule set of modules that are parts of this moduleset of modules that are parts of this moduleprovides set of services provided by this module to externalmodulesrequires set of servicesrequired by this module from other moduleshas-locally set of local data and procedures (services) within this modulehas-access-to setof modules thatcan provide services to this moduleinputs * dataflow into this moduleoutputs* data flow out of this modulecalls* modules called by procedures within this modulecalled-by* modules thatcall procedures provided by this module

FIGURE 10. Minimal internal representationof a module (Bhansali & Nii, 1992) (* derivedproperties).

52 H. P. Nii

*

Meta-model terms ELINT HASPaircraftcluster

fleetship

Object- to-be-tracked radar emitter sourceharmonicline

observationfeedback

line-segmentsignals intelligence-reportFIGURE 11. Some meta-model instantiation for HASP and ELINT.

6.2. Meta-Modeland Domain ModelsThe names ofthe components that were shown in Fig-ure 9 are parts ofthe meta-model associated with theproblemclass. For the class oftracking problems, someof the terms and concepts that form the meta-modelare: for domain objects—objects-to-be-tracked, signal-collection-sites, and signal-data; for relations—line-of-bearing; and for events—object-to-be-track-updated,and so on. The properties of these objects are parti-tioned into attributes and operations. Some of the ge-neric attributes and operations are: position, heading,andspeedfor theattributes;and create-object, compute-position, and compute-headingfor the operations.

The domain models are created by instantiating themeta-model objects. Figure 1 1 shows instantiated do-main-model objects for HASP and ELINT createdfrom the meta-model associated with the generictracking architecture. A radar-signal data in ELINT iscalled observation, and a sonar data reading over agiventime period is called line-segment.

Figure 12 shows typical attributes and propertiesforthe two applications. Typically, the attributes and op-erations are provided by the application designer.However, some generic operations, such as create-ob-jects (instantiated as create-cluster and create-source)

and compute-speedare providedas apart ofthe genericarchitecture. These operations can be instantiatedfor different applications as will be described in Sec-tion 6.3.

6.3. Customizing the Generic ArchitectureThe customization, or instantiation of the generic ar-chitecture, involves instantiating the parametersin thegeneric architecture using the information in the do-main model.Because thecustomization often involvesnon-simple parameters, for example, determiningknowledge sources, a variety of methods are needed.These methods may consist of selecting from a pre-computed listofalternatives, transforming an abstractschema using a set of transformational rules, or usingheuristics designrules and/oralgorithms. KASE storesall the necessarymethods in its customization knowl-edgebase (see Fig. 2). We illustrate the use ofsome ofthe design knowledge in the customization processthrough two examples.

6.3.1. Customizing Blackboard Levels. Given a do-main model, determining theblackboard levels isquitestraightforward. There are heuristic rules that suggestthe levels. Some are generic toblackboard architectures

idpositionheadingactivityspeedthreat-potential

create-clustersplit-clustermerge-clusterdelete-cluster

typepositionconfidenceevolution

FIGURE 12. A typical attributes and operations of objects in HASP and ELINT (Boxed operations are generic operationsthatarepart ofthe generic architecture).

Blackboard Systems at theArchitectureLevel 53

".

.

TrackingMeta-model HASP domain objects Blackboard levels

Trackinfi-agjents -Objects-to-be trackedSignals *

«

%Collection-sitesReport

.%

% .

FIGURE 13. Determining blackboard levels

in general: "Ifan object class is mentioned in the outputreport, then it should be a level," and "If an objectclass contains properties neededto compute any otherproperties, then it should be a level." Some others arespecific to the generic architecture for a problemclass:"If x is an object-to-be-tracked, then x should be ablackboard level."

Figure 13shows object-to-be-tracked instantiated forHASP, and the objects in the HASP domain modelmade into levels. Using the above rules, other objects,such as collection-sites whose coordinates are used inline-of-bearing computation, will also become levels.The KASE-generated levels are complete in the sensethat it will list all possible levels; they can be used assuggestions that can be pruned by the designer. Forexample, in most applications collection-site level isnot needed.

6.3.2. CustomizingKnowledge Sources. In KASE theknowledge source design consists of three parts. In ad-dition to the knowledge source trigger (context-inde-pendent condition) and the action part described inSection 5.2., it has a part called "eventposting," whichmakes explicit the need to post events on the controlpanel when the situation board is modified.

All the operationsin the domainmodel aresearchedto identify those operations that either use or modifythe objects on theblackboard. As shown in Figure 14,each selected operation becomes an action part of a

knowledge source. For example, because compute-po-sition uses bearing data, it is selected and becomes apart ofa knowledge source.

Once the action parts of the knowledge sources aredetermined, designrules are used to determine eventsand triggers. An examplerule for eventcreation is: "Ifan object is represented on the blackboard level,thencreate events for attribute of the object that can bemodified." Thus, for the exampleabove, new-positionwould be an event.

Rules that determine theknowledge source triggersare stated in terms ofthe operation that constitute theaction part of theknowledge source. For example,

If an x updates the value of an attributeai , and its valuedepends on the value of some otherattribute a

2,

then anyevent that signals an update of the value ofa2must triggerthe operation

x;

and

Ifan operationx onanobject takesasitsargument aninstanceofanotherobject, then any event that signals the creationofthe newinstance of the object should trigger the operation.

As shown in Figure 14, since compute-position op-eration uses an attribute new-bearing,any time a newbearing is computed the knowledge source containingcompute-position operation must be triggered.

Domain Model: HASPknowledge source knowledge source

instance format■g j position:S | confidence*j evolution

fleetnew-bearing trigger

shipCompute-position operationsource (X: ... new-bearing ... )g 1 create-source

S suspend-source /2 compute-position .5 V

j_m ■-_-__-,_.

mtU4Vut»4t^mmmmn»4*4Vuuuk4Vk4*4VU4j>4Vuu4i'JM compute-confidence

«

harmonic New-position eventpostingline

*

FIGURE 14. Knowledge source creation.

*

#*

#* **

*

H. P. Nii54

.

.

The creation ofknowledge sources in the mannerjust described creates a complete set of knowledgesources needed to compute all the attributes on theblackboard based on the operations available in thedomain model. However, the knowledge sources aresmall-grained and numerous, and there maybe moreevents generated than necessary. In generating theknowledge sources for HASP, KASE generated 46eventsand 26knowledge sources, about twice as manyas the actual system. The design can be optimized bythe user. KASE providessome heuristic optimizationfacilities. For example, merging knowledge sources: ifseveral knowledge sources are triggered by the sameevent,merge the operationsintoone knowledgesource.

7. SUMMARY CONCLUSIONS

Blackboard systems are unique among AI systems inthat they can be recognized by their architectural fea-tures. Yet, there has been very little formal discussionofsystems in terms of their architectures, either in theAI or in the software engineering literature. In orderto understand architectures better, we analyzed theblackboard architecture from the perspective of thekinds ofknowledge it contained. An architecture at alevel of detail sufficient to serve as specificationsforprogramming is an integration of its problem state-ment, solution strategies for the problem, computa-tional design schemastorealize thesolution strategies,and specific information, operations, and constraintsfrom the actual applicationdomain. We enumeratedon each of these areas.

In the KASE project, we introduced the notion ofa generic architecture for a problem class and its so-lution strategies. Associatedwith agenericarchitectureis an ontologyof terms about the problem class withwhich specific domain information could be acquired.The generic architecture also had associated with itdesignknowledge with which the generic architectureand domain information could be used to create ap-plication-specific blackboard architectures. We gaveexamplesofdesign knowledge, accumulated inKASE,about blackboard systems that were used to automat-icallygenerate the designs ofapplication systems.

Acknowledgement—This research was supportedby DARPA/NASAOrder 6822 and Sumex Core Research Grant, NIH LM05208.

Theresearch onthecustomizationprocess within theKASE pro-jectwasconducted by SanjayBhansali (Bhansali & Nii, 1992a, 1992b).Parts ofSections 4 and 5 were taken from(Nii, 1989).

REFERENCESBhansali,

S.,

& Nii, H.P. (1992a). KASE: An integratedenvironmentfor software design. 2nd International Conference on ArtificialIntelligence inDesign. Pittsburgh, PA.

Bhansali,

S.,

& Nii, H.P. (1992b). Software design by reusing archi-tectures. Ith Annual KBSE Conference. McLean, VA. lEEE CSPress.

Brown, H.D., Schoen, E., et al. (1986). An experiment in knowledge-basedsignalunderstanding usingparallelarchitectures(Tech. Rep.No. KSL-86-69). Stanford: StanfordUniversity, Knowledge Sys-tems Laboratory, ComputerScience Department.

Corkill,

D., & Gallagher, K. (Ed.). (1989). The Proceedings oftheThirdAnnual Workshopon Blackboard Systems.

Devanbu,P., Brachman, R.J., et al. (1991). LaSSIE: A knowledge-based software informationsystem. CommunicationsoftheACM,34(5), 34-49.

Engelmore, R., & Morgan, T. (Ed.). (1988). Blackboard systems.Workingham, England: Addison-Wesley.

Erman, L.D., Hayes-Roth, F., et al. (1980). The Hearsay-II SpeechUnderstanding System: Integratingknowledge to resolve uncer-tainty. ACM Computing Survey, 12,213-253.

Guindon,

R. (1990). Knowledge exploitedby experts during softwaresystem design. InternationalJournal ofMan-Machine Studies,33(3), 279-304.

Hayes-Roth, B. (1985). Blackboard architecturefor control. JournalofArtificial Intelligence, 26, 251-321.

Iscoe, N., Williams, G., et al. (1991). Domain modeling ofsoftwareengineering. 13._ International Conference on Software Engi-neering. Austin.

Jagannathan, V., Dodhiawala, R., et al. (Ed.). (1989). Blackboardarchitecturesandapplications. Boston: Academic Press.

Lesser, V.R., &

Corkill,

D.D. (1983). The distributedvehicle mon-itoringtestbed: A tool for investigation distributedproblemsolvingnetworks. TheAIMagazine, 4(3), 15-33.

McDermott, J., & Newell, A. (1982). Estimating the computationalrequirementsforfuture expertsystems. Pittsburgh: Carnegie-Mel-lon University, Computer Science Department.

Nii, H.P. (1986). Blackboard systems (in 2parts).AIMagazine, 7(2),38-53 and7(3), 82-10.

Nii, H.P., Feigenbaum, E.A., et al. (1982). Signal-to-symbol trans-formation:HASP/SIAP case study. AIMagazine, 3(2), 23-35.

Nii, P. (1989). Blackboard systems. HandbookofArtificial Intelligence(pp. 1-82) New York: Addison-Wesley.

Shaw,

M. (1991). Heterogeneous design idiomsfor software archi-tecture.In Sixth InternationalWorkshopon SoftwareSpecificationandDesign.

Como,

Italy. lEEE Computer Society.Springer, S.,Buta,P., etal. (Eds.). (199 1).Automatic lettercomposition

for customer service. InnovativeApplications ofArtificial Intel-ligence. Menlo Park: AAAIPress.

Velthuijsen, H. (1992). The natureand applicability ofthe blackboardarchitecture. The Haag: CIP-GegevensKoninklijke Bibliotheek.

43

0957-4174/94

$6.00

+ .00© 1993 Pergamon Press Ltd.Expert Systems With Applications, Vol. 7, pp.

43-54,


INVITED PAPER


H. PennyNiiKnowledge Systems Laboratory, Computer Science Department, StanfordUniversity,

Stanford,

CA

Abstract—Since Hearsay-11, many applicationsystems using theblackboardarchitecture havebeenbuilt. Some of these applications have been built using expert system shells or tools. These toolscontain theskeletalconstructs ofblackboard systems into which the useradds thenecessary informationandknowledgefrom the applicationdomain to create an applicationsystem. Although the tools areuseful in the implementationphase, theyprovide little help in the designofthe system, which mustnecessarilyprecede theimplementationphase. Thedeterminationoftheblackboard levels, theknowl-edgesources, and the details ofthe controlstrategy is a task reservedfor theknowledge engineer/system designer. In order to automate thedesign process, oneneeds to understand therelationshipsbetween the architectural constructs and domain information thatprovide the semantics ofthe ar-chitecture. In thispaper theauthors explorethecomponentsofblackboard systemsfrom theperspectiveofthe type ofknowledge that goes into the makeup ofblackboard systems at the architecture level.They describea research system,

KASE,

that captures the variousknowledge neededfor designandapplies theknowledge to aidknowledge engineers design blackboardsystems.

1. INTRODUCTION

The terms "blackboard model," "blackboard archi-tecture," and "blackboard system" are associated witha particular class of software programs. An attemptwas made in Nii (1986) to distinguish the differencesbetween a model, a framework (or, an architecture),and an application system. The model was viewed asaconceptual problem-solving entity consisting of twobasic components, a global data base called theblack-board, and knowledge sources that created and mod-ified the contents of the blackboard. The model in-cludes a description of its behavior. An attempt at ab-stracting the software constructsofvarious applicationsystems resulted in a blackboard architecture. In ad-dition to theblackboard and the knowledge sources, ablackboard architecture includes a control componentthat enables therealization of the behavior in a serialcomputing environment (see Fig. 1). The applicationsystems can be described as the instances and/or spe-cializations ofthe architecture. The description oftheapplication taskand the associated task domain servesto establish a vocabulary to describe the specifics of

Requests for reprints should be sent to H. Penny Nii, KnowledgeSystems Laboratory, ComputerScience Department, Stanford Uni-versity,

Stanford,

CA 94305, USA.

the blackboard data structure, the knowledge sourcecontents, and theproblem-solving behavior ofthe dif-ferent systems. That is,the application domain providesthe semantics ofthe architecture.

There has been a steady increase in the number ofblackboard systems [a recent exampleis Springer, Butaetal. (1991); older examplescanbe found in Engelmore& Morgan (1988); Corkill & Gallagher (1989); Jagan-nathan, Dodhiawala et al. (1989); Velthuijsen(1992)],but the designsof these systems continue to fit withinthe blackboard architecture described earlier. Althoughthe implementationdetail may differ greatly, thebasicarchitecture oftheblackboard systems has not changedover the years. This situation provides us with an op-portunity to study the various properties of architec-ture, in particular, theblackboard architecture. Whatis an architecture? What is its form? What implicit in-formation is embedded within an architecture? And,of particular interest to the knowledge system com-munity, whatkinds ofknowledge are neededto designa system, and what roles do these differentkinds play?

KASE (Knowledge Assisted Software Engineering)is a research project whose goal is to build a set ofpower tools for software analysts and designers at thearchitecture level. The tools should contain sufficientknowledge about the artifact and the design process toenable the automation of many of the activities in-

44 H. P. Nii

*


volved in design. Although its focus has been on an-swering the questionsposed abovefor architectures ingeneral, KASE has used a blackboard architecture asits first test bed. From thepoint ofview ofblackboardsystems, the project represents an attempt to codifyvarious kinds ofknowledge aboutblackboard systems.

In this paper we describe the constituent compo-nents ofan architecture in terms oftheknowledge do-mains needed to construct an architecture. In partic-ular, webegin with the contents ofagenericblackboardarchitecture. We than describe a knowledge-basedtechnique for specializing the generic architecture tocreate application-specific architectures using domaininformation.


A software architecture is an abstraction of softwaresystems. It comprises a topology of functional com-ponents, the interfaces between the components, andthe semantic contents of these constituent parts. Anarchitecture is usually describedhierarchically to showdifferent levels ofdetail,and at the most detailed levelit musthave sufficient detail to serve as a guide or spec-ifications to the coding process.

Often, an architecture is treated as one ofmultipleviews ofa system. In LaSSIE (Devanbu, Brachman etal. 1991), for example, the system is partitioned into adomain model view, an architectural view, a featureview, and a code view. Others, for example Iscoe, Wil-liams et al. (1991), focus on the domain model as abasis for software design. The difficultywith separatingthe domain model and the architecture is that the do-main information forms the basis for the semantics ofthe architecture and must be expressible in terms of,as well as within, the computational constructs thatmake up the architecture.


found that designersdrewon manykinds ofknowledge,including knowledge about the domain, knowledgeabout problem solutions and their representation, andknowledge about design schemas and computationalconstructs.

In KASE, an attempt has been made to identify invarious software architectures their constituent knowl-edge domains and to discover the relationships amongthem. The objective is torationalize software designsin orderto identifyusefulknowledge-based design toolsto help in theprocess ofdesign synthesis.KASEbeginswith a generic architecture. A generic architecture isan abstract architecture designedto solve a particularclass of problems (Bhansali & Nii, 1992a). KASE hasbeen working with a class ofproblems called trackingproblems in which the task is to identify and trackobjects in spacebased on signal data.

A generic architecture represents design decisionsand, by its very nature, is associated with certain ar-chitectural commitments. The design decisions areguidedby knowledge in the following areas:1. Aproblem, or a task, class. The selection ofa prob-

lem class establishes an ontology of generic termswith which todescribe thetask, and the objects andthe operations in the problem class. Diagnostics,tracking, payroll, and transactionprocessingare ex-amples ofproblem classes.

2. A solution strategy. An architecture is a commit-ment to solve aproblem using a particularproblem-solving strategy. Thus, theremaybe more than onearchitecture associated with a problem class repre-senting different ways to solve the problem. Onewayto solve a trackingproblem, for example, is tocumulate incrementally and opportunistically evi-dencefor the identityand thebehavior ofthe objectsbeing tracked.

3. Design schemas (architectural constructs). The so-lution strategy is realized using a variety of designschemas, such aspipelines and layered hierarchies.[See Shaw (1991) for a description ofarchitecturalconstructs.] The incremental and opportunisticproblem-solving strategyfor tracking problemscanbe realized using a blackboard architecture, whichin turn is made up ofwhat Shaw calls "interpreter"constructs.Figure 2 shows how the decisions within these

knowledge domains determine the shape ofa genericarchitecture. In short, a genericarchitecture representscommitments to (1) a particular class ofproblems, (2)a solution strategy for that class, and (3) the architec-tural constructs used torealize the strategy.

Theprocess of designing a specific application is aprocess of mapping domain information onto the ar-chitecture. To automate this process, the generic ar-chitecture needs two typesofassociated knowledge.1 . Customization knowledge. Associated with ageneric

architecture is knowledge about how tocustomize

45Blackboard Systems at the ArchitectureLevel

_In this section we revisit blackboard systems in termsofthe concepts justdescribed. We describe the variouscommitments inherent in blackboard systems by re-viewing thetaskcharacteristics that are suited toblack-board architecture. In Section 4 we discuss the differ-ences in blackboard architectures that canbe attributedto different solution strategies. In Section 5 we discusssome of the ways in which the components ofblack-board systemscanbe designedsemi-automatically. Fi-nally, in Section 6 we describe, using two examplesfrom a tracking problem class, automated tools from

One way to categorize a problem-solving approach isby determining whether it uses a search or arecognitionmethod of problem solving. Recognition is a termcoined by McDermott and Newell (1982)—"the com-plete recognition does not search, it knows." At anyparticular computational state, instead of generatingand evaluatingthe possible next states as in search, arecognition system simply knows what the next stateshould be. A classic example of a blackboard systemthat uses search as its solution strategy is HEARSAY-II (Erman, Hayes-Roth et al., 1980), and one usingrecognition strategy is HASP (Nii, Feigenbaum et al.,

_______________ Uservmki_>m ICustomization | IProblem . _ _. ■ w

classv I knowledge |^^ . .Nw Specific

Solution ' . fa J^sßedesiKi/^ architecture___

_.

—■>■ Generic iv^ -r"^ I 'strategy architecture | \Design/ \SChemas I mpfa- I /^" T^N I Domain I|>{-nstantiate)-> uomam

model I V^ model

User

£J System provided □ User created O Process

FIGURE 2. Constituent components of generic architectures and theirrelationships toapplication-specific architectures.

the architecture into application-specific architec- KASE for designing specific blackboard systems fromtures. This knowledge includes how to instantiate a generic architecture,componentsofthe architecture in terms ofthe spe-cificfunctionalities ofthe application domain. Cus- .

m

tomization knowledge captures design knowledge 31 - Task Characteristicsthat is specific tothe architecture. For example,the The applications for which the blackboard approachcustomization knowledge for the problems using has been useM include signal understanding, vision,theblackboard approach may include a heuristic: and situation assessment (Engelmore &Morgan, 1988;"Each intermediate data class needed to solve a Jagannatharl) Dodhiawala et al. 1989). These appli-problem should be a level in theblackboard data cations aU share common characteristics:structure." j The problems are complex and ill-structured with

2. Meta-model. Also associated with a generic archi- lafge solution spaces Systematic generation ofso-tecture is an ontology of generic terms established lution candidates is neither possible nor

feasible,

by the commitment to a problem class. Called a 2 The solutions require situation-dependent, or op-meta-model, it contains the necessary vocabulary portunistic, invocation of diverse sources ofknowl-for describing the task and the domain. A domain edge That control decisions are made while themodel for a specific application is built by instan- problem is being solved instead of using a prioritiating thisontology. For the trackingproblem class, established control paths.the generic terms include "objects-to-be-tracked" 3 Qfte^ the problems demand both synthetic andand "signal-data," aswell as their genericproperties, analytic processes. These often translate into bot-such as, "location" and "speed." tom-up information fusion or composition,and top-An application-specific architecture can be defined down model.based reasoning.

as a generic architectureinstantiated with informationfrom the application domain (Figure 2).


3. BLACKBOARD SYSTEMS REVISITED c.

wj|v

.

ratftwW

a nrnr_en_-__lvin._ aooroach is

46 H. P. Nii

1982). 881 is an exampleofa shell that allows for theuse ofboth strategies (Hayes-Roth, 1985).

In the search paradigm, each step in problem solvingrequires an evaluator to select from a pre-enumeratedor enumerable next state. Each problem-solving stepconsists of a generation ofoperatorsor state, followedby an evaluation, followed by a selection and an ap-plication of the state transforming operator. Often,evaluation precedes generation so that generation canoccur selectively. The generatorcan be algorithmic orheuristic; it can be a legal-movegeneratoror a plau-sible-move generator.Theevaluatorcan beknowledge-poor (general and weak), or it can be knowledge-rich(task-specific). To date most programsthat use searchuse weak knowledge—the search paradigm is called aweak method.

In HEARSAY-II all the possible states were enu-merable by its knowledge sources. For example,givena grammar, a table ofall legal adjacent words for eachword could be generated.The evaluator, or the sched-uler, used weakcriteria. For example, criteria from se-lecting from a number of possible word sequencesmight use the number of words in the sequence. Theknowledge is weak, because it does not use task-specificcriteria, or when used, thetask-specificcriteria are verysimple. A hypothetical, knowledge-rich criterion mightbe: "select a word sequence beginning with a prepo-sition followinga noun clause."

In the recognition paradigm, the knowledge basemust be scanned for a piece ofknowledge that can beappliedto the current situation. This is called the matchstep. Each problem-solving step consists of a matchstepfollowed by theapplication ofa state transformingoperator. If a piece ofknowledge is encoded as a con-ditional if-then rule, thenit contains information aboutwhat the next state would be as well as the situationunder which the state transformation can occur. Mostcurrent expert systems are recognition systems. (Itshould be noted that if-then rules are not necessaryfor a recognition system, and conversely the mere useof if-then rules does not imply a recognition system.The problem-solving approach is independent of theknowledge representation.)

In HASP the search paradigm was tried andfailed,because there was no generatorof the solution space.It was oneofthe first completerecognition systems. Itconsisted of 40-50 knowledge sources, each with anaverageof 10rules. The activeknowledge sources con-sisted of domain- and situation-specific pieces ofknowledge that "knew" what to infer or what actionto takefor each intermediate solution state. In addition,it had a plan for the application of the knowledge inthe form ofcontrol knowledge sources.

In the nextsection we elaborate on the basic differ-ences in system architectures attributable to thediffer-ences between the search andrecognition methods ofproblem solving.


4.1. SearchAs stated earlier, search requires at least ageneratorofthe solution space and an evaluator. The evaluationcan be of two types: a local look-ahead that evaluatespossiblefuture states; and a global evaluator that selectsthe best operatorbased on the information providedby the look-ahead or the overall state of the solution.In the HEARSAY-II architecture, the action part oftheknowledge source was used as a generator(see Fig.3). Uponitsexecution, the action part oftheknowledgesource placed on theblackboard new hypotheses. Thecondition part served as a look-ahead for the actionpart. When executed, it determined the state changesthat would be produced if its action part were to beexecuted.The schedulerdecided on the nextactivity—either to look-ahead or to generate changes; that is, itdeterminedthe solution pathby evaluatingthe currentstate ofthe solution and a set ofpossible future states.


Within the search paradigm the quality of the so-lution may dependon the amountofsearch conducted,which is also a function ofthe qualityoftheknowledgeavailable for evaluation. The premise in HEARSAY-II is that a favorable trade-off can be made betweenthe amount of control knowledge and knowledgesource activations—that is, spending time on evalua-tion pays off in reducing search and in improving thequality ofthe solution.

4.2. Recognition

Therecognition problem-solving paradigm is concep-tually simpler than the search paradigm (see Fig. 4).Here, the knowledge base is scanned for a piece ofknowledge that can be applied to a state. Of course,

FIGURE 3. Control architecture forsearch.->" Data flow ->► Control flow

*

47Blackboard Systems at the Architecture Level

0

.^Data flow Control flow

FIGURE 4. Controlarchitecture for recognition.

theremaybe manypieces ofknowledge applicable fora given state,and a decisionmust be made whether toapply all the pieces ofknowledge or a subset of them.This control decision can be algorithmic (for example,first-in-first-out)or it can be knowledge-based. Whenthecontrol decision isknowledge-based, there is a cer-tain amountofuniformitybetween the way decisionsare made about which knowledge to apply and aboutthe manipulations ofthe solution space objects. In rec-ognition-oriented blackboard systems, the conditionpart of the knowledge source specifies the situationsunder which it can contribute to the solution state.The action part of the knowledge source changes thesolution state. Since the applicable knowledge sourcefor any given situation is predetermined, in the sensethatknowledge sources are always associated with sit-uations, the scheduler focuses on the selection of thebest regionofthe solution space (the specific situation)to process next.

In theory, no distinction is made between controland domain-specificknowledge in recognition systems.However, since a domain knowledge source looks attheblackboard data, and a control knowledge sourcelooks at a description ofthe changes to theblackboardin addition to the specifics ofthe changes, they are infact different. It might be said that the control knowl-edge source has wider scope. Because control knowl-edgeis different from otherknowledge sources, systemscan be designed to exploit the differences. Informalplanseither can be built into the control structure ordynamically generated. In 881 (Hayes-Roth, 1985)control plans for the execution ofthe domain knowl-edge sources are dynamically created.


Some ofthe architectural differences between HEAR-SAY-like and HASP-like systems can be attributed tothe different computational methods inherent in theuse of search and recognition paradigms. There arealso variations in the structure of the components of

the architecture driven by the different needs within aproblem class or the specific application itself. Thesedifferent architectural schemas can be stored in a li-brary. The designer can select appropriate designschema for the various component parts ofthe archi-tecture.For example,as mentioned earlier,knowledgesource selection may be algorithmic or knowledge-based, and the library may contain several differentknowledge-selection modules. In this section we de-scribe some ofthe alternative constructs for the majorcomponents ofthe blackboard architecture.

5.1. TheBlackboardIn addition to servingas a mediumofcommunication,and thus of cooperation, between the knowledgesources, the blackboard represents a design of the so-lution. Since it is a data structure, one could not quitecall it a problem-solving plan, yet in the process ofproblem formulation the structure of the blackboardserves asthebackbone ofthe system design. It iswherethe design process begins. The blackboard partitionsthe solution space, and these partitions dictate whatknowledge sources will be neededto solve the problem.What constitutes a solution, what intermediate solu-tions are needed or available,what relationships existamong hypotheses, must all be expressed within theblackboard structure.

From the standpoint of structure there is very littlevariability in the blackboard. Theblackboard is orga-nized into levels corresponding to the solution spacepartitions. These form either abstraction or composi-tional hierarchies. The objects on a given level sharethe same properties, or vocabulary.

5.1.1. Levels. As a data structure, the level object holdsinformation about the nodes on its level. For example,it must keep the names of the attributes of the nodesand maintain housekeeping information, such as thenumber of nodes on the level at any given time. Forthese reasons, it is often convenient to view the levelobject as a class, and the nodes on the level as theinstances of the class. This has thefurther advantagethat nodes can inherit default property values at nodecreation time. Also, operators (methods) associatedwith creation and destruction of nodes can be storedwith the level object.

5. 1.2. Nodes. Nodes areobjects on alevel;for example,a particular word in a sentenceis a node on the wordlevel in HEARSAY-11. Nodesare created dynamicallyas they are needed. The vocabularyrelevant to the levelofanalysis is represented as attributes and values;eachnode on the level shares the same attributes. In an ob-ject-orientedprogramming languageslots and slot-val-ues can be used, and there is nothing to preclude theuse ofrecord structures available in other languages.

48 H. P. Nii

5.1.3. Attribute Values. The value of an attribute canhave multiplefields; for example, credibiHty value and/or time stamps. Often it is useful to maintain valuehistory. This is especially true in continuous-input sig-nal understanding programs in which temporal trendsare important. In object-oriented systems, a value canbe representedas a method that computes it when theslot is accessed.

5.1.4. Panels. Panels are useful when more than onehierarchy isneededtorepresentthe solutionstate data.The most common use of a second panel is to holdcontrol-related information,as in 881.

5.2. The Knowledge SourcesA knowledge source representsknowledge needed tosolve a sub-problem. All knowledge sources are event-triggered agents—the activation ofknowledge sourcesaresolution-state-dependent, rather thanbeingprocess-dependent.Theimplication is that the most importantconsideration in the design ofthe knowledge source isitsability toevaluate the current stateofthe blackboard.

In all blackboard systemsknowledge sources are de-signed with condition and action parts (Fig. 5).

5.2.1. Condition Part. The condition part can: (1)evaluate possible future states, or (2) make context-independent or context-dependentevaluation of thesituation on theblackboard. In HASP, possiblechangesto the blackboard were categorized into different"event" types. The name of the event type was usedto record a blackboard change. The event name wasalsoused asa triggering condition in thecondition partofthe knowledge sources. In this type ofconstruct thecondition part iscontext-independent—it does nottakeinto consideration the specifics of the change. Alter-natively, the condition part can be a procedure thatevaluates the specifics ofthe change, making the trig-gering ofknowledge sources context-dependent as inHEARSAY-11.

One can think of the condition part as a filter forthe activation ofthe action part. In newer systems, thedesign of the condition part consists of multi-stagedfilters. The first stage, called the trigger, is usually acontext-independentfilter that is followed bya number

FIGURE 5. Use of filters in knowledge sources.

of context-dependent filters. If the action part of theknowledge source is a collection ofrules, then thecon-dition part of the knowledge source can be viewed asa high-level filter for the rule set. Rules have their owncondition parts that serve as more detailedfilters fortherule actions.

5.2.2. Action Part. The action part of a knowledgesource makes modifications to the current blackboardstate. The actionpart can be a procedureor a collectionofrules. The selection oftheknowledgerepresentationscheme is independent of the selection of solutionstrategies.

Each knowledge source can make one or morechanges to theblackboard. In arule-based knowledgesource, multiple changescan come from multiple firingof rules, or from multiple actions on the right-hand-side of rules.

The changes to the blackboard are new solutioncandidates (and new data) or modifications to the ex-isting solution. Changes also canbe made tothecontrolinformation, as in 881. In addition to changes to in-termediate solutions on theblackboard, state changescan occur from the posting of goals and sub-goals tobe achieved (Lesser & Corkill, 1983) or posting ofmodel-based expectations of changes to occur in thefuture, as in HASP.

5.3. The ControlControl is the most complex component ofthe black-board architecture, and it can have many architecturalvariations. The basic function of the control compo-nent is to select and apply knowledge sources in thecase ofrecognition-based systems, or thecondition andaction components of knowledge sources in search-based systems. Major design differences occur in thefollowingareas: (1) schedulable entities—whetherpartsofthe knowledge sources are separate schedulable en-tities or not; (2) scheduling—whether thefocus of at-tention is based on events or on knowledge sources;(3) noticing—who notices the changes in the black-board; and (4) control data—where and in what formthecontrol data is stored.1 . Schedulable Entities: In a search-based architecture

thecondition and theaction parts oftheknowledgesources are scheduled separately. In recognition-basedarchitecture, eachknowledge source issched-uled as a single entity. If the condition part is sat-isfied, than theaction part is immediately executed.

One thing to note is that in the search-based ar-chitecture, theblackboard statemaychangebetweenthe time a condition part and its action part areexecuted. In sucha situation the conditionpart mustbe re-evaluated.

2. Scheduler: There are two bases on which to ap-proach the selection ofthe next thing to do:

Knolwlege SourceCondition part Action part

I Trigger I| If ...then... ICondi tionl If

#

then...Condition 2

' '^^■^■■■■■■^^^^^■■■■■_-__ " " "" " "111 I


*

*



Aknowledge source, or knowledge sources, canbe selected on the basis of the current state oftheblackboard, or more specifically,on the latestchanges to the blackboard, which are calledevents. Called event-oriented scheduling, thefo-cus is on selecting the best solution island onwhich to base further computation. Most rec-ognition systems take this approach. The basicfunction of the scheduler is to decide where towork next. Figure 6 shows a simple event-ori-ented control schema.

a.

In reality, many problems can gain from a mixedstrategy of search and recognition, and 881, for ex-ample, allows for both event-oriented andknowledge-oriented scheduling.

5.3.1. Posting and Noticing Blackboard Changes.What changes areposted and whonotices these changesdifferfrom system to system. Often, in search-orientedsystems, every changeto theblackboard isa candidatefor a solution, and there must be a knowledgesourceto evaluate each change. On the other hand, event-oriented recognition systems can process only thoseblackboard changesfor which there isavailableknowl-edge. By making the event creation explicit, the rulewriter cancontrol what blackboard changesmerit fur-ther action by theknowledge sources. For example, ifanew pieceofevidence isfound tosupportahypothesisbut the only consequence is that the credibility ratingis increased, this change may not need tobe an event.

Aknowledge source can be selected on thebasisofwhat the knowledge source can contribute tothe current state. This approach, called knowl-edge-oriented scheduling, is taken most often insearch systems. The scheduler decidesamong thelook-ahead evaluators and the generatorsofthesolution space, and it applies the selectedcom-ponents to all the relevant data objects on theblackboard. Thebasic function ofthe scheduleris to decide what to do next. Figure 7 shows one

b

FIGURE 7. A knowledge-orientedcontrol schema.

Control

, 1 , * llI Blackboard I Select an eventi1' TControl panel " * . I .

Select KS fT 7~\ Ievent queu% (matchevent <"> K^*SI v \ . sources■ 1\ &KS actions) I 1(Solution panel \ >J

levels <_(-*" "\[ ExecuteKS Iaction partI 1 ' rr -^ Dataflow

T I ->> Control flow

Control

, , I , * . ■T]I Blackboard Select an activity |

I I . IORControl panel Evaluatorj |activity queued : Execute . .

I condition part Knowledgef~ 1 *. 1 _ w * sourcesSolution panel' v, Generator y ,' I I

. , *^_ Executeaction part

I ■ M V I ->- Dataflow[ j -__► Control flow

50 H. P. Nii

What blackboard changes should be events dependonthe application.

5.3.2. Control Data. Control information needed todrive the system alwaysresides outside the blackboardcontaining the solution state. In HASP different typesof changes to the blackboard (modification to nodes,expectationposting, and so on) were storedin separatedata structures. Each eventwas arecording ofthe typeofchange, the node that was modified, the new values,therule that made the modification. In HEARSAY-IIthe control data was stored on a global list, the sched-uling queue. Theitems on the queuewere oftwotypes:information generated by the condition part thatpointed to its action part and all the places on theblackboard it could be applied to, and the names ofthecondition parts ofknowledge sources. Since HASP-like systemsfocus on eventscheduling, thecontrol dataare primarily about events;in HEARSAY-like systemsthat focus onknowledge source scheduling thecontroldata are primarily about knowledgesources.

In 881, control must determine what domainknowledge source to apply and to what object on theblackboard. The control problem is formulated as aplanning sub-problem, and its solution state appearson a separatecontrol panel. All data dealingwith con-trol areposted on the control paneland are shared byboth the control-planning and the domain knowledgesources.

5.3.3. Domain-specific Knowledge, Meta-knowledge,and Control Knowledge. The distinction between do-main-specific knowledge and meta-knowledge is notalways clear cut. Meta-knowledge, knowledge aboutknowledge, is often thought to be weak, general, anddomain-independent. But, in both search and recog-nition systems, meta-knowledge is often treated ascontrol knowledge aboutwhat todo next, and this typeofknowledge isoften verydomain-specific. In general,making distinctions between domain-specific and

meta-knowledge does not contribute much to the de-sign of the system; rather, it tends to distract. Insteadit is preferable to organize knowledge sources hierar-chically according to some control hierarchy. In mostsystems thecontrol hierarchypartitions theknowledgesources into those that deal directly with theemergingsolution states and those that dealwith theprocess his-tory or problem-solving states, called control states.The knowledge sources that operate on control statesare called control knowledge sources.


Up to this point we have discussed the three types ofknowledge that are needed to create a generic black-board architecture—knowledge about the character-istics ofa class ofproblems, its solution strategies, andalternative design schemas torealize the solution strat-egy. As was shown in Figure 2, a generic architecturehas explicitelyassociated with it ( 1) a meta-model con-sisting ofa set ofconcepts and objects to describe theclass of problems, and (2) knowledge about how tointegrate domain information with the generic archi-tecture to create application-specific architectures. Inthis section we describe these two items by means ofexamples from work done on theKASE project.

6.1. A Generic Architecture For Tracking Problems6.1.1. The Tracking Problem. This class ofproblemscan be describedsimply asfollows: Identify,track, andsometimes, infer the intentions ofobjects in spaceusingsignal information about the objects (see Fig. 8). Asexamples,we use the HASP and the ELINT (Brown,Schoen et al., 1986)problems. In HASP the objects tobe trackedare ships andsubmarinesusing passive sonarsignals. InELINT the objectstobe trackedare airplanesusingradar signals. In both problems,there are multiplesources of signal for each platform (engines and pro-


51Blackboard Systems at the ArchitectureLevel

"

FIGURE 9. A generic architecture fortracking problems(based on Figs. 4 and 6).


A generic architecture is most often created by ab-stracting common architectural constructs from severalapplications in a particular problem class. In the caseofblackboard systems, theblackboard architecture of-tencan be converted into a generic architecture for aproblem class by selecting the appropriate constructsfor the various components and renaming some ofthem to fit the application glass. Figure 9 shows a ge-neric architecture for tracking problemscreated in sucha manner. The solution strategy is to use therecognitionmethod with a simple context-independent, event-ori-ented control as shown in Figure 6. There are twoblackboard panels, one for the solution space and onefor control information.

6.1.2. Representation of Generic Architectures. InKASE, the genericarchitecture is represented as a col-lection ofhierarchicallyorganized functional modules.Each module is an object describing services (opera-

tions and procedures) that itprovides, that it has accessto, and that it needs to provide the promised services(see Fig. 10). Other relationshipsbetween the modulessuch as input/outputand control relationships, can bederivedfrom the service information. Forexample, in-put to a module is the collection of data types of thearguments of the service functions that the moduleprovides, plus the results ofthe services it uses.

In a genericarchitecture anyattribute ofthe modulescan be abstractedas parameters.These parameters needto be instantiated with domain information. For thetracking architecture thefollowing operations andpro-cedures are treated as parameters: (1) the blackboardlevels and theproperties of the objects on each level;(2) thecondition and the action parts oftheknowledgesources; and (3) some control functions, such creatingeventtypes andselecting an eventfor focus ofattention.


FIGURE 10. Minimal internalrepresentation ofa module (Bhansali & Nii, 1992) (* derived properties).

52 H. P. Nii

»

Meta-model terms ELINT HASPaircraftcluster

fleetship


observationfeedback


6.2. Meta-Model and Domain ModelsThe names ofthe components that were shown in Fig-ure 9 are parts of the meta-model associated with theproblemclass. For the class oftracking problems, someof the terms and concepts that form the meta-modelare: for domain objects—objects-to-be-tracked, signal-collection-sites, and signal-data; for relations—line-of-bearing; and for events—object-to-be-track-updated,and so on. The properties of these objects are parti-tioned into attributes and operations. Some ofthe ge-neric attributes and operations are: position, heading,andspeedfor theattributes;and create-object, compute-position, and compute-heading for the operations.

The domain models are created by instantiating themeta-model objects. Figure 1 1 shows instantiated do-main-model objects for HASP and ELINT createdfrom the meta-model associated with the generictracking architecture. A radar-signal data in ELINT iscalled observation, and a sonar data reading over agiven time period is called line-segment.

Figure 12 shows typical attributesand propertiesforthe two applications. Typically, the attributes and op-erations are provided by the application designer.However, some generic operations, such as create-ob-jects (instantiated as create-cluster and create-source)

and compute-speedareprovided as a part ofthe genericarchitecture. These operations can be instantiatedfor different applicationsas will be described in Sec-tion 6.3.

6.3. Customizing the Generic ArchitectureThe customization, or instantiation of the generic ar-chitecture, involves instantiating theparametersin thegeneric architecture using the information in the do-main model. Becausethecustomization often involvesnon-simple parameters, for example, determiningknowledge sources, a variety of methods are needed.These methods may consist of selecting from a pre-computedlist ofalternatives, transforming an abstractschema using a set of transformational rules, or usingheuristics designrules and/oralgorithms. KASE storesall the necessarymethods in its customization knowl-edgebase (see Fig. 2). We illustrate the use ofsome ofthe design knowledge in the customization processthroughtwo examples.

6.3.1. Customizing Blackboard Levels. Given a do-main model, determining theblackboard levels isquitestraightforward. There are heuristic rules that suggestthe levels. Some are generic toblackboard architectures


create-cluster-WVVVVVVMMWMVWIMMMnMMVVVIWVVm

split-clustermerge-clusterdelete-cluster

typet4aqp P°sition

"ASI confidenceSource evolution

FIGURE 12. A typical attributes and operations of objects in HASP and ELINT (Boxed operationsare generic operationsthatarepart of the generic architecture).


.

»

*

Tracking Meta-model HASP domain objects Blackboard levels

Tracking-agents

.Collection-sitesReport

.% .

FIGURE 13. Determining blackboard levels.

in general: "Ifanobject class ismentioned in the outputreport, then it should be a level," and "If an objectclass contains properties neededto compute anyotherproperties, then it should be a level." Some others arespecific to thegeneric architecture for aproblem class:"If x is an object-to-be-tracked, then x should be ablackboard level."

Figure 13showsobject-to-be-tracked instantiated forHASP, and the objects in the HASP domain modelmade into levels. Using the aboverules, other objects,such as collection-sites whose coordinates are used inline-of-bearing computation, will also become levels.The KASE-generated levels are complete in the sensethat it will list all possible levels; they can be used assuggestions that can be pruned by the designer. Forexample, in most applications collection-site level isnot needed.

63.2. CustomizingKnowledge Sources. In KASE theknowledge source designconsists of threeparts. In ad-dition to the knowledge source trigger (context-inde-pendent condition) and the action part described inSection 5.2., it has a part called "eventposting," whichmakes explicit the need topost events on thecontrolpanel when the situation board is modified.

All theoperations in the domain model are searchedto identify those operations that either use or modifythe objects on theblackboard. As shown in Figure 14,each selected operation becomes an action part of a

knowledge source. For example,because compute-po-sition uses bearing data, it is selected and becomes apart of aknowledge source.

Once the action parts ofthe knowledge sources aredetermined, designrules are used to determine eventsand triggers. An examplerule for eventcreation is: "Ifan object is represented on the blackboard level, thencreate events for attribute of the object that can bemodified." Thus, for the exampleabove, new-positionwould be an event.

Rules that determine the knowledge source triggersare stated in terms ofthe operation that constitute theaction part of the knowledge source. For example,

If an x updates the value of an attribute ai , and its valuedepends on the value ofsome other attribute a

2,

then anyevent that signals an updateof the value ofa2must triggerthe operation

x;

and

Ifan operationx on anobject takesasitsargumentaninstanceofanotherobject, then any event that signals the creationofthe new instance ofthe object should trigger the operation.

As shown in Figure 14, since compute-position op-eration uses an attribute new-bearing, any time a newbearing is computed the knowledge source containingcompute-position operation must be triggered.


instance format$ j type■g I positionsg | confidence*j 1 evolution.%,;g | create^soiirce2 suspend-source *2 | fcompute^positipnl .P*\ compute-confidence

."

♦

"

fleet new-bearingship

Compute-position(X: ... new-bearing ... )source

harmonic New-position»

line «


*

#

*

*

54 H. P. Nii

A

.

*

*

The creation ofknowledge sources in the mannerjust described creates a complete set of knowledgesources needed to compute all the attributes on theblackboard based on the operations available in thedomain model. However, the knowledge sources aresmall-grained and numerous, and there may be moreevents generated than necessary. In generating theknowledge sources for HASP, KASE generated 46eventsand 26 knowledge sources, about twice as manyas the actual system. The design can be optimized bythe user. KASE provides some heuristic optimizationfacilities. For example,merging knowledge sources: ifseveral knowledge sources are triggered by the sameevent,merge the operationsinto one knowledgesource.

7. SUMMARY CONCLUSIONSBlackboard systems are unique among AI systems inthat they can be recognized by their architectural fea-tures. Yet, there has been very little formal discussionofsystems in terms oftheir architectures, either in theAI or in the software engineering literature. In orderto understand architectures better, we analyzed theblackboard architecture from the perspective of thekinds ofknowledge it contained. An architecture at alevel of detail sufficient to serve as specificationsforprogramming is an integration of its problem state-ment, solution strategies for the problem, computa-tional design schemastorealize thesolution strategies,and specific information, operations, and constraintsfrom the actual applicationdomain. We enumeratedon each of these areas.

In the KASE project, we introduced the notion ofa generic architecture for a problem class and its so-lution strategies. Associated with agenericarchitectureis an ontologyof terms about theproblem class withwhich specific domain information could be acquired.The generic architecture also had associated with itdesignknowledgewith which the generic architectureand domain information could be used to create ap-plication-specific blackboard architectures. We gaveexamplesof designknowledge, accumulated in KASE,about blackboard systems that were used to automat-ically generatethe designs ofapplication systems.

Acknowledgement—This research was supportedby DARPA/NASAOrder 6822and Sumex Core Research Grant, NIH LM05208.

Theresearch on thecustomizationprocess within theKASE pro-jectwas conductedby SanjayBhansali(Bhansali & Nii, 1992a, 1992b).Parts ofSections 4 and 5 weretaken from (Nii, 1989).

REFERENCESBhansali,

S.,

& Nii, H.P.(1992a). KASE: An integrated environmentfor software design. 2nd International Conference on ArtificialIntelligence in Design. Pittsburgh, PA.

Bhansali,

S.,

& Nii, H.P. (1992b). Softwaredesign by reusing archi-tectures. Ith Annual KBSE Conference. McLean, VA. lEEE CSPress.

Brown, H.D., Schoen, E., et al.(1986). An experimentin knowledge-basedsignalunderstanding usingparallel architectures(Tech. Rep.No. KSL-86-69). Stanford:Stanford University, Knowledge Sys-tems Laboratory, Computer Science Department.

Corkill,

D., & Gallagher,K. (Ed.). (1989). The Proceedings oftheThirdAnnual Workshop on BlackboardSystems.

Devanbu,P., Brachman, R.J., et al. (1991). LaSSIE: A knowledge-based software informationsystem. CommunicationsoftheACM,34(5), 34-49.

Engelmore, R., & Morgan, T. (Ed.). (1988). Blackboardsystems.Workingham, England: Addison-Wesley.

Erman, L.D., Hayes-Roth, F., et al. (1980). The Hearsay-II SpeechUnderstanding System: Integratingknowledge to resolve uncer-tainty. ACMComputing Survey, 12, 213-253.

Guindon,

R. (1990). Knowledge exploitedby expertsduring softwaresystem design. International Journal ofMan-Machine

Studies,

33(3), 279-304.Hayes-Roth, B. (1985). Blackboard architecturefor control. Journal

ofArtificial Intelligence, 26, 251-321.Iscoe, N., Williams,

G.,

et al. (1991). Domain modeling ofsoftwareengineering. 13._ International Conference on Software Engi-neering. Austin.

Jagannathan, V., Dodhiawala, R., et al. (Ed.). (1989). Blackboardarchitecturesandapplications. Boston: AcademicPress.

Lesser, V.R., &

Corkill,

D.D. (1983). The distributed vehicle mon-itoring testbed:A toolfor investigation distributedproblem solvingnetworks. TheAIMagazine, 4(3), 15-33.

McDermott, J., & Newell, A. (1982). Estimating thecomputationalrequirementsfor future expertsystems. Pittsburgh: Carnegie-Mel-lon University, Computer Science Department.

Nii, H.P. ( 1986). Blackboard systems (in 2 parts).AIMagazine, 7(2),38-53 and 7(3), 82-10.

Nii, H.P., Feigenbaum, E.A., et al. (1982). Signal-to-symbol trans-formation:HASP/SIAP case study. AIMagazine, 3(2), 23-35.

Nii, P.(1989). Blackboard systems. HandbookofArtificial Intelligence(pp. 1-82) New York: Addison-Wesley.

Shaw,

M. (1991). Heterogeneous design idiomsfor softwarearchi-tecture. In SixthInternationalWorkshop onSoftware Specificationand Design.

Como,

Italy. lEEE Computer Society.Springer,

S.,

Buta, P., et al. (Eds.). (1991). Automatic lettercompositionfor customerservice. InnovativeApplications of Artificial Intel-ligence. Menlo Park: AAAIPress.

Velthuijsen, H. (1992). The nature andapplicability ofthe blackboardarchitecture. The Haag: CIP-GegevensKoninklijke Bibliotheek.

_.

4

43

0957-4174/94

$6.00

+ .00© 1993 Pergamon Press Ltd.Expert Systems With Applications, Vol. 7, pp.

43-54,


INVITED PAPER


H. Penny NiiKnowledge SystemsLaboratory, Computer Science Department, Stanford University,

Stanford,

CA

Abstract—Since Hearsay-11, many applicationsystems using the blackboard architecturehavebeenbuilt. Some of these applications have been built using expert system shells or tools. These toolscontain theskeletalconstructs ofblackboard systemsinto which the useraddsthe necessary informationandknowledgefrom the application domain to create an applicationsystem. Although thetools areuseful in the implementationphase, they provide little help in the design ofthe system, which mustnecessarilyprecede theimplementationphase. The determinationofthe blackboardlevels, theknowl-edgesources, and the details ofthe control strategy is a task reservedfor the knowledge engineer/system designer. In order toautomate the designprocess, one needs to understand therelationshipsbetween the architectural constructs and domain information thatprovide the semantics ofthe ar-chitecture. In thispaper theauthors explorethecomponentsofblackboard systemsfrom theperspectiveofthe type ofknowledge that goes into the makeupofblackboard systems at the architecture level.They describea research system,

KASE,

that captures thevariousknowledge neededfor design andapplies theknowledge to aidknowledge engineers designblackboardsystems.

1. INTRODUCTIONThe terms "blackboard model," "blackboard archi-tecture," and "blackboard system" are associated witha particular class of software programs. An attemptwas made in Nii (1986) to distinguish the differencesbetween a model, a framework (or, an architecture),and an application system. The model was viewed asa conceptual problem-solving entity consisting of twobasic components, a global data base called the black-board, and knowledge sources that created and mod-ified the contents of the blackboard. The model in-cludes a descriptionof its behavior. An attempt at ab-stracting the software constructs ofvarious applicationsystems resulted in a blackboard architecture. In ad-dition to the blackboard and theknowledge sources, ablackboard architecture includes a control componentthat enables the realization ofthe behavior in a serialcomputing environment (see Fig. 1). The applicationsystems can be described as the instances and/or spe-cializations of the architecture. The description of theapplication task and the associated task domain servesto establish a vocabulary to describe the specifics of

Requests for reprints should be sent to H. Penny Nii, KnowledgeSystemsLaboratory, Computer Science Department, Stanford Uni-versity, Stanford, CA 94305, USA.

the blackboard data structure, the knowledge sourcecontents, and theproblem-solving behavior ofthe dif-ferent systems. That is, the application domainprovidesthe semantics of the architecture.

There has been a steady increase in the number ofblackboard systems [arecent example is Springer, Butaet al. ( 199 1); older examplescanbe found in Engelmore& Morgan (1988); Corkill & Gallagher (1989); Jagan-nathan, Dodhiawala et al. (1989); Velthuijsen (1992)],but the designs of these systems continue tofit withinthe blackboard architecture describedearlier. Althoughthe implementation detail may differ greatly, the basicarchitecture ofthe blackboard systems has not changedover the years. This situation provides uswith an op-portunity to study the various properties of architec-ture, in particular, theblackboard architecture. Whatis an architecture? What is its form? What implicit in-formation is embedded within an architecture? And,of particular interest to the knowledge system com-munity, whatkinds ofknowledge are neededto designa system, and what roles do these different kinds play?

KASE (Knowledge Assisted Software Engineering)is a research project whose goal is to build a set ofpower tools for software analysts and designers at thearchitecture level. The tools should contain sufficientknowledge about the artifact and the designprocess toenable the automation of many of the activities in-

44 H. P. Nii

4

.


volved in design. Although its focus has been on an-swering the questions posed above for architectures ingeneral, KASE has used a blackboard architecture asits first test bed. From thepoint ofview ofblackboardsystems, the project represents an attempt to codifyvarious kinds ofknowledge aboutblackboard systems.

In this paper we describe the constituent compo-nents ofan architecture in terms ofthe knowledge do-mains needed to construct an architecture. In partic-ular, webeginwith thecontents ofagenericblackboardarchitecture. We than describe a knowledge-basedtechnique for specializing the generic architecture tocreate application-specific architectures using domaininformation.


A software architecture is an abstraction of softwaresystems. It comprises a topology of functional com-ponents, the interfaces between the components, andthe semantic contents of these constituent parts. Anarchitectureis usually describedhierarchically to showdifferent levels ofdetail, and at the most detailed levelit must have sufficient detail to serve asa guide or spec-ifications to the codingprocess.

Often, an architecture is treated as one ofmultipleviews ofa system. In LaSSIE (Devanbu, Brachman etal. 1991), for example, the system is partitionedinto adomain model view, an architectural view, a featureview,and a code view. Others, for example Iscoe, Wil-liams et al. (1991), focus on the domain model as abasis for software design. The difficultywith separatingthe domain model and the architecture is that the do-main information forms thebasis for the semantics ofthe architecture and must be expressible in terms of,as well as within, the computational constructs thatmake up the architecture.


found thatdesigners drewon manykinds ofknowledge,including knowledge about the domain, knowledgeabout problem solutions and theirrepresentation, andknowledge about design schemas and computationalconstructs.

In KASE, an attempt has been made to identifyinvarious software architectures their constituent knowl-edge domains and to discover the relationships amongthem. The objective is to rationalize software designsin ordertoidentifyusefulknowledge-based design toolsto help in theprocess ofdesign synthesis. KASEbeginswith a generic architecture. A generic architecture isan abstract architecture designed to solve a particularclass of problems (Bhansali & Nii, 1992a). KASE hasbeen working with a class ofproblems called trackingproblems in which the task is to identify and trackobjects in space based on signal data.

A generic architecture represents design decisionsand, by its very nature, is associated with certain ar-chitectural commitments. The design decisions areguidedbyknowledge in the following areas:1 . A problem, ora task, class. The selection ofa prob-

lem class establishes an ontology of generic termswith which to describethe task, and the objects andthe operations in the problem class. Diagnostics,tracking, payroll, and transaction processingare ex-amples of problemclasses.

2. A solution strategy. An architecture is a commit-mentto solve aproblem using aparticularproblem-solving strategy. Thus, there maybe more than onearchitecture associated with a problem class repre-senting different ways to solve the problem. Oneway to solve a tracking problem, for example, is tocumulate incrementally and opportunistically evi-dencefor theidentity and thebehavior ofthe objectsbeing tracked.

3. Design schemas (architectural constructs). The so-lution strategy is realized using a variety of designschemas, such as pipelinesand layeredhierarchies.[See Shaw (1991) for a description ofarchitecturalconstructs.] The incremental and opportunisticproblem-solving strategyfor tracking problems canbe realized using a blackboard architecture, whichinturn is madeup ofwhat Shaw calls "interpreter"constructs.Figure 2 shows how the decisions within these

knowledge domains determine the shape ofa genericarchitecture. In short, a genericarchitecture representscommitments to (1) a particular class ofproblems, (2)a solution strategy for that class, and (3) the architec-tural constructs used torealize the strategy.

The process of designing a specific applicationis aprocess ofmapping domain information onto the ar-chitecture. To automate this process, the generic ar-chitecture needs two types ofassociated knowledge.1. Customizationknowledge. Associated with a generic

architecture isknowledge about how to customize

45Blackboard Systems at theArchitectureLevel

In this section we revisit blackboard systems in termsoftheconcepts justdescribed. Wedescribe the variouscommitments inherent in blackboard systems by re-viewing thetaskcharacteristics that are suited to black-board architecture. In Section 4 we discuss the differ-ences inblackboard architectures that canbe attributedto different solution strategies. In Section 5 we discusssome of the ways in which the components ofblack-board systems canbe designedsemi-automatically.Fi-nally, in Section 6 we describe, using two examplesfrom a trackingproblem class, automated tools from

One way to categorize a problem-solving approach isby determiningwhether it uses a search or arecognitionmethod of problem solving. Recognition is a term

coined by McDermottand Newell (1982)—"the com-plete recognition does not search, it knows." At anyparticular computational state, instead of generatingand evaluating the possible next states as in search, arecognition system simply knows what the next stateshould be. A classic example of a blackboard systemthat uses search as its solution strategyis HEARSAY-II (Erman, Hayes-Roth et al., 1980), and one usingrecognition strategy is HASP (Nii, Feigenbaum et al.,

_^serv.~ui_,«. ICustomization I IProblem _ , __ ■ w

classv I knowledge |^^ . .Specific

Solution T~~". ___ architecture—^> Generic m^r r^ I I

strategy architecture |Design/ \schemai I mr. |><£^W°°^

model I Vs^ X model

User

System provided □ User created O Process

FIGURE 2. Constituentcomponents of generic architecturesand theirrelationships to application-specific architectures.

the architecture into application-specific architec- KASE for designing specific blackboard systems fromtures. This knowledge includes how to instantiate a generic architecture,

components ofthe architecture in terms ofthe spe-cific functionalities ofthe application domain. Cus-

m m

tomization knowledge captures design knowledge 31 - Task Characteristicsthat is specific to the architecture. For example, the The applications for which the blackboard approachcustomization knowledge for the problems using hag feeen u

_eful indude signal understanding, vision,

the blackboard approach may include a heuristic: and situation assessment (Engelmore & Morgan, 1988;"Each intermediate data class needed to solve a Jagannathans Dodhiawala et al. 1989). These appli-problem should be a level in the blackboard data cations aU share common characteristics:structure." j The probiems are complex and ill-structured with

2. Meta-model. Also associated with a generic archi- large solution spaces Systematic generation ofso-tecture is an ontology ofgeneric terms established Mon candidates is neither possible nor

feasible,

by the commitment to a problem class. Called a 2 Jhe solutions require situation-dependent,or op-meta-model, it contains the necessary vocabulary portunistic, invocation ofdiverse sources ofknowl-for describing the task and the domain. A domain edge Jhat contTol decisions are made while themodel for a specific application is built by instan- problem is being solved instead of using a prioridating this ontology. For the tracking problem class, estabiished control paths.the generic terms include "objects-to-be-tracked" 3 Qften the problems demand both synthetic andand "signal-data," aswell as theirgeneric properties, analytic processes. These often translate into bot-such as, "location" and "speed." tom-up information fusion orcomposition, and top-An application-specific architecture can be defined down model_based reasoning.

as a genericarchitecture instantiated with informationfrom the application domain (Figure 2).


3. BLACKBOARD SYSTEMS REVISITED „

wav

. „at„onriw a nrnhum

-Kc,.v\no

annroach is

46 H. P. Nii

1982). 881 is an example ofa shell that allows for theuse of both strategies (Hayes-Roth, 1985).

In the searchparadigm, each step in problem solvingrequires an evaluator to select from a pre-enumeratedor enumerable nextstate. Each problem-solving stepconsists ofa generation ofoperatorsor state, followedby an evaluation, followed by a selection and an ap-plication of the state transforming operator. Often,evaluation precedes generation so that generation canoccur selectively. The generatorcan be algorithmic orheuristic; it can be a legal-move generatoror a plau-sible-movegenerator.The evaluator can beknowledge-poor (general and weak), or it can be knowledge-rich(task-specific). To date most programs that use searchuse weakknowledge—the search paradigm is called aweak method.

In HEARSAY-II all the possible states were enu-merable by its knowledge sources. For example,givena grammar, a table ofall legal adjacent words for eachword could be generated.Theevaluator, or the sched-uler, used weak criteria. For example, criteria from se-lecting from a number of possible word sequencesmight use the number ofwords in the sequence. Theknowledge is weak, because it does not use task-specificcriteria, orwhen used, the task-specific criteria are verysimple. A hypothetical, knowledge-rich criterion mightbe: "select a word sequence beginning with a prepo-sition followinga noun clause."

In the recognition paradigm, the knowledge basemust be scannedfor a piece ofknowledge that can beappliedto the current situation. This is called the matchstep. Each problem-solving step consists of a matchstepfollowedby the application ofa state transformingoperator. If a piece ofknowledge is encoded as a con-ditional if-then rule, thenit contains information aboutwhat the next state would be as well as the situationunder which the state transformation can occur. Mostcurrent expert systems are recognition systems. (Itshould be noted that if-then rules are not necessaryfor a recognition system, and conversely the mere useof if-then rules does not imply a recognition system.The problem-solving approach is independentof theknowledge representation.)

In HASP the search paradigm was tried and failed,because there was no generatorof the solution space.It was one ofthe first completerecognition systems. Itconsisted of 40-50 knowledge sources, each with anaverageof 10 rules. The activeknowledge sources con-sisted of domain- and situation-specific pieces ofknowledge that "knew" what to infer or what actionto takefor each intermediate solution state. In addition,it had a plan for the applicationof the knowledge inthe form ofcontrol knowledge sources.

In the nextsection we elaborate on the basic differ-ences in system architectures attributable to the differ-ences between the search and recognition methods ofproblem solving.


4.1. SearchAs stated earlier,search requires at least a generatorofthe solution space and an evaluator. The evaluationcan be of two types: a local look-ahead that evaluatespossiblefuture states; and a globalevaluator that selectsthe best operatorbased on the information providedby the look-ahead or the overall state of the solution.In the HEARSAY-II architecture, the action part oftheknowledge source was used as a generator(see Fig.3). Upon its execution, the actionpart oftheknowledgesource placed on theblackboard new hypotheses. Thecondition part served as a look-ahead for the actionpart. When executed, it determined the state changesthat would be produced if its action part were to beexecuted. Thescheduler decidedon the nextactivity—either to look-ahead or to generatechanges; that is, itdetermined the solution pathby evaluating the currentstate ofthe solution and a set ofpossible future states.


Within the search paradigm the quality of the so-lutionmay dependon the amountofsearchconducted,which isalso afunction ofthe quality oftheknowledgeavailable for evaluation. Thepremise in HEARSAY-II is that a favorable trade-off can be made betweenthe amount of control knowledge and knowledgesource activations—that is, spending time on evalua-tion pays off in reducing search and in improving thequality ofthe solution.

4.2. Recognition

Therecognition problem-solving paradigm is concep-tually simpler than the search paradigm (see Fig. 4).Here, the knowledge base is scanned for a piece ofknowledge that can be applied to a state. Of course,

->" Data flow ._>. Control flowFIGURE 3. Control architecture for search.

47Blackboard Systems at theArchitecture Level

s^ Data flow -^Control flow

FIGURE 4. Control architecturefor recognition.

theremaybe many pieces ofknowledge applicable fora given state, and a decision must be made whether toapply all the pieces ofknowledge or a subset of them.This control decision can be algorithmic (for example,first-in-first-out) or it can be knowledge-based. Whenthe control decisionisknowledge-based, there is a cer-tain amount ofuniformity between the way decisionsare made about which knowledge to apply and aboutthe manipulations ofthesolution space objects. In rec-ognition-oriented blackboard systems, the conditionpart of the knowledge source specifies the situationsunder which it can contribute to the solution state.The action part of theknowledge source changes thesolution state. Since the applicable knowledge sourcefor any given situation is predetermined, in the sensethatknowledge sources are always associated with sit-uations, the scheduler focuses on the selection ofthebest region ofthe solution space (the specific situation)toprocess next.

In theory, no distinction is made between controland domain-specific knowledge in recognition systems.However, since a domain knowledge source looks attheblackboard data, and a control knowledge sourcelooksat a description ofthe changes to theblackboardin addition to the specifics ofthe changes, they are infact different. It might be said that the control knowl-edge source has wider scope. Because control knowl-edge is differentfrom otherknowledgesources, systemscan be designed to exploit the differences. Informalplans either can be built into the control structure ordynamically generated. In 881 (Hayes-Roth, 1985)control plans for theexecution ofthe domain knowl-edgesources are dynamically created.


Some ofthe architectural differencesbetween HEAR-SAY-like and HASP-like systems can be attributed tothe different computational methods inherent in theuse of search and recognition paradigms. There arealso variations in the structure of the components of

the architecture drivenby the different needs within aproblem class or the specific application itself. Thesedifferent architectural schemas can be stored in a li-brary. The designer can select appropriate designschema for the various component parts ofthe archi-tecture. For example,as mentioned earlier,knowledgesource selection may be algorithmic or knowledge-based, and the library may contain several differentknowledge-selection modules. In this section we de-scribe some ofthe alternative constructs for the majorcomponents ofthe blackboard architecture.

5.1. The Blackboard

In addition to servingas amedium ofcommunication,and thus of cooperation, between the knowledgesources, the blackboard represents a design of the so-lution. Since it is a datastructure, one could not quitecall it a problem-solving plan, yet in the process ofproblem formulation the structure of the blackboardserves asthebackbone ofthe system design. It iswherethe design process begins. The blackboard partitionsthe solution space, and these partitions dictate whatknowledge sources will be neededto solve theproblem.What constitutes a solution, what intermediate solu-tions are needed or available,what relationshipsexistamong hypotheses, must all be expressed within theblackboard structure.

From the standpoint ofstructure there is very littlevariability in the blackboard. The blackboard is orga-nized into levels corresponding to the solution spacepartitions. These form either abstraction or composi-tional hierarchies. The objects on a given level sharethe same properties, or vocabulary.

5.1.1. Levels. As a data structure, the level object holdsinformation about thenodes on its level. For example,it must keep the names ofthe attributes ofthe nodesand maintain housekeeping information, such as thenumber of nodes on the level at any given time. Forthese reasons, it is often convenient to view the levelobject as a class, and the nodes on the level as theinstances of the class. This has the further advantagethat nodes can inherit default propertyvalues at nodecreation time. Also, operators (methods) associatedwith creation and destruction ofnodes can be storedwith the level object.

5. 1.2. Nodes. Nodesare objectson a level;for example,a particular word in a sentenceis a node on the wordlevel in HEARSAY-11. Nodes are created dynamicallyas theyare needed. Thevocabularyrelevant to the levelofanalysis is represented as attributesand values;eachnode on the level shares the same attributes. In an ob-ject-orientedprogramming language slotsand slot-val-ues can be used, and there is nothing to preclude theuse ofrecord structures available in other languages.

48 H. P. Nii

5.1.3. Attribute Values. The value ofan attribute canhave multiple fields; for example, credibility value and/or time stamps. Often it is useful to maintain valuehistory. This isespecially true in continuous-input sig-nal understanding programs in which temporaltrendsare important. In object-oriented systems, a value canbe representedas a method that computes it when theslot is accessed.

5.1.4. Panels. Panels are useful when more than onehierarchy is neededtorepresentthe solution statedata.The most common use of a second panel is to holdcontrol-related information, as in 881.

5.2. The KnowledgeSourcesA knowledge source representsknowledge needed tosolve a sub-problem. All knowledge sources are event-triggered agents—the activation ofknowledge sourcesare solution-state-dependent,rather than beingprocess-dependent.The implication is that the mostimportantconsideration in the design oftheknowledge source isits ability toevaluate the current state oftheblackboard.

In all blackboard systemsknowledge sources are de-signed with condition and action parts (Fig. 5).

5.2.1. Condition Part. The condition part can: (1)evaluate possible future states, or (2) make context-independent or context-dependent evaluation of thesituation on theblackboard. In HASP, possible changesto the blackboard were categorized into different"event" types. The name of the event type was usedto record a blackboard change. The event name wasalso usedas a triggering condition in thecondition partoftheknowledge sources. In this type ofconstruct thecondition partis context-independent—it doesnot takeinto consideration the specifics of the change. Alter-natively, the condition part can be a procedure thatevaluates the specifics ofthe change, making the trig-gering ofknowledge sources context-dependent as inHEARSAY-11.

One can think of the condition part as a filter forthe activation ofthe action part. In newer systems, thedesign of the condition part consists of multi-stagedfilters. The first stage, called the trigger, is usually acontext-independentfilter thatis followed by a number

FIGURE 5. Use offilters in knowledge sources.

of context-dependent filters. If the action part of theknowledge source is a collection ofrules, thenthe con-dition part of the knowledge source can be viewed asa high-level filter for therule set. Rules have their owncondition parts that serve as more detailed filters forthe rule actions.

5.2.2. Action Part. The action part of a knowledgesource makes modifications to the current blackboardstate. The action part canbe aprocedure or a collectionofrules. The selection oftheknowledge representationscheme is independent of the selection of solutionstrategies.

Each knowledge source can make one or morechanges to theblackboard. In a rule-based knowledgesource, multiple changescan come from multiplefiringof rules, or from multiple actions on the right-hand-side of rules.

The changes to the blackboard are new solutioncandidates (and new data) ormodifications to the ex-isting solution. Changes also canbe made tothecontrolinformation, as in 881. In addition to changes to in-termediate solutions on the blackboard, state changescan occur from the posting of goals and sub-goals tobe achieved (Lesser & Corkill, 1983) or posting ofmodel-based expectations of changes to occur in thefuture, as in HASP.

5.3. The ControlControl is the most complex componentofthe black-boardarchitecture, and it can have manyarchitecturalvariations. The basic function of the control compo-nent is to select and apply knowledge sources in thecase ofrecognition-basedsystems, or thecondition andaction components ofknowledge sources in search-based systems. Major design differences occur in thefollowing areas: (1) schedulable entities—whether partsofthe knowledge sources are separate schedulable en-tities or not; (2) scheduling—whether the focus ofat-tention is based on events or on knowledge sources;(3) noticing—who notices the changes in the black-board; and (4) control data—where and in what formthe control data is stored.1. Schedulable Entities: In a search-based architecture

the condition and the action parts oftheknowledgesources are scheduled separately. In recognition-based architecture, each knowledge source is sched-uled as a single entity. If thecondition part is sat-isfied, than theaction part is immediately executed.

One thing to note is that in the search-based ar-chitecture, theblackboard statemaychangebetweenthe time a condition part and its action part areexecuted. In such asituation thecondition partmustbe re-evaluated.

2. Scheduler: There are two bases on which to ap-proach the selection ofthe next thing to do:

Knolwlege Source

Condition part Action partI Trigger I| If ...then... |

Condi tionl j£ then<##Condition 2

" * "



a. Aknowledge source, or knowledge sources, canbe selected on the basis of the current state oftheblackboard, or more specifically,on the latestchanges to the blackboard, which are calledevents. Called event-oriented scheduling, the fo-cus is on selecting the best solution island onwhich to base further computation. Most rec-ognition systems take this approach. Thebasicfunction ofthe scheduler is to decide where towork next. Figure 6 shows a simple event-ori-entedcontrol schema.

b. Aknowledge source can be selected on thebasisofwhat theknowledge source can contribute tothe current state. This approach, called knowl-edge-oriented scheduling, is taken most often insearch systems. The scheduler decidesamong thelook-ahead evaluators and thegeneratorsofthesolution space, and it applies the selected com-ponents to all the relevant data objects on theblackboard. The basic function ofthe scheduleris to decide what to do next.Figure 7 shows one


In reality, many problems can gain from a mixedstrategy of search and recognition, and 881, for ex-ample, allowsfor both event-oriented andknowledge-oriented scheduling.

5.3.1. Posting and Noticing Blackboard Changes.What changesare posted andwho notices these changesdifferfrom system to system. Often,in search-orientedsystems, every changeto theblackboard is acandidatefor a solution, and there must be aknowledge sourceto evaluate each change. On the other hand, event-oriented recognition systems can process only thoseblackboard changesfor which there is availableknowl-edge. By making the event creation explicit, the rulewriter can control what blackboard changesmerit fur-ther action by the knowledge sources. For example, ifa new pieceofevidence is found tosupportahypothesisbut the only consequenceis that the credibility ratingis increased, this change maynot need tobe an event.

FIGURE 7. A knowledge-oriented control schema.

Control

, ,i , *—~nI Blackboard I -- Select an eventi1' JControl panel " ' " .

Select KS V~Z T~> Ievent queu% (matchevent < "Kk »wtod «e

I v v" _,z .. . sources■ 1\ &KS actions) ; I 1ISolutionpanel *

levels __d- H* * J ExecuteKS I

I actionpart1 a. ' -_>" Dataflow1- 1 ->» Control flow

ControlV I

I Blackboard _^ Setect an activityi . n y* IORControl panel

t

* Evaluatorf"_____"_-___-____----—^^

activity queued ;—- " Execute I .I 1— __£ condition part p Knowledger~~ "1 \ I ~

v/ - sourcesSolution panel \ Generator y I I. , *%^_ Execute £

action part1 ' » 1 V | ->- Dataflow

I -__► Control flow

50 H. P. Nii

What blackboard changes should be eventsdepend onthe application.

5.3.2. Control Data. Control information needed todrive the system alwaysresides outside theblackboardcontaining the solution state. In HASP different typesofchanges to the blackboard (modificationto nodes,expectationposting, and so on) were stored in separatedata structures. Each eventwas arecording ofthe typeofchange, the node thatwas modified, the newvalues,therule that made the modification. In HEARSAY-IIthe control data was stored on a globallist, the sched-uling queue. Theitems on the queuewere oftwotypes:information generated by the condition part thatpointed to its action part and all the places on theblackboard it could be applied to, and the names ofthecondition parts ofknowledge sources. Since HASP-like systems focus on eventscheduling, thecontrol dataareprimarily about events; in HEARSAY-like systemsthatfocus onknowledge source scheduling thecontroldata are primarilyabout knowledge sources.

In 881, control must determine what domainknowledge source to apply and to what object on theblackboard. The control problem is formulated as aplanning sub-problem, and its solution state appearson a separatecontrol panel. All data dealing with con-trol are posted on the control panel and are shared byboth the control-planning and the domain knowledgesources.

5.3.3. Domain-specific Knowledge, Meta-knowledge,and Control Knowledge. The distinction between do-main-specific knowledge and meta-knowledgeis notalways clear cut. Meta-knowledge, knowledge aboutknowledge, is often thought tobe weak, general, anddomain-independent. But, in both search and recog-nition systems, meta-knowledge is often treated ascontrol knowledge aboutwhat todo next, and this typeofknowledge is often very domain-specific. In general,making distinctions between domain-specific and

meta-knowledge does not contribute much to the de-sign of the system; rather, it tends to distract. Insteadit is preferable to organize knowledge sources hierar-chically according to some control hierarchy. In mostsystemsthecontrol hierarchy partitions theknowledgesources into those that deal directly with the emergingsolution states and those that dealwith theprocesshis-tory or problem-solving states, called control states.The knowledge sources that operate on control statesare called control knowledge sources.


Up to this point we have discussed the three types ofknowledge that are needed to create a generic black-board architecture—knowledge about the character-istics ofa class ofproblems, its solution strategies, andalternativedesign schemas torealize the solution strat-egy. As was shown in Figure 2, a generic architecturehasexplicitely associated with it ( 1)a meta-model con-sisting ofa set ofconcepts and objects to describe theclass of problems, and (2) knowledge about how tointegrate domain information with the generic archi-tecture to create application-specific architectures. Inthis section we describe these two items by means ofexamples from work done on theKASE project.

6.1. A Generic Architecture For TrackingProblems6.1.1. The Tracking Problem. This class of problemscan be describedsimply as follows: Identify,track, andsometimes, infer the intentions ofobjects inspace usingsignal information about the objects (see Fig. 8). Asexamples,we use the HASP and the ELINT (Brown,Schoen et al., 1986)problems. In HASP the objects tobe tracked are ships andsubmarines usingpassive sonarsignals. In ELINT the objectstobe trackedare airplanesusingradar signals. In both problems, thereare multiplesources of signal for each platform (engines and pro-


l\ Collection site

Blackboard Systems at theArchitecture Level 51

*

FIGURE 9. A generic architecture for tracking problems(based on Figs. 4 and 6).


A generic architecture is most often created by ab-stracting commonarchitectural constructs from severalapplications in a particular problem class. In the caseofblackboard systems, theblackboard architecture of-ten can be converted into a generic architecture for aproblem class by selecting the appropriate constructsfor the various components and renaming some ofthem to fit the application glass. Figure 9 shows a ge-neric architecture for tracking problems created in suchamanner.The solution strategy is to use therecognitionmethod with a simple context-independent, event-ori-ented control as shown in Figure 6. There are twoblackboardpanels, one for thesolution space and onefor control information.

6.1.2. Representation of Generic Architectures. InKASE, the generic architecture is represented as acol-lection ofhierarchically organized functional modules.Each module is an object describing services (opera-

tionsand procedures) thatit provides, thatit has accessto, and that it needs to provide the promised services(see Fig. 10). Otherrelationshipsbetween the modulessuch as input/output and control relationships, can bederivedfrom theservice information. For example,in-put to a module is the collection of data types of thearguments of the service functions that the moduleprovides, plus theresults ofthe services it uses.

In agenericarchitectureany attribute ofthemodulescanbe abstracted as parameters.Theseparametersneedto be instantiated with domain information. For thetrackingarchitecture thefollowingoperations and pro-cedures are treated as parameters: (1) theblackboardlevels and the properties of the objects on each level;(2) thecondition and the action partsofthe knowledgesources; and (3) some control functions, such creatingeventtypesandselecting an event for focus ofattention.


supermodule a module thatcontains this module as a partsubmodule setof modules that are parts of this moduleprovides setof servicesprovided by this module to external modulesrequires setof servicesrequired by this module from other moduleshas-locally set of local data and procedures (services) within this modulehas-access-to set of modules that can provide services to this moduleinputs * data flow into this moduleoutputs* data flow outof this modulecalls* modules called by procedures within this modulecalled-by* modules that call proceduresprovided by this module

FIGURE 10. Minimal internal representationofa module (Bhansali & Nii, 1992)(* derived properties).

52 H. P. Nii

"

Meta-model terms EUNT HASPfleetship

aircraftcluster


observationfeedback


6.2. Meta-Modeland Domain ModelsThe names ofthe components thatwere shown in Fig-ure 9 are parts of the meta-model associated with theproblemclass. For the classof tracking problems,someof the terms and concepts that form the meta-modelare: for domain objects—objects-to-be-tracked, signal-collection-sites, and signal-data; for relations—line-of-bearing; and for events—object-to-be-track-updated,and so on. The properties of these objects are parti-tioned into attributes and operations. Some ofthe ge-neric attributes and operations are: position, heading,andspeedTor the attributes;andcreate-object, compute-position, and compute-heading for the operations.

The domain models are created by instantiating themeta-model objects. Figure 1 1 shows instantiated do-main-model objects for HASP and ELINT createdfrom the meta-model associated with the generictracking architecture. A radar-signal data in ELINT iscalled observation, and a sonar data reading over agiven time period is called line-segment.

Figure 12 showstypical attributesand properties forthe two applications. Typically, the attributes and op-erations are provided by the application designer.However, some generic operations, such as create-ob-jects (instantiated as create-cluster and create-source)

and compute-speedareprovided as a part ofthe genericarchitecture. These operations can be instantiatedfor different applicationsas will be described in Sec-tion 6.3.

6.3. Customizing the Generic ArchitectureThe customization, or instantiation of the generic ar-chitecture, involves instantiating theparametersin thegeneric architecture using the information in the do-main model. Because thecustomization often involvesnon-simple parameters, for example, determiningknowledge sources, a variety of methods are needed.These methods may consist of selecting from a pre-computedlist ofalternatives,transforming an abstractschema using a set of transformational rules, or usingheuristics designrules and/or algorithms. KASE storesall the necessarymethods in its customization knowl-edge base (see Fig. 2). We illustrate the use ofsome ofthe design knowledge in the customization processthrough two examples.

6.3.1. Customizing Blackboard Levels. Given a do-main model, determining theblackboard levelsis quitestraightforward. There are heuristic rules that suggestthe levels. Some are generic toblackboard architectures


create-clustersplit-clustermerge-clusterdelete-cluster

type create-source ]suspend-sourceposition

confidenceevolution

refine-source-type| compute-positioncompute-confidence

FIGURE 12. A typical attributes and operations of objects in HASP and ELINT (Boxed operations are generic operations thatare partof the generic architecture).


*

v

T

Tracking Meta-model HASP domain objects Blackboard levels

Tracking-agents ...jObjects-to-be tracked ISignals %

.Collection-sitesReport

% . . .

FIGURE 13. Determining blackboardlevels.

ingeneral: "Ifan object class is mentionedin the outputreport, then it should be a level," and "If an objectclasscontains properties neededto compute any otherproperties, then it should be a level." Some others arespecific to the generic architecture for a problem class:"If x is an object-to-be-tracked, then x should be ablackboardlevel."

Figure 13shows object-to-be-tracked instantiated forHASP, and the objects in the HASP domain modelmade into levels. Using the above rules, other objects,such as collection-sites whose coordinates are used inline-of-bearing computation, will also become levels.The KASE-generated levels are complete in the sensethat it will list all possible levels; they can be used assuggestions that can be pruned by the designer. Forexample, in most applications collection-site level isnot needed.

6.3.2. CustomizingKnowledge Sources. InKASE theknowledge source designconsists of three parts. In ad-dition to the knowledge source trigger (context-inde-pendent condition) and the action part described inSection 5.2., it has apart called "eventposting," whichmakes explicit the need topost events on the controlpanel when the situation board is modified.

All the operations in the domain model are searchedto identify those operations that either use or modifythe objects on theblackboard. As shown in Figure 14,each selected operation becomes an action part of a

knowledge source. For example,because compute-po-sition uses bearing data, it is selected and becomes apart ofa knowledge source.

Once the action parts of the knowledge sources aredetermined, designrules are used to determine eventsand triggers. An examplerule for eventcreation is: "Ifan object is represented on the blackboard level, thencreate events for attribute of the object that can bemodified." Thus, for the exampleabove, new-positionwould be an event.

Rules that determine the knowledge source triggersare stated in terms ofthe operation that constitute theaction part of theknowledge source. Forexample,

If an x updates the value of an attribute at , and its valuedepends on the value of some other attribute a

2,

then anyevent that signals an update of the value of a2must triggerthe operation

x;

and

Ifan operationx onanobject takesasits argumentan instanceofanother object, then any event that signals the creationofthe new instance ofthe object should trigger the operation.

As shown in Figure 14, since compute-position op-eration uses an attribute new-bearing,any time a newbearing is computed theknowledge source containingcompute-positionoperationmust be triggered.


instance format■g j position£ jj confidence*s evolution< .

fleet new-bearingship .

Compute-position(X: ... new-bearing ... )source g jcreate-source

S suspend-source /*J !j "rt*_W*rt**A»W««*«WWrt*nrtrtrtrt«nrt««flrtWW«__%%1^2 I pompute-position .q,

>.

17. I-. 9

P« | compute-confidenceharmonic New-position%

♦

line%


**

*

_*

*

54 H. P. Nii

.

/

t

The creation ofknowledge sources in the mannerjust described creates a complete set of knowledgesources needed to compute all the attributes on theblackboard based on the operations available in thedomain model. However, the knowledge sources aresmall-grained and numerous, and there may be moreevents generated than necessary. In generating theknowledge sources for HASP, KASE generated 46eventsand 26knowledge sources,about twice as manyas the actual system. The design can be optimized bythe user. KASE provides some heuristic optimizationfacilities. For example, merging knowledge sources: ifseveral knowledge sources are triggered by the sameevent,merge the operationsinto one knowledgesource.

7. SUMMARY CONCLUSIONS

Blackboard systems are unique among AI systems inthat theycan be recognized by their architectural fea-tures. Yet, there has been very little formal discussionofsystems in terms oftheir architectures, either in theAI or in the software engineering literature. In orderto understand architectures better, we analyzed theblackboard architecture from the perspective of thekinds ofknowledge it contained. An architecture at alevel of detail sufficient to serve as specifications forprogramming is an integration of its problem state-ment, solution strategies for the problem, computa-tional design schemas to realize the solution strategies,and specific information, operations, and constraintsfrom the actual application domain. We enumeratedon each of these areas.

In the KASE project, we introduced the notion ofa generic architecture for a problem class and its so-lution strategies. Associated with a genericarchitectureis an ontologyof terms about the problem class withwhich specific domain information could be acquired.The generic architecture also had associated with itdesign knowledge with which the generic architectureand domain information could be used to create ap-plication-specific blackboard architectures. We gaveexamples of designknowledge, accumulated in KASE,about blackboard systems that were used to automat-icallygenerate the designs of application systems.

Acknowledgement—This research was supportedby DARPA/NASAOrder 6822 and Sumex Core Research Grant, NIHLM05208.

Theresearch onthecustomizationprocess withinthe KASE pro-jectwasconducted by SanjayBhansali (Bhansali &Nii, 1992a, 1992b).Parts ofSections 4 and 5 were taken from(Nii, 1989).

REFERENCESBhansali,

S.,

& Nii,H.P. (1992a).KASE: An integratedenvironmentfor software design. 2nd International Conference on ArtificialIntelligence in Design. Pittsburgh, PA.

Bhansali,

S.,

& Nii, H.P. (1992b). Software design byreusing archi-tectures. IthAnnualKBSE Conference. McLean, VA. lEEE CSPress.

Brown, H.D.,

Schoen,

E.,et al. (1986). An experimentin knowledge-basedsignal understanding usingparallelarchitectures(Tech. Rep.No. KSL-86-69). Stanford: StanfordUniversity, Knowledge Sys-tems Laboratory, Computer Science Department.

Corkill,

D., & Gallagher, K. (Ed.). (1989). The Proceedings oftheThirdAnnual Workshop on Blackboard Systems.

Devanbu, P., Brachman, R.J., et al. (1991). LaSSIE: A knowledge-based software information system. Communications oftheACM,34(5), 34-49.

Engelmore, R., & Morgan, T. (Ed.). (1988). Blackboardsystems.Workingham, England: Addison-Wesley.

Erman, L.D., Hayes-Roth, F., et al. (1980). The Hearsay-II SpeechUnderstanding System: Integrating knowledge to resolve uncer-tainty. ACM Computing Survey, 12,213-253.

Guindon,

R. (1990). Knowledge exploitedby experts duringsoftwaresystem design. International Journal ofMan-Machine

Studies,

33(3), 279-304.Hayes-Roth, B. (1985). Blackboard architecturefor control. Journal

ofArtificial Intelligence, 26, 251-321.Iscoe, N., Williams,

G.,

et al. (1991). Domain modeling ofsoftwareengineering. 13th International Conference on Software Engi-neering. Austin.

Jagannathan, V., Dodhiawala, R., et al. (Ed.). (1989). Blackboardarchitecturesand applications. Boston: Academic Press.

Lesser, V.R., &

Corkill,

D.D. (1983). The distributed vehicle mon-itoring testbed: A toolfor investigation distributedproblem solvingnetworks. TheAI Magazine, 4(3), 15-33.

McDermott, J., & Newell, A. (1982). Estimating the computationalrequirementsforfuture expert systems. Pittsburgh: Carnegie-Mel-lon University, Computer Science Department.

Nii, H.P. (1986). Blackboard systems (in 2 parts).AIMagazine, 7(2),38-53 and 7(3), 82-10.

Nii, H.P., Feigenbaum, E.A., et al. (1982). Signal-to-symbol trans-formation: HASP/SIAP case study. AIMagazine, 3(2), 23-35.

Nii, P. (1989). Blackboard systems. HandbookofArtificialIntelligence(pp. 1-82) New York: Addison-Wesley.

Shaw,

M. (1991). Heterogeneous design idiomsfor softwarearchi-tecture. InSixthInternationalWorkshop onSoftware SpecificationandDesign.

Como,

Italy. lEEE Computer Society.Springer,

S.,

Buta,P., etal.(Eds.). (1991). Automaticlettercompositionfor customer service. InnovativeApplications of Artificial Intel-ligence. Menlo Park: AAAIPress.

Velthuijsen, H. (1992). The nature andapplicability ofthe blackboardarchitecture. The Haag: CIP-Gegevens Koninklijke Bibliotheek.

Date post:	18-Mar-2018
Category:	Documents
Upload:	dokhanh
View:	219 times
Download:	2 times

Blackboard Systems at the Architecturemq853nj9727/mq853nj9727.pdf44 H.P.Nii FIGURE1....

Documents