# Mobile Autonomous Sensing Unit (MASU): A Framework That Supports Distributed Pervasive Data Sensing
## 3 The MASU Framework
### Data Retrieval Mechanism
#### 3.6.2 Data Source Manager  
The Data Source Manager (DSM) is in charge of specifying the sensors that the unit will use to collect the input data. The DSM enables the units to capture diverse types of data from different sensors so that the MASU units can sense different kinds of information and share it with others.  
The MASU framework supports diverse sensors or data sources, such as IoT devices, information repositories, sensors in smart buildings and sensors embedded in commercial smartphones. These sources must be able to provide information that is relevant for the applications and users (in our case, information that is relevant for pervasive monitoring and awareness). Moreover, as stated in [25], any modern mobile ubiquitous system must provide context-awareness and therefore information about the environment that is providing services to the users (in our case, the MASU unit). For this reason, the proposed framework supports a wide range of data sources that are necessary to provide context-awareness about the MASU units (what we previously called hardware monitoring) as well as useful information for pervasive monitoring in learning scenarios. Next, we specify the different categories of data sources that are supported:  
* _Physical sensors_: We can differentiate between three kinds of physical sensors: hardware sensors (e.g., accelerometer, GPS or compass), communication sensors (correspond to built-in communication interfaces like Bluetooth, infrared or Wi-Fi), and performance sensors (that determine battery level, or CPU/memory utilization).
* _Virtual sensors_: In this group we consider information that can be obtained from the device's applications and services; e.g., the screen status, the user's touch inputs, applications status, log files and notifications.  
Figure 6: Example of data sharing between units.  
* _Human-based sensors_: We include in this category any custom application used to collect information that require explicit user intervention. These types of sensors require the participation of a human user to provide information and create new knowledge [29]. Human-based sensors complement the implicit sensing process performed automatically by unobtrusive sensors. This way we can obtain both objective (e.g., a picture, a quantitative datum, etc.) and subjective (e.g., perception, opinion, etc.) information from the user.
* _Context sensors_: These are modules that collect information related to the user context [25] from existing repositories; for instance, the user's profile, preferences, schedule or performance indicators.
* _Logical sensors_: These sensors provide high-level information and they can combine data from a number of sources. Information from this category usually involves some type of aggregation and processing to interpret the sensed data and contextual information. An example of logical sensors could be a service that interprets raw data from an accelerometer to infer the type of physical activity that the user is performing (e.g., sitting, walking, running, etc.).  
In the MASU framework there can be units that act as producers and consumers of the different types of data that these categories of sensors provide. MASU units that use an indirect method to collect input data from any of these sensors will act as Consumers, whereas units that use a direct method will fulfil a particular Producer role. In this later case, the MASU units that sense data using physical, virtual, human-based or context sensors can have a collector or processor role, depending on whether this data require some level of interpretation (e.g., classification, aggregation, processing, etc.) or not. On the other hand, those units that retrieve data from logical sensors to perform further interpretation tasks always play a Processor role.