1 Introduction

Though Citizen Science is frequently viewed as a modern day phenomenon, it should be noted that for most of history, amateur scientists have been most active. Indeed, the professional scientist is a feature of the modern age [37]. Amateur by definition, the key strength of Citizen Science is the ease and speed by which data can be assembled in a short space of time, a feat that would be impossible for many individual, professional organizations [11]. Nonetheless, while Citizen Science projects have, demonstrably, produced reams of information, it is not universally accepted as a valid method for scientific investigation [5].

The state of present day Citizen Science has been compared to the incubation stage of open-source software where, initially, it was synonymous with Linux yet has evolved to incorporate an enormous range of diverse projects [56]. Information and Communication Technologies (ICTs) are increasingly fundamental to Citizen Science, particularly WWW and mobile computing. However, sensing technologies, fundamental to many areas of modern science, is one area that has not yet been harnessed by the amateur science community to any great degree.

Sensor networks are fundamental in many domains, particularly environmental monitoring. In many cases, deployed sensors cannot harness common connectivity solutions and platforms. This may be due to a lack of infrastructure in the geographic area; alternatively, the practical constraints of an arbitrary deployment (limited power availability, siting considerations, and so forth) may preclude the harnessing of a standard wireless communications technology, based on 3G or telemetry solutions for example. This renders the data collection exercise time-consuming and expensive as the sensor network must be visited in person at regular intervals. Citizen Scientists, acting in collaboration with the professional scientist community, can offer a potential solution by acting as Human Relays, thereby deliberately or opportunistically carrying data to an access network for subsequent uploading. How such a solution may be achieved in practice is the focus of this paper.

1.1 Contribution

This paper advocates interaction between smart-phones and embedded sensors as a practical means of addressing the data collection problem in sparse sensor networks. Such an approach solves a key problem for many professional scientists and aid collaboration with the amateur science communities in meaningful scenarios; it would also aid the take-up of sensor technologies by the citizen science community - something that is lacking at present. Specifically, an augmentation to an existing middleware solution is described in detail and a protocol for this (or an equivalent) solution being made available to the science community for integration into their custom Apps is described.

1.2 Paper structure

Section 2 presents related research in the domain pervasive sensing, data collection in sparse sensor networks and Citizen Science. Issues pertaining to the practical deployment and use of sensors is presented in Section 3. A middleware abstraction for Point-to-Point (P2P) access between conventional mobile phones and embedded sensor artifacts is discussed in Section 4. A case study illustrating how such a middleware would operate in practice is presented in Section 5. Challenges and a research agenda for enabling intelligent sensing is then proposed in Section 6 after which the paper is concluded.

2 Background

Practical sensor configurations are influenced by many factors. Ideally, a sensor network would route data back to a server at an appropriate rate, and support remote monitoring and configuration. In practice this does not always happen for a variety of reasons; thus the operator of the network must visit the physical deployment to collect data and perform routine maintenance. Sparse sensor networks are a case in point; such networks are usually deployed over a large geographic area with a low node density. Indeed, many environmental monitoring networks are of this category. In practice, such networks cannot harness many of the traditional approaches synonymous with sensor networks, in particular routing. For highly dynamic networks, this remains a very active research area; for static networks such as many of those those used in environmental monitoring, a variety of potential solutions have been documented. These solutions generally coalesce around concepts such as mobile sinks, mobile base stations, mobile relays or data mules; though each differs in a number of dimensions, the broad objective of data collection is common to each. These concepts are mature; the interested reader is referred elsewhere for more detailed information [14, 19, 48]. Unmanned Aerial Vehicles (UAVs) [24], robots [4] and trains [9], amongst others, have been harnessed to demonstrate the mobile relay concept. Park and Heidemann [40] have demonstrated that mobile phones can be used to support the data mule function, observing that it can be the only cost effective option for rural and remote sensor network deployments. Other approaches using social networks [60] and user mobility traces [59] have been proposed. It should be noted in passing that the use of a mobile relay presupposes that a Delay Tolerant Networking (DTN) approach harnessing Intermittently Connected Delay-Tolerant Wireless Sensor Networks (ICDT-WSNs) [31], is sufficient for the application domain in question.

