Project
Table of contents
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
The idea and execution must demonstrate design skills and creativity, culiminating in a functioning deliverable (feedback for this will be given during the proposal and milestone).
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)
Timeline
Wednesday, Oct 4: Project groups assigned
Friday, Oct 13: Proposal due
Week of Oct 16: Proposal feedback received, parts ordering begins
Proposal (Due Friday, Oct 13 at 11pm)
Write a project proposal (about 1-2 pages) 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 early 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, factoring in shipping. We will take a look at this and approve it/offer suggestions before putting in orders. Each group has a budget of $40.
Part orders will be placed the week of Oct 16. Factor in about a week of processing and shipping time to receive the hardware.
Progress milestone
The progress milestone consists of a report (composed of artifacts from the left/design side of the software engineering V-model), a short presentation/demo, and peer reviews.
Please turn in the following (as separate files in the same submission) to Gradescope:
- Your report (see below)
- Your milestone presentation slide(see below)
A basic rubric that breaks down the point distribution for the progress milestone is here
Milestone report (due Wednesday, Nov 8 at 11pm)
Your report should have the following sections:
Clear, concise, complete, and confirmable requirements for your project, written with “shall/should” language as defined in class.
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.
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. 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. Include a short (1-2 sentence) description of what the use case scenario is.
One finite state machine that describes the detailed design of the main module of your system, as described in class. 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. Once you start coding your project, you will be expected to write your code according to your FSM, like in lab 5 – figuring out the way your FSM interacts with inputs/other modules is a non-trivial design problem that you should start thinking about now. Note that you should have your FSM ready in time for the demo (Nov 6 or 7, see below).
A traceability matrix of how the transitions and states of the FSM in step 4 trace 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 the FSM lecture.
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 (and later lectures). 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 final deliverable/project requirements: if the deliverable has changed/been scaled back due to challenges and/or feedback, you should include updated versions of parts 1 and 2 of the proposal. If there were comments in your proposal about how you meet the four requirements in the Project Overview section of this document, you should address these comments.
Demo (Monday, Nov 6 and Tuesday, Nov 7 during lab time)
You should prepare a slide with a quick summary of the project description and goals. You should plan to do a brief (5 min) live demo of the work you described in step 4 of the proposal – showing the Arduino reading in sensors/controlling actuators is totally sufficient here. (If you cannot get a demo working before your presentation day, you can present a second slide of the challenges you have faced in getting a working demo and how you plan to address those challenges.)
After demos, we will use the remaining lab time to do peer reviews – have your FSM ready in some sort of document (pdf, google doc, etc) before your demo.
Final deliverables
Report (Initial due date: Dec 14 @ 11pm, Receive feedback by EOD Dec 15, Revisions due Dec 17 @ 11pm)
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.
Three sequence diagrams for reasonable use case scenarios of your system (if there are more than 3, you should pick the 3 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 will discuss safety and liveness requirements on the week of November 27th. 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. Composing state machines was covered on November 15/17. 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 review spreadsheets you received after the milestone demo. Each defect 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 (Dec 17 @ 11pm)
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/ADC/DAC, watchdog, ISR, WiFi/Serial/timer), in your own words, explain how the requirement is being met. For PWM/ADC/DAC, watchdog, and ISR, we are looking for you to demonstrate understanding of the purpose and nuances of these peripherals as discussed in class and how they apply to your project. Thoroughly explain how the hardware and software design and behavior of your specific project makes use of these peripherals and why your team chose to incorporate them where you did in the project.
Any extenuating factors or important information about your team dynamics that you would like to share (this will be kept confidential).
Code (Dec 17 @ 11pm)
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. The FSM implementation of your code should follow the conventions learned in class and should have annotations for each transition. All functions in the code should be commented with descriptions of the high-level behavior, inputs, outputs, and side effects.
Form for website (Dec 17 @ 11pm)
To receive a grade for the final project, your group must fill out a form that asks you to upload/include links to a photo/optional video of your project, your flier or slide (see below), and an optional github link. We’ll ask your permission to display these on the course website as a celebration of your work.
Demo (Dec 12)
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 [deadline TBD]. 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. 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.