Purpose & Scope

Marco Poli is a system composed by a network of sensors placed around Politecnico which send information about temperature, noise, congestion, humidity and light to a server. These informations are elaborated and a thematic map is created where critical zones and events are marked.

The students can decide to log-in or not. If the student doesn’t log-in, he can just watch the map with the critical zones on it, together with some other (limited) services. Otherwise, by logging in, he can setup favourite parameters such as zones inside Politecnico, temperature, noise, congestion level, humidity and light level. A list of possible destinations is generated and shown to the user according to the configuration chosen.

The system is not a “navigation” system because doesn’t tell the user how to reach a zone inside Politecnico. A selected user (administration, owner of a bar, etc.) can add a place of interest visible to all the other students that are using the app in another thematic map.

AmI

AmI main steps

The sensing part consists in fetching informations such as temperature, noise, humidity and light level from some places around Politecnico as well as data about the concentration of people in those places.

As for the reasoning part, the system elaborates the gathered informations which are used to build a thematic map which represents the situation inside Politecnico.

In the acting part, the system notifies the user of unusual situations as well as suggests him/her possible points of interest.

Finally, for the interacting part, the user decides his preferences and receives multiple feedbacks from the application.

AmI features

  • Sensitive: It gathers informations about temperature, humidity, noise, congestion and light level from sensors around politecnico. The schedule of the user is exploited to have aimed suggestions.
  • Responsive: it continuously monitors the building in order to react quickly to a situation change such as the end of a lecture or an unexpected crowding.
  • Adaptive: the system observes past data and evolves accordingly.
  • Transparent: the user intuitively exploits the application without being aware of the system behind it.
  • Ubiquitous: any student can benefit from the system by downloading the application
  • Intelligent: the system builds a thematic map of Politecnico and suggests custom destinations.
Definitions

Glossary

  • Ambient Parameter: the various quantities we use to rank destinations, i.e.:
    • temperature
    • noise
    • humidity
    • congestion
    • light level
  • User Comment: review of a destination made by a user.
  • Configuration: set of parameters chosen by registered users which modifies the behavior of the webapp.
  • Congestion Scale: a measure of people density close to a specific area.
  • (Favorite) Destination: a possible result of the query issued by the user on the webapp. Favorite destinations can be chosen by the user so that they can be kept as results. Possible destinations include:
    • classroom
    • library
    • study room
    • bar
    • wc
    • corridor
    • courtyard
  • Event : a happening defined by third parties.
  • (Advanced) Filter: set of requirement defined by users employed when choosing which destinations are to be shown. Advanced filters which supply more options are available to registered users.
  • Interface: graphic side of the application, implemented by the website. Includes the maps, the list and the user panel.
  • Login: procedure by which the server can identify users and provide them with advanced features.
  • Map: chart of Politecnico, comes in different flavours depending on the information shown, such as
    • Empty map: simple map which shows the plant of Politecnico together with the name of the rooms.
    • Congestion map: shown on the website, displays the map together with the concentration of people in the area.
    • Temperature map: shows the temperature measured by the station in correspondence of its position.
    • Noise map: shows the temperature measured by the station in correspondence of its position.
    • Wifi map: shows the number of people connected to the WiFi hotspots.
    • Event map: shows the events inserted by third parties.
  • Notification: sent by the server to the users, it can warn of critical situations as well as notify of newly created events.
  • Places: areas in the map, divided into:
    • Places of interest: areas in which an event should be held.
    • Critical zones: areas in which the concentration of people is high.
  • Pop-up: window which opens on the map when the user taps/clicks on it, it shows information about the chosen point.
  • Rank: classification of destinations. The classification is divided in:
    • User ranking: when it is based on user reviews of the destination.
    • Server ranking: when it is based only on information gathered using the stations.
  • System: the overall set of parts which constitute Marco Poli. It is divided in:
    • Web app: user side, this part shows the results of the searches and the maps.
    • Server: computational part, gathers data from the station network and builds the maps and the list of destinations which are shown on the web app.
    • Station (network): sensing part, contains the sensors which gather the data needed by the system.
  • (User) Schedule: timetable of the lessons of the user, which can be set by the user himself/herself and is used by the server to filter out results in the destination list.
  • User Preference: requirement set by the user which is employed together with others to filter and provide him/her a customized answer.

Actors

  • Users looking for a room
  • Users trying to avoid congested areas
  • Users looking for an event
  • Third party entities (selected by the admins) defining events
System Req.

System Requirements

Functional Requirements

Functional Area

1

2

3

4

Description

User Interaction

Server Operations

Station Operations

