[go: up one dir, main page]
Next Article in Journal
AI Product Factors and Pro-Environmental Behavior: An Integrated Model with Hybrid Analytical Approaches
Previous Article in Journal
A Two-Layer Causal Knowledge Network Construction Method Based on Quality Problem-Solving Data
 
 
Search for Articles:
Title / Keyword
Author / Affiliation / Email
Journal
Article Type
 
 
Advanced Search
 
Section
Special Issue
Volume
Issue
Number
Page
 
Journals
Systems
Volume 13
Issue 3
10.3390/systems13030143
systems-logo
Submit to this Journal Review for this Journal Propose a Special Issue
► Article Menu

Article Menu

share Share announcement Help format_quote Cite question_answer Discuss in SciProfiles
first_page
settings
Order Article Reprints
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Conceptual Modeling for Understanding and Communicating Complexity During Human Systems Integration in Manned–Unmanned Systems: A Case Study

by
Tommy Langen
*,
Kristin Falk
and
Gerrit Muller
Department of Science and Industry Systems, University of South-Eastern Norway, 3616 Kongsberg, Norway
*
Author to whom correspondence should be addressed.
Systems 2025, 13(3), 143; https://doi.org/10.3390/systems13030143
Submission received: 29 December 2024 / Revised: 28 January 2025 / Accepted: 19 February 2025 / Published: 21 February 2025
(This article belongs to the Special Issue Architectural Complexity of Systems Engineering)
Browse Figures
Figure 1
<p>Conceptual modeling framework: An Illustration of five key aspects. These aspects, labeled from (a) to (e), include conceptual models, the purpose, key drivers and qualities, multi-level abstraction, and the knowledge pyramid.</p> "> Figure 2
<p>Review of models represented in aerospace and defense case studies investigating HSI in MUM-T applications.</p> "> Figure 3
<p>Abstract–formality diagram [<a href="#B26-systems-13-00143" class="html-bibr">26</a>]: Showing the classification of conceptual model types, divided into eight sections (A–H) according to their degree of formality (horizontal axis) and level of abstraction (vertical axis).</p> "> Figure 4
<p>Raw data of the survey mapping of the TOP from one participant. The colors blue, yellow, and pink represent T, O, and P, respectively. (The red circle indicates the participant’s preferred degree of abstraction and formality in their modeling practice).</p> "> Figure 5
<p>Results from the survey indicate the number of individuals who used the various conceptual models for the CAFCR and TOP views, respectively. (For CAFCR max = 3 individuals, while for TOP max = 5 individuals).</p> "> Figure 6
<p>Illustration of Storytelling and Visual ConOps from the case study observation and exploration.</p> "> Figure 7
<p>Percentage of respondents and articles mentioning the various models (x-axis), as derived from the case company and literature review, respectively.</p> ">
Versions Notes

Abstract

:
Informal soft system methodologies hold a significant role in developing complex systems. They bridge system knowledge and sensemaking among heterogeneous stakeholders. This article investigates the application of conceptual models to support such communication and understanding among transdisciplinary stakeholders, ensuring the translation of customer requirements and needs into suitable engineered systems. This article presents a case study incorporating observations, interviews, and a review of conceptual models utilized by an aerospace and defense case company for the development of future Manned–Unmanned Systems. It explores how practitioners employ conceptual modeling to support the Human Systems Integration (HSI) aspects of technological, organizational, and human elements of Manned–Unmanned Teaming (MUM-T) systems. The results indicate that practitioners utilize a mix of informal and formal types of conceptual models when developing Human Systems Integration aspects of the system. Formal models, such as sequence diagrams, requirement overviews, and functional flow models, are applied when addressing technology-focused aspects. Organization-centered modeling leverages representations like stakeholder maps and swimlane diagrams, while people-centered aspects rely more on informal techniques such as storytelling and user personas. The findings suggest a potential underestimation by practitioners of the value of quantification in conceptual modeling for Manned–Unmanned Systems development. This study highlights the important role that conceptual modeling methods play, particularly focusing on the informal aspects. These methods are instrumental in enhancing effective communication and understanding among transdisciplinary stakeholders. Furthermore, they facilitate mutual understanding, which is essential for fostering collaboration and shared vision in the development of complex systems. This facilitates deeper insights and reasoning into HSI for MUM-T applications.

1. Introduction

As system designs grow more complex, the need for transdisciplinary collaboration becomes more noticeable [1]. Systems architects and designers require useful tools and methods to support their systems development. Effective modeling techniques are essential because they allow decision-makers and technical influencers in product development teams to visualize how future systems will operate in their context and throughout their life cycle. By providing a clear representation of these systems, these models facilitate team communication, understanding, and reasoning on complex systems [2,3,4].

1.1. Facing an Increasingly Complex System Development

This article examines a case company, a Norwegian key supplier of high-tech system solutions with an extensive product portfolio covering underwater, surface, land, air, and space domains. The company is facing an increasingly complex system development. An example used as the case in this paper is the development of remotely controlled and autonomous systems. Management has highlighted that such products have drastically increased in complexity, resulting in internal processes needing to adjust to these new challenges. Project team members have expressed a need for an agile, accessible, and resource-efficient method that shall support low-fidelity testing and exploration in relation to human–machine collaboration. Historically, the System of Interest at the case company has been a clearly defined system with a constant interface [4,5], making product development clear with known knowns [6]. Such systems are evolving into a new paradigm consisting of a fleet of manned and unmanned systems functioning together in an emergent environment [7]. The case company’s system of interest concentrates on land-based Manned–Unmanned Teaming (MUM-T) operations between operators and machines having an autonomy level between 2 and 5 [8], aiming to increase safety and reduce manpower. Between levels 2 and 5 of driving automation, the operator’s involvement decreases from supervising and intervening when necessary (level 2) to becoming a passenger with minimal task performance when the system is engaged (level 5) [8]. We position this case in the aerospace and defense domain. Previous insight in the case investigated the use of conceptual modeling, such as storytelling, visual ConOps, and dynamic workflow models, to facilitate reasoning about the system [4]. Additionally, published and unpublished human factor insights were studied to understand the operators’ situational awareness [9]. This article expands on the previous work, incorporates additional interviews and surveys, and connects these insights with existing case studies from the literature. We aim to understand which lightweight models and modeling processes are used for Human Systems Integration (HSI) in MUM-T, contributing to the systems engineering body of knowledge.
MUM-T is the integration of manned and unmanned systems to leverage the capabilities of both types of systems [10]. With such a paradigm shift, the case company has expressed the need to increase its understanding of various capabilities, such as operational effectiveness. Gaining insight into the cognitive abilities, such as the stress levels, of operators to maintain sufficient situational awareness in the systems of systems context may achieve this [9]. Therefore, one should evaluate the human performance and limitations in the context of the system of systems that the operators are involved in [11]. However, observations in the industry reveal challenges in adopting methods to harvest and utilize data and information relevant to HSI, which limits the ability to reason about the system’s behavior [12]. The product development team is particularly struggling to generate sufficient data to explore and validate human–machine interactions. With limited access to end-user operators, decisions are heavily guided by standards and requirements, as well as communication with customers and input from various discipline experts to gain insight and understanding of the system to be made.
Researchers have investigated the challenges in transdisciplinary collaboration related to the knowledge barriers that exist between team member groups [13]. They found that there was a need to transform the representations of knowledge at the intersections of different disciplines in order to facilitate knowledge sharing used for problem-solving [13]. Teams are seen as “complex, multilevel systems that function over time, tasks, and contexts” [14]. To overcome such challenges, the product development teams need to anticipate potential problems in advance and establish contingency plans while being well-coordinated, potent, and familiar with each other [14]. However, different subject matter experts and engineering disciplines have various abstract views [15]. They work with different methods used to deliver subsystems in the early and later phases of the life cycle [16], which can result in asynchronization of interfaces in product development.
Bridging product development teams and other stakeholders through expressed mental models of the system of interest is an important part of technical leadership as it supports overcoming organizational silos and promotes transdisciplinary communication and collaboration [17]. Therefore, in transdisciplinary development, the mental models need to materialize into conceptual models to aid the development and integration of the system of interest. Companies desire lightweight architectural methods [18], such as conceptual modeling, which is seen as an accepted practice in the energy and medical domains [15,19]. The benefit is the support of communication and system knowledge among internal and external heterogeneous groups of stakeholders [19]. With a foundation in the soft system approach of systems engineering [20], the iteration between models and viewpoints at different abstraction levels aids in knowledge sharing and sensemaking within the architectural and design process [15,21,22]. Furthermore, participatory design, such as co-creation with customers and end-users, is suitable for exploration and context understanding [23,24]. This can enhance the system knowledge among stakeholders [25]. However, in the context of HSI in MUM-T applications, the research focuses on understanding the human and technical factors through more advanced formal and data-driven analytical approaches [26]. Less emphasis is placed on informal types, such as conceptual modeling. The formal type of modeling usually follows the principles seen in commonly used architecture frameworks, such as the Unified Architecture Framework (UAF), with domain models using UML and SysML formalisms [27,28]. These are useful for maintaining structure and subsystem interoperability and supporting specific integration needs. Lightweight architecture frameworks, such as CAFCR, with the support of simplified model representations, are aimed to be practical for a wider group of stakeholders [15]. Both aspects are important in HSI [29,30], but the study of the informal aspects of MUM-T development is lacking in the literature [26]. Therefore, we use CAFCR as a frame of reference, which allows us to gain insight into the less formal models a product development team uses and how they utilize them to understand and communicate the various system architectural aspects.

1.2. Research Objective