Many of the approaches described in the literature continue to be oriented towards simulation rather than real-world deployments [49]. This is the antithesis of what is required; in practice, this emphasis on simulation is a tacit acknowledgment of the difficulties encountered when operating in real-world scenarios. Thus the subsequent discussion in Section 4 and Section 5 is grounded in the real world, governed by its constraints and opportunities. It should be noted that the term data mule is not appropriate in a human context; as such, the term Human Relay, as proposed by Yang et al. [60] will be used going forward.

2.1 Sensing paradigms

From a paradigm perspective, Citizen Science has much in common with crowd sourcing [25] where the collective effort of an arbitrary crowd is harnessed to fulfil a specific task. Participatory sensing [17], sometimes called citizen sensing [15], encapsulates the notion of a citizen as a sensor. Mobile Crowd Sensing (MCS) seeks to take advantage of the pervasiveness of mobile devices to enable efficient data collection for large scale applications [35]. Two categories of mobile sensing may be considered here. Opportunistic sensing [32] involves people, having ceded permission, contributing to the sensing process while not conscious of the particulars of its occurrence. On the other hand, participatory sensing itself envisages the user actively and consciously engaging in the sensing process. Both sensing paradigms have been described extensively in the literature; Citizen Science is considered a potential application domain in each case. A detailed description of each of these sensing paradigms is beyond the scope of this discussion; the interested reader is directed elsewhere for a more detailed treatment [16, 20, 27, 30].

2.2 Physical sensing

A number of sensors, including cameras, acceleration, proximity, and positioning, are now standard smart-phones features. The Sense-it [23] App provides abstracted access to all sensors on Android smart-phones. Though harnessing the sensing capabilities of mobile devices has proved a boon to Citizen Science, the issue of harnessing external sensors embedded within the environment is one that has not as yet received significant attention by the research community. However, platforms that enable the capture of data from sensors and its subsequent publication via WWW or cloud services, for example XivelyFootnote 1, ThingSpeakFootnote 2 and OpenIoT [28], are being increasingly documented in the literature. Indeed, many of these platforms are commercial, frequently providing a free service to data providers but leveraging this data as a basis for commercial add-on services. Weather UndergroundFootnote 3 is a classic example of a commercial entity which follows this model.

Traditionally expensive devices, sensors manufactured to a high degree of precision and sufficiently robust for scientific experimentation remain relatively expensive. In contrast the provision of low-cost sensing devices is increasingly driven by developments in manufacturing processes and a keen awareness of emerging markets such as the Internet of Things (IoTs). As an example, consider weather stations. For many years, the cost of acquisition numbered in thousands of euro; at present, one can be acquired for several hundred euro. National meteorological services possess extensive networks of meteorological monitoring equipment; nonetheless, they usually do not cover a geographical area in equal or sufficient granularity. Citizen Science is seen as offering a feasible and low cost solution. Voluntary weather networks are in operation in many countries, for example the Community Collaborative Rain, Hail, and Snow network (CoCoRaHS) network in the USA [12] and the UCRain project in the UK [36].

2.3 Citizen science

Information and Communication Technologies (ICTs) in Citizen Science may be considered as broadly falling into two categories. The first is the most popular, and concerns the use of internet technologies; the second involves harnessing smart-phone technologies whilst in the field. In the former case, so called Virtual Citizen Science (VCS) harnesses computer mediated interaction to enable the practical realization of a (citizen) science initiative [45]. In practice this means harnessing a variety of WWW technologies. This category encompasses many of the best known citizen-science initiatives. For example, Zooniverse is, in essence, a collection of VCS projects. This grew out of the Galaxy Zoo project [44]; it has collected more than 300 million observations from over 1 million volunteers [47]. Other examples of VCS projects include Moon Zoo [26] and CyberlabFootnote 4 amongst many others. VCS platforms may generally be conceptualized as portals where interested citizens can identify engaging projects and contribute to their progression through task completion.

