PSAFactory: An End-User Programming Tool for Building Participatory ...

2014 IEEE International Conference on Global Software Engineeering Workshops

PSAFactory: An End-User Programming Tool for Building Participatory Sensing Applications Jiangtao Wang1, 2,Yasha Wang1,3,*, Hao Wang1, 2 1 Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing 100871, China 2 School of Electronics Engineering and Computer Science, Peking University, China 3 National Engineering Research Center of Software Engineering, Peking University, China {wangjt10, wangys, wanghao13}@sei.pku.edu.cn *Corresponding Author campaign participant. The campaign initiators are those who initiate and manage a participatory sensing campaign. They are usually city administrators or people who care about the public interest. The campaign participants are residents taking part in the campaign by collecting and sharing sensing data.

Abstract— Participatory Sensing is a new paradigm that empowers non-professional citizens to collect and share sensory data from their surrounding environments using their mobile phones. The emergence of the participatory sensing has resulted in a broad range of novel participatory sensing applications (PSA). PSA are more suitable to be developed by the people who want to launch the campaign, rather than the professional software developer. However, the development of PSA requires complex programming skill, and thus only professionals can build them.

Comparing with traditional sensor networks which rely on the pre-deployment of large number of static wireless sensors, participatory sensing has two advantages. First, since participatory sensing leverages existing sensing (mobile phones) and communication (cellular or Wi-Fi) infrastructure, the cost of deployment are much less. Second, the inherent mobility of the phone users provides unprecedented spatiotemporal coverage and makes it possible to observe unpredictable events. There are some examples of participatory sensing.

Inspired by the concept of end-user programming, this paper develops a tool, named PSAFactory, for non-professional people who do not understand the programming techniques to develop their own PSA in a quick and simple way. With this tool, non-professionals can build PSA by just doing some simple settings, while the tool will run automatically to tackle common issues in a completely transparent manner. Besides, two prototype applications are developed with the tool.

x Software Requirement Acquisition Software requirements acquisition is an important activity in the software development process. Traditionally, the requirement analyst proactively engages stakeholders in a series of face-to-face activities. However, when software products are designed for the mass around the globe, the traditional requirement acquisition process may not work. Therefore, leveraging participatory sensing is a promising method for software requirements acquisition. Different stakeholders can participate via the web to express their need for a specific software product.

Keywords—Participatory Sensing, End-User Programming.

I.

INTRODUCTION

The popularization of smartphones and their advance in sensing, processing and communication capabilities leads to the Participatory Sensing [1], a new paradigm for sensing data collection and sharing. The key idea behind this concept is to empower non-professional citizens to collect and share sensory data from their surrounding environments using their mobile phones [1]. The emergence of the participatory sensing paradigm has resulted in a broad range of novel participatory sensing applications (PSA). Typical applications include air quality monitoring [3], traffic congestion detection [4], noise and ambiance monitoring [5], price auditing [6], and queuing time notification [7], e.g.

x Urban Infrastructure Monitoring It is very difficult for the limited number of administrators to monitor masses of widely distributed urban infrastructures in the city. Therefore, the administrators can launch a photo taking campaign for better monitoring the infrastructure in the city, while the warmhearted citizens can participate by taking and uploading photos about urban infrastructures. x Spot Reporter A journalist is under deadline pressure to write an article about a polluted river and with its impact on nearby communities. He recruits volunteers with smartphones to send pictures of the water in the river, video interview with the local residents and report on the impact of the polluted water on their daily life.

There are a lot of enthusiastic and warmhearted people in our society, and they want to launch participatory sensing campaigns related to their own concerns. For example, some people who are committed to help the poor may want to initiate a campaign to call out people for recording photos or videos about their life environment. Other people who worry about urban infrastructure (such as manhole covers, street lights and other issues) are desired to initiate photo taking campaigns related to the infrastructure in the city. Participatory sensing mainly has two stakeholders: the campaign initiator and the

978-1-4799-5206-9/14 $31.00 © 2014 IEEE DOI 10.1109/ICGSEW.2014.8

39

Fig. 1. PSAFactory: System Overview

x Crime Investigation Security officials are investigating a bomb attack in a building carried out by terrorists, and would like to find out people who were at the scene of the outbreak when the attack occurred. They request volunteers, who may have taken pictures during the event, to send snapshots of faces in the building.

support PSA as much as possible, the interface would be very complex. However, as this tool is designed for the end-user who lacks programming even information techniques, the interface or functionality of the tool should be as simple as possible. To tackle this challenge, this paper proposes an enduser oriented programming framework in Section 3, which considers the tradeoff between the tool simplicity and functionality.

x Restaurant Recommendation Tourists want to find a nearby restaurant that meets certain requirements. They may ask people who are familiar with this area to give some advices. They can initiate a task by expressing his requirements for the restaurant, and people who are familiar with this area may answer it. Answering questions is just like uploading sensing data.

Second, there are some common issues that have to be considered for PSA at runtime, including the participant identification, sensing data visualization, user experience improving, e.g. The tool should allow end users just do some simple settings, and the tool will run automatically to solve these problems in a completely transparent manner. To tackle this challenge, PSAFactory utilize a set of corresponding runtime supporting components which will be described in detail in Section 4.

Those campaigns need the support of PSA. Besides, PSA are more suitable to be developed by the people who want to launch the campaign. This is because PSA have two important features, one is the strong demand for personalization, and the other is the requirement for short development cycle. However, the development of PSA requires complex programming skill, such as sensor access and sensing data visualization. Therefore, only professionals can build them.

The rest of this paper is organized 6 sections. In section 2, we will give a system overview of the tool; Section 3 and 4 introduce the end-user programming framework and runtime supporting components respectively. Section 5 introduces two prototype applications developed by PSAFactory; Section 6 reviews related works. Finally, we discuss the limitation and directions for future work in Section 7.

The concept of End-User Programming [8] allows endusers of software systems, rather than the professional software developers, to create software artifact. Inspired by this concept, this paper develops a tool, named PSAFactory, for nonprofessionals who do not understand the programming techniques to develop their own PSA in a quick and simple way.

II.

PSAFACTORY: AN OVERVIEW

Figure 1 gives a brief overview of the PSAFactory. Campaign initiators who develop PSA to initiate participatory sensing tasks and responsible for viewing all collected sensing data are referred to as initiator. Campaign participants who take part in a sensing task by collecting and uploading sensing data are referred to as participants in this paper.

While the idea is easy to understand, translating it into a practical system is not straightforward and entails two main challenges. First, to build such a system, a common end-user oriented programming framework has to be abstracted. However, the abstraction is non-trivial. This is because different PSA have different features. If we want to make the tool be able to

The design goal of the tool is to allow the initiator just do some simple settings, while the tool will run automatically to

40

In order to distinguish between these two types of problems and select corresponding participant Identification policy, the initiator should select either "deep understanding” or "timesensitive" .

solve common problems for PSA, which is completely transparent to the initiators and participants. In order to realize this goal, the tool is designed mainly as two parts. One is the end-user programming framework, and the other part is the components repository. The generation of the PSA consists of two steps. First, the initiator uses the programming framework to do some settings. Second, the tool will generate the app according to the settings by configuring and assembling the components in the repository together, including both the user interface and the runtime supporting components.

(4) Sensing Content The framework for PSAFactory supports three types of sensing contents, and they are photos, videos and answers for questions. The initiator has to select one or more of them, and the PSAFactory will generate different user interfaces for participants automatically. The user interface is showed in Fig .2 (c).

Besides, the tool not only provides the initiators with a framework to customize their PSA, but offer the participants a PSA stores. In the PSA store, participants can browse latest PSA that they are interested. Besides, the store can also make some recommendations according to the user profile. III.

Besides, the location data is collected when the sensing data acquisition process is executed. Because in many participatory sensing scenarios, the location tag has to be uploaded with the sensing data. Therefore, the user’s location information, such as Wi-Fi fingerprints, GPS and Cell ID, are obtained from the localization modules in the phone. For energy-saving purpose, GPS data will not be recorded if the profile management component can capture Cell ID and Wi-Fi fingerprints

END-USER PROGRAMMING FRAMEWORK FOR PSA

In order to provide the initiators with a simple framework to develop their own PSA, the participatory sensing task (PST) should be defined at first. The framework is designed according to the PST, which enables the end-users to build their PSA just by doing some simple settings.

(5) Payment Policy In some participatory sensing scenarios, the initiator has to offer payment to encourage more people to participate. Therefore, our framework enables the initiators to declare their incentive mechanism for a participatory sensing campaign. Our framework supports three types of incentive mechanism, and they are “pay-to-all”, “pay-to-best” and “ranking”. “pay-to-all” means that the payment will give to all participants who are confirmed to contribute the sensing data, while the “pay-tobest” means that the payment will only give to the one who contribute the most qualified sensing data. The term “most qualified” is evaluated by the campaign initiator. The third incentive policy (i.e. the “ranking” mechanism) adds a ranking interface for the PSA, through which the participants will see whose contribution ranks higher. The term “higher” is evaluated by the campaign initiator too.

