OpenCores

REQUIREMENTS & INTERFACES FOR SMART WORK PROCESS

by reena_152 on 2006-04-20
source:
ABSTRACT

This paper describes Requirements and Interfaces for smart work processes in context rich environments. Smart work process4 is a work process that senses the environment which it performs in, adapts to relevant context or context changes through context-based reasoning to reach process goals, and actuates by providing situated activities. Smart work process architecture provides a framework for smart work processes. It aims at making the mobility transparent to the mobile worker. In this paper, Requirements based on this architecture are elaborated. These requirements will be the backbone of the services the system should provide and will be the basis of any system design. Finally, Interfaces between various entities of the architecture are defined and explained, which will provide communication details between various entities to the system designer.


Keywords: Mobile work, Smart work process, Requirements, Interfaces

1. INTRODUCTION

The development in mobile and wireless technology has changed the ways in which activities can be performed and supported by giving opportunities to automate and support work processes in real-time irrespective of time and location of the worker. It opens new possibilities to provide computational support for both professional and private activities, “anytime” and “anywhere”.
Mobile computing is one of such technologies. It is a confluence of communication technologies, computing devices and their components, and access technologies such as wireless. A mobile computing environment will include not only real-time mobility of devices, but also mobility of people across devices. Therefore, the environment includes a wide range of devices, applications, and networks. A mobile environment is characterized to be very dynamic in terms of available resources.
Users expect that many of the properties in the fixed computing environment also retain in a mobile computing environment. Access to necessary and demanded information and the ability to persistently record information in a work situation are both requirements that must be taken into account when building applications for mobile usage.
Smart work process is a concept to capture adaptive and context-aware process support. Smart work process is a work process that is sentient, i.e., sense the environment which it performs in, adapts to relevant context or context changes through context-based reasoning to reach process goals, and actuates by providing situated activities, or by changing/refining the current planned activities.
In this paper, first smart work process architecture is briefed. Then requirements for each of the entity in the architecture are elaborated. Afterwards, interfaces between entities in the architecture are defined. Finally, some issues are discussed and then scope of further work is enlisted.
2. SMART WORK PROCESSES ARCHITECTURE

The architecture consists of seven main parts which will be described in more detail in Fig i.
2.1 Actuator
An actuator is an entity that is able to change the environment based on digital input from some digital equipment.
2.2 Sensor
A sensor is responsible for measuring, and transmitting sensor readings according to specifications by the context service.
2.3 Actuator Service
An actuator service is responsible to initiate actuations in an environment.
2.4 Context Service
A context service2 is responsible for identifying sensors, initiate sensor readings, check sensors, setup/terminate sensor subscriptions, etc., i.e., provide the communication with all actual sensors.
2.5 Client-Based, Context-Aware Workflow Enactment Service (CAWES)
CAWES is responsible for monitoring and executing delegated activity (ies), through surveillance of the current process/activity state1, and contextual events received either from the context service3, the COWCS (2.6), or the Server-based Workflow Enactment Service(2.7).
2.6 Client-Based Cooperative Workflow Coordination Service (COWCS)
COWCS is responsible for managing and coordinating activities in a multi-actor environment. This includes a coordination service that, based on policies, can send messages to all involved parties about coordination needs and competitive resources etc.
2.7 Server-based Workflow Enactment Service
The Server-based Workflow Enactment Service is responsible for traditional workflow management including sending activities to the users, based on delegation/plans, and managing the complete, high-level process for the involved participants.
3. PROPOSED REQUIREMENTS

Smart work process architecture provides framework to imagine the system. But to bring this into shape, some core guidelines are needed. So we have derived a list of requirements below for each of the entities in the architecture. These requirements will form the basis of system design.
3.1 Actuator
 Actuator ID
It is Identification Number of Actuator. It may be from a simple numeral to complex addresses like IP address.
 Location of Actuator
Location of Actuator may be specified by a simple group of characters to as complex as GPS location.
 Name(s) of Environment property/ies
This characteristic of Actuator indicates the properties of the environment controlled by the actuator. The actuator can change these properties.
 Parameter(s) of Environment Property (ies)
Each of the environment properties requires a list of parameters to specify the environment settings.
3.2 Actuator Service
 Service Clients’ Specifications
Specifications of clients who have requested/may request for Actuator Service .
 List of all Actuators
IDs of all the Actuators available to the Actuator Service
 For each actuator:
