CONTEXT-AWARE APPLICATIONS

Linnhoff-Popien and Strang (2004) states that context-aware systems have demanded the following terms.

1. Distributed Composition: absence of a central system for coordinating data maintenance and service provisioning.

2. Partial Validation: since it is recommended to be a distributed system, it is well known that complete contextual information will not be available in any particular node; however, it is still desirable to validate the information to make it error-free.

3. Richness and Quality of information: context-aware systems rely heavily on sensors which are hardware components and in due times are prone to give deteriorated quality of information. Also, sensors from different vendors may give the different richness of information.

4. Incompleteness and ambiguity: Interpolation of data might be required since data gathered from sensor networks might be incomplete or ambiguous.

5. The level of formality: Presenting contextual facts with their relationships is quite a challenge. In other words, interpretation should be common among all the participating objects of context.

6. Applicability of existing environments: context models should be within the available infrastructure.

29

for developing context-aware systems. Based on the way the steps of context acquisition, pre-processing, storing and reasoning are performed, three models have been proposed.

 No application-level context model: All actions are performed within the application boundaries.

 Implicit context model: All actions are performed by using frameworks, toolkits, and libraries. Provides standard design for rapid application building.

 Explicit context model: Context management infrastructure or middleware solution is used resulting in stages being outside the application boundaries. The management and application are separated and can be developed and extended independently.

Schilit, et al.(1994) and Pascoe (1998) presented three important features that any context-aware system should process and Charith, et al. (2013) extended the features to accommodate IoT.

 Presentation: Context-aware systems should decide on the information and service that are presented to the user based on location, time and other context attributes Carnot (2011); Moses (2012).

 Execution: Context-aware systems should execute the services automatically without or with minimum human interference.

 Tagging: Context-aware systems should be able to annotate or tag the data collected from numerous sensors as these data has to be fused together.

2.3.1 GENERAL CONTEXT-AWARE APPLICATIONS

A context-aware smart home, proposed by Xiaopeng and Zhiliang (2016), details the services that can be provided for the homeowners. The paper proposes a UML and Colored Petri Net (CPN) based hybrid Context-aware modelling approach. The work mainly focuses on the technique of avoiding deadlocks and formally verifying the model.

Road safety and transportation network are indispensable today and one of the key networks which help them with this mission is the Vehicular Ad-hoc Networks (VANETs). Services such as traffic alert, collision alert, convenient alert and unmanned vehicle driving have been designed based on this network. The paper proposes a framework for applications to be developed on this network considering the environment, application, and context Vahdat, et al. (2016).

2.3.2. HEALTHCARE RELATED APPLICATIONS

Context-awareness in healthcare would help in utilizing the human resource and device resource more efficiently and promote quality of service considering the patient’s condition and need. Some of the context-aware medical applications are: VOCERACOMMUNICATION SYSTEM which got experimented at St. Vincent Hospital, Birmingham, USA uses communicator badge system for mobile user Push-to-call button, small text screen, voice dialling, and hands-free conversation which are biometrically secured with speaker verification Stanford (2003).

STROKE ANGEL experiment was conducted at Bad Neustadt, Germany (November 2005-May 2008). The main aim of this system is to shorten the

31

time requirement for the entire process. That is from discovery and diagnosing the stroke victim to the patient’s admission and treatment in hospitals. This is the main goal is to meet the short time frame in which to treat the stroke patient the first 3 hours after the stroke Orwat, et al. (2010).

In INTELLIGENT HOSPITAL SOFTWARE, University of Cambridge, UK an experimental prototype has been implemented after the study of needs at the Accident & Emergency Department of the Royal London Hospital. The system includes remote consultation, tracking of patients and equipment, notification of awareness and patient data Mitchel, et al. (2000). One more study was conducted for a period of 8 months in mid-size public hospitals in the city of Ensenada, Mexico. The emphasis was done on the activities performed by three roles. They are Nurses, Physicians and the medical interns Favela, et al. (2006).

A decision-level data fusion technique for monitoring and reporting critical health conditions of hypertensive patients. H-SAUDE (Health Support in Aware and Ubiquitous Domestic Environments) proposes an architectural framework for individualization of treatment, influence of the patient activity and of the home environment, relaxation (or loosening) of the limits of each monitored variable Copetti, et al. (2009). Hospital based prototypes involve the design of a context-aware pill container and a context-aware hospital bed, both of which reacts and adapts according to what is happening in their context Bardram, (2004).

MobileWARD (Mobile Electronic Patient Record, Denmark) project supports morning procedure tasks in a hospital ward, information, and

functionalities according to the location of the nurse and the time. Few other prototypes include medication consumption, distant monitoring and new assistants Skov and Hegh, (2006). The afore-mentioned research works reveal three relevant classes of information which have been identified to gather through the pervasive device. These are Environmental, Psychological, and Behavioural.

Erik et al. (2016) in their work, applied context awareness to e-Health and m-Health catering to the needs of households. An implementation of social sensor prototype to exhibit their flexibility, complexity and cost features which use a Bluetooth transceiver is described. Data acquisition from multiple sensors has been demonstrated in the work.

A context-aware framework illustrates abstracted layers which could be envisaged in a system that claims to be context-aware. A framework or an architecture supporting context-aware system or a context-aware middleware should either be built or capable of building by incorporating this abstracted model. The above said higher level abstractions are only possible to be built from a lower level abstraction or context management.

Any context management should possess the features such as context acquisition, aggregation and fusion, dissemination, discovery. Context acquisition can be made from various sources namely; sensors, social media, web databases. The acquired data can be filtered to form the high level abstraction of the context. The next step of dissemination involves passing on the context to the other entities. Situation recognition entities and Reasoning engines along with objects involved in recognizing situations should find sources of context and publish it. The challenge in designing

33

grows bigger when the context dissemination and discovery is over a distributed system. Therefore ensuring quality in the acquired and reasoned out context is an absolute required feature of context management.

Context-aware systems manage context on different levels of abstraction.

Contextual information can be represented by a single scalar value such as

“body temperature is 101.6 degrees Fahrenheit” which represents the raw output of a sensor. Contextual information can also be a higher-level semantic description of a situation such as “Patient is having fever”.

Therefore, a context-aware system should be capable of interpreting from a raw sensor data meaningful information abstracted appropriately. There should be a transformation of low-level sensing to high-level context provision Baker (2009).

2.4 SERVICE ORIENTED ARCHITECTURE AND SERVICE