Domain Representations as Artifacts to ‘Bridge the Gap’ from Analysis to Design

1. Domain Representations as Artifacts to ‘Bridge the Gap’ from Analysis to Design Emilie Roth Roth Cognitive Engineering

2. Objective of Talk • Explore the multiple roles that work domain representations can play in guiding design • Highlight the ‘degrees of freedom’ in selecting the content and form of a domain representation that can have important implications for guiding design • Use three design projects as illustrations

3. Design Projects • Military Command and Control Display • Naval Ship Control Center Displays • Displays for Mission Planning and Execution in a Military Airlift Organization

4. Work Domain Representations • Eclectic approach to domain representation formalism: • Rasmussen’s Abstraction Hierarchy • ACWA -- Functional Abstraction Network • And modifications thereof… • Key elements: • Explicitly represent domain goals, and means available for achieving them – Shifting Levels of Abstraction • Highlight mappings between abstract functions and physical means

5. Case 1: Shifting Level of Abstraction • Abstraction Hierarchy representations allow the cognitive analyst to see beyond the physical level of description of the domain • Shifting levels of abstraction can result in powerful novel visualization aids

6. Illustrative Case: Combat Power Display (Potter et al., 2002) • Military commanders think in terms of ‘relative combat power’ in making decisions about movement of troops and equipment to achieve a mission objective. • Current tools provide physical representations of the domain (i.e., physical maps) -- they provide little support in reasoning at this more abstract level.

8. Choose Combat Power Visualization • Display Objective: Support commanders in choosing appropriate combat power to achieve mission. • Combat missions whose objective is to engage and defeat an enemy to prevent it from taking over key terrain. • Probability of meeting mission objectives is a function of the ratio of friendly to enemy combat power at the point in time and space where the engagement is to take place. • Display intended to support commanders in deciding: • where to engage the enemy • when to engage the enemy • what combat resources to deploy to maximize the potential to defeat the enemy.

12. Case 2: Supporting a Large ‘First of a Kind’ Design • Domain representations can highlight ‘Many-to-One’ mappings between abstract functions and physical systems • This Can: • Facilitate Dialogue with System Designers • Support identification of requirements for human roles and supporting displays

13. Illustrative Case: Navy Ship Design(Bisantz et. al., 2003) • Large engineering team ‘Next generation’ Battleship’ design project • Our task: Define functional requirements for command center roles and displays • As part of project developed an abstraction hierarchy that highlighted multiple mappings between physical systems and abstract ship functions.

15. Revealed One-to-Many Mapping

16. Benefits • Highlighted that multiple functions could rely on the same system. • Supported Dialogue with Systems Engineers • By revealing “costs” of system design decisions • Dictated Collaborative Support Requirements: • Revealed need for coordination among Land-Attack and Self-Defense Watchstanders in the Command Center and the Watchstanders on the Bridge. • Imposed display and communication requirements.

17. Post-Script: There are ‘Degrees of Freedom’ in Work Domain Modeling • There can be important degrees of freedom in the choice of form and content of a Work Domain Representation • Different representational choices highlight different aspects of the work domain • These choices can have profound impact on design guidance.

18. Illustrative Case: Comparison of two WDA (Burns et. al., in press) • Compared two independently developed Work Domain Analysis models of similar military ships • While there was substantial overlap in content there were also fundamental differences • Examination of differences pointed to important degrees of freedom in how to represent a WDA with implications for guiding design. • Level of integration of the model (own ship, environment, contact) • Treatment of sensors

19. Approach 1: Modeling without Sensors • Model the ‘sensed’ object (environment; opponent) • Focus is on modeling what needs to be sensed rather than what is/can be sensed • Broad Work Domain perspective • Inputs for new sensor design/redesign • Input to displays of sensor coverage, gaps

20. Approach 2: Include Sensor Management in the WD Model • Rationale: sensor control and management is a critical issue • Sensor systems are an important part of the overall system which must be understood and controlled • Sensor systems affect, and are affected by, other systems • Sensors interact with high level goals, and may impact them differently

21. Example Interactions from a Command and Control Environment Defense of Systems and Personnel Achieve Assigned Missions Signature Maintenance Battlespace Awareness Use of sensors necessary for offensive functions Use of some sensors makes ship detectable Maneuvering Systems Battlespace Sensors Environmental Sensors Moving may disambiguate sensor data Knowledge of environmental conditions can impact choice of sensor settings

22. Case 3: Revealing Domain Constraints and Interaction • Domain representations can reveal domain constraints and interactions that impose demands on cognitive and collaborative process. • Can guide design of displays that reveal these constraints enhancing decision-making.

23. Illustrative Case: Mission Planning and Execution • Mission Planning and Execution in a Military Airlift Organization • Mission Planners: Plan missions • Execution Cell: monitor missions and handle last-minute changes Project Objective: Develop work-centered support systems for mission planning and execution.

24. Work-Centered Design Framework Work Work Work - Centered Work Aiding Work Aiding Work Work - - Oriented Oriented Work Ecology Knowledge Knowledge Requirements Design Design Evaluation Evaluation Modeling Capture Capture Analysis • Multi-facet assessment • Representational aiding • Direct aiding • Work Domain Analysis • Work Process Analysis • Cognitive Task Analysis • Work Practice Observations • Work Probe Techniques • Local Artifact Discovery

25. Opportunities to Aid Mission Planning & Execution • Bridge the ‘seam’ between mission planning and execution • More effectively communicate mission plan and constraints to execution • Improve the ability to detect and respond to emerging problems during execution • Flag emerging problems • Facilitate the ability to assess repercussions of mission changes (e.g., delays)

26. Domain Representation

27. Value of Multiple Domain Conceptualizations • The abstraction hierarchy representation highlights constraints and interdependencies in the domain • Temporal constraints have particularly primacy during mission execution • An alternative representational formalism was adopted that emphasized the role of temporal constraints.

28. Re-conceptualizing a Mission Plan as Events and Constraints EVENT Takeoff, Landing, Air Refueling, Rendezvous … RESOURCES Aircraft, Aircrew, Airfields, Airspace … Temporal Constraints on Availability: Aircrew – Crew Duty day Airfields: operating hours Airspace – DIP clearance Aircraft – Previous mission CONDITIONS

29. Time-Line View • A timeline display is intended to provide a visualization of 'temporal' constraints: • Temporal constraints among events • Temporal constraints in the availability of resources that impact when an event can take place (e.g., MOG) • Temporal constraints imposed by 'legal restrictions' (e.g., DIPS)

30. Crew Duty Day ETD/ETA per leg Airfield Op Hours Day/Night A/R Reservation 0600 4183:0600 1000 1400 1800 2200 4184:0200 Conception of a Timeline View • A highly customizable view of a mission with its temporal constraints, organized into slices: crew duty day, mission schedule, airfield restrictions, airspace restrictions, air refueling. • Each ‘slice’ may be included or not, summarized or expanded. • The goal is to be able to look at this mission view and be able to easily see temporal constraint violations (as mismatches in vertical slices).

31. Multiple Roles ofDomain Representations • Clarifies the sources of complexity (that any agent would confront): – Lack of information, • many-to-many mappings that create goal-trade-offs • Captures domain constraints and interactions that impose demands on cognitive and collaborative processes. • Supports dialogue with System Engineers • Provides a framework for guiding Engineers/Display designers • Provides abstract conceptualizations that are generative – resulting in powerful novel visualizations.

32. Some ‘Provisos’ • Coming up with ‘productive’ abstract representations (conceptualizations) is not a mechanical process • It involves deep understanding of the domain • Different representational choices highlight different aspects of the work domain – differentially supporting different design decisions. • Novel visualizations still involve a ‘leap’ of creativity • Domain Representations can ‘reduce the gap’ but not eliminate it. • Design artifacts don’t strictly ‘precede’ display concepts – there is a constant ‘back and forth’ between them.

33. References • Burns, C., Bisantz, A., & Roth, E. M. (in press). Lessons from a comparison of work domain models: Representational Chioices and their implications. Human Factors. • Bisantz, A. M., Roth, E. M., Brickman, B., Gosbee, L., Hettinger, L. and McKinney, J. (2003). Integrating Cognitive Analyses in a Large Scale System Design Process. International Journal of Human Computer Studies, 58, 177-206. • Potter, S. S., Elm, W. C., Roth, E. M., Gualtieri, and J., Easter, J., (2002). Bridging the Gap between Cognitive Analysis and Effective Decision Aiding. In M. D. McNeese and M. A. Vidulich (Eds) State of the Art Report (SOAR):Cognitive Systems Engineering in Miltary Aviation Environments: Avoiding Cogminutia Fragmentosa! Wright-Patterson AFB, OH: Human Systems Information Analysis Center. (pp 137- 168). Available online at: http://iac.dtic.mil/hsiac/.