Project

Project overview
Proposal
Progress milestone
1. Report (due Tuesday, Nov 2 at 4pm on Canvas)
2. Demo
Final deliverables

Project overview

Design and implement an embedded project using one or more Arduinos and some external electronic components.

Your project must:

Use PWM, ADC, or DAC
Have a watchdog timer
Have at least one interrupt service routine (watchdog timer doesn’t count)

It must also use at least one of:

Serial communication
WiFi
Timer/Counter

To be updated as we cover these topics in class The final writeup and demonstration will also feature documentation of process (requirements writing, testing plan, modeling)

Proposal

Write a project proposal that has the following sections:

High-level overview of what the project will be.
Explanation of how the project will fulfill the requirements above.
Proposed final deliverable for the project – what physical object will you demo, and what is the criteria by which we will know that the demo is successful?
Proposed demo for progress milestone (will be due first week of November). This milestone should be substantial enough that you will know if the final deliverable is feasible in the timeframe, or if your requirements need to be adjusted. For example, you can demonstrate that you can connect each of sensors/actuators to the Arduino and read from/drive them individually.
Discussion of uncertainties, such as challenges you anticipate in implementing the project, timeline considerations, faulty components, etc. You don’t have to provide a contingency plan for each uncertainty, but you should offer some idea of what a scaled-back project would look like.
List of parts to be ordered and total cost. Try to order all things from the same place if possible, and factor in shipping cost and estimated shipping time.

Progress milestone

Report (due Tuesday, Nov 2 at 4pm on Canvas)

Write a report that has the following sections:

Clear, concise, correct, coherent, complete, and confirmable requirements for your project, written with “shall/should” language as defined in class (lecture 5).
An architecture diagram of the modules/components of the system and the interfaces between them. This should fit on one page and be a “boxes and arrows” diagram, as described in class (lecture 5).
One sequence diagram that describes how the modules of the system will interact for one of the primary use case scenarios of the system, as described in class (lecture 5). For the progress milestone, you only need to provide one sequence diagram, but for the final report you will be asked to create a diagram for each reasonable use case scenario of your system.
One finite state machine that describes the detailed design of the main module of your system, as described in class (lecture 5). You should clearly define the inputs, outputs, and variables of the system. Remember to indicate how the variables are initialized and what the start state is. Also remember to number your states and give each one a concise name.
A traceability matrix of how the transitions and states of the FSM in step 4 traces to the requirements in step 1. If your system is made up of multiple modules, you will not have full traceability from just one FSM, so you are not required to have a check in every column (requirement) of the matrix. Traceability matrices were covered in lecture 5.
A test plan that lays out which modules you will unit test and what integration and system (software and user-facing/acceptance) tests you will run, as described in class (lecture 6). You should explain the testing approaches you will take and how you will evaluate how much testing is enough
A reflection on whether you met the milestone you proposed in part 4 of the proposal, and if not, what challenges got in your way.
An update on the expected final deliverable of the project you proposed in part 3 of the proposal. If the deliverable has changed/been scaled back due to challenges, you should include updated versions of parts 1 and 2 of the proposal.

A rubric for the report is available when you access the milestone report assignment on Canvas.

Demo

During the lab time for this milestone (first week of November), you should prepare a 10 minute presentation with a summary of the project description and goals. You should plan to do a brief live demo of the work you described in step 4 of the proposal. Your presentation should also include any challenges you have faced so far, and your planned next steps.

You should also have a copy of your FSM from part 4 of the milestone report, digital or printed out, to perform a peer review with another team.

Final deliverables

A rubric for each deliverable is provided on Canvas.

Report (initially due Wednesday, Dec 8 at 11:59 pm on Canvas. Feedback will be given by Friday, Dec 10 10pm and revisions will be due by Thursday, Dec 16 at 11:59 pm)

Write a report that has the following sections:

A short introduction giving an overview of your project and what assumptions you are making about the user.
*Revised and fleshed out requirements from part 1 of the progress milestone report.
*Revised architecture diagram from part 2 of the milestone report.
A sequence diagram for each reasonable use case scenario of your system (if there are more than 4, you should pick the 4 most likely use case scenarios to diagram, and include a note as to what scenarios you left out). Before *each diagram, you should write a short (1-2 sentence) description of what the use case scenario is.
*Revised finite and/or extended state machine from part 4 of the milestone report. See part 13 below for directions on including your peer review feedback as an appendix.
*Revised traceability matrix from part 5 of the milestone report.
*An overview of your testing approach, including which modules you unit tested and which integration and system (software and user-facing/acceptance) tests you ran. You should explain how you determined how much testing was enough (i.e. what coverage or other criteria you used, how you measured that you achieved that criteria, and why you think it is sufficient for you to have met that criteria).
At least 2 safety and 3 liveness requirements, written in propositional or linear temporal logic, for your FSM. Include a description in prose of what the requirement represents. Each requirement should be a single logic statement, made up of propositional and/or linear temporal logic operators, that references only the inputs, outputs, variables, and states defined in part 5 of this report. We discussed safety and liveness requirements in the “Verification and invariants” lecture. You can also refer to chapter 13 of Lee/Seshia or chapters 3 and 9 of Alur’s textbook (Brown login required).
A discussion of what environment process(es) you would have to model so that you could compose your FSM with the models of the environment to create a closed system for analysis. Modeling was discussed in the “Modeling” lecture and closed systems were discussed in the “Verification and invariants” lecture. For each environmental process, you should explain and justify whether it makes sense to model it as either a discrete or hybrid system and either a deterministic or non-deterministic system (for example, a button push could be modeled as a discrete, non-deterministic signal because it is an event that could happen at an arbitrary time, but a component’s position could be modeled as a hybrid, deterministic signal based on some acceleration command). You are not being asked to actually do this modeling or any sort of reachability analysis, just to reason about this sort of modeling at a high level.
A description of the files you turned in for the code deliverable. Each file should have a high-level (1-3 sentence summary) description. For each of the assignment requirements (PWM, interrupts, serial, etc), you should indicate which file(s) and line(s) of code fulfill that requirement.
A procedure on how to run your unit tests (for example, if you have mock functions that are used by setting a macro, similar to lab 6, make sure to note that).
A reflection on whether your goals were met and what challenges you encountered to meet these goals. You should only include challenges met or newly addressed since the milestone.
As an appendix, include the two peer review spreadsheets you received during the milestone demo. Each line should be marked as “fixed” or “will not fix” with a justification.

Any sections marked by an asterisk (*) should incorporate feedback from the progress milestone report.

Individual report (due Wednesday, Dec 8 at 11:59 pm on Canvas

Each team member should also produce an independent report that has the following sections:

An overview of your personal contributions to the project (which part(s) of the code, final deliverable, report you did or helped with).
For each of the assignment requirements (PWM, watchdog, ISR, WiFi/Serial/timer), in your own words, explain how the requirement is being met.
Any extenuating factors or important information about your team dynamics that you would like to share (this will be kept confidential).

If we have any questions about your individual contribution to the project, we reserve the reading period time (Dec 10, 3:00-5:30 pm) for short meetings. If we need to meet with you, you will be e-mailed by Thursday, Dec 9 at 3pm. Zoom meetings and meetings outside of reading period time will be accommodated as best as possible.

Code (due Wednesday, Dec 8 at 11:59 pm on Canvas)

Include all of your project code in a zipped file. Any code included here should have a summary in Part 10 of the project report. We should be able to run your unit tests according to Part 11 of the project report, and all tests should pass.

Demo (Friday, Dec 3, at 3pm)

This demo is meant to be a celebration of all the hard work you put into making your project! You will get to show your classmates what you’ve accomplished and get to see what they accomplished. Have fun with it.

In lieu of a presentation, prepare a flier (half page-page) or slide to display on a laptop that you bring to the demo. If you want us to print the flier, you should e-mail it to the course staff by Friday, Dec 3 at noon. The flier or slide should contextualize your project by giving user-facing product requirements and should explain any assumptions you are making about the users of your project. Remember that user-facing product requirements can simply be the features of your project, described from a marketing perspective.

During the demo time, you will have a designated spot in the classroom to show off your project. You should have all of your hardware and any equipment necessary to demonstrate your project. If you need any special accommodations (multiple outlets, table size requirements, etc) for your demo, contact the course staff by Tuesday, Nov 30 at noon. During the demo, at least one person should be at your station at any given time to answer questions and do a demonstration, but otherwise you will be free to walk around and admire your classmates’ projects. The entire team will be expected to be available to answer questions that course staff will have.