Mobile devices, particularly of the smart-phone ilk, have radically increased the possibilities for mobile data collection. GeoTools [54] is an exemplar of a mobile data collection App in the geological domain. Within the Citizen Science community, one of the best known mobile data collection systems is Cybertracker; designed for conservation biology data collection, it is frequently used as an education tool [41]. iSpot [43] is a website that allows users to submit observations of animals and plants, thereafter the iSpot community is harnessed to assist in identification. Fundamental to its operation is the use of reputation which is indicative of user expertise. An App is available for engaging with the iSpot WWW site [46].

One barrier to entry for many wishing to launch a Citizen Science project is a lack of expertise in a sub-domain necessary to make the project a success. In essence, as well as being a good scientist, it is necessary to be a good communicator, project manager and, increasingly, ICT specialist. In the latter case, a particular difficulty frequently encountered is a lack of App development expertise. As such, a number of tools have been developed to help streamline this process. For example, the Mobile Campaign Designer [22] is one instance of a tool that enables definition of App behaviour through parameter specification. Source code and the App executable are then automatically generated. PSAFactory [52] is another example of such a tool, though this has a focus on participatory sensing. Sensr [29] is another example of an authoring environment that allows those without technical skills to build mobile data collection systems for citizen science.

3 Sensing in practice

For many environmental-monitoring applications, a sparse sensor network is sufficient. It has been demonstrated through simulation that for sparse networks of low duty cycle, data mules are a feasible approach for many common environmental applications [2]. However, when designing a sensor network configuration in the first instance, choice of communications strategy will have a direct influence on the primary constraint of sensor networks and determinant of operational longevity: power.

Sensing in and of itself does not usually consume much power; it is communication that is the most power intensive process. As sensors are almost invariably powered by batteries, a poor choice of communications strategy can comprise the operational life span of the network. Quite a number of wireless technologies have been developed to enable sensor communication with neighbouring nodes, sink nodes, and fixed network Access Points (APs). Many of these are proprietary and operate in the ISM (Industrial, Scientific and Medical) (433MHz/863MHz). Others such as SCADA (Supervisory Control and Data Acquisition) are widely used in industrial sensing systems. At present, there is an increasing interest in Machine-to-Machine (M2M) technologies as an IoTs enabler; it is probable that some of these will find their way into sensor systems in the near future. At present, three of the most popular open wireless technologies in sensor networks are Zigbee, Bluetooth, and WiFi; a number of key characteristics of these protocols are compared in Table 1.

Table 1 Characteristics of ZigBee, Wi-Fi, and Bluetooth
Full size table

In many cases, multiple communication standards can co-exist in a heterogeneous network, as is illustrated in Fig. 1. Wi-Fi-enabled sensors are able to route data to a Wi-Fi access point; thereafter, a smart phone or laptop can retrieve the data. ZigBee-enabled sensors have more flexibility in their networking structure. A mesh network is often established - each node broadcasts data to its neighbours; a coordinator node is required for each network. Bluetooth-enabled networks demand one master node, which is able to communicate with up to 7 Bluetooth-enabled devices simultaneously.

Fig. 1
figure 1

Sensor networking topology

Full size image

Sensor networks and mobile phones each possess standard communication mechanisms, 3G/4G and ZigBee respectively, overlap between the two only occurs when sensors support Wi-Fi or Bluetooth for the most part. At present, this represents only a small subset of commercial sensor platforms; many commercial sensors would use ZigBee particularly in the Home Area Networking (HAN) domain for example. Integrating ZigBee with mobile devices is something that has been expected since the announcement of ZigBee but has not materialized in the manner expected. Why this is the case can only be speculated; it may well be the case that the business model does not as yet justify it. Zigbee USB dongles are widely available. In the case of the smart-phone, the TazPhone platformFootnote 5 demonstrates supports for ZigBee, Wi-Fi and Bluetooth; however, this is very much the exception. As such, seamlessly integrating phones and external sensors remains a vision more than a reality.

