Scenario
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.
Write a response describing how you, as the Systems Engineer, would
go about resolving this issue. Use your imagination, and try to capture what
you would really do. Take into account and express in your writing the things
you’ve learned so far in this module: 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?
Solution
In regards to the scenario above,
there are multiple responsibilities that I would have as the systems engineer
responsible for resolving the issue between the guidance, navigation and
control team and the payload delivery team. The three overarching roles that an
ideal systems engineer must assume are; intermediary between design teams, the
decision maker when conflicts occur between teams’ and final authority on
whether a is ready to hand off to the costumer. Within each role, I must also
examine and understand the requirements set forth by the customer, provide
clear and concise communication between design teams, and be prepared to take
charge of the project as a whole to ensure its on time, well designed, and
meets expectations (Embry Riddle Aeronautical University, 2015). Below I have outlined how I would
resolve to current issue by analyzing and describing how I would accomplish
each one of my three overarching responsibilities.
Systems
Engineer as an Intermediary
As the systems engineer I would recognize that the two
design teams that are arguing are responsible for very different systems that
require very unique technical knowledge to accomplish. The skills associated
with developing guidance and navigation are very technical with much of the
detail in sensors and computer coding. The payload delivery design team would
be more focused on the mechanical aspect of the project. The Payload design
team may also feel a certain level of self-proclaimed importance due to the
fact that the entire project is essentially built to perform the single task
that they are reasonable for. It’s this understanding of not only the requirements
and project, but it’s the interpersonal skills and understanding of the design
teams as people that could help me perform my duties as an intermediary. I
would work to educate both design teams as to how important the other teams
contribution to the total project is and perhaps encourage them to take a
minute and put themselves in the others shoes. Here we could pass ideas between
the design teams and ensure both teams have a good understanding of how far
they should be willing to flex in order to ensure the project completion stays
the main focus. Perhaps this alone would invigorate one or both teams to seek
smart and cost effective solutions to reduce weight from their respective
components.
Systems
Engineer as the Decision Maker
If acting as the
intermediary failed to result in a constructive resolution to the overweight
problem between both design teams, I would have to utilize the decision making responsibility
of my job to seek resolution to the conflict. In general, I would have to take
a very detailed look at both the requirements and the costs associated with
each design teams’ components and determine for the teams how they would
resolve the conflict. I would have to have enough technically knowledge of both
subsystems in order to make smart and well educated decisions (System engineer vs. system
architect, 2011, p. 73 sec.). Perhaps I could utilize my knowledge of the
system as a whole to help both design teams work a creative solution that would
lower the weight of both components. Perhaps the off the shelf systems that
both teams used contained their own power control unit, but the design team
associated with power control told me that they would be able to handle the
power control requirements of each of the subsystems in question and both teams
would be able to reduce the weight of the system through this efficiency. I
would tell both teams to integrate into the main power control unit and then
the conflict would be resolved. This example not only demonstrates my role as
decision maker, but also reinforces my role as intermediary between design
teams at the same time.
Systems
Engineer as the Final Authority
In regards to the
above scenario, my role as final authority ties into all other aspects of my
job as systems engineer due to the fact that my adherence to satisfying the
original requirements is what sparked the conflict in the first place. If I did
not take my role as the final authority seriously, I may have aloud to teams to
continue forward with their current and produce a final product that was not
capable of what it was advertised to do. This would hinder both current and
future sales potential.
The above
responsibilities often run concurrently and continually while performing duties
as a systems engineer therefore it’s essential to continually relook the requirements
and current technology in order to stay one step ahead of the design process.
Looking at the iterative design process, the systems engineer is in the best
position to fuse future technologies into the project for the next version of
the system. Perhaps in the future, a light weight navigation computer may
become cheaper and therefore relieve the weight issue. On the other hand, I
could reduce the allowed weight of both design teams and increase the payload capability
which could make our product better than the competition. Another option would
be to keep weight requirements and payload capacity the same while decreasing
system cost for future iterations. A systems engineer should balance cost,
performance, and capability when looking forward to future versions of systems
in order to ensure relevancy in the current and future markets (Dahmann, n.d).
References
Dahmann,
J. (n.d.). A Model of Systems Engineering in a System of Systems Context.
Retrieved September 19, 2016, from
http://www.acq.osd.mil/se/docs/2008-04-04_CSER-Paper_Dahmann-etal-SoS.pdf
Embry
Riddle Aeronautical University. (2015). ASCI-530 unmanned systems: Module 2 -
Global system design concepts, requirements and specification overview.
System
engineer vs. system architect (2011). [Motion Picture]. Retrieved Sept 19,
2016, from
https://www.youtube.com/watch?v=wWnESjf4ajQ
No comments:
Post a Comment