ABSTRACT
Commercial off the Shelf (COTS) parts have not yet proven to have a level of airworthiness (i.e., safety) to allow for the commercial introduction and operation of unmanned aircraft systems (UAS) within the National Airspace System (NAS). When the average person is asked to describe a drone, or unmanned aerial vehicle (UAV), the most common description given, is that used by the military, one that performs reconnaissance and weapons delivery missions, the Predator UAS. These and similar military UAVs, large and small, are built to satisfy a military mission, most not all, are built to military specifications. These UAVs are flying their missions over or in military air space and in foreign countries. None of these UASs are manufactured by an approved quality system, with approved parts or processes, nor are they required to be maintained by approved mechanics or repairman.
Here is the problem; the public perception is these systems can be introduced into the NAS and flown for commercial purposes (profitability) without having to implement any further safeguards or quality standards into the manufacturing process or the continued airworthiness of the system. This perception is highly flawed while the systems may not have changed, flying in the NAS has. Constant communication is required with ATC and with surrounding aircraft that are now also flying within the vicinity of the UAV, aircraft that they now need to see-n-avoid. The software, flight controls and data arrays that allow for the control of the UAS to accomplish these critical see-n-avoid maneuvers need to be from an approved and quality source. The UAS programs cannot be allowed to have unapproved parts introduced into the UAS system from a COTS supplier without the benefit of an approved quality process. Otherwise, this clearly is a breakdown in the manufacturing quality system and a breakdown in continued airworthiness.
The intent of this research, is to show through case analysis, how the implementation of Regulatory requirements in approving the manufacturing quality system and associated processes, or acceptance of the quality standards for those manufacturers that are accredited IS09001 /AS9100 will assure the airworthiness of proposed UAS for commercial use into the NAS.
Monday, November 4, 2013
Weeding out a Solution (2.5)
UAS-Crop-Dusting Design, Revision: B
Scenario
An unmanned aircraft system (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.
Response
As the Systems Engineer, I would meet with the Program Manager to inform them of the situation. I would point out that we are still in the design phase of the project and it might be possible to renegotiate the requirements with the customer. A renegotiation of the requirements may not be out of the question. Our priorities should not change, we must effectively define and manage requirements to meet our customer needs, while managing compliance and staying on schedule and within budget (IBM, 2013). As might have already been the case, a poorly defined requirement can have a negative impact; it can have a domino effect that could potentially lead to time-consuming rework, inadequate deliveries or budget overruns (IBM, 2013). If the customer is unwilling to flex on the requirements then the following actions would most likely have to put in place.
Actions
The fundamental goal of Systems Engineering (SE) is problem solving (Marvel, 2006). The general problem solving process consists of three activities:
1. The “problem system” which contains all the customer needs and requirements (Marvel, 2006). It produces an acceptable base line that has been validated with the customer and contains the amount of influence the customer will have over the problem solution (Marvel, 2006).
2. The “project system” which includes all of the development, design and production of the solution to the problem (Marvel, 2006).
3. The “Delivered system” includes the testing, integration, verification, certification and delivery of the working solution. Through all this effort, the SE is only successful if the customer is smiling (Marvel, 2006)
A meeting with the overall UAS design team to explain the circumstance(s) involved regarding the overweight issues, the payload delivery requirements and fuel margin safety concerns. It would be made clear at this meeting how much the other two systems were overweight and collectively all subsystems/teams would need to figure out a way to trim enough weight so as not to affect the originally agreed upon customer requirement(s) or that design changes would need to be made that could take into account the increased weight without affecting fuel margins, the latter of which would not be an acceptable resolution. Since the design is essentially being re-evaluated as a new process, a block diagram will be implemented as it is a useful tool both in designing new processes and in improving existing processes (Block, 1998). A block diagram is a specialized, high-level type of flowchart. Its highly structured form presents a quick overview of major process steps and key process participants, as well as the relationships and interfaces involved (Block, 1998). By identifying the problem, the process and the participants on a clearly outlined/labeled flow diagram, verification that the revised process/requirement reflects the current process operation can be accomplished (Block, 1998). The process review teams collectively have discovered that all subsystems can reduce enough weight to overcome the amount that was incurred by the Guidance, Navigation & Control and Payload systems. The overall effect of savings will now effectively increase the payload for fertilizer dispersal, without affecting fuel safety margins.
References
IBM Corporation, Software Group. (2013). Ten steps to better requirements management. Somers, NY:
Author. Retrieved from http://public.dhe.ibm.com/common/ssi/ecm/en/raw14059usen/RAW14059USEN.PDF
Marvel, O.E. (2006). Foundations of systems engineering problem solving. Monterey, CA: Naval
Postgraduate School. Retrieved from International Council on Systems Engineering website: http://www.incose.org/sfbac/2006events/060613ProblemSolving.pdf
Block Diagram. (n.d.). Retrieved from Concordia University website:
http://web2.concordia.ca/Quality/tools/3blockdiagram.pdf
Scenario
An unmanned aircraft system (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.
Response
As the Systems Engineer, I would meet with the Program Manager to inform them of the situation. I would point out that we are still in the design phase of the project and it might be possible to renegotiate the requirements with the customer. A renegotiation of the requirements may not be out of the question. Our priorities should not change, we must effectively define and manage requirements to meet our customer needs, while managing compliance and staying on schedule and within budget (IBM, 2013). As might have already been the case, a poorly defined requirement can have a negative impact; it can have a domino effect that could potentially lead to time-consuming rework, inadequate deliveries or budget overruns (IBM, 2013). If the customer is unwilling to flex on the requirements then the following actions would most likely have to put in place.
Actions
The fundamental goal of Systems Engineering (SE) is problem solving (Marvel, 2006). The general problem solving process consists of three activities:
1. The “problem system” which contains all the customer needs and requirements (Marvel, 2006). It produces an acceptable base line that has been validated with the customer and contains the amount of influence the customer will have over the problem solution (Marvel, 2006).
2. The “project system” which includes all of the development, design and production of the solution to the problem (Marvel, 2006).
3. The “Delivered system” includes the testing, integration, verification, certification and delivery of the working solution. Through all this effort, the SE is only successful if the customer is smiling (Marvel, 2006)
A meeting with the overall UAS design team to explain the circumstance(s) involved regarding the overweight issues, the payload delivery requirements and fuel margin safety concerns. It would be made clear at this meeting how much the other two systems were overweight and collectively all subsystems/teams would need to figure out a way to trim enough weight so as not to affect the originally agreed upon customer requirement(s) or that design changes would need to be made that could take into account the increased weight without affecting fuel margins, the latter of which would not be an acceptable resolution. Since the design is essentially being re-evaluated as a new process, a block diagram will be implemented as it is a useful tool both in designing new processes and in improving existing processes (Block, 1998). A block diagram is a specialized, high-level type of flowchart. Its highly structured form presents a quick overview of major process steps and key process participants, as well as the relationships and interfaces involved (Block, 1998). By identifying the problem, the process and the participants on a clearly outlined/labeled flow diagram, verification that the revised process/requirement reflects the current process operation can be accomplished (Block, 1998). The process review teams collectively have discovered that all subsystems can reduce enough weight to overcome the amount that was incurred by the Guidance, Navigation & Control and Payload systems. The overall effect of savings will now effectively increase the payload for fertilizer dispersal, without affecting fuel safety margins.
References
IBM Corporation, Software Group. (2013). Ten steps to better requirements management. Somers, NY:
Author. Retrieved from http://public.dhe.ibm.com/common/ssi/ecm/en/raw14059usen/RAW14059USEN.PDF
Marvel, O.E. (2006). Foundations of systems engineering problem solving. Monterey, CA: Naval
Postgraduate School. Retrieved from International Council on Systems Engineering website: http://www.incose.org/sfbac/2006events/060613ProblemSolving.pdf
Block Diagram. (n.d.). Retrieved from Concordia University website:
http://web2.concordia.ca/Quality/tools/3blockdiagram.pdf
Subscribe to:
Posts (Atom)