Considering the tradeoff between tool simplicity and functionality, a PST consists of following parts, and the user interface is showed in Fig .2. (1) TTL (Time To Live) A PST has time limitation. For example, a sensing task is for asking the current traffic condition in a certain place. The initiator can assign a TTL for the task. Over this time, the PST is shut down because the sensing data has already become meaningless. (2) Geographic Coverage A PST is related to a specific geographical coverage (GC). In this paper, our framework enables the initiator to assign circular range by giving the center and radius in the map. For the center, the tool provides two options. One is based on a fixed location, and the other is based on a dynamic location, namely binding to a specific mobile phone. For the radius, initiator can either assign it vaguely by moving fingers in the digital map (showed in Fig .2 (c).) or inputting specific distance value in the edit box. (3) Participant Identification Policy After specifying the geographical coverage, the PSAFactory has to identify the most appropriate participants and deliver the PST to them. There are two types of sensing tasks. One is "deep understanding” type, which requires the participant to have a more comprehensive and in-depth understanding for local circumstances, such as when recommending a cost-effective restaurant nearby. The other is "time-sensitive" type, which requires the participants to provide latest information, such as “how many people in the canteen now”.

Fig. 2. The user interface of the PSAFactory for initiator.

IV.

RUNTIME SUPPORTING COMPONENTS

The programming framework described in Section 3 only generate the user interface of a participatory sensing application and set some rules for the application. However,

41

there are many other issues that have to be taken into account when the application is running. Typical issues include the following ones.

see there are a lot of marks on their designated geographical area map. The maker can be zoomed and associated sensory data can be viewed.

(1) How to identify potential participants for a PSA so that the tool can deliver the application to them?

However, when the number of participants is quite large, initiators are often exposed to large amounts of data, thus bringing about the information overload problem. Therefore, it is important to think about how to make the initiator views the data that he is more concerned about or more reliable. Therefore, this paper presents relevant filtering and ranking mechanism to reduce the amount of data on the display screen. First, the initiator can choose to narrow geographic range. Second, the initiator can choose to see the data from high reputation participants.

(2) How to improve participants’ experience when using the app to collect and share data? (3) How to visualize the sensing data, and how to deal with the information overload for the initiator when too much participants share their sensing data? (4) How to manage the profile of participants so as to improve the efficiency of the app?

For some applications, initiator may want to see all the data even if too much participants share their sensing data. For example, a participatory sensing app is to monitor the city's manhole covers by calling out people to take photos with geographical tag. The initiator wants to see all the photos, as each lost manhole cover is likely to be hidden danger for the citizen. Therefore, the tool allows the initiator view all data. In this case, the filtering and ranking process aforementioned will not be executed.

Runtime supporting components tackles those common issues for PSA at runtime respectively, which comprises following four main components. A. Participant Identification Participant identification component will select appropriate users and then deliver the application to them. This process is conducted according to two factors set by the initiator in the development phase. One is the geographical coverage, and the other is the participation identification policy.

D. Participant Profile Management Participant’s profile is very important for participant identification, filtering & ranking for sensing data, user experience improving. The participant profile management component is responsible for managing user’s location records, interested domains and reputation record.

(1) For the "deep understanding” type, the participant identification should be according to the regularity of the potential participants’ historical location for finding persons familiar with this geographical coverage.

The user’s location information, such as Wi-Fi fingerprints, GPS and Cell ID, are obtained from the localization modules in the phone. For energy-saving purpose, GPS data will not be recorded if the profile management component can capture Cell ID and Wi-Fi fingerprints.

(2) For the "time-sensitive" type, the participant identification should be according to potential participants’ current location. B. User Experience Imporving User experience of the participants is very important for participatory sensing. Some people do not want to be disturbed under certain circumstances. Therefore, if the potential participants are forwarded with too many PSA, the frequently bothering might reduce their interest for participatory sensing. Therefore, PSAFactory proposes an anti-disturb mode setting mechanism to improve the user experience.

User’s interested domains are used in the participant identification phase. If the number of potential participants is quite large, the PSA will not be delivered to all of them. The system will select people who are interested in the domains related to the sensing task. The reputation records are meaningful in two aspects. One is to deal with the problem of malicious participants. For example, Tom developed his participatory sensing app, and the sensing task of the app is to ask “Is there restaurants nearby with quiet environment and healthy food?”. In order to attract business, some shopkeepers may participate in the task to recommend their restaurants even if they are very noisy. In this case, the tool uses the reputation history record to recognize the malicious participants and filter their data. The other usage of reputation record is to deal with the information overload issues for participants. The initiator can select to view the data form the people with best reputation history.

