Proceedings of the 2005 Systems and Information Engineering Design Symposium Ellen J. Bass, ed.

Transcription

1 Proceedings of the 2005 Systems and Information Engineering Design Symposium Ellen J. Bass, ed. WORK DOMAIN ANALYSIS FOR IMPROVEMENT OF UNINHABITED AERIAL VEHICLE (UAV) OPERATIONS Luis Nicolas Gonzalez Castro Amy R. Pritchett CAS Laboratory Daniel Guggenheim School of Aerospace Engineering Georgia Institute of Technology Atlanta, GA ABSTRACT This paper describes an abstraction decomposition space (ADS) modeling UAV operations in many different types of missions. The ADS is used to pre-define operational procedures that provide a coherent work structure and to provide insight on how to distribute automation among the UAV system components. 1 INTRODUCTION Uninhabited Aerial Vehicles (UAVs) are not a recent aerospace development (Gerken, 5), however, recent advances in computing, control theory, power systems, and materials have allowed for the development of new vehicles, with new capabilities and applications, increasing the use of UAVs in many areas. Missions range from traditional military surveillance, target acquisition and direct attack, to civilian weather monitoring, crop dusting, and search and rescue missions. Although modern UAVs have enabled more complex missions, their reliability is far from the reliability that most aerospace systems exhibit (Johnson, 20; Manning et al., 3). Development timeframes that emphasize meeting certain vehicle performance requirements have led to a neglect of other important components of the system design process. This neglect is frequently observed in non-existent or precarious work design considerations in the design of UAV systems. The focus of this paper is to apply work design methodologies to UAV operations as a way to improve system efficiency and increase system reliability. The work domain boundary for UAV operations has been selected to include the environment, the air vehicle(s), and the ground control station(s). Work domain analysis (WDA) for UAV operations is conducted by means of an abstractiondecomposition space (ADS) (Vicente, 149). The ADS lays out a map where all the possible trajectories (desired and undesired) within a given work domain can be traced, and also illuminates the existent environmental constraints affecting the different domain subsystems and operators. In this paper a generic ADS is developed for the UAV operations domain and used to address two relevant design issues: the identification of representative domain activities and procedures, and the analysis of alternatives for automation allocation among the different system elements for each activity. 2 WORK DOMAIN ANALYSIS CONSIDERATIONS 2.1 Complex Sociotechnical Systems and the Abstraction Decomposition Space The analysis of the UAV operations domain will be conducted by means of an abstraction-decomposition space (ADS), a two-dimensional modeling tool used for analyzing complex sociotechnical systems (Rasmussen, 35-46). In its vertical dimension the ADS presents a meansends hierarchy with five levels of abstraction. Beginning at the top we encounter the Functional Purpose of the system. Here is where the motives of existence for the system are listed. Moving down to the next level we find the Abstract Functions. These are functions that describe high-level activities of the system dictated by physical laws. In the next level, Generalized Functions describe general work activities and functions of the system (Rasmussen, 37). The fourth level includes Physical Functions, which represent observable work processes of the domain. Finally the Physical Form level of the abstraction hierarchy presents a description of the physical characteristics of the system and its components (Rasmussen, 37). By traversing the abstraction hierarchy (vertical dimension of the ADS) from top to bottom we can represent the objectives of the system and the means and processes available to accomplish them. By taking the reverse route, we see how different elements are assembled into a system to achieve a particular set of goals. In the horizontal dimension of the ADS the different elements of the abstraction characterization are distributed in the different physical (structural) levels of the system. Starting from the left with the complete system and moving to the right we traverse through different subsystems, functional units, and assemblies of the domain until we ar-

2 rive at its individual components. Although in the vertical (abstraction) dimension of the ADS the levels are agreed to be standard, for the horizontal dimension (decomposition) the number of levels vary with the complexity of the system and the resolution that the system analyst wishes to obtain from the model. In most cases, at least three different levels (system, subsystems, and component) are identified (Rasmussen, 43). 3 ABSTRACTION DECOMPOSITION SPACE FOR UAV OPERATIONS The UAV operations domain is comprised of three main elements: the air vehicle(s), the ground control station(s) and the environment. Precise system architectures for UAV operations vary from application to application. In some cases, more attributes and functionalities are allocated to some components of the system, or the UAV system itself is considered an element of a larger system. However, regardless of the level of complexity or specific application, the UAV operations domain can, without loss of generality, be characterized by the three elements mentioned above. Figure 1 presents the ADS developed for the UAV operations domain. At the Functional Purpose level, two main functions were identified: gather/broadcast data/information and deliver/retrieve payloads. These are also the only two functions that pertain to the overall system level. Several UAV configurations and missions were analyzed (Masey, 6-63) and it was noted that, regardless of the labeling of the mission, all missions could be simplified to gathering and/or broadcasting data/information (this distinction between data and information is made to allow for maximum generality in terms of the data processing capabilities of the vehicle) and handling of payloads. Table I presents a list of civilian and military missions reflecting the above fact. At the Abstract Function level, and moving to the subsystem level in terms of part-whole decomposition, guidance/trajectory generation and data/information analysis were the two functions identified. Guidance/trajectory generation is a high-level function on which all missions requiring information gathering and/or payload handling rely in order to accomplish their objectives. Its importance does not lie solely on generating a trajectory that the vehicle can fly but also in generating a trajectory that is relevant to the mission. In many missions, this guidance/trajectory generation function is informed in realtime with data obtained from the sensors of the vehicle. Here is where we see a common application of the data/information analysis function and hence the arrow connecting the two functions. At times, the trajectory of the vehicle has been already pre-set and does not vary throughout its execution. In this case, the output of the data/information analysis function proceeds directly to the next hierarchical level or to lower functional levels. We have termed the next two levels (Generalized Function and Physical Function) as the dynamics levels of the ADS. In the Generalized Function level of the ADS, the outputs of the guidance/trajectory generation function and the data/information analysis function are fed into two separate functions that control the kinematics of the vehicle. The determination of control inputs function provides the required control inputs (deflection of control surfaces, variations in thrust, etc) corresponding to the desired trajectory, i.e. the actions required to have the vehicle at all times in the desired position and with the correct attitude. In the same level we encounter the control of sensors and payload systems function. This function receives inputs from the two abstract level functions and provides the necessary motions of sensors and payload systems installed in the vehicle. Table 1: Gathering/Broadcasting Data/Information and Payload Handling (PD, Payload Delivery; PR, Payload Retrieval) for Different UAV missions. Civilian Military Weather Monitoring (e.g., Hurricane Tracking) (G/B D/I) Surveillance (G/B D/I) Mapping/Monitoring of Disaster-Affected Areas (G/B D/I) Reconnaissance + Target Acquisition (G/B D/I) Search & Rescue (G/B D/I, PR) Targeting & Enemy Engagement (G/B D/I, PD) Agricultural Activities (Crop Dusting) (PD) Direct Attack (G/B D/I, PD) Border Patrol (G/B D/I) Battle Damage Assessment (G/B D/I) Environmental Monitoring (G/B D/I) Electronic Warfare (G/B D/I, PD) Traffic Monitoring (G/B D/I) Antisubmarine Warfare/Patrol (G/B D/I, PD) 66

3 Figure 1: Abstraction Decomposition Space for the UAV Operations Domain. For many sensors to perform correctly, or to gather the required data, they need to have an appropriate attitude and position with respect to their sampling space (e.g. cameras do not obtain relevant video if they are not pointed in the right direction, or the video that they capture is of poor quality if the distance to their objective overwhelms their zooming capabilities). Similarly, for payload systems to operate correctly, they need to be in the correct position and have an appropriate attitude with respect to the reference frame of the target where the payload will be delivered or retrieved. The control of sensors and payload systems function ensures that these kinematic requirements are met. Many times the range of motion of sensor and payload systems is limited or null. This is why the determination of control inputs and control of sensors and payload systems functions inform and complement each other (this is represented by a bi-directional arrow in the ADS). In cases where the range of motion of sensors or payload systems is limited, the vehicle will adapt its kinematics in order to enable the functions of these systems. In the Physical Function level we found the kinetic components of the dynamics section of the ADS. The mass and energy balance function keeps track of mass an inertia changes in the vehicle and optimizes energy consumption in accordance with mission performance requirements. The balance of forces and moments function ensures that the proper forces and moments are acting on the vehicle as to fulfill the kinematic requirements developed in the previous level. In terms of sensors and payloads, the capture data and handle payloads functions regulate the actual operation of sensors and payload systems. Finally, the Physical Level elements, disaggregated at the component level of the decomposition dimension, are the elements required to allow all the previously described functionality. The mass and energy balance function will interact with the avionics of the vehicle (e.g., changes in mass and inertia will modify the dynamics of the vehicle requiring compensation by a stability augmentation system [SAS] or an adaptive controller), the lift systems ( including both aerodynamic surfaces for lift generation [wings, lifting bodies, rotors, etc] and the power component that complements these surfaces), and the ground control input devices, as required for operator commands. The balance of forces and moments function interacts with the avionics (navigation, SAS, control laws), the lift systems (regulation of lift and thrust in the vehicle), the control systems (effection of SAS and control commands), the mechanical systems (actuators, linkages and connections that enable the action of the other subsystems), and the input devices. Some of the outputs generated by the mass and energy balance and the balance of forces and moments function (e.g., fuel status, fuel consumption, batteries status, stores status, etc. for the former, and engine status, position, attitude, airspeed, rate of ascent/descent, etc. for the latter) will be presented to the UAV operator(s) via interface displays. Finally, the capture data and handle payloads functions will directly interact with mission specific sensors and mission specific payloads and payload systems respec- 67

4 tively. Interaction through input devices will allow for the direct control of the capture data and handle payloads functions. The status of these functions will be presented to GCS operators via interface displays. The different functions and elements in the ADS have been color coded to represent their possible spatial distribution within the work domain. Functions or elements that can only be present at the vehicle level are shown in black. Functions and elements that can only be situated in the GCS are represented in green, and functions or elements that can be both (or either) in the vehicle and (or) the GCS are shown in blue. graphical representation of this procedure is given by the series of nested control loops shown in Figure 2. 4 USING THE UAV ADS TO IDENTIFY REPRESENTATIVE DOMAIN ACTIVITIES AND OUTLINE THEIR PROCEDURES This study uses the ADS to identify specific procedures or work processes that describe a feasible, coherent work practice. Four main groups of procedures were identified in the UAV domain, as detailed in the following sections: Guidance/Trajectory Generation Procedure Data/Information Analysis Procedure Supervisory Procedures Mission-specific Procedures Although the procedures are categorized in separate groups, all domain procedures will exchange information with other procedural groups. In order to not break up the work and keep the work structure coherent (Beyer et al., ) it is important to be mindful of these interactions when designing the procedures. 4.1 Guidance/Trajectory Generation Procedure Guidance/trajectory generation is an essential activity for the effective completion of any mission in the UAV operations domain. If the air vehicle is not guided during flight, or is flown in a deficient trajectory, the probability of successful mission completion will be greatly diminished. Flying uninhabited air vehicles entails: 1) a planning stage where decisions are made about real time guidance or, a trajectory or a criterion for real-time trajectory generation is developed, 2) determining the necessary velocity or adjustments to the current velocity in order to follow the trajectory, 3) determining the necessary attitude and power requirements mandated by the required velocity, 4) determining the necessary adjustments to control surfaces and power system settings to comply with the attitude and power requirements, and finally 5) commanding the effection, via actions of a human agent on input devices or through a flight computer via electronic commands, of these adjustments at the subsystem level. A convenient Figure 2: Guidance/Trajectory Generation Procedure. The guidance/trajectory generation relies on the output data of the data/information analysis procedure. Besides giving relevant environmental information in terms of mission goals, this procedure also provides information about environmental hazards that may be in the proximity of the air vehicle. The velocity determination process considers the vehicle flyability constraints in terms of flight envelope. As it was identified in the ADS, many vehicles need to complement their dynamics with those of their sensor and payload systems in order to have this systems operational at all times. For this purpose information from the operation/supervision of mission-specific sensors and payload system procedure is used as an input for the attitude and power requirements determination process. The output of the attitude and power requirements determination process is then relayed to the operation/supervision of mission-specific sensors and payload system procedure to keep it updated. The attitude power requirements determination also considers flyability constraints that relate to attitude such as aerodynamic stall. 4.2 Data/Information Analysis Procedure The objective of the data/information analysis procedure is to analyze the raw output obtained from mission-specific sensors and from that information provide inputs to the guidance/trajectory generation procedure and the missionspecific procedures. In terms of the guidance/trajectory generation procedure, the sensor data can be used to update the trajectory; for mission-specific procedures, the sensor data can provide information for updating the motion of the sensors in order to maximize the mission performance metrics. The data/information analysis procedure is outlined in Figure 3. 68

5 Figure 3: Data/Information Analysis Procedural Outline. The procedure is triggered by the arrival of data from the mission specific sensors. If no data is received or if the data received is of poor quality (too much noise, low update rate, etc) this will initiate supervisory procedures of mission-specific sensor systems (see operation/supervision of mission-specific sensor and payload systems in section 4.4). If the data received satisfies minimum quality standards (defined in terms of the specific mission analysis requirements), it is then fed into the mission-specific analysis. Here is where the data is filtered, grouped and compared with pre-defined criteria. The output of the analysis is then fed into the guidance/trajectory generation procedure (if relevant) and the mission-specific procedures. 4.3 Supervisory Procedures Supervisory procedures are necessary to monitor the status and insure the correct operation of the different subsystems in the domain, both in the air vehicle and in the ground control station. The ADS helps identify these subsystems, Avionics Mechanical Systems Lift Systems Control Systems Interface Displays Input Devices Alerting Systems In terms of avionics, important parameters to monitor are: availability and status of communication/navigation devices, availability and status of flight computers, availability and status of flying data sensors and inertial navigation devices. In terms of mechanical systems, important parameters to control are: status (output) of actuators (to prevent saturation), loss of mechanical linkages, pressures in hydraulic components, etc. Control systems draw functionality from other subsystems in the vehicle, then by monitoring avionics and mechanical systems we are in part monitoring the status of the Control Systems. However, there are certain tests that can be implemented to monitor specific aspects of these systems, like, control surface status and mobility, and response to control inputs. Malfunctions in interface displays and input devices can be readily detected by GCS operators. However, the design must insure that the elements used for building the interface present high levels of availability and that alternative workstations are available to take over in case of failure. Given the high integration that exists between all vehicle subsystems, their correct operation is essential for the overall mission success and vehicle survivability. In order to address this need, all subsystem components are designed under very strict standards and exhibit extremely high levels of reliability. Given this fact, continuous monitoring of their activities to guarantee coverage can very quickly become a tedious endeavor. The possibility of delegating some of the supervision to automation or of having human supervision aided by alerting systems is discussed in section Mission-specific Procedures Mission-specific procedures deal directly with the high level goals of the mission. They also exhibit high specificity depending on the nature of the mission. However, regardless of these characteristics, mission-specific procedures can be organized into two different categories: Operation/Supervision of Mission-Specific Sensor & Payload Systems Monitoring of Mission Performance Metrics Different platforms are equipped with different sensor suites. Many UAV platforms are also adaptable in the sense that they have the capability of tailoring their sensor suite for a specific mission. The design of interfaces to support these activities should take this fact into account, in order to create flexible interfaces that accommodate information from different sensors. Similar is the need for payload systems. In terms of procedures for operation of sensor and payload systems, we will not address the specific procedures required for each type of sensor or payload, but the necessary procedures to successfully integrate the results and requirements of these tasks to the entire operation of the domain. As mentioned in the description of the ADS, the attitude of the vehicle is important for the correct operation of sensor and payload systems. From the data/information analysis procedure it was seen that adjustments in sensor settings could be needed in order to satisfy data quality requirements for the analysis. These re- 69

6 quirements are contemplated in the procedural outline presented in Figure 4. Figure 4: Mission-specific Procedures: Operation / Supervision of Mission-specific Sensor and Payload Systems. Monitoring of mission performance metrics is also an area where the specific work activities will be determined by the characteristics of the mission. Before the beginning of each mission, performance metrics must be clearly identified. The identification also requires a precise method to quantify them. Measurements can take place at very different levels, and information can be drawn from many different subsystems. In order to allow for real time tracking of these metrics (essential as a decision aid), an interface should be developed to display them. In many cases mission performance metrics will not be analyzed at the GCS level but relayed by the vehicle or the GCS to a higher level command and control center that will analyze the data and then relay commands to GCS personnel in case of deviations from mission metrics. 5 ANSWERING THE AUTOMATION QUESTION UAV missions can, for the most part, be appropriately characterized as 3-Ds-missions: dull, dirty, and dangerous (Braybrook, 90). Many UAVs are designed for long endurance missions, ranging from days to several weeks. The nature of these missions (surveillance, weather monitoring, etc) and their length call for an efficient use of the human element in the system. Having humans manually flying and supervising all aspects of these missions for their entire length would probably lead to deficient performance due to excessive workload and decreased attention. In the case of dirty and dangerous missions, we find that due to environmental constraints the number of satisfactory operational trajectories for successful mission completion is greatly reduced. Let us consider the case of a UAV gathering data at low altitude assessing damage due to a forest fire or an accident in a chemical or nuclear plant. The proximity to terrain and the existence of environmental hazards greatly limits the alternatives for successful operation of the vehicle, requiring a level of precision that can overwhelm the capabilities of a human operator. Similarly, in a battlefield environment, where a UAV could be engaged by other UAVs, manned vehicles, or from ground forces, flying the vehicle, acknowledging all possible threats, categorizing them and developing plans for engagement or evasion could create an unbearable workload for the human operator. These are some scenarios where automating some of the tasks within the domain would prove to be of great benefit. Sheridan (65-66) effectively describes the different alternatives for sharing and trading control between human and automation in a supervisory control setting. Five possible scenarios with different mixes of human and automation control have been described. In the first one, the human has complete control over the task and receives no aid from the automation. In the second scenario, the human is in control of initiating the task and utilizes the automation to execute it. In this setting the automation extends the human capabilities beyond what he/she can achieve alone. The third scenario presents the automation executing some task related activities or functions, while the human, using information provided by the automation, completes the task. Sheridan designates this as a relieve scenario, with this and the previous scenarios representing control sharing alternatives. In the fourth scenario, the human is basically in the conditions described for scenario one, but at the same time automation is available to take complete take over the task in case that the human falters. This scenario is characterized by Sheridan (65-66) as a back-up scenario. Lastly, in the fifth, scenario the automation has complete control over the task and replaces the human entirely. Scenarios four and five represent trading control alternatives. Below we analyze the application of these different alternatives for control trading and sharing between human and automation for the four task areas identified in the domain. 5.1 Automation of Guidance/Trajectory Generation Tasks For the guidance/trajectory generation procedure described in section 4.1 we identified three different implementation modes with different levels of automation, 1. Non-autonomous Guidance/Trajectory Generation 2. Semi-autonomous Guidance/Trajectory Generation 3. Autonomous Guidance/Trajectory Generation First an introduction of each of the modes is provided, and then each mode is categorized into the different human-automation combinations described in the previous section. For the first mode, human operators are completely in charge of the task, from generating a trajectory to 70

7 effecting the command to the control surfaces and power systems. Gonzalez Castro and Pritchett Figure 6: Mode 2 Implementation Alternative for Guidance/Trajectory Generation Procedure. Figure 5: Mode 1 Implementation Alternative for Guidance/Trajectory Generation Procedure. In the second mode, automation with similar functionality to that of a Flight Management System (FMS) (Billings, ), which we will denote Flight Management Automation (FMA), will be used to conduct most activities within the procedure. Provided a certain trajectory or guidelines for trajectory generation, which are programmed by the human agent, the FMA will determine the necessary velocity vector, the required attitude and power and the adjustments to the control surfaces and power system settings. Finally, the FMA will summarize the implementation of these requirements to the tracking of a vector in the flight display of the human operator. The human operator will then track this vector on his/her display in order to have the vehicle follow the trajectory. The operator will also have to translate and program data arriving from the data/information analysis and mission-specific procedures into the FMA. In the third mode, a second element of automation, an autopilot, is introduced. The autopilot receives the information from the FMA and directly executes commands on the vehicle subsystems without assistance of the human. The human is still involved programming a specific trajectory or guidelines for trajectory generation, and data inputs from the data/information analysis and mission-specific procedures, however, the actual task of continuous vehicle guidance is delegated completely to the automation. Analyzing the three procedural modes in the light of the sharing and trading of control alternatives presented in the previous section, we see that mode one will correspond with the first scenario. In this scenario the human is in complete control of the task and receives no aid from the automation to complete the task. The second mode could be identified with the third automation alternative, a control sharing alternative, where the human is relieved from some of the task activities by the automation and uses its outputs to complete the task. The third procedural mode, is clearly an example of the fifth automation alternative, where control is traded and the automation replaces the human in completing the task. Figure 7: Mode 3 Implementation Alternative for Guidance/Trajectory Generation Procedure. An interface with flexible automation (e.g. the possibility to tailor the information presented on the different displays in accordance with the requirements of a particular mode) would be desired in order to support all different modes and allow for mode changes during mission if required. If this is granted, then modes one and two could also then be categorized under scenario four, where automation is always available as a back up to take over the task. 71

