This chapter introduces a development methodology of pervasive applications based on the application model and execution framework in Chapter 3. Following the specification principles of context model, process schema, and service description, the developers can design their pervasive applications. and
illustrate how to develop pervasive applications from two distinct viewpoints.
indicates the necessary data items in the development methodology, whereas shows the development workflow for such applications in BPMN.
Figure 4-1
Figure 4-1
Figure 4-2
Figure 4-2
Figure 4-1: The Basic Data Model at Each Activities of Development Methodology.
39
Figure 4-2: A Development Workflow Diagram Designing a Pervasive Application.
In Figure 4-2, the application developers are categorized into three main roles:
application analyzer, element developer, and application deployer. By combining both viewpoints in Figure 4-1 and Figure 4-2, we present a development methodology with workflow for pervasive applications as below:
(1) Application Analysis and Requirement Specifications by Analyzers:
Through the investigations or negotiations with customers, this stage analyzes the following data and questions completely:
40
I. The goal of the application with necessary service processes.
II. The participants/organizations in this application.
III. Used pervasive services in this application.
IV. The context entities with their attributes and relationships for the applied environment.
In this stage, the above data are closely-related to the rest of development methodology. Items I and II are used for the process construction in the Step (2-2). Item III assists the developers to give universal service descriptions in the Step (2-3) and build the context information of service part in the domain-specific context model. Item IV helps to construct the knowledge about the deployed environment, and is derived from the generic context model presented in Chapter 3. In addition, the domain analysis [40][41][42] helps the developers define the common and variable parts in Step (2-1).
(2) Constructing Elements by Element Developers:
This stage develops the data items inside each of three elements shown in . The development workflow in contains: (2-1) Building the domain-specific context model with reasoning rules, (2-2) Building processes/workflows, and (2-3) Building service descriptions, as below:
Figure 4-1 Figure 4-2
(2-1) Building Domain-Specific Context Model with Reasoning Rules:
41
Figure 4-3: A Workflow of the Domain-Specific Context Model Construction (CMC)
Figure 4-3 illustrates the workflow of domain-specific context model construction: Firstly, the element builders decide whether to reuse the existing domain-specific context model. If yes, the element builders search suitable/applicable models. Otherwise, they build their own model with the following steps:
Step 1: Derive basic entities, their context attributes and relationships.
This step uses Item IV in Stage (1) to construct the knowledge about the applied environment.
Step 2: Define deduced situation classes with reasoning rules. The semantic meanings deduced from the raw context data are
42
defined as the deduced situation classes in the domain-specific context model. In order to achieve the application goal, a deduced situation represents an event that a designed application is required to handle. The developer extracts the deduced situations from Item I in Stage (1).
Next, the element builders check the consistency and completeness of the first context model developed, and tunes it up if necessary. The context-model checking involves the ontology checking [49][50][51][52][53]. The result of model checking may contain a fatal error. For example, a context entity derived in (IV) in Stage (1) may not be well compiled in the model. If such an error occurs, a re-modeling work is adopted, so does the checking. The followings indicate the checking searches the following ontology errors:
(1) Trivial errors: Syntax errors or type errors.
(2) Logical errors (consistency in ontology): Disjoint contradiction, complementary contradiction, and others like Satisfiability, Subsumption, Equivalence, etc.
(3) Redundant rules: Rules that infer the same situation can be merged.
The checking-and-tuning is a loop until the errors in the designed domain-specific context model are solved. There are several tools [49][54]
which can be applied to perform the checking/tuning. Then, the deduced situation classes are transmitted to the process builders to perform (2-2).
43
Besides, the service entities defined in the domain-specific context model might be performed concurrently; however, its developing activity cannot start until (2-3) completes. In , we use a massage event to indicate the wait. After getting the services, the corresponding (service) part in the model is constructed and (2-1) completes.
Figure 4-3
(2-2) Building Process/Workflow:
In this sub-stage, the element developers extract the processes/workflows from the Items I and II. There are at least two types of processes needed to be constructed:
Figure 4-4: The Workflow of Building Process/Workflow in an Application (BPW)
i. The processes associated with participants/organizations: This process is globally in charge of the cooperation among participants/organizations based on control logic and transitions.
44
ii. The event-handling process: This process deals with the events delivered from context management system. The events correspond to the deduced situation classes in Step 2 in (2-1), Hence, the developers identify events and specify the event-handling processes.
The built processes in the above type ii are relevant to the context-changing and the correspondent reaction, while the built processes in the type i are not.
Figure 4-4 illustrates the workflow of building process/workflow. In the beginning, it contains two sub-flows. In the bottom flow, the element builders construct processes of type i that are associated with participants/organizations. In the top flow, a message event is designed to represent the wait: the event-handling process of type ii relies on the context entities and deduced situation classes specified in (2-1); i.e., the element builders cannot start to construct this type of processes until the specification of context entities completes.
If a process of other types is needed, it can be constructed in the last developing activity after a concurrent join of the above two sub-flows in . Finally, the process builders inform the service builders when the application process/workflow building is complete.
Figure 4-4
(2-3) Building Services Descriptions
45
Figure 4-5 illustrates the workflow for building service descriptions. In the beginning, it contains two sub-flows. The top flow waits until the element builders completes the specification of processes/workflows in (2-2) and pass them in. After passing the built processes/workflows in, the element builders attach the required service descriptions to the tasks of each built process/workflow. In the bottom flow, the element builders specify the service descriptions to used pervasive services in the applied environment.
Hence, a developing activity transmits services described previously and throws a message event to notify the waiting of CMC in Figure 4-3. The specification of service descriptions in the above two sub-flows conform to OWL-S format in Chapter 3. After a concurrent join of the above two sub-flows in Figure 4-4, the construction of (2-3) is completed.
Figure 4-5: A Workflow of Building Service Descriptions (BS)
46
After the construction of the service parts of domain-specific context model in (2-1) is completed, all the elements in a pervasive application are built and a pair of throwing–catching events indicates to go to the next development stage.
(3) Deploying Execution Framework Based on Target Environments By Deployers:
Firstly, to instantiate the designed pervasive application system, the developers deploy CMS, WfMS, and SMS in the application environment according to our framework as centralized or distributed. For example, a smart home can adopt the centralized deployment approach, while a hospital or a shopping mall is suggested to use the distributed deployment approach.
Next, the developers may request the service providers to furnish used pervasive servicers in all derived-processes if the applied environment lacks of them. For example, the used pervasive services in a pervasive healthcare application are wearable sensors, video sensors, handhelds etc. in a smart home.
Finally, the applications developers put the built elements into three repositories in the execution framework: (1) the context-model elements including the generic and domain-specific context models are put into the context repository, (2) The reasoning rules are put into the rule repository, and (3) the process/workflow elements with the required service descriptions are put into the process repository.
47
(4) Execution and Feedback:
This stage performs the testing of the designed pervasive application. There are several challenges associated with the testing of pervasive applications:
(1) Testing data rely on the sensor data. In [58], T.H.Tse et al. indicates that the simulated and real senor data are both crucial to examine a pervasive application.
(2) The pervasive applications are not adequate to perform unit testing since In [59], M. Bylund and F. Espinoza indicate the behavior of context-aware applications is determined by rules that may be independent from the codes.
In terms of the above challenges, so far there are no efficient solutions to solve these problems. Hence, we present a simple testing strategy by means of the workflow integration testing currently. According to the requirement of the designed application, the testers design the testing sets of context information and examine their execution results and behaviors. The application running with test sets may indicate: (a) Deadlock, happening if more than two workflows access the same services. (b) Unreachable states in the defined process.
Once the testing results yields the unsatisfactory behavior, these test results are feed backed to element builders to fine-tune the built elements, and the whole work is started as the next turn. The details of testing activity will be studied further in our future work.
48
Chapter 5 Case Study: A Pervasive Healthcare System for a Smart Home
This chapter applies our methodology to the example described in Section 2.4.3 to indicate its usability. Obviously, a smart home is usually supported by one or more healthcare center/providers for emergency handling. Each step in the development is described in details as follows:
(1) Analysis and Requirement Specification :
I. Several service processes to achieve the goal of this application:
A. Daily scheduling process: Arrange a target patient’ daily schedule according to her/his medical history and physician’s instruction.
B. Regular serving process: Daily serves according to the scheduling from A.
C. Context monitoring process:
(1) Bio-signal measurement process: Gather a patient’s bio-signal data like the blood pressure repeatedly.
(2) Posture-capturing processes: Capture the patient’s motion/posture repeatedly.
D. Emergency handling: If the abnormal blood pressure or abnormal motion/posture is detected from C, the emergencies are identified to request the healthcare center to provide aid-support.
49
II. Participated organizations:
The organizations in this application are categorized into: (1) Smart Home (2) Healthcare center, and (3) Healthcare provider including hospitals, where the latter two are third-parties for supporting. Each target patient is located at a smart home. And, the environment information in a smart home is specified as context entities in a home-specific context model. The details of context entities in a smart home are analyzed in IV.
III. Used services in a smart home:
The context providers include wearable sensors and video sensors.
A handheld is in charges of processing the context data and displays the jobs according to the patient’s daily schedule. PCs have a capability to perform a video conference with staffs in the healthcare center or physicians in hospitals. These devices should be connected through wireless network.
IV. The context entities with their attributes and relationship in a smart home:
The following analyzes the context entities in a smart home based on the generic context model presented in Chapter 3.
The subclasses of person in a smart home are patient, physician, and nurse. Physicians and nurses can contact with the target patient through video conference. Thus, the context management system in a smart home needs to know the above persons at least. In addition, since the application
50
is aimed at the patients with hypertension, a subclass of hypertension patient inherited from the patient class is required.
In a smart home, the basic chambers are living room, bedroom, bathroom, kitchen, corridor and stairway. They are the subclasses of indoor space. The subclasses of outdoor space around a smart home are courtyard, backyard … etc.
In terms of activity, the scheduled activities of a patient include medicine treatment, therapy, diagnosis, and so on.
Context providers directly collect the raw data of context viewed as the type of sensed context. The sensed contexts are concluded: (1) blood pressure with diastolic and systolic, and (2) the patient’s motions These sensed contexts are focused on the target patient’s status and must be specified as attributes relevant to the patient entity in a smart home context model.
With respect to deduced situations, the emergency inherited from deduced situations contains morbidity (Morbidity of hypertension) and falling. The deduced-situation classes and their happening conditions are:
(1) Morbidity: The morbidity of hypertension happens if the Diastolic greater than 140 mm hg and Systolic greater than 90 mm hg.
(2) Falling: The motion is falling (abnormal motion). The video images are judged by the image analysis techniques (e.g. the suddenly-fast moving track).
51
(2) Constructing Elements
(2-1) Define Domain-Specific Context Model with Reasoning Rules:
In accordance with context entities defined in Stage (1), we utilize the OWL format described in Chapter 3 to specify the context model in a smart home. Figure 4-4 shows the mapping result.
The reasoning rules defined for subclasses of deduced situations include:
Figure 5-1: The Domain-Specific Context Model in a Smart Home
(1) Current status of a patient’s health:
A. Morbidity of hypertension:
52
(?u diastolic > 140) ∩ (?u systolic > 90)
Î (?u DeducedSituation Morbidity_of_Hypertenstion)
B. falling:
Since falling is judged by image analysis techniques, the context management system gathers the motions of the patient and transmits them to healthcare center to acquire the image analysis results.
(2) Location of Patient:
#(?vs instanceOf video senor)
(?vs locatedIn ?location) ∩ (?vs capture ?u)
Î (?u locatedIn ?location)
A deduced situation is associated with an event. For example, the morbidity class is relevant to the MoH (Morbidity of Hypertension) event that triggers the warning sub-process specified in the (2-2).
(2-2) Building Processes/Workflows:
53
Figure 5-2: A Workflow of Pervasive Healthcare Involving the Smart Home, Healthcare Center, and Healthcare Provider
Figure 4-5 illustrates the details of the processes associated with all the participated organization by BPMN. In the beginning, the application concurrently activates three sub-processes in a smart home: (1) Bio-signal measurement sub-process, (2) Posture capture sub-process, and, (3) Daily schedule sub-process. The above two are in charge of monitoring the
54
patient’s status (Context monitoring process) and repeat per time units.
The gathering data of patient’s condition will transmit to the healthcare center. The latter one includes a scheduling process and regular serving process.
(1) Bio-signal measurement sub-process:
Figure 5-3: The Bio-Signal Measurement Sub-Process
Figure 5-3 shows the detailed elements of the bio-signal measurement sub-process. The context provider in this sub-process is wearable sensor gathering/measuring the patient’s bio-signal data. After sensing the bio-signal data, CMS updates the data instance of the context model, and applies the rules to acquire the deduced situation. Finally, the CMS initiates and sends Morbidity of Hypertension (MoH) event to the corresponding handling process (Warning process).
(2) Posture capture sub-process:
55
In the demonstration example, we adopt a simple approach to monitor the patient’s motion/posture. The patient’s motions gathered by video sensors are directly transmitted to healthcare center. And, the staffs in the healthcare center or related expert systems can monitor whether the patient is abnormal.
(3) Daily schedule sub-process:
Figure 5-4: The Daily Schedule Sub-Process Containing the Scheduling and Regular Serving Process
Figure 5-4 illustrates the daily schedule sub-process containing the scheduling and regular serving processes. The daily schedule sub-process arranges the patient’s to-do-list through contacting the hospital and checking the physician’s instruction. The daily to-do-list can be wrapped
56
into a schedule description for regular serving process to perform. Based on the date, the regular process executes the appropriate process. Figure 5-5 gives a simple example about a possible schedule for Monday.
Figure 5-5: An Example of Regular Serving Process
When the bio-signal measurement sub-process is executing, the morbidity of hypertension (MoH) event is triggered if the emergency rule is satisfied. Thus, the emergency handling process (warning process) associated with the smart home and the third-parties are activated. In the smart home, it captures and reacts for the MoH event, and performs video conference immediately to healthcare center. In healthcare center and providers, they identify the emergency level and provide the appropriate aid-support.
57
Figure 5-6: A Warning Process Corresponding to MoH Event
Figure 5-6 depicts the warning sub-process in the smart home. Once the MoH event is captured, the warning process containing a sequence of tasks will be performed by service management system. The first task asks context management system to get the patient’s current location and marks up the services at the same location. The second matches computers required to perform video conference among the mark-up services. After the second task picks up the candidate computers, the third task applies a selection policy to allocate a computer to start the video conference between the smart home and healthcare center.
Since the example is focused on the healthcare application in a smart home, the process-design in the healthcare center and providers are not concerned. However, we should identify the communication flows among the smart home and the supporting parties. The following demonstrates possible processes associated with these third parties.
58
In the healthcare center, the primary activity is the professional judgment of a patient’s bio-signal data and motions from the smart home as shown in Figure 4-5. The approach of professional judgment may utilize an expert system or a real physician to analyze the patient’s bio-signal data and motions. Besides, the professional judgment also provide second check whether the erroneous judgment from the smart home.
In the healthcare provider, we give an example process in Figure 5-7.
There are two emergency levels needed to be handled: (1) Medium level and (2) Heavy level. If the received message-event is medium, the healthcare provider sends ambulance. If heavy level, the healthcare provider sends helicopter and concurrently inform the physician in order to save the time. No matter a received event is the medium or heavy level;
they finally activate the correspondent handling process in hospital.
Figure 5-7: An Example of Emergency Handling Process in Healthcare Provider
59
In conclusion, the three participating organizations have their own flow to perform. Among them, the smart home arranges the patient’s daily schedules, and continuously monitors and transmits the patient’s data to the healthcare center. If any emergency is identified, the healthcare center requests the healthcare provider to send appropriate aid support based on the emergency levels. By means of connecting these participating organizations, a entire pervasive healthcare application is constructed.
(2-3) Building Service Descriptions:
There are two kinds of service description needed to be constructed: (1) The required service description for tasks within designed processes, and (2) The service descriptions for pervasive services. The service description conforms to the format of OWL-S described in Chapter 3.
(1) The required service description for tasks within designed processes: Two examples of required service descriptions are shown as the following Figures 5-8 and 5-9: (1) the required service for the activity of “measure bio-signal” in Figure 5-3 and the required service for the activity of “match computer” in Figure 5-6.
60
<Match Computer>
<Process: AtomicProcess rdf:ID =“Computer”>
<process: hasInput>
<process: Input rdf:ID = “Micro Phone”>
</process: Input rdf:ID >
<process: Input rdf:ID = “Camera”>
</process: Input rdf:ID >
</process: hasInput>
<process: hasOutput>
<process: Output rdf:ID = “Speaker”>
</process: Output rdf:ID >
</process: Output rdf:ID >