During the System Level design phase, the MSD team plans to examine and analyze the full BugTorch system. Our approach to the design problem will be to break down the system into smaller subsystems with uniform integration in mind. The team will also go over engineering requirements and customer requirements to see if there need to be any adjustments. Each of the engineering disciplines will research, generate and select design concepts, and devise a plan for testing down the line. The team will choose some concepts and each member will create a benchmark for each subsystem of the main concept. After creating a benchmark we plan on making a systems architecture to breakdown the functional decomposition. We plan on re-evaluating any risks associated with the design concepts generated.

The team was able to accomplish everything that we were planning to get done. We first started by going over our functional decomposition. We wanted to make sure that we were all on the same page and go in-depth with customer and engineering requirements. The team then created a morphological chart with multiple solutions to different functions of the system. The functions that we created solutions for were detecting oil levels, establishing wireless communication, getting fuel up the torches, pumping the fuel to the torches, stabilizing the base, and creating a sealed system. We used those solutions for the functions and created different concepts. We created 6 concepts with the 1st concept being the base concept that we compared the other concepts with. We went over our feasibility for the system and thought of questions on how to solve a problem through prototyping, analysis, and simulation. Next, we chose a specific concept that fits our requirements the best by choosing 3 concepts that we created and comparing them to our first concept which was our worst concept. The team compared the concepts with some criteria that were selected from our customer and engineering requirements. We found that concept 2 was our best choice. With the different solutions from the morphological chart, each member created a new benchmark with those solutions. As a team, we created a systems architecture following the morphological chart which goes in-depth of the major sub-systems and creates relationships between material, energy, and data. We also created a design and flowchart to define a high-level view of the elements of BugTorch. Finally, we reviewed our risk assessment with our modified customer and engineering requirements. 

Below is a Function Tree Decomposition of the BugTorch System. At the top lies the most basic function of the system given by the customer requirements. Going down a level in the tree, the functions here are the "how" to how the top function is to be completed; these are often also other customer requirements. Taking another step down the tree, we once again ask "how" we will achieve the previous function. It is at this level and below that we begin to get into our engineering requirements, as well as the basic functions the team plans to tackle. Once completed, one can take any of the lowest selected branches and as "why is this being done"; this "why" is answered by the above function.

The main requirement given to the team was that the BugTorch system is designed to run indefinitely with little to no human interaction, so this function was placed at the top of the Function Decomposition chart below. As we take a step down the function tree, we ask ourselves "how does the torch system to stay running indefinitely?" From the other customer requirements, the team determined that the most important functions are refueling the system of torches automatically, the ability to withstand the weather and other elements, and have the entire system be overviewed and controlled via an app or central hub. Continuing down the tree, the team broke down each function until we determined the functions that the team should focus on; these are in green on the images below. Since them scope of this team is not to function on app functionality but system functionality, no functions under "Controlled By App" were chosen by the team as a focus for further development.

During initial concept generation, a morphological chart was developed to collect and organize potential solutions to each function the system requires. From these solutions we generated several combinations of concepts that will allow the system to function as required by the Customer Requirements. The designs represent three primary methodologies: maximize performance, minimize costs, and balance cost with performance.

The team utilized the functional decomposition to determine the functions for which to generate concepts. During a brainstorming session the team created 10 concepts for each function, the most reasonable and practical of which are listed in the trimmed down morphological chart below. Viable solution candidates were selected via a Pugh chart and first-order benchmarking.

Morphological Chart

Relevant Files

Using the finalized morphological chart, four main concepts, Concept #1-4, were initially generated and further explored . Method development and detailed descriptions for each individual concept is as follows:

