A UAS is to be designed for precision crop-dusting. In the middle of the design process, the system is found to be overweight.
- 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.
What are your considerations? What are your priorities? What do you think about the future prospects for the “next generation, enhanced” version of the system as a result of your approach?
Having
never fulfilled the systems engineering position, I’m unsure what kind of power
or authority the systems engineer would possess. However, from my experience in
the military, I would take a very forward and up-front approach to solving the
problem. I would delegate and hold people accountable to their task
responsibility as well as their team responsibility.
I
believe it’s clear in this scenario that a few bottom-line system requirements
have been established. These bottom-line requirements must be met in order to
satisfy the needs of the customer, and ultimately win the contract. In other
words, keep your eye on the finish line (Ryen, 2008). The first requirement is
the amount of fertilizer that will be spread and the other is the amount of
fuel that will be carried. Without satisfying the fertilizer issue, there won’t
be any customers, thus nullifying the contract. The fuel issue is an issue of
safety. In aviation, safety is paramount to the successful operation of any
aircraft. Without optimal safety practices, laws, public perception, and
customer support will be impossible to satisfy. Therefore, the amount of
fertilizer cannot be reduced and the amount of fuel cannot be reduced. Those
are the higher priorities. Logically, that means that either the Guidance,
Navigation, and Control (GNC) team or the Payload Delivery team must change
their design to accommodate for the added weight.
As
the systems engineer I would tell the GNC team and the Payload Delivery team to
both reduce weight, in whatever way possible. Of course, I would offer
solutions and suggestions, but I will never do another’s job for them simply
because they are too stubborn to compromise. Some of those solutions might be
to use lighter material in the structures of each system. Because they were
using off-the-shelf products are they fully utilizing all structural weight
saving options? For example, could the GNC team use aluminum? Might the Payload
Delivery team be able to use a polyester impregnated fiberglass as the tank for
the payload, thus reducing weight? Both options might increase cost; however,
it’s unlikely the cost would be so significant as to put the project
over-budget. Ultimately, one or both of the teams must give, even if it means
slightly increased cost and slightly lowering profit margins. At the end of the
day, securing the customer’s satisfaction is the ultimate priority – without it,
nobody gets paid.
In
the processes for future aircraft, I would begin by establishing the
expectation noted above. Yet, the blame cannot completely fall with the teams for
this mid-design hiccup. Ultimately boundaries and limitations on weight,
design, and function should have been clearly stated by the systems engineer before
the teams embarked on accomplishing their tasks. For example, in a future
project perhaps the GNC team would be given a maximum weight of 300 pounds and
the Payload Delivery team a max weight of 100 pounds. With these thresholds
established, no time, effort, and money would be wasted as energies are kept
within the bounds established by the limitations. For future projects, that
process of clearly defining limitations would effectively reduce or even
eliminate collisions between different teams in designing the system.
Reference
Ryen,
E. (2008, March 1). Overview of the
system engineering process. Retrieved from https://www.dot.nd.gov/divisions/maintenance/docs/OverviewOfSEA.pdf
No comments:
Post a Comment