3.1 The state of play

At the time of writing, mobile devices and sensor networks remain disparate islands of technologies with limited scope for interaction. There are two broad exceptions to this. The first concerns scenarios where a sensor network is connected to the Internet and the WWW; the second involves scenarios where sensors are hosted on a mobile device itself - a much more common scenario but more trivial. In the former case, the situation is unsatisfactorily as bidirectional communication is limited, and a communications link is always assumed - a naive assumption in many cases. This problem of universal access to sensors and sensor networks is akin to that described by Zachariah et al. [61] in the case of IoTs. Gateways are predominantly at the application layer, and constitute a conflation of the connection, processing and interface functions; adopting a Separation of Concerns (SoC) design approach would be more sustainable going forward. To this end, the issue of standards should be considered. In the case of Open Geospatial Consortium (OGC)Footnote 6 standards for example, Sensor Web Enablement (SWE) [7] and Sensor Markup Language (SensorML) [6] are of particular relevance through there is an acknowledged need for more lightweight standards in the mobile computing and WSN domains [3]. A general solution to these issues is some way off and the characteristics of such solution are well beyond the scope of this paper. Recalling the objectives (see Section 1.1), the requirements of a solution with the current state-of-the-art can now be articulated.

3.2 A two step approach

Sensor networks comprise a variety of communications standards and protocols as alluded to previously. This hints at one of the more complex issues affecting sensor networks, that of heterogeneity. Platforms can differ in almost any dimension - operating system, sensing modality, power and so forth. Designing for heterogeneity poses many challenges. The preferred approach adopted by many researchers to address this challenge is that of middleware. Middleware solutions have been described extensively in the literature [53], and are seen as enabling a suitable level of abstraction for software developers. Thus encapsulating a suitable middleware solution may be regarded as a prerequisite when seeking to enable interaction with sensors. How this may be achieved in practice is considered in Section 4.

Though middleware provides a necessary abstraction and implementation framework for managing heterogeneity in sensing contexts, this problem recurs when considering how best to implement Apps. A number of platforms are available in the marketplace; Android and iOS being predominant at present. Developing for, and subsequently supporting, multiple native Apps is expensive. Alternative approaches might involve harnessing cross-platform tools for App development of which many exist [13]; however, these usually incur a performance penalty when compared to native applications [57]. One category of tool, Web-to-Native Wrappers are most popular, harnessing standard Web technologies such as HTML5, JavaScript and CSS. One of the best known for delivering cross-platform Apps is that of Cordova Footnote 7 / PhoneGap Footnote 8; indeed Cordova itself may be regarded as a type of middleware and will form the basis of the discussion in Section 5. It should be noted in passing that systems such as App Inventor [58] support a visual Drag and Drop approach to constructing Apps though the resultant App functionality may be limited. Tools such as the OpendataKit [21] offer a more extensive solution encompassing facilities to construct, collect and aggregate data in mobile contexts.

4 Middleware for sensor-phone interaction

Middleware has always been the tool of choice in the mitigation of heterogeneity. Conceptually, middleware seeks to lift the contextually relevant into common abstractions which hide that which is irrelevant to all upper layers. In the mobile sensing domain, heterogeneity is manifest in many dimensions acting as a persistent barrier to ubiquity and sensor-reasoning. Amongst others, sensing devices and networks present stark differences in sensing granularity, messaging formats, reconfiguration operations (and lack thereof), method of connectivity (Bluetooth, Wi-Fi, ZigBee), and lack of connectivity. The remainder of this section provides a discussion of one particular middleware solution, SIXTH, and how its abstract sensing domain representational model supports P2P communication between a smart-phone and an arbitrary sensor platform in the furtherance of data collection.

