System Middleware

Fig. 10.1

Middleware architecture

As can be interpreted from Fig. 10.1, middleware will be installed in a local personal computer (the Home Gateway). Data from the different modalities (EEG, GSR, SPO2, etc…) will be acquired to the personal computer throughout an encrypted wireless channel. Data will be stored and uploaded to PHR server in a time configurable way (mainly in a daily basis scheme), from where data will be accessible and presented in a friendly manner to authorized persons (doctors, caregivers, etc…). When the on-line processing takes place, an event notification trigger can occur, by pressing the push button or by any event detection algorithm in the DSMS component. Depending on the severity of the event, immediate notification to a caregiver will be triggered using the MS (Management Service—SHACU) and immediate sensor data plus event information will be uploaded to PHR. Notice that to allow upload of data a broadband connection at home is required.

10.2.1 Secure Incoming Data

Security and privacy of patient data is of big concern in these cyberphysical systems which have been addressed in Chap. 9.

Regarding the communication, part of the efforts in the project is being concentrated to secure communications at RF level between the sensors and the home gateway by the provision of encryption/decryption engines.

To provide a secure communication between sensor (modalities) and home gateway, both hardware and software solutions are possible. While Chap. 9 explains the encryption phase, the following subsections describe two alternatives for the decryption of sensor data being sent through RF channels. The encrypted data reaching the middleware needs to be decrypted for online processing. There are two ways of decrypting the data, which are described within this chapter, hardware and software decryption.

10.2.1.1 Hardware Decryption Engine

Hardware decryption module follows the same 8-bit architecture presented in Chap. 9. As done in encryption phase, decryption commences by executing the expansion operation in order to produce all intermediate requires keys. After the completion of the key expansion phase the decryption module is ready for the 128-bit data blocks processing. Due to the 8-bit data-path architecture that is used, 16 clock cycles are required to load/unload the 128-bit ciphertext/plaintext block. The input block is decrypted by performing four different byte-oriented transformations, which are executed sequentially and repeatedly (as rounds); the transformations are: Add Round Key, InvSubstitute Bytes, InvShift Rows and InvMix Columns. The resulted intermediate decipher result, known as state, is stored and updated at the end of each round. The number of rounds depends on the size of the key. The actual key size and the number of rounds are configured via the KEY_SIZE input as shown in Table 10.1. Note that, since the key size determines the number of rounds, it also affects the latency of the decryption module. Respective delay and throughput performance is presented in Table 10.1.

Table 10.1

Decryption module processing delay and throughput rate (@200 MHz operating frequency)

Key size (bits)	Processing delay (in clock cycles)	Throughput rate (Mbps)
128	480	53.3
192	582	44.4
256	684	37.4

10.2.1.2 Software Decryption Engine

A decryption module can be developed within xAffect. Its deciphering process can be abstracted as much as possible providing wide algorithm customization.

This module should be designed to be flexible and adaptable which results a highly reusable ciphering/deciphering component that can be used within all the functionalities that xAffect provides, like data collection, data logging, data sending, etc.

10.2.2 Data Fusion

Data Fusion is a process dealing with the association, correlation, and combination of data and information from single and multiple sources. Multi sensor data fusion refers to the acquisition, processing and synergistic combination of information gathered by various knowledge sources and sensors to provide better understanding of a phenomenon.

The most important part of data fusion is, the data itself. Therefore, it is crucial to take care during the capturing in order to minimize uncertainties. However, there is one aspect that is sometimes left behind and in some cases it is the most relevant: adapt metadata in a common format in order to simplify the process.

The data fusion can be classified as low level fusion of data, high level variable fusion and mixture level fusion. When the data fusion is performed before analysis, it is classified as low level. When the data fusion is performed after some data analysis, it is classified as high level variable fusion. There are some situations where we can fuse data and variables.

The overall system architecture, depicted in Fig. 10.1, shows the two paths where processing of sensor data takes place. On-line multi-parametric data processing and analysis takes place at the Home Gateway, while the off-line multi-parametric data processing takes place in different server/database, by (i) accessing/acquiring sensor data from the PHR (previously captured by the system) or by (ii) accessing/acquiring sensor data from external databases not belonging to the system itself. The data flow is depicted in Fig. 10.2.