MIT Libraries logoDSpace@MIT

MIT
View Item 
  • DSpace@MIT Home
  • Department of Aeronautics and Astronautics
  • Humans and Automation Laboratory
  • HAL Reports
  • View Item
  • DSpace@MIT Home
  • Department of Aeronautics and Astronautics
  • Humans and Automation Laboratory
  • HAL Reports
  • View Item
JavaScript is disabled for your browser. Some features of this site may not work without it.

Cognitive Task Analysis for the LCS Operator

Author(s)
Scott, S. D.; Cummings, M. L.
Thumbnail
DownloadHAL2006-01.pdf (378.8Kb)
Other Contributors
Massachusetts Institute of Technology. Dept. of Aeronautics and Astronautics. Humans and Automation Laboratory
Metadata
Show full item record
Abstract
The following Tables and Figures detail the cognitive task analysis (CTA) performed to determine the information requirements needed to support a single operator located aboard the futuristic Littoral Combat Ship (LCS). This operator is responsible for controlling four underwater unmanned vehicles in conjunction with a UAV operating on a shared network. • Table 1 is a scenario task overview that breaks the overall mission into 3 phases (planning, execution, and recovery) and then details the subtasks for each of the 3 mission phases. • Figure 1 is an event flow diagram that demonstrates what events must occur in a temporal order for each of the 3 phases. There are three basic event types in Figure 1: 1) a loop (L) that represents a process that occurs in a looping fashion until some predetermined event occurs, 2) a decision (D) that represents some decision that is required from the LCS operator, and 3) a process (P) which requires some human-computer interaction to support the required tasks. In each event block, an alphanumeric code is included which labels that particular event type (L#, D#, P#). This label is important because later information requirements will be mapped to one of these events. • Table 2, which details the situation awareness (SA) requirements for the LCS Operator for each of the 3 mission phases and associated subtasks. Each of these SA requirements is mapped directly to one or more events in Figure 1. Because the decisions in Figure 1 represent critical events that require detailed understanding of what information and knowledge is needed to support the operator’s decision-making process, decision ladders were constructed for the diamonds and loops in Figure 1 that correspond to an involved decision process to resolve the question being posed at that stage in the event flow (Figures 2-4). Decision ladders are modeling tools that capture the states of knowledge and information-processing activities necessary to reach a decision. Decision ladders can help identify the information that either the automation and/or the human will need to perform or monitor a task. Decision Ladders, illustrate the need not only for the same information identified by the cognitive task analysis, but the need for several other pieces of information such as the need for visual or aural alerts in contingency situations. In Figures 2-4, three versions are included that detail (a) the basic decision ladder, (b) the decision ladder with corresponding display requirements, and (c) the decision ladder with possible levels of automation. • Figure 2 represents the automated target recognition (ATR) decision ladder (D3 from Event Flow): (a) decision ladder, (b) decision ladder with corresponding display requirements, and (c) decision ladder with possible levels of automation. • Figure 3 shows the decision ladder information and knowledge requirements for the sentry handoff (L3 from Event Flow). • Figure 4, the UUV Recovery Decision Ladder (D7 from Event Flow), illustrates what information is nominally needed. Since this phase was not a major focus, the decision ladder is not as detailed as it could be. This should be a point of focus in Phase II. Lastly Figure 5 demonstrates the coordination loop that must occur in the case where a handoff failure occurs (for a number of reasons to include equipment failure, communication delays, etc.) Again, because the multi-player coordination issues are not a primary focus in Phase I but are a significant consideration for any follow-on phases.
Description
In support of Plan Understanding for Mixed-initiative control of Autonomous systems (PUMA)
Date issued
2006
URI
http://hdl.handle.net/1721.1/46723
Publisher
MIT Humans and Automation Laboratory
Series/Report no.
HAL Reports;HAL2006-01

Collections
  • HAL Reports

Browse

All of DSpaceCommunities & CollectionsBy Issue DateAuthorsTitlesSubjectsThis CollectionBy Issue DateAuthorsTitlesSubjects

My Account

Login

Statistics

OA StatisticsStatistics by CountryStatistics by Department
MIT Libraries
PrivacyPermissionsAccessibilityContact us
MIT
Content created by the MIT Libraries, CC BY-NC unless otherwise noted. Notify us about copyright concerns.