• Concept #1: With the level of knowledge that the team has thus far, Concept #1 seems to be the least ideal concept to solve the problem. For starters, the float switch is an electromechanical device poses a risk of overflowing the system due to the potential for the float switch to get stuck. Based on the benchmarking from Phase 1: Problem Definition, Z-wave kits are very expensive which may cause the team to go over budget. As far as fuel transport goes, the mechanical engineers on the team have suggested against capillary action and using a hand pump due to not meeting the customer requirements of aesthetics and potential problem with transporting enough fuel to the individual torches. To ensure the torches are stabilized and wont leak a combination of burying the base of the torches in the ground and using flex seal was selected. Each of these selections are very likely to cause problems that may miss the customer requirements and break over time.
• Concept #2: The team developed concept #2 with the intention of being realistic and effective. This concept utilizes a differential pressure sensor for fuel level sensing, a WiFi/Bluetooth combination communication system, butterfly valves to direct fuel, and electric pump to pump fuel to different torches. To avoid fuel leaks, O-rings would be used to help seal the fuel lines and the base of the individual torches will be filled with sand, gravel, etc. to prevent any of the torches from falling over. Our team believes this concept meets most if not all of the customer requirements and overcomes several constraints.
• Concept #3: This concept is another realistic selection of solutions. The team selected all different components with the exception of the electric pump from concept #2 in order to consider a variety of components. An Ultrasonic sensor, Zigbee communications, and one way valve were selected for the fuel level sensing, communication, and fuel transportation systems. The team chose to stabilize the individual torches by using yard stakes and prevent leaks in fuel lines by using caulk. Similar to Concept #2 this meets the customer requirements and overcome the majority of design constraints.
• Concept #4: Concept #4 is also a competitive option as it was also approached in the same way as Concept #3. A Laser transmitter, IR communications, pressure sensitive valve, and natural suction are combined together to achieve the main functions of the BugTorch. Magnetizing the base of the torch provided a solution for holding the torch in an upright position although it may not be as effective as we want it to be, but allows for more placement options across a yard. Pipe dope would be used as an adhesive to prevent leaks in fuel lines. Each solution is somewhat reasonable and meets most of the customers requirements and constraints.
  

Each of the concepts are summarized in the table below and evaluated using a Pugh Chart. The objective of the Pugh chart is to compare how each of the solutions rank amongst each other and further described in Section 7.

After a discussion with team mentors and experts and completing some benchmarking for the system level design, some revisions were made to the Morphological Chart and the team added Concept#5 and #6. One of the experts in attendance to the discussion suggested the team look into capacitive sensors to detect the fuel levels. Due to a signed agreement between one of the team members and another company, cause the team to immediately dismiss of a capacitive solution without any further research, but after some advising from experts and mentors, the team added the capacitive sensor back on the Morphological Chart. Another suggestion made was to eliminate the differential pressure sensor to detect the fuel level. Once the team was asked to further elaborate on our intentions for integrating this type of sensor into the system, the team realized that this solution was no longer feasible for our design and would be ignore in when considering alternative design concepts for the torch. Additionally, during the benchmarking process which will be discussed further in a Section 7, irrigation products were suggested to purchase based on search history and placed on the morphological chart as another feasible design solution.

After the Morphological chart had been updated, the team added two additional concepts that compared to Concept #2. The differential pressure sensor would be replaced by an ultrasonic sensor in Concept #5 and a capacitive sensor in Concept #6. This was done since Concept #2 initially ranked #1 in the Pugh Chart.

Relevant Files

As of the time of the Phase II Design Review, the team has just received the package from the customer containing concept torch designs and other parts to be used in designing the system. Since the team was previously unable to work with these materials, we were unable to move forward with meaningful prototyping until now.

One of the goals put forth is that the cost per torch should not go above $25 for additional parts. Based of a torch concept that utilizes a Bluetooth/WIFI combination for data transfer, solenoid valve for fluid control, solar/rechargeable batteries for power, ultrasonic/capacitance for fuel level monitoring, and o-rings for sealant runs these prices as a preliminary check:

• Wireless Connector - $5-$25
• Solenoid Valve - $3-$100
• Power Source - $10-$30
• Fuel Monitor - $4-$20
• Sealant - ~$0.05 per o-ring

Minimum total price per torch - ~$22

If the team is able to source all necessary parts at minimum, we should be able to keep the price per torch below $25.

Timewise, the customer hopes to make the BugTorch system available on the market by early-mid 2021. As MSD I ends in May, the team is unable to fully scope out all phases of the project, but in terms of goals and deadlines set by the project the team is on, if not ahead of schedule. The Gantt Chart with tasks from the first two phases as well as overall MSD 1 tasks completed is shown below.

To determine the teams system level design several steps had to be taken.  To design this system, first, a functional decomposition was completed to help identify what this product should do. Then, a morph chart was created in order to identify function based solutions.  Several concepts were pulled out of the morphological analysis.  Some of these concepts had more merit than others but to make sure each was judged fairly the team employed the use of a Pugh chart to aid in the overall concept selection.  This chart features a concatenated list of each of the teams individual selection criteria which were then divided into customer and engineering requirement categories.  Concept one was designed to be flawed and used as the datum from which other concepts could be compared.  Each criteria was given an equal weight to keep the chart simple.  To determine the viability of each concept they were given one of three values : "-, 0, +".  The minus indicated the concept was worse than the control in said criteria, zero showed equality to the control and plus was reserved for those that had better traits than the control.  Whichever concept held the highest positive score would then become the teams' center of focus for designing the system. Based on the charts below three concepts became the leading design ideas. During the next phase this is where our focus will be.

                                        

