P19345: Model Railroad Control Panel

Build & Test Prep

Table of Contents

Team Vision for Build & Test Prep Phase

Our team vision for the Build and Test Prep phase was to confirm our system design and update all edge documentation with work completed over the summer. This phase, we were able to reconvene with our customers in the Model Railroad Club and review our project scope and progress. This phase was critical to set a foundation of necessary design build tasks and tests to prepare our team for successful project deliverables. The following tasks were accomplished this phase:

Design Summary

Hardware Schematic



The following changes were made to the schematic between the last design review and now

PCB Layout

PCB Top View

PCB Top View

PCB Bottom View

PCB Bottom View

Some changes were also made to the PCB layout

Software Design Summary

Chosen aspects of the phase to provide a summary of the project design can be seen in this section.

The figure below is a diagram that contains the information of how the different components of the system will be connected.

Updated System Architecture Diagram

Updated System Architecture Diagram

A general block diagram of how the different parts of the overall system are connected to each other is depicted below. The block diagram does not include the hardware components that will be included during integration of subsystems.

General block diagram of overall system

General block diagram of overall system

A list of preliminary planned out functions to use for software development is provided below, but a more detailed description of the functions can be seen using the link to the Detailed Design - Software Design Concept

Preliminary Planned Out Functions


- initPi3
- connectPi3toCS
- sendCommandToCS(command)
- getSysConfig
- getBlockOccupancy
- sendColor(color)
- ledOn / ledOff / toggleLED
- getButtonPressInfo


- initPi0
- connectPi0toPi3
- ledOn / ledOff / toggleLED
- setButtonPressInfo


- startTime(timer)
- endTimer(timer)
- printTimer(timer)
- resetTimer(timer)
- initTimer(timer)

The previous phase of the software design can be seen here. The design will be updated along the way as needed.

Before the semester started, the software aspect of the project was planned briefly. Planning out the software included emulation of the expected behavior of the code. Though incomplete, it was discovered certain data structures are more efficient to use based on the information that needed to be stored. Some of these data structures can be seen below.

PiZero Data Structures

id : string; must be a unique value to allow the PiThree to identify a specific PiZero
controlPanelButtons : Will hold information about which buttons are pressed on a control panel; keys in left and right sides will be the button itself. Its value will be a boolean value saying if it's pressed or not
controlPanelButtons = {
leftSide = {},
rightSide = {}
gpioPins : Keeping track of which pins are already being used on a board; Pins will be grouped in 3s because of the encoder that is being used in hardware
gpioPins = {}

PiThree Data Structures

gpioPins : Keeping track of which pins are already being used on a board; Pins will be grouped in 3s because of the encoder that is being used in hardware
gpioPins = {}
piZeroIds : A set that will contain all PiZero IDs. Having a set does not allow for IDs to be duplicated
piZeroIds = {}

As mentioned before, code to emulate the expected behavior of the software that will be developed for the project was written. The code is currently incomplete, but will not be used for the actual project code. The emulation code can be used for reference while developing the actual code that will be used for the project. The code can be seen in the documents listed below.

Customer and Engineering Requirements

For reference, our customer and engineering requirements are visible below:
Customer Requirements

Customer Requirements

Engineering Requirements

Engineering Requirements

A working version of the customer and engineering requirement document can be found here.

Test Plan Summary

Test Plans were created and documented here. Lab space was reserved in the Electrical Engineering department on the third floor of Gleason, and all items necessary to begin building and testing are available for use.

Our test plans were created through analyzing the engineering and customer requirements. We utilized the MSD test plan template to create a standardized format in which we can identify what materials are needed, how data will be collected and maintained, what processes to follow to complete the test, and a summary of our conclusions on if the test was successful or not. These testing requirements are visible in the below image:

Testing Requirements

Testing Requirements

To view an example of one tab within our test plan document, please see the below image titled T6 Test Plan. This format is followed throughout our entire test plan excel sheet. Each tab represents a different test plan for each of the engineering requirements, and specific testing cases are visible within the testing flowchart section.

T6 Test Plan

T6 Test Plan

To view the live test plan document, please click here.

Risk and Problem Tracking Documentation

Risk Register

Throughout MSD 1, we utilized a risk register to monitor the potential risks that could impact our project. With continuation into MSD 2, we will be utilizing the same risk register with modifications to our risks' severity and likelihood each phase. Each risk is assigned a letter code and rated based off of a 1-3-9 rating in severity and likelihood with 1 being the least severe and 9 being the most severe.

The Risk Register was assessed to determine if any mentioned risks have been encountered or if their likelihood or severity have changed between the end of MSD 1 and beginning of MSD 2. As seen below in the risk register graph, risks D and Y were marked as being resolved. Risk D was "Customer expectations are beyond scope of MSD 1" and Risk Y was "Customer expectations are beyond scope of MSD 1". These ideas were successfully resolved with the end of MSD 1. Risks B and K were re-evaluated and adjusted to show a lower RPN this phase. Risk B reflects the risk "Team member drops the class". All team members were able to enroll into MSD 2 and have a plan to remain enrolled throughout the semester. With this, the severity of risk B was reduced from a 9 to a 3. Risk K reflects the risk "Customer requirements are misunderstood by the team." Through beginning the build and test prep phase of MSD 2, this risk was able to be reduced from a likelihood of a 9 to 1 for our strong communication of project scope between customer and team.

Risk Z, "Technological issues encountered with remote communication between Marianna and Team" was added this phase to address team member Marianna's remote accomodation for MSD 2. To mitigate this risk, back-up communication alternatives are available such as Google Hangouts, GroupMe, Facebook Messenger and Video Call, Facetime Call, and Regular Phone Call. This risk has a RPN value of 9.

Risk Register Visual Interpretation

Risk Register Visual Interpretation

To view our risk register, please click here.

Problem Tracking Documentation

In addition to the Risk Register, we have created a problem tracking document to identify problems encountered. This document relays mitigation plan completion and allows the team to monitor our potential problems.
Problem Tracking Snapshot

Problem Tracking Snapshot

To view the entire problem tracking document, please click here.

Plans for next phase

Subsystem Level Build and Test Phase Scheduled Plan

Subsystem Level Build and Test Phase Scheduled Plan

To view our entire MSD II schedule, please click here.

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation