Software

The project's software was implemented in the popular object-oriented programming language, C++ [59]. In addition to the final Windows GUI implementation, the code written, debugged and tested using the Linux operating system, the GNU g++ compiler and accompanying software development tools [60]. The graphical user interface for the software was built for the Win32 API [61,62] in C++ using the free MingW32 compiler [63] and accompanying software utilities.

The software implementation consisted of more than 60 source files, containing approximately 20,000 lines of code. A listing of the source files and their purposes is shown in Appendix B.

  

Figure 7.1: Software implementation detail

During the software design process, the major tasks and processes that the software needed to implement were identified as follows: data interface, feature extraction, DBN engine, belief extraction and user interface, which interacted as shown in Figure 7.1. This chapter describes the complete software implementation in terms of these tasks.

Data collection

Data collection was the combined responsibility of the datalogger and sensors, already discussed in Chapters 5 and 6 respectively.

Data interface

The data interface is where the software written for this project collects the raw sensor signals from Siesta datalogger. The current software implementation achieves this by reading the output files from the SiestaView program, as covered in Section 4.3.1. However, the software design made extensive use of C++'s polymorphism mechanisms so that it could easily be be extended to handle different types of data sources in the future.

   
Channel splitting

The Siesta datalogger can collect sensor readings from a number of channels at once, so the raw samples collected via the data interface must handled carefully to avoid confusing readings from different sensors. Additionally, the Siesta may sample different channels at different rates, so channel splitting also handles entering the data into the following feature extraction stage at the correct rate. If this was not performed, the DBN could receive evidence caused by data from different sensors in the wrong order, producing confused results.

   
Feature extraction

As mentioned in Section 4.3.2, feature extraction is performed on the raw data using various software data filters arranged into a `filter network'.

A filter network can be thought of as a tree of `filter nodes'. Samples are entered at the root of the tree and propagate through each node, which subjects the data to some processing - determined by the node's type and configuration - and then outputs the result to its child nodes. Each software input channel (one for each sensor), has its own filter network, and has the responsibility of providing it with samples received from the datalogger through the data interface.

Using C++ inheritance techniques, many different filter nodes have been implemented to perform a number of data-processing tasks useful in extracting features such as footsteps from raw sensor signals. The configuration of each node in the filter network is specified in the comments section of the .dne network file (See Appendix A.1.3). Some filtering nodes implemented included signal rectification, quantisation, clipping and clamping, integration, differentiation, rising/falling edge triggers and a DSP variable-tap FIR filter (See A.1.3 for list of available filters).

   
Evidence extraction

The process of evidence extraction is identical to feature extraction, with the addition that input into a filter node may result in evidence being entered into the DBN. Special `evidence nodes' can take output from filter nodes and test it using particular rules to determine whether it constitutes evidence.

Once evidence has been added to the DBN via one or more evidence nodes, the network is expanded by a specified number of slices^7.1.

   
DBN engine

The implementation of a DBN software system was quite substantial, resulting in the largest individual section of the project's software. The primary tasks of the DBN engine was to perform network expansion and contraction, maintain correct network structure and provide an interface for entering evidence and extracting beliefs.

The Netica API was used to perform inference (Section 3.1.2) and store the DBN itself. Netica stores and performs inference on the DBN as if it was a static belief network; the DBN engine extends the Netica API by splitting this network into slices which are added and removed as necessary, while maintaining the proper causal links and probability distributions.

The DBN software builds a multiple-slice DBN using a 2-slice `reference network' supplied as a Netica belief network file. The names of each node in a reference network (and resulting DBN) are suffixed with a number to specify which DBN slice they belong to. The conditional probability tables supplied with the reference network specify the static and temporal probabilistic relationships between nodes both within and across slice boundaries.

The software stores each individual slice in the network as lists of nodes. This way, accessing an individual node requires a search through one slice node list, as opposed to searching the entire network. This could be very time consuming, especially during network expansion and contraction, where substantial amounts of network restructuring is commonly required.

The DBN engine maintains node lists for the DBN's current, prediction and history slices. The node lists for prediction and history slices are stored in fixed-length queues as shown in Figure 7.2. The length of these queues directly determine how many slices the network will maintain as `history slices' and `prediction slices', and is specified before processing starts. When the DBN engine is first started, prediction slices are automatically added to fill the prediction queue, but the history queue remains empty until the network is expanded.

  

Figure 7.2: DBN engine's storage of history, current and prediction slices.

When a new slice is added during expansion, its node list is added to the front of the prediction queue, and its nodes are connected to those of the previous newest slice while maintaining the structure specified in the reference network. Next, the slice from the rear of the prediction queue becomes the current slice, and the old current slice is added to the head of the history slice queue.

When the history queue fills, the oldest slice is removed from the end and unlinked from the network, producing a network contraction. All the remaining children of nodes in the removed slice then have their CPTs `marginalised' to account for loosing one or more parent nodes. Marginalisation works by averaging each node's probability distribution over the beliefs of its remaining parents. The method for performing this process on a node X_n with remaining parent states is shown in Equation 7.1 shows the formula used to marginalise the probability vector in a node X_n for each of the conditioning state p_i of its remaining parents. If the node has all its parents removed during network contraction, its CPT was simply converted to a prior probability distribution using the node's current beliefs.

 

$$\emph{P}(X_n\vert P_n=p_i) \frac{1}{M}\sum^M_{j=0}\emph{P}(X_n\vert P_n=p_i,Q_m=q_j)$$ = (7.1)

$$\mathrm{For\ each\ }p_i\mathrm{\ in\ }P_n$$ given

$$\mathrm{Parents\ of}\ X_n\ \mathrm{\ in\ slice\ }n$$ P_n =

$$\mathrm{Parents\ of\ }\ X_n \mathrm{\ in\ slice\ }m,\ m\neq{}n$$ Q_m =

$$\mathrm{All\ possible\ state\ combinations\ (}q_j\mathrm{)\ of\ }Q_m$$ M =

After the network has more than one slice, the software performed network expansion by effectively appending a copy of the last (newest) slice of the network onto the front of the network (and prediction queue). Network expansion uses lists of forward- and backward-linked nodes derived from the reference network to add the necessary causal links to and from the previous and newest slice. Any nodes in the previous slice which have causal links directed to previous slices (backwards links) are replaced with copies from other slices to ensure the node CPTs are correct.

Belief extraction

Belief extraction is reasonably simple. A list of states belonging to nodes of interest are specified by the user and maintained by the software; whenever the DBN is expanded and updated this `watch' list is checked, and the belief in all the states of interest is queried and stored. Beliefs can be extracted from any node in any existing slice - if the history slice queue is not yet full, some historical slices and their nodes may not be available until the DBN is expanded further.

User interface

Two different types of user interfaces were implemented. Both essentially used the same input, DBN engine, configuration and output code, but supply different interfaces for the user to interact with the software.

The first interface required the user to specify filenames and number of reference and prediction slices on the `command-line', displayed all output in text, and was mainly intended for testing while developing under Linux.

  

Figure 7.3: Graphical user interface implementation

The second interface used the Windows 32-bit API to implement the graphical user interface shown in Figure 7.3 (see Section A.3 for a brief overview of the WinDBN application). This provided a `user-friendly' interface to the otherwise complex task of configuration.

This GUI application took advantage of the Windows operating system's multi-threading environment, which enabled feedback to be provided to the operator while the DBN engine was processing

This implementation also provided file polling, which could be used to load and process data from the SiestaView program while it was being received from the datalogger.

   
Configuration

A majority of the DBN software's configuration information is provided as text commands in the reference network's `comments' section. This is where the user provides the configuration for the data interface (number and sampling rate of input channels), feature extraction system, node `watch' list and the software's other features. When a reference network is supplied to the software, this information is loaded and interpreted in order to create the necessary software objects. As a consequence of this design, a DBN model can be entirely specified in a single file.

A detailed description of the configuration method syntax is provided in Appendix A.