4.1 Overview of SIXTH

SIXTH Middleware [10] has been developed as an enabling layer for truly ubiquitous sensing. Conscious of the rapidly increasing computational capacity of sensor-rich mobile devices, such as smart-phones, SIXTH was successfully ported onto Android as a background service layer: AndroSIXTH [18].

Originally, SIXTH was designed and implemented as a gateway-side middleware solution in the vein of GSN [1] or WSNWare [50]. Indeed, GSN has also been ported to Android through the MOSDEN project [42], illustrating a trend of reuse of these mature platforms. SIXTH is implemented as a set of decoupled OSGi bundles. OSGi is a modular framework for Java development which was inspirational in the design of the Android Activity life-cycle. Despite this conceptual familiarity, there were many technical challenges resultant from the decision to maintain a consistent underlying framework - Open Service Gateway Initiative (OSGi) and a common core code-base.

The design of SIXTH is explicitly framed in the Design Patterns [51] methodology owing to the well-documented advantages of such “pre-solved” problem solutions. Consequently, one key abstraction for dealing with heterogeneous data sources is the adaptor pattern. Broadly speaking, an adaptor transforms unknown data representations and API functionality into a homogeneous abstracted presentation.

Figure 2 depicts the role and consequent responsibilities of the adaptor within SIXTH. The creation of a new adaptor is scaffolded by the abstract base class which handles integration with other middleware elements such as the data consumers. Additionally this base class creates a virtual domain representation and provides convenience methods for the creation of valid sensor data. A newly implemented adaptor forms a data source connection with the information source for which it is defined, that is, an isolated sensor platform (for example, weather station) in the environment. The translator sub-component transforms heterogeneous observation formats into a standardized SIXTH data format.

Fig. 2
figure 2

SIXTH adaptor model

Full size image

This data format is designed to be permissive, flexible, easily generated, and expanded by power users. The format specifies:

  • Time-stamp: Time of the observation.

  • Sample type: Circumstance of the observation e.g. periodic, requested, escalated etc.

  • Identifiers: Sensor node and network unique identifiers.

  • Modality: An object which signifies the modality being observed and it’s meta-data linked to an external semantic URI. The modality is a complex object, as a modality may have many sub-parts this relationship is represented as a map of key-value pairs.

  • Data values: The observed values, this may be singular or a set of connected readings e.g x, y, z-axis observations.

In contrast with the translator, the wrapper consumes homogeneous SIXTH tasking messages and transforms them into sensor specific messages for dispatch via the connection mechanism. Connection mechanisms are diverse; consider that for some relatively sophisticated sensor platforms, connection is achievable through Bluetooth, ZigBee, Wi-Fi or even external cellular modems. Thus connection fragments are substitutable elements of the SIXTH architecture, utilized as the need arises. Homogeneous nodes, otherwise alike, may be programmed in an incompatible manner which facilitates the need for multiple wrappers and translators to facilitate the different formats. These components are utilized in sequence until the appropriate mechanism is found.

When the translator has performed its function, a brokering mechanism is utilized to disseminate the sensed observations, and domain meta-data, to clients in a loosely-coupled manner. In a sparse network and data mule scenario, in which sensors are physically isolated, these observations will be stored on the phone until such time as it observes that it has regained sufficient connectivity. At this juncture the data can be routed to a persistent store in the Cloud and made available via the OGC Sensor Observation Service (SOS) or equivalent.

4.2 Towards phone-sensor communication

