Systematic Literature Review of System Models for Technical System Development

Abstract

In Model-Based Systems Engineering (MBSE) there is yet no converged terminology. The term ‘system model’ is used in different contexts in literature. In this study we elaborated the definitions and usages of the term ‘system model’, to find a common definition. We analyzed 104 publications in depth for their usage and definition as well as their meta-data e.g., the publication year and publication background to find some common patterns. While the term is gaining more interest in recent years, it is used in a broad range of contexts for both analytical and synthetic use cases. Based on this, three categories of system models have been defined and integrated into a more precise definition.

1. Introduction

While the research and industrial interest in Model-Based Systems Engineering (MBSE) is very high—as this special issue of Multidisciplinary Digital Publishing Institute (MDPI) shows—there is yet no common terminology for this topic. Huldt and Stenius [1] mentioned that ‘the definition of MBSE is not yet internationally converged and standardized. As a consequence, the definition of MBSE is rather vague and open to a broad range of interpretations of the concept’. Even though the model of a system is seen as the main artifact in MBSE [2], there is also yet no common definition for the term ‘system model’, which the model is often referred to. In 2015, Hart [3] mentioned, that a system model is ‘[…] a structured representation that focuses on the overall system requirements, behavior, structure, properties and interconnections’. This definition is as vague as the MBSE definition mentioned by Huldt and Stenius [1]. Despite the vagueness of the existing definitions, the concept of systems modeling increases in popularity across various industries. This also means multiple definitions and concepts, which are difficult to compare. From an industry perspective, this means information and results are difficult to exchange between different systems modeling eco-systems both internally and externally. The widespread, but fragmented understanding poses a challenge for research and academia, since there is no universal understanding or grand theory of systems modeling which could function as a base from which to extend on existing knowledge. Therefore, on one hand, it is important to understand how different organizations in different industries apply the concepts they define as systems modeling to meet their individual needs in order to then identify recurring schemes and similarities. On the other hand, inconsistencies and contradictions help to identify gaps and areas of improvement to derive future solutions that are needed to advance systems development through the use of system models.

In order to evaluate those points in particular, as well as the current state of system model application and development for engineering systems across various industries in general, the following research questions have been addressed in this study:

• How is the term ‘system model’ used in MBSE and further domains?
• Who uses ‘system models’ besides Systems Engineers?
• Is it possible to have more than one ‘system model’ per system?

The following hypotheses are connected to these research questions:

• There is yet no converged overall definition of the term ‘system model’.
• A ‘system model’ can be created in different ways and is not limited to the application of Systems Modeling Language (SysML).
• The usage of a ‘system model’ is not limited to the domain of System Engineers.

This paper is structured as follows. In Section 2, the method used for the systematic literature review is introduced. This includes, for example, the search strategy, the eligibility criteria and information sources. The results of this systematic literature review are listed in Section 3. Screened studies are presented and discussed in the context of biases. Eventually, the findings of the synthesis of these studies are discussed in Section 4. This includes limitations, e.g., based on the bias, as well as an overall conclusion regarding the hypotheses listed above.

2. Materials and Methods

The systematic literature review has been carried out without a systemic review protocol.

The study focused on international definition and thus on titles in English. Due to the native language of the authors being German, literature written in German has been declared as eligible as well with the term ‘Systemmodell’ being equivalent to the English term ‘system model’. To get a full overview of any possible definition of the term ‘system model’ the year of publication has not been limited in any form. The eligibility has mainly been based on the reference to engineered systems and a possible correlation to MBSE.