The research aims to investigate the use of conceptual modeling in facilitating HSI in Manned–Unmanned Systems. It also seeks to explore how advancements in this area can support both academic research and product development teams. The scope of this research encompasses the practical use of conceptual modeling within a case operating in the aerospace and defense domain. We will compare this to academic approaches, emphasizing the complexity of Manned–Unmanned Systems. The article’s purpose is to provide insight into the industry’s informal aspects of modeling. The research objective focuses on understanding, examining, and documenting how product development team members utilize conceptual modeling to facilitate HSI in Manned–Unmanned Systems. Consequently, we pose the research question: How do practitioners utilize conceptual modeling to facilitate Human Systems Integration in Manned–Unmanned Systems?
Four sub-questions discuss the following:
  • What are the conceptual modeling practices in the case company?
  • What conceptual models are used to facilitate Human Systems Integration in Manned–Unmanned Systems?
  • What conceptual models does the case company use in relation to lightweight architectural recommended practice?
  • How to facilitate the Human Systems Integration through conceptual modeling?
This paper examines what type of conceptual models the case company uses and how they conduct conceptual modeling. We then frame the case company’s insight within a lightweight architectural framework (CAFCR) and the HSI aspects of a system: technology, organization, and people. The research contributes to the systems engineering field by identifying gaps in current practices and literature and provides industry insights into the use of lightweight models and conceptual modeling processes in HSI for MUM-T applications.

2. Literature on Conceptual Models

2.1. Conceptual Modeling for Supporting Systems Development

We define the art of conceptual modeling in this paper as a process that reduces the complexity of systems to a level of abstraction that enables an individual or a group to understand and reason about the system of interest and its contextual influences and appreciations. This section explores various aspects of conceptual modeling, and it is divided into five paragraphs (a.–e.) each representing a different aspect of conceptual modeling as depicted in Figure 1.
  • According to the following sources, conceptual modeling is the process of creating one or more conceptual models and their associated activities. We define conceptual models as abstract, simplified representations of real-world systems, serving as a tool for analyzing a given problem or solution through understanding, communicating, and reasoning. These models, often graphical [31], provide a common language for clients and modelers [32] and are implementation-independent representations of the structure and system behavior from the real-world system [33]. They represent various aspects or structures [34] and consolidate structural and behavioral features to describe the System of Interest [35,36]. Conceptual models consist of various data forms, abstracting the system’s features [36], and describe objectives, inputs, outputs, content, assumptions, and simplifications [37]. They serve as architectural or abstraction tools, representing actual environments [37]. Essentially, conceptual models are tools that provide a manageable view of complex systems in understandable, communicable forms.
  • Conceptual models serve several purposes. They represent static and dynamic aspects [31] and aid in understanding complex systems [32,34]. They facilitate knowledge sharing and communication [35] and decompose systems into smaller sets for analytical purposes [38]. These models simplify reality through abstraction [39,40] and document structure and components [41]. They also help modelers and stakeholders understand the real world [36]. Lastly, they provide a tool for the representation of reality through abstraction [37]. Overall, conceptual modeling aims to create an understanding, reasoning, communication, decision-making, and problem-solving by simplifying complex systems while maintaining their essential features. An example of understanding is to have a sufficient understanding of the human behavior of the operator. Communication can be used to validate the task and workload of the operator with stakeholders.
  • Conceptual modeling often begins when there are known and unknown ambiguities in the system and its context. These uncertainties may arise from unexplored complexities and their influence on the final system solution [4]. Key drivers and qualities, originating from business and customer value propositions, need to be transformed into insight and actionable development tasks, which can be achieved through conceptual modeling [42]. The key drivers that influence the system’s behavior, such as technological advancements, organizational constraints, or human factors, can influence the performance of the system of interest. For instance, in the context of HSI, understanding the interplay between technology, organization, and people (TOP framework) [43] is an important aspect in which conceptual modeling is useful [44]. The TOP framework [43] is designed to consider technology, organization, and people drivers. Technology refers to both hardware and software artifacts. Organization covers the procedures, processes, and coordination of systems. People represent the human stakeholders involved, such as end-user operators.
  • In systems of systems architecture and design, conceptual modeling relies on multi-level abstraction. This process involves moving between different levels of abstraction, using various views and perspectives suitable for each level to understand the system comprehensively [15]. The choice of views and perspectives depends on factors such as the purpose of the modeling exercise, the required level of detail, and the potential impact of the modeling on the system. One such framework is CAFCR [15], a structured and iterative reasoning approach to architecture. CAFCR decomposes into five views: customer objectives, application, functional, conceptual, and realization. Each view addresses a specific aspect of the system, from understanding customer needs to defining technical implementation. The customer objectives view focuses on comprehending the customer’s problems and needs. The application view links the customer objectives with the technical implementation. The functional view captures the core of the product, including both its functional and quality requirements. This represents the ’what’ of the system, ensuring the requirements meet the customer’s expectations and stay within the system’s boundaries. The conceptual view explains the “how” of the system through concrete solutions. The realization view expands on the conceptual view by adding specific implementation details and quantifications to ensure the architecture functions as intended. Systems engineers use two primary approaches to navigate this space: open perceptive scanning and structured scanning with judgment [15]. Open perceptive scanning provides understanding and insight, while structured scanning and judgment are necessary for achieving results within a limited timeframe and with minimal effort. Multi-level abstraction in systems of systems is a useful tool for gaining a deeper understanding of complex systems, aiding in the design, validation, and implementation of solutions.
  • Conceptual modeling supports data sensemaking by interpreting and using the data, information, and knowledge within the context. The sensemaking mitigates the oversimplifications and facilitates informed decision-making in conceptual modeling [42]. As much as the models are context-specific, so are the data and information. Specifically, human factor data can be utilized for HSI. Examples of physiological human factor data are galvanic skin response to measure stress [45] and eye tracking for usability insight [46]. The self-rating technique, SART [47], and the freeze probe technique, SAGAT [48], are examples of methods to obtain information on the human mental aspects. Knowledge emerges when information is applied and understood in a particular context. For instance, operational procedures and weather conditions can be used to inform safety assessments or performance data from machines and event logs to guide manpower distribution decisions. Knowledge is central in system development, particularly the insights gained from key stakeholders such as end-users, peers, and subject matter experts. The value of knowledge in providing perspectives that aid in verifying and validating the system [26]. Wisdom arises when knowledge is used to make informed decisions, consider multiple perspectives, and achieve desired outcomes.

2.2. Applicable Conceptual Models in HSI for MUM-T Systems

We highlight 21 applicable conceptual models related to HSI used in the MUM-T system context, derived from a literature review that aimed to structure the field [26]. Table 1 describes the conceptual models.

2.3. Case Studies on Manned–Unmanned Teaming in Aerospace and Defense

To contextualize the literature on conceptual models, we now highlight case studies within the aerospace and defense sectors. We conducted a literature review based on the keywords and their synonyms: conceptual modeling, human systems, and unmanned systems. The literature selection process involved four stages: identification of 185 articles, screening of 162 after removing duplicates, skimming of 64 full-text articles for eligibility, and conducting an in-depth evaluation of 32 articles. According to this literature review that examined the models used, analytical approaches, and the data communicated in the Human Systems Integration of Manned–Unmanned Teaming [26], nine of the 32 articles conducted a case study related to aerospace and defense. We refer to these nine due to their higher similarity to the case company [7,11,59,60,61,62,63,64,65]. Figure 2 shows the number of conceptual models represented in these nine case studies. Worth noting that none of the above-mentioned articles conducted a meta-analysis on the use of conceptual modeling in the product development of Manned–Unmanned Systems from an HSI perspective.
The majority of the selected articles approach their studies by investigating the task and workload distribution during manned–unmanned operations [7,11,60,61,62,63,65]. Human factor data are typically used during workload analysis modeling. Human factor data here means objective data (e.g., eye tracking) and subjective assessments (e.g., NASA Task Load Index). For example, insight into the interface and interactions can be achieved through human-in-the-loop simulation, where the human performance data elevate the understanding of the operator states in various scenarios and are used for evaluating new procedures and validating concepts [7]. In addition to technical system data, a bottom-up approach can support the understanding of how subsystems and components affect the system of interest and the system of systems [65]. Statistical approaches, such as Bayesian analysis and principal component analysis, were used to analyze the data to investigate situational awareness [59]. An argument suggests that designs that overlook human factors could potentially overestimate both human and system capabilities, as they are based on unrealistic assumptions [62].
HSI can be approached by gathering data from human-in-the-loop activities and documentation as well as harvesting knowledge from subject matter experts and end-users [29,30]. A study assessed the application of co-creation and design thinking [59]. Lessons learned were that some of the best input does not necessarily come from numerical data. Furthermore, they recognized that even simple drafts and prototypes could offer significant insights for the stakeholders involved. Sometimes, the representations used by the developer are not the most suitable type of visualization for the end-user [66], while an informal conceptual sketch is [59]. Feedback from end-users can be highly beneficial, as it provides new insight and ideas, whereas the developers believe they are restricted by rules, regulations, and technical limitations [59]. McGowan et al. [59] emphasize that complex projects require subject matter experts from various disciplines. Interdisciplinary teams might provide a holistic perspective beyond just the technical, which is needed to understand the system’s capabilities [59]. The foundation of HSI is the combination of technical, organizational, and human aspects [29], which form the system.

3. Research Methodology

This research was conducted within an industrial company over a span of three years as part of an industry–academia collaborative research project investigating early validation, transfer of human insight, and innovation across engineering disciplines. The company was selected due to its incorporation of systems engineering practices and its development of complex Manned–Unmanned Systems. During this period, the primary author participated in three main research cycles, which form the backbone of the investigations presented in this paper. The following details outline the methodological framework using these research cycles:
  • Problem understanding: Interviews, survey, and literature review;
  • Exploration and observation: Case study of the development team;
  • Classification and evaluation: Interview, Survey and Analysis.
Earlier papers have partially published results from the first two cycles.

3.1. Problem Understanding

The initial research cycle consisted of a set of interviews [5] to understand the problem, followed by a survey [12] in a set of high-tech companies, including the case company. The relevant insights from [5,12] are used in this article. The literature review presented in [26] established the foundation for understanding and classifying conceptual models. The present article utilizes this to compare industry practices with those detailed in published articles. We organized these based on abstraction and formality levels, as illustrated in Figure 3, to better understand their use. Abstract models are mental models that require imagination and tend to be black box-oriented, while concrete models are grounded in reality and closer to the final product. Informal models are free-form and are typically more artistic, while formal models follow standardized modeling language and guidelines. Informal models do not adhere to formal semantics, whereas formal models can be logical, quantitative, geometric, or surrogate models, each expressed with explicit semantics [29]. Seven systems engineering academics undertook the classification task, individually placing 21 models from the literature on an abstract–formality diagram. We combined the academics’ contribution into one diagram and divided it into eight sections (A–H). Figure 3 shows the final abstract–formality diagram.

3.2. Exploration and Observation

The second research cycle lasted for 18 months when the primary author was co-located with a development group [4]. The author performed five passive observations of company meetings, eight participatory meetings, and three workshops. Additionally, the author attended an average of one research project meeting every month. The company team members and the researcher collaboratively explored and tested the conceptual models in a project. The conceptual models were evaluated according to their desirability, feasibility, and viability. Additionally, we measured their modeling values against impact factors.

3.3. Classification and Evaluation

The two previous research cycles formed the foundation for the third main research cycle. The iteration is divided into three sub-steps:
  • Interview with project team members
    • One-hour interview per participant with seven anchor questions
    • Verification from participants
  • Survey on types of conceptual models
    • Participants plotting conceptual model use on abstract–formality diagram according to CAFCAR and TOP framework
    • Summarization of results and plotting to a bar chart
  • Comparison, analysis, and evaluation
    • Comparing conceptual modeling use between literature and the participants
    • Analysis and evaluation

3.3.1. Interview with Project Team Members

Eight participants were selected by our industry contact based on their technical and system-oriented contributions to the case study project. However, one participant was unavailable due to their workload, leading to seven participants who participated in the interviews and survey. The selected individuals represent core members in the systems design and architecture activities within the product development team. Their central involvement in the project provides sufficient understanding and perspective on how communication, understanding, and reasoning are conducted in transdisciplinary collaboration within the specific project. Of the participants, there was one chief engineer, three systems architects, two product managers, and one interactive designer. The range of tasks includes managing end-user interfaces, investigating future technological solutions, translating abstract concepts for software implementation, modeling subsystems, synchronizing hardware and software capabilities, standardizing components, managing requirements, risk mitigation, and stakeholder management. Table 2 shows the interviewees’ experience. The goal was to understand how practitioners use conceptual modeling to facilitate HSI in Manned–Unmanned Systems. To enable this, we developed an interview guide based on our literature review [26], a parallel case study [44], and previously identified knowledge gaps within the case company [4]. Each one-on-one interview lasted for an hour and incorporated a mix of open-ended anchor questions from the interview guide. After each interview, we compiled a summary of the interview notes and had them verified by the interviewees. While the interviews provide deeper insights and allow for clarifications, they may be subject to bias. Additionally, the quality of data depends on the interviewee’s willingness to share information and their ability to articulate their thoughts clearly.
We addressed the research question in the interview analysis by examining the conceptual models used and assessing the developers’ perceived effectiveness. We address three topics: the purpose of complex modeling, the approach to conceptual modeling, and how to navigate complex systems. Below, we show how the anchor interview questions are linked to each of these overarching topics.
Practitioners’ purpose for doing conceptual modeling:
  • “What would you describe conceptual modeling as?”
  • “Why do you model things?”
How practitioners approach conceptual modeling:
c.
“When are you doing conceptual modeling?”
d.
“With whom are you doing modeling with?”
e.
“How do you do conceptual modeling?”
How practitioners navigate complexity with modeling and analysis:
  • “What part of the system do you need to model?”
  • “What inputs are used for conceptual modeling?”

3.3.2. Survey on Types of Conceptual Models

During the interviews, each interviewee marked their use of conceptual models on printed abstract–formality diagrams, Figure 3. The goal was to connect the practitioners’ classification of conceptual modeling by associating it with the CAFCR [15] and TOP [43] framework. We clarified each of the conceptual models to mitigate potential bias related to misinterpretation of the various model types.
The researcher gave the participants a description of each CAFCR architectural viewpoint and asked them what conceptual models they used when modeling the various perspectives. The participants marked the applicable conceptual models according to each of the five CAFCR views on the abstract–formality diagram (Figure 3).
The researcher asked the participants what parts of the system they work on and then asked them what type of conceptual model they prefer to use, if applicable, when they model the technological, organizational, and people aspects of the system. The participants marked each of the three TOP aspects on a copy of the abstract–formality diagram. Figure 4 is an example from one participant, showing the mapping of models used in relation to the system aspects, where blue = technology, yellow = organizational, and pink = people.
We summarized the survey results from the seven case company participants and visualized them using bar charts. Note that the low number of participants cannot provide statistically significant answers, but together with qualitative answers, the bar charts support our conclusions.

3.3.3. Comparison, Analysis, and Evaluation

We conducted a comparative analysis of relevant case studies from a literature review [26] and industry findings to identify similarities and differences in conceptual modeling practices. The relevant case studies within the aerospace and defense domain researching MUM-T applications underwent a review based on the type of models used. We compared the percentage of conceptual models represented in these case studies and the results from the case company.
Furthermore, we have classified the practice into a framework for lightweight architecture [15] (CAFCR) and the HSI aspects [43] (TOP) based on the results from the survey on the types of conceptual models that practitioners use. An evaluation of the CAFCR results takes place according to its recommended practices. We analyzed the TOP results and synthesized how the conceptual modeling approach facilitates the HSI. In another case study of MUM-T development, we undertook a similar classification, where we mapped their conceptual models and classified them according to the CAFCR viewpoints and TOP aspects [44]. We note the similarities between [44] and this case company.

4. Conceptual Modeling Practices in Case Company

This section presents the outputs from interviews and surveys conducted within the case company, supported by observations and exploration. The insights are organized according to the “why”, “what”, and “how” aspects related to practitioners’ utilization of conceptual modeling to facilitate Human Systems Integration in Manned–Unmanned Systems.
  • Why do practitioners use conceptual modeling?
  • What conceptual models do practitioners utilize?
  • How do practitioners navigate complexity through conceptual modeling?

4.1. Why Do Practitioners Use Conceptual Modeling?

A product manager started by explaining the following: “A conceptual model is essentially a drawing of a concept, a process that begins when you start examining something”. He continued to explain why: “… with the intention of solving a task and ending with a preliminary solution. Afterwards, we proceed with more formality and dive into the details”. Another person, a systems architect, explained that conceptual models could aid in transforming customer requirements into subsystems and help illustrate concepts to better understand a system’s structure and function. Two respondents independently stated that peers seem to be using such informal models without knowing the formal definition of conceptual models.
When specifically answering what is the purpose of conceptual modeling, one systems architect mentioned that they perform conceptual modeling to support the transformation of customer requirements into subsystems and component levels, such as modeling the interaction between hardware and software. Another systems architect responded, “We do modeling to ensure synchronization between documents and implementation, serving as an enforcer of the architecture”.
Three interviewees mentioned that visualized models and drawings are often easier to comprehend compared to text-based documentation. Specifically, one stated, “Previously, the strategy documentation was communicated mainly through a Word document… However, it is important to reach out to a transdisciplinary audience and present it such that it is understandable… Thus, we model things for transdisciplinary communication.” Furthermore, he pointed out that conceptual modeling helps in bridging gaps between technical influencers and other stakeholders. As such, conceptual modeling makes it easier for all stakeholders to contribute effectively to the project’s success.
In conclusion, the interviewees within the company characterized conceptual modeling as a problem-solving approach. This approach entails the generation of holistic views and perspectives of a system and its associated problem domain.

4.2. What Conceptual Models Do Practitioners Utilize?

The practitioners stated that they use different types of models. This includes sequence diagrams, requirement overviews, concept sketches, and so on. These 21 conceptual models have varying degrees of formality, suggesting a balance between free-form and rule-based formats.
The first column of Figure 5 lists 21 conceptual models that the practitioners have marked as used in their work on MUM-T systems development. The model that was marked by most interviews (Sequence Diagrams) appears at the top. Examples of frequently used formal models are sequence and requirement overview diagrams and informal models like concept sketches and storytelling.
Figure 5 indicates what, and partly for what, the practitioners use each of these. In the interviews, we asked to classify for what they use each type of model according to the two frameworks: CAFCR and TOP. The CAFCR architectural framework represents the following: customer, application, functional, conceptual, and realization. These viewpoints are used by architects to make a complete solution satisfying stakeholder needs. TOP stands for technology, organization, and people. The TOP framework is used to investigate the Human Systems Integration aspects of architecting.
The first row of Figure 5 represents an x-axis with eight different viewpoints: five CAFCR and three TOP. The second row represents the number of interviewees who had applied sequence diagrams. More specifically, the second row can be read as follows: the sequence diagrams were said by one of the interviewees to display the customer view (upper yellow bar), while two persons used sequence diagrams for the application view (upper light blue bar), one functional (red) and three conceptual (green), and so on. Note that the CAFCR columns range from zero to three, while the TOP columns range from zero to five.
The conceptual models most represented among the CAFCR views are sequence diagram, requirement overview, concept sketch, state diagram, storytelling, and swimlane diagram. Note also that almost no one states they use any models in the realization view. The in-depth interviews shed more insight into this. One of the systems architects commented, “There is very little time spent in the realization view as there is a lack of data from the systems”. Another architect highlighted, “We do some modeling closer to the realization view, but not much, as this is where we see domain models being used”.
A product manager acknowledged the importance of connecting and jumping between viewpoints, stating, “As a product manager, one needs to get into the dirt to see if the ‘realization’ is answering the things the ‘customer’ needs. For instance, consider a camera tracker. If the customer doesn’t specify its intended purpose, we are left wondering whether it’s meant to track planes or people”.
Four interviewees, with various roles, mentioned that they mostly model in the conceptual view of CAFCR. One of the systems architects stated, “We model to a specific abstraction before handover to developer…The software developer needs autonomy to solve the ‘black box’, except in cases where it is highly complex and critical”. Another mentioned that “a key point with the conceptual models is not to be too fluffy or abstract”.
According to the product managers, the conceptual modeling occurs mainly during the functional and conceptual architectural views, saying, “I am constantly asking ‘why’. I believe understanding the ‘why’ is crucial to doing the job effectively. Therefore, when working in the ‘functional’ and ‘conceptual’, I look back into the ‘customer’”.
Six participants mentioned that the considerable distance from external stakeholders, such as end-user operators and customers, could result in insufficient focus on the customer view. However, two interviewees mentioned that they appreciate being presented with models connected with the application aspect. This aspect bridges the gap between customer objectives and technical implementation. One systems architect highlights that the UAF is now being implemented to ensure a stronger presence in the customer and application views.
Each participant highlighted which conceptual models they use to navigate the various system’s aspects according to the technology, organization, and people aspects (TOP) [43]. See the last three columns in Figure 5. According to the survey, when modeling the HSI aspects of the system, the following models are used:
  • Technology: Sequence diagrams, requirement overview, and functional flow.
  • Organization: Stakeholder maps, swimlane diagrams, and block diagrams.
  • People: Storytelling, user personas, and activity diagrams.
When modeling the system’s technological components, practitioners from the case company tend to favor more formal types of models. Conversely, when modeling the people within the system, they opt for a higher degree of informal models. As for the organizational aspects of the system, they employ a mix of both informal and formal models but show a slight preference for the latter.
The technology aspect was the most common aspect, represented by 43% of the occurrences, while people was represented by 30% and organization was represented by 27%. That is, they use fewer variations of models in organization and people views.
An interesting opinion came up during the in-depth interviews. A systems architect mentioned that the Through Life Support group is responsible for the ‘O’ and ‘P’ components in TOP. Furthermore, the Through Life Support group leans towards the ‘CA’ in CAFCR, focusing on the wider aspects of the life cycle, such as maintenance. On the other hand, systems architects primarily deal with technical requirements and solutions. The systems architect further explained the importance of modeling the interaction between hardware, software, and other subsystems to understand better how each component contributes to the system’s overall functionality. According to the systems architect, software alone constitutes only 20% of the system. Thus, there is a need to model other components. This is why they construct all the logical subsystems, such as the motion system and sight system, which further may include a video system as a subsystem. For instance, the camera in the video system has a video chain that sends data through the network and then to the screen.
A project manager claimed that modeling the technology part is mainly related to the sequence of functions. In comparison, organizational models revolve around how the customer will maintain the system. From the people aspect, the project manager’s goal is to explain the role and actions of the operator involved, with the help of storytelling and other visual aids for illustrations. For example, what happens during the morning routine for the system on site. Another project manager highlighted the importance of mixing the aspects by saying, “I often incorporate multiple views (technological, organizational, and people) into the same model”. For example, “The Concept sketch is used iteratively to understand various aspects of the system, ranging from technological to organizational and people-views”.

4.3. How Do Practitioners Navigate Complexity Through Conceptual Modeling?

This section examines the methods practitioners employ to navigate complexity through conceptual modeling. The insights are related to the modeling process, the participants involved, and the tools utilized. We explore how cross-discipline teaming, platform tools, and domain-specific practices contribute to the conceptual modeling process.
The interviews provided input on the modeling process regarding participants and tools used. On the question of with whom they are performing conceptual modeling, a systems architect replied, “There is a lot of cross-discipline teaming. The (conceptual modeling) process is very people-oriented”. One systems architect mentioned that whiteboard modeling with peers is typically the initial step of conceptual modeling, followed by working together on a screen-based platform. They use various platform tools, such as Whiteboard, PowerPoint, MagicDraw, Visio, and Adobe XD, to draw their conceptual models. At the same time, domain-specific disciplines use their own set of specific tools for modeling practices. A system architect said software domain modeling uses UML, while hardware creates 3D models to draw up elements such as cable layouts. PDF documents are the primary means of transferring information between these domain tools.
The interviewees provided insight into data, information, and knowledge acquisition for their models and analysis. The chief engineer emphasized that significant interactions and iterations occur between external partners, necessitating frequent meetings and workshops. The interactive designer pointed out, “External actors have already defined the system’s boundaries, but one must clarify the constraints to determine the degree of freedom”. The three system architects stated that specifications and requirements serve as the primary inputs for the modeling and analysis of their systems. Understanding the customer’s true needs is essential. Sometimes, the requirements are vague, while they are very detailed at other times. The requirements from the systems engineers are then passed further down the production pipeline. The project managers emphasized the importance of understanding the source of the requirements, stating, “It is important to determine whether it (the set of requirements) originated directly from the customer or if it is an internal requirement, and why this particular task needs to be solved”. An additional source of input information is the customer’s intended use for the product.
The interviewees indicated that a significant portion of the input for modeling and analysis arises from discussions with subject matter experts, such as a camera specialist. Thus, they acknowledge the importance of recognizing and utilizing the knowledge, skills, and expertise already present within the organization during conceptual modeling. The majority of communication and interactions transpire through meetings and emails. The modeling process involves multiple iterations, conducted via email and both formal and informal meetings, allowing the models to mature over time.
Based on our observations and exploration [4], we discovered that informal conceptual models can be useful and valuable for understanding, reasoning, communicating, and making decisions during HSI activities. One such activity involved gaining insight into the situational awareness of operators in MUM-T systems. Figure 6 illustrates storytelling and visual ConOps as published in [4]. We observed that storytelling, visual ConOps, and various dynamic workflow models are desirable in product development. This is because they add contextual understanding and enhance discussions among stakeholders. We saw that the project team members established empathy for the end-users by verbally describing their interactions while navigating the visuals of the conceptual models. These conceptual models are feasible as low-fidelity, easy-to-create models, particularly in the early stages of product development. Furthermore, their viability lies in their ability to provide rapid, iterative learning and cost-effectiveness, which aligns with systems engineering practices.
In summary, the practitioners manage complexity in conceptual modeling through cross-disciplinary teaming, utilization of diverse platform tools, and domain-specific practices. The process relies on understanding the customer’s needs and identifying the origin of requirements. Specifications, requirements, and discussions with subject matter experts primarily drive the inputs for the modeling and analysis. The modeling process is highly people-oriented, often starting with whiteboard modeling and progressing to screen-based platforms. The conceptual models, such as storytelling, visual ConOps, and various dynamic workflow models, are desirable, feasible, and viable in their product development environment. The process involves multiple iterations, which allow the models to evolve over time. This approach enables practitioners to develop mature models that effectively tackle the inherent complexity in their systems.

5. Discussion

This article highlights the current knowledge and practice of conceptual modeling to facilitate HSI in MUM-T by investigating a case company and comparing the insight with other case studies. This section discusses the main research question: How do practitioners utilize conceptual modeling to facilitate Human Systems Integration in Manned–Unmanned Systems? Four sub-questions discuss the following:
  • What are the conceptual modeling practices in the case company?
  • What conceptual models are used to facilitate Human Systems Integration in Manned–Unmanned Systems?
  • What conceptual models does the case company use in relation to lightweight architectural recommended practice?
  • How to facilitate the Human Systems Integration through conceptual modeling?

5.1. Conceptual Modeling Practice in the Case Company

This sub-section first highlights the application of conceptual modeling, followed by an explanation of what practitioners perceive as the purpose of conceptual modeling. It then examines the types of conceptual models typically used in various architectural viewpoints.
The case company practitioners mention that conceptual modeling involves multiple iterations through various platform tools. The conceptual modeling tools range from lightweight whiteboard sketching to more advanced platforms such as MagicDraw. The lightweight platforms are typically used in synergy with co-creation, design thinking, and other soft systems methodologies [25,44,59]. Our research in the case company indicates that visual support during meetings facilitates engagement from various stakeholders, fostering discussion and contextual understanding [4].
The practitioners in the case company see conceptual modeling as a problem-solving approach that involves creating holistic views and perspectives of a system and its problem domain. This approach yields preliminary solutions that can take various forms, such as sequence, use case, logical, or reference models. The practitioners use conceptual modeling to support the transformation of customer requirements into subsystems and component levels, ensure synchronization between documents and implementation, facilitate transdisciplinary communication among diverse stakeholders, and bridge gaps between technical influencers. They further suggest that stakeholders can more easily understand conceptual models by visualizing complex concepts through drawings or diagrams than by pure text-based documentation. In comparison, various cases from the literature use models to represent tasks and workload, as well as to understand the human reasoning process and capabilities during operations [26]. It is also seen that conceptual modeling aids in gaining system awareness and decision-making [18,19]. Thus, conceptual modeling aids in understanding, communicating, reasoning, and decision-making during the development of complex systems.
Our results show that informal conceptual models, such as concept sketching and storytelling, typically appear in the customers’ problem viewpoint. The informal models are used to understand and explore customer problems and needs before investigating the technical domain. On the other hand, formal models, such as state diagrams, which follow more specific forms and rules, seem more applicable for examining how concrete design solutions should interact and function. The transition from the abstract and informal to the concrete and formal may be rooted in the need to reduce the system complexity to an abstraction level that enables reasoning while still making sense. This process involves transforming customer and business values into preliminary solutions, thereby making the concepts more explicit. Throughout this process, it can facilitate transdisciplinary communication, particularly when working on Human Systems Integration in the development of Manned–Unmanned Systems.

5.2. Conceptual Models Used to Facilitate Human Systems Integration in Manned–Unmanned Systems