Details of the Actuator
Actuator ID, Location of Actuator, Name(s) of Environment property/ies and Parameter(s) of Environment Property (ies) .
Communication media
Communication media to send and receive messages to/from Actuator .
Status of each Actuator
Some Actuators may not be in working condition. Status indicates whether Actuator is available for service to Actuator service or not.
3.3 Sensor
 Sensor ID
It is Identification Number of Sensor2. It may be from a simple numeral to complex addresses like IP address.
 Location of Sensor
Location of Actuator may be specified by a simple group of characters to as complex as GPS location.
 Name(s) of Environment Property (ies)
This characteristic of Sensor indicates the properties of the environment measured by the Sensor. The sensor can change these properties.
 Parameter(s) of Environment Property (ies)
Each of the environment property requires a list of parameters to specify the environment settings need to be sensed.
3.4 Context Service
 Clients’ Subscription Details
Specifications of clients who have requested/may request for Context Service .
 Sensor subscription properties
It is a structure representing which client has subscribed for which of the sensor properties .
 List of All Sensors
IDs of all the Sensors Available to the Context Service .
 For each sensor
Details of the Sensor
Sensor ID
Location of Sensor
Name(s) of Environment property (ies)
Parameter(s) of Environment Property (ies)
Communication media
Communication media to send and receive messages to/from Actuator .
Status of each Sensor
Some Actuators may not be in working condition. Status indicates whether Actuator is available for service to Actuator service or not.
3.5 Client
 ClientID
Identification code of Client
3.5.1 CAWES
 CAWES Service Client ID:
Identification code of CAWES1
 List of activities to be performed/delegated by CAWES3
 List of Events to be sent/received by CAWES
 Structure for Parameters of Environment Properties to be read
3.5.2 COWCS
• Resource(s) Property (ies) Structure
It contains details of all the available resources

• List of All Actors
IDs of all the actors and their other details in a multi actor environment
• List of co-ordination messages
3.6 Server-based Workflow Enactment Service
• Traditional workflow management:
System for traditional activities like sending activities to the users, based on delegation/plans and managing the complete, high level process for the involved participants.
3.7 Mobile Worker
• Mobile Worker ID:
Identification code of Mobile Worker
• List of Process Goals
4. PROPOSED INTERFACES

Requirements help define the needs of the system. But details of how the entities work together may still not be clear. Queries like “what all details will be communicated between any of the entities”, “who will be responsible for what activity” still remain unattended. Each of these needs to be clearly understood before system design. The next step after understanding the requirements is to identify interfaces between various entities. These interfaces will decide the communication between entities of the system.
4.1 Actuator – Actuator Service Interface
Values of parameters of the Environment property to be set
Response of Actuator to Actuator Service (OK / NOK)
4.2 Sensor – Context Service Interface
Parameters of the Environment property to be read
Measured Readings
Readings Transmission Status
4.3 Actuator Service – CAWES Interface
CAWES Service Client ID
Values of parameters of Environment properties to be set by Actuator(s)
Response of Actuator(s)
Status of Actuator(s)
4.4 Context Service – CAWES Interface
CAWES Service Client ID
Parameters of Environment properties to be read by Sensor(s)
Response from Sensor(s)
Status of Sensor(s)
4.5 CAWES – COWCS Interface
For each delegated activity
Environment properties to be set (change environment state)
Environment properties to be sensed (measured)
Contextual events
Activities delegation signals
4.6 CAWES – SBWES Interface
Contextual events
Activities delegation signals
4.7 COWCS – Mobile Worker
Mobile Worker ID
Details of demanded resources
Details of Available resources
Detail of currently performed activities by Actors
5. Applied to a scenario

Let us consider a mobile scenario of automatic driving. A car is moving from location X to location Y, Fig. ii. The purpose of our “Mobile System for Car” is to provide all the infrastructure (hardware) and software to support the target of moving from A to B.
In this scenario, car is the mobile worker. Road, traffic, traffic signals, toll tax boxes etc. form the environment. The environment status keeps on changing with time. So our Mobile worker, i.e. the car, is in a dynamic environment. The car communicates with the Client software to get instructions. The client software communicates with the SWBES to get traditional workflow instructions and information, e.g. the roadmap from A to B, time available to reach B, etc. There can be traffic signals (TS) on the route. The Sensors(S) present in the environment will guide regarding traffic signals. There can be Toll Tax Boxes (TTB) on the route. It is necessary to pay the toll tax to get the route cleared. Hence, there is a need to change the Environment. The Actuator (A) present in the environment will pay toll tax and get the route cleared.
The purpose of this example is to explain the requirements and interfaces. So this example is just explanatory and not exhaustive.
Based on the given details, some requirements(6.1) can be listed:
5.1 Requirements
5.1.1 Actuator
Actuator ID:
An, where n can be 1, 2, 3 …
Location of Actuator:
LAn, where n can be 1, 2, 3…

