This past week, we gave our design presentation and worked on the design proposal.
During this time, we shifted our design process quite a bit. In the beginning of this project, it seemed like we were coming up with an early design and then thinking about why it was good or bad. Now, our design process has turned into defining a problem, coming up with options to solve each part of the problem, then weighing the pros and cons for each of those options to come up with a design for the whole system. This has helped us a lot with justifying the design decisions we make.
After our design presentation, we received quite a bit of feedback from our peers and instructors:
- Think more about the security of the system, since that was one of the system’s supposed pro’s stated earlier.
- Think critically about the 3 second recovery spec in relation to a node in the system going down. Is this possible, given that the node killed was the “master node”?
- Consider alternative master node selection techniques than “lowest serial number”
- Must consider more granular testing of distributed system than “chaos testing”. Messages aren’t read, how will we know how things go wrong?
- If the master node fails, how will the user get to access the web application? Another node would have spun up the web app, but how will the user know that IP address?
- How will external devices gain access to our IoT devices, which may be behind a private network?
- How will we achieve pub/sub protocols while using the low energy requirements imposed by IoT device constraints? Specifically, we will look into ESP8266 & ESP32
Jiaqi actually came to us after the class period and talked to us, suggesting we look into a new device that a lot of IOT projects use. It is called NodeMcu, and has WIFI connectivity, processing power, and can host a simple server, serving a small web application. It could be a much cheaper alternative to using a raspberry pi. We are currently evaluating this option, seeing if it fits our needs and if we will have access to these units given the recent corona-virus events.
Even though this was a design phase, the team has spent some time experimenting with and getting familiar with the technology to build the system. This is important so we can hit the ground running when the time comes to implement the design. All three team members must be on the same page, especially about communication between the different components. A big part of the design doc will be how the data is stored and sent between each device. Planning this out ahead of time will make life easier as we implement each part and make debugging the system easier as well.
In moving forward and formalizing our design, we have carefully considered the feedback given to us. Integrating this feedback will allow us to produce a higher quality project. Reflecting on our feedback, we have realized as a team the importance of finalizing and creating a solid design. Without carefully constructing and reviewing our design in this phase of the project, we will suffer the consequences throughout the rest of the term.
