March 2002

NASA/TM—2002–211397

On Abstractions and Simplifications in theDesign of Human-Automation InterfacesMichael Heymann and Asaf DeganiAmes Research Center, Moffett Field, California

The NASA STI Program Office ... in Profile

Since its founding, NASA has been dedicated tothe advancement of aeronautics and spacescience. The NASA Scientific and TechnicalInformation (STI) Program Office plays a keypart in helping NASA maintain this importantrole.

The NASA STI Program Office is operated byLangley Research Center, the lead center forNASA’s scientific and technical information. TheNASA STI Program Office provides access to theNASA STI Database, the largest collection ofaeronautical and space science STI in the world.The Program Office is also NASA’s institutionalmechanism for disseminating the results of itsresearch and development activities. These resultsare published by NASA in the NASA STI ReportSeries, which includes the following report types:

• TECHNICAL PUBLICATION. Reports ofcompleted research or a major significantphase of research that present the results ofNASA programs and include extensive dataor theoretical analysis. Includescompilations of significant scientific andtechnical data and information deemed tobe of continuing reference value. NASAcounterpart of peer-reviewed formalprofessional papers, but having lessstringent limitations on manuscript lengthand extent of graphic presentations.

• TECHNICAL MEMORANDUM.Scientific and technical findings that arepreliminary or of specialized interest, e.g.,quick release reports, working papers, andbibliographies that contain minimalannotation. Does not contain extensiveanalysis.

• CONTRACTOR REPORT. Scientific andtechnical findings by NASA-sponsoredcontractors and grantees.

• CONFERENCE PUBLICATION.Collected papers from scientific andtechnical conferences, symposia,seminars, or other meetings sponsored orco-sponsored by NASA.

• SPECIAL PUBLICATION. Scientific,technical, or historical information fromNASA programs, projects, and missions,often concerned with subjects havingsubstantial public interest.

• TECHNICAL TRANSLATION. English-language translations of foreign scientificand technical material pertinent toNASA’s mission.

Specialized services that complement the STIProgram Office’s diverse offerings includecreating custom thesauri, building customizeddatabases, organizing and publishing researchresults ... even providing videos.

For more information about the NASA STIProgram Office, see the following:

• Access the NASA STI Program HomePage at http://www.sti.nasa.gov

• E-mail your question via the Internet tohelp@sti.nasa.gov

• Fax your question to the NASA STI HelpDesk at (301) 621-0134

• Telephone the NASA STI Help Desk at(301) 621-0390

• Write to:NASA STI Help DeskNASA Center for AeroSpace

Information7121 Standard DriveHanover, MD 21076-1320

March 2002

NASA/TM—2002–211397

On Abstractions and Simplifications in theDesign of Human-Automation InterfacesMichael HeymannDepartment of Computer ScienceTechnion, Israel Institute of Technology

Asaf DeganiAmes Research Center, Moffett Field, California

National Aeronautics andSpace Administration

Ames Research CenterMoffett Field, California 94035

Acknowledgments

This work was conducted as part of NASA's base research and technology effort, human-automation theory sub-element (RTOP #548-40-12). The first author was supported by Grant NCC 2-798 from the NASA Ames Research

Center to the San Jose State University. Michael Shafto and George Meyer provided helpful insights into thisresearch topic. Ronen Erez wrote the model reduction software. The authors also thank Todd Callantine, Tracy

Golden, Nolie Johnson, Kevin Jordan, and Rowena Morrison for their help and continual support.

Available from:

NASA Center for AeroSpace Information National Technical Information Service7121 Standard Drive 5285 Port Royal RoadHanover, MD 21076-1320 Springfield, VA 22161301-621-0390 703-605-6000

SummaryThis report addresses the design of human-automation interaction from a formal perspectivethat focuses on the information content of theinterface, rather than the design of the graphicaluser interface. It also addresses the issue of theinformation provided to the user (e.g., user-manuals, training material, and all otherresources). In this report, we propose a formalprocedure for generating interfaces and user-manuals. The procedure is guided by two criteria:First, the interface must be correct, that is, withthe given interface the user will be able toperform the specified tasks correctly. Second, theinterface should be succinct. The report discussesthe underlying concepts and the formal methodsfor this approach. Two examples are used toillustrate the procedure. The algorithm forconstructing interfaces can be automated, and apreliminary software system for itsimplementation has been developed.

IntroductionHuman interaction with automation is so

widespread that almost every aspect of our livesinvolves computer systems, information systems,machines, and devices. These machines arecomplex and are composed of many states,events, parameters and protocols. Yet, the onlyface the user sees is the interface: always a(highly) reduced description of the underlyingbehavior of the machine. This is no coincidence,because otherwise the user would be subjected toenormous unnecessary complexity. Consider, forexample, consumer electronics where making theuser-interfaces and associated user-manuals asefficient, simple, and succinct as possible isbecoming a marketing imperative, and no longeris just an engineering and human factors ideal. Asconsumer devices get increasingly complex andmultifunctional, there is a reciprocal drive torender them simpler and easier to use (andthereby more marketable).

In the majority of today’s automated systems, thehuman is the supervisor. Users interact withsystems or tools to achieve certain operationaltasks (Parsuramann et al., 2000). These tasks, ortask specifications, may involve the execution ofspecific sequences of actions (e.g., a procedurefor setting up a medical radiation machine),

monitoring a machine’s mode changes (e.g., anautomatic landing of an aircraft), or preventing amachine from reaching specified illegal states(e.g., tripping a power grid). To achieve thesetask specifications, the user is provided withinformation about the behavior of the machine. Inmost cases, this information is provided by meansof an interface and associated user-manuals andother training material.

Naturally, for the user to be able to interact withthe machine correctly and reliably so as toachieve the task specification, the informationprovided to the user must first and foremost becorrect. For example, if the pilot of an airlinerhas insufficient information to resolve a modetransition and to decide whether, after entering acommand to the autopilot, the aircraft will enter“climb” mode or “level-flight” mode, then onecan say that the information provided to the pilotis inadequate. One sure way to guaranteesufficient information for correct interaction is toprovide the user with the full detail of themachine behavior. This way the user can, inprinciple, always track the status of the machinecorrectly and reliably. But this amount of detailhas an obvious downside too; the size ofinterfaces and weight of user manuals will behuge, and the burden on the userincomprehensible and unmanageable.

In practice, the interface and related user manualsare always a reduced, or abstracted, description ofthe machine’s behavior. No interface provides acomplete description of the underlying behaviorof the machine. Therefore, a major concern ofdesigners of automated systems is to make surethat these abstracted interfaces and manuals areindeed adequate and correct. Currently, thisevaluation is performed in an ad hoc fashion. Itusually involves costly simulations and extensivetesting, and in industries such as aerospace andmedical equipment, it also involves complicatedcertification procedures (see for example FederalAviation Regulation 25.1329 and associatedAdvisory Circular). Yet, despite the best effortsby design teams and certification officials,numerous incidents and accidents involvingincorrect interfaces have been reported in aviation(Abbott, Slotte, and Stimson, 1996), maritime(National Transportation Safety Board, 1997),medical (Leveson, 1995 see Appendix A -- theTherac-25 accidents), and automotive systems

2

(Andre and Degani, 1997). Even in simplerconsumer devices, flaws in the user interfacedesign are frequently encountered.

Developing a correct interface is only onerequirement. In addition, we all strive forinterfaces and user-manuals that are simple andeasy to use. One basic aspect of this requirementis to develop interfaces and user-manuals that aresuccinct. That is, the number of states and eventsthat the user needs to understand and track inorder to operate the system correctly should be assmall as possible. Currently, the design decisionsas to what information must be provided to theuser, both in the interface and in user-manuals,are made intuitively. Systematic methodologiesdo not exist for these decisions.

One of the outcomes of having incorrect andextremely complex interfaces is a commonproblem called “automation surprises,” whereoperators (e.g., pilots, technicians, users) havedifficulty understanding the current status of anautomatic system as well as the consequences oftheir interaction with it (Woods, Sarter, andBillings, 1997).

In an earlier NASA report (Degani et al., 2000)and a recent paper (Degani and Heymann, 2002),we discussed a methodology for evaluatinginterfaces and user manuals. Given a descriptionof the machine, specifications of the user’s task,interface, and all relevant information the user hasabout the machine, the procedure evaluateswhether the interface and user manualinformation are correct for the task. That is, canthe user achieve all the specified tasks correctlyand reliably, given all the information provided?The proposed procedure can be automated andapplied to the verification of large and complexhuman-machine systems.

In the present report we take an additional stepand discuss a formal methodology for automaticgeneration of interfaces and user manuals. Therequirement, of course, is that the interfaces anduser manuals be both correct and succinct. Thedesign problem can be formulated as follows: Themachine and the user’s operational requirements(task specifications) are given. Now the problemis to generate an interface and associated userinformation that enables the user to interact withthe machine correctly. It is further required that

the interface and all user information be as simpleand as succinct as possible. Naturally, additionalconsiderations must be taken into account toensure efficient human-machine interaction.These include graphical user interface design,cognitive limitations, human physical abilities,and the like. But underlying all is the basiccorrectness issue on which we focus our attentionhere.

The report is organized as follows: We begin bydiscussing the four components of human-machine interaction that are part of our theory andmethodology: the machine, the task specification,the interface, and user model. We then use thesefour elements to verify the correctness of aproposed interface for a given machine. Next, weturn to the main topic of this report, a formalmethodology for constructing interfaces andrelated user information (e.g., user-manuals).Here we describe a procedure for abstracting amachine model to the most succinct descriptionthat enables correct user-machine interaction. Weillustrate this procedure with an example of atransmission system in a car and then show othercharacteristics of abstraction using an example ofa somewhat more complex machine. Finally, weconclude with a brief summary and discuss someof the implications of this work for designers ofautomated systems.

Formal Aspects of Human-Automation InteractionMany aspects of the human-machine interaction,such as the design of interfaces in terms of theirgraphical appearance (which is still highlyempirical and intuitive), are not amenable toformal analysis and design. Yet aspects ofinteraction that concern the information contentprovided to the user about behavior of a systemcan be formally analyzed, and thus can besystematically verified and designed. Here theemphasis is on questions regarding “what”information must be provided to the user and“when,” rather than on “how” this information isto be presented.

In this work we focus primarily on theinformation content provided to the user about thebehavior of a system. This aspect of userinteraction with machines can be described andanalyzed formally by considering the following

3

four elements: (1) the machine-model, (2) theoperational tasks, (3) the machine’s interfacewith the user, and (4) the user’s model of themachine, i.e., the information provided to the userabout the machine behavior (e.g., in the usermanual). Let us briefly review these elements.

MachineAs stated earlier, we consider machines thatinteract with their environment and specificallywith their human users. We focus our attentionon the behavior of machine states, transitions, andevents. The machines are modeled as statetransition systems (in particular finite statemachines). A state represents a mode, orconfiguration, of the machine. Transitionsrepresent discrete-state (mode) changes that occurin response to events that trigger them. Some ofthe transitions occur only if the user triggersthem, while other transitions occur automaticallyand are triggered by the machine’s internaldynamics, or its external environment.

To illustrate a typical machine model, let usconsider the machine of Figure 1, which describesa simplified multi-mode three-speed transmissionsystem proposed for a certain vehicle. We use theconvention that user-triggered transitions aredescribed by solid arrows, while automatictransitions are depicted by dashed arrows. Thetransitions are labeled by symbols to indicate the(triggering) circumstances under which themachine moves from state to state.

The transmission has eight states, or modes.These modes are grouped into three super-modesthat represent manually switchable gears (orspeeds): low, medium and high. The states withineach speed represent internal torque-level modes.Thus there are torque modes ,1L ,2L ,3L in thelow speed super mode; there are torque modes

,1M ,2M in the medium speed super mode; and

modes ,1H ,2H ,3H in the high speed supermode. The transmission shifts automaticallybetween torque modes (based on torque, throttle,and engine and road speeds). The automatic up-shifts (to higher torque modes) are denoted by theevent symbol δ and the automatic down-shifts bythe symbol γ . The (user operated) manual speedchanges, achieved by pushing a lever up or down,are denoted in Figure 1 by the event symbols βand ρ , respectively. Pushing the lever up shiftsto a higher speed and pushing down shifts to alower speed. The transmission is initialized in thelow torque mode 1L of the low speed (asindicated in Figure 1 by the free incoming arrow).

Task SpecificationsThe second element is the specification of theoperational tasks the user is required to performwhile using the machine. For example, a commontask specification in an automated control systemis that the user be able to determine

Figure 1. Transmission system.

4

unambiguously the current and the subsequentmode of the machine.

In terms of a formal description, the taskspecification consists of a partition of themachine’s state-set into disjoint clusters that weshall call specification classes (or modes) that theuser is required to track unambiguously. In otherwords, does the user know whether the system iscurrently in, or is about to enter into, the super-mode High, Medium, or Low? We note that theuser is not required to track every internal statechange of the machine: for example, between themodes 1L , 2L and 3L inside mode Low.

InterfaceThe third element is the user interface. Inpractice, the interface consists of a control unitthrough which the user enters commands (e.g.,mode selections, parameter changes) into themachine, as well as a display through which themachine presents information to the user.Generally, the interface provides the user asimplified view of the machine. Not all the eventsof the machine are annunciated to the user, andthe interface displays only partial informationabout the actual behavior of the machine.

Formally, the interface consists of a listing anddescription of the events accessible to the user.These include, of course, all the user-triggeredevents (inputs to the machine), but generally onlya subset of the events that are associated withautomatic transitions. This is because some of thelatter are not monitored at all, and others aremonitored only in groups. The interfaceannunciation tells the user only that one of theevents in the group took place, without specifyingwhich.

It is noteworthy that events per se cannot bedisplayed in the interface. What can be displayedis some consequence of their occurrence.Therefore, events are usually represented bydisplay modes that become active as a result ofthe event occurrence. How these modes arepresented to the user graphically (e.g., icon shape,color, etc.) is beyond the scope of this report.

To illustrate, let’s return to the multi-modetransmission model of Figure 1. The system inFigure 2 gives one possible user interface for thismodel. Here the monitored events are only theones triggered by the user. In the Figure 2 wehave also provided a description of the threedisplay modes, as well as how the user wouldobserve the machine’s behavior when allautomatic transitions are internalized andunobserved. Note that the torque modes arecompletely suppressed from view.

An alternate interface for the transmission isprovided in Figure 3. Here the monitored eventsconsist of the user-triggered events as well as theautomatic transitions. Again, we provide apossible description of how the user mightobserve the machine behavior. Note that whereverthe automatic transitions do not trigger a statechange in the user model, they are shown by(gray) self-loops to indicate the fact that the user-model “is aware” of the possibility that theseevents might take place without its actualparticipation.

Figure 2. Proposed interface and user model.

5

Figure 3. Alternate interface and user model.

User modelAs mentioned earlier, the interface provides theuser with a simplified view of the machine, in thatit displays only partially the machine’s internalbehavior. The description of the machine’soperation that is provided to the user is generallyalso an abstracted simplification of the actualmachine behavior. This description is usuallyprovided in terms of a user manual, trainingmaterial, formal instruction, or any other means ofteaching the user; however, it is presented here asa formal model that we refer to as the user modelof the machine. By its very nature, the user-model is based on the interface through which theuser interacts with the machine, and thus relatesto the modes and events that are displayed there.Therefore, for analysis purposes the interfaceevents and modes are all explicitly referred to inthe user-model, and in this respect can be thoughtof as “embedded” in the user-model.Let us return to the user interface displayed inFigure 2. This Figure depicts a possible user-model associated with the interface that monitorsonly the user-triggered events for the transmissionsystem. This particular user-model can beobtained from the machine model of Figure 1 bysuppressing (internalizing) the events that are notmonitored, and grouping the states as suggestedby the specification. It can be seen that themanual shifts from MEDIUM up to HIGH or downto LOW, as well as the down-shift from HIGH toMEDIUM, are always completely predictable.However, the up-shift from the LOW gear depends

on the current torque mode. Note that the up-shifts from L1 and L2 switch the transmission toMEDIUM speed, while the up-shift from L3switches the transmission to the HIGH speed.Therefore, from the suggested interface of Figure2, it cannot be predicted whether the up-shift willlead the transmission from LOW to MEDIUM, or toHIGH gear.