Application Layout

  • VENICE VERSION (PRIORITY 1)
    • FR 1.1: The user can access some system services (such as viewing the map) without being logged in.
    • FR 1.2: The user (not yet registered in the system) is able to see the congestion map as well as the list of places of interest.
    • FR 1.3: A destination list is available to all users.
  • ACRE VERSION (PRIORITY 2)
    • FR 1.4: The user can view maps which contain data about temperature, noise, wifi, events.
    • FR 1.5: The user logs in the system using the web app’s dedicated page by authenticating himself.
    • FR 1.6: The user can define a basic configuration (types of destination to be shown in the list, maps to be shown…).
    • FR 1.7: Events can be added. They can be created by us or by authorized third party entities through a login page in the website.
    • FR 1.8: Events require date, start/end hours, name, location and a description. The informations can be added in the website page.
  • TREBIZOND VERSION (PRIORITY 3)
    • FR 1.9: Choice of advanced filter. From the settings page, the user can choose the ambient parameters he is more interested in.
    • FR 1.10: The user can insert his own schedule including the classrooms he will use. He will be able to change it whenever he needs to.
  • BAGDAD VERSION (PRIORITY 4)
    • FR 1.11: The user can configure the notifications: activation/deactivation in some time frames, choice of which type of notification he wants to receive.
    • FR 1.12: The user can specify a list of favorite destination.
  • TERBIL VERSION (PRIORITY 5)
    • FR 1.13: Users can rank destinations.
  • VENICE VERSION (PRIORITY 1)
    • FR 2.1: The destination list is filtered by location type (e.g. study room, bar, laib etc.)
    • FR 2.2: The server initializes the stations.
    • FR 2.3: The server uses the informations to build the map shown on the web app.
  • ACRE VERSION (PRIORITY 2)
    • FR 2.4: The server manages the preferences of the users.
  • TREBIZOND VERSION (PRIORITY 3)
    • FR 2.5: The server can suggest places of interest depending on the time of the day (lunch, dinner, afternoon).
    • FR 2.6: The server can suggest places of interest close to the user by exploiting data taken from his/her class schedule.
    • FR 2.7: The server uses the data gathered by stations placed around Politecnico in order to rank possible destinations.
  • BAGDAD VERSION (PRIORITY 4)
    • FR 2.8: The server sends generic notifications to the users.
    • FR 29: The server sends notifications to the users in case the ambient parameters change.
  • TERBIL VERSION (PRIORITY 5)
    • FR 2.10: The server ranks destinations according to both stations data and rankings given by the users.
  • VENICE VERSION (PRIORITY 1)
    • FR 3.1: The sensors inside the various stations placed inside/outside Politecnico register parameter data (noise, temperature, wifi…).
    • FR 3.2: The stations partially elaborate the gathered data.
    • FR 3.3: The stations automatically connect through the Politecnico network to the server, with which they exchange informations.
  • VENICE VERSION (PRIORITY 1)
    • FR 4.1: The user can view the empty map (which only contains the rooms) and the default destination list.
    • FR 4.2: It is possible to choose which floor to show.
    • FR 4.3: The layout changes depending on the size of the screen (picture).
    • FR 4.4: The application can be used starting from a resolution of …
  • ACRE VERSION (PRIORITY 2)
    • FR 4.5: It is possible to modify/delete the events present in the website private page.
    • FR 4.6: By tapping a destination on the map, a pop-up appears showing the ambient parameters.
    • FR 4.7: Tapping on a destination (e.g. a classroom) will open a pop up which shows information about the destination itself.
  • TREBIZOND VERSION (PRIORITY 3)
    • FR 4.7: In the user settings there is a page where it is possible to insert the user schedule.
  • TERBIL VERSION (PRIORITY 5)
    • FR 4.8: Tapping on a destination opens a pop up which shows the user comments.

Non-Functional Requirements

  • NFR 1: System readiness (performance)
    • The backend system must always be on and able to notify the users of unusual situations
  • NFR 2: Portability
    • The application must run on any kind of device which can run a web browser (Chrome v.43, Firefox v.38, Safari v.8).
  • NFR 3: Language localization
    • The application will be localized in English and Italian
  • NFR 4: Web application responsiveness
    • The web interfaces will adapt to the platform used to access them and to different resolutions
Architecture

Deliverable 3 -  Architecture

1)  System Architecture

Marco Poli's Architecture

1.1 Hardware Architecture

  • Station: a single-board computer connected to sensors and to the web
    • Noise sensor: a microphone connected via USB to a single-board computer
    • Temperature sensor
    • Movement sensor
    • Humidity sensor
    • Light sensor
  • Server: a computer connected to the web via LAN or WIFI
  • User’s smartphone: running the app on the web browser
  • User’s computer: running the app on the web browser

1.2 Software Architecture

Web site: used by the user to interact with the maps and the lists

  • Functions: allow the user to log into his/her personal page
    • show the maps
    • display the destination list
  • Runs on: the user’s smartphone or PC
  • Interacts: with the server via HTTP

Server:

    • Functions:
      • initialize the stations (startup session)
      • build the destination list
      • build the maps
      • save the station’s informations in the database
      • destination ranking
      • send notification to the user
      • save user informations/settings
      • host the website
    • Runs on: the server
    • Interacts:
      • with the Web app via HTTP
      • with the Stations via HTTP
      • with Google Maps via Google Maps APIs

Station:

    • Functions:
      • get data from the microphone
      • get data from the sensors
      • manage sensors' data
      • transmit data to the server
    • Runs on: the stations spread around Politecnico
    • Interacts: with the server via HTTP

2  Selected components

2.1 Hardware Components

2.1.1 Off-the-Shelf

  • Server:
    • Raspberry Pi
  • Station:
    • Raspberry Pi + wifi module
    • USB Microphone
    • Z-Wave Sensor (Light, Humidity, Temperature, Movement)
    • Razberry

2.2 Software Components

  • Web app:
    • Bootstrap v3.3.4
    • jQuery v1.11
    • Google Maps API v3
  • Server:
    • Flask v0.10.1
    • Databases (SQLite)
  • Station:
    • Z-Way API
    • Custom software for noise detection

Design by Tim O’Brien t413.com — SinglePaged theme — this site is open source — Images by Luca Mezzatesta