System Design

The following theoretical situation is presented for system design consideration:

 

Two subsystems – 1) Guidance, Navigation & Control [flying correctly] and 2) Payload delivery [spraying correctly] have attempted to save costs by purchasing off-the-shelf hardware, rather than a custom design, resulting in both going over their originally allotted weight budgets. Each team has suggested that the OTHER team reduce weight to compensate.

The UAS will not be able to carry sufficient weight to spread the specified (Marketing has already talked this up to customers) amount of fertilizer over the specified area without cutting into the fuel margin. The safety engineers are uncomfortable with the idea of changing the fuel margin at all.

Analysis

In order to obtain product goals, the system process must meet pre-determined design criteria. It is important to, “Address and link customer needs, requirements and contracts (IBM, 2013).” In this case we have two design teams not wanting to redesign to reduce weight. Considerations must be made for the customer as well as the safety engineers to ensure the aircraft performs as specified, and do so safely, thus managing constraints. Viewing this situation as an “internal customer”, it is essential that what was promised meets with the delivered system. According to Howard Loewen from MicroPilot, “Investing in a standard and efficient requirements-driven design process helps UAV manufacturers bring their product to market swiftly, ensures the development of hight-quality systems, and generates more accurate and timely quotes for their customers (MicroPilot, 2013).”

To resolve this issue all factors must be considered; both teams did not make their products “in house” to save costs, and neither wants to redesign. The priority here is to deliver the best product; so to that end, I would have both teams redesign, and here is why: if both teams redesign at a higher cost now, the end product will be improved on and a proprietary design created. In the long term the initial cost will be absorbed and the overall cost reduced due to using our own superior design. This positively distinguishes the product while exceeding customer demands, which in a given market is usually indication the product will do well. Meanwhile, the weight from both teams will be reduced, leaving the current customer far happier with our product. This “next generation, enhanced” version meets the customer’s needs, as well as solves the design conflict. As part of the “requirements to product”, the system functional requirements take priority; and by meeting and exceeding the requirements the marketability for our design increases and so will our margin. 

In terms of a system design flow chart – the mechanical and electrical specifications need to be revisited, leading to the “improved” design and implementation phase. From there tests can be made leading to the final systems functional test; this time with the weight requirements met and in doing so giving the customer what they want, and making a good move for the company.

References:

Howard Loewen (2014). Requirements-based UAV Design Process Explained – A UAV

manufacturer’s guide (2013). Retrieved from: http://www.micropilot.com/pdf/requirements-based-uav.pdf

IBM (2014). Ten steps to effective requirements management (2013). Requirements

definition and management. Retrieved from: http://public.dhe.ibm.com/common/ssi/ecm/en/raw14059usen/RAW14059USEN. PDF