See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/260640501

Human System Integration Ontology: Enhancing Model Based Systems

Engineering to Evaluate Human-System Performance

Article  in  Procedia Computer Science · March 2014

DOI: 10.1016/j.procs.2014.03.003

CITATIONS READS

28 842

2 authors:

Douglas Orellana Azad M. Madni

ManTech International Corporation University of Southern California
9 PUBLICATIONS   415 CITATIONS    229 PUBLICATIONS   2,589 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Model Based Systems Engineering View project

Tradeoff Decisions in System Design View project

All content following this page was uploaded by Douglas Orellana on 20 March 2014.

The user has requested enhancement of the downloaded file.

 Available online at www.sciencedirect.com

ScienceDirect
Procedia Computer Science 28 (2014) 19 – 25

Conference on Systems Engineering Research (CSER 2014)

Eds.: Azad M. Madni, University of Southern California; Barry Boehm, University of Southern California;
Michael Sievers, Jet Propulsion Laboratory; Marilee Wheaton, The Aerospace Corporation
Redondo Beach, CA, March 21-22, 2014

Human System Integration Ontology: Enhancing Model Based

Systems Engineering to Evaluate Human-System Performance
Douglas W. Orellanaa*, Azad M. Madnia
a
University of Southern California, 854B Downey Way, RRB 225, Los Angeles, CA 90089-1192

Abstract

As we move forward to integrate system descriptive models and system analytical models, there is a key opportunity to integrate
other viewpoints into the system model. Specifically, we have the opportunity to extend current modeling semantics and add
other disciplines. Current systems engineering practices address human-system integration concerns as an afterthought (i.e., after
system architectures have already been created). One primary reason for this deficiency is that people not trained in human
factors engineering are unable to communicate with those that are, due to differences in terminology. To better integrate humans
into and with systems, new semantics are needed to extend current system modeling representations. The integration of new
semantics will allow human elements to be analyzed in a more holistic perspective. This paper looks into identifying core
building blocks for creating the ontology for human system interaction, interfaces, and integration. This ontology, once fully
developed, will extend current system modeling capabilities that will enable the human element to be analyzed as part of the
overall system development process.
© 2014 The Authors. Published by Elsevier B.V.
© 2014 The Authors. Published by Elsevier B.V.
Selection and peer-review under responsibility of the University of Southern California.
Selection and peer-review under responsibility of the University of Southern California.
Keywords: Human System Integration; Human Factors; Model Based System Engineering; SysML; UML; Modeling and Simulation; System
Modeling; Ontology;

* Corresponding author. Tel.: +1-6167-620-9376.

E-mail address: dworella@usc.edu

1877-0509 © 2014 The Authors. Published by Elsevier B.V.

Selection and peer-review under responsibility of the University of Southern California.
doi:10.1016/j.procs.2014.03.003
20 Douglas W. Orellana and Azad M. Madni / Procedia Computer Science 28 (2014) 19 – 25

1. Introduction

From early heliographs to the modern day alphabets, humans have communicated with one another by using a
combination of symbols. As groups gather and began using the same symbols, formal languages were developed
within cultural boundaries. Common to each group and language, were the building blocks that allowed people to
express and communicate with each other. Today engineers have developed their own vocabulary and symbols to
communicate with one other.
The vocabulary and symbols are used in models and documents to represent a system under development. As
systems have evolved into more complex entities, the need to increase and formalize modeling semantics has
garnered greater importance. When system architects and engineers saw the power of the Object Management
Group’s (OMG) Unified Modeling Language (UML) within the software engineering community, they began to use
UML for system development. When creating descriptive system models with UML, the system engineering
community recognized a gap in UML for systems engineering. UML did not provide the necessary terminology that
the system community was accustomed to. In order to evolve the language, the system engineering community
decided to extend UML to meet their needs. Evolving UML with common terminology frequently used within the
system engineering community led to the creation of the OMG System Modeling Language (SysML). Since its
inception in 2007, SysML has become the de-facto language for system architects and engineers for descriptive
system models. Most of the research dedicated to system modeling has been focused on upfront conceptual design
and architecture in the traditional system engineering discipline. As we move forward to integrate these descriptive
models into analytical models, there is a key opportunity to integrate other viewpoints into the system model by
extending current semantics and adding other non-traditional systems engineering disciplines.
Today with the role of the human changing from that of an operator to that of an agent1,2 and systems becoming
increasingly more adaptable, greater demands are being placed on the system architect and engineer. Specifically,
the human element needs to be taken into account and appropriately modeled from system conception to disposal.
Current systems engineering practices address human-system integration as an afterthought (i.e., after architectures
have been already specified and designed). In this situation, when changes to the system accumulate, redesign costs
can spiral out of control. The key issue is that people not trained in human factors engineering are unable to
communicate with those that are, due to differences in terminology. To better integrate humans into systems, new
semantics are needed to extend current system modeling semantics. The integration of the new semantics will allow
for human elements to be analyzed in the holistic view of the system. This paper will look at identifying the core
building blocks for creating a common ontology to include semantics in the field of human system integration (HSI).
This ontology, once fully developed, will extend current modeling capabilities and allow the human element to be
analyzed as part of the overall system from system conception to system disposal.

2. Why Is the HSI Ontology Needed?

The objective of HSI ontology is to consider human actions from multiple perspectives. This multifold
consideration of human actions is intended to increase the functional effectiveness and it should allow to apply
information about human characteristics and behavior into a more systematic way.3 Landsberg et al. presents various
cases in which different aspects of HSI have been applied to different programs.4 What can be seen though is that
there is not one holistic approach to consider HSI. Modeling and simulation can provide an excellent workspace to
achieve the trade-offs necessary across the HSI and system domains.5
Within the system, human and machine tradeoffs must be made. In the past humans were usually modeled as
external entities.6 But in accordance with ISO 15288, humans are now treated as agents and must be considered as
any other subsystem. Analyzing how the interactions between the sub-elements work as one. The human agent
senses the outputs of the machine, and the human response is the input to the machine. Both machine and humans
have a set of required capabilities and functionality to meet the system’s goals and objectives.
Current HSI tools do not take into account the architecture development process and the decision-making in the
conceptual design of the system. Engineers that use these types of tools and methodologies usually tend to address
human system issues well after the architecture is set and major design decisions with huge monetary implications
have been made. These tools are usually just used for design after the fact. In order to truly integrate HSI into the
 Douglas W. Orellana and Azad M. Madni / Procedia Computer Science 28 (2014) 19 – 25 21

architecture process and the rest of the engineering process, new modeling semantics are needed to ease integrations
of engineering methodologies, processes, and tools as well as opening up communications between various
engineering disciplines.
Building common semantics for HSI has not had much traction within the HSI community or the system
engineering community. There have been two attempts to build partial constructs for use in the architecting and
engineering of systems but neither has come to fruition and use.
In an attempt to fill the gap in human-systems architecting, IDEF administrators attempted to develop IDEF 8,
Human-System Interaction Design Method. IDEF 8 was created to look at three different levels of human system
interaction: 1) overall system operation, 2) role-centered scenario of system use, and 3) design objectives
implemented through a library of metaphors used as best practices for detailed design.7 IDEF 8 was centered in
using interaction diagrams (activity based diagrams) to allocate functions between a user and a system. The
functions described had to deal with actions detailing interactions with physical controls and displays. Then with the
use of the library of metaphors, the designers are able to use the metaphors to design the controls and displays of the
system. Although IDEF 8 was a good attempt to bring up human system interaction upfront in the lifecycle it never
took off and it had limited coverage of HSI issues.

Fig. 1. IDEF 8 Interaction Diagram of Resize Box Example.8

Recognizing the need for human viewpoints of the system, the North Atlantic Treaty Organization (NATO)
undertook an effort to examine ways to better evaluate human system compatibility, and created the NATO RTO
HFM 155 Human View Workshop. The Human Views were intended to expand the NATO Architectural
Framework (NAF) by documenting the unique implications of humans for system design.9 With the emergence of
SysML, The United States Department of Defense and the United Kingdom Ministry of Defence with industry
partners developed a profile extending both UML and SysML to depict the DoD Architecture Framework (DoDAF)
and the MoD Architecture Framework (MoDAF) constructs. The Unified Profile for DODAF and MODAF
(UPDM), emerged as a way to use the UML/SysML tools to capture system architecture using these frameworks
and their respective meta models.10
With the introduction of the human viewpoint in NAF and its potential introduction into DoDAF and MoDAF,
these constructs are expected to play a role during acquisition of defense systems. The system currently being
developed using these frameworks has slowly been transitioning to using model architecture tools to capture and
manage complex architectures. The tools and the modeling languages they support will need to be extended to
include the human constructs in accord with the suggested human view meta-models. The change of paradigm to
bring human factors considerations upfront instead of as an afterthought will allow architectures to be more aligned
with human capabilities and limitations and with the changing role of humans.
22 Douglas W. Orellana and Azad M. Madni / Procedia Computer Science 28 (2014) 19 – 25

In an attempt to better understand the role of the human agent, the NATO proposed human views look at various
aspects of humans that may affect system performance. The NATO human views are HV-A Concept, HV-B
Constraints, HV-C Functions, HV-D Roles, HV-E Human Network, HV-F Training, HV-G Metrics, and HV-H
Human Dynamics.9 In particular the following subset of views are intended to allow architects to better understand
the human-machine interactions in accordance with the NATO definitions9:
The human constructs not only provide the ability to integrate the human factors to the architecture process, but
the same semantics will allow the human factors requirements to be tested, verified, and validated. The same
constructs used for architecting complex systems will be able to be used to design the test systems and test cases.
The common semantics will provide the traceability capabilities already built in to system constructs to ensure that
human agent activities are being tested under varying scenarios that are based on the use case scenarios developed in
the architecture. The semantics will also allow values of attributes to be captured, allowing test data and human
attributes to be captured from testing activities. The data captured can then be used to improve the workload analysis
by adding real data to the tasking network analyses.
To align common HSI semantics for interdisciplinary use and full life cycle coverage the common semantics
should cover the varying system aspects as discussed in standards, such as ISO/IEC 15288. Arnold et al. discuss
how a human system model with four views can cover ISO/IEC activities in perspectives: human factors in the
lifecycle, human factors integration, human-centered design, and human resource processes.6 In the same vein,
common semantics should expand these four views for full coverage.

3. What is the HSI Ontology?

Fig. 2. Ontology Domain Diagram.

An absolute and integral part of any design is proper communication among all stakeholders in the development
process.3 The HSI ontology becomes an integral part of having better communications between all engineers,
particular system architects, system engineers, and human specialty engineers. Figure 2, shows how the HSI
ontology will define a meta-model and constrain an extension profile to extend SysML and MBSE for HSI
considerations.
 Douglas W. Orellana and Azad M. Madni / Procedia Computer Science 28 (2014) 19 – 25 23

Fig. 3. HSI Top Level Ontology.

There are several areas that affect HSI; the HSI ontology looks at various areas within the framework of the
system modeling pillars and other considerations that will give a more holistic system view with the perspective of
the human. Collectively, these factors will provide the semantic underpinnings for defining and managing the
human element within the mission and system context. A unified view of these factors is presented in the HSI
ontology (Figure 3). The HSI ontology offers a unifying means of concerns and expectations of the human element.
By considering the various factors in these areas can proceed to increase communication between system architects,
engineers and human factors/human system specialist. Specifically, the HSI ontology provides the building blocks to
bring up human element considerations upfront versus just in the detailed design phase. The HSI ontology informs
us that HSI is composed of requirements, human agents, behavior, structure, parametric, and mechanisms. The HSI
ontology can guide the HSI processes and facilitate communication among stakeholders. The key concepts
represented in figure 3 are discussed next.

3.1. Requirements

Requirements serve as the contractual guidance for the acceptance criteria of any system under development.
Requirements range from functional to performance and are detailed at different level of abstractions. At the top
level the requirements specify intent versus implementation. As requirements get refined and derived the
requirements get more precise in nature until it begins to specify the implemented configuration of the system. In
order to integrate the human agent into the system more attention in the specification of the human agent and HSI
must be specified at all levels of abstraction. The ontology will attempt to explicitly highlight these human centered
requirements in the modeling environment as you would highlight any other system functional and performance
requirement. By explicitly highlighting these requirements it will be easier to trace the requirements to the other
aspects of the modeling pillars: behavior, structure, and parametric. The written requirements should complement
the system model, as to overcome limitations on inferring what is not explicitly modeled in the system model.11

3.2. Human Agent

While the human agent should be treated as any another element within the system, the machine should
complement the human agent and match human characteristics to the agent functions and performance needs.12 It is
24 Douglas W. Orellana and Azad M. Madni / Procedia Computer Science 28 (2014) 19 – 25

equally important to specify human agent characteristics as well as other system agents. The human agent
characteristics should include but not be limited to physical traits, cognitive limitations, sensory performance, and
social factors.
The human agent will extend the block and actor objects in SysML to better specify human agent in the system
under development. In this area, the human agent will have played a certain role in the system operations and system
capabilities. Along with this role, a set of constraints will be specified to understand the limits on the strengths and
weaknesses of the human agent through specifying a skill set that is the minimum requirement for the role to be
played by the human agent. These two areas should help the system architect better match the human agent to the
role it is expected to play in overall system performance.

3.3. Behavior

Modeling behavior using SysML and other object oriented modeling languages is based on use cases and use
case scenarios. Both concepts attempt to capture system usage through high-level interactions of system
stakeholders and actors with the system. These use cases and use case scenarios will enhance written requirements
by refining the requirements to create a descriptive model. Not only does the requirement refinement describe the
interactions, but also shows external visible exchanges, explores user expectations, and defines intended purpose of
system usage.
The use cases are further refined through activity diagrams and sequence diagrams. Activity diagrams give the
general flow of action (functions), while sequence diagrams give a step-by-step description of operations and
exchanges. In both these artifacts, it is important to explicitly detail which functions, operations and accompanying
attributes can potentially enhance the analysis of the human element. In particular, these functions, operations, and
attributes need to allow for ease of transition from conceptual architecture to detailed design. The parallelism
between the aspects that are analyzed in detailed design should be considered up front to account for the human
element impact on the overall architecture, not just the performance of the system.
State machines are used to describe system/subsystem behavior in event driven form. The events identified in this
artifact can occur in one of the system states or can drive a transition from one state to another. As in the case with
systems, humans can be described using state machines. These states can transition under certain events that affect
human cognitive state or performance. By creating specific state machines for the human element, the architect can
specify specific behavior, which the human element must exhibit in response to certain events. This formalism could
also drive the study of the human element/role and limitations that may affect system performance due to state
changes in the human.

3.4. Structure

The structural diagrams describe the system structure through blocks and parts. Within the framework, any
system object can be defined using the block object. In a similar manner, the HSI ontology will be able to extend the
semantics used in the structural diagrams to describe the human agent as well as human system interfaces. These
extended semantics will allow these two concepts to be considered upfront and closely tied to the top-level
requirements. The ontology will also extend the attributes and parameters looked at in this context.

3.5. Parametric

The SysML parametric diagrams are intended to support engineering analysis of critical system parameters (often
the measure of effectiveness and measure of performance). The evaluation of these metrics pertains to performance,
physical characteristics, and “illities.” The parametric pillar of SysML has not been used much until recently.
Currently the parametric artifacts are beginning to be used to trace and link mission and performance metrics of
cube satellites to analytical models.13,14 Similarly, workload analysis, task analysis, and other HSI analysis could be
traced and linked to the human aspects of the system model. The ontology can be extended with the necessary
semantics and mechanisms needed to ensure that traceability and links to the analytical models can be established
and maintained in a model driven environment.
 Douglas W. Orellana and Azad M. Madni / Procedia Computer Science 28 (2014) 19 – 25 25

3.6. Mechanisms

The mechanism portion of the HSI ontology is focused on the human system integration processes, procedures,
tests, and verification required. This viewpoint of the ontology will focus its effort at a basic level to assure
appropriate precautions have been taken to integrating the human element into the overall system. The integration
procedures will attempt to circumvent adverse affects and failures between components,15 with a specific focus on
effects produced by the human agent as well as effects produced by that impact the human agent.

4. Conclusion

Human system interactions, interfaces, and integration has become a key concern today as system continue to
grow in scale, complexity and as humans become increasingly integral part of the systems. In this paper we
discussed why the HSI ontology is needed and possible challenges facing integrating the human element into
systems. The paper presented the HSI ontology that attempts to standardize HSI concepts that could be brought
upfront in the system lifecycle and carried throughout the system lifecycle. The ontology serves a number of
purposes: establishing common terminology among stakeholders, defining HSI factors, support reasoning to detect
inconsistencies and errors that are common to integrating the human element into the system, and enabling human
system analysis and traceability from concept to detailed design, and beyond. It is our hope that this paper will serve
as a tutorial and starting point for systems engineers and human factors engineers when they undertake the
architecting of the human element in relation to the system, and enabling in depth analysis of HSI factors.

References

1. Madni AM. Integrating Humans with Software and Systems: Technical Challenges and a Research Agenda. Syst. Eng. 2010;13(3):232–245.
2. Madni AM. Integrating Humans With and Within Complex Systems. CrossTalk. 2011;May/June:4–8.
3. Balakrishnan PK. Analysis of Human Factors in Specific Aspects of System Design. In: INCOSE International Symposium.; 2002:1–9.
4. Landsburg AC, Avery L, Beaton R, et al. The Art of Successfully Applying Human Systems Integration. Am. Soc. Nav. Eng. J.
2008;120(1):77–107. Available at: http://www.ingentaconnect.com/content/asne/nej/2008/00000120/00000001/art00018. Accessed May 21,
2013.
5. Narkevicius JM. Human Factors and Systems Engineering - Integrating for Successful Systems Development. In: Proceedings of the Human
Factors and Ergonomics Society Annual Meeting.Vol 52.; 2008:1961–1963. Available at:
http://pro.sagepub.com/lookup/doi/10.1177/154193120805202409. Accessed May 22, 2013.
6. Arnold S, Earthy J, Sherwood-Jones B. Addressing the People Problem - ISO/IEC 15288 and the Human-System Life Cycle. In: INCOSE
International Symposium.; 2002:1–7.
7. Mayer RJ, Crump JW, Fernandes R, Keen A, Painter MK. Information Integration for Concurrent Engineering (IICE) Compedum of Methods
Report. Wright-Patterson Air Force Base, Ohio; 1995. Available at: http://www.idef.com/pdf/idef3_fn.pdf.
8. Mayer RJ, Painter MK, DeWitte PS. IDEF Family of Methods for COncurrent Engineering and Business Re-engineering Applications.;
1992:1–77.
9. Handley HAH, Smillie RJ. Architecture Framework Human View: The NATO Approach. J. Syst. Eng. 2008;11(2):156–164. Available at:
http://dl.acm.org/citation.cfm?id=1365459.1365465.
10. Hause M. The Unified Profile for DoDAF/MODAF (UPDM) Enabling Systems of Systems on Many Levels. In: IEEE International Systems
Conference. Ieee; 2010:426–431. Available at: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5482450.
11. Leveson NG. Intent Specifications: An Approach to Building Human-Centered Specifications. IEEE Trans. Softw. Eng. 2000;26(1):15–35.
Available at: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=825764.
12. Miller NL, Crowson Jr JJ, Narkevicius JM. Human Characteristics and Measures in Systems Design. In: Booher HR, ed. Handbook of Human
Systems Integration. John Wiley & Sons, Inc; 2003:699–742.
13. Spangelo SC, Kaslow D, Delp C, et al. Applying Model Based Systems Engineering (MBSE) to a Standard CubeSat. In: 2012 IEEE
Aerospace Conference. Ieee; 2012:1–20. Available at: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6187339.
14. Bajaj M, Zwemer D, Peak R, Phung A, Scott AG, Wilson MW. SLIM: Collaborative Model-Based Systems Engineering Workspace for
Next-Generation Complex Systems. In: IEEE Aerospace Conference.; 2011:1–15. Available at:
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5747539. Accessed June 6, 2013.
15. Madni AM, Sievers M. Systems Integration: Key Perspectives, Experiences, and Challenge. Syst. Eng. 2013;16(4):1–23.

View publication stats