System Design Overview

This chapter summarises the overall design of the fall detection system implemented during this project, covering the purpose and reasoning behind the system's major components.

As shown in Figure 4.1, the final implementation of the falls project can be split into three main sections:

1.

Patient-mounted sensors for detecting limb movement/position (Chapter 6).

2.

Collection and transmission of sensor data using the datalogger (Chapter 5).

3.

Software performing feature extraction, DBN processing and output of results (Chapter 7).

  

Figure 4.1: Overview of fall system implementation.

Datalogger

The datalogger has the task of sampling and digitising the analog electrical signals from the sensors and transmitting this information to the software by way of radio-telemetry. The Siesta datalogger (Chapter 5 used in this project replaces the tethered micro-controller-based datalogger built by Ryan McGowan in the previous project [4].

   
Datalogger communications

As discussed in the proposal [51], the Siesta datalogger provides three main methods to communicate its sensor readings to a computer: flash-card, infra-red or radio network link. The primary datalogger communication method utilised by this project was the radio LAN (Section 5.1.1). The reasons for selecting this over the other communication methods is discussed in Section 5.1.1.

The flash-card storage method (Section 5.1.1) was not used for this project as it required a flash-card reader and that data collected from sensors be recorded then `played back' using further Compumedics proprietary software^4.1. This in turn required software protection device be attached to a computer, all of which was considered unnecessary.

Infra-red communications required an IRDA communications port be attached to the computer, which had to be kept in line-of-site of the Siesta's IR port during recordings (see Section 5.1.1).

The radio-network method - although requiring the installation of a radio LAN card on a desktop computer - was determined the most practical. Here the Siesta uses its internal radio transmitter to communicate with a `master' radio network interface card (NIC) installed in a computer.

Sensors

Initially, it was envisaged that the piezoelectric accelerometer sensors (Chapter 6) already designed and manufactured for use with the datalogger would be the primary transducer used for this project. During numerous trials, these sensors were found to produce very noisy high-frequency signals which were difficult to interpret and convert into discrete gait cycle events. Consequently, new pressure sensors were designed, built and tested (Section 6.3) in an effort to produce reliable signals from which distinct ambulation events could be easily extracted and entered as evidence into the DBN software system.

Software

Designing and developing the project's DBN software was the single largest task in the project. The software implementation can be roughly broken down into the sub-sections shown in figure 4.1, which perform the distinct tasks of: receiving data, extracting features and entering evidence into the DBN, processing data using the DBN engine, storing or presenting results and providing control over the software via a user interface. The implementation of these sections is discussed in detail in Chapter 7.

The SiestaView software (see section 5.2.1) was used in this project to interface with the Siesta as an alternative to implementing a new and complex direct datalogger-software network interface (see section 4.3.1). Use of this existing software allowed for the implementation of a relatively simple (although not particularly efficient) method of collecting the sensor readings from the datalogger.

   
Receiving data

Data transmitted from the datalogger was collected by reading the 16-bit samples stored from data files created by Compumedic's SiestaView program. As such, the project implemented the ``offline'' and ``indirect-offline'' data collection methods mentioned in the project proposal [51].

The offline method simply reads the file-stored data file into the software after recording has finished. Obviously this is not particularly useful for predicting or detecting falls as they happen, although it may be used to analyse the data after a recording and establish whether a patient is more likely to suffer falls in the future^4.2.

The ``indirect-offline'' method works by `polling'<sup>4.3</sup> the output from the SiestaView program while it is still receiving samples from the datalogger. This system required programming for Windows, as the SiestaView program only runs in these operating systems. As a consequence, the graphical user interface version of the DBN software (which also took advantage of Windows multi-threading) was built for the Windows 95/98/NT operating systems (see Chapter 7 and Section A.3). This implementation of the software is also capable of processing recorded data ``offline'' by disabling file polling.

The ``indirect-offline'' method was the closest this project could get to `real time' analysis of the signals. The format of SiestaView's data files, as well as file system and polling delays meant that data could not be received by the project's software for more than a second after it is transmitted by the datalogger, dependent on the number and sampling rates of channels being used. The only foreseeable way of having the software process the data sooner is to implement the network interface, and the software was designed with the later addition of this feature in mind.

Although the project's proposal mentioned the possibility of collecting samples ``direct-online'' from the datalogger via the radio-network, this was not implemented for a number of reasons. Firstly it required Compumedics to supply the communications protocol and network packet format used between the Siesta and the SiestaView software. This they were understandably reluctant to do for legal reasons relating to intellectual property. Secondly, Compumedics staff also mentioned the methods used to configure the datalogger and receive data were quite complicated and would be time consuming to implement. Finally, this method would also require learning a substantial amount about network programming. Despite this, the software was designed to be easily extended to include direct network communications with the datalogger, should it be considered worth adding in the future.

   
Feature extraction

This particular part of the project turned out to be more demanding than expected, due to the variability and noise inherent in using any sensors, especially the AC-dominated piezoelectrics. This, and the need to derive useful features from the data - such as time intervals, signal amplitudes, peaks and signal changes - prompted the development of an adaptable method for easily specifying different types of software signal filtering at runtime. This was realised using a `filter network' structure which is generated at runtime by the software based on commands from the user. The implementation of this system is discussed in detail in Section 7.3.

DBN engine

This is the heart of the software, implementing DBN theory in software by extending Netica's static belief network library. The DBN engine operates in unison with the user interface, receives data from feature extraction, and has its results (posterior beliefs) collected by the belief extraction modules. The DBN engine includes data and functions to perform the necessary expansion and contraction of DBN slices, entry of evidence into the network, querying beliefs of particular nodes, loading and storing of networks and other network maintenance tasks.

Belief extraction

Belief extraction is required to collate and store the posterior probabilities (beliefs) of interest generated by the DBN engine after evidence is added and the network updated. Currently belief extraction involves setting software `watches' on particular nodes and states which are then stored to an output file. The system could be extended to provide live feedback, such as a line-graphs of `belief-bars' as the system processes the data.

User interfaces

The user interface portion of the software provided a method of configuring controlling the input, processing and output of data from the DBN system. Two separate interfaces were implemented; A textual interface which runs from an operating systems `command-line' which provided little flexibility, and a graphical `point-and-click' interface.

Command-line interface

The software's user interface for the offline-only version is fairly simple, allowing the user to provide a `reference network' file, a data file (previously created and filled by the SiestaView program), and the number of required DBN history and prediction slices. This information is provided on the operating system^4.4 command-line and collected by the program when it starts. Once started, this version of the software processes all the data in the specified data file until it is empty. Depending on the configuration specified in the reference network file (see Sections 7.6.1 and A.1), results of processing may be stored in new files by the project's software, which can be later examined and/or graphed.

Graphical user interface

As mentioned in Section 4.3.1, a graphical user interface (GUI) was also implemented for the project's software. A GUI interface was implemented for a number of reasons:

1.

As mentioned earlier, the SiestaView software only runs under Windows 95/98, so to achieve file polling and near-realtime processing of ambulation data, the processing software needed to also run in Windows 95/98.

2.

The multi-threading facilities available in the Windows 32-bit operating systems were used to allow concurrent processing of data and feedback to the user.

3.

The GUI version provided an easier `point-and-click' interface to specify input files and control the DBN software.

4.

The Netica GUI used to build the DBN models used in the project also only runs under Windows 95/98 (or Macintosh), so having the processing software running in the same operating system was more efficient.

   
DBN models

DBN models are used to specify the DBN structure and parameters to be used by the software when processing evidence extracted from sensor data. These models are provided as a `reference network' consisting of two DBN slices, which are expanded to the required number of slices by the software (Section 7.4). Configuration information included in the DBN model's file are also used to specify how evidence should be extracted from the raw data, and to which nodes the extracted evidence should be added (Section A.1).