SOS-SMS

SOS-SMS
Android Application Screenshots

A little bit of background

Our goal was to implement a scalable safety solution for companies with work environments that could potentially become hazardous at any given time. In order to achieve our goal, we decided to experiment with multiple platforms including hardware, mobile application development, web development, and much more. While using cutting edge technology, we also wanted to ensure that our solution would be accessible to all employees regardless of their technological background.

What it does

Our software looks for environmental changes in a given area, and when it deems a specific event hazardous, sends out an emergency alert SMS text message to the phones of all employees. The employees then have the ability to respond to that message updating their status within the database (safe || unsafe).

How we built it

Our system utilizes the raspberry-pi development board and attached environmental sensors to look for potential hazardous conditions in the area (for the sake of our demo it's just a button to simulate an environmental trigger). Once triggered, the raspberry-pi calls the Twilio API which sends an SMS text to all numbers stored in the systems Firebase. The android app (designed for managers only), also has the ability to trigger the Twilio API for the same result. Once the messages are sent, the employees then have the ability to respond to the SMS message with their status update (in this case either yes/no and other variations, indicating safety). These responses automatically update within the database, allowing the manager to see who might be in trouble.

Challenges we ran into

There were many challenges when developing this project:

1) We began using AWS Pinpoint, SNS, and Lambda, but ran into a multitude of issues when trying to update the Firebase database through the Lambda function.

2) None of us were very familiar with raspberry-pi development, so it took a lot of time to understand how to get that started, mainly when trying to flash the board.

3) The scope of our project may have started off a bit too wide. We definitely needed to narrow as we progressed, and ultimately ended up with a product that has potential for growth.

Accomplishments that we're proud of

1) Getting a fully functioning system working within the 24 hour period.

2) Integrating each component together, despite their different natures.

What we learned

Beyond learning more about software development in a team setting, we got to experiment with a lot of technology that we weren't familiar with prior to this weekend. This includes AWS, raspberry-pi development, and other SMS based clients.

What's next for SOS-SMS

1) Allows employees to report incidents to notify managers/first responders on site immediately. Rather than giving access to just the managers or sensors, it would be nice to have a component that gives employees access to incident reporting. This could mitigate certain hazards being overlooked, i.e. ones that can't be detected by sensors such as a broken limb or something hidden.

2) Increase functionality of the managerial app.

3) Implement functionality for sensor specific notifications (i.e. a carbon monoxide leak will send an SMS with details on location, type of hazard, etc.).

4) Implement AWS features to replace Twilio to keep the system consistent.