F Blackboard Pattern

The idea behind the Blackboard architecture is a collection of independent programs that work cooperatively on a common data structure. Each program is specialized for solving a particular part of the overall task, and all programs work together on the solution. These specialized programs are independent of each other. They do not call each other, nor is there a predetermined sequence for their activation. Instead, the direction taken by the system is mainly determined by the current state of progress. A central control component evaluates the current state of processing and coordinates the specialized programs. This data-directed control regime is referred to a s opportunistic problem solving. It makes experimentation with different algorithms possible, and allows experimentally-derived heuristics to control processing.

During the problem-solving process the system works with partial solutions that are combined, changed or rejected. Each of these solutions represents a partial problem and a certain stage of its solution, The set of all possible solutions is called the solution space, and is organized into levels of abstraction. The lowest level of solution consists of an internal representation of the input. Potential solutions of the overall system task are on the highest level.

The name blackboard was chosen because it is reminiscent of the situation in which human experts sit in front of a real blackboard and work together to solve a problem. Each expert separately evaluates the current state of the solution, and may go up to the blackboard at any time and add, change or delete information. Humans usually decide themselves who has the next access to the blackboard. In the pattern we describe, a moderator component decides the order in which programs execute if more than one can make a contribution.

Therefore, the context of the blackboard architecture is an immature domain, in which no closed approach to a solution is known or feasible. It is used to coordinate separate, disparate systems that need to work together or in sequence, continually cycling for updates and actions.

A blackboard can be seen more generally as a repository. In a repository style there are two quite distinct kinds of components: a central data structure represents the current state, and a collection of independent components operate on the central data store. Interactions between the repository and its external components can vary significantly among systems. See Figure F.1 for a simple view of the blackboard architecture.

The blackboard architecture (Figure taken from @mary1996software)

Figure F.1: The blackboard architecture (Figure taken from [21])

The blackboard model is usually presented with three major parts:

  1. The knowledge sources: separate, independent parcels of application-dependent knowledge. Interaction among knowledge sources takes place solely through the blackboard.
  2. The blackboard data structure: problem-solving state data, organized into an application-dependent hierarchy. Knowledge sources make changes to the blackboard that lead incrementally to a solution to the problem.
  3. Control: driven entirely by the state of the blackboard. Knowledge sources respond opportunistically when changes in the blackboard make them applicable

Figure F.1 shows no explicit representation of the control component. However, invocation of a knowledge source (ks) is triggered by the state of the blackboard. The actual locus of control, and hence its implementation, can be in the knowledge sources, the blackboard, a separate module, or some combination of these.

Therefore, summarising the blackboard consists of a number of stores or “global variables”. This is similar to a repository of messages, which can be accessed by separate autonomous processes. A “Controller” monitors the properties on the blackboard and can decide which “Knowledge Sources” to prioritize.

F.1 Examples

In this section we provide a few real-world examples as they have been implemented.

F.1.1 Robotics

Figure F.2 describes a blackboard architecture for mobile robots. This paradigm was used in the NAVLAB project as part of the CODGER system.

A Blackboard Solution for Mobile Robots (Figure taken from @mary1996software)

Figure F.2: A Blackboard Solution for Mobile Robots (Figure taken from [21])

This blackboard solution is comprised of the following components:

  • Captain the overall supervisor (controller).
  • Map navigator the high-level path planner (knowledge source).
  • Lookout a module that monitors the environment for landmark (knowledge source).
  • Pilot the low-level path planner and motor controller (controller).
  • Perception subsystem the modules that accept the raw input from multiple sensors and integrate it into a coherent interpretation.

The components (including the modules inside the perception subsystem) communicate via the shared repository of the blackboard system. Modules indicate their interest in certain types of information. The database (the central blackboard) returns them such data either immediately or when some other module inserts it into the database. For instance, the lookout may watch for certain geographic features; the database informs it when the perception subsystem stores images matching the description. One difficulty with the CODGER architecture is that control flow has to be coerced to fit the database mechanism) even under circumstances where direct interaction between components would be more natural.

The blackboard is also the means for resolving conflicts or uncertainties in the robot’s world view. For instance) the lookout’s landmark detections provide a reality check for the distance estimation by dead-reckoning; both sets of data are stored in the database (the central blackboard). The modules responsible for resolving the uncertainty register with the database to obtain the necessary data. (A good example of this activity is sensor fusion) performed by the perception subsystem to reconcile the input from its diverse sensors.)

F.1.2 HEARSAY-II

The first major blackboard system was the HEARSAY-II speech-recognition system. See Figure F.3 for view of the blackboard architecture as implemented in the HEARSAY-II system.

Blackboard view of HEARSAY-II (Figure taken from @mary1996software)

Figure F.3: Blackboard view of HEARSAY-II (Figure taken from [21])

The blackboard structure is a six- to eight-level hierarchy in which each level abstracts information on its adjacent lower level) and blackboard elements represent hypotheses about the interpretation of an utterance. Knowledge sources correspond to such tasks as segmenting the raw signal) identifying phonemes) generating word candidates) hypothesizing syntactic segments, and proposing semantic interpretations. Each knowledge source is organized as a condition part that specifies when it is applicable and an action part that processes relevant blackboard elements and generates new ones. The control component is realized as a blackboard monitor and a scheduler; the scheduler monitors the blackboard and calculates priorities for applying the knowledge sources to various elements on the blackboard.

F.1.3 Blackboard in Web Applications

The work of [23] discusses the use of a blackboard architectur as an alternative for a 3-layer enterprise architecture in a movie administration system, developed in a graduate course on software engineering. More specifically they implemented ticket selling, standard accounting and management processes in movie chains.

In the authors implementation, knowledge sources contain the business logic, the blackboard contains the database layer and the control manages the knowledge sources and linkes the presentation and business logic. See Figure F.4 for a diagram of their web-based blackboard architecture.

Components of a web-based blackboard architecture (Figure taken from @metzner2005using)

Figure F.4: Components of a web-based blackboard architecture (Figure taken from [23])

More specifically they implemented knowledge sources for accessing movie information, ticket reservation services; information about movie centers, films and show times; control-triggered knowledge sources for closing of pending reservations and of reservations for shows about to start.

Their blackboard is a persistence layer, holding all the data concerning the weekly and daily movie guide and provides special methods for supporting the updating process carried out by knowledge sources.

The control runs in a separate thread, constantly monitoring the blackboard’s state. It contains a list of registered knowledge sources for their automatic activation if necessary. Additionally, it allows for the communication between the web pages and the knowledge sources.

F.2 The Problem

In general, the Blackboard pattern tackles problems that do not have a feasible deterministic solution for the transformation of raw data into high-level data structures, such as diagrams, tables or English phrases. Vision, image recognition, speech recognition and surveillance are examples of domains in which such problems occur. They are characterized by a problem that, when decomposed into subproblems, spans several fields of expertise. The solutions to the partial problems require different representations and paradigms. In many cases no predetermined strategy exists for how the ‘partial problem solvers’ should combine their knowledge. This is in contrast to functional decomposition, in which several solution steps are arranged so that the sequence of their activation is hard-coded.

In some of the above problem domains you may also have to work with uncertain or approximate knowledge. Each transformation step can also generate several alternative solutions. In such cases it is often enough to find an optimal solution for most cases, and a suboptimal solution, or no solution, for the rest. The limitations of a Blackboard system therefore have to be documented carefully, and if important decisions depend on its results, the results have to be verified.

The following forces influence solutions to problems of this kind

  • A complete search of the solution space is not feasible in a reasonable time.
  • Since the domain is immature, you may need to experiment with different algorithms for the same subtask. For this reason, individual modules should be easily exchangeable.
  • There are different algorithms that solve partial problems. For example, the detection of phonetic segments in the waveform is unrelated to the generation of phrases based on words and word sequences.
  • Input, a s well a s intermediate and final results, have different representations, and the algorithms are implemented according to different paradigms.
  • An algorithm usually works on the results of other algorithms.
  • Uncertain data and approximate solutions are involved, for example when the interpretation of a signal is error-prone and there might occur competing alternatives for an interpretation at any stage of the process.
  • Employing disjoint algorithms induces potential parallelism. If possible you should avoid a strictly sequential solution.

F.3 Structure

Divide your system into a component called blackboard, a collection of knowledge sources, and a control component.

F.3.1 Blackboard

The blackboard is the central data store. Elements of the solution space and control data are stored here. We use the term vocabulary for the set of all data elements that can appear on the blackboard. The blackboard provides a n interface that enables all knowledge sources to read from and write to it.

All elements of the solution space can appear on the blackboard. For solutions that are constructed during the problem solving process which are put on the blackboard, we use the terms hypothesis or blackboard entry. Hypotheses rejected later in the process are removed from the blackboard.

A hypothesis usually has several attributes, for example its abstraction level, that is, its conceptual distance from the input. Hypotheses that have a low abstraction level have a representation that is still similar to input data representation, while hypotheses with the highest abstraction level are on the same abstraction level as the output. Other hypothesis attributes are the estimated degree of truth of the hypothesis or the time interval covered by the hypothesis.

The blackboard can also be viewed as a three-dimensional problem space with the time line for information income on the x-axis, increasing levels of abstraction on the y-axis and alternative solutions on the z-axis.

Collaboration of the blackboard (Figure taken from @buschmann2008pattern)

Figure F.5: Collaboration of the blackboard (Figure taken from [5])

F.3.2 Knowledge Sources

Knowledge sources are separate, independent subsystems that solve specific aspects of the overall problem. Together they model the overall problem domain. None of them can solve the task of the system alone - a solution can only be built by integrating the results of several knowledge sources.

Knowledge sources do not communicate directly - they only read from and write to the blackboard. They therefore have to understand the vocabulary of the blackboard. We explore the ramifications of this in the Implementation section below.

Often a knowledge source operates on two levels of abstraction. If a knowledge source implements forward reasoning, a particular solution is transformed to a higher-level solution. A knowledge source that reasons backwards searches at a lower level for support for a solution, and may refer it back to a lower level if the reasoning did not give support for the solution.

Each knowledge source is responsible for knowing the conditions under which it can contribute to a solution. Knowledge sources are therefore split into a condition part and an action part. The condition part evaluates the current state of the solution process, as written on the blackboard, to determine if it can make a contribution. The action part produces a result that may cause a chage to the blackboard’s contents.

Collaboration of the knowledge source (Figure taken from @buschmann2008pattern)

Figure F.6: Collaboration of the knowledge source (Figure taken from [5])

F.3.3 Control

The control structure component runs a loop that monitors the changes on the blackboard and decides what action to take next. It schedules knowledge source evaluations and activations according to a knowledge application strategy. The basis for this strategy is the data on the blackboard.

The strategy may rely on control knowledge sources. These special knowledge sources do not contribute directly to solutions on the blackboard, but perform calculations on which control decisions are made. Typical tasks are the estimation of the potential for progress, or the computational costs for executing of knowledge sources. Their results are called control data and are put on the blackboard as well.

Collaboration of the control (Figure taken from @buschmann2008pattern)

Figure F.7: Collaboration of the control (Figure taken from [5])

Theoretically, it is possible that the blackboard can reach a state at which no knowledge source is applicable. In this case, the system fails to deliver a result. In practice, it is more likely that each reasoning step introduces several new hypotheses and that the number of possible next steps increases exponentially. The problem is therefore to restrict the alternatives to be taken rather than to find an applicable knowledge source.

A special knowledge source or a procedure in the control component determines when the system should halt and what the final result is. The system halts when an acceptable hypothesis is found, or when the space or time resources of the system are exhausted.

F.3.4 Relationships

The following figure illustrates the the relationship between the three components of the blackboard architecture. The blackboard component defines two procedures: inspect and update. Knowledge sources call inspect to check the current solutions on the blackboard. update is used to make changes to the data on the blackboard. The control component runs a loop that monitors changes on the blackboard and decides what actions to take next. We call the procedure responsible for this decisions nextSource.

Relationships in the blackboard architecture (Figure inspired by @buschmann2008pattern)

Figure F.8: Relationships in the blackboard architecture (Figure inspired by [5])

F.4 Dynamics

