Ecological Interface Design in Transportation Systems¶

Status: emerging
Last updated: 2026-07-08
Sources: Burns Hajdukiewicz 2004 Ecological Interface Design.Pdf
Tags: [ecological-interface-design, transportation, aviation, driving, work-domain-analysis, display-design, case-study]

Summary¶

Chapter 5 of Burns and Hajdukiewicz (2004) presents four transportation case studies that apply Ecological Interface Design (EID): a Canadian Halifax Class naval frigate, a next-generation U.S. Navy destroyer, a light training aircraft (the Harvard) fitted with an enhanced Highway in the Sky navigation display, and a Hercules military transport aircraft with a redesigned fuel-balancing display. The chapter treats each system as a mass-and-energy machine whose constraints can be captured through Work Domain Analysis (WDA) and then rendered perceptible in an ecological display. It uses the four cases to contrast modelling decisions rather than to present a single finished interface, and it demonstrates that WDA can drive both complete displays and partial enhancements to existing, well-accepted designs. The naval cases centre on analysis and validation of the work-domain models; the aviation cases carry through to designed and evaluated displays.

Body¶

Context¶

The chapter is drawn from Burns and Hajdukiewicz (2004), Ecological Interface Design, and forms the transportation case study of the book. It examines how the general EID method — Work Domain Analysis built on Rasmussen's abstraction hierarchy, followed by display design that makes work-domain constraints visible — applies to vehicles, which differ from fixed process plants in two respects: they move freely through the world, and they interact continuously with a natural environment. The chapter sits downstream of the method chapters and alongside the other domain case studies in the book; it presumes the reader already understands the abstraction hierarchy and the skill-, rule-, and knowledge-based rationale set out in Ecological Interface Design. Its naval and aviation material overlaps in subject with the maritime-domain-kb and remote-operations-kb, where command-and-control and vehicle-supervision problems recur; those knowledge bases hold their own treatments and are not duplicated here.

Key Points¶

Burns and Hajdukiewicz (2004) frame transportation systems as completely engineered mass-transport systems governed by the laws of mass and energy, which makes their governing relationships obtainable and therefore well suited to WDA (PDF pp. 140–141, orig. pp. 105–106). Two features distinguish them from other work domains: they are not fixed in place, and they interact with the environment. The four case studies are organised so that each foregrounds a different modelling challenge — system boundary, purpose, depth of analysis, and design stage.

Naval frigate (Halifax Class). The first analysis, performed for Defence Research and Development Canada, modelled a multipurpose Halifax Class frigate whose operations room team manages a dynamic flow of sensor and contact information (PDF pp. 141–143, orig. pp. 106–108). The system boundary was drawn widely to include the ship, the natural environment, and external contacts, because capturing the interaction of ship capabilities with weather, sea, and contacts was central to the work. The work domain was split into three separate models — frigate, environment, and contact — rather than one combined model. Three functional purposes were identified for the ship: movement, sea control, and survivability, and these were validated by mapping every mission type (escort, patrol, screen, surveillance, reconnaissance) back to the three purposes to confirm they held constant across tasks (PDF pp. 146–147, orig. pp. 111–112). The environment model deliberately omits a functional-purpose level, since the environment is not a designed entity and acts without purpose, beginning instead at the abstract-function level with conservation of mass, conservation of energy, and creation of entropy. A distinctive contribution of this case is the separate treatment of social constraints: physical constraints (what an engine or hull can do) were modelled first, then social constraints (rules of engagement, naval values, acceptable risk) were added in a different colour, marking them as constraints that can be broken even when operators treat them as inviolable (PDF pp. 145–146, orig. pp. 110–111).

