The BugTorch system is an environmentally friendly network of user controlled, self-filling tiki torches that repel outdoor insects while providing 8 hours of consistent lighting. This project aims to accomplish the following: develop an aesthetically pleasing, low cost, scalable torch system that can be monitored from an app or tablet.  Users will assume control over the system through the application which will actively display torch oil levels.  Once the system identifies a “low” fuel level a central controller will begin refilling the individual torch.  This process should repeat for the desired time of eight hours.  The goal for the design team will be to successfully integrate all pieces of the system.  This includes the fuel line connections and pump subsystem, oil level sensor, micro-controller, and smart device app in a four to eight tiki torch prototype which can be scaled up accordingly.

It is essential that the design and prototype remains consistent with the current US patent on file (10842146 B1) at the very least, but new intellectual property has the potential to elevate the design to fit the needs of the stakeholders. Schematics from the current patent on file are shown below. Specific materials for torch heads must be used to maintain grant funding.

                          

In this phase, the team planned on:

• Meeting with the customer in order to better identify the given requests
• Determining what engineering requirements (ERs) cover the customer requests (CRs)
• Deciding on roles within the team
• Brainstorming our largest design roadblocks
• Creating a phase slideshow to review accomplishments

In this phase, the team accomplished:

• Holding a meeting with the customer to solidify the importance of each CR
• Devising multiple ERs that apply to each CR
• Benchmarked certain processes pertaining to fluid control and management
• Generating multiple use cases for the BugTorch system 
• Population of the Problem Definition page on Confluence

Part of the preliminary brainstorming process involved the development of use cases. These use cases describe different scenarios involving the BugTorch system anywhere from the start of the design process to final system installation. Three different use cases were developed by the design team to consider a new perspective when generating design solutions as well as pinpoint potential risks associated with the case. Each case is described below:

By the end of this project the customer should expect to get:

• All design documents
• Working prototype

The team is expected to complete all task above along with:

• Technical Paper
• Poster

Some other deliverables, if needed:

• Lightning talk video
• Installation instructions and video
• Customer research and documentation
• IP considerations by mutual agreement and legal review, to include invention disclosure

The Bug Torch system is intended for use in residential areas, so excess noise needs to be minimized and the system needs to be aesthetically pleasing. For easy installation underground wires cannot be used and fuel has to be stored in a central location. To simplify operation, the system needs an automatic torch ignition functionality and support for a smartphone or tablet application to allow remote control. Optimal function of the system requires the stored fuel reserve to allow at least eight hours of automatic function without assistance while monitoring fuel levels in each torch. The system needs to have the capacity to add up to 20 torches for large gathering areas, though the ability to add more is preferable. The refilling system needs to ensure all torches are filled evenly to prevent any torch from running out. The system is intended to remain installed throughout the year and as such needs to be resistant to adverse weather conditions and require minimal maintenance.

Relevant Files

Engineering requirements determine a way for the MSD team to assess if the customer needs are met using both quantitative and qualitative metrics. Below there are several benchmarking tables that each highlight important specification for different technologies that are being considered for implementation in different subsystems.

Based upon the teams preliminary analysis these areas were bench-marked.

Relevant Files

The team has identified the above table as the current constraints to the design.  There are two areas of study here.  The first is immeasurable in that there is simply a minimum requirement to be met.  This area includes things like residential regulations and those of higher level engineering societies as well as patent linearity and a general lack of experience. The other section is measurable.  For example, the amount of time and money spent completing this project can be tracked easily.  The power of the system can be simulated and tested in prototype.  The same goes for measuring something like the oil level in the torches.

As for other considerations this project can be mapped to several positive applications.  Taking a look at the economic impact the system may have requires examining the total price of the system and the overall ability to manufacture it.  The constraint here comes from a customer requirement of maintaining a total cost per torch of twenty-five dollars or less.  This price would make the system readily available to multiple social classes.  Another perspective to examine is the environmental impact.  This system will use citronella oil which by EPA standards is considered non-harmful to residential environments.  As for sustainability the system will likely be made from long lasting materials and be powered by solar energy making this a long lasting addition to outdoor entertainment.  One goal is to achieve some form of engineering standard that can be recognized by an organization like IEEE.

Relevant Files

The table shown below showcases the link between the customer requirements(CRs) and engineering requirements(ERs). To the left of the table lists out all of the CRs discussed with the primary customer. At the top of the table are the current ERs which will be used to assess if the CRs have been met. ERs may be added to the table as the design team progresses through the design process.

The team focused on mapping each of the CRs to at least one ER in order to qualitatively or quantitatively shown the CRs have been achieved. Some ERs were directly inspired from the customer interview and connect to multiple customer requirements as shown by the X's in the table. The quantity of X's do not reflect the importance of a CR or ER but rather the connection between the elements. The team tried to considered different perspectives and requirements for each subsystems to accurately assess the CRs further down the line.

At this stage of the project, there have not yet been any major trade offs. The few trade-offs that occurred stemmed from the language used in ERs. The design team wanted to be specific in describing the ERs while not being too specific. Potential ER conflicts and failures modes discovered during the development of the House of Quality table are listed below.

Possible Conflicts

1. Power Vs. Wireless.
   
   1. This is a dilemma caused by the customer requirement of remaining wireless.  It will be difficult to power any device situated in the torch without a wire.  One solution is a solar panel and battery but this would involve changing the torch aesthetic creating another conflict.
2. No External Modification Vs. Fitting Sensors in Torches.
   1. The torch body is very small.  Therefore, fixing a sensor inside the torch alongside the other internal components may be nearly impossible.
3. Metal Torch Body Vs. Bluetooth/Z-wave.
   
   1. The metal body of the torch has the potential to act like a Faraday cage and could severely limit wireless communications. An antennae could solve this issue but may be costly and difficult to hide.

Relevant Files

Sources

Problem Definition Review Notes

In the next phase the team will be working on designing the system level functions of the project.  To achieve this goal a few important objectives should be met including:

• Compilation of functional decomposition flowcharts.
• Structuring a comprehensive morphological chart.
• Picking two feasible system designs from the morph chart and bench-marking them accordingly.
• developing a test plan to accommodate the various engineering requirements of the project.
• uploading and updating the information needed to pass the next phase on confluence.

Relevant Files

The team has organized a set of individual three week plans and a detailed Gantt chart linked here: