Application-driven Event Management

In order to support an application-driven event management strategy, each higher layer component is required to inform the DMC about both the signal(s) it is interested in and the

frequency at which it can handle notification events related to changes in each signal’s characteristics (i.e. new data points). We must, therefore, extend the list of information that the device management component must maintain to include:

! Reference to a timer

! Some sense of the relationships that exist between particular physiological signals and

interested upper layer components

The role of the timer is to produce periodic events which trigger the DMC to poll the sensing hardware for new data points. Theoretically, the timer interval could be fixed at run time, but this produces a similar problem to the one caused by letting the sensing hardware drive data into the overall application, in that data may be retrieved in excess of the requirements of any registered upper layer components. If upper layer components are to be allowed to alter their signal requirements whilst the DMC is running (more about this later), then the polling interval is better set dynamically by the DMC as the requirements of registered components change. To achieve this flexibility the DMC uses the frequency data submitted by each registering upper layer component to dynamically alter the timer notification interval in a bid to satisfy the requirements

three potential models for passing events between the hardware and the upper layers were identified.

The first model is illustrated in Figure 5.5. In this model all command/ interface/ application layer components register with a single entity, which we have called a data query object, that exists

within the DMC. On notification of a timer event the data query object cycles through the list of physiological signals, retrieves a data point for each one in turn from the sensing hardware. It then attempts to identify which upper level components are interested in receiving new data points corresponding to which physiological signal of interest.

There are several problems with this model however, the first being that a single data query object is trying to manage all of the events occurring between the hardware and the higher layers of the model. For one or two signals and one or two simple upper layer components this may work fine. However it is possible that, an interface layer component will want to register interest in a number of physiological signals. So, for example, a bar graph may want to display information about several EEG component signals along a single scale. A display-dependent EPIC system, such as one designed for a biofeedback-based application, may contain a number of interface components, each responding to a different combination of physiological signals. This begins to greatly complicate the data query object’s job of distributing signals on to particular components.

Figure 5.5 Model 1 - A single data query object data point poll notify register Timer Interface Component Command Component Interface Component Application Component Data Query Object

Device Driver Sensing Hardware

To compound this problem, during a running EPICS application, it may be desirable to change the signal(s) that a higher layer component is interested in, or change the time intervals between receipt of data points from the DMC. This would further complicate an already complex distribution procedure. For these reasons a second model was conceived where each component, as it registered with the DMC, was assigned its own data query object (Figure 5.6).

In this case each data query object only needs to poll the hardware for a subset of the physiological signals required within the scope of a given EPICS application. The data query object maintains information about the time interval that its particular upper layer component has specified for receipt of data, and consequently polls the hardware at that rate. It also maintains a list of physiological signals of interest to a particular component throughout the lifetime of that component. When the component is removed from the running application (this is equivalent to closing a window in a windows system) its data query object is removed from the DMC.

This model, though better than the first model, nevertheless has some problems of its own. For example, two interface components could have exactly the same data retrieval requirements, in terms of signals of interest and data-rate handling capabilities. However, in this model two separate data query objects would exist within the DMC, both effectively doing the same job. On a particular clock cycle both data query objects would, in turn, poll the hardware for data about the same signal(s). This potential for redundant activity within the sub-components of the DMC

Figure 5.6 Model 2 - Every higher level component has a dedicated data query object notify data point poll Timer Interface Component Command Component Interface Component Application Component Data Query Object

Device Driver Sensing Hardware

Data Query Object Data Query Object

In this final model, initialization of the DMC includes the definition of a list of physiological signals available on the associated sensing device. For each signal in the list, a new data query object is created. This data query object is interested only in which components want notification about its particular signal. If an upper layer component wants information about more than one physiological signal, it is registered separately with the data query objects corresponding to each of those signals in turn.