The frigate model was validated by scenario mapping. Three Operations Room Officers stepped through a nine-event training scenario spanning air, surface, and subsurface contacts, marking which model elements were active at each step (PDF pp. 148–150, orig. pp. 113–115). The domain experts named no constraint that was absent from the models, supporting the claim that the analysis was reasonably complete; areas of the model that went unvisited were retained on the argument that a validation of this type reveals missing elements but does not prove that an unused element is unnecessary. The exercise also produced trajectories of reasoning across the work-domain space over time, which the authors suggest can bridge WDA and the later control-task stage of Cognitive Work Analysis.

Naval destroyer. The second case supported the early design of a next-generation U.S. Navy surface combatant that did not yet physically exist (PDF pp. 152–153, orig. pp. 117–118). Here the boundary was set to the ship and the battlespace, modelled as a single combined model rather than the frigate's three separate ones. Because the ship was undesigned, physical constraints were sparse and the physical-form level was left blank, with explicit placeholders inserted at the abstract-function level to mark where physical detail would later be added. Purpose was expressed more generally as achieving combat and non-combat missions plus maintaining survivability. The contrast with the frigate is instructive: the single combined model shows connections between elements more clearly (battlespace awareness links directly to physical constraints), whereas the frigate's separated models carry more detail, including the intentions of contacts (PDF pp. 165–166, orig. pp. 130–131).

Harvard aircraft and the Highway in the Sky display. The aviation case used EID to enhance an existing and already successful display — the Highway in the Sky (HITS), which shows the corridor the aircraft should fly in three dimensions — rather than to build a complete new interface (PDF pp. 154–160, orig. pp. 119–125). The Harvard, a single-engine propeller trainer, was analysed with the standard five-level model. At the functional-purpose level the goal was to navigate safely from point A to point B on time; at the abstract-function level the governing relation was the force balance permitting flight dynamics; lower levels ran down to the curve of the wings at physical form.

Figure 1: Work domain model of the Harvard aircraft at the level of the whole plane, from functional purpose to physical form (after Burns & Hajdukiewicz, 2004, Fig. 5.11, orig. p. 122).

An instrumentation availability analysis mapped which work-domain variables could actually be obtained on the real aircraft versus a Microsoft Flight Simulator platform, revealing that several abstract-function and physical-form variables were unavailable and would have to be derived (PDF pp. 158–159, orig. pp. 123–124). The WDA showed that the original HITS omitted the interaction between speed, thrust, and altitude control and the time-to-destination goal implied by the purpose level. Three EID enhancements were added to the cockpit: a configural distance-time-speed triangle whose vertical emergent feature signals on-time status, an airspeed trend plot, and a glideslope indicator with a constraint region for landing. Tested with six pilots and six non-pilot gameplayers flying to a target airport at a designated time under varying visibility, wind, and instrument-failure conditions, the enhanced display produced more accurate landing times in every case, most markedly in the worst weather (PDF pp. 160–161, orig. pp. 125–126). An independent alternative by Amelink (2002) for a Cessna Citation 500 reached a similar work-domain model but integrated the same speed and altitude information directly into the HITS through an energy-management graphic based on the conservation of energy; that display added extensive information integration but was tested only with two pilots and gave mixed results, which the authors attribute partly to the difficulty of retraining experienced pilots onto an innovative display (PDF pp. 161–163, orig. pp. 126–128).

Hercules fuel-balancing display. The fourth case, drawn from Dinadis and Vicente (1999), applied EID to a single subsystem — the engine and fuel system of a Hercules military transport, whose two tanks feed four engines through several routing options that pilots must monitor and balance to keep the aircraft's weight balanced (PDF pp. 163–166, orig. pp. 128–131). Because the boundary was tight, the analysis reached fine component detail (individual tanks, engines, valves, piping, and intermediate stores). The resulting display is a full EID implementation in which each region maps to a level of the work domain: a map in the top-left corner shows the flight range reachable on current fuel, translating functional-purpose information directly; four polar-star displays integrate multiple engine variables (rpm, temperature) into a single emergent shape; four process graphics below them show abstract-function energy and entropy across the engine cycle; and a connected bar graphic on the left shows overall fuel amount, tank balance, engine contributions, and valve settings, spanning abstract-function balance and physical-function detail.