Building upon the work outlined in [39], the SIXTH Middleware was internally restructured into sets of core domain abstractions, compositional elements, and higher-level constructs. The core abstractions represent either an entity abstracted from the problem domain, for example, a sensor; alternatively they could represent a solution for communicating with or reasoning about a sensor network in an abstract and extensible manner. The compositional components of the architecture form the basis of other components; core components such as sensors may be viewed as, or possess, several compositional elements. Compositional types includes: content providers, communication brokers, immutable descriptors, query-driven object aggregates, and the concept of taskability, wherein an object so marked can have its behaviour modified. By means of example Class X implements IBroker <R,U> denotes a class which implements a Broker for objects of type R (such as a Sensor), for which U is a corresponding descriptor (a SensorDescription object). The higher level components are closely related to the core abstractions as they encapsulate lower-level resources and build upon common abstractions. For example a SIXTH deployment encompasses many sensor network adaptors, therefore it is an aggregate, and the brokering mechanisms of the discovery service deliver information regarding, and from, sensors and sensor nodes.

Additionally the core of SIXTH was extended to encompass a RESTful SIXTH Interaction layer. Currently, SIXTH implements P2P interaction, tasking and data sharing between SIXTH deployments using REST. This functionality is underpinned by the RESTlet platform [34] which enables the creation of custom web APIs from Java code. A set of URIs are defined for both the client and server, though a SIXTH deployment can be both. As this means of interaction is decoupled from the underlying programming languages it can be utilized for interaction systems based in any other programming language or for user-driven interaction through a web-dashboard. Other advancements include the development of an OSGi desktop WSN control and display console which displays data from web-resources and local sensors.

5 Case study: P2P interaction with embedded sensors

To illustrate proof of concept, a software service for mobile devices was constructed that enables seamless interaction between a popular mobile device (Google Nexus) and a commercial mass-produced sensor platform (Waspmote).

The Libelium WaspmoteFootnote 9 features low-power consumption and supports a large array of sensor types, 15 radio technologies, including Bluetooth 4.0 and Wi-Fi, Over- The-Air (OTA) programming, encryption libraries, along with industrial protocols, such as RS-232. The platform can be ruggedized to enable its operation in outdoor environments and in varying weather conditions. Solar panels are used for maintaining the battery in a charged state. The Waspmote is an archetypical sensor platform; other commercially available platforms include the SunSpotFootnote 10 and the Shimmer moteFootnote 11. While each has its advantages, the Waspmote supports a greater range of sensing and communication configurations. However, only certain configurations of sensors, radio technologies and so forth can be used in conjunction within a single platform.

Rather than develop a dedicated Waspmote App, the required functionality was embedded within an Apache Cordova plug-in. The advantage of this approach is that the core functionality, namely configuring SIXTH, establishing communications, querying the platform and downloading data, can be easily incorporated within other applications. The plug-in is a wrapper for this core functionality; it can be communicated with using JSON messages, which is the de-facto standard for data interchange and M2M communication on the Web.

Apache Cordova harnesses standard WWW technologies such as HTML, CSS, and JavaScript. It also can be used in conjunction with jQuery MobileFootnote 12 or Dojo Mobile Footnote 13 in the creation of mobile applications that do not require the implementation of native platform specific code. In this way, a Cordova-enabled application developed for an iPhone could also be used on an Android device. This has the advantage of portability, removing the need to support multiple platforms. A critical limitation of Cordova is that if functionality is not directly provided by HTML, JavaScript, CSS, or a pre-existing plug-in, a new plug-in must be developed in a platform-specific language. This circumvents the idea of writing code once for all environments; on the upside, it prevents the lowest common denominator problem to the one size fits all approach to software development.

In this instance, the Waspmote plug-in was explicitly developed for the Android platform, allowing it to harnesses both AndroSIXTH and the standard Android Bluetooth API. Bluetooth 4.0, also known as Bluetooth Low Energy (BLE), was used, as the Waspmote supports this low-power communications method, which additionally lowers the strain placed on the mobile device. Waspmotes offer a pair of predetermined BLE services, each denoted by a Universally Unique IDentifier (UUID). The Waspmote is configured to publish sensor readings as service characteristics, which are also denoted by predetermined UUIDs.