This sub-section discusses the similarities and differences between the conceptual models used by the case company and those used in another case study within the Norwegian domain. We have noticed certain commonalities and variations. Therefore, the sub-section will further compare these with case studies discovered from a systematic literature review within the aerospace and defense domain.
The case company predominantly emphasizes formal models (almost two-thirds), as indicated in Figure 3 and Figure 5. Furthermore, three-quarters of these conceptual models fell into the abstract category. This preference for formal and abstract models may be influenced by the demand of their aerospace and defense customers, who require the use of formal architecture aspects represented by UAF [27] and similar frameworks using UML and SysML. Our case study identified three conceptual models—storytelling, visual ConOps, and dynamic workflow models—as particularly effective for providing HSI insight in the context of MUM-T systems [4]. These models support stakeholder engagement and provide insight into situational awareness and system behavior. The case study found the conceptual models to be desirable, feasible, and viable.
The authors investigated another Norwegian case company that developed a human and autonomous collaborative system with a convoy of vehicles sweeping the runway at airports [44]. They also used a mix of formal and informal models in their system development. Examples of typically formal models were types of block and functional flow diagrams and informal models that gave a visual aided representation, such as mock-up and visual ConOps [44]. The insight may indicate that a mix of informal and formal types of conceptual models is useful during the architecting and design of the HSI.
A limitation of this comparison is that the other Norwegian case study [44] is set in a confined industrial environment, which brings other requirements and expectations from the system than from an aerospace and defense case. Therefore, the following discussion investigates published case studies set in the aerospace and defense domain that study the MUM-T applications to understand the wider practice of conceptual modeling. Figure 7 illustrates the conceptual models represented in the case company next to the nine aerospace and defense cases from published articles derived from a literature review study [26]. The figure shows each of the percentages of representation among the 21 conceptual models listed in Table 1. This means that the concept sketch type was mentioned 71% of the time in the case company, whereas it appeared in 11% of the nine case articles.
Figure 7 shows that the context diagram, which is designed to illustrate entities that influence or are influenced by the system of interest, scores similarly. The context diagram is typically used to identify the external interfaces and limitations [49,52]. According to the interactive designer, reasoning around the context provides an understanding of the degree of freedom the system can be developed. The case company and the selected literature both visualize the concept of operation. Visual ConOps may support envisioning and validating the tasks the system of interest will be exposed to, which is useful for engaging stakeholders [58].
The case company uses the sequence diagram, requirement overview, swimlane diagram, and state diagram more often than the other nine companies from the literature. These are types of models that are commonly found in formal architecting. For instance, when modeling the system’s personnel, UAF recommends using block and internal block definitions, activity, state, sequence, and parametric diagrams [27]. The company maintains a series of hardware and software interfaces. Using such formal representations may support the compatibility between such interfaces due to standardized protocols.
In the case company, informal types of models like concept sketches, storytelling, and user personas are more prevalent than in the literature. According to the interviews, designers use the concept sketch to understand various aspects of the system. The concept sketch is more common in the case company than in the nine case studies. This could be because the case company often uses it in the early stages of conceptual development. The nine case studies might not focus on this early stage, which could explain why they feature the concept sketch less. The case company mentioned that they use storytelling to explain roles and operational actions, such as the start-up routines of the system before a mission. Storytelling and user personas may be interconnected representations due to their association with each other. For example, a specific user conducts an action that pushes the story forward. Therefore, the case company represents both of them. The nine case studies might not represent storytelling and user personas because they might narrate a story through other means than what this analysis captures. Furthermore, these case studies may focus more on technical aspects and quantitative data.
However, quantification representations are more noticeable in academic articles compared to our results. This can be because academic papers have an underlying need to show quantified data to be published, while in the industry, such quantifications are passed over to detail engineering. Another industrial case study that develops MUM-T applications shows the need for quantificational model representations and viewpoints during the informal architecting process [44]. Furthermore, the majority of the nine articles focus on human factor data, which may skew the quantification representation. The lack of readily available data is a challenge with quantification during conceptual architecting. Moreover, we may believe that making assumptions with best-guess numbers is daunting for an engineer who may feel accountable for any assumptions in the early phase. However, assumptions can be used as a baseline, which can later be measured and adjusted with quantification, as proposed in the case company [4].
In summary, academic literature may not sufficiently emphasize the importance of informal approaches, such as concept sketching and storytelling. One Norwegian case company highlighted the use of informal models, such as visual-aided representations, where diagrams are mixed to create new insights. This approach was recognized as useful and effective when developing Manned–Unmanned Systems [44]. Additionally, other visualization models, such as mock-ups and visual ConOps, can provide engagement, feedback, and shared understanding [4]. Secondly, the more structured types of presentations, such as swimlane, sequence, and state diagram, have a stronger presence in the case company than what is present in academic papers. Thirdly, the company places a high focus on requirement management, which is less prevalent in the literature review investigating conceptual models. These three points highlight a gap in academic literature.
On the other hand, practitioners may not fully recognize the significance of using quantification during conceptual modeling. The low use of quantifications is also evident in the other Norwegian case company [44]. The lack of incorporating data or “best guess” may be rooted in a lack of easily available technical system data and human factor data, which is usually needed to publish academic articles. Furthermore, allocating resources to develop simulators occurs later in the design phase, which may put quantifications to a later stage.

5.3. Lightweight Architectural Practice During MUM-T Development

We used the architectural framework CAFCR as a frame of reference to understand what conceptual models they use according to the various architectural viewpoints present in a system. The results indicate that most variations of conceptual models are related to application and functional viewpoints, with slightly lower counts for conceptual and customer. The lowest variation representation is realization. The product managers emphasized the importance of architectural viewpoint hopping, such as moving between the conceptual and customer aspects and bridging between the views to ensure effective realization. According to the teaching of system modeling and analysis with reference to the CAFCR framework [67], the recommended distribution of effort should gradually increase from the customer objective to the conceptual, with some support of realization. Insight into the case company suggests that the realization is lacking according to this practice.
The original research of the CAFCR framework [15], connected to the architecture of medical high-tech systems, suggested potential methods and techniques to use in each architectural view. With reference to Figure 5, we highlight how the conceptual models in our case company compare to the proposed distribution of models. From the customer, application, and functional architectural viewpoint, the purpose is to understand customer needs and how a technical implementation could solve the issue by developing a product that meets the functional and quality requirements. What the case company does similarly is to capture the customer requirements early on. Additionally, they use storytelling, which is suggested to be the starting point for any case analysis and design studies [15]. The case company further enhances the storytelling by using user persona descriptions. However, stakeholder mapping had a low representation, which is important for mapping their potential concerns. Additionally, context diagram to define the system and its boundaries lacks representation. Further, the case company utilizes dynamic and entity relationship models, which the framework suggests. This is accomplished through swimlane, activity, block, and state diagrams. The case company adds to the initial viewpoints using visual aids and concept sketches, which are helpful in telling a story and exploring different scenarios [52].
The conceptualization and realization are about depicting the how of the system with concrete solutions, implementation details, and quantifications to ensure that the system functions as intended. The framework recommends conceptualizing the start-up and shutdown process and creating work breakdown overviews through entity relationship diagrams. The case company marked their use of similar diagrams, such as sequence and activity diagrams. The CAFCR framework advises functional and physical decomposition, although the case company did not map functional and physical flow diagrams during the conceptual and realization viewpoint. The case company conceptualizes the system through mock-ups and prototyping, such as user interfaces, which can be used to support communication, learning, and support decision-making [4] and can be used to analyze the performance [15]. However, the respondents rarely mentioned data and quantification. The lack of quantificational use during conceptual modeling is a noticeable difference between the case company and the recommended CAFCR practice.

5.4. Conceptual Modeling to Facilitate Human Systems Integration

This article utilizes the TOP (technology–organization–people) framework, which is foundational to HSI [29], to examine how conceptual models were used during the product development of the MUM-T systems by the development team.
The system architect practitioners tend to focus on technical requirements, while the Through Life Support group supports more of the organizational and people-related elements. Through the lens of this study, there may be a lack of ownership across the TOP aspects, as there is not one group holding the ownership of the three combined HSI aspects. Nevertheless, the interviewees deemed modeling the interactions between sub-functions critical to understanding the overall system functionalities, specifically in the technological aspects. From an HSI perspective, understanding the soft aspects of the system, such as organizational and people aspects, is also essential [29,30]. These soft aspects include acknowledging customer needs and the context. Subject matter experts can enrich these through communication, according to the interviews. Therefore, communicating both the technical and softer aspects in conceptual modeling practice is key to covering the range of TOP aspects.
The practitioners at the case company utilize a variety of conceptual models for different aspects of system modeling. For the technology aspect, formal models such as sequence diagrams, requirement overviews, functional flow diagrams, and state diagrams are predominantly used. The organization aspect sees the use of stakeholder maps, swimlane diagrams, and block diagrams. Meanwhile, the people aspect is modeled using informal models like storytelling, user personas, and concept sketches. The results suggest that the choice of conceptual models depends on the aspect of the modeled system. The technology aspect prefers formal models. The use of formal models for the technology aspect suggests a systematic and structured approach to understanding and representing the technological components of the system. On the other hand, the people aspect, which necessitates a more flexible and human-centered approach, is better suited to informal models, such as storytelling, as illustrated in Figure 6. This more free-form approach could potentially allow for a greater degree of empathetic understanding of user needs and behaviors, which is important in the validation of the system. The organization aspect appears to benefit from both sides of formality, with a slight preference for selecting formal models. This may be due to the need to represent the structured process within the dynamic and complex nature of the context in which the system of interest operates. Thus, the case company applies different conceptual models tailored to the specific aspects to understand, capture, and represent the unique system elements relevant to developing their MUM-T application.
The variation in conceptual models may be rooted in the development focus, meaning a higher focus may result in a diverse use of conceptual models. In the case company, they select from a larger variety of models when modeling the technology aspects (43%), compared to the organization (27%) and people (30%). This could be because the majority of the development in the case company is related to creating and implementing technical systems. Soft systems, such as end-users and stakeholders, typically use and appreciate the technical system of interest. The customer typically owns these soft system elements, not the product provider. Due to confidentiality and the use of various platforms in the case company, we could not quantify the type and number of actual models created. However, we can draw upon quantitative insights from the other Norwegian case study [44] as a reference for discussion. Both the case company and the other case study develop and deliver technical systems with MUM-T capabilities to a customer. Looking at the quantitative results from the other case study [44], based on an analysis of the conceptual models used (n = 477), the majority of the models created were connected to technology (60%), followed by organization (21%) and people aspects (19%). Furthermore, half of the conceptual model representations focused on one aspect, while the other half had a mix of TOP aspects in them. Given that the case company uses conceptual models for transdisciplinary collaboration, the interconnectivity between the TOP aspects, and especially the technology part, may be rooted in the necessity of using various model representations to understand and communicate the complexity.
However, domain, company size, and cultural differences make system development highly context-dependent. Literature on this topic is scarce. This early indication needs further research. Researchers should consider expanding with other case studies and companies that develop MUM-T systems. Additional insight will help the systems engineering research field understand how HSI modeling practices are incorporated into companies.

