Preliminary Detailed Design
Team Vision for Preliminary Detailed Design PhaseFor the Preliminary Detailed Design phase, the following goals were included in our team vision:
- Confirm the proposed design appropriately addresses the engineering and customer requirements provided from the RIT Model Railroad Club, the team's PRP, and the customer interview
- Complete the test bench configuration to begin prototype testing and assembly
- Design preliminary software concepts to achieve open source goal
- Configure the Pi Zero for prototype testing and integration
- Create a test plan to confirm our design is functional with respect to the engineering requirements
- Reevaluate the high risk items to mitigate any potential issues with prototyping
Throughout this phase we encountered a few unexpected problems. Within our purchase requests through MSD, we did not encompass all cables necessary within a single purchase. As a team, we did not realize we were missing a VGA to HDMI cable for our prototype as it was not provided in our lab workspace, so were required to input another purchase. This caused us to incur unexpected costs due to the extra shipping cost and cost of cables. Another problem we encountered was difficulty with utilizing the monitor / desktop setup with our VGA to HDMI connectors to begin testing the pi zero. This problem was resolved by adjusting settings within the team member's laptop to appropriately connect and display the prototype.
Another concept we are addressing is the open source goal of our design. With a generic design, it is difficult to make something truly generic without knowing all complicated / worst case layout scenarios. As a team, we are comparing our layouts against RIT Model Railroad Club's Niagara layout due to its complex integrations of block detection, routing, and switches. The challenge we are facing is how to allow users to adjust our design to encompass any complex layout, without us as a team designing specifically for a given layout.
Test Bench Prototyping and SimulationThroughout this phase, one of our primary focuses was our test bench. Our test bench encompasses a functional purpose to allow us to prototype our designs against a model of the RIT Model Railroad Club's current systems. This model also allows us to focus on how our prototype will interact with the club's NCE system, without damaging their existing layout.
The test bench schematic is as follows:
From this, the test bench was built to begin prototype testing:
Software Concept Design AnalysisThroughout the phase there were discussions about how to design the software. Questions were brought up, flaws were discussed, and smaller details were considered during these discussions. Though not finalized in this phase, the following notes were written to review during the next phase to decide on a "final" design for the software.
- Needed to determine how many switches / buttons /
LEDs will be on a control panel
- This number will vary with each control panel design
- Input from user can be used to determine the
connections between all the components on a control
- Can be answered with a layout configuration file
- Needed to determine how many switches / buttons / LEDs will be on a control panel
- IMPORTANT Is a requirement from the customers
- Having inputs will help with writing the code to
- Can ask users questions (ex. "How many LEDs
do you need on the control panel?", "How many
Buttons do you need on the control panel?", etc.)
- These questions answers how many GPIO pins will be used on a Raspberry Pi Zero
- Can ask users questions (ex. "How many LEDs do you need on the control panel?", "How many Buttons do you need on the control panel?", etc.)
- Keep track of all the Raspberry Pi Zeros (PiZeros) on
the Raspberry Pi 3 (Pi3)
- This is because the Pi3 will be communicating to multiple PiZeros and the Pi3 needs to know which PiZero it is communicating with
- Can a text file solve this problem?
Question: Will there be enough storage
on the Pi3 to hold all that information?
Solution: The team can always buy
Feasibility Question: Do we
have enough money in the budget to buy
- Feasibility Solution: Possibly - This will have to be reevaluated when the problem arises
- Feasibility Question: Do we have enough money in the budget to buy more storage?
- Solution: The team can always buy more storage
- Question: Will there be enough storage on the Pi3 to hold all that information?
- Comments in the code
- Needed to allow user who are not familiar with
the code to know which sections need to have
- Because the customer would like to have the
code the team provides as open source, the team
must consider which sections might have changing
information so users can change those sections
based on the user's layout configuration
- Open source does not necessarily mean that other technology that we are not working with will be considered
- Because the customer would like to have the code the team provides as open source, the team must consider which sections might have changing information so users can change those sections based on the user's layout configuration
- Needed to allow user who are not familiar with the code to know which sections need to have information changed
- LED signals
- LEDs must produce three colors: Red, Green,
- Each color has a meaning and informs a user of the model railroad system about the current status of the layout so that the user can determine what action to take
- Logic, if-else cases - can be used to determine
which color to display on an LED
Question: Can an RGB LED be sent
signals to change the color it's displaying?
- Solution: Yes, several team members have worked with RGB LEDs and produced various colors by sending specific signals to it
- Question: Can an RGB LED be sent signals to change the color it's displaying?
- LEDs must produce three colors: Red, Green, Yellow
- Layout configuration
- Question: How will the layout information be displayed?
- Question: How will the layout information be stored?
- Both questions above will be answered in next phase
Hardware Concept Design SchematicThis is a V1.0 level schematic created for the purpose of determining potential issues when translating thoughts and ideas into hardware. Note that the SPST momentary switches (SW1-SW-16) and the LEDs (D2-D9) will have connections to the Raspberry Pi shield, but will be physically located on the control panel. This schematic was generated using Eagle 9.2.2 Educational edition.
Bill of Material (BOM)At this point in the project we have utilized $242.98 of our $1,000.00 budget. The majority of items purchased for prototype testing are able to be repurposed and used within our final design implementation. We would like to acknowledge the RIT Model Railroad club for allowing us to create the testbench with items currently in their part inventory. With their support, we were able to construct the testbench from donated items.
1. Voltage Regulator
- Use PSpice to simulate
- Measure the input and output voltage.
- Prototyping will be done in breadboard before
- Voltage input will from DCC power supply or power supply
- Read output voltage by multimeter
2. LED and switch
- Prototyping will be done in breadboard
- Turn switch on and measure the voltage drop across resistors
- measure the current across resistors
3. Button Input
- Build circuit with Pi Zero and LED
- Drive LED when button pressed
Software1. Pi 3 communicate with Pi Zero(s)
- Send message from one to other
- Compare messages sent to confirm same message
2. Signal Logic
- List out use cases
- Compare signal capabilities to use cases
3. NCE Communication
- Have Pi 3 communicate with NCE Command Station to flip switch on test bench
- Observe if desired behavior occurs
4. Button Input
- Build circuit with Pi Zero and LED
- Drive LED when button pressed
To view our test plan please click here
Risk AssessmentWithin our risk register, we assigned all risks with a letter code. The risks we identified were based off of a 1-3-9 rating, 1 being least severe to 9 being most severe. The ratings were given to the severity of the risk and the likelihood of the risk occurring.
A risk register graph was created to depict where the majority of our risks fall in terms of severity and likelihood, as well as if any risks are added or deleted out.
The Risk Register was assessed to determine if any mentioned risks have been encountered or if their likelihood or severity have changed. As seen below in the risk register graph, risks D and J were re-evaluated and adjusted to show a lower RPN. Risk D reflects the risk "Customer expectations are beyond scope of MSD 1" and risk J reflects the risk "Customer does not understand technical limitations of MSD". With closing the third phase of MSD 1, the two mentioned risks changed in likelihood value from 3 to 1. Also, no risks were completely deleted out of the risk management system only adjusted in RPN value.
To view our risk register, please click here
Design Review MaterialsTo access our Preliminary Detailed Design Phase Review powerpoint, please click here
Plans for next phaseIn addition to the below WBS section, the following goals are to be completed within the Detailed Design Phase.
- Final High Level Software Design to begin testing
- Final High Level Hardware Design to integrate with test bench
- Begin test plan tasks and measure against expected results
- Document all plans and designs to adequately prepare for MSD II
- Marianna Palacios - Three-Week Plan
- Denisse Aquino - Three-Week Plan
- Kevin Bradford - Three-Week Plan
- Derek Schwartz - Three-Week Plan
- Rui Chen - Three-Week Plan