Human–Systems Integration

From Virtual to Tangible

Guy André Boy

• Publisher: CRC Press
• Year: 2020
• ISBN:
  9781000028362
• Edition: 1
• Topic: Design
• Subtopic: Product Design

Human–Systems Integration: From Virtual to Tangible

Subject Guide: Ergonomics and Human Factors

This book is an attempt to better formalize a systemic approach to human–systems integration (HSI). Good HSI is a matter of maturity… it takes time to mature. It takes time for a human being to become autonomous, and then mature! HSI is a matter of human–machine teaming, where human–machine cooperation and coordination are crucial. We cannot think engineering design without considering people and organizations that go with it. We also cannot think new technology, new organizations, and new jobs without considering change management.

More specifically, this book is a follow-up of previous contributions in human-centered design and practice in the development of virtual prototypes that requires progressive operational tangibility toward HSI. The book discusses flexibility in design and operations, tangibility of software-intensive systems, virtual human-centered design, increasingly autonomous complex systems, human factors and ergonomics of sociotechnical systems, systems integration, and changed management in digital organizations.

The book will be of interest to industry, academia, those involved with systems engineering, human factors, and the broader public.

chapter one

Human-centered design of industrial complex systems

That’s what we do in real life, with puzzles that seem very hard. It’s much the same for shattered pots as for the cogs of great machines. Until you’ve seen some of the rest, you can’t make sense of any part.

Marvin Minsky
Cognitive Scientist and Artificial Intelligence Pioneer

There are three main difficulties that arise when humans want to understand and interact with a complex system. They need to know (1) how the whole system works, (2) why the system exists, and (3) how it should be used. During the 20th century, even if each part was very well tested independently, we needed to wait until the overall system was assembled (i.e., integrated) to test it as a whole. Today, we can test an entire complex system with a human-centered design (HCD) approach using virtual prototypes and carrying out Human-In-The-Loop Simulations (HITLSs). This is what we call Virtual HCD (VHCD).

Technology-centered engineering versus human-centered design

Software engineering proposed the V-Model (Figure 1.1) as an extension of the waterfall model. It is currently used by most industrial companies worldwide, not only in software engineering, but in any kind of engineering. It provides a graphical “picture” of a development life cycle of a system. The left side of the “V” shows the sequence of processes going from requirement analysis, to system design, architecture design, module design, and coding of the parts (i.e., manufacturing in the general case). The right side of the “V” shows integration of parts, through unit testing, integration testing, system testing, and finally acceptance testing (certification).

Figure 1.1 V-Model.

We observe that most difficulties encountered in the validation phase come from requirements that were not enough human-centered or organization-centered. In fact, we pay high price in the end on lack of sometime-small requirements flaws. We end up with a “V,” directed by technology-centered engineering (TCE), that looks like a check mark (Figure 1.2), that is, we spend extra amount of time and pay a lot of money to be ready before delivery (when it is not too late to still fix design flaws). Obviously, TCE is currently combined with human factors and ergonomics (HFE) considering that HFE is mobilized at the end of the V-Model for acceptance testing.

Figure 1.2 The V-Model when not enough attention is brought to human-centered requirements (the “qualitative thickness” of the line expresses the amount of effort and costs).

However, requirements need to be validated first against the higher-level requirements or user needs (i.e., defining human-centered requirements). This is when modeling and simulation (M&S) comes in, and an HCD contribution can be developed. As a matter of fact, HCD can be symbolically represented as an exact symmetric shape of TCE check-mark V-Model (Figure 1.3). Note that if HCD obviously includes HFE for the design parts, TCE also includes HFE for the testing parts.

Figure 1.3 Combining HCD and TCE.

We already claimed that combining HCD and TCE leads to Human–Systems Integration (HSI). In addition, the amount of effort required without HCD can be reduced carrying out HCD processes. Finally, the more we get experience carrying out HCD processes, the more the amount of effort required for TCE will decrease (Figure 1.4).

Figure 1.4 Combining HCD and TCE to develop HSI.

We will describe later in the book how HFE testing procedures and criteria should be adapted by considering tangibility metrics.

Impact of virtual HCD on the life cycle of a system

It is important at this point to explain what we mean by HCD, and more precisely VHCD. I already provided a description of HCD (Boy, 2013a), which includes six components: cognitive engineering, complexity analysis, M&S, advanced interaction media, organization design and management, and life-critical systems. M&S enables building virtual prototypes that are key HCD digital resources based on artificial intelligence (AI), human–computer interaction, and data science. It is now possible to immerse, very early in the design process, potential users, human operators, and simply people in the loop with simulated systems prefiguring targeted systems to be developed.

We will take NASA’s life cycle phase model (Table 1.1) to illustrate what M&S, and therefore VHCD, can provide to improve the life cycle of a system. This model is obviously specific to space systems, but it can be applied analogously to life cycle development of other complex systems. We are using it to better understand some useful concepts such as design flexibility, resource commitments, and system knowledge evolutions with respect to life cycle phases.

Table 1.1 NASA’s life cycle phases

Pre-Phase A, Concept Studies	Feasible concepts, simulations, studies, models, mockups
Phase A, Concept and Technology Development	Concept definition, simulations, analysis, models, trades
Phase B, Preliminary Design and Technology Completion	Mockups, study results, specifications, interfaces, prototypes
Phase C, Final Design and Fabrication	Detailed designs, fabrication, software development
Phase D, System Assembly, Integration and Test, Launch	Operation-ready system with related enabling products
Phases E and F	Operations and sustainment, closeout

Considering a TCE approach, we want to know what “it” will look like. We can show pieces going together and develop an architecture. However, if there is a change, what could we do; we have no design flexibility and usually a limited amount of funding.

Figure 1.5¹ shows how design flexibility decreases rapidly during the first phases to end up being close to zero during the last phases. In the same way, resource commitments increase rapidly during the first phases to end up on a saturation during the last phases (i.e., we will not have enough resources and money to finish the project correctly, except if we add more resources that were not anticipated in the initial budget – 0% resource commitments mean that we still have 100% of the budget, and 100% means that all the potential is consumed).

Figure 1.5 Design flexibility, resource commitments, and system knowledge evolutions (Conroy, 2016) with respect to life cycle phases (e.g., NASA’s phases) using conventional TCE.

Interestingly, system knowledge (i.e., what we know about the system under development and its potential usages) slowly increases in the beginning and grows faster toward the end of the development life cycle. In other words, we need to wait almost until the end of the development life cycle to know the system and its usages well.

Now, if we take an HCD approach supported by M&S, and more specifically HITLS, we could end up having a big change on these evolutions (Figure 1.6). Assuming that we know system’s purpose, when people ask, “What will the system look like and how it could be used?”, we could show them a simulation and even get them involved into the simulation. Most interesting is that system knowledge is increasing much faster in the beginning because M&S enables to observe various kinds of activity as well as emerging behaviors and properties. In addition, M&S helps the design team in finding out alternative design solutions; we keep design flexibility for a longer time during the design life cycle of the project. Resource commitments start to grow slower with M&S support, and we have more time to make “final” design decisions. At this point, resource commitments are higher in the beginning due...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• Preface
• Author
• Chapter 0 Introduction
• Chapter 1 Human-centered design of industrial complex systems
• Chapter 2 Tangibility problems and potential solutions
• Chapter 3 Technology, organizations, and people
• Chapter 4 Formalizing Human–Systems Integration
• Chapter 5 From rigid automation to flexible autonomy
• Chapter 6 Orchestrating Human–Systems Integration
• Chapter 7 Design for flexibility in an increasingly complex world
• Chapter 8 Activity, creativity, storytelling, and tangibility: The right mix
• Chapter 9 Evaluation processes and metrics
• Conclusion
• References
• Index