6. Conclusions

This article provides insights into the practical application of lightweight architectural approaches during the development of complex systems. The research investigates the use of conceptual models in the context of HSI in MUM-T applications of an aerospace and defense case study. Conceptual modeling aids in understanding, communicating, reasoning, and decision-making during the development of complex systems. Our research builds upon a case study with follow-up interviews and surveys with project team members involved in, or closely associated with, the systems engineering aspect of Manned–Unmanned Systems. Additionally, we have examined and compared the results to other published case studies on Manned–Unmanned Systems.
This article highlights the lack of focus in academic literature on the importance of using informal approaches, such as concept sketching and storytelling, in industrial settings. Experiments suggest that conceptual modeling, with storytelling, visual ConOps, and dynamic workflow models, is suitable within the case company. Such informal conceptual models are agile, low-tech, and accessible, making them desirable, viable, and feasible for facilitating HSI. Additionally, observations show that practitioners in the case company focus on requirement management, a focus not as prevalent in the literature review on conceptual models. The research indicates that the practitioners in the case company visualize the technology aspect through formal-leaning representations, while people aspects are informal-leaning. On the other hand, modeling for the organizational aspect ranges from informal to formal. Thus, a mix of informal and formal types of conceptual models is suggested as being useful during the architecting and design of the HSI. Finally, the findings suggest that the practitioners may not fully recognize the importance of quantification during conceptual modeling in Manned–Unmanned Systems development.
Thus, we recommend future research on integrating informal and quantifiable conceptual models within transdisciplinary collaboration in product development teams. Additionally, it would benefit the HSI research to investigate the emphasis various companies place on modeling the technology, organization, and people aspects of the systems they develop, especially in MUM-T applications. Future research could also measure the effectiveness of different conceptual models in terms of conveying HSI aspects to the relevant stakeholders and identify best practices for integrating suitable conceptual modeling approaches into the development process. In this case study, we mapped the use of various types of conceptual models but lacked the research data to conclude the frequency of use and their long-term effect on systems development. Further limitations of this research are connected to the interviews and surveys, as the participants’ responses may be influenced by their own cognition, experience, and emotions, making it difficult to fully capture their true opinions and behaviors. Additionally, the analysis is based on a single case company, which does not fully represent the diverse practices and experiences of conceptual modeling in HSI across different domains and company sizes.

Author Contributions

Conceptualization, T.L., K.F. and G.M.; methodology, T.L., K.F. and G.M.; validation, T.L., K.F. and G.M.; formal analysis, T.L., K.F. and G.M.; investigation, T.L.; resources, T.L.; data curation, T.L., K.F. and G.M.; writing—original draft preparation, T.L.; writing—review and editing, T.L., K.F. and G.M.; visualization, T.L., K.F. and G.M.; supervision, K.F. and G.M.; project administration, K.F.; funding acquisition, K.F. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded by The Norwegian Research Council, grant number 317862.

Data Availability Statement

Data not available due to privacy.

Acknowledgments

Thank you to the case company for industrial insight and to the researchers who contributed to mapping the conceptual model types.

Conflicts of Interest

The authors declare no conflicts of interest. The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript; or in the decision to publish the results.

References

  1. Systems Engineering Vision 2035. Available online: https://www.incose.org/publications/se-vision-2035 (accessed on 25 September 2024).
  2. Oppl, S. Supporting the Collaborative Construction of a Shared Understanding About Work with a Guided Conceptual Modeling Technique. Group Decis. Negot. 2017, 26, 247–283. [Google Scholar] [CrossRef]
  3. Borches, P.D.; Bonnema, G.M. 3.3.1 A3 Architecture Overviews: Focusing Architectural Knowledge to Support Evolution of Complex Systems. INCOSE Int. Symp. 2010, 20, 354–369. [Google Scholar] [CrossRef]
  4. Langen, T.; Muller, G.; Falk, K. Conceptual Modeling for Human Systems Integration in Manned-Unmanned Teaming. Hum. Interact. Emerg. Technol. Artif. Intell. Future Appl. 2023, 111, 91–101. [Google Scholar]
  5. Langen, T.; Falk, K.; Mansouri, M. A Systems Thinking Approach to Data-Driven Product Development. Proc. Des. Soc. 2022, 2, 1915–1924. [Google Scholar] [CrossRef]
  6. Snowden, D.J.; Boone, M.E. A Leader’s Framework for Decision Making. Harv. Bus. Rev. 2007, 85, 68. [Google Scholar]
  7. Lim, Y.; Gardi, A.; Sabatini, R.; Ramasamy, S.; Kistan, T.; Ezer, N.; Vince, J.; Bolia, R. Avionics Human-Machine Interfaces and Interactions for Manned and Unmanned Aircraft. Progress Aerosp. Sci. 2018, 102, 1–46. [Google Scholar] [CrossRef]
  8. SAE International. Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles; SAE: Paris, France, 2021. [Google Scholar]
  9. Helle, D.E.; Frølich, M.; Langen, T.; Muller, G. Situational Awareness and Human Factors When Designing Complex Systems. INCOSE Int. Symp. 2022, 32, 167–178. [Google Scholar] [CrossRef]
  10. Sticha, P.J.; Howse, W.R.; Stewart, J.E.; Conzelman, C.E.; Thibodeaux, C. Identifying Critical Manned-Unmanned Teaming Skills for Unmanned Aircraft System Operators; U.S. Army Research Institute for the Behavioral and Social Sciences: Alexandria, VA, USA, 2012; p. 68. [Google Scholar]
  11. Colombi, J.M.; Miller, M.E.; Schneider, M.; McGrogan, M.J.; Long, C.D.S.; Plaga, J. Predictive Mental Workload Modeling for Semiautonomous System Design: Implications for Systems of Systems. Syst. Eng. 2012, 15, 448–460. [Google Scholar] [CrossRef]
  12. Salim, F.A.; Ali, H.; Langen, T.; Deb, B.; Wettre, A.; Muller, G.; Falk, K. State of Affair in Terms of Big Data Utilization in Complex System Engineering Organizations: A Case Study in the Context of Norwegian Industry. Int. J. Adv. Softw. 2022, 15, 175–187. [Google Scholar]
  13. Carlile, P.R. A Pragmatic View of Knowledge and Boundaries: Boundary Objects in New Product Development. Organ. Sci. 2002, 13, 442–455. [Google Scholar] [CrossRef]
  14. Ilgen, D.R.; Hollenbeck, J.R.; Johnson, M.; Jundt, D. Teams in Organizations: From Input-Process-Output Models to IMOI Models. Annu. Rev. Psychol. 2005, 56, 517–543. [Google Scholar] [CrossRef]
  15. Muller, G. CAFCR: A Multi-View Method for Embedded Systems Architecting; Balancing Genericity and Specificity; Delft University of Technology: Eindhoven, The Netherlands, 2004; ISBN 90-5639-120-2. [Google Scholar]
  16. Stewart, S.; Giambalvo, J.; Vance, J.; Faludi, J.; Hoffenson, S. A Product Development Approach Advisor for Navigating Common Design Methods, Processes, and Environments. Designs 2020, 4, 4. [Google Scholar] [CrossRef]
  17. Godfrey, P. Building a Technical Leadership Model. INSIGHT 2024, 27, 8–15. [Google Scholar] [CrossRef]
  18. Engen, S.; Falk, K.; Muller, G. The Need for Systems Awareness to Support Early-Phase Decision-Making—A Study from the Norwegian Energy Industry. Systems 2021, 9, 47. [Google Scholar] [CrossRef]
  19. Engen, S.; Muller, G.; Falk, K. Conceptual Modeling to Support System-Level Decision-Making: An Industrial Case Study from the Norwegian Energy Domain. Syst. Eng. 2023, 26, 177–198. [Google Scholar] [CrossRef]
  20. Hutchison, N.; Hoffman, C.; Smith, G. Guide to the Systems Engineering Body of Knowledge; Stevens Institute of Technology: Hoboken, NJ, USA, 2024. [Google Scholar]
  21. Borches, P.D.J. A3 Architecture Overviews: A Tool for Effective Communication in Product Evolution; University of Twente: Enschede, The Netherlands, 2010; ISBN 978-90-365-3105-4. [Google Scholar]
  22. Bonnema, G.M. FunKey Architecting: An Integrated Approach to System Architecting Using Functions, Key Drivers and System Budgets; University of Twente: Enschede, The Netherlands, 2008; ISBN 978-90-365-2631-9. [Google Scholar]
  23. Sanders, E. Information, Inspiration and Cocreation. In Proceedings of the 6th International Conference of the European Academy of Design, Bremen, Germany, 29–31 March 2005. [Google Scholar]
  24. Sanders, E.B.-N.; Stappers, P.J. Co-Creation and the New Landscapes of Design. CoDesign 2008, 4, 5–18. [Google Scholar] [CrossRef]
  25. Kjørstad, M.; Muller, G.; Falk, K. Co-Creative Problem Solving to Support Rapid Learning of Systems Knowledge Towards High-Tech Innovations: A Longitudinal Case Study. Systems 2021, 9, 42. [Google Scholar] [CrossRef]
  26. Langen, T. A Literature Review of Conceptual Modeling for Human Systems Integration in Manned-Unmanned Systems. Syst. Eng. 2024; submitted. [Google Scholar]
  27. UAF Unified Architecture Framework. Available online: https://www.omg.org/spec/UAF (accessed on 20 October 2024).
  28. Odukoya, K.A.; Whitfield, R.I.; Hay, L.; Harrison, N.; Robb, M. An Architectural Description for The Application of Mbse in Complex Systems. In Proceedings of the 2021 IEEE International Symposium on Systems Engineering (ISSE), Vienna, Austria, 13 September–13 October 2021; pp. 1–8. [Google Scholar]
  29. Walden, D.D.; Shortell, T.M.; Roedler, G.J.; Delicado, B.A.; Mornas, O.; Yew-Seng, Y.; Endler, D. INCOSE Systems Engineering Handbook, 5th ed.; Wiley: San Diego, CA, USA, 2023; ISBN 978-1-119-81429-0. [Google Scholar]
  30. Boy, G.A.; Narkevicius, J.M. Unifying Human Centered Design and Systems Engineering for Human Systems Integration. In Complex Systems Design & Management; Aiguier, M., Boulanger, F., Krob, D., Marchal, C., Eds.; Springer International Publishing: Cham, Switzerland, 2014; pp. 151–162. [Google Scholar]
  31. Wand, Y.; Weber, R. Research Commentary: Information Systems and Conceptual Modeling—A Research Agenda. Inf. Syst. Res. 2002, 13, 363–376. [Google Scholar] [CrossRef]
  32. Karagöz, N.A.; Demirörs, O. Conceptual Modeling Notations and Techniques. In Conceptual Modeling for Discrete-Event Simulation; CRC Press: Boca Raton, FL, USA, 2010; ISBN 978-0-429-14886-6. [Google Scholar]
  33. Furian, N.; O’Sullivan, M.; Walker, C.; Vössner, S.; Neubacher, D. A Conceptual Modeling Framework for Discrete Event Simulation Using Hierarchical Control Structures. Simul. Model. Pract. Theory 2015, 56, 82–96. [Google Scholar] [CrossRef] [PubMed]
  34. Reitemeyer, B. Automatic Generation of Conceptual Enterprise Models. In Proceedings of the 2020 IEEE 24th International Enterprise Distributed Object Computing Workshop (EDOCW), Eindhoven, The Netherlands, 5–8 October 2020; pp. 74–79. [Google Scholar]
  35. Lavi, R.; Dori, Y.J.; Dori, D. Assessing Novelty and Systems Thinking in Conceptual Models of Technological Systems. IEEE Trans. Educ. 2021, 64, 155–162. [Google Scholar] [CrossRef]
  36. Zhang, L.; Zhou, L.; Horn, B.K.P. Building a Right Digital Twin with Model Engineering. J. Manuf. Syst. 2021, 59, 151–164. [Google Scholar] [CrossRef]
  37. Robinson, S.; Arbez, G.; Birta, L.G.; Tolk, A.; Wagner, G. Conceptual Modeling: Definition, Purpose and Benefits. In Proceedings of the 2015 Winter Simulation Conference (WSC), Hunigton Beach, CA, USA, 6–9 December 2015; pp. 2812–2826. [Google Scholar]
  38. McDermott, T.A. Advanced Visualization Toolset. In Evolving Toolbox for Complex Project Management; Auerbach Publications: Boca Raton, FL, USA, 2019; ISBN 978-0-429-19707-9. [Google Scholar]
  39. van der Zee, D.-J. Approaches for Simulation Model Simplification. In Proceedings of the 2017 Winter Simulation Conference (WSC), Las Vegas, NV, USA, 3–6 December 2017; pp. 4197–4208. [Google Scholar]
  40. Fujimoto, R.; Bock, C.; Chen, W.; Page, E.; Panchal, J.H. (Eds.) Research Challenges in Modeling and Simulation for Engineering Complex Systems. In Simulation Foundations, Methods and Applications; Springer International Publishing: Cham, Switzerland, 2017; ISBN 978-3-319-58543-7. [Google Scholar]
  41. Abdelmegid, M.A.; O’Sullivan, M.; González, V.A.; Walker, C.G.; Poshdar, M. A Case Study on the Use of a Conceptual Modeling Framework for Construction Simulation. Simulation 2022, 98, 433–460. [Google Scholar] [CrossRef]
  42. Langen, T.; Ali, H.B.; Falk, K. A Conceptual Framework for Data Sensemaking in Product Development—A Case Study. Technologies 2023, 11, 4. [Google Scholar] [CrossRef]
  43. Boy, G.A. Orchestrating Human-Centered Design; Springer: London, UK, 2013; ISBN 978-1-4471-4338-3. [Google Scholar]
  44. Langen, T.; Muller, G.; Falk, K. Classifying Conceptual Models Applied to Develop an Autonomous Snow-Plowing System. In International Conference on Human Systems Integration; Jeju, Republic of Korea, 2024; accepted. [Google Scholar]
  45. Perala, C.H.; Sterling, B.S. Galvanic Skin Response as a Measure of Soldier Stress; American Psychological Association: Washington, DC, USA, 2007. [Google Scholar]
  46. Giuliani, M.; Szczęśniak-Stańczyk, D.; Mirnig, N.; Stollnberger, G.; Szyszko, M.; Stańczyk, B.; Tscheligi, M. User-Centred Design and Evaluation of a Tele-Operated Echocardiography Robot. Health Technol. 2020, 10, 649–665. [Google Scholar] [CrossRef]
  47. Taylor, R.M. Situational Awareness Rating Technique (Sart): The Development of a Tool for Aircrew Systems Design. In Situational Awareness; Routledge: Abingdon, UK, 2011; ISBN 978-1-315-08792-4. [Google Scholar]
  48. Endsley, M.R. Toward a Theory of Situation Awareness in Dynamic Systems. Hum. Factors 1995, 37, 32–64. [Google Scholar] [CrossRef]
  49. Weilkiens, T.; Lamm, J.G.; Roth, S.; Walker, M. Model-Based System Architecture. In Wiley Series in Systems Engineering and Management, 2nd ed.; John Wiley & Sons, Inc.: Newark, NJ, USA, 2022; ISBN 978-1-119-74665-2. [Google Scholar]
  50. Holt, J.; Weilkiens, T. Systems Engineering Demystified, 2nd ed.; Packt Publishing: Birmingham, UK, 2023; ISBN 978-1-80461-068-8. [Google Scholar]
  51. Novak, J.D.; Cañas, A.J. The Origins of the Concept Mapping Tool and the Continuing Evolution of the Tool. Inf. Vis. 2006, 5, 175–184. [Google Scholar] [CrossRef]
  52. Alexander, I.F.; Maiden, N. Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, 1st ed.; Wiley: Chichester, UK, 2004; ISBN 978-0-470-86194-3. [Google Scholar]
  53. Lauff, C.A.; Kotys-Schwartz, D.; Rentschler, M.E. What Is a Prototype? What Are the Roles of Prototypes in Companies? J. Mech. Des. 2018, 140, 061102. [Google Scholar] [CrossRef]
  54. Ehrhart, L.S.; Sage, A.P. User-Centered Systems Engineering Framework. In Handbook of Human Systems Integration; Booher, H.R., Ed.; Wiley: Hoboken, NJ, USA, 2003; pp. 295–373. ISBN 978-0-471-02053-0. [Google Scholar]
  55. Aune, E.F.; Lind, H.; Muller, G. A Reflection on the Use of A3 Architecture Overview in Designing Wave Energy Converters. In Proceedings of the 2016 11th System of Systems Engineering Conference (SoSE), Kongsberg, Norway, 12–16 June 2016; pp. 1–6. [Google Scholar]
  56. Madni, A.M. Expanding Stakeholder Participation in Upfront System Engineering through Storytelling in Virtual Worlds. Syst. Eng. 2015, 18, 16–27. [Google Scholar] [CrossRef]
  57. Lidwell, W. Universal Principles of Design: 125 Ways to Enhance Usability, Influence Perception, Increase Appeal, Make Better Design Decisions, and Teach Through Design; Revised and Updated; Rockport Publishers: Beverly, MA, USA, 2010; ISBN 978-1-61058-065-6. [Google Scholar]
  58. Muller, G.; Falk, K.; Kjørstad, M. Systemic Innovation Toolset. In Evolving Toolbox for Complex Project Management; CRC Press: London, UK, 2020; pp. 511–532. ISBN 978-0-367-18591-6. [Google Scholar]
  59. McGowan, A.-M.R.; Bakula, C.; Castner, R.S. Lessons Learned from Applying Design Thinking in a NASA Rapid Design Study in Aeronautics. In Proceedings of the 58th AIAA/ASCE/AHS/ASC Structures, Structural Dynamics, and Materials Conference, Grapevine, TX, USA, 9–13 January 2017; American Institute of Aeronautics and Astronautics: Grapevine, TX, USA, 2017. [Google Scholar]
  60. Godfroy-Cooper, M.; Miller, J.; Bachelder, E.; Szoboslay, Z. Operator State Monitoring for Workload Prediction and Management; DEVCOM Army Research Laboratory: Adelphi, MD, USA, 2022. [Google Scholar]
  61. Madni, A.M.; Orellana, D.W. Extending Model-Based Systems Engineering to Address Human-Systems Integration Considerations in the System Life Cycle; Institute of Electrical and Electronics Engineers Inc.: New York, NY, USA, 2018; pp. 1–7. [Google Scholar]
  62. Watson, M.; Rusnock, C.; Miller, M.; Colombi, J. Informing System Design Using Human Performance Modeling. Syst. Eng. 2017, 20, 173–187. [Google Scholar] [CrossRef]
  63. Schneider, M.; McGrogan, J.; Colombi, J.M.; Miller, M.E.; Long, D.S. 7.1.1 Modeling Pilot Workload for Multi-Aircraft Control of an Unmanned Aircraft System. INCOSE Int. Symp. 2011, 21, 796–810. [Google Scholar] [CrossRef]
  64. Fang, X.; Wu, X.; Qian, Y. Design and Analyze One Object Recognition System with Human in the Loop for Unmanned Platforms with 5G Communication. In Proceedings of the 2021 6th International Conference on Intelligent Computing and Signal Processing (ICSP), Xi’an, China, 9–11 April 2021; pp. 570–575. [Google Scholar]
  65. Gorman, J.C.; Demir, M.; Cooke, N.J.; Grimm, D.A. Evaluating Sociotechnical Dynamics in a Simulated Remotely-Piloted Aircraft System: A Layered Dynamics Approach. Ergonomics 2019, 62, 629–643. [Google Scholar] [CrossRef] [PubMed]
  66. Veitch, E.; Alsos, O.A. Human-Centered Explainable Artificial Intelligence for Marine Autonomous Surface Vehicles. J. Mar. Sci. Eng. 2021, 9, 1227. [Google Scholar] [CrossRef]
  67. Muller, G.; Engen, S. System Modelling and Analysis. Available online: https://www.usn.no/english/academics/find-programmes/system-modelling-and-analysis/ (accessed on 20 October 2024).