In order to deal with this problem, the tool sets the following default rules. (1) Do not disturb users who prefer to participate at the present time of day; (2) Do not disturb users who have recently received recommended PSA as many times as their settings permit. The maximum number of recommended applications and the time period that do not want to be bothered are set by the participants in the PSA store.

V.

C. Sensing Data Visualization The PSA developed by this tool will provide the user with a map-based visualization interface. In this interface, the user can

PROTOTYPE PSA IMPLEMENTATION

In order to prove the effectiveness of the tool PSAFactory, we developed two participatory sensing applications with the

42

answer it. Answering the questions is just like uploading sensing data.

tool. For each application, we will first give its background, and then describe how it was developed.

With PSAFactory, such an app is developed by doing following settings. The TTL is set to be five minutes, because the initiator wants to find the seats within five minutes, otherwise he will go to seek available seats by himself. The geographical coverage is be set for the whole campus. The identification policy is set to be "time-sensitive". The sensing content is set to be “answers for questions”, and payment is set to be five virtual coins.

A. Cover Monitoring Covers are generally provided on a pedestrian or vehicle road, but the "trap" left after the covers were stolen may pose fatal damage to people living in the city. Of course, people who are responsible for the cover management have the responsibility to see if there is a covers lost, and to fill the trap. However, as the number of such managers is limited, such a way is not the best choice. Using of participatory sensing concept, people can develop an application to utilize the collective power of citizens on the roads. When people find a cover that was stolen, he can use this application to take pictures for the missing manhole cover, and with location tags uploaded to the server. City managers can view data and fill the missing manhole covers as soon as possible. The app can even remind the public nearby the trap to pay attention.

The user interface of this app, both the interface for the participants and the one for the initiator, is showed in Fig.4.

With PSAFactory, such an app is developed by just doing some settings. The TTL is not set, because we want the app be running all the time. The geographical coverage should be set for the whole city. The identification policy is set to be "timesensitive". The sensing content is set to be photos, and payment is set to be two virtual coins. The user interface of this app, both the interface for the participants and the one for the initiator, is showed in Fig.3.

Fig. 4. The user interface of availabe seats seeking app. (a) is the interface for the participants to answer questions. (b) is the interface for the initiator to view the answers.

VI.

RELATED WORK

There are some tools for end-user to create participatory sensing campaigns in specific domains. Epicollect [10] allows the creation of campaigns specific to epidemiology and ecology. Similarly, Project Noah [11] is a tool for creating “missions" in which users can contribute images of wildlife. Campaign organizers (i.e. the initiator in this paper) register a mission on the website, and users simply upload their images from any camera via Project Noah's website. While these systems make initiator free from the need for developer skills, they are specific to their respective domains and do not provide general support for participatory sensing.

Fig. 3. The user interface of CoverMonitoring app. (a) is the interface for the participants to share data. (b) is the interface for the initiator to view data.

There are some other participatory sensing campaign creation tools which have been designed for general campaign creation, such as PRISM [12] , Campaignr [13], Medusa [14], Code-in-the-Air (CITA) [15] and the MC Designer. Each of these provides high configurability of campaigns by the end user, removes the user from the technical challenges of accessing phone sensors, and is robust to changes in the campaign. However, they still require some programming knowledge, including knowledge about the format and ordering of a document, correct use of the programming language's syntax, or infrastructure knowledge. In table 1, we have listed

B. Available Seats Seeking Living on campus for us, when the final exam is approaching, looking for an available seat in the library or classroom building is often very difficult. Such a situation often occurs that you hard to run a lot of room and cannot find an available seat. The use of participatory sensing can be a good solution to this problem. We can develop a PSA, initiator will ask which classrooms have available seats, and the students who are in the classroom or library right now will

43

participants. Therefore, in the future we plan to develop tools of Phone and Windows Phone version

the software development skill that is required by each existing tool. VII. LIMITATION AND FUTURE WORK

VIII. ACKNOWLEDGMENT

Inspired by the concept of end-user programming, this paper develops a tool, named PSAFactory, for nonprofessionals who do not understand the programming techniques to develop their own PSA just by doing some simple settings. However, the tool has following two limitations.

This work is funded by the National High Technology Research and Development Program of China (863) under Grant No. 2013AA01A605, the National Basic Research Program of China (973) under Grant No. 2011CB302604 and the National Natural Science Foundation of China under Grant No.61121063.

