Weeding Out a Solution

Weeding Out a Solution

Shannon Gibson

Unmanned Systems, Module 2, Assignment 2.4

Embry Riddle Aeronautical University

            As a hypothetical Systems Engineer responsible for coming up with solutions to difficult problems when designing a precision crop-duster, I would first look at what is already available on the market to accomplish such jobs. After careful consideration of what worked and failed for other companies, I would then start with direction for my teams. My two teams are broken up by subsystems; the first being guidance, navigation and control, and the second, the payload delivery.  My description to them is inclusive of an executive summary describing the features that make this system unique, what it is, and what it is intended to do as well as the overall functions (Systems Engineering Fundamentals, 2001). I set them free at this point to start brainstorming ideas.

            It appears during the validate and verify phase of this contract we have discovered some issues such as architectural design which has a direct effect on the physical testing phase which would validate this system (Beals & Bonometti, 2015).  Each teams designs have gone over weight, and the weight cannot be changed for the specific type of UAS we are building, the aerodynamic computations are fact. It appears I had not been clear in my directions in assuring the entire system is built correctly. For the guidance, navigation and control team, I had told them to use off-the-shelf hardware since it is much cheaper than an original design. This has caused their area of this project to be much heavier than expected. I believe I’d research other off-the-shelf products that are lighter and see how precise they are. I’d also see what it would cost to design a product that would fit this need. There are times in the design process that the original budget has to be changed to include unforeseen issues. However, in hindsight, I see that with the weight limitations, I should have asked for more than one plan and will now put more restrictions into the design.

            The second team, which was dedicated to the payload delivery, should look into using a different system than originally planned. Although they are using an off-the-shelf delivery system as I had instructed, they might be able to find another one that is comparable in size but weighs less. I’d also like them to provide me a quote on what it would cost to fabricate what we need.  I am not willing to sacrifice fuel weight, as my safety engineers have advised against this, and out company motto is; “Safety First!” So after my meeting with the safety engineers, I have taken the Technical Resource Budget Tracking computations, which include the part, weight, quantity and mass total, and ensure both teams have it for reference. I believe with the restrictions spelled out, they can make more accurate decisions on parts to add for payloads (Beals & Bonometti, 2015).

            When a particular project moves into the verification process, this is where most issues are discovered. Not only does this verify performance requirements, but also costs and schedules are being met (Systems Engineering Fundamentals, 2001).  After discovering issues, we then go back to the proverbial drawing board sometimes, but fuel, weight and the mission cannot be overlooked.

Beale B., Bonometti. (2015) ESMD Course Material: Fundamentals of Lunar and

       Systems Engineering for Senior Project Teams, with Application to a Lunar

      Excavator. Ch. 2: Systems Engineering- The Systems Design Process. 

System Engineering Fundamentals. (2001). Department of Defense. Systems

Management College. Retrieved from http://ocw.mit.edu/courses/aeronautics- and-astronautics/16-885j-aircraft-systems-engineering-fall-2005/readings/sefguide_01_01.pdf