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
Monday, October 28, 2013
History of UAS (1.6)
The Evolution of UAS Design
Militarily speaking, mission requirements for Unmanned Aerial Systems (UAS) have not changed much over the past 60 years. Unmanned Aerial Vehicles (UAV) of the 1950s were tasked to perform reconnaissance and deliver some form of weaponry much like they do today. The differences lie only in how the technological advancements of the past 60 years have set the systems and the payloads apart. It would be a fair assessment that not one particular program has evolved over all these years to become the stand alone system that it is today. Advancements in technology have been applied to UAS programs as operating parameters dictated, only for another program to find a use to implement that newer technology within its own UAS program.
In brief, a comparison of two systems, one from the mid-1950s and the other currently in use, shall be presented in this paper.
1950s
The Army began experimenting with UAVs to perform reconnaissance missions. The RP-71 could ascend to over 3,000 feet per minute and reach a top cruising speed of between 185-224 mph (Blom, 2010). It operated between several hundred feet and four miles and could stay aloft for approximately 30 minutes (Blom, 2010). The UAV could be launched with only five minutes of preparation and used a catapult as its launch platform so that it could operate from the front lines, under the direct control of a ground commander (Blom, 2010). An operator on the ground used a stick box and an on-board camera to control the UAV. (Blom, 2010) When the mission was completed the UAV was flown back over friendly territory, the engine was shut down and a parachute was deployed (Blom, 2010). During a mission, the controller sat in the mobile radar and tracking cabin to guide the RP-71 to its target, while in the cabin, the radar tracked the flight on a map overlay (Blom, 2010). Other instruments in the cabin provided the operator with the altitude, speed and distance from the cabin. Once the drone reached the target, the controller activated the camera. (Blom, 2010)
Current
The Insitu ScanEagle is also a catapult launched UAV based system. However, instead of using the parachute recovery system, ScanEagle has incorporated the technologies of high-quality differential GPS units to catch a rope hanging from a 30-to-50-foot pole (Insitu). This unique launch and recovery system has enabled the ScanEagle to also operate from a marine environment restricted only by the size of the ship operating the equipment. It is capable of operating for up to 20 hours, with speeds up 92 mph with an average cruise speed of 55 mph at a service ceiling of up to 16,000 ft. (Insitu). Its payload is far more advanced than that of the RP-71, in that it operates a stabilized electro-optical and/or infrared camera on a lightweight inertial stabilized turret system, and an integrated communications system having a range of over 62 miles. (Insitu) Modified versions are equipped with a higher resolution camera/video system, all capable of real time viewing and recording in the GCS for mission archives/review/training purposes. ScanEagle’s air-to-ground communications systems deliver stable communications up to 55 nm from a ground control station. (Insitu) Encrypted digital video and command and control datalinks offer increased Intelligence, Surveillance, and Reconnaissance (ISR) security. (Insitu)
Comparisons
It would appear, the operating characteristics are quite different. But then the original designs of the UAV as a Target/Drone have changed. The need for speed is no longer an issue. The capabilities of radar defenses and electronic countermeasures have enabled a UAV capable of flying at much slower speeds without the need of ancient escape and evade mind set. Both systems have cameras but modern technological advances have greatly improved the capabilities of those used in the ScanEagle. Cameras capable of Infrared/night vision, real time digital video, all within a stabilized turret system have greatly improved the mission capabilities of the ScanEagle compared to that of the RP-71. How the UAVs were navigated is probably the greatest technological advancement over the past 60+ years. From radar tracking of an object on a mapped overlay to Satellite GPS, with real time UAV flight critical feedback and proximity of surroundings by video feed to the GCS controller. This newer technology allows for a UAV to be flown on opposite sides of the world without having to have a line-of site link.
New Technologies
As the increased development into solar energy continues, it is possible that more power plants will evolve into solar based energy. Eliminating the need of a depleted fuel source as the mission is conducted and thereby allowing for increased payload of another kind. The issue remains however in developing a battery source that is light/small enough to sustain enough energy to power an engine while operating in non-solar recharging conditions. However, if the engine could provide its own sustainable power source, but then…...
References
Blom, J. D. (2010) Unmanned aerial systems: A historical perspective (Occasional paper; 37) Fort Leavenworth, KS: US Army Combined Arms Center, Combat Studies Institute Press. Retrieved from http://usacac.army.mil/cac2/cgsc/carl/download/csipubs/OP37.pdf
Insitu. (n.d.). ScanEagle capabilities. Retrieved from
http://www.insitu.com/systems/scaneagle/capabilities
Militarily speaking, mission requirements for Unmanned Aerial Systems (UAS) have not changed much over the past 60 years. Unmanned Aerial Vehicles (UAV) of the 1950s were tasked to perform reconnaissance and deliver some form of weaponry much like they do today. The differences lie only in how the technological advancements of the past 60 years have set the systems and the payloads apart. It would be a fair assessment that not one particular program has evolved over all these years to become the stand alone system that it is today. Advancements in technology have been applied to UAS programs as operating parameters dictated, only for another program to find a use to implement that newer technology within its own UAS program.
In brief, a comparison of two systems, one from the mid-1950s and the other currently in use, shall be presented in this paper.
1950s
The Army began experimenting with UAVs to perform reconnaissance missions. The RP-71 could ascend to over 3,000 feet per minute and reach a top cruising speed of between 185-224 mph (Blom, 2010). It operated between several hundred feet and four miles and could stay aloft for approximately 30 minutes (Blom, 2010). The UAV could be launched with only five minutes of preparation and used a catapult as its launch platform so that it could operate from the front lines, under the direct control of a ground commander (Blom, 2010). An operator on the ground used a stick box and an on-board camera to control the UAV. (Blom, 2010) When the mission was completed the UAV was flown back over friendly territory, the engine was shut down and a parachute was deployed (Blom, 2010). During a mission, the controller sat in the mobile radar and tracking cabin to guide the RP-71 to its target, while in the cabin, the radar tracked the flight on a map overlay (Blom, 2010). Other instruments in the cabin provided the operator with the altitude, speed and distance from the cabin. Once the drone reached the target, the controller activated the camera. (Blom, 2010)
Current
The Insitu ScanEagle is also a catapult launched UAV based system. However, instead of using the parachute recovery system, ScanEagle has incorporated the technologies of high-quality differential GPS units to catch a rope hanging from a 30-to-50-foot pole (Insitu). This unique launch and recovery system has enabled the ScanEagle to also operate from a marine environment restricted only by the size of the ship operating the equipment. It is capable of operating for up to 20 hours, with speeds up 92 mph with an average cruise speed of 55 mph at a service ceiling of up to 16,000 ft. (Insitu). Its payload is far more advanced than that of the RP-71, in that it operates a stabilized electro-optical and/or infrared camera on a lightweight inertial stabilized turret system, and an integrated communications system having a range of over 62 miles. (Insitu) Modified versions are equipped with a higher resolution camera/video system, all capable of real time viewing and recording in the GCS for mission archives/review/training purposes. ScanEagle’s air-to-ground communications systems deliver stable communications up to 55 nm from a ground control station. (Insitu) Encrypted digital video and command and control datalinks offer increased Intelligence, Surveillance, and Reconnaissance (ISR) security. (Insitu)
Comparisons
It would appear, the operating characteristics are quite different. But then the original designs of the UAV as a Target/Drone have changed. The need for speed is no longer an issue. The capabilities of radar defenses and electronic countermeasures have enabled a UAV capable of flying at much slower speeds without the need of ancient escape and evade mind set. Both systems have cameras but modern technological advances have greatly improved the capabilities of those used in the ScanEagle. Cameras capable of Infrared/night vision, real time digital video, all within a stabilized turret system have greatly improved the mission capabilities of the ScanEagle compared to that of the RP-71. How the UAVs were navigated is probably the greatest technological advancement over the past 60+ years. From radar tracking of an object on a mapped overlay to Satellite GPS, with real time UAV flight critical feedback and proximity of surroundings by video feed to the GCS controller. This newer technology allows for a UAV to be flown on opposite sides of the world without having to have a line-of site link.
New Technologies
As the increased development into solar energy continues, it is possible that more power plants will evolve into solar based energy. Eliminating the need of a depleted fuel source as the mission is conducted and thereby allowing for increased payload of another kind. The issue remains however in developing a battery source that is light/small enough to sustain enough energy to power an engine while operating in non-solar recharging conditions. However, if the engine could provide its own sustainable power source, but then…...
References
Blom, J. D. (2010) Unmanned aerial systems: A historical perspective (Occasional paper; 37) Fort Leavenworth, KS: US Army Combined Arms Center, Combat Studies Institute Press. Retrieved from http://usacac.army.mil/cac2/cgsc/carl/download/csipubs/OP37.pdf
Insitu. (n.d.). ScanEagle capabilities. Retrieved from
http://www.insitu.com/systems/scaneagle/capabilities
Sunday, October 27, 2013
Technically Challenged
Well, I've reached the end of my first module (Step 3 Blog set-up and First Entry). I'm req'd to share the value of an interactive space to share my thoughts, beliefs, research and interests as they pertain to future/desired career. I'm tasked to do this via my "BLOG". I am sitting here in my make-shift office at home on a Sunday mid-afternoon a bit amused with situations that have taken me to the point of still sitting here at this time of day, writting this "BLOG". 1) I'm not PC savvy by any means, I am the guy in the office that totally believes in the concept of IT. They are there to give "me" a product to make sure it works, because I surely don't know how to use it otherwise, and that is where problems with me and computers begin and end. 2) This whole class is On-line a first for me, I've done Eagle-Vision, that was differant in that there was no class room interaction, but I got used to it. I'm hoping that the on-line will accomodate my work schedule. 3) ERAUs Blackboard was down Friday and Saturday, hence it didn't bode well for the slow to adjust/technically challenged.."ME", as I still had to load my paper and create the "BLOG". 4) Last night our neighborhood suffered a power outage, blown transformer, honestly, you can't dream this stuff up, unless it's a nightmare, Ohhh wait it is!! SO, as my luck would have it, I couldn't get on the internet all morning to access BlackBoard to fumble thru the antiquated instructions to load my paper and then try to create this "BlOG", which looks nothing like anybody elses page. So, here I still sit at 1530 hrs. It's gonna be a long nine weeks. SO, have I done something wrong, more than likely, can it be fixed, more than likely, will this get posted..REMAINS TO BE SEEN!! Will I survive this trial of technical challenges, I certainly hope so, as my future expectations greatly may or may not depend on it. What I do know is that I have a great interest in UAS programs and the evolving technology that is developing them into the future. My current job works around UAS programs and I hope to develop a deaper understanding of those programs that I have yet to be introduced to. I ask those that have read this post (is it any wonder that you could) to please take the time to ponder my question(s) in my profile and respond as you may. CHEERS
Subscribe to:
Posts (Atom)