8 5.2 Automation of Data/Information Analysis Tasks Given the high update rates that some UAV sensors provide, having operators performing data analysis in a longendurance mission can prove to be too taxing on the human element of the system. Analyzing Figure 3, we observe that some of the blocks of the procedural outline can easily be automated. The first two decision blocks which check for data reception and analyze the quality of the data received can be replaced with an algorithm that could perform the same functions. Precise guidelines in terms of noise, update rates, etc. must be built into the automation to insure proper evaluation of the quality of the data. For the mission specific analysis block, automation solutions are not very trivial. Given the case of a vehicle identifying elements on the ground for an assessment task, the required category of image processing would be image understanding (Young et al.). In image understanding, the input of the process is an image and the output is a highlevel description of the elements contained in the image. Although the field of digital image processing has seen great advancements in the last decades, the human eye is still a very accurate tool to discern objects in an image. Considering the fact that regardless of how the mission-specific analysis is performed, the output of the process will be a high-level description of the elements captured by the data, if a detailed and comprehensive algorithm is developed for the decision block that diverts information to the guidance/trajectory generation procedure, this process can then be automated. Considering the image processing requirement discussed above, two different scenarios for automation arise for the data/information analysis procedure. The first one automates the primary (availability + quality) data analysis and the decision of informing the guidance/trajectory generation procedure with the information outputted by the mission-specific analysis. The human remains in charge of the mission-specific data analysis. This could be characterized as an example of control sharing between human and automation, where the automation relieves the human from some of the tasks. The second automation alternative, automates the entire procedure, replacing the human in the mission-specific data analysis process. This approach requires the availability of powerful computers, sophisticated algorithms for digital signal and image processing, and extensive databases of targets and environmental elements. 5.3 Automation of Supervisory Tasks Alerting systems are defined as systems capable of monitoring for, detecting, and announcing conditions predetermined by the system designer that will have an impact in the operator s near term activities. Three main categories of alerting systems have been identified: signal detectors, hazard detectors, and hazard resolvers. Signal detectors, the simplest kind of alerting system, monitor the output of a sensor and trigger an announcement or alarm when the output exceeds a predetermined threshold (Pritchett, 7). Figure 8: Data/Information Analysis Procedure, Automation of Primary Data Analysis and Information of Guidance/Trajectory Generation Procedure. Figure 9: Data/Information Analysis Procedure, Automation of Primary Data Analysis, Mission-specific Analysis, and Information of Guidance/Trajectory Generation Procedure. In a hazard detection alerting system, the output of different sensors is fed into a hazard assessment block which calculates a measure of hazard. This measure of hazard is then fed into a signal detector which triggers an alarm when the measure crosses a pre-established threshold. Lastly, a hazard resolver alerting system works similarly to a hazard detector, but instead of producing an alarm when the measure of hazard exceeds the threshold, it proposes a procedure to address the hazard using a system interface. 72