A Cordova plug-in maps a JavaScript interface to a Java interface. The Java interface itself expects a string representation of the action to be performed and a JSON array of arguments. Once invoked, the plug-in, within the native Java components, connects to and configures SIXTH. The SIXTH configuration step consists of a number of actions, including ensuring that SIXTH has started, loading and configuring the appropriate Adaptor, which in this case is a Waspmote BLE Adaptor, and querying SIXTH for the associated sensor data. Within the Adaptor itself, it will use the BLE API to scan for devices, establish BLE connections to these devices and then ascertain whether they provide the expected service representing the Waspmote, as well as accessing the sensor readings on properly recognized devices. Once these readings have been obtained and returned to the plug-in, it can disable and unload the SIXTH Adaptor, which will terminate BLE communications. Additionally it can shut down SIXTH if it is not further required. The sensor results themselves are then passed back to the JavaScript closure as a JSON array.

A plug-in that uses Wi-Fi was also developed; however, this proved more complex, requiring far more configuration of the phone to establish a connection. The Waspmote cannot act as a Wi-Fi Access Point. As such the mobile phone would be need to be configured to act as an Access Point. Android does not provide a standard API for configuring the Wi-Fi subsystem, and while it is possible to configure a device programmatically in this manner, it is not guaranteed to work on all devices. Furthermore, if multiple mobile phones were within range of the Waspmote, it becomes increasingly complex orchestrating the Waspmote to connect to multiple access points. Additionally the Waspmote requires the IP address of the mobile phone in order to connect and upload data, which is another detail that will depend on manufacturer specific configurations of the mobile phone.

6 Future directions

Having described a methodology for, and one implementation of, P2P interaction between a smart phone and external sensor platform, the question of scalability and realization of a truly generic approach for ubiquitous sensing arises. An intelligent middleware solution can obviously enable far more sophisticated services than just data collection, fundamental though this activity is. Three issues are now considered going forward: realizing intelligent middleware services, the need for standards, and the Citizen Observatory - an innovative approach to Citizen Science.

6.1 Harnessing intelligent middleware

As the projected scale of sensor-driven applications comes to fruition, it is evident that the administration of management policies is no longer achievable by a human controller. Such management must be administered through intelligent context-aware software frameworks, which are underpinned by a layering of lower-level context enablers such as SIXTH and constituent sensor devices. Properly informed, such frameworks can inject behaviour into the network in furtherance of longevity, shift granularity to reflect current needs, infer additional knowledge from raw observations, actuate behaviour in the environment, and raise unmanageable concerns to the stakeholders. The need for intelligence manifests in high-yield data collection scenarios wherein it is prudent to filter, omit, aggregate, augment, or otherwise transform the observations to mitigate data overload concerns in relation to storage, transmission, and presentation. In the context of SIXTH, prior work [33] has integrated the middleware with the ASTRA intelligent agent framework through a homogeneous framework-agnostic environment bridge.

Seamless interaction with sensors, sensor networks and mobile devices, enabled by intelligent middleware, ensures the following can be accomplished more effectively.

  • Task Management: A coordinated and efficient approach to task assignment and execution by citizen scientists is possible. This enables the optimization of both human and computational resources. For example, in participatory sensing, the decision to direct volunteers towards certain sensors to collect data or complete some other necessary task will be informed by the information currently available to the system and the varying demands of the project over time.

  • Retasking: Once a sensor network has been tasked (that is, programmed) and deployed, it can very difficult to retask, particularly in sparse sensor networks. Retasking is required for bug fixing and adjusting sensing parameters, such as the node duty cycle. In this type of scenario, the data or logic will need to be delivered via Human Relays enabling delay tolerant Over-The-Air (OTA) retasking and agent migration.

  • Operations & Maintenance: Practical maintenance of sensor networks that are deployed over extended geographic areas is time consuming and difficult. A sensor may be malfunctioning for an extended period of time before the situation is detected. In certain cases, the sensor may just need a new battery; in others, a hardware/software reset may be sufficient. Equipping a Citizen Scientist with a debugging tool would help the situation be rectified in most circumstances.

  • Gamification One of the difficulties in Citizen Science projects is to maintain the enthusiasm and engagement of volunteers. One approach to increase participation is to offer incentives or rewards, possibly financial, for taking part. The problem with this approach, however, is that individual users or groups of users may begin to game the system to increase their rewards. In such cases, adopting agent-based mechanism design techniques to avoid potential negative impacts of gamification is necessary. There is significant scope, in this area, to harness intelligent techniques to create strategy proof incentivization, aligned with the needs of the project in question.

