Finding the Solution As A Systems Engineer in UAV Design

         This research document is a systems engineer process response to a precision crop-dusting unmanned aerial vehicle (UAV) design issue. Mid-way through the build, the realization that the UAV would be overweight was noticed and three factors should be noted on this account: 1) two subsystems were off-the-shelf hardware which resulted in the overweight UAV 2) max payload has been established to the external customer so change in this area is restricted and 3) safety engineers prefer the fuel margin to remain as originally designed so change in this area is also restricted. Maintaining these factors and their restrictions during the problem solving process, the role of the engineer will be examined and represented by reflecting external customer interaction, development team communications, decision making on requirements, and the final decision of forward progress getting the UAV to the field. The document concludes with a summation of the process and path chosen in order to get the UAV through the build process, meeting requirements, and stepping through the validation/verification process.   

            The UAV is midway through the build and a problem has developed, the UAV is overweight. Understanding the overweight issue was caused by two departments off-the-shelf hardware being out of specification, the decision needs to be made for the location of where the weight reduction can occur while meeting the requirements and being conscious of cost. Known limitations include preferences from the safety engineers about reducing the fuel margin, two off-the-shelf sub-systems prefer not to be adjusted, and the max payload has already been established so reduction therefore is unfavorable.

            A quick analysis of the issue triggers a few locations for weight reduction of the system and those include reduction in the remaining half of the build, airframe reduction, increasing lift, and forcing modifications for one or both of the two sub-systems that caused the UAV to go out of specifications.  Assuming of course, that these potential reduction factors were available for consideration and the development team could provide some data on how implementing these reductions would affect cost, time, and the requirements the situation can be presented to the stockholders and customer. A meeting with the external customer would be required to communicate the issue and the purposed options for the fix and they should be presented to the customer in the form of high-level requirements to eliminate technical level variances that limit to complete understanding of the requirements (Loewen, 2013). Examples of the high-level nonfunctional requirements could include 1) airframe built using composite material and 2) payload delivery will weigh no more than X lbs by eliminating overbuild aspects.

            The systems engineer’s responsibility to maintaining the bridge between the requirements and the business or customers needs is imperative (Tavassoli, 2008). The requirements are continuously changing during the design and development process. So presenting the new potential requirements is not as problematic as the customer and the design team actually agreeing on the decision. Assuming in this instance a decision is difficult to acquire, as the systems engineer I would strongly suggest the addition of a composite airframe. For arguments sake, this document is written with the assumption the airframe was not originally designed with composite material. The reason behind the composite decision is the new airframe design would allow for the potential of an increase in payload for the current UAV, which would benefit the customer, and by utilizing a the new material for future designs to enhance the design companies future projects.  Adjusting the off-the-shelf hardware risks potentially result the hardware malfunctioning and strictly increasing lift would require a new airframe design anyway. The priorities of a systems engineer in this situation would be to have a cost and time efficient decision made that coincides with the customers use cases but also aligns with the design teams capability.

            While the composite airframe is being created, preemptive validation tests can be done on portions as they are completed such as weight tests and hull dimensions. Once the full airframe is complete, the verification tests can begin to confirm that all the high-level requirements as well as the low-level requirements. Regression testing on the off-the-shelf hardware when officially apart of the system would also need to take place in order to validate the new UAV and the system. Once validation is confirmed by the testers as well as the stockholders and with the approval of the systems engineer, the product is released to the customer for field use.

            In summation, the continuous communication between the systems engineer and the customer as well as the development team is pertinent to the efficiency and the success of the build. Being able to speak the use case language of the customer and the technical language of the development team is a skill that the engineers posses. Keeping the requirement document alive and fluid while design and development are in progress is important because a single attempt at the requirements can prove to be inefficient and costly (Tavassoli, 2008). Decisions also often fall on the systems engineer and experience and expertise often assist with those decisions. Validation and verification testing are the last stage of the process where the goal is to confirm that the system works and expected and meets the requirements. Systems engineers are deep in the process from the conception of the project to the moment the product goes to the field and their importance is reflected throughout.  

References

Loewen, H. (2013). Requirements-based UAV Design Process Explained. MicroPilot. Retrieved from https://www.micropilot.com/pdf/requirements-based-uav.pdf

Tavassoli, D. (2009). Ten steps to better requirements management. International Business Machines (IBM) Corp. Retrieved from ftp://public.dhe.ibm.com/software /uk/pdf/RAW14059-USEN-00-1.pdf