9 For all types of alerting system the sensor output or outputs that are fed into the system may or may not be available to the operator that receives the alarm or hazard resolution procedure (Pritchett, 7-13). In terms of systems and subsystems supervision, the human operator, can greatly benefit from the assistance of alerting systems. In general for simple subsystems, one or two relevant measures can be presented on the GCS interface and at the same time have their outputs connected to a signal detection type alert. If different subsystems are grouped into more complex systems and the number of available inputs, and potential announcements or alarms, clutter the interface, a hazard detection or hazard resolution alerting system should be implemented instead. 5.4 Automation of Mission-Specific Tasks In the area of mission-specific tasks, the possibilities for automation of the operation/supervision of mission-specific sensor and payload systems procedures will depend on the automation level of other related procedures, particularly the data/information analysis procedure. In terms of the operation component, to allow for automatic adjustment of the dynamics of the sensor systems the mission-specific data analysis must be automated. In the case of payload systems, the adjustment of their dynamics will also depend on a continuous stream of commands, possible only in the scenario where the data/information analysis procedure is completely automated. For the supervision component of this task, which is to be automated only if the operation is also automated, signal detection type alerting systems can be installed and set to be triggered if the signals arriving from the sensors or the manipulation of payload systems fail to satisfy the requirements established by the other procedures of the domain. A similar approach can be instituted for the monitoring of mission performance metrics. Alerting systems, of the hazard 1 detection type could be used to integrate different system outputs into one performance measure, notifying the crew of deficiencies in terms of performance metrics. High level performance metrics that do not have to be evaluated in real time can also be aided by automation for data recording or data transmission purposes. 6 CONCLUSION In sight of the current growth of UAV operations for different military and civilian applications, and considering the weak safety record that some platforms exhibit, there is 1 We use the same terminology used to describe the different types of alerting systems. It should be noted, however, that in this case the alert does not represent an actual hazard to the system but only a failure to meet prescribed performance standards. 73 a need to carefully model the domain to advert its vulnerabilities and suggest corrective action. This paper addressed this need by using an ADS to identify the different functions of the domain, and organizing them hierarchically and systemically. The ADS model illuminated the visualization of procedures within the domain that were outlined generically to allow for maximum platform compatibility. The possibility of automating different tasks within each procedure was also discussed, proposing solutions that focused not in the specific components that could be used for the task but on the particular functional requirements that the given procedure and the entire domain operation mandated from the task. REFERENCES Beyer, H. and K. Holtzblatt Contextual Design, Defining Customer-Centered Systems. San Francisco, CA: Morgan Kaufmann. Billings, C.E Aviation Automation: The Search for a Human-Centered Approach. Mahwah, NJ: LEA. Braybrook, R Three D Missions Dull, Dirty and Dangerous! Unmanned Air Vehicles Complete Guide by Armada 28 (3): Gerken, L. C UAV Unmanned Aerial Vehicles. Chula Vista, CA: American Scientific Corp. Johnson, E. N Making UAVs Smarter. Aerospace America 41(9), Manning, S.D., Rash, C.E., LeDuc, P.A., Noback, R.K, and McKeon, J The Role of Human Causal Factors in U.S. Army Unmanned Aerial Vehicle Accidents. U.S. Army Aeromedical Research Laboratory, USARRL Report No Masey, J. Ed Unmanned Vehicles Handbook Burnham, Bucks, England: Shephard Press. Pritchett, A.R Reviewing the Role of Cockpit Alerting Systems. Human Factors and Aerospace Safety 1(1), Rasmussen, J., Pejtersen A.M., Goodstein, L.P Cognitive Systems Engineering. New York, NY: Wiley-Interscience. Sheridan, T.B Telerobotics, Automation, and Human Supervisory Control. Cambridge, MA: MIT Press. Vicente, Kim J. (1999) Cognitive Work Analysis: Toward Safe, Productive, and Healthy Computer-Based Work. Mahwah, NJ: LEA. Young, I.T., Gerbrands, J.J., and L.J. van Vilet An Interactive Image Processing Course [online]. Available online via < > [accessed April 4, 2005].

10 AUTHOR BIOGRAPHIES LUIS NICOLAS GONZALEZ CASTRO is a first year graduate student pursuing a M.S. in Aerospace Engineering at the Daniel Guggenheim School of Aerospace Engineering of the Georgia Institute of Technology. He is a graduate research assistant in the Cognition, Automation, and Simulation (CAS) Laboratory working under Dr. Amy R. Pritchett. His research interests are in the areas of dynamic systems, control theory, cognitive engineering and aerospace human factors. He can be reached by at <luis_gonzalez-castro@ae.gatech.edu> AMY R. PRITCHETT is an Associate Professor in the Daniel Guggenheim School of Aerospace Engineering and joint Associate Professor in the School of Industrial and Systems Engineering at the Georgia Institute of Technology. She is the director of the Cognition, Automation, and Simulation (CAS) Laboratory. Her research interests include cockpit design, including alerting systems and advanced decision aids, procedure design for operations of complex multi-agent systems, and agent-based simulation of complex systems. She holds S.B., S.M., and Sci.D degrees from the Department of Aeronautics and Astronautics of the Massachusetts Institute of Technology. Dr. Pritchett can be reached by at <amy.pritchett@ae.gatech.edu> 74