Figure 2: The Hercules fuel balance display — a full EID implementation mapping map (functional purpose), polar stars (engine state), energy-entropy process graphs (abstract function), and fuel-balance bars with a mimic diagram (physical function) (after Burns & Hajdukiewicz, 2004, Fig. 5.18, orig. p. 131; display from Dinadis & Vicente, 1999).

Cross-case lessons. The chapter closes by reading the four cases against nine recurring challenges (PDF pp. 166–175, orig. pp. 131–140). System boundaries are artificial and must match the project objective — the fuel system for the Hercules, the whole plane for the Harvard, the ship with some externals for the destroyer, the ship plus environment plus contacts for the frigate — since a boundary that is too wide wastes analytic effort and one that is too tight starves the model of needed detail. Purpose must be stated specifically and, where possible, split into at least two purposes, so that safety and operational systems can be separated and any conflict between them examined; the "move from A to B" and "survive" split on the frigate is offered as a better example than the Harvard's combined "navigate safely from A to B". Physical relationships model consistently across all four cases at the abstract-function level as mass and energy balances. Social constraints appear mainly at the higher levels of the naval models and were absent from the aviation models. Five-level models are the norm, with incomplete levels left visibly blank and justified rather than dropped. Depth of analysis is governed by the level of control required — the last level of a WDA must show the control that is needed — which is why the Hercules display shows valve settings and control levers while the Harvard remains a flight-monitoring display. For partial implementations, the authors recommend checking that functional-purpose information (especially safety, financial, and maintainability goals) and the abstract- and generalized-function levels are represented, since these are the levels most often missing from existing displays.

Conclusion¶

The transportation case studies show that EID scales from a single aircraft subsystem to a whole naval command-and-control problem, and that its value does not depend on building a complete new interface: the aviation cases demonstrate that a small set of ecological enhancements, derived from the abstract- and generalized-function levels a conventional display omits, can measurably improve performance, particularly under degraded conditions. They also show that the method is honest about its own limits — placeholders, blank levels, and deliberately narrow boundaries are treated as legitimate outcomes of real project constraints rather than as failures. The cases collectively argue that the work-domain model, not the task, is the durable foundation for transportation displays, because a vehicle's purposes and physical constraints remain constant while its missions change.

References¶

Amelink, M.H.J. (2002) Ecological Automation Design: Enhancing HITS with Energy Management. Unpublished thesis, Delft University of Technology. To be validated.

Bisantz, A.M., Burns, C.M. and Roth, E.M. (2002) 'Validating methods in cognitive engineering: A comparison of two work domain models', Proceedings of the 46th Annual Meeting of the Human Factors and Ergonomics Society, pp. 521–525. To be validated.

Burns, C.M. & Hajdukiewicz, J.R. (2004) Ecological Interface Design. Boca Raton, FL: CRC Press. burns2004ecological

Dinadis, N. & Vicente, K.J. (1999) 'Designing functional visualizations for aircraft systems status displays', International Journal of Aviation Psychology, 9(3), pp. 241–269. To be validated.

Moradi-Nadimian, N. (2003) An Ecological Enhancement of the Highway in the Sky Display. Unpublished work, University of Toronto. To be validated.

Open Questions¶

The frigate and destroyer analyses were validated or specified but not carried through to fielded ecological displays; how far do their work-domain models translate into interfaces, and does the single-model versus separated-model choice affect the resulting display?
The two HITS enhancements (Moradi-Nadimian's separate graphics versus Amelink's integrated energy display) gave different evaluation outcomes on small samples; which approach holds up under adequately powered testing with trained pilots?
The chapter's naval cases overlap with maritime and remote-operations command-and-control; how should the transportation work-domain models here be reconciled with the treatments held in the maritime-domain-kb and remote-operations-kb without duplicating constraints?