The scanning period is dated from 18 July 2020 to 31 July 2020. Information sources included the databases Scopus by Elsevier (www.scopus.com (accessed on 21 July 2020)), Web of Science by Clarivate (apps.webofknowledge.com (accessed on 28 July 2020)), SAGE Journals by SAGE Publications (journals.sagepub.com (accessed on 22 July 2020)), IEEExplore of the Institute of Electrical and Electronics Engineers (IEEE) (ieeexplore.ieee.org (accessed on 24 July 2020)) and arXiv.org made available by the Cornell University (arxiv.org (accessed on 31 July 2020)). As of 18 November, Scoupus includes 41,462 journals, proceedings, books and trade publications (https://www.scopus.com/sources.uri (accessed on 18 November 2020)) from 1960–2020. Web of Science covers 21,419 books, proceedings and journals from 1900–2020 (https://clarivate.libguides.com/webofscienceplatform/coverage (accessed on 18 November 2020)). IEEExplore includes 5,329,188 articles from journals, conferences, early access publications, standards, magazines, courses and books. The date coverage goes from 1872–2021. Sage Journals dates back from 1847–2021 and accesses 1211 journals. arXiv.org covers 1795706 open-access articles explicitly submitted to arXiv.org with a date coverage of 1991–2020.

Table 1. Overview of information sources.

Source Name	Date Coverage	Last Searched	Comments on Included Data
Scopus	1960–2020	21 July 2020	41,462 journals, proceedings, trade publications and books
Web of Science	1970–2020	28 July 2020	21,419 books, proceedings and journals
Sage Journals	1847–2020	22 July 2020	1211 journals
IEEExplore	1872–2021	24 July 2020	5,329,188 articles from journals, conferenes, early access publications, standards, magazines, courses and books
arXiv.org	1991–2020	31 July 2020	1,795,706 open-access articles (only explicitly submitted to arXiv.org)

summarizes this information and gives an overview of the content of the database.

No additional sources have been used.

As the search for the term ‘system model’ would bring too many results regarding different kinds of non-technical systems and models in various contents, the keywords have been refined. The following keywords have been used:

• federated system model
• system model creation
• system model development
• system model usage
• system model fidelity
• system model complexity
• system model uncertainty
• multi-model networks
• model hierarchy
• system model perspectives
• system model visualization
• system model characteristics
• transdisciplinary system model
• interdisciplinary system model
• system model + MBSE
• system of systems model

The search for these keyword-searches has been carried out as demonstrated in the following for the Scopus database:

• The advanced search of the database has been located and the keywords were entered for searching the title, abstract and keywords, if available. The keyword combination has been combined with logical ‘AND’ to limit the results. Range of year, language and authors have not been limited. If the keyword combination raised too many results, i.e., exceeded 1000 results, the keywords have been combined with quotation marks. An exemplary search string for Scopus is TITLE-ABS-KEY (“system model” AND development). All keyword combinations are attached in the Appendix A as

  Table A1. Used keywords—Scopus.

  Database	Keyword	Count	Search String
  Scop-1	federated system model	45	TITLE-ABS-KEY (federated AND “system model”)
  Scop-2	system model creation	499	TITLE-ABS-KEY (“system model” AND creation)
  Scop-3	system model development	130	TITLE-ABS-KEY (“system model development”)
  Scop-4	system model usage	642	TITLE-ABS-KEY (“system model” AND usage)
  Scop-5	system model fidelity	458	TITLE-ABS-KEY (“system model” AND fidelity)
  Scop-6	system model complexity	14	TITLE-ABS-KEY (“system model complexity”)
  Scop-7	system model uncertainty	114	TITLE-ABS-KEY (“system model uncertainty”)
  Scop-8	multi-model networks	7	TITLE-ABS-KEY (“multi-model network”)
  Scop-9	model hierarchy	411	TITLE-ABS-KEY (“model hierarchy”)
  Scop-10	system model perspectives	19	TITLE-ABS-KEY (“system model perspective”)
  Scop-11	system model visualization	469	TITLE-ABS-KEY (“system model” AND visualization)
  Scop-12	system model characteristics	8	TITLE-ABS-KEY (“system model characteristic”)
  Scop-13	transdisciplinary system model	21	TITLE-ABS-KEY (transdisciplinary AND “system model”)
  Scop-14	interdisciplinary system model	242	TITLE-ABS-KEY (interdisciplinary AND “system model”)
  Scop-15	system model + MBSE	155	TITLE-ABS-KEY (“system model” AND mbse)
  Scop-16	system of systems model	52	TITLE-ABS-KEY (“system of systems model”)

  ,

  Table A2. Used keywords—Web Of Science.

  Database	Keyword	Count	Search String
  WebO-1	federated system model	21	ALL = (federated AND “system model”)
  WebO-2	system model creation	193	ALL = (“system model” AND creation)
  WebO-3	system model development	74	ALL = (“system model development”)
  WebO-4	system model usage	278	ALL = (“system model” AND usage)
  WebO-5	system model fidelity	205	ALL = (“system model” AND fidelity)
  WebO-6	system model complexity	10	ALL = (“system model complexity”)
  WebO-7	system model uncertainty	25	ALL = (“system model uncertainty”)
  WebO-8	multi-model networks	679	ALL = (“multi-model” AND network)
  WebO-9	model hierarchy	217	ALL = (“model hierarchy”)
  WebO-10	system model perspectives	604	ALL = (“system model” AND “perspective”)
  WebO-11	system model visualization	170	ALL = (“system model” AND “visualization”)
  WebO-12	system model characteristics	671	ALL = (“system model” AND “characteristic”)
  WebO-13	transdisciplinary system model	17	ALL = (“transdisciplinary” AND “system model”)
  WebO-14	interdisciplinary system model	228	ALL = (“interdisciplinary” AND “system model”)
  WebO-15	system model + MBSE	87	ALL = (“system model” AND (“MBSE” OR “Modelbased Systems Engineering” OR “Model-Based Systems Engineering” OR “Model Based Systems Engineering”))
  WebO-16	system of systems model	339	ALL = (“system-of-systems model” OR “system of systems model” OR “systems of systems models” OR “sytems-of-systems model” OR “SoS model”)

  ,

  Table A3. Used keywords—Sage.

  Database	Keyword	Count	Search String
  Sage-1	federated system model	22	[Abstract “system model”] AND [Abstract federated]
  Sage-2	system model creation	35	[Abstract “system model”] AND [Abstract creation]
  Sage-3	system model development	210	[Abstract “system model”] AND [Abstract development]
  Sage-4	system model usage	347	[Abstract “system model”] AND [Abstract usage]
  Sage-5	system model fidelity	4	[Abstract “system model”] AND [Abstract fidelity]
  Sage-6	system model complexity	75	[Abstract “system model”] AND [Abstract complexity]
  Sage-7	system model uncertainty	47	[Abstract “system model”] AND [Abstract uncertainty]
  Sage-8	multi-model networks	4	[Abstract “multi-model”] AND [Abstract network]
  Sage-9	model hierarchy	3	[Abstract “model hierarchy”]
  Sage-10	system model perspectives	14	[Abstract “system model”] AND [Abstract perspective]
  Sage-11	system model visualization	2	[Abstract “system model”] AND [Abstract visualization]
  Sage-12	system model characteristics	93	[Abstract “system model”] AND [Abstract characteristic]
  Sage-13	transdisciplinary system model	0	[Abstract “system model”] AND [Abstract transdisciplinary]
  Sage-14	interdisciplinary system model	2	[Abstract “system model”] AND [Abstract interdisciplinary]
  Sage-15	system model + MBSE	0	[Abstract “system model”] AND [MBSE]
  Sage-16	system of systems model	0	[Abstract “system of systems model”]

  ,

  Table A4. Used keywords—IEEExplore.

  Database	Keyword	Count	Search String
  IEEE-1	federated system model	19	(“All Metadata”: federated AND “system model”)
  IEEE-2	system model creation	88	(“All Metadata”: “system model” AND creation)
  IEEE-3	system model development	23	(“All Metadata”: “system model development”)
  IEEE-4	system model usage	184	(“All Metadata”: “system model” AND usage)
  IEEE-5	system model fidelity	89	(“All Metadata”: “system model” AND fidelity)
  IEEE-6	system model complexity	14	(“All Metadata”: “system model complexity”)
  IEEE-7	system model uncertainty	46	(“All Metadata”: “system model uncertainty”)
  IEEE-8	multi-model networks	264	(“All Metadata”: “multi-model” AND network)
  IEEE-9	model hierarchy	69	(“All Metadata”: “model hierarchy”)
  IEEE-10	system model perspectives	203	(“All Metadata”: “system model” AND perspective)
  IEEE-11	system model visualization	169	(“All Metadata”: “system model” AND visualization)
  IEEE-12	system model characteristics	1	(“All Metadata”: “system model characteristic”)
  IEEE-13	transdisciplinary system model	3	(“All Metadata”: transdisciplinary AND “system model”)
  IEEE-14	interdisciplinary system model	38	(“All Metadata”: interdisciplinary AND “system model”)
  IEEE-15	system model + MBSE	52	(“All Metadata”: “system model” AND MBSE)
  IEEE-16	system of systems model	49	“All Metadata”: “system-of-systems model” OR “system of systems model” OR “systems of systems models” OR “sytems-of-systems model” OR “SoS model”)

  and

  Table A5. Used keywords—arXive.org.

  Database	Keyword	Count	Search String
  arXi-1	federated system model	7	all:federated + AND + all:%22system + model%22
  arXi-2	system model creation	9	all:creation + AND + all:%22system + model%22
  arXi-3	system model development	448	all:development + AND + all:%22system + model%22
  arXi-4	system model usage	14	all:usage + AND + all:%22system + model%22
  arXi-5	system model fidelity	17	all:fidelity + AND + all:%22system + model%22
  arXi-6	system model complexity	356	all:complexity + AND + all:%22system + model%22
  arXi-7	system model uncertainty	128	all:uncertainty + AND + all:%22system + model%22
  arXi-8	multi-model networks	41	all:network + AND + all:%22multi + model%22
  arXi-9	model hierarchy	33	all:%22model + hierarchy%22
  arXi-10	system model perspectives	49	all:perspective + AND + all:%22system + model%22
  arXi-11	system model visualization	36	all:visualization + AND + all:%22system + model%22
  arXi-12	system model characteristics	116	all:characteristics + AND + all:%22system + model%22
  arXi-13	transdisciplinary system model	0	all:transdisciplinary + AND + all:%22system + model%22
  arXi-14	interdisciplinary system model	2	all:interdisciplinary + AND + all:%22system + model%22
  arXi-15	system model + MBSE	0	all:MBSE + AND + all:%22system + model%22
  arXi-16	system of systems model	3	all:%22system-of-systems + model%22 + OR + all:%22system+ of+systems+model%22

  .
• All titles have been exported as *.csv (or if a *.csv has not been available as *.bib) files. If the total number of entries exceeded the limit for export, it has been split into partial exports and was combined locally. For arXiv.org a script for the Application Programming Interface (API) has been written to export the information into a *.csv file, which is shown in Appendix B.
• The *.csv files containing all results for a search string have been combined to an overall data table. To allow easier filtering, the *.csv-files have been imported into Microsoft Excel and analyzed as *.xlsx file.

The following methodology was based on the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) workflow [4]. It is depicted in the following Figure 1.

The table produced in the final step of the identification process with the keyword search has been screened for duplicates. This included identical titles, titles with different capitalization of the words and abbreviated titles with identical listed authors and year. The rest of the titles has been screened for eligibility. As the defined criteria did not exclude any year or, this step mainly focused on selecting titles in English or German and excluding most non-engineered systems. In the following, the same procedure has been applied to the selected publications abstracts and associated full-texts in the final screening step. The screening for eligibility has been performed by two reviewers. Ambiguities and disagreements between them were resolved by consensus. The number of publications that remained have been included in the study.

The data has been manually extracted by copying and summarizing the relevant information of each publication into comments in the PDF and transferring these comments into a tabulated data-set. The extracted items have been discussed by the two review authors and whenever a disagreement was reached, a third reviewer was contacted. This study focused on the definition and usage in literature, none of the authors have been contacted for further details, as this might lead to biases in the analysis.

As this literature review here does not focus on quantitative values that have been analyzed in other studies the process of extraction of data was about identifying the meaning for the topics of interest. These topics focused on three variables:

• Domain/origin/background of the systems under consideration,
• Definition or meaning of the term ‘system model’ and
• Usage of the ‘system model’.

While the different domains represented in the publications could raise some bias in another context it was used here as the first variable under consideration. Further risk of bias has been assessed by two authors collecting the data of the studies independently. Principle measures have been the quantities of specific origins, definitions, creation approaches and usage description for ‘system models’ (defined variables listed above). The analysis of the studies was performed by clustering the data-set with respect to the definition of the term ‘system model’.These clusters have been investigated for specific domains for the system under consideration as well as their stated creation and usage methods. Additionally, the authors and years of publication have been analyzed to asses the risk of bias across studies.

3. Results

In this section, the literature body as a result of the PRISMA workflow from Figure 1 is first described and then the analysis of its content is presented.

3.1. Selected Studies for Literature Body

The following Figure 2 shows the number of results which pertained each step of the methodological approach of Figure 1.

As result of the database search described in Section 2 10,514 records have been extracted. After screening for duplicates, the 6586 left titles have been screened for eligibility depending on the eligibility criteria (engineered systems as target systems and a possible correlation to MBSE) mentioned in Section 2. With this procedure, 6103 titles have been excluded as they were not fitting within the topic of interest. This was primarily achieved by investigating the titles for fitting into the topic of model-based technical system development. The rest of 483 publications have been investigated in their abstracts and after excluding 303 mainly due to different scopes (e.g., full software systems in scope or no existing full-texts to be found for the publication) the rest of the 180 publications was read in more detail with the same criteria. While reading the publications in more detail, it turned out, that 76 of them were still out of scope and thus, 104 publications have been included in this study and are listed in the following

Table 2. Literature overview of eligible publications.

Reference	Year	Type	Domain	Category	Multitude	Usage
Capehart [5]	1977	Journal Article	Production Systems	theoretical concept	single	analytics
Joshi et al. [6]	1995	Journal Article	Production Systems	theoretical concept	multiple	synthesis
Ironmonger et al. [7]	1996	Conference Paper	Energy	prototype	single	analytics
Bluff [8]	1999	Conference Paper	Air and land vehicle	theoretical concept	multiple	synthesis
Bluff [9]	1999	Journal Article	Air and land vehicle	theoretical concept	multiple	synthesis
Estanbouli et al. [10]	2004	Conference Paper	Other	theoretical concept	single	analytics
Hicks et al. [11]	2004	Journal Article	Other	theoretical concept	single	synthesis
Wilson et al. [12]	2007	Journal Article	Defense	theoretical concept	single	analytics
Che and Jennings [13]	2007	Conference Paper	Air and land vehicle	theoretical concept	multiple	synthesis
Ma et al. [14]	2008	Conference Paper	Energy	theoretical concept	single	analytics
Curry et al. [15]	2008	Journal Article	Other	theoretical concept	single	analytics
Sturm [16]	2008	Conference Paper	Defense	theoretical concept	single	synthesis
Wakefield and Miller [17]	2008	Conference Paper	Air and land vehicle	theoretical concept	multiple	analytics
Amrhein et al. [18]	2008	Journal Article	Air and land vehicle	theoretical concept	both	analytics
Hoang et al. [19]	2008	Conference Paper	Space Technology	…	multiple	analytics
Hummel and Braun [20]	2008	Conference Paper	not specified	theoretical concept	multiple	analytics
[21]	2009	Conference Paper	Air and land vehicle	theoretical concept	multiple	analytics
Qamar et al. [22]	2009	Conference Paper	not specified	theoretical concept	multiple	analytics
Li and Xiong [23]	2010	Conference Paper	Air and land vehicle	theoretical concept	multiple	analytics
Dickerson and Valerdi [24]	2010	Conference Paper	Defense	prototype	multiple	synthesis
Borutzky [25]	2010	Monography	not specified	theoretical concept	single	synthesis
Follmer et al. [26]	2010	Conference Paper	not specified	theoretical concept	multiple	analytics
Stetter et al. [27]	2011	Conference Paper	not specified	theoretical concept	multiple	synthesis
Kleins et al. [28]	2011	Conference Paper	not specified	prototype	multiple	synthesis
Witsch and Vogel-Heuser [29]	2011	Conference Paper	Production system	theoretical concept	multiple	synthesis
Schütz and Vogel-Heuser [30]	2011	Other	Production system	theoretical concept	single	synthesis
Piaszczyk [31]	2011	Other	Defense	theoretical concept	multiple	analytics
Guan et al. [32]	2012	Journal Article	Air and land vehicle	theoretical concept	multiple	analytics
Strahilov et al. [33]	2012	Conference Paper	Production systems	theoretical concept	multiple	analytics
Magalhaes et al. [34]	2012	Journal Article	Energy	theoretical concept	multiple	synthesis
Hoffmann [35]	2012	Conference Paper	Other	theoretical concept	multiple	synthesis
Ahn et al. [36]	2012	Conference Paper	Other	prototype	single	analytics
Chandraiah and Dömer [37]	2012	Journal Article	Other	theoretical concept	single	synthesis
Kim et al. [38]	2012	Conference Paper	Air and land vehicle	theoretical concept	multiple	analytics
Schmelcher et al. [39]	2012	Conference Paper	Air and land vehicle	theoretical concept	multiple	synthesis
Reichwein et al. [40]	2012	Conference Paper	not specified	theoretical concept	multiple	synthesis
Follmer et al. [41]	2012	Conference Paper	not specified	theoretical concept	single	synthesis
Ramos et al. [42]	2012	Conference Paper	Other	theoretical concept	multiple	synthesis
Becherini et al. [43]	2012	Conference Paper	Space Technology	theoretical concept	single	analytics
Glas and Sartorius [44]	2012	Conference Paper	Air and land vehicle	theoretical concept	multiple	analytics
Wang and Wang [45]	2013	Journal Article	Energy	theoretical concept	single	analytics
Ma et al. [46]	2013	Journal Article	Other	theoretical concept	single	analytics
Zander [47]	2013	Conference Paper	Other	prototype	single	analytics
Haveman and Bonnema [48]	2013	Conference Paper	Air and land vehicle	theoretical concept	multiple	synthesis
Nattermann and Anderl [49]	2013	Conference Paper	Air and land vehicle	prototype	multiple	synthesis
Sharon et al. [50]	2013	Journal Article	not specified	theoretical concept	single	synthesis
Gausemeier et al. [51]	2013	Journal Article	not specified	theoretical concept	multiple	synthesis
Broy [52]	2014	Conference Paper	not specified	theoretical concept	single	analytics
Barbieri et al. [53]	2014	Conference Paper	Production system	prototype	multiple	synthesis
Zierolf et al. [54]	2014	Conference Paper	Air and land vehicle	theoretical concept	multiple	analytics
Komoto et al. [55]	2014	Conference Paper	not specified	theoretical concept	multiple	synthesis
Micouin [56]	2014	Journal Article	Air and land vehicle	theoretical concept	multiple	analytics
Song et al. [57]	2014	Conference Paper	Other	theoretical concept	single	multiple
Pfluegl et al. [58]	2015	Monography	Air and land vehicle	prototype	multiple	analytics
Acker et al. [59]	2015	Conference Paper	Other	theoretical concept	multiple	analytics
Aboutaleb and Monsuez [60]	2015	Journal Article	Other	theoretical concept	single	synthesis
Morkevicius and Jankevicius [61]	2015	Conference Paper	Air and land vehicle	theoretical concept	multiple	analytics
Tschirner et al. [62]	2015	Conference Paper	not specified	theoretical concept	multiple	analytics
Kaslow [63]	2015	Conference Paper	Space Technology	theoretical concept	multiple	analytics
Kaslow et al. [64]	2015	Conference Paper	Space Technology	theoretical concept	multiple	synthesis
Holtmann et al. [65]	2015	Conference Paper	Air and land vehicle	theoretical concept	multiple	synthesis
Dumitrescu et al. [66]	2015	Other	not specified	theoretical concept	multiple	synthesis
Iwata et al. [67]	2015	Conference Paper	Space Technology	theoretical concept	single	analytics
Hampson [68]	2015	Journal Article	not specified	theoretical concept	multiple	analytics
Aboutaleb and Monsuez [69]	2015	Conference Paper	not specified	theoretical concept	multiple	synthesis
Cheng and Zhou [70]	2016	Conference Paper	Energy	theoretical concept	multiple	analytics
Johnson et al. [71]	2016	Journal Article	Other	theoretical concept	multiple	analytics
Kulkarni et al. [72]	2016	Conference Paper	Space Technology	prototype	multiple	analytics
Sindiy et al. [73]	2016	Conference Paper	Space Technology	existing business	multiple	synthesis
Brecher et al. [74]	2016	Conference Paper	Production systems	theoretical concept	multiple	synthesis
Vannesjo et al. [75]	2016	Journal Article	Other	theoretical concept	single	synthesis
Henke et al. [76]	2016	Conference Paper	Production system	prototype	multiple	synthesis
Pleshkova and Zahariev [77]	2017	Conference Paper	Other	prototype	multiple	synthesis
Wu et al. [78]	2018	Conference Paper	Energy	theoretical concept	single	analytics
Qu et al. [79]	2017	Conference Paper	Defense	…	multiple	analytics
Kaslow et al. [80]	2017	Conference Paper	Space Technology	theoretical concept	multiple	synthesis
Watson et al. [81]	2017	Journal Article	Defense	theoretical concept	multiple	synthesis
Fischer et al. [82]	2017	Journal Article	Space Technology	prototype	multiple	synthesis
Rambikur et al. [83]	2017	Conference Paper	Other	theoretical concept	multiple	analytics
Friedl et al. [84]	2017	Conference Paper	Production system	theoretical concept	multiple	synthesis
Kößler and Paetzold [85]	2017	Conference Paper	not specified	theoretical concept	multiple	analytics
Hanson et al. [86]	2017	Conference Paper	Other	theoretical concept	multiple	synthesis
Parrott and Weiland [87]	2017	Conference Paper	Space Technology	theoretical concept	multiple	analytics
Anyanhun and Edmonson [88]	2018	Conference Paper	Space Technology	theoretical concept	single	synthesis
Wang et al. [89]	2018	Journal Article	not specified	theoretical concept	multiple	synthesis
Fischer et al. [90]	2018	Conference Paper	Space Technology	existing business	multiple	synthesis
Kübler et al. [91]	2018	Conference Paper	Production system	theoretical concept	single	synthesis
Madni and Sievers [2]	2018	Journal Article	not specified	theoretical concept	multiple	synthesis
Bossa et al. [92]	2018	Conference Paper	Air and land vehicle	prototype	single	analytics
Papakonstantinou et al. [93]	2019	Conference Paper	Energy	theoretical concept	multiple	analytics
Gaskell and Harrison [94]	2019	Conference Paper	Defense	theoretical concept	multiple	analytics
Wang et al. [95]	2019	Conference Paper	Production system	theoretical concept	multiple	analytics
Duncan and Etienne-Cummings [96]	2019	Journal Article	Other	theoretical concept	multiple	analytics
Kunnen et al. [97]	2019	Conference Paper	Not specified	theoretical concept	multiple	synthesis
Buldakova [98]	2019	Conference Paper	not specified	theoretical concept	multiple	synthesis
Stevens [99]	2019	Conference Paper	Space Technology	theoretical concept	multiple	synthesis
Konrad et al. [100]	2019	Conference Paper	Other	theoretical concept	multiple	analytics
Baklouti et al. [101]	2019	Journal Article	Air and land vehicle	theoretical concept	multiple	analytics
Bagdatli et al. [102]	2019	Conference Paper	Air and land vehicle	theoretical concept	multiple	synthesis
Gao et al. [103]	2019	Conference Paper	Defense	theoretical concept	multiple	analytics
Kamburjan and Stromberg [104]	2019	Conference Paper	not specified	theoretical concept	single	analytics
Duhil et al. [105]	2020	Conference Paper	Defense	theoretical concept	single	analytics
Zimmermann et al. [106]	2020	Other	not specified	theoretical concept	multiple	analytics
Mei et al. [107]	2020	Journal Article	Production System	prototype	multiple	analytics

. This table lists the publications in chronological order (focusing on the year and not the month of publication) with their reference, year of publication, type of publication, the domain of the target system under consideration in the publication, the category of work behind the publication, whether the system model is a single model or consists of multiple models and whether the model is used for analytics or synthesis of the target system. The different columns of the table will be investigated in the following subsections.

3.2. Description of the Literature Body

In the following subsections the literature body will be described and characterized in terms of scientific sources, types of use cases and industry context in order to classify and subsequently discuss the results. It shall be mentioned that all mentions of ‘raw search results’ focus on the results after the duplicate removal.

Figure 3 displays the distribution over publication types.

The body of literature consists primarily of conference papers and articles published in peer-review journals not associated with a conference. Combined, those make up 94% percent of the selected samples, with monographs only accounting for 2% of the literature body. ‘Other’ in Figure 3 represents articles published without going through a peer-review process.

The chronological distribution of the 104 publications included is shown in Figure 4.

The earliest sample was published in 1977 as could be seen in Table 2. Despite the earliest sample being published in 1977, only about 12% of the raw search results were published before the year 2000, with only 5% of the publication in the literature body analyzed in-depth dating from before 2000.

Comparing the initial raw search results after duplicate removal with the body of literature analyzed in depth there is a considerable selection bias towards publications sources published 2011 or later.

Figure 5 displays this publication bias.

The largest amount of samples qualified for inclusion into the literature body dates from 2011 through 2015, despite this only being the second-largest bracket in terms of raw search results. At about 41% compared to a little under 38% this is of no significance given the sample size of n = 104. What is more indicative of a shift towards the usage of the term ‘system model’ in the last decade is that, if combined, close to 80% of the publications included in the literature body were published in 2011 or later. This is largely driven by the fact that a significant amount of results before 2011 makes use of similar verbiage and concepts of systems theory but applies those concepts to natural systems, social systems, entirely mathematical problems or computer science topics. (Of those, a good amount offers great inspiration for novel systems engineering approaches and certainly deserves more attention from the engineering community, but do not qualify in the context of reviewing the definition and usage of systems models in systems engineering or for engineered systems in general.) We suspect this being overall related to advances in IT-infrastructure and tools available and in particular the increasing computing capabilities that allow for more intensive use of tracing between artifacts and data used as part of systems development and of simulation as part of system development and operation.

The domain of the target systems have been clustered in seven (7) categories: Space Technology, Production Systems, Air and Land Vehicle, Energy, Defense, Other and ‘Not Specified’. The latter has been used when the solution was described as universally applicable or if a specific domain or target system could not be identified (e.g., if the aim of the publication was on the methodological approach). In context of the domain, ‘Other’ comprises diverse areas, such as communication, forestry, mechanical, embedded systems, control systems, complex System of Systems (SoS), building, Cyber-Physical System (CPS), computer engineering, robotics, biomedical and business process. The following Figure 6 depicts the distribution of these domains over the literature body.

With many publications of Systems Engineering (SE) focusing on Space and Aerospace, Space Technology and Air and Land Vehicle combined make up 33% of all samples. Production systems (12%), Energy (7%) and Defense (9%) combined make up less than 30% of the literature body. While the summed up other systems have an impact as well (18%) the 22% of the not specified system show the use case-independent relevance of this topic.

For a breakdown of the use cases according to their maturity in the business model, we have divided them into the categories: Existing business, prototype, and theoretical concept. The latter refers to theoretical concepts based on existing business models that have not yet been implemented. Figure 7 displays their distribution.

The largest part (85%) of the literature body fall into the category “Theoretical Concept” and only 2% of the included publications cover the category “existing business” beyond mentioning currently applied methods and tools to the proposed new approaches to systems development. Overall, it is very noticeable that an overwhelming majority of 98% of samples fall into the categories “Theoretical Concept” or “Prototype”. This may be explained by the fact that holistic system modeling is often either not applied to established system development processes or simply just not recognized as such, driven by the fact that organizations often develop system modeling capabilities over time and through a need-based bottom-up approach.

One question we tried to answer when we set out to review literature pertaining the definition and use of system models was whether there is a consensus if there can be more than one system model per system.

Most of the publications (72%) refer to system models as a conglomerate of multiple models. In some cases (28%) the term ‘system model’ is used for a specific type of model that can be used without further dependencies or related models.

The definition and purpose of the system model have been extracted from each publication as well. Due to readability, the table has been added to the Appendix A (

Table A6. Purpose and definition of system models extracted from eligible literature.

Reference	Definition	Purpose
Capehart [5]	system of differential equations	create continuous computer simulation
Joshi et al. [6]	state graphs connecting models	connection with physical models
Ironmonger et al. [7]	Object-Oriented database management system	controlling
Bluff [8]	link between behavior model and performance model, should aim to provide architecture optimization	Analyze hardware and software components and their interaction, early understanding of system behavior in operation
Bluff [9]	link between behavior model and performance model, should aim to provide architecture optimization	Analyze hardware and software components and their interaction, early understanding of system behavior in operation
Estanbouli et al. [10]	mathematical model (equations)	analysis, easier form of FEA
Hicks et al. [11]	system architecture that is progressively fed with details until a network of mathematical components is achieved	developing architectures comprised of standard components
Wilson et al. [12]	captures logic of knowledge in a graphical (BN) and mathematical model	provides a big picture of the system’s functionality that can form the basis for a statistical analysis
Che and Jennings [13]	any kind of system, subsystem or component with behavior representation that can be shared with other developers and connected with their respective models	integrated system representation from requirement through behavioral component models
Ma et al. [14]	block model	system operation and optimization
Curry et al. [15]	graphical and mathematical model (parameter model network, linear programming model)	quantify system capacity, getting alternatives
Sturm [16]	UML model	provide multiple views on the system
Wakefield and Miller [17]	center of development process, simulation model of a process	design of complex algorithms combined with hardware, system simulation
Amrhein et al. [18]	combination of subsystem models (DHS) or single models	integrated system simulation and behavior prediction
Hoang et al. [19]	simulation models of integrated system	mitigate system risk, system test
Hummel and Braun [20]	integrated model based on multiple behavior models defining components and ports	quickly derive domain specific simulation scenarios
[21]	simulation model on component level	diagnostics and health management, failure mode analysis
Qamar et al. [22]	models defined with system modeling languages (here SysML)	investigate design alternatives, check quality of design, resolving complexity by transformation of information, simulation (in combination with other tools, e.g., Matlab)
Li and Xiong [23]	connected models of application and behavior	understanding of possible operation—design space exploration
Dickerson and Valerdi [24]	basic attributes of the system, graphical model	tracing and model transformation to SoS
Borutzky [25]	an interconnection of system components, an aggregation of data and methods operating on them	single source of truth and used for simulation
Follmer et al. [26]	domain-neutral models to bridge different engineering domains, provide a holistic system view and simulate overall system behavior	describe complex system in holistic way
Stetter et al. [27]	model, holding cross domain information about the system and important relations; holds different types of knowledge	application of agent systems
Kleins et al. [28]	UML diagrams	build modeling tools and DSL for running simulations
Witsch and Vogel-Heuser [29]	graphical modeling notation based on BPMN, model of the technical system, describes components of that system, static model	provide data for MES
Schütz and Vogel-Heuser [30]	control of agents in agent based system	manually integrate model information
Piaszczyk [31]	graphically described model (IDEF or SysML or similar)	very early validation in cooperation with stakeholders, generally front-loading
Guan et al. [32]	mathematically formalized model, does not rely on structural architecture of the system	used for hybrid simulation (virtual/real) validation
Strahilov et al. [33]	geometry, multi body system model	validation
Magalhaes et al. [34]	tool for understanding and predicting the performance of the trigeneration system as well as sizing it	predict system performance, simulation
Hoffmann [35]	SysML models, relevant for systems engineering (architecture etc,), mainly executable, only mentions subsystem models	trade studies
Ahn et al. [36]	mathematical equations, transform function	Analysis of system (e.g., damping) and design of system
Chandraiah and Dömer [37]	executable specification of the design on system level	(automated) system exploration and synthesis
Kim et al. [38]	generated with graphical modeling (here SysML), descriptive, not analytical by default	automatically generate analytical models and execute them, connected to anayltical model
Schmelcher et al. [39]	contains cross-domain information and relations, created here with SysML	survey interdisciplinary information with agent based systems, spanning framework for further system development tools
Reichwein et al. [40]	SysML or Modelica (high level and simulation)	describe requirements etc (glsSysML), descirbe and simulate dynamics and behavior (Modelica)
Follmer et al. [41]	integrated model connecting a full system model with sub system und domain models	provide holistic cross domain view of system and analyze overall reliability of the system, connect abstract models with concrete models
Ramos et al. [42]	in SysML: requirements, its structure, its behavior, its parametrics. This integrated specification is usually in interaction with other engineering models (e.g., simulation models, analysis models, hardware models)	single source of truth, defining system boundaries
Becherini et al. [43]	static model of functions and elements of a system	to provide different views of systems and subsequently used as basis for the derivation of simulation models in a more mature stage of product development
Glas and Sartorius [44]	SysML/UML model of capabilities, parameters, system function, simulation, unclear of individual UML artifacts are system models too	performance assessment and effort estimation; sketching existing system for benchmarking the to-be-designed system; explore design alternatives
Wang and Wang [45]	mathematical models (DEQ)	simulation
Ma et al. [46]	model of the enery consumption system, multi-view model and mathematical model	efficiency assessment
Zander [47]	executable simulation model of the system	simulation (compute states and outputs)
Haveman and Bonnema [48]	high-level (pre-domain) model (here SysML)	communicate information for design trade-offs
Nattermann and Anderl [49]	contains requirements, functions, components and corresponding properties and parameters as well as their interdependencies, derived from functions and requirements	communication across domains, simulation
Sharon et al. [50]	OPM model	formally and model-based connection project management and product development
Gausemeier et al. [51]	partial models form the discipline-spanning system model. This system model is the starting point for the discipline-specific development of the product	calculate the product maturity on system level, module level, domain level, and system element level, obtaining relevant information for planning the development progress are extracted from the system model and project management
Broy [52]	Dymola models	Analysis of a system
Barbieri et al. [53]	SysML model	change analysis and linking domain specific design
Zierolf et al. [54]	software model	simulation, understanding system level behavior
Komoto et al. [55]	modelica model, physical model + data model	cross-domain communication
Micouin [56]	made up of a Specification model and behavioral Design model, can be composite of multiple spec and design model pairs	validation through simulation
Song et al. [57]	model that provides key performance parameters of the system starting at the beginning of the design	derive simulation
Pfluegl et al. [58]	series of interconnected domain models	monitoring
Acker et al. [59]	composed of models of the subsystems, in general one level of abstraction, sometimes more levels of abstraction combined; computation, communication and control models	system simulation, transfer to simulink
Aboutaleb and Monsuez [60]	shows system complexity, set of components, interrelations and their intensity	early system design/architecture
Morkevicius and Jankevicius [61]	SysML	Requirements verification
Tschirner et al. [62]	graphical model of the system (SysML/OPM)	core of MBSE, enabling consistent specification of product from different viewpoints, requirements, structure, behavior, concepts /e.g., sketches), makes dependencies visible, one system model, data basis for all disciplines
Kaslow [63]	single source of truth, integrates other models and simulations	integrates other models
Kaslow et al. [64]	integration of domain specific models	integrates other models
Holtmann et al. [65]	SysML	coordinate disciplines (E/E, Mech, SW), common understanding, starting point fir domain specific engineering, generate software spec
Dumitrescu et al. [66]	graphic models, SysML	derive behavioral models
Iwata et al. [67]	single model in SysML or similar (can consist of multiple SysML diagrams) that integrates other design and modeling information	visualize the concurrent activities and identify conflicts more efficiently
Hampson [68]	system architecture + system parameters	perform verification of its value properties post-analysis against the requirements
Aboutaleb and Monsuez [69]	holistic integration of models that provide a single source of truth across domains	collaborate across domains, manage complexity beyond “divide and conquer”
Cheng and Zhou [70]	common information model	active monitoring
Johnson et al. [71]	physic based models of robot system, model of hybrid dynamic system, number of assumptions for mathematical model	analysis
Kulkarni et al. [72]	SysML model	evaluate design decisions
Sindiy et al. [73]	SysML	multi-user accessible, reporting (web-based extracted), single source of truth (main source of project information), needs to be center of MBSE infrastructure, partial write access through view editor, stored in system model repository
Brecher et al. [74]	IML, self developed, based on UML, SysML, FAD, Consens	communication, extract discipline specific information
Vannesjo et al. [75]	DEQ	support development
Henke et al. [76]	requirements and architecture, connected with domain models via SysML	tracing
Pleshkova and Zahariev [77]	graphical model of the system (SysML/OPM)	design of systems
Wu et al. [78]	behavior and block model of the hybrid AC/DC system	reflect electromagnetic properties
Qu et al. [79]	behavior model, multi-agent system	simulate emergence
Kaslow et al. [80]	commonly uses SysML	Single source of truth
Watson et al. [81]	SysML—series of tightly integrated and interrelated models that form a complete system model	integrate human interaction into system development
Fischer et al. [82]	database, for the whole lifecylce, several for different phases, central source of truth for system relevant information	organize information for everyone and keep data consistent
Rambikur et al. [83]	word not used in text, but speaks of system modeling (behavior and architecture models)	fault tree anaylsis
Friedl et al. [84]	descriptive SysML model	NOT the main focus of SysML to run simulation, should supprt calculations, automatical generate executable (Simulink) models out of (SysML system model)
Kößler and Paetzold [85]	complementing domain specific models, core of SysML	enable consistency of data, visualization, understanding of complete system, communication, calculate the fulfillment of requirement with less effort, representf dependencies between different domain’s data
Hanson et al. [86]	SysML model	improve integration and collaboration
Parrott and Weiland [87]	SysML model	technical reviews
Anyanhun and Edmonson [88]	concept model (SysML)	requirements definition
Wang et al. [89]	SysML model	document change propagation
Fischer et al. [90]	meta-model, similar to database, merged knowledge of engineer, stores current design of system	focus on common tasks, feedback to engineers, hierarchical decomposition of system, on-the-fly analysis
Kübler et al. [91]	graphical language model that connects to domain models	single source of truth, lifecylce management, collaboration, provide view points
Madni and Sievers [2]	‘living representation’ of a system that continues to evolve as details are incrementally added throughout the system’s lifecycle	single source of truth, VV
Bossa et al. [92]	capella model	starting point for the definition of a co.simulation platform model
Papakonstantinou et al. [93]	multidisciplinary model of the system under development	used for safety and security assessment as well as communicating information between all system stakeholders
Gaskell and Harrison [94]	more connected and dynamic definition of a system, DSM, (SysML/OPM model)	SETR with metrics in meta-model
Wang et al. [95]	connected SysML diagrams	creation of highly integrated product model
Duncan and Etienne-Cummings [96]	SysML (can be integrated with Matlab)	trade-off and analytics using FEA, Single source of truth
Kunnen et al. [97]	continuous data model with usage of modeling language, here SysML	identification of errors and risk = identify negative influences and risk
Buldakova [98]	ONLY behavioral black box model	study real processes or phenomena and the control system as well as the system response; classification of system states, forecast of changes, assessment of system description completeness and parameter sufficiency
Stevens [99]	connection of various models which are accepted and maintained as authorative representation	development of concepts, understanding of real system and inform decision makers, improve communication
Konrad et al. [100]	graphical modeling language model (here SysML)	support the development process, visualization of processes, identification of complexity drivers, complexity management
Baklouti et al. [101]	SysML with included system requirements, behavior, architecture and functions	generation of FMEA and fault tree
Bagdatli et al. [102]	SysML	single source of truth, design space exploration
Gao et al. [103]	SysML based digital system model or sets of models that help integrate other discipline specific engineering models and simulations, which is initiated at the start and evolves through the system’s lifecycle	used or integration and to support optimization, simulation and analysis
Kamburjan and Stromberg [104]	formal model of a real target system that mirrors structure and behavior sufficiently for prototyping and to evaluate changes, digital twins are a variant of this	prototyping and to evaluate changes and digital twins
Duhil et al. [105]	system architecture	Simulation (when enriched)
Zimmermann et al. [106]	model that integrates requirements and architecture	generating dynamic models and viewpoints, supporting digital twin application
Mei et al. [107]	integrated multi-domain model incl. a “transformer model” for integrating all comprising models, created through bottom up integration of component and subsystem models	simulation, prediction and system VV

). For each reference, the extracted key points for the purpose of the system model in the publication as well as the definition in sense of what is inside the model and how is it is created are listed there. The purpose has been clustered as synthesis and analytics in Table 2.

Both use cases, analysis and synthesis, make up roughly the same percentage with analytical use cases having a slightly larger share (51%). To get a better insight, these aspects will be further investigated in the discussion part.

Regarding the definition of a ‘system model’ the distribution taken from Table A6 are listed in Figure 8.

The most widely used definition of a ‘system model’ are graphical language models defined with SysML or Object-Process Methodology (OPM) (44%). 24% of the literature body call the combination of different domain-specific models a system model.Explicit domain models used for simulation like Matlab models are used in 14% of the literature body when speaking of ‘system models’. Eventually, pure mathematical models as differential equation (DEQ) systems and data models are meant in 10% and 4% of the literature body, respectively.

While most publications regarding graphical language models had references to MBSE, the publications presenting mathematical models and domain models did often not mention MBSE at all.

Figure 9 displays the dominant model formats for these definitions.

Regarding the primary model format a publication utilizes there is a wide variety of custom or commercial tools and formats and only very few formats are used in more than three samples. SysML and Matlab/Simulink or Modelica are the dominant ones across all systems model definitions. Analyzing the primary model formats used in publications in correlation to their understanding of system models shows that multiple samples depict graphical modeling as the main aspect of systems modeling, but utilize Matlab/Simulink or Modelica as the primary model format. This is mainly caused by the fact that a large part of the publications describing graphical modeling as the core of a systems model, connect various behavior models through graphical diagrams.

As MBSE is largely driven by Software Engineering, the distribution of software systems as target system, compared to interdisciplinary systems has been investigated and is shown in Figure 10.

The distinction between publications that focus on the information system or software-driven aspects of their system of interest on one hand or the entire system across all domains equally on the other hand, interestingly does not show huge discrepancies in the respective understanding of system models. Data Models as the focus of systems modeling are significantly more common in software-centric publications compared to more holistic ones. The samples that consider the entire system equally put more emphasis on domain-specific simulation models, as well as general mathematical approaches like networks of differential equations. This is mostly driven by a stronger need to find generic approaches to combine multiple viewpoints and system aspects, while from a software-centric view behavior and data models are often sufficient.

4. Discussion

The results presented in the previous section shall be used to answer the research questions and validate the working hypotheses.

In this section, we discuss the results of our literature review.

4.1. Definition of the Term ‘System Model’

As was expected, most publications referred to system models as graphical models like SysML and OPM models (Figure 8), which are often associated with MBSE. Furthermore, system models have been defined as mathematical models in form of DEQs, domain-specific models like Matlab models and as networks of multiple domain models. The definition data model was barely mentioned and therefore was included in the definition ‘interconnected models’, as data models were exclusively mentioned in the context of connecting multiple models.

Even though the domain-specific and mathematical models rarely mention MBSE, it is still seen as feasible for the modeling a complex engineered system. Therefore, they remain relevant within the context of systems modeling of technical systems.

Additionally, all system models have been digital. While models, in general, do not have to be virtual (e.g., clay models), digital representations that allow for different views on a model and the dynamic integration of different artifacts as system parameters provide great benefits.

4.2. Usage of the Term ‘System Model’

In regards to the use of system models, 51% of sources indicate a primary use of system models in the context of their publication as analytics, as opposed to 49% of publications that indicate system synthesis as the main driver behind the application of system modeling. According to our observations, this unclear picture is largely driven by the nature of systems development in engineering. Due to the recursive and iterative nature of system development, simulations as an aspect of system analytics generate knowledge about a current or future system, yet might ultimately be driven by system synthesis. This circular dependency between analytics and synthesis also means that the results obtained are usually applied to further develop and optimize a system until a desired system maturity and layout is achieved through multiple iterations. This usage is not bound to a single domain but is widely spread as could be seen in Figure 6.

One question we tried to answer when we set out to review literature pertaining the definition and use of system models was whether there is consensus if there can be more than one ‘system model’ per system. It turned out that even within individual publications determining whether a single or multiple system models are being developed or applied is very difficult, due to the generally iterative and recursive nature of system development. None of the selected publications put much emphasis on this question either. The first issue here may be the vague definition of what constitutes a single model versus a group of highly interconnected models. For example, there is not even consensus on a technical level whether multiple diagrams in a graphical modeling notation constitute one model or multiple ones. This, again, may be attributed to the fact that system modeling is often applied from a need-driven perspective and ultimately it is probably not important as long as project/product boundaries are predetermined and the selected modeling approach supports existing or prospective use cases. This is further supported by the fact that none of the analyzed publications explicitly defines clear boundaries between pre-domain systems modeling and domain-specific modeling and development approaches. None of the samples attempts to even implicitly define a generalized definition of that pre-domain/domain boundary, which suggests that this boundary may be driven by existing processes and organizational structure and therefore be highly dependent on a specific use case. None of the reviewed publications contains negative views on system models, despite some samples mentioning new difficulties which arise with new methods and tools, such as requirements regarding IT-infrastructure, potentially new organizational structures as well as extended skill sets of developers. As conclusion, we found no consensus across the literature body, if there can be more than one ‘system model’ per system. Looking at the different definitions used in the publications (see Figure 8), there seems to be no evidence that there must not be more than one system model per system. In conclusion, this means that multiple system models per system should not be considered infeasible per se and might very well be useful depending on individual use cases.

4.3. Drivers and Indicators for the Usage of System Models

The decomposition of the statements on the reasons for applying system models into indicators and drivers supports a cause-and-effect analysis between drivers of system model usage. This approach connects the question why system models are being considered (Drivers) with the question, which measures authors aim to invoke on a technical level in order to achieve what they set out to accomplish (Indicators). Since the body of literature is of the size n = 104, most publications mention only one driver (111 mentions of drivers and 143 mentions of indicators) and for readability, the numbers shown in the Figure 11 represent the share of the drivers and indicators mentioned in the publications over their respective sum in absolute numbers. The different indicators are comprised of clustered aspects of systems development in engineering, which are supposed to be optimized according to the publications contained in our body of literature. The drivers are comprised of system properties on one hand and perceived challenges across a systems development life cycle on the other hand. Potentially perceived challenges might trace back to the system or product properties, but there was no clear evidence for this in the analyzed set of publications. While beyond the scope of this review, the obvious fact that system development activities seek to produce a system that exhibits a set of desired properties, suggests that the drivers would ultimately all trace to the system or product properties (the “best” possible system). The flow within the figure highlights relationships between drivers and indicators. If, for example, a publication describes the impact of improved traceability and attributes this to the driver Collaboration, this is recorded as a relation and is displayed as a sankey flow in the figure. The width of each sankey flow connector correlates to the number of samples mentioning this driver-indicator relationship. This enables visual identification of the correlations between drivers and indicators, and indicates the frequency of occurrence in the literature body.

The drivers were aggregated to form groups from the sum of all identified drivers contained in the body of literature, which often used different verbiage but was alluding to the identical driver:

• System Complexity: By far the most important driver resulted from the focus of many publications on improving the development and operation of large and highly interconnected mechatronic or cyber-physical systems.
• Development Process: A large number of publications included in the body of literature indicated the development process itself as the main driver for the application of system models in order to maintain consistency across processes and methods that are themselves complex and can not be handled well without the extensive use of modeling.
• System Quality: This is perhaps the most basic of all mentioned drivers and refers to the quality properties of a developed system as opposed to the performance of its development lifecycle activities.
• System Design: This driver pertains to the functional properties of a system and is mentioned by publications that describe the development of new features and design solutions, which emerged using system modeling.
• System Safety: The publications that explicitly describe safety as one of the drivers behind the use of system models employ systems modeling as a means to derive safety engineering-related artifacts automatically (e.g., fault trees).
• System Validation: This driver relates explicitly to system validation activities.
• System Modularization: Publications that mention this driver view system modeling as a tool to improve system modularization in terms of clear and standardized system boundaries to support compatibility with other systems and sub-systems.
• System Security: This driver relates systems modeling to the development of secure systems.
• System Certification: The publications explicitly mentioning certification as a driver see system modeling not only as a means to satisfy other certification requirements, but also as a direct requirement by certification authorities.
• System Performance: This driver does not relate to the implementation of novel features but improvements in non-functional properties, like general efficiency of the system, uptime, or accuracy of an operation executed by the developed system.
• Collaboration: A number of publications mention general collaboration among developers or even all stakeholders as a driver. This often is related to the ease or efficiency of exchange of information and data between developers internally, as well as with customers and other external parties.

Indicators:

• Improved Modeling Quality: This indicator includes factors such as model fidelity and performance in other aspects.
• Earlier Testing and Validation: This relates to the front-loading of verification and validation activities.
• Traceability: This includes explicit traceability, e.g., in a requirements engineering context, as well as (dynamic) modeling of connections inside and between models improved systems.
• Integration: This includes aspects such as (co-) simulation and other digital methods that allow for front-loading and concurrent execution of integration activities.
• Better Requirements: This indicator relates to improved requirements in terms of the formal quality of the developed requirements and their usefulness for other aspects of system development.
• Improved Tools and Methods: This comprises improved IT-Tools and methods enabled by the application of systems modeling.
• Compliance: This indicator indicates a direct requirement to apply systems modeling by certification bodies or legal frameworks.
• Better Solution Architecture: An improved solution architecture relates to an improved system in terms of features available and/or system performance through new structural or behavioral properties that emerged using systems modeling.
• Intellectual Property (IP): This indicator relates to the way that system models can support the protection of intellectual property, in this particular case through compartmentalization of IP and easier exchange of subsystem models.

Our analysis shows that the general challenge of development processes, system quality and system complexity are the main drivers for the application of system models (combined those three alone amounts to more than 73% of all mentions). These three are not necessarily independent criteria and over the course of our review, we come to conclude that the main reason development processes are perceived as challenging is often a combination of system complexity and the complexity of processes and tools. This would suggest that managing complexity and achieving high quality are the key drivers for the use of system modeling. The fact that complexity is a vaguely defined term in the context of systems engineering appears to show a relatively equal distribution of connections to all mentioned indicators. The three largest drivers System Complexity, Development Process and System Quality account for an overwhelming majority among the drivers. They are associated with almost all indicators to equal amounts (with the exception of System Quality being biased towards improved model performance), which may be because system development of large and interconnected systems poses a particular challenge with wide-ranging impact. This is because it comprises various activities and technical goals, which need to be managed and balanced in order to create the desired system or at least approximate the ideal outcome as closely as possible with available resources and under the current circumstances.

Overall, our analysis shows that system models are viewed as a sufficient tool to synthesize and analyze technical systems across various industries and domains, despite being seen as novel and to a degree often still experimental. A precise definition of the term system model remains elusive, yet there are certain key aspects in regards to the purpose system modeling should serve, that we were able to extract. Overall system modeling is applied to manage complexity in system development and unify as well as align different domains of system development. Depending on the author’s perspective and the context, this can manifest itself as improved consistency, improved communication, improve collaboration or other terms that all describe a concerted effort by an organization to develop a technical system. For practitioners in engineering, the issue of system modeling and specifically how to utilize a system model is largely need-driven, without much emphasis on the definitions and boundaries that are of potential interest to academia and systems theory research. This becomes even more clear when considering the relative variety of implied definitions of the term system model. This need-driven and basically problem-solving-oriented view in the industry appears to also be reinforced by a largely bottom-up approach to systems modeling. Across all industries, explicit generic system modeling efforts through graphic modeling languages such as SysML, OPM and others are gaining traction, which are often associated with MBSE. Regarding incorporating behavioral and dynamic system characteristics, though, the architectures encountered in the body of literature draw significantly from established methods and models used in different engineering domains. For both modeling solution vendors as well as engineers ultimately only the outcome matters.

Due to the need-based and often bottom-up approach to system modeling in engineering, there is a considerable risk of missing publications that simply make use of different verbiage to describe their understanding of system models and their applications. Furthermore, non-peer-reviewed engineering magazines could contain more information regarding the use and understanding of system models in different industries, but those sources were mostly not searchable or otherwise indexed and were not included in the initial key word search.

This review sought to lower this risk by using a relatively wide range of keywords and putting more emphasis on manual review of a larger literature body. Across the body of the literature review, a wide range of either, very explicit or implicit statements were made regarding system models, their purpose, definition, general usage as well as unique use cases described. Quite often defining and describing the system model is not the main focus of publications and systems modeling is merely established and described as a solution to a problem, which is then described in further detail.

In addition to information about the scope of the review being embedded within other subjects of research in engineering and technology, some publications mentioned keywords of our search exclusively in their abstract without mentioning them in the actual text, or if so, only implicitly and hard to extract through automated methods, which was another driver for our focus on manual review of a less exclusive body of literature as opposed to a very restrictive keyword search.

4.4. Validation of Hypotheses

Considering these discussion points, the hypotheses defined in the beginning shall be summarized and validated.

Hypothesis 1.

There is yet no converged overall definition of the term ‘system model’: As most publications used different definitions for a ‘system model’, this hypothesis was confirmed. The definition presented by Hart [3] in Section 1 was the only full definition of a system model, even though it has not been referenced in any publication.

Hypothesis 2.

A ‘system model’ can be created in different ways and is not limited to the application of Systems Modeling Language (SysML): This hypothesis was confirmed. System models are often created with and thus connected to graphical modeling languages like SysML, but are not limited to them. Mathematical modeling and direct linking of different models are also valid forms of system modeling.

Hypothesis 3.

The usage of a ‘system model’ is not limited to the domain of System Engineers: This hypothesis was true considering all kinds of system models defined in the previous subsections. As one kind of system model may be domain-specific, different other domains can use them. With interconnection models and data models as system models domain-specific engineers can use them as well in their common tools, even though it is in an indirect form. Thus, system models can benefit all domains that are part of the system development.

The three confirmed hypotheses support and enrich Hart’s [3] definition.

Definition 1.

A system model is a (usually virtual) representation of the target system or one or more of its subsystems. It can be in the form of

(A) 

a domain specific part of the (sub)system (e.g., a domain-specific simulation model of a subsystem),

(B) 

a domain-independent structure of the (sub)system (e.g., system architecture) or

(C) 

a model linking the various (sub)system artifacts.

One key aspect of this definition is that in contrast to the definition of Hart [3], it specifically includes subsystems. In the previous definition, overall system interconnections were already addressed, but did not focus on the lower levels which have an important role. Additionally, domain-specific parts of systems and subsystems as well as models for linking artifacts, are included in this definition. The categorization within the definition allows us to classify upcoming research to one of these categories and thus allow an even better alignment of research conducted in that field.

5. Conclusions

Defining the term ‘system model’ is particularly challenging, considering the fact that there are multiple definitions for the concepts ‘system’ and ‘model’, which are not always consistent. Despite there being a vague general agreement as to what those terms mean, the general understanding is not clear enough to establish a definitive scope of system modeling and system models in engineering and technology.

Across various industries, as much as it seems clear what purpose system models serve on a higher level, it remains unclear where system modeling ends and where domain-specific methods and models begin. This makes it particularly difficult to define an exclusive scope of systems modeling in engineering and technology.

There is also no consensus in the reviewed publications regarding the ideal system modeling approach (a perfect generic solution presumably does not exist) there is a broad consensus about the benefits and the need for system models. In general, the utilization of systems modeling is driven by business needs and largely tailored to specific challenges system developers face, when engineering a particular system. This use-case-driven approach does neither require a general definition of the ‘system model’ nor a clear distinction between what constitutes a system model and what does not. Innovations appear therefore mostly driven by use-case studies and experiments as opposed to an overall theory of system modeling in engineering. More academia and research-driven publications looking to improve on current advances and to innovate current system development approaches, attempt to apply existing concepts from other modeling domains, such as Software Engineering. In those samples, systems theory concepts are additionally leveraged to support evidence-based knowledge with a more mathematical and rule-based foundation. Often this is part of a greater effort in further defining and developing MBSE beyond high-level approaches or the mere application of specific methods that are supposed to support model-based approaches to systems engineering.