SSH: Situational Student Helper
We describe the main features of a system that could benefit from being built upon the concepts and techniques investigated within the SMScom project. The overall goal of the system is helping students roaming the campus of a big University (e.g., Politecnico di Milano) achieve their goals of optimizing their schedules, finding quiet classrooms for studying, setting up card games, or socializing and meeting friends. Since the main characteristic of the system should be its adaptivity to ever-changing student needs, the set of functionalities described in this document is only indicative of what students might use the system for. Other uses (i.e., functionalities) are left to the students to invent.
This document outlines the main features of a system that could be a test bench for the techniques developed within the SMScom project.
The system is born out of the Cooperative Mobility (CoMob) scenario discussed in meetings, of which it strives to keep the main features (e.g., mobility, high level of distribution, dynamism, etc.). However, that scenario is here re-cast as a campus-wide system for a big University, to make its implementation in a pilot application a realistic goal in the SMScom project.
The Situational Student Helper (SSH) system is intended to be an automated assistant to the students roaming the campus of a big University. These students are performing many disparate activities that require some coordination among them. However, the core idea underlying the system is that there is no centralized coordination mechanism to guide the students through their activities. Rather, the students are interacting with each other (and possibly with some infrastructural elements, such as ambient sensors, installed in the University campus) in a decentralized manner.
The key assumption underlying the application is that students have at their disposal mobile devices, such as smartphones, that are able to run fairly sophisticated pieces of software. These devices are able to interact with each other, and also with a “smart campus” that is outfitted with a variety of sensors, whose readings are made available (possibly through intermediary software components) to the students’ applications.
The SSH system is an enabler for applications that respond to the needs of students who are on the University campus, including those needs that arise after the deployment of the system. Hence, a key feature of the SSH system must be the ability to respond on-the-fly to emerging, previously unknown, student requests.
For its very nature, the SSH system is not built with a fixed set of requirements in mind. What follow are some possible examples of tasks that students can accomplish through the SSH system, presented as scenarios.
Search for a quiet classroom
Student Alison Smith would like to get some work done for hew Advanced Calculus class, before going home. She is looking for a quiet room where she can study unbothered by other people, since the subject she wants to study is very tough, and she needs to focus. By querying the smart campus infrastructure, the SSH application running on her smartphone determines that classroom S13, which is close to where she is now, is at the moment empty. However, by interacting with SSH applications on fellow students’ smartphones Alison’s application determines also that a group of students is heading towards classroom S13 to play some card games. Classroom N14, on the other hand, is a bit farther away from her current position, and it is not empty; however, the smart campus sensors detect that the classroom is very quiet (the students there are also working hard on their classes). Classroom N18 also seems suitable for Alison’s needs (it is quiet, and reasonably close; in fact, it’s closer than classroom N14), but the system determines also that it is too cold for Alison’s tastes, and Alison does not like to study in cold environments. Hence, the SSH application on her smartphone redirects Alison towards classroom N14, and points her in the right direction to get there.
Search for people to study with
Student Brett Johnson does not like to study all by himself. He prefers working with other people (e.g., to exchange opinions on different exercise’s solutions), provided these are good hard-working students and not lazy time-wasters. He does not mind working with people he does not know, if they meet his requirements. Today, he needs to work on his Object-Oriented Programming class, which is taught by Professor Corman, and focuses on Java. The SSH application running on his smartphone looks around campus for other students in his same class; the only students it can find are either currently working on other subjects, or do not meet his requirements, or are playing around and not working. However, the application finds a small group of students working on the Advanced Programming class taught by Professor Raimi, who also teaches Java. Since the topics match, the SSH application determines that this latter group of students fits Brett’s needs; it then sends a query to those students (through their smartphones), to check whether Brett can join them. After they respond affirmatively, the SSH application points Brett to the classroom where these students are.
Student Curtis Brown today has classes only in the afternoon, starting from 2pm. He plans to use the morning to catch up with a few items on his to-do list. In particular he wants to:
- go to the student office to complete some paperwork regarding the classes he wants to attend this semester;
- talk to Professor Hyde, whose office hours are between 11am and 1pm;
- go to the library to borrow a molecular biology book;
- talk to the dorm manager about a possible room switch.
Curtis would like to have some time for lunch before going to class at 2pm, but he is flexible with that (he can grab a quick sandwich before heading to class, but he is also amenable to skipping lunch altogether, if need be). The SSH application running on his smartphone determines that many people are already in line at the student office, while Professor Hyde is currently talking to a fellow student, and another one is waiting. However, one of these two students is going to have a long talk with Professor Hyde (about her Master’s thesis), while the students in line at the student’s office need just a minute or two each to complete their queries.
The SSH application on Curtis’s smartphone then determines that the best schedule is: 1. dorm manager; 2. library; 3. student office; 4. Professor Hyde.
However, while Curtis is at the library, a fire alarm goes off at the student office building, which must be evacuated. The application then re-routes Curtis to Professor Hyde’s office; however, the rescheduling forces Curtis to skip lunch, which is acceptable, though not the preferred situation, as he is in fact able to complete all his chores.
The fire alarm goes off at building 22, which houses the student office, an open space for students to work and study, and some faculty offices. The SSH components that run on the computing infrastructure of building 22 send alerts to the smartphones of the people who are in the building when the fire alarm goes off. In addition, the alarm notification indicates the path to get out of the building (customized for every recipient), and instructions for people to exit safely from the building. Also, the SSH system alerts the people who are either approaching building 22, or have a visit to building 22 in their plans, that a fire emergency in ongoing.