Soren Sabet Sarvestany

Selecting a Method for Detecting Submersion

​

          During the second half of Praxis II, my teammates and I were tasked with creating an automatic child restraint system for children with intellectual disabilities which would release the children in case of fire or submersion. I was responsible for coming up with a method for detecting submersion. Overall, I consider this piece of engineering design that I did a failure, because I failed to use my process properly. However, success is made of many small failures, so I'm one step closer to mastery over engineering design. 

 

         Here are my process notes for selecting the sensor. 

 

         I first started my notes by doing a google search for submersion detection mechenasisms for vehicles. I came across a patent which mentinoed a specific kind of pressure sensor, so I decided that we could use a pressure sensor as well for our approach. Given the requirements of the RFP, and my own personal values, I chose to design for worst case scenario - that is to say, if there's a chance that someone can get out, get them out. I thouht I had selected the type of sensor, so I decided to search for specific models. I found one, but in the ranges useful to this design, it cost $700.00. This was unfeasible,  so I had to go back to the drawing board (page 5). 

 

       I genereated conceptual approaches, and then an idea based off other reference designs I had come across in my searches. They all failed to meet the requirements in some way or another. After thinking some more on the situation, I decided that sensing water would be the best way to go. I looked at two models for water sensors, chose one from judgement, found another model, then chose from judgement again (which one scored best against the criteria). 

 

While there was some structure to my approach, it was not rigorous enough for me to consider my solution a work of engineering design. There were time constraints, but there was a great deal of procrastination as well. This was however, more successful than a detailed design report I completed (or rather attempted to complete and failed) last term.  While my design work is still not at the level it needs to be, nevertheless I have made improvements. 

 

I believe that had I used formal engineering tools and had started working on the project when I first recieved it, I would have been able to take a more rigorous approach, and I would have actually saved time. I jumped forward with a solution in mind, which to date has been the most difficult habit to break. A lesson learned for next time. 

 

One thing I did do well in this design however, was budgeting time for each detailed design that needed to occur. While these timelines were unrealistic, nevertheless they did impose some structure on my chaotic ways, and from now on, I will incorporate fixed timelines at the beginning of every design project so that I am not rushed to finish the week/night before. 

 

The rest of my work on this structure followed much the same pattern. I was following a process of sorts, but it was not nearly rigorous enough to be considered engineering design. In the end, the results were moderate, indicating that the use of a process would significantly increase the qaulity of my work. ​One thing that I have mastered, however, is breaking down problems into requirements, metrics, constraints, and criteria, as can be seen in my rough work provided above and below. 

 

Selecting an adhesive to connect  the sensors to the body of the vehicle