Relevant Files

Purpose

In order to find the best possible pieces to this BugTorch puzzle the team once again bench-marked.  To set this version apart from that of phase one we employed some new practices.  Once we had achieved a set of feasible concepts we set up a meeting with some experts to discus the fine details and identify some possible vendors. Using this new information in collaboration with what we had already learned from previous analysis like our functional decomposition and morphological chart we had enough to go off of and began some advanced bench-marking.  Below are several charts that detail each portion of this project deemed in need of a solution.  As we are contained by time the best possible solutions currently appear as readily available products that can be made compatible to achieve the overall goal.  Using these products will likely save sometime when it comes to debugging as starting from scratch usually takes well over the time frame we have.

Tiki Torch General Information

This chart shows the most basic characteristics of the system we are looking to map out. To adhere to most of the customer requirements these characteristics should be maintained although by using all readily available parts the cost per torch will likely exceed the ideal price.  It should be noted that infinite time and capacity do not mean they can function forever but rather in comparison to a typical torch they last much longer without need for maintenance.

Oil Level Sensing (General Ideas)

In order to actively detect the amount of oil remaining in a given torch a sensor commonly used for such is the simplest and best solution to this problem.   The below chart features a general list of sensors that the team and our experts decided would be best for achieving our goal of accurately measuring the oil level in not only the torches themselves but also the central tank that stores the bulk of the consumers oil reserves.

Oil Level Sensing (Sensors)

The bench-marking below shows specific sensors the team plans to explore in future prototypes of the system.  Some of these sensors may be too expensive or large to achieve the overall goal but looking into each of these will give the team a proper idea of what to expect in designing this system as well as future ones like it.  This insight will be invaluable for the debugging process in MSDII.

Individual Torch Power

One of the more difficult tasks we have in meeting our customers requirements is providing sustainable power to the torches without running ground wires.  This is one of the most essential goals to meet as not doing so will make the installation process complicated and remove appeal from the marketable system.  The team and our experts came to the conclusions below which outline mainly solar power as the effective solution.

Wireless Connection

Once again to avoid the use of ground wires the next simplest solution to monitoring the torch system is through wireless connections.  Identified below are several options that outline the possible wireless connections that may be used to achieve this requirement.  Designing our own board may be more effective in the long run but in order to have some tangible advancements in the term it is easier to adapt development boards to our needs.

Fuel Maneuverability

Controlling the flow of fuel in this system is very important.  If the pump system ran without check there would be overflow which could be very dangerous considering we are dealing with a flammable substance.  There are two ways the team identified to make sure the correct amount of fuel gets to the right place, without overflow. Much like a gas station pump we plan to use a mechanical valve to halt the flow of fuel in already full torches.  To move the fuel is another issue.  We need a pump that has a very slow flow rate because on average a single torch only burns one to two ounces of fuel per hour.  But, the pump needs to be able to give each torch fuel so it has to be able to apply a lot of pressure.  These two constraints make the pump very unique.  Below are some possible solutions although tests should be run on each to make sure they can achieve these standards.

Stabilizing the System

As stated by the customer this system will need to stand up to the test of time.  Our main concern is that the torches may fall over in acclimate weather causing a slew of issues for the consumer. To make sure this does not happen these simple solutions have been bench-marked.  Provided that these are readily available they will each very easily achieve this goal.

Sealing the System

In the event that the system happens upon damage or falls over we want to make sure everything is sealed properly to avoid unnecessary spills.  There are hundreds of ways to stop a pipe or tank from leaking but the team felt the options below would have the highest benefit to that goal.

Relevant Files

From the Functional Decomposition diagram, the team developed a better understanding of the major subsystems of the BugTorch project. Two major subsystems of the project are derived from the need to refuel the individual torches automatically: fuel transport and fuel level sensing subsystem. The app in itself is a separate sub-system which will be integrated with communicative electronics after the other subsystems are functioning properly. The transfer diagram below maps out how energy, materials, and information travel through these necessary subsystems.

One of the end goals for the BugTorch is to send citronella oil across a space and to light a flame indefinitely on each tiki torch. The blue boxes in the transfer diagram reflect the citronella oil on the level being converted to an open flame on the right. In order to make the conversion, the citronella oil supplied by the user in the central fuel tank must make its way to a pump where pressure in the tubes will force the oil across the yard to the designated torches. Valves will assist transporting the fuel to an individual fuel reservoir in the tiki torch where it will be absorbed by the wick and burn.

Another major source that needs to transform throughout the system's performance is energy. Energy is sourced from two different places in order to avoid unnecessary wires which is a customer constraint. One source is used to power the pump and stems from a 120V supply. This most likely will come from an outdoor receptacle near a home or other facility. The energy output from the pump results in mechanical and thermal energy. The other source of energy used in the system is for microcontrollers. There is one main microcontroller in the system refer to as the Gateway. The energy first is sourced and then stored. Energy is then disbursed between the receiver and the transmitter so it can communicate with the other microcontrollers. Any remaining energy just remains in storage. One difficulty that the team will have to overcome is harnessing power from an alternate source that requires little to no user interface with the system and aesthetic changes. Energy will also need to be transferred throughout the individual torches. Energy stored near the microcontrollers of the individual torches will need to be distributed to a transmitter and potentially a sensor. Any resulting energy, again, will remain in storage to use as electricity or be converted to thermal energy.

Collecting and transferring data throughout the system is extremely important in order for the system to function the way the client intends it to. First data is collected by the fuel sensor analogously and converted into digital. The data is then stored and then transmitted in the event that the measurement taken is considered "low." The receiver of the gateway intercepts the data, stores it, then transmits it to the app interface so the user of the system can view the diagnostic information.

Most processes of transporting material, energy, or data happen simultaneously but will majorly be impacted by the torch fuel level reading. for instance, Data will only be transmitted to the gateway only if the value from the level sensor is considered to be "low." The design team also has been considering that the fuel should be under constant pressure and only when the fuel level is "low" will a valve allow fuel to enter the torch reservoir for the individual torch. When design the team needs to ensure that the flow rate of the oil isn't too high when it fills the reservoir, otherwise it may splash and damage the electronics inside as well as potentially overflow the reservoir.

The System Level Flowchart provides a top-level view of the components required in the construction and operation of the BugTorch automatic refueling system. The system functions by using a liquid level sensor to determine when a torch is running low on citronella oil and open a valve in the torch stand to allow more oil to flow into each torch's local storage tank. Operation metrics and statuses including torch fuel tank levels and central fuel tank level are reported to the operator via a smartphone application. The operator has access to the central fuel tank and the smartphone application, the rest of the process is entirely automated.

This document describes the basic process of the system operation, and may change during preliminary prototyping if unforeseen problems arise.

Relevant Files

The team re-evaluated our risk management and decided that even though there were slight modifications to our customer and engineering requirements, we decided there doesn't need to be any changes to the risk management. The main scope of the project stayed the same as when we created the risk assessment and thought that no major changes needed to be made. The different types of risk that we have still qualify for the scope of the project along with the customer and engineering requirements. The types of risk that were considered were environmental, safety, resource-related, social, technical, and. resource. Along with the type of risk it is, we established the risk item, the effect of that risk item, and the cause of that risk were also included. Next, we valued the likelihood, severity, and importance. This worked by choosing a value for likelihood by estimating how likely that risk would happen and the severity of that risk. Then the importance was measured by multiplying the likelihood and the severity. After measuring the importance of the risk each member thought of a way to minimize that risk and who would be responsible for that action. The most important risk that the team needs to consider is the weather hazard as the torches need to withstand the different weather conditions and we needed to make sure the torches sell so a cheap and good lucking torch is needed. The second most important risk to consider is that we have limited knowledge of app development and fluids which could potential delay us from thinking of solutions. Some other important risks that we considered were to make sure the torch oil doesn't leak or spill, making sure that we can get reliance on custom-built components, and Covid-19 could slow down the progress of our project. We plan on keeping a look at our risk assessment to see if any modifications need to be done on it as we move along with our project. We also created a Risk Burndown Chart for the phases so far. The Burnout Chart will be updated as the phases go on.

Relevant Files

Pre-read

Presentation

By next phase we plan to have settled on one specific design for this system.  This design will have a detailed flowchart for each of its sub-systems.  To further expand on the design we will develop technical documentation like CAD drawings and electrical simulations if need be.

Gantt Chart

Individual Three Week Plans