The following scenario illustrates the behavior of the Blackboard architecture. It is based on our speech recognition example:

  • The main loop of the Control component is started.

  • Control calls the nextSource() method to select the next knowledge source.

  • nextSource() first determines which knowledge sources are potential contributors by observing the blackboard. TODO base on example above. In this example we assume the candidate lmowledge sources are Segmentation. Syllable Creation and Word Creation.

  • nextSource() invokes the condition-part of each candidate knowledge source. TODO base on example above. In the example, the condition-parts of Segmentation. Syllable Creation and Word Creation inspect the blackboard to determine if and how they can contribute to the current state of the solution.

  • The Control component chooses a knowledge source to invoke, and a hypothesis or a set of hypotheses to be worked on. TODO base on example above. In the example the choice is made according to the results of the condition parts. In other cases the selection is also based on control data. It applies the action-part of the knowledge source to the hypotheses. In our speech recognition example, assume that Syllable Creation is the most promising knowledge source. The action-part of Syllable Creation inspects the state of the blackboard, creates a new syllable and updates the blackboard.

F.5 Implementation

To implement the Blackboard pattern, carry out the following steps:

  1. Define the Problem. Specify the domain of the problem and the general fields of knowledge necessary to find a solution. Define the input to and output of the system. Detail how the user interacts with the system.

  2. Define the solution space for the problem. We distinguish intermediate and top-level solutions on one hand, and partial and complete solutions on the other. A top-level solution is a t the highest abstraction level. Solutions at other levels are intermediate solutions. A complete solution solves the whole problem, whereas a partial solution solves part of the problem. Note that complete solutions can belong to intermediate levels, and a partial solution may be top-level. To do this perform the following steps:

    • Specify exactly what constitutes a top-level solution.
    • List the different abstraction levels of solutions.
    • Organize solutions into one or more abstraction hierarchies.
    • Find subdivisions of complete solutions that can be worked on independently, for example words of a phrase or regions of a picture or area.
  3. Divide the solution process into steps.

    • Define how solutions are transformed into higher-level solutions.
    • Describe how to predict hypotheses at the same abstraction level.
    • Detail how to verify predicted hypotheses by finding support for them in other levels.
    • Specify the kind of knowledge that can be used to exclude parts of the solution space.
  4. Divide the knowledge into specialized knowledge sources with certain subtasks. These subtasks often correspond to areas of specialization. There may be some subtasks for which the system defers to human specialists for decisions about dubious cases, or even to replace a missing knowledge source. Knowledge sources must be complete in the following sense: for most of the input phrases, a t least one possible sequence of knowledge source activations that leads to an acceptable solution should exist.

  5. Define the vocabulary of the blackboard. Elaborate your first definition of the solution space and the abstraction levels of your solutions. Find a representation for solutions that allows all knowledge sources to read from and contribute to the blackboard. This does not mean that each knowledge source must understand every blackboard entry, but each knowledge source must be able to decide whether it can use a blackboard entry. If necessary, provide components that translate between blackboard entries and the internal representations within knowledge sources. This allows knowledge sources to be easily exchanged, to be independent of each other’s representation and paradigms, and at the same time use each other’s results.

To evaluate the contents of the blackboard, the Control component must be able to understand it. The vocabulary of the blackboard cannot therefore be defined once, but evolves in concert with the definition of knowledge sources and the Control component. At some point during design the vocabulary must stabilize, to allow the development of stable interfaces to the knowledge sources.

  1. Specify the control of the system. The Control component implements an opportunistic problem-solving strategy that determines which knowledge sources are allowed to make changes to the blackboard. The aim of this strategy is to construct a hypothesis that is acceptable a s a result. But when is a hypothesis acceptable? Since the correctness of a hypothesis is not verifiable in a strict sense, our goal is to construct the most credible complete, top-level solution possible in the solution space.

The credibility of a hypothesis is the likelihood that it is correct. We estimate the credibility of a hypothesis by considering all plausible alternatives to it, and the degree of support each alternative receives from the input data. The credibility rating is, for example, a number on a scale ranging from 0 to 100. A hypothesis is acceptable if it is top-level and complete and if its assessed credibility reaches a threshold value, for example 85. To find a n acceptable hypothesis, the system eliminates hypotheses with a low credibility, and detects mutually-supportive clusters of hypotheses that are consistent with the input data.

In the simplest case the control strategy consults the condition-part of all knowledge sources whenever the blackboard is changed, and picks one of the applicable knowledge sources for activation at random. However, this strategy usually is too inefficient, as progress toward a n acceptable hypothesis is slow. The design of a good control strategy is the most difficult part of the system design. It often consists of a tedious process of trying combinations of several mechanisms and partial strategies.

  1. Implement the knowledge sources. Split the knowledge sources into condition-parts and action-parts according to the needs of the Control component. To maintain the independency and exchangeability of knowledge sources, do not make any assumptions about other knowledge sources or the Control component.

You can implement different knowledge sources in the same system using different technologies. For example, one may be a rule-based system, another a neural net and a third a set of conventional functions. This implies that the knowledge sources themselves may be organized according to diverse architectural or design patterns such as a layered monolith, pipes and filters, reactive programming or actors.

F.5.1 Radar Defence System

A technical discussion of a toy Radar Defence System implemented with the blackboard architecture is given in https://social.technet.microsoft.com/wiki/contents/articles/13461.blackboard-design-pattern-a-practical-c-example-radar-defence-system.aspx. In the example the radar defense system is detecting objects (Planes, Rockets, Birds or Unknown) which fly from the bottom to the top of the screen, see Figure F.9.

A screenshot of the Radar Defense System example implemented with a Blackboard Architecture.

Figure F.9: A screenshot of the Radar Defense System example implemented with a Blackboard Architecture.

The heart of a blackboard architecture are the knowledge sources. Each knowledge source is responsible for declaring whether it is available for the current state of the problem being analysed. This could in fact be an autonomous process, as the knowledge sources could monitor the blackboard directly. In this example there are multiple problems (detected objects) being analysed, so each knowledge source has an IsEnabled property, which is set if there are any valid objects on the blackboard.

public interface IKnowledgeSource
{
    KnowledgeSourceType KSType { get; }
    KnowledgeSourcePriority Priority { get; }
    bool IsEnabled { get; }

    void Configure(Blackboard board);
    void Stop();

    void ExecuteAction();
}

public enum KnowledgeSourcePriority
{
    Disabled,
    High,
    Normal
}

public enum KnowledgeSourceType
{
    Detector,
    Analyser,
    Actioner
}

In the blackboard pattern a controller iterates over the knowledge sources, each taking their turn at the problem. Therefore, in this example, the controller runs in a loop, iterating over all the knowledge sources that are active, and executing each. The blackboard pattern defines the controller as the decision maker, choosing which knowledge source to execute and in what order. In this project that is represented simply by a Priority enum which orders the knowledge sources. For example the WarMachine knowledge source (see below) is top priority and executed first, so any known threats are acted upon, before any further decisions are made.

class Controller
{
    Blackboard blackboard;
    List<IKnowledgeSource> KnowledgeSources = new List<IKnowledgeSource>();
    List<IKnowledgeSource> OrderedKnowledgeSources;

    public Controller(Blackboard board)
    {
        blackboard = board;

        KnowledgeSources.Add(new SignalProcessor(DateTime.Now.Millisecond));
        KnowledgeSources.Add(new ImageRecognition());
        KnowledgeSources.Add(new PlaneIdentification());
        KnowledgeSources.Add(new WarMachine());

        OrderKnowledgeBases();

        foreach (var ks in OrderedKnowledgeSources)
            ks.Configure(blackboard);
    }
    
    void tick(object sender, EventArgs e)
    {
        foreach (IKnowledgeSource ks in OrderedKnowledgeSources)
            if (ks.IsEnabled)
                ks.ExecuteAction();
    }

The blackboard in this example is a multi-problem blackboard, and each active knowledge source iterates over all the problems/objects that meet it’s execution criteria.

public class Blackboard
{
    public ObservableCollection<IObject> CurrentObjects { get; set; }

    public Blackboard()
    {
        CurrentObjects = new ObservableCollection<IObject>();
    }
}

Objects are represented by the IObject interface and can be Unknown, Bird, Plane or Rocket and at various processing stages.

public interface IObject
{
    ObjectType Type { get; set; }
    string Name { get; set; }
    bool? IsThreat { get; set; }
    ProcessingStage Stage { get; set; }
}
    
public enum ObjectType
{
    Unknown,
    Bird,
    Plane,
    Rocket
}

public enum ProcessingStage
{
    Detected,
    Analysed,
    Identified,
    Actioned
}

The knowledge sources act directly upon the blackboard through the IsEnabled and Execute methods. In this examples there are four knoweldge sources:

  • Signal Processing: the biggest job of number crunching the radar data (eg spectrogram analysis) into digital data.
  • Image Recognition: comparing the part-processed image with known signatures.
  • Plane Identification: “Hand-shaking” with onboard computers, requesting voice contact, checking flight paths, basically deciding if friend or foe.
  • War Machine: if a Rocket or hostile Plane, the military take over and decide how best to deal with the target (Missile defense, scramble rapid response fighters)

F.5.1.1 Signal Processor

This is the first Knowledge Source to act upon the problem, in that it takes the raw radar data from the incoming Objects, as presented on the blackboard, in the CurrentObjects collection, which the radar is reporting to.

The signal processor is enabled if there are any objects which are not analysed yet and executes its action on these objects.

class SignalProcessor : KnowledgeSourceBase
{
    public override bool IsEnabled
    {
        for (var ix = 0; ix < blackboard.CurrentObjects.Count(); ix++)
            if (blackboard.CurrentObjects[ix].Stage < ProcessingStage.Analysed)
                return true;

        return false;
    }
    
    public override void ExecuteAction()
    {
        for (var ix = 0; ix < blackboard.CurrentObjects.Count(); ix++)
            if (blackboard.CurrentObjects[ix].Stage < ProcessingStage.Analysed)
                ProcessAnotherBit(blackboard.CurrentObjects[ix]);
    }
}

F.5.1.2 Image Recognition

This knowledge source is responsible for trying to figure out what the pixilated image is. This is done on every pass of the data, as the image takes form. Every time a block of pixels is added to the known image, it is compared against known images to see if it now only matches ONE of the images. Although not shown in this simple example, it could also trigger if all remaining images are hostile, allowing the War Machine to get involved before the image is even fully analysed.

The image recognition is enabled if there are any objects which are not analysed yet and executes its action on these objects. The code is similar to the one of the signal processor, therefore we omit it.

F.5.1.3 Plane Identification

This Knowledge Source is just an example of another analyzer layer that could process the data further. We have Birds (safe) and Rockets (hostile) but we also have Plane, that could be either, depending on further analysis. In this module’s Execute method, it emulates the process of further analysis, whether that be initiating a hand-shake protocol to onboard computer identification systems, a manual contact attempt from air traffic controllers, and checking the resulting data against published flight paths.

The plane identification is enabled if there are objects which are analysed already and executes its action on objects which are analysed and identified as planes. It simply sets the plane to identified.

class PlaneIdentification : KnowledgeSourceBase
{
    public override bool IsEnabled
    {
        for (var ix = 0; ix < blackboard.CurrentObjects.Count(); ix++)
            if (blackboard.CurrentObjects[ix].Stage == ProcessingStage.Analysed)
                return true;

        return false;
    }

    public override void ExecuteAction()
    {
        for (var ix = 0; ix < blackboard.CurrentObjects.Count(); ix++)
        {
            var obj = blackboard.CurrentObjects[ix];
            if (obj.Stage == ProcessingStage.Analysed && obj.Type == ObjectType.Plane)
            {
                var unk = obj as IncomingObject;
                var actual = unk.GetActualObject();
                obj.Name = actual.Name;
                obj.IsThreat = actual.IsThreat;
                obj.Stage = ProcessingStage.Identified;
            }
        }
    }
}

F.5.1.4 The War Machine

This final Knowledge Source represents one possible solution to the problem. To add extra peril to this example, it takes three seconds (passes) for the military to respond and react to an object that is identified and labelled as hostile. With each pass of the War Machine, each ‘military response’ gets closer to it’s target. This represents the delay it takes for Missile Defence Systems to respond, SAMs or rapid response type fighter jets to scramble and intercept the target.

The war machine is enabled if there are objects which pose a threat and for which no countermeasures have been actioned and executes its action on these objects.

class WarMachine : KnowledgeSourceBase
{
    public override KnowledgeSourcePriority Priority
    {
        return KnowledgeSourcePriority.High;
    }

    public override bool IsEnabled
    {
        for (var ix = 0; ix < blackboard.CurrentObjects.Count(); ix++)
        {
            var obj = blackboard.CurrentObjects[ix];
            if (obj.IsThreat != null && obj.IsThreat.Value && (obj.Stage != ProcessingStage.Actioned)) 
                return true;
        }

        return false;
    }

