modeling and simulating work practice: a method for work...

32 1094-7167/02/$17.00 © 2002 IEEE IEEE INTELLIGENT SYSTEMS

H C C a t N A S A

Modeling and Simulating WorkPractice: A Method forWork Systems DesignMaarten Sierhuis, Research Institute for Advanced Computer Science/Universities SpaceResearch Association at NASA Ames Research CenterWilliam J. Clancey, University of West Florida and NASA Ames Research Center

Work systems involve people engaging in activities over time—not just with

each other, but also with machines, tools, documents, and other artifacts.1

These activities often produce goods, services, or—as is the case in the work system

described in this article—scientific data. Work systems and work practice evolve slowly

over time. The integration and use of technology, thedistribution and collocation of people, organizationalroles and procedures, and the facilities where thework occurs largely determine this evolution.

Improving or redesigning systems is sometimesaccomplished through a business process reengi-neering approach.2 Business process reengineeringis usually based on business process flow analysis,typically performed by business consultants whofocus on work products. The result is usually animprovement involving technology, such as a work-flow tool. We call this a machine-centered approachfor work systems design because functional trans-formations are the focus of attention. However,focusing on the flow of products and data through awork system often ignores the way the people in theorganization actually prefer to work.3,4 As a result,engineers often receive requirements for new tech-nology without a thorough understanding of how thenewly designed system might affect human com-munication, collaboration, and workspaces, as wellas problem solving and learning.

In this article, we present a human-centered worksystem design method based on modeling and sim-ulating work practice—that is, what people actuallydo. Rather than abstracting human behavior as workprocesses or tasks—functional idealizations of thework to be accomplished—we model people’s activ-ities comprehensively and chronologically through-out the day.5 We emphasize that an analysis of how

work gets done must be open to understanding theeffects of behaviors in different places and times,details often omitted in a product-oriented task analy-sis. For example, someone might not schedule meet-ings at the office before 10:30 a.m. because of ababysitter’s schedule, or he or she might use sched-uling software on a computer at home to reservemeeting rooms for later that day. Such practices arerelevant to the design of workplace facilities andscheduling. We call our method human-centeredbecause we focus on how people organize their worklife and the details of their practices. We believe thisbest suggests work system transformations, includ-ing any different tools and processes that might even-tually be required.3 For a look at other relevantresearch, see the sidebar “Related Work.”

The Brahms language: A model-basedview of work practice

Most engineering disciplines have methods andtools to help in understanding complex system inter-actions; often such tools help engineers develop sys-tem prototypes. We have developed a tool calledBrahms that supports our method for modeling andsimulating work practice.6,7 Brahms is a multiagentmodeling and simulation environment for dealing withthe complex human–machine system interactions.

In software engineering, model-based refers to asystem design approach in which the system isdescribed in terms of the structure and behavior of

Modeling actual

human activity

requires understanding

the effects of

communication,

collaboration,

teamwork, tool and

workspace usage, and

problem solving and

learning behavior.

Using a work system

design method that

contains these variables

can produce powerful

insights into complex

system interactions.

defined components.8 In particular, to modelthe work practice of a human activity system,we must create a dynamic model that showshow the system changes over time. Figure 1describes an operational method for devel-oping a formal computational model and asimulation of a work practice for a humanactivity system. It also shows the relationbetween four methods for using Brahms in amodeling effort.

Method M1: Work practice analysisThe purpose of method M1 is to observe

and analyze a human activity system.9,10 Thegoal of the analysis is to gather useful data thatinformally describes work practice and thento create (with the Brahms language) a formalmodel of work practice in M2. M1 modelers

should be workers from the work system,work system designers, and anthropologists.

Method M2: Formal model of thework practice

The purpose of method M2 is to formal-ize the informal data gathered during M1. InBrahms terms, this is where we develop theBrahms model. The formal-system model-ers translate the informal models developedin M1. The formal modelers and the infor-mal modelers do not necessarily have to bethe same; in fact, the skill sets for these twotypes of modelers differ significantly. For-mal Brahms modelers are usually peoplewho understand the concept of agent-basedmodeling and simulation and often haveexperience in developing rule-based systems.

Method M3: SimulationIn Method M3, formal modelers run the

Brahms simulator with the model as inputand the work practice simulation as output.The M3 method is the Brahms compile-simulate-debug cycle, because the modelerwill compile, simulate, and fix the errors inthe formal model until the desired agentbehavior is simulated.

Method M4: Observing the simulation

The purpose of method M4 is to observeand investigate the work practice simulationoutput and compare it with the human activ-ity system with the objective of creating ashared understanding of the results of thework practice model and simulation. The

SEPTEMBER/OCTOBER 2002 computer.org/intelligent 33

Several researchers have developed different work designapproaches through qualitative work in interdisciplinary aca-demic fields that combine social science with a system analysisperspective.1,2 A wave of Scandinavian participatory-designprojects conducted in the late 1980s partially stimulated thisrush.3 We have adopted two principles from the Scandinavianparticipatory-design approach: redesigning a work systemrequires understanding how the work is actually performed,and participatory means that the workers must participate asdesigners of their system.

This Scandinavian approach is essentially human-centeredbut does not generally involve formal modeling of human–system interactions, as in Brahms. For example, contextualdesign4 is based on the development of mostly paper-basedmodels of a work system.

The lack of a theory of work practice has hampered thedevelopment of a generic work system engineering approachbecause it makes work system design an art. What is needed isa theory and an associated method for developing formalmodels of work practice. This will bring a human-centeredwork system design approach into mainstream methods fortechnology development, especially software engineering.Such an approach facilitates design conversations, creating adesperately needed bridge between scientists, workers, andtechnology engineers.

We can use a formal model of people’s work practice as adesign model for how technology impacts the total system—aholistic system design approach. Developing formal models ofwork practice means we need to model people’s behavior atthe activity level. Relevant work in modeling and simulatinghuman behavior comes from different scientific disciplines:

• The business process modeling and simulation communitycreates formal specifications of an organization’s businessprocesses.5

• Cognitive-modeling tools, such as Soar and ACT-R, incorpo-rate a cognitive theory for predicting human mental pro-cesses in controlled laboratory experiments.6,7

• The field of distributed artificial intelligence developed thenotion of using multiple agents in complex problem-solvingtasks,8 which is essential for modeling teams of people col-laborating in organizations.

• Computational organization modeling tests theories ofcommunication and optimal decision making in humanorganizations.9

• The computational-economics community uses an agent-based simulation environment (for example, Swarm) as atool for studying economic theories in complex systems.10

Reference

1. J.M. Corbett, L.B. Rasmussen, and F. Rauner, Crossing the Border:The Social & Engineering Design in Computer Integrated Manufac-turing Systems, K.S. Gill, ed., Springer-Verlag, London, 1991.

2. K.J. Vicente, Cognitive Work Analysis: Towards Safe, Productive,and Healthy Computer-Based Work, Lawrence Erlbaum Associates,Mahwah, N.J., 1999.

3. P. Ehn, Work-Oriented Design of Computer Artifacts, Arbetslivcen-trum, Stockholm, 1988.

4. K Holtzblatt and H. Beyer, Contextual Design: A Customer-Centered Approach to Systems Design, Morgan Kaufmann, SanFrancisco, 1998.

5. R.J. Mayer et al., “Framework and a Suite of Methods for BusinessProcess Reengineering,” Business Process Change: ReengineeringConcepts, Methods and Technologies, V. Grover and W.J. Kettinger,eds., Idea Group, Hershey, Pa., 1998.

6. A. Newell, Unified Theories of Cognition, Harvard Univ. Press, Cam-bridge, Mass., 1990.

7. J.R. Anderson and C.J. Lebiere, The Atomic Components ofThought, Lawrence Erlbaum Associates, Mahwah, N.J., 1998.

8. P.E. Agre, “Computational Research on Interaction and Agency,”Artificial Intelligence, vol. 72, nos. 1–2, 1995, pp. 1–52.

9. K.M. Carley and M.J. Prietula, eds., Computational OrganizationTheory, Lawrence Erlbaum Associates, Mahwah, N.J., 1994.

10. F. Luna and A. Perrone, “Agent-Based Methods in Economics andFinance: Simulations in Swarm,” Advances in Computational Econom-ics, A.N. Hans Ammam, ed., Kluwer Academic, Norwell, Mass., 2002.

Related Work

result might be suggestions for changes tothe formal model—for example, to performa what-if scenario. Thus, there is a modelingand simulation cycle between M1, M2, M3,and M4, which means these methods mustbe closely integrated if we want this cycle tobe complete.

We used the Brahms modeling process inthe case study described in this article.Because the work system from the case studydid not yet exist, the analysis of the workpractice (M1) became an analysis of the worksystem based on similar previous missionsand the proposal for the new mission. Dur-

ing this analysis, the work practice analystworked with the mission project team mem-bers (including the principal investigator,mission scientists, and roboticists) who hadpractical experience with similar work sys-tems. After this initial work practice analy-sis, the Brahms modeler developed an initialformal model of the work system (M2) inBrahms. Then the modeler compiled, simu-lated, and fixed the errors in the formal modeluntil there was a high-level simulation (M3)of the complete work system. Next theBrahms modeler reviewed the model andsimulation results with the mission projectteam members to verify the model and getmore detailed information about the workpractice (M4). The M2–M3–M4 cycle hap-pened three times over a period of sixmonths. Our case study gives a more detailedexplanation of the development of a Brahmsmodel as a part of M2 and M3.

Developing a model of work practice

Figure 2 shows how our epistemology ofwork practice, formalized in the Brahmsmodeling language and made operational inthe Brahms simulation engine, relates a sim-ulation to a real-world human activity sys-tem. The empirical relational system (ERSin Figure 2) is the human activity systemunder observation in Figure 1. The purposeof Brahms is to make modeling the ERS pos-sible and to create a work practice model thatthe Brahms simulator can execute.

In general, Brahms models represent workwith much more detail than business processmodels but somewhat less detail (and farmore broadly) than cognitive models. Con-siderable effort is devoted to modelingobjects (for example, fax machines) andcomputer systems, with which people ofteninteract to accomplish their work. TheBrahms language and simulation enginerelates several levels of detail (areas andobjects, groups and agents, activities andactions) and integrates different perspec-tives—physical, cognitive, and social.

Typically, a modeler sketches a Brahmsmodel by specifying the geography andgroups first. The grain size of the simulationclock (time per tick) might vary from onesecond or less to five minutes or more,depending on the information available andmodeling purposes. Common objects andactivities such as telephones and phone con-versation can be easily reused or adapted, bythe modeler, from other Brahms models.

34 computer.org/intelligent IEEE INTELLIGENT SYSTEMS

H C C a t N A S A

Work practicesimulation

Human activitysystem

M1Analyze

work practice

M4

Used in Used in

YieldsYields

YieldsYields

Observingsimulated

work practice

M2Formal

modelingof the WP M3 Simulation

Used in

Used in

Soft-systems modelers

Formal-systems modelers

Informal static models

Formal static models

Figure 1. Brahms work practice modeling process of the human activity system.

Is specified in

Describes aspects of

Work practice modelof a real-world

environment in Brahms

Made dynamic by

Defines elements of

Generates

Brahms simulator

FRS

Brahms dynamicbehavioral model of the

work practice

Epistemology ofwork practice

Work practicein real-worldenvironment

ERS

Figure 2. Describing real-world work practice (empirical relational system) withcomputational modeling (formal relational system).

Work practice is a set of related modelsthat we can view independently, whichmakes the modeling effort easier:

• Agent. The agent model is a group-agentmembership hierarchy of the people in thework system. Brahms groups can repre-sent formal roles and functions or be basedon location, interpersonal relations, inter-ests, and so forth.

• Object. The object model is a class hierar-chy of all the domain objects and arti-facts—for example, tools, desks, docu-ments, and vehicles.

• Geography. The geography model describesareas in which agents and objects arelocated, consisting of area definitions (user-defined types of areas such as buildings,rooms, and habitats) and areas (instancesof area definitions).

• Activity. The behaviors of agents andobjects are expressed in terms of the activ-ities they perform over time.5 Agent orobject activities are mostly represented atthe group or class level, but they are alsooften specific to agents and objects. Activ-ities are inherited and blended through apriority scheme.

• Timing. Constraints on when the activitiesin the activity model can be performed arerepresented as preconditions of situation-action rules (workframes). Activities taketime, as determined by the predefinedduration of primitive actions. Workframescan be interrupted and resumed, makingthe actual length of an activity situation-dependent.

• Knowledge. An agent’s reasoning is rep-resented as forward-chaining productionrules (thoughtframes) that fall at group andclass levels and can be inherited. Inquiryis modeled as a combination of activities(such as detecting information, communi-cating, and reading or writing documents)and thoughtframes. Perception is modeledas conditions attached to workframes(called detectables). Thus, observationdepends on what the agent is doing.

• Communication. The communicationmodel describes actions by which agentsand objects exchange beliefs, includingtelling someone something or asking aquestion. A conversation is modeled as anactivity with communication actions,either face to face or through some devicesuch as a telephone or email. The choice ofdevice and how it is used are part of thework practice.

Mission operations systemdesign

As an example, let’s look at an initialdesign of a mission operations system for aproposed NASA discovery mission to theMoon with a semiautonomous rover. Thiscase study illustrates the Brahms modelingapproach and the potential gain for engagingin such modeling. Specifically, the modelingproduced useful insights about power con-sumption and its potential impact on scienceobjectives under certain scenarios in the Vic-toria mission.

Victoria is the name of a proposed long-term semiautonomous robotic mission to thesouth pole region of the Moon. (The missionwas named after Ferdinand Magellan’s onlyship that completed the circumnavigation ofthe world.) At the start of this case study, theNASA Victoria team was in the middle ofwriting a mission proposal. The Victoria mis-sion’s team members (principal investigatorand coinvestigators) are world-renowned sci-entists from different scientific disciplines:planetary scientists, geologists, roboticists,and artificial intelligence specialists.

Victoria’s primary mission is to verify thepresence of water ice and other volatiles inpermanently shadowed regions on the Moon.This will be accomplished by gathering lunardata for analyzing the history of water andother volatiles on the Moon and, by implica-tion, in the inner solar system. The teamdecided the most efficient approach wouldbe to use a high-speed semiautonomous roverthat could traverse a long distance (severalhundreds of kilometers) for a long timeperiod (three months to a year) while gath-ering the necessary geological and physicsdata.11 Using the Brahms approach, wedeveloped a model of the total mission oper-ations work system during the proposalphase of the project, including a model ofpeople’s work practice in mission operations,the rover on the Moon, the information sys-tems, and people’s workspaces. With Brahms,we were able to quantify the impact of thehuman work practice on the productivity ofthe rover on the Moon.

The work system is centered on remotehuman–robot interaction. On the basis of therover science data returned, the Earth-basedscience team decides what rover commandsto send next (while trying to maximize thequantity and quality of the returned sciencedata). We should consider the rover as a ser-vant to the science team.

The Victoria mission’s work is distributed

over several human teams and the Victoriarover. In a sense, we can view the Victoria sci-ence team as a user of the teleoperated rover.On the other hand, by virtue of being people’sarms and eyes on the Moon, the rover is moreof an assistant than a simple tool. In particu-lar, the work is distributed between peopleand robot, so we can ask, how do the behav-iors of people and the robot interact? Who isdoing what, where, when, and how?

The Victoria model is limited becauseagents represent teams. We did not modelhow decision making within and betweenteams will occur, making the model lesscomplete. However, our modeling approachis incremental.

Victoria mission operations worksystem

Figure 3 is an informal representation ofthe people and objects in the Victoria worksystem and their locations during the mis-sion. The science team consists of severalsubteams collocated in Building 244 at theNASA Ames Research Center in California:the science operations team (SOT), theinstrument synergy team (IST), and the dataanalysis and interpretation team (DAIT).Two other supporting teams are outside thescience team: the data and downlink team(DDT) and the vehicle and spacecraft oper-ations team (VSOT). These teams worktogether to accomplish the mission’s scien-tific objectives, which involve acquiring cer-tain data from different locations on theMoon. The teams communicate with the Vic-toria rover on the lunar surface using the uni-versal space network (USN) via two separatecommunication links: the high-capacity S-Band direct Earth-to-rover link and the UHFcommunication link (directly and via Victo-ria’s lunar orbiter).

Telemetry and science data will come toNASA Ames via the universal space networkdata connection. Data will be automaticallyconverted by mission information systemsinto accessible formats in near real time andmade available to the teams via visualizationapplications (such as 3D visualization of thelunar surface).

The model’s purposeThe major limitation of current robot

energy modeling tools, apart from problemswith creating and revising models, is theirinability to include human factors in their cal-culations of the rover’s power consumption.Before our case study, the impact of Earth-


based operations on the rover’s energy usagewas unknown. Consequently, one purpose ofthe case study was to determine the effect ofa particular work system design on the

rover’s power consumption during a sciencetraverse into a permanently dark crater.

The Brahms–Victoria model prescribes awork system design by modeling the rover

and the team’s geographical locations andmovements; the activities of all the Earth-based teams, the rover, and the communica-tion actions of both; as well as the missioninformation systems the teams are using.Through this example of the Victoria mis-sion, we are also explicating the Brahmsmodeling language and how the componentsinteract in work practice simulations.

Agent modelFigure 4 shows the group–agent member-

ship hierarchy on which the work system’sdesign is based. The agents in the model arethe Earth-based human teams and the Victo-ria rover, as shown in Figure 3. The teams arerepresented as single agents because at thismoment prescribing each team’s composi-tion and practices in more detail is not pos-sible. For example, the SOT’s “plan a com-mand sequence” activity represents theteam’s work, whereas each team member’sindividual activities remain unspecified.


H C C a t N A S A

Victoria Web site

Scienceoperations team

Scienceteam

Building 244NASA ARC

Moffett Field, Calif.

Data analysis andinterpretation team

Data anddownlink team

Vehicle &spacecraft ops team

Data access/visualization systems

Real-time dataconversion systems

Instrumentsynergy team

USN satellite dish

12 Kps or 1 Mbps

Moon

Lander

Permanentlydark

crater

USN

Teleoperationsystem

USN

DVDstorage

Orbiter

Earth Rover

UHF

256 Kbps

UHF

256 Kbps

S-Band

Figure 3. The Victoria lunar mission work system.

MyBaseGroupGroup

Data communicatorGroup

Victoria teamGroup

Victoria roverAgent

Data analysis andinterpretation team

Agent

Vehicle and spacecraftoperations team

Agent

Instrumentsynergy team

Agent

Scienceoperations team

Agent

Data anddownlink team

Agent

RoverGroup

Science teamGroup

Figure 4. The Victoria agent model.

VictoriaRover is modeled as an agentbecause it has behaviors (including primitiveactions that change the world), movements,and communications. Strictly speaking,activities of designed objects are only formalprocesses, whereas activities of people areconceptualizations of actual behavior. How-ever, in a Brahms model, both are abstrac-tions in a formal language. So, the distinc-tion is how we interpret the model—what itrepresents, rather than how the simulationexecutes the activities of agents versus theactivities of objects.

Table 1 shows a possible distribution ofthe functions over the Victoria teams.12

Details of how different teams collaborate toperform these functions constitute the workpractice of the different agents, specified inBrahms workframes and expressed as situa-tion-action rules.

An example SOT workframe for creatinga command sequence for finding water iceis (paraphrased): “When I believe that thereis a possibility we can find water ice at thecurrent location of the rover, then start theactivity of finding water ice.” Generically, aworkframe is of the form, “When (I believe{X}*) Do {activity A, conclude a new beliefand/or fact}*.”

Object modelA Brahms object model consists of the

classes and instances of physical artifacts aswell the data objects created during the sim-ulation. The Victoria object model (see Fig-ure 5) includes classes for the science instru-ments on the rover as well as other objectscontained in the rover, such as the carouseland the battery. The data communicator classincludes the objects for S-Band and UHFcommunication. The model also representssoftware systems that receive, convert, andvisualize mission data. The Data and Core-

Sample classes dynamically create datainstances and lunar core sample objects dur-ing the simulation.

Geography modelThe Victoria geography model (see Figure

6) represents locations on Earth and theMoon. The dotted lines in Figure 6 showclass-instance relationships, whereas thesolid lines show part-of relations.

The Victoria teams and systems arelocated in Building 244 at NASA AmesResearch Center, and the UsnDish1 satellitedish is located in the area UsnSatelliteLoca-tion. Locations for the simulated scenario are

represented on the Moon; ShadowEdge-OfCraterSN1 represents the rover’s locationat the start of the simulation (the shadowedge that is in crater site number 1). Shad-owArea1InCraterSN1 represents the locationin the permanently shadowed SN1 craterwhere the rover will perform a drilling activ-ity. The LandingSite area is only representedfor completeness.

Victoria simulation scenarioThe Victoria proposal spells out many sur-

face activities that the rover will perform incoordination with the teams on Earth. Forthis case study, we selected the activity of


MyBasegroup

CoresampleDataData

communicatorContained

objectBoreStemEnergyconsumer

Scienceinstrument

Clementine datafrom shadow edge

in crater SN1

Roverbattery

Instrumentcarousel

VictoriaorbiterUsnDish1

SATMNeutronspectrometer

Auger

Visualizationsystem

Tele-operationsystem

Dataconversion

system

S-BandMGA

Softwaresystem

UHFcommunicator

Universalspace

network dish

S-Bandcommunicator

Orbiter

Figure 5. The Victoria mission object model.

Table 1. Functional activity distribution over Victoria teams.

Process Science Instrument Data analysis and Data and Vehicle and spacecraft Roveroperations team synergy team interpretation team downlink team operations team

Uplink 1. Maneuver 1. Commands for 1. Long-term 1. Telecom- 1. Maneuver commands 1. Commandcommands engineering planning for munications 2. Command sequences execution

2. Command operation of robot science commands for experiment sequences for or spacecraft opportunities operationexperiment 2. Emergency or operation anomaly resolution

commands

Downlink 1. Monitoring of 1. Data quality 1. Experiment 1. Experimenthealth and assessment data collection data status telemetry 2. Experiment 2. Data processing collectionfrom robot data collection and enhancementsubsystems

searching for water in permanently shad-owed craters:

The rover arrives at the shadow edge of cratersite number 1. The battery is fully charged. Onthe basis of the data analysis by the Earth-based teams of the Clementine data availablefor the shadow edge area of crater site number1, the science team decides where to enter thiscrater and search for water ice. As the roverenters the crater, it takes hydrogen measure-ments with the neutron spectrometer. Whenthe rover arrives at the assigned location withinthis crater and finds hydrogen there, the sci-ence team decides to drill 10 cm into the sur-face using the sample acquisition and transfermechanism (SATM) and collect a 1.0-cc lunarsample. When the rover receives this com-mand, it starts the drilling activity and finallydeposits the sample into the instrumentcarousel.

The rover uses two instruments in this sce-nario: the neutron spectrometer (to detecthydrogen—most likely caused by water ice—within the first half meter of the lunar surfacebelow the rover) and the SATM.

The simulation model’s backbone consistsof three primary activities: data uplink, roveroperations, and downlink.

Simulation resultsThe simulation lets us visualize the work

system’s behavior over time—that is, activi-ties, communication, and movement of eachagent and object in the work system. TheBrahms simulation engine executes the modelafter it is compiled. The simulation engine cre-ates a relational database, including every sim-ulation event. A Brahms model display toolcalled the AgentViewer uses this database todisplay all groups, classes, agents, objects, andareas in a selectable hierarchical browser. TheAgentViewer’s user can select the agents andobjects he or she wants to investigate to under-stand what occurred during the simulation. TheAgentViewer displays an activity timeline ofthe selecting agents and objects, highlightingthe communications. Let’s look at the results ofthe Victoria model simulation based on screen-shots from the AgentViewer application.

Data uplinkThe scenario starts with the DAIT retriev-

ing the Clementine data image of the shadowedge area, where the rover is located. Theteam reviews this image using the visualiza-tion system, represented by the Visualiza-

tionSystem object.According to the work practice, the

DAIT does this without anyone requestingto look at the data. This means that it needsto know

• The rover’s location and situation• Whether data is available and needs to be

retrieved • Where and how it can retrieve data

Once the DAIT has retrieved the images,it communicates this to the SOT, and the twoteams collaboratively analyze these images(the AnalyzeRoverImages activity). At theend of this analysis activity, the SOT plansthe first rover command sequence. Accordingto the scenario being simulated, the SOTdecides the rover needs to drive for a speci-fied time (15 minutes) into the crater to a spe-cific location (ShadowArea1InCraterSN1)and that while driving it should use its neu-tron detector instrument to detect hydrogenin the lunar surface. This decision is com-municated to the VSOT (and the DAIT).After this communication, the SOT waits forthe rover’s downlink data.


H C C a t N A S A

Planet Location City BuildingUniverse

Building244: Building

Initial agent location = SOT, IST, VSOT DAIT, DDTInitial object location = Teleoperation system Real-time data conversion system Data access/visualization system DVD storage

NasaAmes: CityMoon: PlanetEarth: PlanetVictoriaGeography: Universe

ShadowArea1InCraterSN1: Location

UsnSatelliteLocation: Location

Initial agent locationInitial object location = UsnDish1

ShadowEdgeOfCraterSN1: Location

Initial Agent Location = VictoriaRoverInitial Object Location

LandingSite: Location

BaseAreaDef

Figure 6. The Victoria geography model.

RoverThe Victoria rover is modeled as an agent,

whereas the neutron spectrometer and SATMinstruments are modeled as separate scienceinstrument objects contained in the rover. Inthe scenario, the NeutronSpectrometer objectis active and creates a HydrogenData_1object containing the hydrogen data that aresent to Earth while the VictoriaRover is tra-versing to a permanently shadowed areawithin the crater SN1 (see Figure 7). Therover then waits for the next commandsequence from Earth. Meanwhile, the Earth-based teams analyze the hydrogen data anddecide what to do next. In the second uplinkactivity, the VSOT commands the rover tosearch for water ice in the permanent darkarea. This triggers the SATM instrument tostart the drilling activity.

To collect a sample the SATM must

• Lower its auger to the surface• Drill to the depth given as part of the com-

mand by the Earth-based science team (inthis scenario, the command is to take a 1.0-cc sample at a 10-cm depth)

• Open the sample cavity door• Continue drilling to collect the sample• Close the sample door when done• Retract the drill from the surface• Deposit the collected sample on the instru-

ment carousel (see Figure 7)

The activity durations for drilling into thesurface are dynamically derived during thesimulation of the rover’s drilling activities.Honeybee Robotics, the designers and man-ufacturers of the SATM instrument, pro-vided data for the time it takes to move theauger to the surface and to open and closethe sample door, and the average time ittakes to drill the auger into, and retract it outof, the lunar surface.

DownlinkWhen the rover detects hydrogen in

the ShadowArea1InCraterSN1 location,the downlink process starts. The BrahmsAgentViewer in Figure 8 demonstrates this.

The VictoriaRover agent contains the S-Band medium-gain antenna object, whichrepresents the S-Band transmitter on therover. The VictoriaRover creates a data objectwith both the current rover location infor-mation and the hydrogen data. This dataobject is then communicated to Earth via theUsnDish1 object. The UsnDish1 object com-municates the data to the DataConversion-

System located at NASA Ames. As Figure 8shows, the DataConversionSystem performstwo conversion activities, one for the hydro-gen data and one for the location data fromthe rover. The work system design requiresthe data conversion system to interact withthe visualization system without humanintervention. Requirements for these systemscould have easily been modeled in moredetail in the Brahms model, but this was notthe focus of the case study.

When the VisualizationSystem receives thenewly converted data, the system alerts theDAIT. A member of the DAIT monitors theVisualizationSystem while in the activityWatchForDownlink. When the DAIT agentdetects newly available neutron detector andlocation data, it retrieves the data from theVisualizationSystem object (that is, the activ-ities RetrieveNeutronData, InterpretNeu-tronData, and FindRoverLocationData). Thissimulates the DAIT members looking at andinterpreting the rover’s neutron and locationdata using the visualization system.

Next, the DAIT communicates its findingsto the SOT. In this example scenario, thehydrogen data suggest that the rover has foundhydrogen in the ShadowArea1InCraterSn1area. Given this finding, the SOT determines

the next command sequence for the rover andcommunicates this decision to the VSOT.

The communication informs the VSOT totransmit the command sequence to the Vic-toriaRover. The command sequence tells theVictoriaRover to start the SearchForWater-IceInPermanentDarkArea activity. It alsotells the VictoriaRover that its subactivity,which should occur during this primaryactivity, is to perform the DrillingActivity.Parameters indicate how deep to drill andhow big a sample to collect at that depth. Fig-ure 8 shows part of this second uplink process.

The duration of this downlink and seconduplink process determines the length of theVictoriaRover’s DoNothing activity, repre-senting the time the rover must wait for theVictoria science team to design the next com-mand sequence.

Modeling the rover’s energy consumption

The scenario identifies the energy usageduring all the rover’s primitive activities,based on each subsystem and instrument onthe rover requiring power during a specificactivity. The rover designers, the RoboticsInstitute at Carnegie Mellon University,provided the power consumption specifica-


Figure 7. Victoria rover scenario activities.

tion for the rover’s low-level activities. UsingEquation 1, the simulation calculates energyusage during each rover activity in Equation 2:

Power consumption for rover at time t Prover(t) =

power for driving + power for command

& data handling+ power for science instrumentation + power for communications+ power used for thermal protection + other (not measurable power)

(1)

Eacti (2)

The rover’s total power consumption duringthe scenario can then be calculated, in thesimulation, by adding all the energy usagesfor each rover activity:

Eacti (3)

Figure 9 shows energy consumption forevery rover activity during the simulation.The energy the rover uses during the waitingactivity is defined by the energy needed forThermal Protection during driving + Com-mand and Data Handling during driving.This means that even while the rover is stand-ing still and “doing nothing,” it consumespower for its thermal protection and its com-mand and data handling for its subsystems.

Another interesting variable is the rover’senergy usage rate. The power level in the bat-tery object at the start of the scenario is inwatts/hour. The simulation calculates howmuch power the rover uses, in watts, on thebasis of the activities it performs over time,resulting in a total power consumption at theend of the scenario. The EnergyRate is thepercentage of power usage of the rover forthe scenario: the amount of power consumedby the rover in this scenario given the totalpower available in the battery at the begin-ning of the scenario.

EnergyRate= Total Power Consumption (W/hr)/

Power of battery at start of scenario (W)

(4)

Recalling the scenario involves driving 900meters into the crater and taking one 1.0-ccsample at 10-cm depth, and using Equations

Total Power Consumption ==∑i

n

0

= ( )∫ Prover t dtstart of act

end of each act

i

i


H C C a t N A S A

120

100

80

60

40

20

0

99.0486.84

33.96

0.37

49.52

wt_Traverse

ToLocationInShadowArea

wt_CommunicationCurren

tLocation

wt_Waiting

wt_ProcessUplinkData

wt_Drilling

Wat

ts/h

our

Figure 9. Rover energy used in high-level activities from simulation history database.

Figure 8. Simulation of downlink and second uplink command activities.

3 and 4 (together with the data correspond-ing to the current work system design), wefind the EnergyRate equals approximately0.30 (or 30 percent per hour). In other words,the rover consumes almost one-third of itspower during the scenario. The energy con-sumption rate of the rover was higher than theVictoria team expected, because the time therover had to wait in the permanent dark craterfor the next command from the science team(see Figures 6, 7, and 8) had been previouslyleft out of the mission design. While waiting,the rover consumes thermal and communica-tion power. The longer the downlink–uplinkdecision cycle of the mission operation teams,the more power the rover consumes.

The length of this human decision cycle isdependent on the work system design; thus,the energy consumption rate of the rover(EnergyRate) is also dependent on the worksystem design. This variable represents thework system design’s rover power efficiencyand is a measure that other researchers canuse to compare different work systemdesigns for their chosen scenarios.

We believe that the Brahms languageapproach and simulation engine are

still in their infancy, with decades of researchand application required before we haveaccomplished our ultimate objective of use-fully modeling the complexities of humanbehavior in work settings. In viewing workbroadly as part of human life, many possibleaspects might be relevant: the nature of iden-tity as played out in interpersonal interactions(for example, office politics and friendships),anthropometric details (such as the abilityto reach controls), decision making (cogni-tive models of reasoning), fatigue, boredom,diurnal rhythm, “external life” (errands andfamily interruptions), and learning (espe-cially by watching and mimicking). Werequire further research and experience inusing Brahms in design projects to decidewhich of these perspectives to include and atwhat level of detail.

Practical challenges to developing reusablemodel components organized by types of set-tings and human interactions exist. To useBrahms to explore a variety of workload con-ditions, it would be useful to have tools for sta-tistically generating cases for simulation analy-sis. We would also need theoretical frameworksfor validating analog models (for example,relating Arctic expeditions to space station

experience and planned missions to Mars).Each model we construct is both an exper-

iment and a revelation. Every setting changesour understanding of work practice and therequirements for modeling it. The practicalboundaries of what is necessary for work sys-tems design and what is only of researchinterest remain to be seen.

References

1. C.H. Pava, Managing New Office Technology:An Organizational Strategy, Free Press, NewYork, 1984.

2. R.J. Mayer et al., “Framework and a Suite ofMethods for Business Process Reengineer-ing,” Business Process Change: Reengineer-ing Concepts, Methods and Technologies, V.Grover and W.J. Kettinger, eds., Idea Group,Hershey, Pa., 1998.

3. P. Ehn, Work-Oriented Design of ComputerArtifacts, Arbetslivcentrum, Stockholm,1988.

4. J. Greenbaum and M. Kyng, eds., Design atWork: Cooperative Design of Computer Sys-tems, Lawrence Erlbaum Associates, Mah-wah, N.J., 1991.

5. W.J. Clancey, “Simulating Activities: Relat-ing Motives, Deliberation, and AttentiveCoordination,” to be published in CognitiveSystems Rev., 2002.

6. W.J. Clancey et al., “Brahms: SimulatingPractice for Work Systems Design,” Int’l J.Human-Computer Studies, vol. 49, 1998, pp.831–865.

7. M. Sierhuis, Modeling and Simulating WorkPractice. Brahms: A Multiagent Modelingand Simulation Language for Work SystemAnalysis and Design, SIKS DissertationSeries no. 2001-10, Dept. of Social ScienceInformatics, Univ. of Amsterdam, Amster-dam, 2001.

8. E. Yourdon, Modern Structured Analysis,Prentice-Hall, Upper Saddle River, N.J., 1989.

9. K Holtzblatt and H. Beyer, ContextualDesign: A Customer-Centered Approach toSystems Design, Morgan Kaufmann, SanFrancisco, 1998.

10. J. Blomberg et al., “Ethnographic Field Meth-ods and Their Relation to Design,” Partici-patory Design: Principles and Practices,A.N.D. Schuller, ed., Lawrence ErlbaumAssociates, Mahwah, N.J., 1993, pp. 1, 26,123–155.

11. N.A. Cabrol et al., “Science Results of theAtacama Nomad Rover Field Experiment,Chile: Implications for Planetary Explo-

ration,” J. Geophysical Research, vol. 106,no. E4, 2001, pp. 7664–7675.

12. S.D. Wall and K.W. Ledbetter, Design of Mis-sion Operations Systems for Scientific RemoteSensing, Taylor & Francis, London, 1991.

For more information on this or any other com-puting topic, please visit our Digital Library at http://computer.org/publications/dlib.


T h e A u t h o r sMaarten Sierhuis isa senior research sci-entist at the ResearchInstitute for AdvancedComputer Science (aninstitute of the Univer-sities Space ResearchAssociation at NASAAmes Research Cen-

ter), where he manages the Brahms project onmodeling and simulating work practice. Hisresearch interests are multiagent modeling lan-guages and their application to the developmentof human-centered systems. Before joiningRIACS, he was a member of the Work SystemsDesign group and the Expert Systems labora-tory of NYNEX Science & Technology. He alsodeveloped expert systems as a senior knowledgeengineer in the Netherlands and at IBM. Hereceived his PhD from the Department of SocialScience Informatics at the University of Am-sterdam. Contact him at RIACS, M/S T35B-1,NASA Ames Research Center, Moffett Field,CA 94035-1000; [email protected].

William J. Clancey isa senior research scien-tist at the Institute forHuman & MachineCognition, Universityof West Florida, Pen-sacola, and chief scien-tist for human-centeredcomputing at NASA

Ames Research Center, Computational SciencesDivision. His current interest is the relation ofdescriptive cognitive theories to human experi-ence and neural processes. Before joiningIHMC and NASA, he was a founding memberof the Institute for Research on Learning, wherehe codeveloped the work system design meth-ods of business anthropology in corporate envi-ronments. He also did research in artificial intel-ligence at Stanford University’s KnowledgeSystems Laboratory. He received his PhD incomputer science from Stanford University. Heis a member of the steering committee of theMars Society and serves as a NASA VisitingResearcher for the Challenger Center’s schooloutreach program. Contact him at the Compu-tational Sciences Division, M/S 269-3, NASAAmes Research Center, Moffett Field, CA94035; [email protected].

modeling and simulating work practice: a method for work...

Documents