Integrated System Build & Test
Table of Contents
Team Vision for Integrated System Build & Test Phase
The team vision for this phase was to successfully integrate software and hardware components to achieve a comprehensive build and design. The previous phase allowed individual hardware and software components to be built and tested, and this phase supported the joining of the two designs to be integrated and tested for success. One of the biggest successes of this phase with regard to integration was the pi to pi connection and communication, as well as connecting the pis to the PCB and successfully sending data through the integrated design and build.
Other accomplishments this phase include:
- Continuation of the integration of hardware and software concepts
- Completion of test plans to begin validating the integration of our design
- Eliminating multiple risks due to not experiencing them through our design and build phases, as well as their RPN values decreasing significantly due to our placement within the MSD schedule.
- Updated Problem Tracking documents
- Started the draft of the term paper
- Started the draft to the user document guide
Test Results Summary
During this phase, components from both hardware and software were integrated together and tested for correct functionality. These tests on integrated components were recorded on our test plan document with more detail, and can be seen here
The following tests performed during this phase can be seen below:
- UART and RS-485 Conversion
- Pi to Pi UART Communication
- Control Panel Prototype and Test Bench Integration With Team Components
UART and RS-485 ConversionThis was to test the functionality of having data sent from a Pi device to our custom PCB design via UART serial communication, have the data converted from UART to RS-485 through the custom PCB, and then back to UART through another PCB. This is needed in our design because UART serial communication is limited in how far it can send a signal. There is also the effect of having signals becoming noisier the farther out it is sent via UART. Seen below is an image that shows that the received UART (upper yellow trace) is opposite in polarity to the received RS-485 'B' signal.
During testing, the Pis were first setup to use UART serial communication using the steps listed in this document. Connections were then made from the transmit pin of the Pi to the custom PCB design. From the PCB, another set of connections were made to an oscilloscope to view data being transmitted from the PCB. Several tests were performed as some connections were tested to make sure they were done correctly. Once bugs and issues were resolved, it was concluded that the integration of the PCB and the Pi for UART and RS-485 conversion was successful. A completed test plan for this test can be seen here.
Pi to Pi UART CommunicationThis was to test the functionality of having two different Pi devices communicate with each other via UART serial communication. This is needed because it is how data will be sent between Pis. Mentioned in the UART and RS-485 Conversion section, data from one Pi is sent via UART, converted to RS-485, then converted back to UART. When looking at the end points of this communication line, the end devices are essentially talking to each other via UART. With this information, UART to UART communication between Pis was decided to provide a sufficient test case to fulfill the goals of this project.
There were two phases to test UART communication between Pis.
- The first phase was to have two Pi devices setup to use UART serial communication using the steps listed in this document. Connections were made between the transmit and receive pins of each Pi so data can sent back and forth between the Pis. In this first phase, one Pi would send data to the other, and the second Pi would simply display the received data. This test was done several times to show the receiving Pi could display whatever information is was given. Regular text and content from a text file were used to test if the receiving Pi could still display what data was being sent from the first Pi. After these tests were performed, it was concluded that this phase of the Pi to Pi communication was done successfully.
- The second phase was to have two Pi devices communicate with each other using code written in Python. Libraries were installed use serial communication with Python. The connections between Pis used in the first phase of this test was used, as it did not need to be changed. During this testing, a more real-time response was simulated. A user must have Python scripts running on both Pis. One code allowed a user to type in text via the terminal on one Pi, then have it send to the other Pi via UART. On the second Pi, once it receive data, it will display it on the terminal, then send a message back to the first Pi letting it know it received it's message. Timeouts were implemented in this phase to see how much data could be received at once successfully. This was needed because it was observed that not all characters would be received and displayed at the same time on the second Pi if there was not enough time for the Pi to grab all of the data from the input buffer. The baud rates and timeouts values were changed to resolve this issue. After performing several tests, it was concluded that the second phase of Pi to Pi communication was done successfully.
Control Panel Prototype and Test Bench Integration With Team ComponentsThis is to test having all components connected to each other to simulate how they would be connected when given to the customer.
This test has not been completed yet. It was concluded that this project would require another phase of integration as the whole system integration may contain many issues that cannot be resolved in time for this phase.
Bill of MaterialsAn updated version of our Bill of Materials document can be seen using this link here.
Risk and Problem TrackingWithin 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.
Throughout this phase, risks B, C, F, H, J, K, S, V, X were removed from the risk matrix due to being resolved with the project coming to an end with one phase remaining. The following image lists out each of these risks with their RPN values. At this point in the project, 15 risks out of 26 risks have been resolved with 1 risk, risk G "A lot of Extreme Snowfall" being encountered in Spring 2019.
To view a snapshot of our risk register for the Integrated System Build and Test phase, please click here.
In addition to our Risk Register, we also updated our Problem Tracking document based off of integration tests that were completed. At this point in the process, there are no extraneous problems that have happened that will impact the completion and customer handoff scheduled for next phase. To view a current snapshot of our Problem Tracking documentation for the Integrated System Build and Test phase, please click here.
Term DeliverablesThis phase, we began drafting our end of project deliverables. The first item we addressed was our MSD Term paper due to our project coming to an end within the next few weeks. The first step we did to determine what information would be needed to mention in the paper was draft an outline. The outline we have created is our first draft outline and is visible below:
From the outline, we began drafting our term paper. To view a section of our first draft, please click here.
In addition to the term paper, we began drafting user documents for customers interested in building our design. To view a part of our user document first draft, please click here.