6.2 Standardization

From a software perspective, issues pertaining to standards, semantics and ontologies are of fundamental importance and represent a barrier to ubiquitous sensing. Only through solving such issues can seamless and transparent interaction take place, enabling interoperability, scalability and the production of open, quality-assured datasets. This later issue is of crucial importance, particularly in the environmental monitoring sphere. As such, it continues to be the subject of international standardisation efforts.

There are a range of standards available for environmental data and these standards can be harnessed to allow interoperability between system components and facilitate data sharing. One of the most mature standards for modelling sensors is that of SensorML, developed by the OGC. SensorML, when used in conjunction with a Sensor Observation Service (SOS), provides a uniform methodology for accessing observations and meta-data [38]. Additionally, Sensor Web Enablement (SWE) makes sensors discoverable, and accessible via the Web, and the Geography Markup Language [8] supports an open exchange format for geographical features.

6.3 The citizen observatory

Many volunteer projects are compromised by a lack of resources; Citizen Science is no different. One of the implications is that sub-optimal tools are frequently harnessed. Such tools are often free, but come with various limitations including insufficient functionality, poor usability and minimal documentation. Thus, technologies with the least complexity and lowest cost are the only sustainable choice [55]. Citizen Observatories were conceived to at least partially mitigate this issue and lower the barrier of entry for communities interested in harnessing Citizen Science.

Citizen Observatories may be loosely defined as ICT infrastructures that facilitate and encourage citizen science. In particular, it is envisaged that devices owned and operated by local communities, Non-Governmental Organizations (NGOs), and individual citizens will be harnessed. For the most part, these will be of the smart-phone ilk. However, it can be envisaged that social media, IoTs technologies and various sensors, including legacy platforms, may also be availed of.

At the time of writing, the Citizen Observatory remains a hypothetical construct for the most part; the hypotheses governing their conception remains to be proven. In an effort to verify the potential of Citizen Observatories, the EU, under the FP7 initiative, has sponsored five projects within this domain. An overview of these is provided in Table 2. Furthermore, one of the objectives of the ongoing Horizon 2020 programme is to validate the construct through the promotion of community and industry engagement. Specifically, the issues of research, policy, and societal perspectives are perceived as fundamental. It is this explicit objective of enabling communities to take ownership of their environment, and influence governmental policy through the provision of transparent quality-assured data-sets that distinguishes the Citizen Observatory concept from that of Citizen Science portals.

Table 2 Examples of citizen observatory projects
Full size table

7 Conclusion

Collaborating with local Citizen Scientists offers the professional scientific and research community opportunities to increase the relevance, impact and sustainability of their research. Likewise, many benefits of such collaborations accrue for Citizen Scientists in terms of education and environment stewardship. This paper has proposed such a collaborative approach to the issue of data collection in sparse, intermittently-connected, delay tolerant, WSNs. Augmented middleware offers a basic for counteracting the heterogeneity problem; harnessing the Apache Cordova Framework ensures the approach can be leveraged by a wider user base. The continuing decrease in the cost of sensing devices suggests that sensing technologies will be increasingly adopted in amateur science initiatives going forward. Technologies such as those described in this paper will also play a role in enabling Citizen Science communities harness the power of smart devices to interact with their own community-owned sensor infrastructures.