    public override void ExecuteAction()
    {
        for (var ix = 0; ix < blackboard.CurrentObjects.Count(); ix++)
        {
            var obj = blackboard.CurrentObjects[ix] as IncomingObject;
            if (obj.IsThreat != null && obj.IsThreat.Value && (obj.Stage != ProcessingStage.Actioned))
            {
                if (obj.MoveHitsTarget())
                    DestroyTarget(obj);
            }
        }
    }
}

F.5.1.5 Expanding

The signal processor in this example is simulated to take some time to identify radar data. Also the war machine has a built-in response time of 3 seconds to simulate the time such a system needs to make a decision. This means that in this example some objects may not get processed in time. This is of course unacceptable in a real system, so it would need to expand, grow with demand. As the controller is simply iterating over a list of known knowledge sources, it is a simple matter of adding to that collection. In this example controllers can be added on the fly, adding extra processing power to each loop of the controller, resulting in all images to get identified before they fly out of the window.

This represents one of the main selling points of this design pattern. Extra knowledge sources will also bring their own priority attributes, allowing it to slip into the collection at whatever priority is required. This is also why the controller is needed, to centralize the decision process and mediate between multiple knowledge sources.

F.6 Consequences

Experimentation. In domains in which no closed approach exists and a complete search of the solution space is not feasible, the Blackboard pattern makes experimentation with different algorithms possible, and also allows different control heuristics to be tried.

Support for changeability and maintainability. The Blackboard architecture supports changeability and maintainability because the individual knowledge sources, the control algorithm and the central data structure are strictly separated. However, all modules can communicate via the blackboard.

Reusable knowledge sources. Knowledge sources are independent specialists for certain tasks. A Blackboard architecture helps in making them reusable. The prerequisites for reuse are that knowledge source and the underlying Blackboard system understand the same protocol and data, or are close enough in this respect not to rule out adaptors for protocol or data.

Support for fault tolerance and robustness. In a Blackboard architecture all results are just hypotheses. Only those that are strongly supported by data and other hypotheses survive. This provides tolerance of noisy data and uncertain conclusions.

Support for concurrency. The blackboard architecture supports concurrency and decouples senders from receivers, thus facilitating maintenance.

Difficulty of testing. Since the computations of a Blackboard system do not follow a deterministic algorithm, its results are often not reproducible. In addition, wrong hypotheses are part of the solution process.

No good solution is guaranteed. Usually Blackboard systems can solve only a certain percentage of their given tasks correctly.

Dfficulty of establishing a good control strategy. The control strategy cannot be designed in a straightforward way, and requires an experimental approach.

Low Efficiency. Blackboard systems suffer from computational overheads in rejecting wrong hypotheses. If no deterministic algorithm exists, however, low efficiency is the lesser of two evils when compared to no system at all.

High development effort. Most Blackboard systems take years to evolve. We attribute this to the ill-structured problem domains and extensive trial-and-error programming when defining vocabulary, control strategies and knowledge sources.

No explicit support for parallelism. The Blackboard architecture does not prevent the use of a control strategy that exploits the potential parallelism of knowledge sources. It does not however provide for their parallel execution. Concurrent access to the central data on the blackboard must also be synchronized.

F.7 Conclusion

To summarize, the Blackboard architecture allows an interpretative use of knowledge. It evaluates alternative actions, chooses the best for the current situation, and then applies the most promising knowledge source. The expense for such deliberation can be justified so long a s no adequate explicit algorithm is available for the problem. When such a n algorithm emerges, it usually provides higher performance and effectiveness. The Blackboard architecture consequently lends itself best to immature domains in which experimentation is helpful. After research and the gaining of experience, better algorithms may evolve that allow you to use a more efficient architecture.

Sources

This chapter is based on material from [5], [21].

References

[5] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. 2008. Pattern-oriented software architecture: A system of patterns. John Wiley & Sons.

[21] Shaw Mary and Garlan David. 1996. Software architecture: Perspectives on an emerging discipline. Prentice-Hall (1996).

[23] Christiane Metzner, Leonardo Cortez, and Doritza Chacı́n. 2005. Using a blackboard architecture in a web application. Issues in Informing Science & Information Technology 2, (2005).