An alternate user-model for the transmissionmodel is presented in Figure 3. This user-modeldescribes an interface that also monitors theoccurrences of two specific automatic transitions,in addition to all user-actuated events. This user-model, in particular, is aimed at enabling theoperator to determine whether the transmission isin a display-mode LOW-1 (where an up-shift issupposed to lead to MEDIUM speed), or in thedisplay-mode LOW-2 (where an up-shift leads toHIGH).

Correctness of interactionAmong the four elements that play a role in thehuman automation interaction, the machine modeland the task specification must be regarded forour purpose as given and beyond dispute, becausethey are not subject to our scrutiny. In contrast,the interface and the user model, which are thesubject of investigation in the present report, mustbe examined for correctness. Specifically, wewish to know whether a given interface and usermodel enable the user to operate the machinecorrectly so as to satisfy the specification.

This verification problem was the focus of arecent paper (Degani and Heymann, 2002) inwhich a methodology was described forverification of user-model and interfacecorrectness for a given machine-model andspecification. It was shown that the user modeland interface are correct if, in a composite modelobtained through a suitably defined synchronouscomposition of the machine model and the usermodel (see Figure 4), there exist no error statesand no blocking states. An error state represents adivergence between the machine and user models– the user model does not indicate the correctspecification-class the machine is in and henceleads the user to a wrong interpretation of themachine’s behavior. A blocking state is one inwhich the machine can trigger a observed

6

transition that the user-model is unaware of and

does not recognize.

Next, we review the methodology of Degani andHeymann (2002), about the verification problem.This will also introduce us to terminology thatwill be required for the discussion of the mainissues of the present report.

As we have already stated, the interface and user-model are intended to provide an abstracted andreduced description of the machine. Thisabstracted description does not enable the user todetermine with certainty each state the machine isin, since it is required only that the user be able todetermine which specification-class (mode) themachine is in and which it is about to enter. Let

MΣ denote the set of events, or transition labels,that take place in the actual machine model. Theevents that ultimately appear in the associateduser-model and are displayed in the interfaceconstitute a reduced subset of the set MΣ ofmachine events. This reduction, or abstraction, isachieved through a projection operation Π : MΣ→ USRΣ as explained next, where USRΣ is the

event set that is displayed in the interface andappears in the user-model.

The event set MΣ consists of three disjoint

subsets: (1) oMΣ - the set of observed-events that

includes all machine events that are actuallypresented in the interface and appear also in the

user-model; (2) mMΣ - the set of masked events

(that are not displayed individually, but rather aregrouped into sets of two or more events each,

with each set having a single event-label in the

user-model; and (3) uMΣ - the set of unobserved-

events that are neither displayed nor appear in theuser-model.

In view of the above, the event set USRΣ consists

of the union of the event sets )( oMΣΠ (which is

identical to oMΣ ), the event set )( m

MΣΠ whichdenotes the set of events obtained after masking

the events in mMΣ , and the “empty event” ε (=

)( uMΣΠ ) that represents the set of unobserved

events.

In actual operation, the machine is driven byevents from MΣ . The user tracks the progress ofthe machine via the interface (display), where he

or she observes events in USRΣ , with the aid of

the associated user-model. Thus, the user-modeland the machine evolve concurrently. But they areonly partially synchronized, in that the user-modeltracks the actual state evolution of the machinewith some uncertainty. This is because (1) not allmachine events are observed and some machine-events are masked, and (2) the user-model is onlyan abstraction of the actual machine’s behavior.

Suppose that the machine is at state q at which a

transition labeled α is defined, leading to a state

q’ (we denote this by 'qq → α ). Assume thatwhen the machine is at state q, the user-model isat a corresponding state p. Event α can be eitherobserved, masked, or unobserved.

Figure 4. Masked synchronous composition.

7

If α is an observed event and hence αα =Π )( ,it is required for adequacy of the user-model thata corresponding transition be also defined at statep, leading to p’. That is, there must exist a

transition 'pp → α . In the concurrentoperation of the machine and the associated user-model, there will appear a transition labeled αfrom the state pair (q,p) to the state pair (q’,p’).That is, there will be a “composite” transition

)','(),( pqpq → α .

If α is a masked event, there will be a

corresponding transition ')( pp → Π α in the

user-model, where )(αΠ is the (masked) image

of α in USRΣ . The composite transition will

appear as ).','(),( )( pqpq → Π α The fact thatthe event labels are taken from the user-model isbecause the composite transition is viewed fromthe point of view of the user.

Finally, if α is unobserved and εα =Π )( , thecomposite transition will appear as

),'(),( pqpq → ε (since α is silent and has nocorresponding transition in the user model).

For the user-model to be correct for the taskspecification, it is necessary that the user-model

be able to track the machine-model’s specificationclasses unambiguously. More explicitly, it isrequired that when the user-model enters a statep in response to an observed event-string (or

event sequence) t , all possible states q that themachine-model could have entered in response tomachine event strings s for which ts =Π )( ,would belong to the same specification class.

Before proceeding with the discussion, let us useour methodology to verify whether the user modelof Figure 3 is correct. Recall that this user-modelis aimed at enabling the operator to determineunambiguously which speed the transmission is inor is about to enter. The composite model of themachine of Figure 1 and the user model of Figure3 is shown in Figure 5. Here we can readily seethe error state (M1,High) which is entered uponexecuting the event sequence δβ (δ followed by

β ). It is evident that the user model of Figure 3is incorrect.

It is of course possible to try other interfaces anduser-models and then employ the verificationprocedure to determine their correctness.However, such an approach is not likely to bevery fruitful: It may take considerable effort todevelop and verify one design after the other, withno guarantee of success. Furthermore, even when

Figure 5. Composite model of the alternative user model.

8

a correct interface is found, there is no assurancethat it is the simplest. The development of asystematic approach for constructing interfacesthat are both correct and succinct is the subject ofthe next section.

Machine Model ReductionIn the previous section we have seen whichconditions the user-model and interface mustsatisfy in order to enable the user to performcorrectly a specified task on a given machine. Wehave also reviewed a procedure for verifying thatthese conditions indeed hold true. However, thequestion remains open as to how a correctinterface and user model can be designedsystematically for a given task.

As mentioned earlier, one possible choice of usermodel is to take the full machine model as usermodel and the complete machine event set as theset of monitored events. If the machine model isdeterministic (as we assume throughout thisreport), this will ensure that there will never beany problem in predicting the next state of themachine. But the operator would be required totrack every state and every event in the machine –a formidable and impractical job. In the simpleexample of Figure 1, the machine has 8 states, 18transitions and 4 distinct transition labels. But thisis a tiny number when compared to “industrialsize” situations.

In this section we shall turn to the main issue ofthe present and describe a procedure for thegeneration of all optimal user models andinterfaces for a given machine model and taskspecification. In particular, we shall consider theproblem of constructing, for a given machine andtask specification, the set of all best possible user-models and event abstractions that satisfy thespecification. Here, by best user models andinterfaces we mean the ones that cannot be furtherreduced. Since, as we shall see, these user models(and associated event abstractions) are generallynot unique, we cannot speak of user-model“synthesis,” but rather, of machine modelreduction. We shall show how all “smallest” usermodels and associated interfaces can be derived.

Compatible state sets and coversWe assume that the machine-model is given as astate machine and that the task specification is

given as a partition of the state-set into disjointclasses of states that we refer to as specificationclasses (Degani and Heymann, 2002). Thus, eachstate of the machine model belongs to a uniquespecification class. (In Figure 1 which depicts themulti-mode three speed transmission, thespecification classes consist of the three speeds;Low, Medium and High. Each state, or mode,belongs to exactly one speed.)

Let us consider a machine-model given as a state-machine, and let the task specification consist of apartition of the machine-model’s state set Q into

disjoint specification classes lQQ ,...,1 (as

described, for example, in Figure 1 where 3=l ).

The user model must enable the user to operatethe system correctly with respect to thespecification classes. That is, it must enable theuser to track the specification classes but notnecessarily individual states. Thus, the user doesnot need to be able to distinguish (by means of theuser model and interface) between two states pand q of the same specification class, if for thepurpose of tracking the specification classesunambiguously it is sufficient for the user toknow that the machine visited either p or q .More explicitly, the user does not need to be ableto distinguish between p and q if thespecification class visited following any user-machine interaction starting in state p , is thesame as the specification class visited followingthe same user-machine interaction starting at stateq . This leads to the following definition: Twostates, p and q , are specification equivalent (orcompatible), if given that the machine is presentlyin either state p or q (of the same specificationclass), the specification classes to be visited underfuture inputs will be the same. Stated moreformally, we have

Definition: Two states p and q arespecification compatible if and only ifthe following two conditions bothhold:1. The states p and q belong tothe same specification class,

9

2. If 'p and 'q are states such thatthere exists an event string

ns σσ ...1= for which'pp s→ and 'qq s→ are

both defined, then 'p and 'qbelong to the samespecification class.

It is clear that if the only concern is to track thespecification classes, two specificationcompatible states need not be distinguished in theuser model. We may also conclude immediatelythat any set of states is specification compatible ifall the pairs of states within that set arespecification compatible.

Thus, if an efficient procedure is found forcomputation of all specification compatible pairs,the set of all compatible state sets will easilycomputed. Indeed, the compatible triples will beobtained as the state triples, all of whose pairs arecompatible; compatible quadruples as thequadruples all of whose triples are compatible,and so on.

Next, we have the following:

Definition: A set C of compatible sets of

states is called a cover of the state set of

the machine-model, if every state of the

machine-model is contained in one or

more elements of C.

Since a set that consists of a single state is(trivially) compatible, it follows that every state isincluded in at least one compatible set, so that theset of all compatibles is always a cover.

Definition: A compatible set of states is

called a maximal compatible set, if it is

not a proper subset of another compatible

set; that is, if it is not contained in a

bigger compatible set of states.

Since sets that consist of a single state arecompatible, it is clear that every state is containedin at least one maximal compatible set. It followsthat the set of maximal compatibles is a cover.

Definition: A cover C of compatiblesis called a minimal cover, if no propersubset of C is a cover.

Of particular interest to us will be the set of allminimal covers formed from the set of maximalcompatibles. That is, we shall be interested inminimal covers whose component elements aremaximal compatible sets. In general, the numberof such minimal covers can be greater than one.

We shall see below that minimal covers bymaximal compatibles constitute the foundation of

Figure 6. Table of all pairs.

10

the model reduction and interface generationprocedure. However, we shall first show how theset of compatibles is computed.

Generation of compatible pairsAs stated above, the computation of compatiblesets hinges on the construction of the set of allcompatible pairs. An efficient iterative algorithmfor construction of compatible state pairs is basedon the use of merger tables (see e.g., Paull andUngar 1959, and Kohavi 1978, where relatedmodel reduction problems are discussed).

A merger table is a table of cells representingdistinct state pairs. An initial table for the eightstates of our transmission example is shown inFigure 6. Each cell of the table corresponds to apair of distinct states, and each pair of distinctstates appears in the table exactly once.

Next, we have the following observations that canbe easily derived from the definition ofcompatible pairs:

A state pair ),( qp of the same specificationclass is compatible if and only if for every

event symbol σ such that 'pp → σ and

'qq → σ are both defined, it is true that

either '' qp = , or the pair )','( qp iscompatible.

We shall use the above characterization ofcompatible sets to obtain a complementarycharacterization of all pairs that are notcompatible (or incompatible). It will then beconvenient for us to compute recursively the setof all incompatible pairs. The set of compatiblepairs will then consist of all state pairs that are notfound to be incompatible. Based on the abovecharacterization of compatible pairs, thecharacterization of incompatible pairs is asfollows:

A state pair ),( qp is incompatible if andonly if either p and q belong to distinctspecification classes, or there exists an event

symbol σ for which 'pp → σ and

'qq → σ are both defined, and the state

pair )','( qp is incompatible.

Using the above observations regardingcompatible and incompatible pairs, thedetermination as to whether a state pair iscompatible or incompatible is computediteratively as follows.

1. For each state pair ),( qp that can bedetermined as incompatible in the firststep based on the above characterization(i.e., if p and q belong to distinct

Figure 7. Resolution table (initial).

11

specification classes), we mark thecorresponding cell F (for false). For allother state pairs, we write in their cellstheir associated transition pairs thatconsist of all distinct state pairs )','( qpfor which there exists an event symbol

σ , such that the transitions 'pp → σ

and 'qq → σ are both defined.

For illustration, the initial resolution table for thetransmission model of Figure 1 is presented inFigure 7. Notice that each transition pair in thetable has been subscripted with the associatedevent label. This subscription is not essential tothe algorithm and is for the reader’s convenienceonly. Notice further that the cell (H1,H3) is emptybecause it is neither incompatible nor hasassociated transition pairs.

Next, the table is resolved iteratively.

2. At each step of the iteration every statepair that has not yet been determined as Fis updated as follows: If the cell of a statepair ),( qp includes a transition pair

)','( qp whose cell has already beendetermined as F (incompatible), then thecell of ),( qp is also denoted F.

Otherwise, the cell of ),( qp is modified

as follows: Each transition pair )','( qpin the cell of ),( qp is replaced by all thetransition pairs that appear in the cell of

)','( qp .

3. If in a given iteration step no newincompatible state pairs are found (i.e., nonew F designations are added to thetable), then all the state pairs that are notdesignated as F, are given the designationT (for true). This completes the tableresolution procedure and thedetermination of all compatible pairs.

To illustrate the iteration steps of the procedure,let us return to our transmission example. Thetable of Figure 8 is obtained from that of Figure 7as follows: First we replace the transition pairs inthe cell (L1,L2) by those in the cell (L2,L3). Thecells (L1,L3) and (L2,L3) are denoted with Fbecause their cells include incompatible pairs.The remaining undecided state pairs (those thathave not yet been given the value F) are modifiedaccording to the algorithmic procedure. Forexample, in the cell (M1,M2) we list the transitionpairs from the table of Figure 7 of the cell(H1,H2) that consists of (H2,H3).

Figure 8. Resolution table (after first iteration).

12

In the next resolution step the table of Figure 9 isobtained. Here the cell (L1,L2) is marked F uponsubstituting the value F of the cell (M1,H1,)which is incompatible. The remaining undecidedcells are modified as specified by the algorithm.In fact, notice that no further change needs to bemade to the table.

In the next step, no further incompatible pairs arecreated and the table remains identical to that ofFigure 9. At this point, all the remainingundecided cells are marked T as shown in thetable of Figure 10, concluding the tableresolution.

Thus, as seen in Figure 10, for the example ofFigure 1, the set of compatible pairs consists of(M1,M2), (H1,H2), (H1,H3), and (H2,H3).Notice that the states L1, L2 and L3 do not appearin any compatible pairs and therefore thesingleton sets (L1), (L2) and (L3) are clearlymaximal compatibles.

Generation of the set of maximalcompatiblesThe procedure for generation of maximalcompatibles consists of first systematicallycreating all compatible sets. We begin bycomputing all compatible triples, then compatiblequadruples, then quintuples, and so on. A

compatible triple is a triple all three of whosepairs are compatible; a compatible quadruple is aquadruple all of whose pairs are compatible,which is equivalent to a quadruple whose fourtriples are all compatible, and so on. Once allcompatibles are listed, the maximal ones caneasily be computed by deleting from the list allcompatibles that are contained within larger ones.

For the transmission example, the maximalcompatibles are easily found to be the sets (L1),(L2), (L3), (M1,M2) and (H1,H2,H3). It is also notdifficult to see that, in this case, they partition thestate set into disjoint subsets and hence form the(unique) minimal cover by maximal compatibles.

Generation of reduced modelsThe generation of a reduced model that can serveas a correct user model for the given machine andspecification is based on an abstraction of themachine-model. This reduced model is obtainedby clustering the states into sets that consist of aminimal cover by maximal compatibles.

To this end, let us assume that a minimum coverconsists of a given set of maximal compatibles

lCC ,...,1 , where the set iC , li ,...,1= , consists of

states },...,{1 inii qq of the machine model. The

maximal compatibles lCC ,...,1 form the state set

of the reduced model. Here it is noteworthy that a

Figure 9. Resolution table (after second iteration).

13

minimal cover by maximal compatibles need notbe a partition of the state set into disjoint subsets.Specifically, while each state of the machinemodel must be contained within some maximalcompatible set, it may well be the case that a stateis contained in more than one maximalcompatible of the minimal cover. That is, thesesets may have overlaps.

Next, we turn to computing the transitions in thereduced model. An event symbol σ is said to beactive at iC , if there exists an outgoing transition

in the machine model labeled by σ , at some state

iCq ∈ . That is, there exists a state 'q in the

machine model, such that 'qq → σ is defined.

We denote by )(σiC the set of all states iCq ∈for which an outgoing transition labeled by σexists.

Next, we define )(σiS to be the set of all states

'q of the machine model, such that 'qq → σ

for some )(σiCq ∈ . Thus, the set )(σiS is the

set of all states of the machine model that can bereached from states in iC through the event σ .

It readily follows from the definition ofcompatible sets that there exists one or moreelement of lCC ,...,1 which contain )(σiS . In the

reduced model we then create a transition labeledby σ going from the state iC to the state jC ,

where jC is the maximal compatible that contains

)(σiS . If more than one such set jC exists, we

can choose any one of these (and to avoid non-determinism in the reduced model we chooseexactly one).

To summarize, the reduced model associated withthe minimal cover lCC ,...,1 is obtained as

follows. The state set of the reduced modelconsists of elements lpp ,...,1 (think of ip as

associated with iC ). There is a transition labeled

σ from ip to jp if jC is the (chosen) set that

contains )(σjS . The reduced model is initialized

at state kp if the machine model is initialized at a

state in kC (where, as before, there may be more

than one possible selection if the initializationstate is contained in more that one of the iC ).

The reduced model obtained for the transmissionexample is shown in Figure 11. The correctnessof this reduced model as a user model for thespecification is verified in Figure 12 in which thecomposite model with the machine model of thetransmission is displayed.

Figure 10. Resolution table (completed).

14

Event AbstractionThe final step of the model reduction procedureconsists of the abstraction of the reduced model’sevent set (when possible). Specifically, we askwhich events can be internalized (i.e., need not bemonitored) and which events can be clustered intogroups so that instead of being monitoredindividually, they will be monitored collectively.That is, the user will be informed that someevents in the group occurred, but will not be

informed which events of the group actually tookplace.

To this end the following abstraction rules apply:

1. An event can be internalized if it occursin the reduced model only in self-loops.

2. A set of events can be grouped together,if every state transition that can betriggered by any event of the group can

Figure 12. Verification of the reduced model (no error states and no blocking are detected).

Figure 11. The reduced user model.

15

also be triggered by any other event of thegroup.

In the transmission example of Figure 11no event abstractions are possible. Anillustration of event abstractions isprovided in the example of the nextsection.

a GENERIC machine exampleIn the above discussion on verification andmachine model reduction, we used an example ofa transmission system. In this final section, weshall apply the reduction algorithm to a somewhatmore complex machine. The machine in Figure13 has 9 states and 25 transitions. There are threespecification classes: the gray region that includesstates 7, 8, and 9; the wave-like region thatharbors state 4 and 6; and the rest of the states ofthe machine (1, 2, 3, and 5). The taskspecification is similar to our previous one: theuser has to track the machine along these threeregions (or modes). Specifically, the user must beable to identify the current mode of the machineand anticipate the next mode of the machine as aconsequence of his or her interactions.

We perform the reduction procedure along thesteps described in the previous section. First thetable is constructed, and then the iterations areperformed. The procedure terminates with onlyone minimal cover of maximal compatibles that

consists of four state sets: (1,3,5) (2,3,5) (4,6)(7,8) and (9). Notice however, that this exampleillustrates a case in which the cover is not apartition of the state set. Indeed, the state 3 isincluded in two distinct maximal compatibles.

We then arbitrarily assign names to these sets,and call them A, B, C, D, and E, respectively.The reduced machine is obtained uponcomputation of the abstracted transitions asexplained earlier, and is shown in Figure 14. Itcan be seen in this figure that the event ρ occursonly in the self-loop in state A and that the eventsγ and δ are interchangeable. Thus, ρ can be

internalized and the events γ and δ can begrouped. The result of this event abstraction ispresented in the final reduced (user) model ofFigure 15, which contains only 5 states and 16transitions. The verification result of this modelis presented in Figure 16. No error states orblocking are detected.

ConclusionsIn this report we discussed several formal aspectsof the design of human-automation interaction.Specifically, we focused attention on theconstruction and verification of correctness ofuser models and interfaces. Two objectivesguided us in our design and analysis: (1) that theinterfaces and user models be correct; and (2),that they be as simple as possible. We have

Figure 13. A generic machine model.

16

described a systematic procedure for generatingsuch correct and succinct user-models andinterfaces.

The discussion and the examples illustrate thateven for machines that are seemingly simple, i.e.,that have very few states and straightforward taskspecifications, finding a correct interface anduser-model is not a trivial matter. Interfaces thatintuitively may appear to be correct are shown,after applying formal verification, to be faulty. Itis therefore not surprising that we encounter somany automation problems in commonlyencountered systems. Indeed, such problems canbe found in almost every computer-based system.

Thus, the main focus of the report is on asystematic procedure for constructing correct andsuccinct user-models and interfaces. Theproposed reduction procedure generates interfacesthat are not necessarily intuitive or easilycorrelated with the underlying system (e.g., seethe reduced user model of Figure 15).Nevertheless, these user models are formallycorrect and efficient. They are also irreducible.This is a marked departure from the usual ad hocway of constructing abstractions in interfacedesign. But this change in approach is necessary,given the complexity of current systems, theexpected increase in complexity of futuresystems, and the ever-increasing requirements forcorrect and reliable operation.

As discussed in the section “compatible states setsand covers,” the proposed procedure may lead tomore than one possible minimal (irreducible)interface and user-model. That is, it may findseveral minimal covers (of maximal compatibles).These minimal covers are all correct and efficientreductions of the same machine and task-specification. Naturally, the decision as to whichone is selected constitutes a human-factors and/orengineering design decision. It affords thedesigner with several candidate interfaces andallows designers the freedom to choose the mostappropriate one, given other design considerationssuch as graphical user interface considerations,users’ preferences, and ease of implementation.

While the discussion and examples have focusedon discrete-event systems and finite state machinerepresentations, the approach is amenable to othertype of representations. It remains, however, aninteresting topic of future research, to expand theapproach to systems that have continuous anddiscrete events (hybrid systems) as well as timedsystems.

Figure 14. Reduced model.

17

Figure 15. Reduced model (with masking and internalization of event).

Figure 16. Composite model.

18

ReferencesAbbott, K., Slotte, S. M., and Stimson, D. K.(1996). The interface between flightcrews andmodern flight deck systems. Washington, DC:Federal Aviation Administration.

Andre, A. & Degani, A. (1997) Do you knowwhat mode you're in? An analysis of modeerror in everyday things. In Mouloua, M. &Koonce, J.M., (Eds.) Human-automationinteraction: Research & Practice, Mahwah,NJ: Lawrence Erlbaum.

Degani, A. and Heymann, M., Meyer, G., andShafto, M. (2000). Some Formal Aspects ofHuman-Automation Interaction, NASATechnical Memorandum 209600, NASAAmes Research Center, Moffett Field, CA.

Degani, A. and Heymann, M. (2002). FormalVerification Of Human-AutomationInteraction. Human Factors.

Federal Aviation Regulation 25.1329.Certification of Flight Guidance Systems.Washington, DC: Code of FederalRegulations.

Kohavi, Z. (1978). Switching and FiniteAutomata Theory. New York: McGraw-Hill.

Leveson, N. (1995). Safeware: System Safetyand Computers. New York: Addison-Wesley.

National Transportation Safety Board. (1997).Grounding of the Panamanian passenger shipRoyal Majesty on Rose and Crown shoal nearNantucket, Massachusetts on June 10, 1995.Washington, DC: National TechnicalInformation Services.

Parasuraman, R., Sheridan, T.B., andWickens, C.D. (2000). A model for the typesand levels of human interaction withautomation. IEEE Transaction on Systems,Man, and Cybernetics – Part A: Systems andHumans, 30(3), 286-297.

Paull, M.C. and Unger, S.H. (1959).Minimizing the number of states inincompletely specified sequential switchingfunctions. Institute of Radio EngineersTransactions on Electronic Computers, 356-367.

Woods, D., Sarter, N., and Billings, C. (1997).Automation surprises. In G. Salvendy (Ed.),Handbook of human factors and ergonomics(pp. 1926-1943). New York: John Wiley.

20

Report Documentation PageForm Approved

OMB No. 0704-0188Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time forreviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewingthe collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations andReports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork

1. AGENCY USE ONLY (Leave

blank)

2. REPORT DATE

March 2002

3. REPORT TYPE AND DATES COVERED

Technical Memorandum4. TITLE AND SUBTITLE

On Abstractions and Simplifications in the Design of Human-Automation Interfaces

5. FUNDING NUMBERS

548-40-12

6. AUTHOR(S)

Michael Heymann and Asaf Degani

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

NASA Ames Research CenterMoffett Field, California 94035-1000

8. PERFORMING ORGANIATION

REPORT NUMBER

IH-024

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration

10. SPONSORING/MONITORING

AGENCY REPORT NUMBER

NASA/TM—2002–211397

11. SUPPLEMENTARY NOTES

Point of Contact: Asaf Degani, M/S 262-4, Ames Research Center, Moffett Field, CA 94035(650) 604-0013

12A. DISTRIBUTION/AVAILABILITY STATEMENT

Subject Category: 03-01, 63-02 Distribution: PublicAvailability: NASA CASI (301) 621-0390

12B. DISTRIBUTION CODE

13. ABSTRACT (Maximum 200 words)

This report addresses the design of human-automation interaction from a formal perspective thatfocuses on the information content of the interface, rather than the design of the graphical userinterface. It also addresses the issue of the information provided to the user (e.g., user-manuals,training material, and all other resources). In this report, we propose a formal procedure forgenerating interfaces and user-manuals. The procedure is guided by two criteria: First, theinterface must be correct, that is, with the given interface the user will be able to perform thespecified tasks correctly. Second, the interface should be succinct. The report discusses theunderlying concepts and the formal methods for this approach. Two examples are used toillustrate the procedure. The algorithm for constructing interfaces can be automated, and apreliminary software system for its implementation has been developed.

14. SUBJECT TERMS

Interface design, Formal methods, Human-automation interaction15. NUMBER OF PAGES

20

16. PRICE CODE

17. SECURITY

CLASSIFICATION

OF REPORT

18. SECURITY

CLASSIFICATION

OF THIS PAGE

19. SECURITY

CLASSIFICATION

OF ABSTRACT

20. LIMITATION OF

ABSTRACT

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)Prescribed by ANSI Std. Z-39-18

298-102