DisCoPar: DSL for Adding New Components
The sheer number of sensor-enhanced mobile devices combined with their user’s mobility led to the establishment of participatory sensing. This approach to data collection and interpretation relies on individuals, acting alone or in groups, along with their personal smartphones to systematically monitor personal information (e.g. health) and/or environmental information (e.g. noise levels, traffic conditions). Participatory sensing provides the enabling technology to deploy so-called citizen observatories, i.e., community-based environmental monitoring and information systems which can be used as a policy making and evaluation instrument for improving the quality of life of citizens.
DisCoPar (Distributed Components for Participatory Campaigning), is a platform aimed to enable a flexible composition of citizen observatory features. To do so, DisCoPar is implemented as a component-based system using flow-based programming concepts. The highly reconfigurable and reusable nature of this component-based approach makes it a very suitable method for implementing the wide-range of functionality that a citizen observatory should provide (mobile apps, server logic, etc.). Figure 1 illustrates the concept of the DisCoPar platform: end-users (non ICT-experts) can build mobile apps by assembling various components through a visual drag-and-drop interface. Server-side data processing logic can be implemented through a similar interface. More information can be found online at https://discopar.net/
One particular issue with HTML5 apps is that sensor access is very limited. By switching to a hybrid approach, access to these sensors can be obtained. The goal of this thesis - amongst other - is to create a DSL that enables developers to add new sensing components to DiscoPar. The DSL should make it possible for developers to write glue-code between hardware sensors and the corresponding DisCoPar sensing components. We envision abstractions that enable the addition of new sensors in an easy way. Communication with external sensors through bluetooth should also be supported. Different external sensors might use different protocols. We envision a system of 'pre-processing' components that converts each sensor data into the same format as used by the DisCoPar platform. Additionaly, sensor data types can be tagged with information about the type of data produced. For example, we might indicate that a temperature sensor produces numerical values. The goal is that this information will be used to automatically test what kind of processing components can interact with each type of sensor (e.g. mathematical components can be used on numerical-value producing components, etc.)