Name(s) of Environment property/ies:
Toll Tax Box
Parameter(s) of Environment Property (ies):
Toll Tax Amount
Status of Toll tax box gate
Location of Toll Tax Box
5.1.2 Actuator Service
Service Clients’ Specifications:
Clientx, where x can be 1, 2, 3…
List of all Actuators:
A1, A2, A3, A4
Details are given in Table i .
5.1.3 Sensor
Sensor ID:
Sn, where n can be 1, 2, 3 …
Location of Sensor:
LSn, where n can be 1, 2, 3….
Name(s) of Environment Property (ies):
Traffic Signal
Parameter(s) of Environment Property (ies):
Traffic Signal Status (Red / Yellow / Green)
Distance of traffic signal
5.1.4 Context Service
Clients’ Subscription Details:
Clientx, where x can be 1, 2, 3…
Sensor subscription properties:
For each of x in Clientx
ClientIDx
List of sensors subscribed
List of All Sensors:
S1, S2, S3, S4
Details are given in Table ii.
5.1.5 CLIENT
ClientID
Clientx where x can be 0, 1, 2, 3…
5.1.5.1 CAWES
 CAWES Service Client ID:
CAWESClientx where x can be 0, 1, 2, 3
 List of activities to be performed/delegated by CAWES
Collect Status of sensors (S1, 2, 3…)
Collect Status of Actuators (A1, 2, 3…),
 List of Events to be sent/received by CAWES
SensorNotResponding
ActuatorNotResponding
RoadMapNotMatch
 Structure for Parameters of Environment Properties to be read:
Traffic Signal Status (Red / Yellow / Green)
Distance of traffic signal
5.1.5.2 COWCS
• Resource(s) Property (ies) Structure:
List of sensors and actuators
• List of All Actors:
List of all the cars with details
• List of co-ordination messages
ResourcesNotAvialable
RouteBusy
ActorNotBehavingLogically
5.1.6 Server-based Workflow Enactment Service
• Traditional workflow management:
All the tasks related to normal working of automatic driving system. This can be based on the MOWHAS framework.
5.1.7 Mobile Worker
• Mobile Worker ID:
MobileCarx where x can be 0, 1, 2, 3…
• List of Process Goals
ReachTheDestination
OvershootTime
5.2 Interfaces
5.2.1 Actuator – Actuator Service Interface
• Values of
Toll Tax Amount
Status of Toll tax box gate (open / closed).
Location of Toll Tax box
• Response of Actuator to Actuator Service
(OK / NOK)
5.2.2 Sensor – Context Service Interface
 Parameters
Traffic Signal Status (Red / Yellow / Green)
Distance of traffic signal
 Measured Readings
Traffic Signal Status (Red / Yellow / Green)
Distance of traffic signal
 Readings Transmission Status (Success/Failure)
5.2.3 Actuator Service – CAWES Interface
 CAWES Service Client ID
CAWESClientx where x can be 0, 1, 2, 3…
 Values of
Toll Tax Amount
Status of Toll tax box gate (open / closed).
Location of Toll Tax box
 Response of Actuator(s)
(OK / NOK)
 Status of Actuator(s)
(Active/Inactive)
5.2.4 Context Service – CAWES Interface
 CAWES Service Client ID
CAWESClientx where x can be 0, 1, 2, 3…
 Parameters of Environment properties to be read by Sensor(s)
Traffic Signal Status (Red / Yellow / Green)
Distance of traffic signal
 Response from Sensor(s)
(OK / NOK)
 Status of Sensor(s)
(Active/Inactive)
5.2.5 CAWES – COWCS Interface
 Environment properties to be set (change environment state)
Toll Tax box clearance
 Environment properties to be sensed (measured)
Traffic signal status
 Contextual events
SensorNotResponding
ActuatorNotResponding
RoadMapNotMatch
 Activities delegation signals
GetNextActivity
5.2.6 CAWES – SBWES Interface
 Contextual events
SensorNotResponding
ActuatorNotResponding
RoadMapNotMatch
 Activities delegation signals
FindmobileWorkerStatus
5.2.7 COWCS – Mobile Worker
 Mobile Worker ID
MobileCarx where x can be 0, 1, 2, 3…
 Details of demanded/available resources are given in Table iii.
 Detail of currently performed activities by Actors are given in Table iv.

6. DISCUSSION

In this paper, requirements and interfaces have been defined for smart work process. The requirements listed give an elaboration of the system. These will help identify some details which may go unattended otherwise. Interface explains the relationship between various entities.
The car scenario clarifies how these can be used to describe a scenario. Of course, some assumptions are still there, like dynamic changes in the roadmap, which are not covered in this example. However, some of the details needed to ensure a safe and dependable support of smart work processes may be hard to address.
Situated action and situated planning are the areas open for further enhancement of the Requirements and interfaces.
7. FURTHER SCOPE

To get more experiences with and to valid our investigations, options below can be considered:
Try the Requirements and Interfaces on more scenarios to improve/extend them to cover mobile work in as many areas as possible.
Try the Requirements and Interfaces on already implemented systems. This may validate the Requirements and Interfaces based on the feedback and will enhance their utility further.













8. REFERENCES
[1] Gregory D. Abowd, Christopher G. Atkeson, Jason Hong, Sue Long, Rob Kooper, and Mike Pinkerton, Cyberguide: A Mobile Context-Aware Tour Guide. Wireless Networks, 3(5):421–433, 1997.
[2] Steven Ashley, Smart Cars and Automated Highways, Mechanical Engineering Magazine, May 1998. http://www.memagazine.org/backissues/may98.
[3]Victoria Bellotti and Keith Edwards, Intelligibility and Accountability: Human Considerations in Context-Aware Systems, Human-Computer Interaction (HCI) Journal. Special Issue: Context-Aware Computing, 16(2–4):193–212, 2001.
[4]Carl-Fredrik Sørensen, Alf Inge Wang, and Reidar Conradi, Support of Smart Work Processes in Context Rich Environments, In John Krogstie, Karlheinz Kautz, and David Allen, editors, IFIP TC8 Working Conference on Mobile Information Systems (MOBIS’2005),Leeds, UK, December 6-7 2005. Springer, New York, USA. IFIP 191/2005.
9. GLOSSARY

CAWES – Client-Based, Context-Aware Workflow Enactment Service
COWCS – Client-Based Cooperative Workflow Coordination Service
GSM – Global System for Mobile telephony. Second generation (2G) mobile telecommunication system
MOWAHS – Mobile Work Across Heterogeneous Systems.
Process definition – The representation of a business process in a form which supports automated manipulation, such as modelling, or enactment by a workflow management system. The process definition consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc.
SBWES – Server-based Workflow Enactment Service




10. FIGURE CAPTIONS


Fig. i : Smart Work Process Architecture
It is composed of actuator , sensor, mobile worker , actuator service, context service, client , CAWES, COWCS, server-based Workflow Enactment Service.
Fig. ii : Roadmap for Mobile Car from X to Y
It describes the roadmap for mobile car from X to Y as given in example of automatic driving. The purpose of example is to explain the Requirements and Interfaces.








11. TABLE CAPTIONS

Table i : Details of Actuator Service
It has 7 columns and 5 rows. There are 4 actuator ids and corresponding to each actuator id there is location , environment property , parameters , status and media.

Table ii : Details of Context Service
It has 7 columns and 5 rows. There are 4 sensor ids and corresponding to each sensor id there is location , environment property , parameters , status and communication media.
Table iii : Details of demanded/available resources
It has 4 columns and 3 rows. For each resource there is corresponding demand , status and currently occupied mobile car.
Table iv : Details of currently performed activities by Actors
It has 3 columns and 3 rows. For each actor there is corresponding status and activity.
Fig. i









Fig. ii





Table i


Actuator No Actuator ID Location Environment Property Parameters Status Media
1 A1 LA1
Toll Tax Box
1. Toll Tax Amount
2. Status of Toll tax box gate.
3. Location of Toll Tax box Active Wireless
2 A2 LA2 Active Wireless
3 A3 LA3 Active Wired
4 A4 LA4 Inactive Wireless















Table ii


Sensor No Sensor ID Location Environment Property Parameters Status Communication Media
1 S1 LS1
Traffic Signal 1. Traffic Signal Status
2. Distance of traffic signal Active Wired
2 S2 LS2 Active Wireless
3 S3 LS3 Active Wireless
4 S4 LS4 Inactive Wireless























Table iii


Resource Demanded by Currently occupied by Status
A1 MobileCar0 MobileCar1 Not Available
S1 MobileCar1 --- Available


























Table iv


Actor Activity Status
MobileCar0 Take left turn Ongoing
MobileCar1 Get S1 status Waiting

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.