Cognitive Systems Engineering Modeling Profile

The Cognitive Systems Engineering Modeling Profile (CSEMP):

Enabling a Set of Descriptive and Validation Logics to

Extend the Unified Modeling Language to Support Cognitive

Work and Task Analyses

By Jerry A Gordon

Submitted in fulfillment of requirements for HFS699,

Independent Study

Embry Riddle Aeronautical University (ERAU) Human Factors

and Systems Department

Table of Contents

List of Figures...........................................i

List of Tables...........................................ii

Abstract..................................................1

Introduction..............................................1

Purpose of this Study.....................................6

Method....................................................9

Complex Systems and Cognitive Systems Engineering........10

Unified Modeling Language, Architecture and Profiles.....19

Cognitive Systems Engineering Modeling Profile - Key

Concepts from Cognitive Work Analysis....................28

Conclusions and Recommendations..........................45

References...............................................46

List of Figures

Figure 1. Different Task Analysis Perspectives of Work and the

World, adapted from Hollnagel & Woods, 2005..............13

Figure 2. Components of the Man – Machine Systems viewed as

organizations interacting with their Environment. The Human

Machine Interface (HM) becomes the focus in cognitivist

methods..................................................16

Figure 3. Examples of Graphical Symbols used in the UML

descriptions of utility, structure and behavior..........24

Figure 4. Concepts that define an Architectural Framework as

per IEEE 1471............................................26

Figure 5. Hierarchy of meta-models that compose the CSEMP. UML

Package Classes embody the JCS architectural Framework.. .27

Figure 6. Goals Means Decompositions. Adapted from Hollnagel &

Woods, 2006..............................................29

Figure 7. Use Case Diagram Example of an Organization. Used to

Model the top of a Abstraction Decomposition Space.......30

Figure 8. Carrier Flight Control Block Definition Diagram.

This allows us to logically group the elements in our

functional abstraction hierarchy, and add users , or

technology, as they are determined.......................32

Figure 9. Example Package Diagram for the Carrier Flight

Center. It depicts how we are binding concepts such as

“system” to names articulated differently for a CSE view

(developed with the ACWA method) and as used to develop a

manufacturing parts list.................................37

Figure 10. Activity Diagram for Flight Management Procedures.

Used to Evaluate Allocation Strategies...................40

Figure 11. Example of using Parametric Diagram to Capture

Cognitive Loading and Interface Requirements on a Human

Actor Block. Parametric constraint blocks store systems of

equations to use in simulation based analysis............44

List of Tables

Table 1. CSEMP stereotypes defined for block definition

diagrams, and linked objects in other Diagrams...........34

Table 2. Summary of CSEMP Stereotypes and Logics as used In

Activity Diagrams........................................42

Table 3. Parametric Diagram Stereotypes to support Cognitive

Task Analysis. Validation logic is used to verify

completeness.............................................45

Abstract

Cognitive Systems Engineering is a practitioner’s discipline

that grew out of the human factors community. It developed

to provide practical solutions to the increasing complexity

of modern systems, in particular to address the human

contribution to and implications for this complexity. Coming

as it is from a practitioner’s community, a number of inter-

related methods to conduct CSE that have evolved. However,

while early successes in applying CSE to programs are noted,

it has not achieved the level of general acceptance and

there are noted challenges with integrating the findings of

CSE into the total systems engineering problem; ensuring

that the CSE recommendations actually get built. This study

seeks to address this by offering a graphical modeling

language to capture CSE concepts, built off the Unified

Modeling Language (UML) common to software and systems

engineers.

Introduction

For the first eight years after I left the US Navy, I worked

for a defense contractor that supported a number of applied

research programs in cognitive systems engineering (CSE) for

the development of large, complex systems. Some of the

leading practitioners in the field have written about the

early successes of CSE, although they admit that CSE has not

yet reached the level of general acceptance (Milletello,

Dominguz, Lintern & Klein, 2009). Unfortunately with my

experiences, the programs I worked either were cancelled, or

were significantly over budget and schedule. I could easily

see the value of applying CSE principles in theory, but it

seemed to me that CSE work products were often too time-late

to have positive impact on the program - a characteristic

Vicente calls the Task-Artifact Cycle (Vicente, 1999) – or

that they were given short shrift by management as the

bridge between the CSE work products and immediate value to

the program was harder to demonstrate. The CSE community has

also identified that there are residual challenges in fully

realizing the value of including CSE in programs, especially

given that the conduct of CSE analysis and design is so

costly (Milletello et al, 2009).

In addition, it seemed to me that while the leaders in the

human factors/applied psychology field were adept at

achieving success with CSE principals, the tools available

were too immature to enable success by the more median

practitioner, and thus without a leader’s involvement on a

project, it was more difficult to benefit from CSE

application. In my experience, a new technology has to be

applied with some success by the “one standard deviation

below the mean” practitioner in order to be perceived as

generally adding value. Put another way, while having

Gavriel Salvendy on your team is quite likely to contribute

to success, he is expensive and there is only one of him.

CSE and “traditional” engineering (i.e. the fields of

Systems, Software and Hardware Engineering) integration is

complicated by the spectrum of CSE methods, tools and

dictionaries available. Millitello (Milletello et al, 2009)

writes that there are a number of related CSE approaches,

each of which comes with their own unique language and

acronyms. Moreover, there are two distinct approaches to

integration of humans into complex work environments, most

traditional Human Factors methods embody the “Cognitivist”

approach, which is the underpinning of concepts such as

“Human Centered Design” The alternative is the “ecological”

approach, which evolved from sociology, and which seeks to

examine work from a holistic perspective, with the humans

and their “artifacts” (technology and information transfer

mechanisms as actually used to provide value to human users)

treated on an equal footing. (Hollnagel & Woods, 2003)

While working on the Virtual Environment Landing Craft Air

Cushion (VELCAC) around 2000, Several colleagues and I

started implementing an “encoding scheme” which modeled the

results of Rasmussen’s goals-operators-methods-selection

(GOMS) style cognitive task analysis (CTA). This scheme

aided the development of software simulation fidelity

requirements for a training simulation (Jonassen, D.

Tessmer, M. & Hannum, W., 1999). Revisiting this initial

effort a few years later, we proposed an extension from this

original method, we called the Universal Performance Data

Model – UPDM (Gordon, Burns, & Giebenrath, 2005), which

sought to put performance requirements for system design on

par with human performance requirements, so that designers

could see how they worked together to describe the overall

system operation. The idea was to establish a truly

integrated lingua franca for describing cognitive requirements

in technical engineering terms. It was borne of frustration

experienced (Gordon, Burns, Ricci & Ramsden, 2005) that had

its root in differences between the psychology, technical

and operational perspectives of various stakeholders on a

program we were working.

In particular, we had difficulty in coming up with common

accepted definitions for seemingly simple terms; e.g.

scenario, task and function. Vicente (Vicente, 1999) notes

that the working definitions of “function and task” are

somewhat arbitrary among the Human Factors community. We

found that different stakeholders had vastly different

interpretations that brought the biases of their stake to

their understanding of these terms. This made an analysis

from one perspective very difficult to integrate with an

analysis from the different perspective, essentially every

term related to every other term and little meaningful

relationships could be gleaned from the resulting data

“soup”.

Moreover, the project was concerned with a training

analysis for a new weapon system that had not yet been

placed under contract (much less designed or built).

Applying the traditional human factors engineering process

(Sanders & McCormick, 1993) for functional allocation left

us too many unanswered and unanswerable questions (Gordon et

al, 2005). We all agreed that bringing in HF early in the

process was a good idea, but that the methods available to

us to take full advantage of the opportunity were lacking.

Some advancement would be required to realize the potential

of “integrating HF early”. To this end we proposed some

extensions to the traditional methods to enable some of our

questions at least to be answered (Gordon, Burns, Sheehan,

Ricci & Pharmer, 2005).

This method was at least satisfactory for correcting the

issues that had plagued us in the earlier project, where now

we could speak of organizations having capabilities,

technology performing functions and humans performing tasks.

“Functional Allocation” in the human factors sense was now

about mapping a manpower concept and a systems concept to a

set of desired capabilities, with task definitions that

would become apparent at the intersections of the two.

Instead of an arbitrarily demarked (Vicente, 1999) hierarchy

of “mission, function, task”, we got the set of attribute

manifolds described in our UPDM “risk tensor” (Gordon, et al,

2005) that could be evaluated to find an optimal

automation/human allocation mix. Subsequent use of this

method illustrated some holes in this simplistic

formulation, but it at least provided a starting point.

In reflecting on the problems we encountered, it seemed to

me that the “language” problem was the most significant one

to be addressed. Linguistics science in the early 20th

century held a consensus that the words of a particular

language were reflective of the way its native speakers

actually thought (Putz & Vespoor, 2000). Thus a lack of or

focus on certain related words meant that certain concepts

could not be (or would always be) conceptualized by its

speakers, even if translated into another language, as a

function of their cultural biases embodied in their language

(e.g. the semi-apocryphal 20 Eskimo words for “snow”). This

found its height in the so called “Whorf-Sapir” hypothesis,

(which was not a hypothesis in the strict sense, but a

related collection of loosely stated theories) that had the

above “strong” statement, and a related “weak” statement

that semantics would at least influence the speaker’s

conceptualization of a problem. The Whorfian hypothesis was

largely held in disfavor by the 1980’s. Other theoretical

work in linguistics proposed a “transformational grammar”,

where meaning was common to all languages, and cultural

biases simply hampered the interpretation of meaning

(Radford, 1988). However, subsequent research has provided

evidence for the veracity of the weak component (Putz &

Vespoor, 2000).

Thus to address the language problem, it seems a natural

approach to select an agreed upon framework, and extend

concepts as necessary with caveats. Thus, it is possible to

use the word for which stakeholders are accustomed (e.g.

“interface”) and caveat it with adjectives and nouns so that

they can recognize where the usage was meaningful to them

(Human Machine Interface) and where it was not (Class

Interface). CSEMP provides a framework, which can be

extended by or incorporated into other frameworks, for

capturing the goals-means abstractions and cognitive

workspace content inherent in performing cognitive work

analysis.

Purpose of this Study

The principal purpose of this study is to create a new way

to support CSE, by evaluating the observations I made in the

last 10 years in applying task analysis methods in concert

with a solid foundation in theory. Applicable research

domains include advances in complexity science, practical

and theoretical application of cognitive work and task

analysis, linguistics, and the practical experiences of CSE

practitioners in applying their methods. The study will

culminate in the definition of a graphical language for

encoding CSE analyses of complex systems, particularly of

socio-technical and/or software intensive systems. This

language should be suitable for capturing the required

concepts, along with validation logic to show when the

models were complete, as well as “legal” in the sense that

information elements were linked with elements in a way that

was logically consistent with those concepts. This CSE

language is called the Cognitive Systems Engineering

Modeling Profile or CSEMP.

My hope is by mapping knowledge discovery from CSE methods

to graphical concepts and diagrams familiar to traditional

software/systems engineers, it will facilitate synchronicity

between the problem domain mental models of the psychology

and technical stakeholders. More importantly, as a systems

engineer, I see every program as unique, but I also see that

design resembles doing crossword puzzles. A lot of things I

don’t know at first, but once some words are in place, the

clues and shared letters guide me in finishing the puzzle. I

believe that by capturing the concepts of a complex system

design graphically, it will be become apparent that some

aspects of a notional design are more “defined” or “certain”

than others. Thus the selection of a method to identify and

refine the remaining concepts will become logically

apparent.

In defining the purpose of this study, it will be helpful to

articulate what it is not. First, it is not intended as a

primer on modeling languages; there are plenty of reference

books to define them. It is not intended to evaluate among

the alternatives languages, but chooses one for which this

author is most familiar. Most importantly, this study will

not attempt to ensconce any particular practical CSE

approach. While it approaches the data structure from the

holistic, and thus ecological, perspective, it should be

able to represent data as collected from a “cognitivist”

approach with equal facility as from an “ecological”

approach. As an initial logical check on this goal, it

should be able, with simplifications, to represent

information as modeled by a traditional human factors

analysis (in the same way that in fluid mechanics, the

Navier-Stokes equation simplifies down to Bernoulli’s

equation).

While the initial work (Gordon, et al, 2005) posited a

“universalist” approach, with the idea that the model could

simply be extended as far as it needed to encompass the

entire system under study, I have since decided that

completely universal models are probably infeasible. A

search for a universal language has been around since at

least Isaac Newton, but all attempts have met with failure.

I think the reasons why are best articulated by combining

the notion that “humans are difficult to pin down” central

to human factors with recent advances in complexity theory.

Attempts at imposing universal languages probably fail for

the same “bounded rationality” problem Wolpert (Braha, Minai

& Bar-Yam, 2006) discusses in trying to deterministically

design large complex systems in waterfall fashion –

incomplete information and non-rational actors. It becomes

apparent that a universal model would be just as expensive,

time consuming, and likely to become obsolete faster than it

could be changed as the method I was attempting to augment.

With uncertain future configurations, it is difficult to

model said configurations, and analysis of possibilities

beyond the control of the designers becomes an intractable

problem. Rather than attempt to model everything, a model

should instead attempt to define an initial set of explicit

analytic boundaries, populate these boundaries with concepts

semantically meaningful to the analysts, and then define

strongly typed artifacts as “boundary objects” (Fong, Valerdi,

& Srinivasan, 2007) that can be exchanged at these

boundaries to other stakeholders. Thus, an initial ecology

is defined, with potential flows offered to adjacent

ecologies, which can form “super ecologies” as future

possibilities become more concrete, or the organization

grows in complexity.

Thus it is a principal goal of the CSEMP to identify in

concrete graphical terms “assumptions of scope”. It is in

unmatched assumptions between these system ecologies where

potential miscommunications cause problems in complex system

design (Fong et al, 2007) - Can the system support that

interface? Can it handle data in that range? Can the

operators adapt to the new workload and new nature of the

tasks? What happens to the operators and users culturally?

And what do those cultural shifts mean for the purpose, and

value, of the original system? CSEMP does not seek to answer

these questions; it does however endeavor to see that they

are asked.

Most importantly this study is not intended to be

“finished”. My hope is to start a discussion. I know there

are large swaths of the CSE domain space I have left

untouched, and I have only brushed the content of the

modeling languages I have introduced. However, I feel this

profile might at least provide a useful starting point.

Method

In order to develop the CSEMP, I will relay on my experience

in applying model based systems engineering (MBSE) on over a

dozen DOD programs over the last decade, and comparing my

anecdotal observations to characteristics of the languages

described in the reference literature. Secondly, I will

evaluate concepts as articulated in the CSE literature and

look first for atomic semantic equivalencies to SYSML/UML

concepts, and second for complex definitions based on those

atomic definitions. CSE introduces additional stereotype

extensions as descriptive logic with validation logic

routines. The resulting meta-models must serve the intent

of CSE methods, while avoiding the pitfalls, articulated

well by Vicente, Woods, Hollnagel and Lintern throughout

their works. The results are presented graphically in

SYSML/UML notation with examples in later sections. Since

the purpose of this language is to manage complexity in

systems, it will aid in discovering what “complexity”

actually means.

Complex Systems and Cognitive Systems Engineering

The human factors methods of cognitive task and work

analysis evolved in response to increased complexity of

systems. The original work done in the 1980’s (Bizantz &

Burns, 2009), coincided with the rise of automation and

computer based manufacturing and other work. It is

interesting that there is not a generally agreed upon

definition for what “complexity” actually means (Vicente,

1999).

While there is not a single agreed upon definition, there

are several workable definitions. Suh (Suh, 2001) defines

complexity as the probability of meeting requirements, an

arcane definition that makes the most intuitive sense in the

manufacturing domain from which he developed it. Vicente

defines it in terms of the ability to predict the behavior

of a system; a more mathematical definition that allows for

a lack of stated requirements. Hollnagel and Woods address

it from the perspective of human coping, referencing the

cybernetics “law of requisite variety” – where the number

and range of options to complete the work is at least

equivalent to the number and range of constraints imposed by

the work environment. All of them define complexity in terms

of “information content”; the number of variables that are

present in a system and can impact its behavior; and whether

that behavior achieves desirable ends.

Automation arose to make life easier for humans. While the

potential downsides of technology have been the subject of

authors since “Rossum’s Universal Robots” at the dawn of the

20th century, it was generally thought that automation would

make for less work and it certainly has reduced the need for

human muscle (Hollnagel & Woods, 2005). Subsequent to

actually fielding automated systems, however, it was

discovered that the nature of the work had simply changed,

and that automation came with its own challenges, such as

“automation surprises” (Woods, Patterson, & Roth, 1998). Far

from eliminating humans in the work environment, automation

created a whole new set of challenges for designing work

environments for which humans could succeed (Parasuramen &

Wickens, 2008).

Cognitive systems engineering as a sub discipline within

human factors formed out of a collective of related methods

for performing task analyses, in order to better define

human computer interfaces (HCI) for humans operating

computer controlled or automated equipment. Evolving from

“classical” human factors, which in turn evolved from

information theory of Shannon and Weaver (Hollnagel &Woods,

2006), these methods used cognition as a starting point, and

then built a model of the world around it. This represents a

hermeneutic or “brain in a jar” perspective, where reality

is experienced through sensors and actors, and the job of the

HCI specialist is to identify and design the right sensors

and actors.

The work detailed in the earlier methods developed by my

colleagues and I (Gordon et al, 2005) was derivative of the

Shannon-Weaver paradigm, and classical human factors. It was

part of an effort to merge the traditional systems

engineering methods of functional analysis, while

considering the cognitive impacts of functional allocation.

It was noted (described in detail in a government report

which is not available for citation) that the human centered

stimulus - response model broke down, practically in our

attempts to describe the goals of the organization we were

studying, and identified empirically in the results

tabulated from the surveys of work activity we submitted as

part of the research. To complete the work at the time we

established a set of conventions for crafting events tied to

affective goals rather than acting solely as environmental

stimuli. This method is probably unsatisfactory as well, as

returning to the same data several years later, it was very

difficult to recall or recreate the conditions we used to

establish these conventions. I had a similar experience in

2004 when working on the DDG-1000 program, in developing

discrete event simulation (IMPRINT) operator models based on

the theories of Card, Moran, Newell and Wickens.

Approximately 20% of the cases we studied did not work well

within this stimulus-response based model. I heard this same

20% number during a panel at the 2005 HSI Symposium for a

different Army program using the same modeling tool and

approach.

Fortunately, an alternative philosophy has evolved,

leveraging ideas from sociology; that of an ecological approach

(Hollnagel &Woods, 2006). The ecological approach thinks of

humans and technologies in “Joint Cognitive Systems” (JCS).

These JCS exist with humans and their artifacts interacting

with their environment and identifying, assessing and

achieving human purposes. The technology may be prosthetic

(where the artifact is an extension of the human – an

example of a most extreme case, the “bionic” artificial

limb) or a tool (with a pencil serving as a simple example).

The ecological approach thinks of humans as embodying the

technology to sense, interact and affect the world, thus the

technology must be designed to “mesh” cognitively with the

human. These contrasted perspectives are depicted in Figure

W orld Interface(Prosthetic or Tool) Hum an

Herm eneutic Em bodim ent

Figure 1. Different Task Analysis Perspectives of Work and the World,

adapted from Hollnagel & Woods, 2005.

Several practical approaches to conducting Cognitive Work

Analyses have been designed from this ecological perspective

(Hollnagel, 2003), (Vicente, 1999), (Lintern, 2009), and

(Potter, Elm, Roth, Gualtieri, & Easter, 2001). While

Vicente considers cognitive task analysis (CTA) as a

subspecialty of cognitive work analysis (CWA), I would

consider a CTA as assembling data from the hermeneutic

approach and CWA as assembling data from the embodiment

approach, although Lintern acknowledges that there is no

general agreement on the difference within the CSE

community.

Vicente does point out, however, that the cognitivist

perspective tends to focus on the HMI, since it is here that

the connections between the biological sensors and actuators

and the rest of the world are located. As discussed

previously, this provides for “oversimplification” of the

CTA representation of the “rest of the man-machine” system.

However, I hypothesize that the success realized in applying

cognitivist CTA methods, in such approaches as Human

Centered Design (Vicente, 1999) is due in part to the

relatively closed and fixed nature of the systems for which

it was applied. This is not to say those systems weren’t

challenging, or even apparently complex, but rather the

analysts could adopt a set of conventions and

simplifications that could be understood by the various

stakeholders within the timeframe of a tolerable task-

artifact cycle. Additionally, it may have been true that

most of the behaviors present in the rest of the man machine

system had a direct analog on the HMI, and the description

of the HMI from a cognitive perspective was sufficiently

complete to facilitate this understanding.

To support that second hypothesis, I would submit as

evidence the use of Visual Basic and Microsoft Foundation

Classes (MFC) software frameworks, a dominant de facto

standard in the 1990’s and early 2000’s. Code logic was tied

directly to the under the classes that formed the “window”,

which was the basis of the graphical user interface (GUI).

Thus in a very real way, all software developed with those

frameworks proceeded from its GUI. In fact, Martin’s mid

1990’s software engineering method called “Rapid Application

Development” suggested the development of iterative

prototype GUIs as the best way to actually discover the user

requirements and domain data structure.

In the abstract, however, there is much more to the complete

man-machine system than the humans and their HMI. Moreover,

especially in socio-technical systems which have emergent

social networks and dominant cultural impacts, there is more

to the human portion than individual thinking. Hollnagel

and Woods call this “distributed cognition”. There is also

more to the Machine aspect than an HMI and the underlying

data. Automation has advanced from the information support

and repetitive motion of its early days (Sheridan &

Parasuramen, 2006) to complex decision and action automation

with “fully automatic control”. We now have robots making

decisions and executing actions, and only then informing

their human monitors (Hollnagel & Woods, 2005). Thus it can

be said that there is a lot to the “man machine” system that

exists in the machine space, for which man has no direct

mechanism to interact.

In addition to the human shared cognition and the pure

automation of the machine, there are organizational aspects

which exist above the humans and technology to describe the

system. These organizational aspects include shared culture

and sense of purpose, as well as “institutional knowledge”

that shapes the perceptions of the humans, and defines the

ways in which technology may be applied. Moreover, the

definition of the organization, with formal and informal

networks of command, will determine the rules for

information flow throughout the organization. It is through

these organizational aspects that the cues and responses to

and from the man-machine systems environment are filtered.

This is depicted in Figure 2.

Environm entEffects Cues, Constraints and Pressures

Hum an Aspects M achine Aspects

Organizational Aspects

Figure 2. Components of the Man – Machine Systems viewed as organizations

interacting with their Environment. The Human Machine Interface (HM)

becomes the focus in cognitivist methods.

Complex systems engineering as we currently understand the

concept add a new dimension of difficulty. This is due to

the “open” nature of modern systems, which are constantly

undergoing evolution, expected to be composed in multiple

“systems of systems” which include many components outside

the direct control of the designers or operators. Norman and

Kuras write (Braha et al, 2006) that these open systems are

best viewed as an enterprise that has several characteristics

that distinguish it from a “traditional” system.

Each instance of the enterprise is unique

They are continuously evolving with new requirements

They have ambiguous boundaries

New possibilities are constantly evaluated, tried and

implemented

They are self organizing

They include both internally cooperative and

competitive elements

Sheard (Sheard & Mostashari, 2009) adds that the words

“enterprise” and “architecture” have now become semantically

overloaded and inadequate to discuss the implications of

developing complex systems. In addition to restatements of

the above, she adds that complex systems have a fractal

nature, where the structure of low level components cannot

easily be discovered by analysis of macro level structures,

although they do exhibit repeating patterns on ever

increasing scales.

In order to address the complexity in CSE, Hollnagel and

Woods introduce the term “Joint Cognitive Systems” JCS. This

concept lies at the heart of all ecological approaches. It

identifies an ecology of humans, both augmented with prostheses

and utilizing tools as artifacts, which have been selected to

provide cognitive affordances, or opportunities to accomplish

work. The result is a socio-technical network of shared and

augmented cognition; defining, evaluating, planning and

executing work towards achieving purpose, the goals of which

are established both internally and externally. The intent

of the JCS concept is to enable focus on the totality of the

work environment as an emergent system, rather than a focus

solely on the human-technology dyad, which in practice tends

to shift engineering emphasis to human-machine interface

(HMI) design.

Complex systems theory as applied to socio-technical systems

has benefited from another concept in sociology, that of the

boundary object. Boundary objects are a concept that is used

to bridge the gap between otherwise isolated ecologies of

human society. In the sociological context, this may mean

trade or treaties that govern the relations between

countries or tribes. Fong (Fong et al, 2007) introduces

boundary objects as means to communicate between different

engineering communities of practice (and indeed the very

purpose of this CESMP is to facilitate exchange of that type

of boundary objects). Key concepts from boundary objects are

layering (where one community may add additional comments to

aid in interpretation, equivalent to the view concept

articulated here) and contextualization/de-contextualization (where

senders and receivers encode and decode according to their

own formalisms, and walk away with the correct intended

meaning –analogous in the CSEMP to descriptive logic).

The theoretical basis for the ecological methods lies in the

activity theory of Vygotsky and others, which was developed

as part of Soviet Psychology (Woods & Hollnagel, 2006). They

mandated an anthropocentric frame of reference as being the

only one that matters, i.e. that technology had no meaning

until it was actually used by someone, and that person’s

goals assumed primacy. The affordance becomes a property of

elements in the environment, which are acted upon by the

human users and their tools/prosthesis. This theory was

presented in the 1970’s by Gibson as an alternate to the

Shannon-Weaver paradigm (Albrechtsen, H., Andersen, H.,

Bødker, S., & Pejtersen, A., 2001). In the CSEMP, I chose to

represent concepts such as “artifact” and “affordance” as

complex elements, such that users of the model could capture

both the sterile technology as something to build as well as the

emergent technology as rendered meaningful to humans characteristics

of said technology. The affordance propagates as a reference

property back to the human actors after it has been

associated in the UML.

In addition to the Human Factors “ecological” and

“cognitivist” approaches discussed above, there is a third

set of approaches that have been proposed to address the

human element of complex systems. These methods extend the

classical “systems” paradigm, treating “humans” as simply a

third allocation choice, along with hardware and software.

Systems based methods were the idea behind the top down

functional analysis (TDFA) approach introduced in Gordon

(Gordon, et al, 2005). Hollnagel, however, warns of the

dangers in anthropomorphizing machines or treating humans

too mechanistically (Woods & Hollnagel, 2006) and my

experience is that it is tempting to fall into this trap if

one is not careful. However, I suggest that looking at the

“systems engineering” problem as one of building an

organization (one that includes hardware and software

“systems” as well as people and culture) that these pitfalls

can be avoided, and that with proper book-keeping of

analysis data, aids in crafting this system cum organization

from either of the two HF perspectives. It was my intention

that the CSEMP provide a means to “keep the books.” Critical

to this is graphical based modeling languages like UML.

Unified Modeling Language, Architecture and Profiles

The Unified Modeling Language or UML was developed in the

late 1990’s by three of the leading names in software

development methods: James Rumbaugh, Grady Booch and Ivar

Jacobson (Jacobson, Booch & Rumbaugh, 2000). The three were

hired by IBM to develop a graphical language to help in the

analysis and design of object oriented software, which had

been recently introduced as a means to manage the increasing

complexity of software intensive systems. Since that time,

the UML has been adopted by an advocacy group and standards

body, the Object Management Group (OMG), and undergone

several revisions and extensions.

The purpose of the UML is, as the name implies, to model.

Models are depictions of real world systems that obey some

set of conventions or formalisms (Vicente, 1999). The UML

language, based as it was to support object oriented

computer software languages, preserves several features of

object orientation which are useful constructs for the CSE

purpose. The underlying structure of the UML language is

defined in the Meta Object Facility (MOF), currently in

version 2 (OMG, 2010). The “base class” (the atomic level

convention from which all other UML concepts are derived and

extended) is the element. Characteristics of UML that enable

the goals of the CSEMP proposed in this paper include:

Generalization allows concepts to be specified in a

generic, high level sense and to add additional

information (data) or behaviors (functions) which

increase the level of specificity of objects that are

referenced. Some objects can be defined in a “virtual”

or purely abstract sense. In the physical models of UML

“classes” refer to abstract concepts of things and

“objects” refer to specific things or “instances” which

have added values to the defined characteristics of

their class. This paradigm can be extended to other UML

elements as well, such as use cases, which in the virtual

class sense can represent abstract functions of the

functional abstraction hierarchy.

Inheritance – Inheritance is the property whereby an

element that is a specialization (the corollary to

generalization) of another element possesses all of the

data and behaviors that describe the general element,

along with new data and behaviors unique to the more

specialized element. However, the values of the data

and behaviors, even the inherited ones, are unique to

the new element.

Polymorphism says that behaviors may be context

dependent. Under different circumstances the behaviors

of an element may be processed differently.

Polymorphism allows for the description of “selections”

in classical CTA analyses, as well as environmental

impact of correspondence driven work domains, where the

environment imposes “dynamic considerations” on the

form of work (Vicente, 1999).

Data Hiding/Encapsulation maintains separation of

concerns in Object Orientation. The use of data hiding

is to encapsulate tightly coupled behaviors and data

within a class or component. Classes and components

then communicate through well defined interfaces, so they

may control access to their internal data as the timing

and form of their behaviors. Encapsulation aids in

maintainability of software by reducing the complexity

of the code.

“Paste by reference” means that a particular model or

description can include an element which was introduced

and defined in another model, and rely on the same

instance in both models. In this way, changes to the

item in either model are reflected in the other,

particularly when those changes render the logic of the

other model unusable.

Other important relationships in the UML include:

Aggregation and Composition are represented by solid

and voided lozenges respectively. Aggregation states

that an element is crafted by aggregating two or more

elements that can exist as independent elements (such

as a car aggregated from wheels and doors).

Compositions are elements include subordinate elements

that have no independent existence (a paper may

decompose to an introduction and body, but those are

meaningless unless you have the paper first).

Association and Trace are untyped relationships in UML,

meaning that there aren’t detailed rules on legality of

associations. Conventions are adopted by the model

developer as to which relationships are allowed or

required. Associations may be supplied cardinality

constraints that define the multiplicity, optionality

and directionality of a relationship.

Stereotypes are a mechanism included in UML to allow a

common attribute that can extend the vocabulary of UML

for a specific purpose (for example , UML “class” could

be extended to define <library> and <executable> so

that a code file type can quickly be identified, and

sorted, in the model.

Packages and Namespaces are used to assemble elements

and diagrams of a similar purpose, subsystem, analysis

space or other highly contextual purpose into a

convenient group for reference. Package names are used

to define a “fully qualified name”. The package defines

a “namespace”, which specifies the context to be used

in interpreting the definition of another work used

within a package. This is especially useful when the

same word (e.g. “interface”, which could be a software

control providing a graphical user interface, a

physical cable, a virtual data-less software class used

to pass messages between memory locations, or a phone

call, depending on the audience and usage).

Translation between one namespace and another is known

as a “binding”.

The UML and tools aiding in UML model development are aided

by the use of descriptive and validation logics. These

logics are possible because the language is “strongly

typed”, i.e. it has precise rules for explaining what

concepts are and how they relate. Descriptive Logics

determine what a node is and how it is to be graphically

represented. Validation logics are used to validate that any

model defined in the UML is complete, and possesses only

“legal” relationships (Nantajeewarawat & Wuwonge, 2005). DL

will specify whether a node type can be connected to another

node type, and the nature of the allowable relationships

between the nodes. If an edge does not terminate, or

properly terminate, or if nodes are incomplete, or do not

reference all of the appropriate traces (a function cannot

exist unless a purpose for it existed first), then the model

is not “well formed”. Many UML software tools use validation

logics to discover these “illegal” model elements and will

provide alerts to the user that additional work must be

completed.

Some representative symbol conventions in the UML are

depicted in Figure 3.

Use case<<stereotype>>

Class/Block

State/Activity

Association

Operation/m ethod()Statetransition

AggregationCom positionGeneralization

Utility (Use Case and Requirem ents Diagram s)

Requirem ent

Behavior (State, Activity, and Sequence Diagram s)

Structure (Class, Block and Deploym ent Diagram s)

Figure 3. Examples of Graphical Symbols used in the UML descriptions of

utility, structure and behavior.

The descriptive logics for the core UML are encoded within

the MOF. Validation logics are included as part of the

standard defined by the OMG. The UML MOF is in the

Extensible Markup Language (XML), and thus like all XML is

based on graph theory (Daum, 2003). Graphs includes nodes,

and edges that connect nodes. Nodes and edges have types and

classifiers, known in MOF as “typed identifiers”, that

describe what kind of node they are, and from which an

expectation of information they contain and behaviors they

can perform are built. Edges have an additional

characteristic of trajectory, meaning that they must have an

origin and a target node.

Thus, the MOF defines the “meta-language” of the semantics

and syntax for UML. A deep understanding of MOF is not

essential for describing the CSE profile, although this

understanding was necessary to conduct the analysis. UML

itself still maintains its software centric focus, in that

it is optimized for describing software terms, however, it

has been extended to enable descriptions of more general

things, which can be explained in terms of utility,

structure and behavior. The mechanism for extending UML is

the profile, and MOF describes the rules for defining profiles

(just as English grammar provides rules for adding “er” to

turn verbs like “to read” into nouns like “reader”).

An important profile for work related to complex systems

engineering is the Systems Modeling Language - SySML

(Friedenthal, Moore & Reiter, 2008). SYSML utilizes the

behavioral descriptions of sequence, state and use case

diagrams in the UML, extends the activity diagrams to create

the equivalent of extended functional flow block diagrams

(another important behavioral description). It includes two

new diagrams, Block diagrams used to describe physical

structure and interfaces, and the requirements diagram,

which is built up from the base element class. SYSML is

useful because it is able to describe full systems,

including hardware, software and operator/users, putting

each on an equal footing. This is an important

characteristic for supporting the ecological perspective of

the cognitive work analysis. The use of graphical

requirements models is powerful, as the lowest level of

Rasmussen’s functional abstraction hierarchy is the physical

implementation, which can now be mapped to requirements,

constraints and specifications, the basic language of the

hardware and software engineers required to actualize the

systems, whether designed by CSE or conventional engineers.

The CSEMP provides an architectural framework for defining

Joint Cognitive System (JCS) architectures. Architecture

frameworks are defined by the IEEE 1471 standard for

development of architectures. It defines a particular

stakeholder, who is interested in a subset of information and

normally displays or understands that information as

presented in a certain way, called a view. The stakeholder’s

interest in the view defines the context for interpreting

that subset of model data. Models can be multidimensional

and visually complex, much too complex to be easily read in

their entirety. The concept of a view allows for displaying

only a slice of the model, selecting a subset of available

elements, and depicting it in a particular context. This

context is defined as a viewpoint. This viewpoint exists as

a relationship between the stakeholder and the view (i.e. an

affordance) and is instantiated by the descriptive logic that

define the conventions and content of the model. These

concepts are depicted in Figure 4.

Figure 4. Concepts that define an Architectural Framework as per IEEE 1471.

Architecture, as an engineering discipline distinct from

design, is a relatively new concept (Maier & Rechtin, 2006),

even though it has been done in practice for years.

Architectural defines the basic rules under which a system

is to be built, the major components, the interfaces, and

the general approaches towards composing and selecting the

hardware, software, users and operators of the system. All

systems have an architecture, even if it wasn’t deliberately

conceived, and some are better (or at least, less needlessly

complex) than others. A Framework is a mechanism for

describing or solving a number of different problem sets

that share some basic characteristics (e.g. XNA is a

software framework for writing video games).

UML is a modeling language built off the MOF meta-model,

which is itself a graphical enhancement of basic graoh

theory. SYSML reused some UML model elements and introduced

additional elements to focus on the development of systems,

although they are both internally consistent with each

other, and there is a great deal of overlap possible. CSEMP

is an extension of SYSML/UML to address the needs of CSE.

The hierarchy of content is depicted in Figure 5 (overleaf).

The next section will discuss the meta-elements of the CSE

modeling profile.

Graph Theory

SYSM L

CSEM P

Package

Nam espace View point

Graph Theory

SYSM L

CSEM P

Package

Nam espace View point

Figure 5. Hierarchy of meta-models that compose the CSEMP. UML Package Classes embody the JCS architectural Framework.

Cognitive Systems Engineering Modeling Profile - KeyConcepts from Cognitive Work Analysis

Annet (in Hollnagel, 2003) describes a key concept central

to the conduct of all task analyses, the Hierarchical Task

Analysis (HTA). This tool was initially developed in the

1960’s as an alternative to time and motion studies. It

bears some similarity to the structured analysis methods of

classical systems engineering, in decomposing problems from

high levels to increasingly granular levels of detail, in

assigning the relationship between form and function, and

describing functions in terms of inputs, outputs and

processes.

The HTA has undergone a steady evolution, through the work

domain analysis (Vicente, 1999), to the Functional

Abstraction Hierarchy (Hollnagel, 2003) and many variations

in between. Each of them presents an “abstraction-

decomposition” space (Vicente, 1999) that moves from lesser

to greater levels of specificity and concreteness, starting

with abstract wishes and ending with actual systems in

operation providing value. These models start with a

definition of goals (as attributes of the users, and not

having meaning without them) and decomposes to the means to

accomplish these goals. As the models become increasingly

fine grained, they move from statements of purpose, to

described behaviors to design specifications. Hollnagel &

Woods describe this as answering “why, what and how” with

each successive level providing the components which address

one of the previous levels means as its own goal as depicted

in Figure 6.

Goals -M eans

Next Level of Granularity

Figure 6. Goals Means Decompositions. Adapted from Hollnagel & Woods, 2006.

Lintern takes exception to this model (Lintern, 2009) and

reinterprets it as a “what, what, what” set of questions,

and makes the argument that the concepts should stay

behavioral in scope. He warns against making structural

assumptions too early. Both authors indicate that the lines

of demarcation can be somewhat arbitrary, and state that the

characteristics for splitting up concepts between parent-

child and peer to peer can change as the hierarchy

progresses. I would add based on personal experience that

adding notions of either causality or mixing ergodic and

discrete time in what is otherwise an attribute-

characteristic sorting can complicate future recall, reuse

or interoperability.

CSEMP addresses this by starting with UML use cases, defined

as “functionality of a system in terms of how its users use

that system to achieve their goals” (Friedenthal et al,

2008). Note that “system” here may refer to hardware and

software alone, or it may include humans. However, the UML

notion of “Actor” does represent a human, or other

hardware/software system that is considered external to the

original “system”. To address the apparent discrepancy,

CSEMP utilizes the SYSML “block” concept to establish a set

of analytic hierarchies, decomposing the entire

organization, and identifying sets of hardware and software

as “subjects” within the overall organization, and with

which the actors interact. This is depicted in Figure 7.

Figure 7. Use Case Diagram Example of an Organization. Used to Model the top of a Abstraction Decomposition Space.

This allows us to have an entire organization which exists

in an environmental context we define. This organization can

be composed of humans and technology, and we can arbitrarily

talk about these humans and technology and decompose their

behaviors. We do not have to make any initial normative

assumptions about how to sort the groups, as they can

overlap. The value of graphical models is that relationships

not obvious when examining prose are more easily seen and

the models can be easily changed to reflect new normative

assumptions. Moreover, use cases provide for <<uses>> and

<<extends>> relationships that describe modular reusable

functionality. These relationships can abstract out certain

functions, providing clues to selecting reusable patterns

and frameworks of solutions to address them.

By using the contrast between the aggregation and

decomposition relationships in UML, we can indicate multiple

paths in and out of a particular use case or subject. This

provides a way to track “which things” and “which humans”

are parts of a particular goal as we have stated it. It also

allows us to form the model as a functional abstraction

network, as described by Elm, et al (Hollnagel, 2003), and

it allows us to keep all of the high level definitions

behavioral to address the criticisms of Lintern; the

subject/analytic block mechanism allows us to keep track of

whether we discuss the behavior of a single air intercept

controller, or the behavior of the entire flight control

organization. Aggregations imply “shared” concepts, in this

case, the equipment installed in the CVC suite is shared

between those concerned with flight safety and those

concerned with intercepting targets. Compositions imply

objects which derive their meaning explicitly from the

higher level object they reference. In the case of the

carrier flight control organization, there is only “flight

safety management system” and an “air intercept system”

because there us a carrier flight control system. This is

easily depicted in the associated block definition diagram,

as shown in Figure 8.

Figure 8. Carrier Flight Control Block Definition Diagram. This allows us to logically group the elements in our functional abstraction hierarchy,and add users , or technology, as they are determined.

Figure 8 does not represent a “technology implementation”.

Even the CVC suite is a notional set of hardware and

software at this point. It doe, however, provide a way to

keep track of the notional human roles and notional

technology that will form our organization. As the analysis

proceeds, this diagram will change and increase in detail,

however links between the “subjects” in the use case diagram

and the blocks stereotyped here as <<analysis boundaries>>

and <<technical systems>> are maintained by the use of a

“specifies” association in UML, and changes to the block

elements can be seen to impact on the original goals

hierarchy.

Figure 8 is an example SYSML block definition diagram (bdd),

which uses the block element of SYSML as augmented by

stereotypes to support the CSEMP. These stereotypes and

conventions are to maintain consistency with concepts as

used in CSE. The Stereotypes applied to the blocks are

listed (overleaf) in Table 1. In addition to the

stereotypes, blocks may link to other objects. These

linkages are through the refines, allocates, and specifies

relationships in UML. As increasingly lower level elements

(all the way to hardware parts and software classes) are

defined, these linkages provide cues to the engineering/CSE

team when changes may impact the ability to achieve these

high level goals as they were originally defined. This

diagram also demonstrates some generalization relationships

to detail actors and boundary objects from their more

abstract “base classes”.

Table 1. CSEMP stereotypes defined for block definition diagrams, and linked objects in other Diagrams.

Stereotype Meaning Linked Objects

OrganizationThe highest level unit under analysis - the Top level JCS which is analyzed

All View DiagramsBlocksPartsOperational Views

Analysis Boundary

a non mutually exclusive subset of humans and technology within an organization, with common purpose. In SYSML this is known as a collection. This is a subordinate JCS

Subject (use case diagram)blocks (composition/aggregation/generalization)State diagramsInternal Block DiagramsSequence DiagramsParametric Diagrams

Technical System

A subset of hardware and software within an organization. Technical system items must not overlap, as they are concrete and must be "built"at some point. However, for analytic purposes, part properties may be shared between analytic boundaries. Technical systems are "traditional" materiel systems, they are not JCS.

BlocksPartsState diagramsInternal Block DiagramsSequence DiagramsParametric DiagramsRequirements DiagramsSystem ViewsTechnical Views

OperatorsHuman roles within a system which are responsiblefor executing task work

Actor::Operator (stereotype)Part: Human (Stereotype)

Human roles within a system which are empowered to set goals and establish priorities. Users and operators may physically be the same person, fulfilling different roles

Actor::User (stereotype)Part: Human (Stereotype)

Stereotype Meaning Linked Objects

Environment

Elements external to the organization which provide context, exchange matter, energy and information across the organization boundary Boundary Object (optional)

To implement CSE principles, several conventions are

adopted. First, use case diagrams conventionally focus on

the “subject” as technology, with operators external to it

in context. This is at odds with the JCS notion of humans

within the system, or indeed humans extended by technology

as the system. CSEMP addresses this disparity by

establishing two different stereotypes with associated use

case subject boundaries, one to include the humans as part

of an organization, and one to address just the technology.

By SYSML convention, the technology is the “system under

consideration” (Friedenthal, et al, 2008). This allows us to

define when a collection of objects is a JCS, when it is

just technology, and how it overlaps within our overall

understanding.

Another key difference between CSEMP and SYSML convention is

in the assignment of actors. Actors are defined to mean

anything that acts outside of the boundary of the “system

under consideration”. Actors are usually humans, but may

mean external systems. In this case, we are defining actors

both within our organization acting on our technological

system, as well as external actors that represent technology

as boundary objects, in this case, an air tasking order

(ATO) which is part of the flight control doctrine, and is

received electronically through the Contingency Theater Air

Planning System (CTAPS). This actor is stereotyped as a

“boundary object” and it is associated with a block, which

may in turn, be associated with the XML document that

details the content of the ATO, along with additional

“bindings” specific to the CFC organization we are now

building as a JCS.

In the UML base specification, the line between the actor

and a use case, or between actors is an association.

Association is a loosely typed specification in the

UML/SYSML standard. In the CSEMP case, it is stereotyped

as <<affordance>>, and the validation logic is extended to

show full traceability to a technology and task to implement

the goal – i.e. this use case must be allocated to technology

parts and human tasks, defined in an activity diagram. If all

these conditions are met, it satisfies the definition of

affordance. If they are not, then it is either incomplete,

or unaddressed, or superfluous. Additionally, the technology

parts ultimately defined or selected become “artifacts”,

once they have been linked to activities which decomposed

from use case goals. Artifact become a reference property of the

block, and becomes a useful way to evaluate the top level

structure as it has been refined to ensure those top level

goals and elements have been addressed throughout the model.

Before embarking on the development of the goals means

decomposition, the program manager and chief engineer would

have developed a package diagram. This diagram helps sort

out the various perspectives of the stakeholders, and

establishes namespaces. If, for example, the CSE and the

hardware engineers persisted in different definitions for

“system”, as belied their respective biases, it is possible

to use “fully qualified names” by establishing element

“bindings” within one package and namespace and mapping them

to a different set of bindings in another. On the MMA work

(Gordon et al, 2005), we continually had trouble with

“function”, which our prime insisted meant “things an

airplane does”, while we wanted to call functions “what the

squadron did” in order to address the entire organization

within our TDFA framework. We resolved this by using the

Status of Readiness and Training System (SORTS) messages

used by the Navy to report “functional readiness”,

effectively as a boundary object (it was understood by all

stakeholders, even though we were unfamiliar with the

concept at the time), and decomposed our function

description from it, to include mappings to “what an

airplane did”. Examples of the relationship between

packages, namespaces, views and viewpoints are illustrated

in Figure 9.

Figure 9. Example Package Diagram for the Carrier Flight Center. It depicts how we are binding concepts such as “system” to names articulated differently for a CSE view (developed with the ACWA method) and as used to develop a manufacturing parts list.

Use case models can be developed at an arbitrary level of

detail, as suited by the analytic needs of a particular

problem domain. The next level is that of establishing

activity diagrams for each of the use cases. Some use case

methods call for a text based elaboration of each use case,

as a set of scenarios composed of actions. As an alternative to

the text based method, an activity diagram can be developed

showing the series of actions performed during the use case,

with forks and decision points to show the various branches

that form different scenarios. UML Constraints can be used

to establish starting and ending criteria or state

definitions for the use case. In addition to the basic

activity modeling of UML, the extended activity diagram of

SYSML, which facilitates developed of enhanced functional

flow block diagrams (EFFBD), can describe additional aspects

of the behaviors. EFFBD are semantically equivalent to

Petri-Nets, often used in Human factors research (Jonnasen

et al, 1999).

Vicente (Vicente, 1999) defines tasks as the need to do

something in support of goals. They are performed via

operations, which have inputs and outputs, and actions, which

specify transfer functions for the input to output. This is

semantically equivalent to the “function” of EFFBD, which

describes inputs and outputs, a process and a set of

controls on that process, along with the items passing

between processes. The SYSML activity diagram doesn’t

distinguish, although a “traditional” structured analysis

approach would focus on the functions of the technology, and

then define tasks as the human implications of that

functionality (Buede, 2000). In this case, actions in a human

swimlane refer to “functions of the people” (and in a

particular work setting, which is simply the reverse of

looking at the affordance relationship) as opposed to

“functions of the technology”.

In the SYSML case, the activity diagram can include

“swimlanes” which are distributions of functions between

“blocks” which would accomplish them. Swimlanes are the

horizontal lines are linked to blocks and established by the

<<functional allocation>> stereotype between the block and

the action it performs. As we saw previously, these blocks

can be both human and technology. In this way a basic

“functional allocation” is defined. The CSEMP does not

presume to introduce a method to accomplish the allocation,

but merely provide a mechanism to capture it. To provide

EFFBD equivalency, SYSML activities, in addition to forks,

unions and decisions, add the following additional features.

Token and Item flow between functions to show how data

moves through the system. Items can be matter, energy

or information. This is equivalent to the processes in

the goals-means decomposition of Elm’s applied

cognitive work analysis (Hollnagel, 2003). Tokens are

control cues, which may be electric signals in hardware

and software, but also represent cues when evaluated by

humans.

<<Continuous>> and <<Discrete>> flows, which

discriminate between item flows which can be parsed,

and those which occur over time. Additional constraints

or parametric models can be added to the flow

specification to describe format and range of these

Ports which can be associated with flow specifications

that describe directionality, modality and content for

flows in and out of objects.

Signals used to describe item flows that originate or

terminate outside of the boundary of the subject of the

activity diagram.

An example of an activity diagram from the Carrier Flight

Control case, specifically Establish Flight Management

Procedures Use case, is depicted in Figure 10.

Figure 10. Activity Diagram for Flight Management Procedures. Used to Evaluate Allocation Strategies

In this case, the model proposes a notional “Navy Automated

Command and Control System” (NAC2S) as an automated system

to aid in accomplishing this goal. The goal relies on a

boundary object, the air tasking order (ATO), and has a

notional human partner, the Air Intercept Controller (AIC).

The lines which cross the AIC and NAC2S swimlanes represent

items which are passed on the HMI. The descriptive logic can

find these “crossing” item flows and stereotype them as

“HMI”, to be collected later and evaluated within a user

interface design. Additionally, the type, frequency and

modality of the item flow on the HMI can be captured in the

model, as those decisions are made.

Control token flows exchanged on human swimlanes can be

stereotyped as <<environmental cues>> and indicate a

stimulus/response situation that can be evaluated via

classical human factors methods. Additionally, decision

points within the human swimlane can be stereotyped as

<<selections>>, and forks and unions as <<fusions>>, used to

evaluate the cognitive implications as those parts of the

model are continuously refined. Selections passing control

tokens and further amplified with UML guard conditions may

be stereotyped as <<control strategies>> as defined by

Vicente.

However, the first cut of the model will likely not have

this level of detail. The initial activity diagram result is

likely to be only a collection of identified actions to

describe the means of the goals established as use cases.

However, as other elements of the overall design are

selected, evaluated or constrained, the model will take

shape, and the functional allocation, cognitive

implications, and interface requirements definition will be

completed. Note that these final elements can be collected

in any order, it is only as the relationships are joined

that they are considered complete, and thus a functionalist,

cognitivist or ecological approach may ultimately yield the

same content, populating the model in vastly different

order. A summary of CSEMP stereotypes used to augment

activity diagrams is listed in Table 2.

Table 2. Summary of CSEMP Stereotypes and Logics as used In Activity Diagrams. Concepts are considered “validated” when the tuples are complete.

Stereotype Base Class Validation LogicAffordance Actor Actor - Use Case - Functional AllocationFunctional Allocation

Allocation Action - Block Allocation

Control FlowObject Flow

Item Flow Specification- Actor Block to Technology Block

Environmental CueControl Flow

Item Flow Control Token - Allocated to Actor Block

SelectionsDecision Node Decision - Allocated to Actor Block

FusionsFork/JoinNode Fork/Union Allocated to Actor Block

Control Strategies

Decision Node Guard Condition

Item Flow Control Token -Decision - Allocated to Actor Block

SYSML was developed with an eye towards building “executable

architectures”, i.e. enabling engineers to connect their

graphical models directly to simulations such that

verification and trade space analysis could be performed

directly from the model (Friedenthal et al, 2008). A

critical portion of the SYSML specification to support this

goal is the parametric diagram. Parametric diagrams depict

sets of related constraints that define sets of equations.

The equations are provided ports which can be typed and

connected to attribute values of other blocks. Parametric

diagrams have a wide variety of usages, and they can be

associated with blocks, activities or other elements.

Assignment of Technical Performance Measure (TPM) budgets

for system characteristics such as weight or heat balance,

as well as defining systems of equations related to

performance measures such as “braking distance” for a car as

a function of mass, friction, etc. are two common uses from

traditional systems engineering.

In the CSE case, parametric constraints provide a useful

place to capture cognitive data relating to human actors

blocks in the system. Activities can be categorized by the

visual, cognitive, auditory and psychomotor loading

contribution as per the human information processor models

of Card, Moran, Newell and Wickens. Each actor required to

execute an action then “connects” to these loading factors,

and a total loading factor for the human can be calculated.

For cases where the analysts are concerned about cognitive

overload, a discrete event simulation can be developed from

the parametric equations and analyzed as a “run time” model.

Similarly, the implications for transferring data from a

technical system into usable information, or the synthesis,

analysis and evaluation of information received from other

human actors can be modeled as “transfer functions” which

capture human factors data required to perform that

transfer: social context constraints, interface modalities,

display phase spaces, supporting knowledge, skills and

abilities, etc. An example is provided in Figure 11.

Figure 11. Example of using Parametric Diagram to Capture Cognitive Loadingand Interface Requirements on a Human Actor Block. Parametric constraintblocks store systems of equations to use in simulation based analysis.

A summary of Stereotypes to extend Parametric Diagrams for

cognitive concepts is listed in Table 3. Validation logic

lists other objects in the model which must exist in order

to generate the parametric constraint. Some constraints are

not mandatory in all cases. The model should not require

these elements to be defined, but validation should check to

see that if some are defined, then that portion of the model

is complete (e.g. if cognitive channels are defined for one

action-actor pair, then all actions should be defined to get

accurate measure or workload).

Table 3. Parametric Diagram Stereotypes to support Cognitive Task Analysis. Validation logic is used to verify completeness.

Stereotype Base Class Validation Logic

ModalityPort Constraint

All Interface Data Item for HMI

Human Performance MeasureParametric Constraint

Optional- Actor, Collection

Training RequirementParametric Constraint

Enabling KSAParametric Constraint

WorkloadParametric Constraint

All actions for Actor

Cognitive ChannelPort Constraint

Action

Phase SpaceParametric Constraint

Optional - All InterfaceData Item for HMI flow specification

Interface RequirementParametric Constraint

All Interface Data Item for HMI flow specification

Information Exchange Requirement

Port Constraint

All User Interface Data Item – Actor, Collection

Display DataPort Constraint

All Interface Data Item for HMI flow specification

Conclusions and Recommendations

During the analysis of CSE concepts from the literature, I

found a high degree of textual equivalence to UML and SYSML

concepts, where the stated definitions for two terms were

nearly identical. This provided a good starting point for

developing the CSEMP profile. Additionally, the UML is now

over a decade old, and advances in informatics have

progressed to the point where the language is mature, and

many cases are already addressed. It has become semantically

precise, and many concepts could easily be related by

comparing contextual definitions and examples. The

“namespace” concept is especially powerful, providing a

means to “bind” dictionary meanings between communities of

practice. I found in the literature review good support from

my anecdotal observations that the key challenges in

establishing a working dictionary were those of perspective,

fortunately, the discussions in Vicente, Hollnagel, Lintern

and Woods and Hollnagel were sufficiently complete to

provide a means to construct a meta-perspective that could

accommodate the characteristics of the subordinate

perspectives. I believe that that this study should provide

a useful starting point for what I hope is continued

discussion.

References

Albrechtsen, H., Andersen, H., Bødker, S. , & Pejtersen, A.

(2001). Affordances in Activity Theory and Cognitive Systems Engineering.

Riso National Laboratory: Roskilde Denmark. Retrieved 14 Apr

2011, from http://130.226.56.153/rispubl/SYS/syspdf/ris-r-

1287.pdf

Ann M . Bisantz & Catherine M . Burns (eds). (2009).

Applications of Cognitive Work Analysis: CRC Press. Retrieved 19 April

2011, from

http://www.crcnetbase.com.ezproxy.libproxy.db.erau.edu/doi/p

dfplus/10.1201/9781420063059.ch13

Braha, D. , Minai, A. & Bar-Yam, Y. (eds).(2006). Complex

Engineered Systems- Science Meets Technology. MA: Springer Publishing

Buede, D. (2000). The Engineering Design of Systems: Models and

Methods. Canada: Wiley and Sons

Daum, B. (2003). Modeling Business Objects with XML Schema. Germany:

Morgan Kaufman.

Douglass, B. (2994). Real Time UML (3rd ed). MA: Addison Wesley

Fong, A./Valerdi, R./Srinivasam, J. (2007). Using a Boundary

Object Framework to Analyze Inter-Organizational Collaboration. Paper

presented at the 17th INCOSE Symposium San Diego,

California. Retrieved 11 Feb 2011, from

http://web.mit.edu/rvalerdi/www/INCOSE_final_Boundary

%20Objects%20(Fong%20Valerdi%20Srinivasan%202007).pdf

Friedenthal, S. Moore, A. & Steiner, R. 2008. A Practical Guide

to SYSML. Amsterdam: Morgan Kaufman Press.

Gordon, J., Burns, J, Ricci, K., & Ramsden, C., (2005).

Identifying Training Requirements Early in Systems Acquisition: HSI and the

Navy’s Multi-mission Maritime Aircraft: Proceedings of the 2005 Human

Systems Integration Symposium

Gordon, J. , Burns, J, Sheehan, J., Ricci, K. & Pharmer, J.

(2005).A Framework for Enabling HSI within Systems Engineering: HSI and the

Navy’s Multi-mission Maritime Aircraft: Proceedings of the 2005 Human

Systems Integration Symposium

Gordon, J., Burns, J. & Giebenrath, J. (2005). A Common Data

Representation for HSI: The Universal Performance Data Model: Proceedings

of the 2005 Human Systems Integration Symposium

Hollnagel, E. & Woods, D. (2005). Joint Cognitive Systems,

Foundations of Cognitive Systems Engineering. FL: CRC Press.

Hollnagel, E. (ed). (2003). Handbook of Cognitive Task Design. NJ:

L Erlbaum.

Jacobson, Booch& Rumbaugh, (2000). The Unified Software

Development Process. Boston:Addison Wesley

Lintern, G. (2009). The Foundations and Pragmatics of Cognitive Work

Analysis: A Systematic Approach to Developing Large Scale Information Systems.

V 1.0 Retrieved 12 Mar 2011, from

http://www.cognitivesystemsdesign.net/Downloads/Title

%20Contents%20Preface.pdf

Madni, A. (2010_. Integrating Humans with Software and

Systems: Technical Challenges and a Research Agenda. Systems

Engineering, 13(3). 232-245.Wiley Press.

Maier, M. & Rechtin, E. , 2002. The Art of Systems Architecting. Fl:

CRC Press

Militello, L. Dominguez, C. Lintern, G. & Klein, G. 2010.

The Role of Cognitive Systems Engineering in the Systems

Engineering Design Process. Systems Engineering 13(3). 261-273.

Wiley Press.

Nantajeewarawat, E. , & Wuwongse, (2005). Knowledge-Based

Inconsistency Detection in UML Models. In Chang (ed).

Handbook of software Engineering and Knowledge Engineering Vol3 (pp177-

202). PA: World Scientific

Parasuraman, R. &Wickens, C. (2008) Humans: Still Vital

After All These Years of Automation. Human Factors 50(3): 511-

Potter, S.S. , Elm, W. Roth, E. , Gualtieri, J. , & Easter,

J. 2001. Bridging the Gap Between Cognitive Analysis and Effective Decision

Aiding. Retrieved 12 Mar 2011, from

http://mentalmodels.mitre.org/cog_eng/reference_documents/Br

idging%20the%20Gap--revised2.pdf

Putz, M. & Verspoor, M. 2000. Explorations in Linguistic Relativity.

Google Books,. Retrieved 3 Apr 2011, from

http://books.google.com/books?

id=_QLF02w1qXMC&printsec=frontcover&dq=Explorations+in+lingu

istic+relativity&source=bl&ots=DmVaa7rYcL&sig=EcH87lpPF3bOJY

MDQr4bYOhYvzs&hl=en&ei=ZkmmTbHYCoaatwfI6bCFAQ&sa=X&oi=book_r

esult&ct=result&resnum=3&ved=0CC8Q6AEwAg#v=onepage&q&f=false

Radford, A. (1988). Transformational Grammar. England:

Cambridge University Press.

Sanders, M. & McCormick, E. (1993). Human Factors in Engineering

and Design, 7th ed. NY: McGraw Hill

Sheard, S. & Mostashari, A. (2009) Principles of Complex

Systems for Systems Engineering. Systems Engineering 12(4). 295-

311. Wiley Press

Sheridan, T., & Parasuramen, R. (2006). Human –Automation

Interaction. Retrieved 10 Oct 2010, from

http://archlab.gmu.edu/people/rparasur/Documents/Sheridan-

ParasuramanRevHFES06.pdf

Suh, N. (2001). Axiomatic Design Advances and Applications. NY:

Oxford University Press.

Vicente, K. 1999. Cognitive Work Analysis: Toward Safe, Productive and

Healthy Computer Based Work. NJ: L Erlbaum.

Woods, Patterson & Roth. (1998). Can we ever escape from data

overload? A cognitive systems diagnosis. Cognitive Systems Engineering

Laboratory Institute for Ergonomics: The Ohio State

University. Retrieved 19 April 2011, from

http://10.1.1.37:6079

Cognitive Systems Engineering Modeling Profile

Documents

Transcript of Cognitive Systems Engineering Modeling Profile

GE Profile

Satellite Cognitive Communications: Interference Modeling ...

Prospect-Theoretic Modeling of Customer Affective-Cognitive Decisions Under Uncertainty for User Experience Design

Profile kk

CACCI Profile

The Growth of Cognitive Modeling in Human-Computer Interaction Since GOMS

PROFILE - UMPH

Primary User Activity Modeling Using First-Difference Filter Clustering and Correlation in Cognitive Radio Networks

A distinct [18F]MPPF PET profile in amnestic mild cognitive impairment compared to mild Alzheimer's disease

Pulses profile

COMPANY PROFILE

Jhon's profile

DISTRICT PROFILE

Prospect-Theoretic Modeling of Customer Affective-Cognitive Decisions.pdf

ECONOMIC PROFILE

Porosity investigation of compacted bentonite using XRD profile modeling

Cognitive profile and brain morphological changes in obstructive sleep apnea

CMC Profile

Corporate Profile

VietStar Profile