MOBILE ARCHITECTURE FOR DYNAMIC GENERATION AND SCALABLE DISTRIBUTION OF SENSOR-BASED APPLICATIONS

Transcription

1 MOBILE ARCHITECTURE FOR DYNAMIC GENERATION AND SCALABLE DISTRIBUTION OF SENSOR-BASED APPLICATIONS Marco Picone, Marco Muro, Vincenzo Micelli, Michele Amoretti, Francesco Zanichelli Distributed Systems Group ( RimLab ( Università degli Studi di Parma, Parma, Italy Mobilware June 22-24, London, UK

2 OUTLINE Introduction Proposed Architecture - Mobile Platform - Service Platform QoS and QoI Management Analyzed Scenarios Prototype Conclusion & Future Work

3 INTRODUCTION The widespread and ubiquitous nature of mobile devices makes them attractive as providers of information collected from their rich equipment of sensors (camera, microphone, accelerometers, compass, GPS), and also from external sensors (placed on persons, or in the environment). We envision large-scale sensor networks that use mobile devices as raw data sources, but also aggregated information producers - merging raw data coming from sensors distributed in the environment. With the growing of the mobile application market, new solutions for software distribution have been recently introduced, with the dominance of online application stores (such as AppStore and Android Market). These virtual marketplaces have solved many problems to developers and common users. If on one hand this approach allows for widespread distribution of applications, on the other hand it appears to quite unsuitable for highly dynamic scenarios where application needs may change very frequently within a week or even the same day, according to user credentials, location or purposes.

4 PROPOSED ARCHITECTURE Mobile Device-Centric Approach for sensor-based distributed application Mobile devices allows to : Collect a huge amount of data from local and external inputs/sensors. Mobile Engine Share collected data within the network through a cloud service. Dynamically compose the user interface according to the service nature and user profile. Simplify the application update managing new services entirely remotely though the mobile engine. User Interface Generator Sensor Communication Layer

5 PROPOSED ARCHITECTURE Mobile device-centric approach has a number of advantages over the centralized approach for sensor data collecting: Energy efficiency: In a mobile user scenario sensors will be storing data locally and provide it at request to mobile collectors. The data can be sent directly when the appropriate connection is available or in a second moment according to user preferences reducing environment sensors battery. Improved availability of sensor networks: it allows to access remote and disconnected parts. In this way some parts of the network could be just partially connected and central data collection could be in any way possible. Ubiquity. Users can query the network and collect data from any location in sensor network. User interaction may contribute to enhance the quality and effectiveness of the application enriching collected data before they are shared within the network.

6 Push Notification Cloud Knowledge Mobile UI Specifications Definition DB Engine Web Data Exchange Server Mobile Devices Communication Layer External Modules Communication Layer EM1 EM2 EM3

7 PROPOSED ARCHITECTURE Mobile Device (MD): Is the principal entity of the system, interacting with external sensors to collect data, exchanging them with the cloud and allowing user to enter extra information. The Cloud: Provides personalized environments with services for storing information generated by MDs, as well as mobile Web user interfaces to view collected and analyzed data. MD Communication Layer: Allows the communication between the Cloud and the MD in terms of login procedure, data exchange, UI specification transmission and notification pushing to the device. EM Communication Layer: Allows the communication between the Cloud and EMs to transmit and receive data.

8 MOBILE PLATFORM On the mobile side there is the necessity to communicate with different types of external sensors and to generate a rich user interface to collect user input. For this reasons there is the need to develop the mobile engine using native programming languages - such as Java, C++ or Objective-C - in order to provide the capabilities to: - generate all user interface from a standardized UI Specification Language. - discover and exchange data with internal and external sensors. This approach reduce the complexity of the mobile platform dissemination and update process for the UI. (App should be downloaded once) Designed elements are: Mobile Engine, Sensor Communication Layer, Service Communication Layer.

9 User Interface Read User Inputs Generate Mobile Engine Read Sensor s Info & Data Send Data Read & Parse WSDL File Sensor Communication Layer WS Communication

10 SERVICE PLATFORM Semantic Service Engine: The core of the service platform, managing all available modules in order to provide different types of services to final users. Database Communication Layer: A middleware for storing and retrieving data and information from system databases. Service Ontology: A Web 3.0 knowledge base encompassing all the characteristics of each service, user, sensor and inputs. Client Communication Layer: A middleware that enables mobile devices to connect transmit and receive data. Security Layer: A middleware that provides protocols for securing the communication between service platform and mobile clients. Web Interface Builder: A component that builds dynamic Web pages forshowing real-time or cached data in personalized fashion, according to user needs, profile and credentials.

11 Web Interface Provide WS Engine Security Layer Read & Store Data Read Send and Receive Data Database Communication Service Knowledge (WSDL) Client Communication

12 UI DEFINITION Service: Defines a specific functionality with different UI sections and a list of required sensors with the following parameters. (Name, Storing Type, Storing Location). - UI-Section: Defines a single section of service s UI allowing the designer to divide data entry in different slices, that may be either mandatory or not, and may contain labels and figures to show useful information, or input fields. (Name, Description, Mandatory) Input: Represent a generic input for the data entry. (Name, Type, Mandatory) Label: Represent a text label with an associated image. (Name, Text, Image) Sensor List: Contains the list of sensors required by the service - Sensor: Type, Mandatory, Working Frequency, Reading Limit Type (TIME, SAMPLE), Reading Limit Value

13

14 QOS & QOI MANAGEMENT In terms of QoS each service may specify a minimum guaranteed quality of service, defined in terms of transmission rate, packets error, computational power, connection type, etc. During the connection establishment phase, the server could ask to the client to check if it is able to send data with the requested QoS. This kind of test could be also repeated periodically during the data delivery phase, to identify possible lowering of performance and QoS. Another important aspect we took into account is the quality of information (QoI), that refers to the ability to figure out if available information coming from sensors is fit-for-use for a particular service. - QoI management provides mechanisms for investigating new task admission and resource utilization, for controlling the individual QoI pro- vided to new and existing tasks. The QoI can be characterized by a set of quality attributes, such as accuracy, latency, and spatio-temporal relevancy.

15 WORKFLOW - DATA EXCHANGE Mobile Sensor Management Authentication QoS/QoI Management Service Discovery Web Service User Interface Generation Data Exchange

16 MOBILE SENSOR MANAGEMENT Local sensors/inputs discovery (GPS, Accelerometers,Compass, etc..) Additional sensors discovery: The user searchs for available external inputs like remote camera, environment sensors, barcode reader, etc... connected through Bluetooth, WiFi, USB cable, etc... Additional sensors pairing: The user selects which external discovered sensor wants to use in his workflow. (This operation can be repeated several time to add or remove external sensors)

17 SERVICE DISCOVERY 1 WS Service List Request + User Info (Location) 2 3 WSDL file with available services and related requirements Check user s information and location (if necessary) and select from the list of available service those are compatible with user s profile. ( For example a particular service can be only available for client connect from a certain geographic region or for a user that has specific credentials).

18 USER INTERFACE GENERATION Mobile Engine reads UI specifications and: - Shows the list of available services. - User selects the desired service and the engine: Shows an interface to select the right sensors for the service. If there are more than one sensor of the same type the user can select witch of them must be used. If one or more mandatory sensors are not yet available the engine shows an error message and avoid next interaction. Generates Graphic User Interface for the user s manual input.

19 DATA EXCHANGE 1 2 WS Starts sending data to the server according to the frequency of user inputs and sensor behaviors. 5 Check server response to show errors or connection status. Send Data (JSON Format) 4 Server Response (JSON Format) QoS/QoI Procedure 3 Read received information and store them in the appropriate databases according to the right service and data type. Randomly and according to the type of selected service the server can send a request to check the connection status of the client in order to keep the requested QoS/ QoI.

20 WORKFLOW - DATA VISUALIZATION Data Visualization is provided through a Web Interface using specific CSS sheet in order to be customized for each mobile platform and traditional PCs. WS Also for data visualization there will be an authentication layer to show the right content only to users with the right credentials.

21 SCENARIOS Car Tracking - Geo Localization - Engine monitoring - Brake status - Street status Environment Monitoring - Weather - Chemical - Biological - Radiological - Populations e-health - Non-invasive parameters diagnostics - Patient s data entry - Fall detection - Patient Behaviors monitoring - Body sensors interaction Industrial - Production line monitoring - Machine status - Workers feedbacks

22 production line feedbacks from workers sensor sensor wine bottlers sensor new sensor Mobile Engine water bottlers dynamic data External Modules sensor discovery & pair synchronization when can retrieve and analyze peers connection is available data

23 feedbacks from the patient AFO Mobile Engine discovery & pair external sensors dynamic data synchronization when connection is available External Actors and Modules can retrieve and analyze data

24 IOS-PROTOTYPE

25 IOS-PROTOTYPE

26 CONCLUSION & FUTURE WORK In this paper we have illustrated a novel architecture for agile development and deployment of mobile, sensor-based applications. The distinctive features are: - The mobile device-centric approach - Mobile Engine that allows to : Dynamically generate User Interface according to service provider specification. Interact with available sensors (internal/external). Simplify the application update and dissemination. As future work, we are going to : - Complete the development of the Service Platform. - Improving the semantic service engine develop versions of the Mobile Engine for the Android platform. - Build the first ehealth full prototype.

27 Q&A?