Team Vision for System-Level Design Phase
What did your team plan to do during this phase?
During the Systems Design phase, the team planned on working through each step of the design individually and then meeting together to discuss different views each member of the team had on a topic. When a new section of the systems design was discussed in class, the team members would discuss who would cover a specific part of the system during that phase, allowing no redundant work to be done.
The first part of the design phase was planned to create a functional decomposition, based off of the customer and engineering requirements, that must be delivered by the final design of the system. The team planned to do separate functions and subfunctions for specific parts of the system, so that concepts could be created based off of the functions identified. The next part planned was to set concept requirements based off of the functional decomposition, and then start to brainstorm potential solutions and compare them to already available methods and concepts options via benchmarking. Once the benchmarking was complete the team planned to move onto concept development, where new concepts options and ideas would be discussed that could match or potentially exceed the benchmark concepts found.
Once a few concept options were agreed on by the team, the next step would be to construct a morphological table to select various system level designs. From the previous team doing much of the system level design, the plan was to see what could be changed and altered to make the system more efficient, durable and user-friendly. Once the morphological table was completed, the team planned to do feasibility questions and answers for specific parts of the system. The feasibility questions were done separately by each team member for the specific part of the project that they were currently working on, so that the assumptions, approaches and inputs and outputs were found for each area of the system. The next step in the plan was to have different members of the team work on generating error use cases, refining the engineering and customer requirements and reviewing the microcontroller currently being used.
Along with the individual work, the group planned to work together to generate system architecture for both the hardware and software application, to create a concept selection table, and research applicable standards for designing and prototyping that will take place in the future. The final plan of the design phase was to create a high-level overview of the entire system and to create a powerpoint to show the customer the key concepts generated from the phase. The team also planned to pick dates to go to Watkins-Glen, the test-site, to test the system and to see how it currently operates as well as understand what adjustments can be made to the design.
What did your team actually accomplish during this phase?
During the Systems design phase, the team completed all of the steps planned by working together during senior design class and at home on Google drive. The functional decomposition was completed by each member of the team and then the best functions were chosen by the team as a group, so that they could be displayed on the edge page and during the powerpoint for the customer. During the functional decomposition the engineering and customer requirements were reviewed and refined, so that the concepts generated could be specific and possible to fulfill the customers necessities.
The team then moved onto creating concept requirements and brainstorming potential ideas for the design based off of the benchmarking done. From looking at systems from Autosport Labs and Mouser Electronics, the team was able to benchmark potential solutions for communication of the data via Wi-Fi or Bluetooth and designing new wire harnesses and enclosure for the microcontroller. The systems found at the time had available solutions and concept options were then compared to the previous teams work. From the comparison and the functional decomposition, various concept options were brainstormed by the team and the best ones were picked by the team to be moved forward with.
Once the concept options were finalized, the morphological table was made to show the specific ideas that the team chose to move forward with for design ideas, along with changes that could be made to the past teams system to make the enclosure, wire harnesses, sensors, and code for the embedded system more efficient and user-friendly. After the morphological table was finalized, the team worked separately and created feasibility questions for the specific parts they were working on, such as the hardware or software portions of the design. Once the questions were made, the team met and chose the best questions to be presented, and then worked together to create the assumptions, approaches, and inputs and outputs for the questions chosen.
The team then worked individually to create error use cases, to create a concept selection table, to review the microcontroller and code given to us by the previous team and to go through and organize the previous teams purchases for testing and prototyping. During meetings, the system architecture and the high-level overview of the entire system were made by the team, along with a list of applicable standards found for the sensors, communication and microprocessor from IEEE. The team also picked the weekend of October 11th-13th to go back to Watkins-Glen to test the system and see how accurate the GPS signal is and how calibrated the sensors are currently.
- A working document can be found here
Feasibility: Prototyping, Analysis, Simulation
- How accurately of a speed can our sensors measure?
- How small and durable of a box can we create for our telemetry processor?
- How can we gather data and send it to the driver/team in an efficient manner?
- All sensors work properly; furthermore, all code has been used within a demonstration to provide for us basic analysis of sensor data. In addition, the wiring and circuity has been captured, allowing for ease of use when putting it together.
- A box is currently designed for the telemetry processor that is 3-D printed. Currently, the box fits most cars to be tested on; however, a need for stronger and temperature-durable box is needed to withstand high temperatures from the vehicles used in races?
- Currently, an SD card is being used the primary medium between data from the vehicle to a laptop for analysis. The SD card is cheap and easy to use; our system currently supports the SD card idea.
- Initially, we should go to the test site and see what the current test car outputs from its current sensors. The driver of the vehicle could also have an phone application or device that measures speed which can be used to compare against the sensor values. If close, this would be a great scenario such that the sensors are accurate. If the approximation is not close, the team will look into the source code to look into what caused the inaccuracy. Furthermore, a spare speed sensor could be used to see if the original sensor was not working properly.
- When going to the test site next time, the test unit should be ready within the box. This unit should be ran continuously around the track and analyzed afterwards to see what wear and tear the compartment received. If the compartment did not receive much damage, the next test would be to move it to other vehicles that are exotically shaped to test strength differently or test temperature conditions that affect the box. From here, qualitative data can be gathered for the box holding the kit which will help us finding better materials to encapsulate the telemetry processor.
- Currently, source code is available to be viewed for the SD card data processing. The source code for the SD card data presently requires a great understanding of RTOS (Real Time Operating System) and has many other dependencies which have to be understood to ensure the data processing works. Other methods of tracking data have been thought of such as Wi-Fi, which is more complicated to integrate to within the source code, but will tremendously improve the data acquisition process.
Inputs and Source
- Accelerometer - Acceleration data must be within 5% of the expected value on bench test.
- Vibration and Torture Testing of System and Enclosure - System must be able to withstand volatile in-car environment
- Mounting Bracket Design and Production - Brackets must be manufactured/adaptable to the various mounting locations within the vehicle.
- Lap Time Acquisition - Configuration of timer module to pair to GPS data for timestamps
- All sensors must acquire data within 5% tolerance.
- Device is able to store at least one hour of data to an external storage device 32GB in size without overwriting buffer
Outputs and Destination
- 5% tolerance of all sensors
- Gain a greater understanding of the source code to move forward and create greater progress
- Continuously compare to other concepts to ensure we are on the right track
- Find better and cost-effective materials to create a stronger box
Morphological Chart and Concept Selection
- A working document can be found here
- A working document can be found here
Refined Engineering Requirements (Metrics & Specifications)
Purpose: Create a contract between the engineer and the customer where indisputable satisfaction of the engineering requirements equates to customer satisfaction
- A working document can be found here
Design Review MaterialsLink to PowerPoint Presentation below:
Plans for next phaseAs a team, where do you want to be at your next review?
In the next phase the teams’ goal is to complete the preliminary detailed design of the system by the next review. During the detailed design the feasibility should be demonstrated, and through testing and analysis the design will satisfy all customer and engineering requirements, in all use case scenarios, presented in the problem definition phase. The prototyping, analysis, and simulations will be iterated until the selected concepts from the systems design phase can be confirmed to deliver functionality, as defined in the system architecture of the design. As the system design gets more detailed, more drawings, schematics, flow charts, and simulations will be made to define instructions for fabrication of the elements for the system. The Bill of Material will also be completed by the next review, which will define all components that will be fabricated or purchased, to show that the system will stay within the budget of the customer requirements. Test plans for the system will also be recorded, showing when the system was tested, the data collected from the test; and what instrumentation and test procedures will be used during the test. The risk assessments from the previous phase will also be refined, and the main points of the phase will be added to a PowerPoint to be presented to the customer.
What questions will you answer during the next phase?
- Has the team run sufficient analysis to ensure that the design will satisfy requirements?
- Have all use case scenarios been tested in the modeling?
- What are the concepts that are expected to be most sensitive or problematic?
- Did the team use the models to quantitatively specify the design parameter targets?
- Did the team complete a significant portion of the detailed design of the system?
- Are all expenses and contingencies affordable by the project financial allocation?
- Did the team demonstrate objectively the degree to which the engineering and customer requirements are satisfied?
- Has the team driven the risk severity down as they have worked through the details of the design?
- Does the GPS capture significant data that can be sued in coaching the drivers?
- What changes from the previous teams design will make the system more efficient and user friendly?
Individual 3-week plans below:
- Nick Washco:Systems Design
- Adam Bork:Systems Design
- Josh Henderson:Systems Design
- Michael Schroeder:Systems Design
- Sahil Gogna:Systems Design