Systems 13 00143 g001
Figure 1. Conceptual modeling framework: An Illustration of five key aspects. These aspects, labeled from (a) to (e), include conceptual models, the purpose, key drivers and qualities, multi-level abstraction, and the knowledge pyramid.
Figure 1. Conceptual modeling framework: An Illustration of five key aspects. These aspects, labeled from (a) to (e), include conceptual models, the purpose, key drivers and qualities, multi-level abstraction, and the knowledge pyramid.
Systems 13 00143 g001
Systems 13 00143 g002
Figure 2. Review of models represented in aerospace and defense case studies investigating HSI in MUM-T applications.
Figure 2. Review of models represented in aerospace and defense case studies investigating HSI in MUM-T applications.
Systems 13 00143 g002
Systems 13 00143 g003
Figure 3. Abstract–formality diagram [26]: Showing the classification of conceptual model types, divided into eight sections (A–H) according to their degree of formality (horizontal axis) and level of abstraction (vertical axis).
Figure 3. Abstract–formality diagram [26]: Showing the classification of conceptual model types, divided into eight sections (A–H) according to their degree of formality (horizontal axis) and level of abstraction (vertical axis).
Systems 13 00143 g003
Systems 13 00143 g004
Figure 4. Raw data of the survey mapping of the TOP from one participant. The colors blue, yellow, and pink represent T, O, and P, respectively. (The red circle indicates the participant’s preferred degree of abstraction and formality in their modeling practice).
Figure 4. Raw data of the survey mapping of the TOP from one participant. The colors blue, yellow, and pink represent T, O, and P, respectively. (The red circle indicates the participant’s preferred degree of abstraction and formality in their modeling practice).
Systems 13 00143 g004
Systems 13 00143 g005
Figure 5. Results from the survey indicate the number of individuals who used the various conceptual models for the CAFCR and TOP views, respectively. (For CAFCR max = 3 individuals, while for TOP max = 5 individuals).
Figure 5. Results from the survey indicate the number of individuals who used the various conceptual models for the CAFCR and TOP views, respectively. (For CAFCR max = 3 individuals, while for TOP max = 5 individuals).
Systems 13 00143 g005
Systems 13 00143 g006
Figure 6. Illustration of Storytelling and Visual ConOps from the case study observation and exploration.
Figure 6. Illustration of Storytelling and Visual ConOps from the case study observation and exploration.
Systems 13 00143 g006
Systems 13 00143 g007
Figure 7. Percentage of respondents and articles mentioning the various models (x-axis), as derived from the case company and literature review, respectively.
Figure 7. Percentage of respondents and articles mentioning the various models (x-axis), as derived from the case company and literature review, respectively.
Systems 13 00143 g007
Table 1. Description of conceptual model types.
Table 1. Description of conceptual model types.
Conceptual ModelDescription
Activity diagramAn activity diagram represents one activity with a sequence of actions, where arrows depict the relationship between action inputs and outputs. This diagram is commonly used to specify use case behavior, depicting scenarios with multiple paths [49].
Block diagramThe block definition diagram consists of blocks that contain information describing their use within a defined context. The blocks have relationships represented by lines between them and are organized in a top-down, bottom-up, or network layout [50].
Concept mapConcept maps are hierarchical structures with nodes of one or two words linked by lines, placing general concepts at the top. They facilitate knowledge creation and collaboration, enabling users to construct and exchange knowledge models [51].
Concept sketchConcept sketching is a method used to draft system and subsystem solutions, such as a screen for a user interface. These sketches tend to be used to give a glimpse into how the system might look and support requirement discovery. Early, rough sketches are particularly useful for exploring different scenarios [52].
Context diagramThe context diagram illustrates all the domain entities that influence or are influenced by the system of interest [52]. It supports system development by defining the system boundary and identifying external interfaces to technical and human systems [49].
Functional flow diagramThe functional flow diagram illustrates the system’s functions and their flow. It uses a combination of verbs and nouns to show the functional behavior of the system and its components [3].
Mock-upMock-ups involve visually representing envisioned conceptual user interfaces to support, for example, the end user’s imagination in how the new work practice will turn out to be [52].
Parametric diagramA parametric diagram is an internal block diagram that shows the parametric relationships between the system’s value properties [49]. Its function is to serve as a bridge between the visual and the formal mathematical world [50].
Physical flow diagramA physical flow diagram shows how the various physical system elements interact [50]. This is usually in the form of a block diagram, showing hardware and software elements with their interfaces [3].
PrototypeA prototype, whether physical or digital, represents elements of the final design. It is used to enhance communication and learning, supporting decision-making in the design process [53]. In this text, the focus is on the digital model aspect.
Requirement overview diagramA requirement overview diagram is a block diagram with text-based requirements notation with relationship lines between them, and it is used primarily for requirements management [50].
Sequence diagramA sequence diagram illustrates the message exchange between system elements. It is commonly used for test scenarios, example scenarios, and communication protocols between elements [49].
Stakeholder mapA stakeholder map diagram is an overview, illustrated with, for example, circular layers, that map specific stakeholder roles, such as operator and maintainer. Each layer represents a type of system [52].
State diagramA state diagram outlines discrete behavior via state transitions, illustrating an entity’s states and the transitions between them [49]. The state machine diagram is usually used for detailed low-level tasks [50].
StoryboardStoryboards illustrate specific scenarios in a design, with each frame detailing a particular moment. The storyboard presents a sequence of screens, typically using simple drawings. Storyboards are useful for exploring requirements and can be reused in future design evaluations [52,54].
StorytellingStorytelling involves identifying the story’s stakeholders and perspective, making it relatable by detailing the character’s name, age, and role, and defining the story’s scope [55]. Typically, storytelling is used to structure our knowledge about some user [52], and it may facilitate better comprehension of the system in its environmental context [56].
Swimlane diagramA swimlane diagram combines an activity diagram with column lanes, each assigned to a specific system element. It illustrates the flow of actions between elements along the columns to indicate what element does what [50].
User personaUser personas are fictional users created to guide decisions about features and interactions. They are formed from stakeholder insights like interviews, customer feedback, and usage statistics. Each persona, represented by a photo, name, description, and behaviors, is used early in the design process to define requirements [57].
Visual aidVisual Aid involves using a mix of models to tell a story. Its purpose is to align with the mental model by using images and visual representations to explain the system’s context and functions [3].
Visual ConOpsVisual ConOps, also known as illustrative ConOps, aims to capture envisioned operations and gather feedback to validate early concepts. It illustrates the placement and interface of system elements for the main operational steps. Its visual format engages stakeholders more effectively than detailed text [58].
QuantificationThe quantification view involves numerical data of key parameters, such as measurements, expert estimations, and educated guesses. The purpose of quantification views is to represent data and information in relationship to other views to support them [3].
Table 2. Interviewees’ work experience in the company and in total.
Table 2. Interviewees’ work experience in the company and in total.
Years of ExperienceIn the CompanyIn Total
1–92 participants1 participant
10–194 participants3 participants
20–401 participant3 participants
Average all participants11 years23 years
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Langen, T.; Falk, K.; Muller, G. Conceptual Modeling for Understanding and Communicating Complexity During Human Systems Integration in Manned–Unmanned Systems: A Case Study. Systems 2025, 13, 143. https://doi.org/10.3390/systems13030143

AMA Style

Langen T, Falk K, Muller G. Conceptual Modeling for Understanding and Communicating Complexity During Human Systems Integration in Manned–Unmanned Systems: A Case Study. Systems. 2025; 13(3):143. https://doi.org/10.3390/systems13030143

Chicago/Turabian Style

Langen, Tommy, Kristin Falk, and Gerrit Muller. 2025. "Conceptual Modeling for Understanding and Communicating Complexity During Human Systems Integration in Manned–Unmanned Systems: A Case Study" Systems 13, no. 3: 143. https://doi.org/10.3390/systems13030143

APA Style

Langen, T., Falk, K., & Muller, G. (2025). Conceptual Modeling for Understanding and Communicating Complexity During Human Systems Integration in Manned–Unmanned Systems: A Case Study. Systems, 13(3), 143. https://doi.org/10.3390/systems13030143

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop