A: The problem

• Internet of Things (IoT) broadly refers to sensors and "smart" devices with network capabilities that can be employed to design various applications. Here we will use IoT concepts to design a distributed system that can be deployed in a "smart home" to automate simple tasks.

  We will assume three classes of IoT objects:

  1. Sensor, which can sense surrounding conditions and report it.
  2. Smart Device, which can be remotely turned on or off
  3. Gateway, which is a tiny server that interacts with sensors and smart devices.

  The goal of the assignment is to build a distributed system with three sensors, two smart devices, and a multi-tier central gateway that controls these sensors and devices. We will use this system to implement a simple security system in the smart home.

  Assume three types of sensors: a temperature sensor that reports the current temperature, and a motion sensor that reports whether it senses motion in the surrounding environment. The temperature sensor is a pull-based sensor, where the gateway must send it a query and it responds by sending the current temperature. The motion sensor is a push-based sensor where it pushes a notification to the gateway whenever it senses motion and does nothing when there is no motion.

  The third type of sensor called the door sensor. The door sensor has two states: open and closed, which indicates whether the entry door is open or closed. While the door sensor can be polled to check its current state, it is primarily a push-based sensor that pushes a notification wheever there is a state chage (e.g., the door is opened or when the door is closed).

  Assume two types of smart devices: a smart light bulb and a smart outlet. Both smart devices have remote control capabilities, which means that in addition to being turned on or off normall by users, they can be remotely controlled by the gateway and turned on or off through commands sent by the gateway. Both smart devices need to support query capabilities where they are queried by the gateway about their current state and they respond whether they are currently on or off. Both also support control capabilities where the gateway can send a command to change the state from on to off, or off to on, and they perform the action and send an acknowledgement.

  The gateway, sensors and devices the following interfaces:

  • register(type, name): initially all sensors and devices must register themselves with the gateway. The type can be "sensor" or "device" and the name can be one of "temperature", "motion", "bulb", "door", or "outlet" Sensors only have query or reporting capabilities, while devices can be qeuried as well as actuated. Upon registration, all sensors and devices are given a global ID, which is simply a unique integer.
  • query_state(int device id): all sensors should support pull-based query where they receive a query_state request from the gateway and report their current state. A temperature sensor reports state as the current temperature; a motion sensor reports state as yes or no, while devices report state as on or off. The reply to query state should contain two parts: the device id and the reported state.
  • report_state(int device id, state): any push-based sensor or device can push its current state to the gateway without being asked via the query_state interface. This is achieved via report_state call to the gateway. The sensor or device includes its device id and current state. The interface can be used to implement a push sensor where its reports its state whenever a change is observed (e.g., motion can be reported when the state changes from no motion to motion, or absence of a motion is reported when motion has stopped).
  • change_state(int device id, state): any smart device with control capabilities also supports the change_state command where the gateway can specify the state as "on" or "off" and it changes its state to the specified state.
  Assume that the smart home has one temperature sensor, one motion sensor, one door sensor, one smart light bulb, and one smart outlet. In addition, there is central gateway that interacts with all sensors and devices.

  The central IoT gateway should be implemented as a multi-tier architecture and we will also use clock syncronization and logical clocks to reason about ordering of sensor events.

  Assume that the gateway a multi-tier application with two tiers: the front tier is the application tier that interacts with sensors and smart devices. The backend tier is a database tier that maintains a database of sensors and their current states as well as the history of prior state changes / events seen by sensors and devices. For simplicity, we will not use an actual relational database. Instead implement the database tier as a separare process from the front-end gateway process. The database process should interact with the frontend tier and maintain its state on a disk file (the file contains data for the "database" and each record is a single line with text entries). You can be creative about the schema for your database and how you store and retrieve data from your file. Be sure not to maintain the entire file in memory since it is important for the data in the database to be persistent. The front-end tier should record state changes into the database history "table" and also update the current state of each sensor in the database when it changes. The front-end tier can also query for data from the history or check the current state from the database. The front-end and back-end processes should interact with one another using RPCs, RMIs or network sockets and the two tiers should be capable of running on different machines.

  You should also implement a user process to simulate arrival and departure from the smart home as well as turning on devices or triggering sensor such as motion sensor based on user movement inside the home.

  Further, while the API exposed by front-end servers as as specified above, you should implement your own internal interface to handle interactions between the front-end and back-end processes (you can deisgn it any way you wish and this interface should be documented in your README file).

  Implement each sensor, device, gateway and the user as separate processes that are capable on running on different machines. All entities communicate with one another via the above interfaces. This is essentially a distributed client-server application where the gateway is the central server entity. The gateway process should support concurrency where it should be capable or interacting with multiple sensors or devices at the same time.

  Part 1: Leader election and clock syncronization

  Assume that the front-end, back-end, sensor and device processes run a leader election algorithm to elect a time server. You can use any leader election algorithm discussed in class for this purpose. Once a leader has been elected, this node also acts as a time server. Implement the Berkeley clock syncronization algorithm to syncromnize their clocks. Each node then maintains a clock-offset variable that is the amount of time by which the clock must be adjusted, as per the Berkeley algorithm. We will not actually adjust the system clock by this value. Rather to timestamp any request, we simply read the current system time, add this offset to the time, and use this adjusted time to timestamp request. Each push or pull event is now time-stamped with the syncronized clock value; this time stamp is recorded in the database so that the gateway can track when the state change occured.

  Part 2: Logical or Vector clocks

  While clock syncronization can be used to syncronize clocks and reason about ordering of events, it is also possible to do so using logical or vector clocks. Assume that all sensors and devices as well as the front end server maintain a logical or vector clock. You can either use Lamports clocks or vector clocks for this purpose. Pick either the totally ordered multicast or causally ordered mutlicast algorithm to determine an ordering of all push and pull events. Like before, record the logical/vector timestamp in the database.

  Part 3: Event ordering

  With these algorithms in place, we can now reason about events and take appropriate actions. First design an algorithm that takes motion sensor and door sensor data to infer when someone entered or left the house. For instance, if motion is sensed first and the door open event happens later, it follows that someone has exited the home. Conversely, if the door open event is seen first and motion is detected later, someone has entered the house.

  Of course, your algorithm should determine which event happened before the other event using two methods: physical clock timestamps that syncronized using clock syncronization and logical/vector timestamps to determine event ordering. Log each inferred activity saying "user came home" or "user left home" in addition to logging raw events.

  Based on this reasoning, we can automate the process of turning the home's security system on or off automatically. If the user leaves the home, turn the system from HOME to AWAY and turn on the system. If the user enters the home, turn the system to HOME mode and turn off the security system. Like before, when the user is home, motion detection is used to turn on lights.

  While the system can not automatically distinguish between the user process entering the home from the burglar process (and whether to raise an alarm or not), this issue can be addrresed by adding a "presence sensor" which is simply a beacon attached to the user's keychain. When someone enters the home, the presence or absence of such a push events from such sensor can be used to distinguish between the user and an intruder. Raise an alarm if an intruder is detected.

  Requirements:

  1. You need to implement all three parts.
  2. Like Lab 1, you should use github as your source code control repository.
  3. Like Lab 1, you should create a small test suite (at least three test cases or testing scenarios) to test the correctness of your code and submit it with the source code.
• Other requirements:
  No GUIs are required. Simple command line interfaces and textual output of scores and medal tallies are fine.

  You are free to develop your solution on any platform, but please ensure that your programs compile and run on the edlab machines (See note below).

C. What you will submit

1. An electronic copy of the output generated by running your program. Print informative messages when a client or server receives and sends key messages and the scores/medal tallies.
2. A seperate document of approximately two pages describing the overall program design, a description of "how it works", and design tradeoffs considered and made. Also describe possible improvements and extensions to your program (and sketch how they might be made). You also need to describe clearly how we can run your program - if we can't run it, we can't verify that it works.
3. A program listing containing in-line documentation.
4. A seperate description of the tests you ran on your program to convince yourself that it is indeed correct. Also describe any cases for which your program is known not to work correctly. Include the testcases themselves in a test directory, to be submitted with the source code
5. Performance results.

D. Grading policy for all programming assignments

1. Program Listing
   works correctly ------------- 50%
   in-line documentation -------- 15%
2. Design Document
   quality of design and creativity ------------ 10%
   understandability of doc ------- 10%
3. Use of github with checkin comments --- 5%
4. Thoroughness of test cases and test output---------- 10%

Note about edlab machines