Team Vision for System-Level Design Phase
We started off planning a team vision for system definition and discussed on how to proceed with Phase 2. The goal is to present a feasible proposal for our system that meets all of the engineering requirements from Phase 1 and any newly recognized or updated requirements from Phase 2.
A number of things need to be completed in order to justify a system design. We created functional decomposition and morphological charts to break down system function and possible solutions to those functions. From there, we worked to select a concept with different combinations of solutions using feasibility and Pugh chart analysis. After selecting a concept, we developed a rough plan for system architecture and created designs and flowcharts on user interaction with our system. Finally, we as well as reviewed and revised both our risk assessment spreadsheet and project schedule accordingly to accommodate for Phase 3.
Updated Engineering Requirements
There are already other water-powered USB chargers that exist on the market today. They are competitors and we are studying their product designs and functionality in detail in order for us to make improvements to existing tech and apply them to our product. This also helps us to avoid redundant work by making use of existing solutions and concept options.
The Engineering Requirements were updated due to the system design process and the document can be found here: Engineering Requirements
The functional decomposition chart tells us what functionality the device needs to be capable of. We first came up with our concept generation through individual brainstorming and then merging those ideas into one flowchart. Our engineering requirements from the problem definition review will be used for measuring whether we have actually managed to accomplish what we planned on accomplishing.
Our functional decomposition chart starts at the top with our end goal: to charge the phone or device. As we move down the chart and to the sub functions and sub functions within sub functions, we can see they increase in level of specificity. Moving up the chart shows why we need the device to perform a function, and moving down the chart shows how we intend to do that. This chart has therefore established our need for specific concepts required to deliver the overall objectives for our project. It has also acted as a starting point for generating morphological concepts.
The working Functional Decomposition document can be found here: Functional Decomposition
This is a system level functional decomposition; the level of specificity in the functions will only increase as we move further into subsystem design. New sub functions of various subsystems are expected to be added in Phase 3.
The objective of the Morphological chart is to develop several concept options to satisfy the required list of functions and assess whether or not these concepts are capable of delivering all functionality. This enables the team to select potential optimal sets of integrated concepts to satisfy the engineering requirements.
The working Morphological Chart document can be found here: Morphological Chart
Feasibility: Prototyping, Analysis, Simulation
PurposeThe main purpose of the feasibility study is to make sure that the selected concepts can deliver functionality defined by the system architecture. This will help us think about and use efficient methods to determine the optimal values of critical measurements such as the rotational speed of the turbine, device power output, test device floatability, test device water resistance, perform drop tests, and calculate battery charging time. We have theoretical measurements, we are now ready to verify these with the ones obtained after the device is assembled and is ready for actual testing. In the end, we will have all this data to support the evaluation of our team's concepts with quantitative information.
FailureThe team is convinced that the device can encounter failures throughout rigorous testing, but plans to troubleshoot those failures with solutions and alternatives are on hand. These failures can involve and be a combination of device sinking in water, disassembling when dropped, water entering and damaging internal components, or components such as the voltage regulator or the motor failing. Chances of these failures occurring reduce drastically through making use of Feasibility Analysis Tools.
Feasibility Analysis Tools
Project Budget: $500
That's our project budget and the Bill of Materials (BOM) attached below shows that the whole cost of assembling and testing this device will cost way less than the required budget. That means we will use the remainder of the budget as backup funds for troubleshooting, designing other prototypes or buying replacement parts if required.
The working Bill of Materials document can be found here: Bill of Materials
1. How to calculate the rotational speed of the turbine?
The shape/design of the turbine blades affect the rotational speed of the turbine The radius of turbine blades = R The speed that water is flowing = V Hence, Rotational Speed = V / R Example: Assume, If the water is flowing 2 miles/hour or 2.93 feet/second And your turbine has a radius of 8 inches or 2/3 of a foot Hence rotational speed of turbine is 4.4 rps or 264 RPM assuming there are no losses. We will also make use of MATLAB and analyze all the data to help us choose the most feasible configuration for our device. And once we have the device assembled, we can make use of a tachometer to verify our calculations.
2. How to calculate the device power output?
The working Power Calculations document can be found here: Power Calculations
3. How to test device floatability?
-Make use of RIT’s water tank in lab. -Make use of a hydrometer which measure specific gravity (relative density) of liquids which is the ratio of the density of the liquid to the density of water.
4. How to test device water resistance?· Make sure everything is sealed before testing · Make use of Genesee river as testing location · Repeat test at regular intervals and after major drops. Keep performing tests from time to time throughout development while also deepening and increasing water flow. · Place sheets of white paper or paper towels all around inside the assembled device casing/housing without the electrical components. This water test would be safe enough to pinpoint water leakage spots without the risk of harming our whole device.
5. How to perform drop tests?
Test the durability of the casing/housing without device components inside and just using a dummy instead by dropping device from different heights. The impact of the drop on our dummy should be good enough to tell us if our actual device components as well as casing can withstand the drop from that specific height.
6. How to calculate the battery charging time?
This tells us how much current the battery can deliver. Assuming we use a 20000mAh power bank with 2.1A current then the charging time would simply be 20/2.1 = 9.52 hours for the battery to fully charge. Similarly, the phone charging time can be calculated using the phone battery’s capacity rating.
Concept Development and Selection
The purpose of concept development is to generate new concept options or combinations that can satisfy the engineering requirements and potentially exceed the benchmark concepts. Using ideas from our morphological table and comparing them to our functional decomposition and engineering requirements allowed us to generate practical system-level concepts. The assemblies of these system-level concepts and their origins are shown in the table below:
The working Concept Generation Table document can be found here: Concept Generation Table
Concept selection consists of two parts: "Concept Screening" and "Concept Improvement."
Concept Screening: 6-10 useful system-level selection criteria will be identified and used to evaluate the system designs objectively. The selection criteria were chosen carefully as extensions of all existing requirements and functions in a hierarchical fashion as displayed by the table below:
The system level concepts will be compared to the concept selected as the datum in a Pugh Chart. We will then run our selection analysis over multiple datum to uncover potential differences or advantages. This comparative analysis displays how each option compares to one another in a relative sense.
Designs on Pugh Diagram:
Concept Improvement: We will continue looking for opportunities to combine more achievable system concepts in order to create a more efficient solution. While this is primarily done in the Systems Design Phase, it will continue throughout the Subsystems Design Phase and the remainder of the project.
While the comparison matrix, or Pugh Chart, shows relative applicability of each system concept, it does not necessarily quantify how applicable that is. The most important resources to consider are the quantitative and qualitative research and analyses done on each component of the design to support our evaluation.
The system architecture shows our anticipated subsystem integration methods as well as how the inputs help generate the desired outputs. These subsystem interactions, represented by the arrows in the chart below, outline what the device is doing to perform all of the required functions.
Some interactions contribute to performing more than one function. For example, the interaction between the rigid cable with the housing of the device is intended not only to prevent the charger from drifting away, but also to angle the housing of the charger in a way that allows the most flow to pass through it.
Other interactions may be unintentional or necessary for others to occur, and can actually pose risk to other areas of the project. The rotating component of the charger is what drives the entire system; it is absolutely necessary. However, the rotation of the device could result in a tangled or twisted power cable.
It is smart to exercise caution with high risk, high yield ideas that could jettison one subsystem forward while leaving the others incapable of performing their own basic functions.
Designs and Flowcharts
Designs and Flowcharts allow us to have a high-level view of the elements required to build and operate the entire system as well as showing the customer interaction process. The Interconnection wiring diagram shows the overall connection of all the electrical components being used in the device and is used as the main reference drawing for other detailed drawings for components. Drawings such as the DC Motor Internal Components drawing as well as the Voltage Regulator and Powerbank Wiring Diagram. These drawings are also part of the Feasibility prototyping process and directly related back to it. More drawings will be added soon in the future if deemed necessary.
Risk AssessmentThe risk management matrix is an essential tool for anticipating difficulties and ensuring the project stays on schedule. When assessing the risks listed in the Problem Definition Phase, the team realized many of the risks are too vague to narrow down to a single problem. In order to promote the use of risk management matrix, the team reevaluated the relevant, increasingly specified risks that may be encountered along the critical path.
Nearly every new risk added to the matrix is a technical risk. The team now has a better understanding of how the subsystems need to interact with each other in order to produce the system output. This knowledge and some initial feasibility analyses allowed the team to hone in on specific, challenging portions of the project. These tasks were documented as technical risks due to their complexity and potential to set back the schedule. The most notable risk as of now is the generation of CFD models for different turbine shapes; the mechanical engineers will most likely have to learn this from scratch.
Finally, a “Function” column was added to the risk management matrix. This column ties each risk directly back to the function it correlates with; sometimes a risk will be related to more than one function. This column is used to categorize and justify the legitimacy of the assessed risks.
Plans for next phase
The VisionThe purpose of the Preliminary Detailed Design Phase is to finalize a design concept and perform tests and simulations to determine its feasibility. This includes prototyping, analysis, simulations, schematics, drawings, flowcharts, a bill of materials, and test plans. Detail will continue to be added to our design via more specific analyses and prototyping in order to answer feasibility questions. Feasibility of our design must be demonstrated and all usage scenarios must be considered.
After feasibility is demonstrated; drawings, schematics, flowcharts and simulations must be created. These will define instructions that will enable fabrication of the elements required to build and operate the entire system. These documents will be inspected at every following design review until the system is assembled and debugged.
Using this information a Bill of Materials will be constructed that will dictate what needs to be purchased and how much everything will cost. Test plans will be conducted and executed in order to determine if engineering requirements are met. Test plans need to specify what data will be collected, instrumentation to be used, test procedures and the personnel who will perform the tests before the test begins. Risk assessment and the project schedule will also be updated during this phase.
Project ScheduleEach phase of MSD is another iteration of building, revising, and enforcing schedules. In the System Design Phase, much of the project was structured off of the required fields on Edge. While this helped serve as a base list of what was required, Edge is not an all-encompassing model of a successful project. The objectives were too vague to the point where the dates were too difficult to estimate with accuracy, and as a result many of us neglected the schedule.
The Subsystem Design Phase project schedule has been crafted in order to eliminate many of these concerns. This schedule's action items were crafted "working backwards" from the end goals of the phase back to where we are now. They were closely based off of the relationships the subsystems have with one another and the actions they work to perform. These actions were also modeled so that there can be as many things working in parallel as possible. In other words, if one part of the project hits a snag, the schedule should allow us to shift our focus without changing the overall plan.
The working Project Schedule document can be found here: Project Plan
After a thorough risk analysis and reevaluation, the schedule also estimates potential setbacks with high profile risks. These risks include the amount of time needed to learn the Computational Fluid Dynamics (CFD) required for our project and preventing the generator from overheating in a waterproof container.