Tools or Framewor ks PRISM [12]

Medusa [14] Code-inthe-Air (CITA) [15] Campaignr [15] MC Designer [16]

REFERENCES

Development Skills Required [1]

Burke, J. A., Estrin, D., Hansen, M., Parker, A., Ramanathan, N., Reddy, S., & Srivastava, M. B. (2006). Participatory sensing. [2] Kanhere, S. S. (2013). Participatory sensing: Crowdsourcing data from mobile smartphones in urban spaces. In Distributed Computing and Internet Technology (pp. 19-26). Springer Berlin Heidelberg. [3] J. Carrapetta, N. Youdale, A. Chow and V. Sivaraman, “Haze Watch Project”,Online:http://www.pollution.ee.unsw.edu.au. [4] P. Mohan, V. Padmanabhan, R. Ramjee, “Nericell: Rich Monitoring of Road and Traffic Conditions using Mobile Smartphones”, in Proceedings of ACM SenSys, Raleigh, NC, USA, November 2008. R. Rana, C.T. Chou, S. Kanhere, N. Bulusu and W. Hu, “Ear-Phone: An [5] End-to-End Participatory Urban Noise Mapping System”, in Proceedings of ACM/IEEE IPSN, Stockholm, Sweden, April 2010. [6] Y. Dong, S. S. Kanhere, C. T. Chou and N. Bulusu, “Automatic Collection of Fuel Prices from a Network of Mobile Cameras”, in Proceedings of IEEE DCOSS 2008, Santorini, Greece, June 2008. [7] Wang, Y., Wang, J., & Zhang, X. (2013, July). QTime: A Queuing-Time Notification System Based on Participatory Sensing Data. In Proceedings of the 2013 IEEE 37th Annual Computer Software and Applications Conference(pp. 770-777). IEEE Computer Society. [8] Jones, C. (1995). End user programming. Computer, 28(9), 68-70. [9] Zhou, P., Zheng, Y., & Li, M. (2012, June). How long to wait?: predicting bus arrival time with mobile phone based participatory sensing. In Proceedings of the 10th international conference on Mobile systems, applications, and services (pp. 379-392). ACM. [10] D. Aanensen, D. Huntley, E. Feil, B. Spratt, et al. Epicollect: linking smartphones to web applications for epidemiology, ecology and community data collection. PLoS One, 4(9):e6968, 2009. [11] Networked Organisms. Project Noah.http://www.projectnoah.org. [12] T. Das, P. Mohan, V. N. Padmanabhan, R. Ramjee, and A. Sharma. PRISM: platform for remote sensing using smartphones. In Proc. of MobiSys, pages 63-76,2010. [13] A. Joki, J. Burke, and D. Estrin. Campaignr: A framework for participatory data collection on mobile phones. Technical report, UCLA Center for Embedded Net-work Sensing, 2007. [14] M. Ra, B. Liu, T. La Porta, and R. Govindan. Medusa: A programming framework for crowd-sensing applications. In Proc. of MobiSys, pages 337-350, 2012. [15] L. Ravindranath, A. Thiagarajan, H. Balakrishnan, and S. Madden. Code in the air: simplifying sensing and coordination tasks on smartphones. InProc. of Hot-Mobile, 2012. [16] Heggen, Scott, Amul Adagale, and Jamie Payton. "Lowering the Barrier for Crowdsensing Application Development." In Proc. of MobiCASE, 2013.

Using a procedural programming language for collecting sensor data from a large number of mobile phones. Using the MedScript programming language to describe crowd sensing tasks Using complex data processing primitives to process data Using an XML description language to specify data collection tasks and parameters. Components deployment skills.

Table 1 Development Skills Required By Existing Tools First, the tool can only be able to build a part of PSA, whose sensing task is simple enough to match the structure of PST described in Section 3. Other applications that are more complex cannot be produced by PSAFactory, such as applications containing sensing data analysis in the participant’s phone [7] [9]. However, the key idea of the tool is to make the programming as simple as possible, because it targets at non-professional end-user (the initiator) rather than professional software developer. Therefore, we sacrifice functionality for simplicity, which leads to this limitation. Second, energy-saving and privacy preserving have not been well considered in current version’s PSAFactory, which are important for participatory sensing. In the future work, we will introduce corresponding mechanisms into the tool. Third, since the current version of our tool has been implemented only on the Android phone system, it cannot generate PSA in other phone systems and limit the number of

44