Dynamic system construction¶
To ensure an easy-to-use system, we implemented as the main class a wrapper that integrates the different main components, and hides their connections where possible. This main class is called BlackboardSystem, since the blackboard is the central component of our platform. This is an excerpt of its definition:
class BlackboardSystem properties blackboard; blackboardMonitor; scheduler; robotConnect; dataConnect; methods BlackboardSystem() setRobotConnect( robotConnect ) setDataConnect( connectorClassName ) buildFromXml( xmlName ) addKS( ks ) createKS( ksClassName, ksConstructArgs ) numKSs() run()
The engine of our system is distributed across the
Scheduler classes, with the
BlackboardSystem class holding instances of the latter three. These four
classes each have genuine responsibilities: the
the framework parts, responsible for constructing and setting up the system. The
blackboard is the central storage of functional data and knowledge sources. It
holds a data map that saves arbitrary knowledge source data along time, together
with methods to add and recall data from within knowledge source code.
Additionally, the knowledge sources themselves are put into blackboard storage
BlackboardMonitor is responsible for creating bindings on demand between
knowledge sources, by instantiating event listeners. It keeps track of these
bindings and maintains the agenda of knowledge sources. The
the executive component of the system. While the
control of the knowledge sources in the agenda, the
Scheduler decides about
the order of those knowledge sources to be executed. It does that based on the
attentional priorities of the knowledge sources.
Fig. 44 shows the system class diagram.
An example of an XML-configured blackboard system is shown below. Two identity knowledge sources are connected to the Auditory front-end, and triggering an identity decision knowledge source.
<blackboardsystem> <dataConnection Type="AuditoryFrontEndKS"/> <KS Name="baby" Type="IdentityKS"> <Param Type="char">baby</Param> <Param Type="char">6687829ce1a73694a1ce41c7c01dec1b</Param> </KS> <KS Name="femaleSpeech" Type="IdentityKS"> <Param Type="char">femaleSpeech</Param> <Param Type="char">6687829ce1a73694a1ce41c7c01dec1b</Param> </KS> <KS Name="idDec" Type="IdDecisionKS"> <Param Type="int">0</Param> <Param Type="int">1</Param> </KS> <Connection Mode="replaceOld" Event="AgendaEmpty"> <source>scheduler</source> <sink>dataConnect</sink> </Connection> <Connection Mode="replaceOld"> <source>dataConnect</source> <sink>baby</sink> <sink>femaleSpeech</sink> </Connection> <Connection Mode="replaceParallel"> <source>baby</source> <source>femaleSpeech</source> <sink>idDec</sink> </Connection> </blackboardsystem>
Several core functionalities are provided through the
Connecting a Robotic platform or the Binaural simulator to the Blackboard system. The connected robot or simulator must implement the robot interface for delivering audio ear signals and commanding movement and head rotation. The blackboard system and all its components including the knowledge sources get access to the audio stream and robot actions through this connection (
Setting the type of the module that integrates with the Auditory front-end, instantiating it and connecting it to the Blackboard system. This module is a knowledge source itself, responsible for processing the ear signals into cues (such as interaural time differences) needed by other knowledge sources. The Auditory front-end itself is connected to the Robotic platform or the Binaural simulator in order to obtain the ear signals. (
Instantiating and adding knowledge sources. These knowledge sources must inherit from
AbstractKS(see abstract knowledge source) or
AuditoryFrontEndDepKS(see Section Auditory signal dependent knowledge source superclass: AuditoryFrontEndDepKS) to be able to be interfaced and run by the system. Knowledge sources that inherit from
AuditoryFrontEndDepKSautomatically get connected with the Auditory front-end by the system in order to place their signal/cue requests.
Adding and instantiating knowledge sources can take place both before or while running the system; it can be done from outside the system or from inside knowledge sources. This enables the development of top-down controlling knowledge sources from higher cognitive experts running in the system (
The start-up configuration of the system can completely be defined by an XML file; the system is then constructed before running by loading this file. Of course this configuration can be changed dynamically while executing the system. The XML description needs at least a
dataConnectionnode specifying the type of the Auditory front-end module; then, it can also contain
KSnodes with parameters to construct knowledge sources, and
Connectionnodes that specify event bindings between knowledge sources. See the code listing from above for an example (
Starting the execution of the system. This triggers the blackboard system to request data from the robot/binaural simulator connection, and subsequent action by the Auditory front-end and all knowledge sources that are connected. The system will not stop execution before the Robotic platform or the Binaural simulator sends an ending signal (