Systematic literature review of system models for technical system development

: In MBSE there is yet no converged terminology. The term ’system model’ is used in different contexts in literature. In this study we elaborated the deﬁnitions and usages of the term ’system model’, to ﬁnd a common deﬁnition. 104 publications have been analyzed in depth for their usage and deﬁnition as well as their meta-data e.g., the publication year and publication background to ﬁnd 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 deﬁned and integrated into a more precise deﬁnition.


Introduction
While the research and industrial interest in Model-Based Systems Engineering (MBSE) -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 interationally 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 a main artifact in MBSE [2], there is also yet no definition for the term 'system model', which the model is often refered to. In 2015, Hart [3] mentioned, that a system model is '[...] a structured representation that focuses on the overall system requirements, behavior, structure, properties,& 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. But 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 wide spread 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 organizations and 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: 1. 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). 3. The usage of a 'system model' is 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 lsited in section 3. Screened studies are presented and discussed in context of bias. 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.

Materials and Methods
The systematic literature review has been carried out without a systemtic 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 eligibile as well with the term 'Systemmodell' as equivalent to the English term 'system model' . To get a full overview of any possible definition for the term 'system model' the year has not been limited in any form. The eligiblity has mainly been based on the reference to engineered systems and a possible corrolation to MBSE.
The scanning period dated from July 18 th , 2020 to July 31 st , 2020. Information sources included the databases Scopus from Elsevier (www.scopus.com), Web of Science from Clarivate (apps.webofknowledge.com), SAGE Journals from SAGE Publications (journals.sagepub.com), IEEExplore of the Institute of Electrical and Electronics Engineers (IEEE) (ieeexplore.ieee.org) and arXiv.org made available by the Cornell University (arxiv.org). As of November 18 th , Scoupus includes 41,462 journals, proceedings, books and trade publications (https://www.scopus.com/sources.uri) from 1960-2020. Web of Science covers 21,419 books, proceedings and journals from 1900-2020 (https://clarivate.libguides.com/webofscienceplatform/coverage). IEEExplore includes 5,329,188 articles from journals, conferenes, early access publications, standards, magazines, courses and books. The date coverage goes from 1872-2021. Sage Journals dates back from 1847-2021 and accesses 1,211 journals. arXiv.org covers 1,795,706 open-access articles explicitly submitted to arXiv.org with a date coverage of 1991-2020. Table 1 summarizes these information and gives an overview on the content of the database. No additional sources have been used. As the search for the term 'system model' would bring too much results regarding different kinds of none technical systems and models in various contents, the keywords have been refined. The following keywords have been used: 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 capitalizations of the words and abbreviated titels with same list of authors and year. The rest of the titles has been screened for eligibilty. 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 done with the abstracts of the publications and their full-texts in the final screening step. The screening for eligbility has been performed by 2 reviewers. Unclarities 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 comprising the relevant information of each publication into comments in the PDF and transfer these comments into a tabularized dataset. The extracted items have been discussed by the two review authors and whenever a disagreement was reached, a third reviewer was contacted. A the this study focused on the defintion and usage in literature, none of the authors have been contacted for further details, as this might bias the analysis. 4 of 38 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: 1. Domain/origin/background of the systems under consideration, 2. Definition or meaning of the term 'system model' and 3. 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 independtly. Principle measures have been the quantities of specific origins, definitions, creation appraoches and usage description for 'system models' (defined variables lsited above). The analysis of the studies was done by clustering the dataset 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 a risk of bias across studies.

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

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 6,586 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, 6,103 titles have been excluded as they were not fitting into the topic of interest. This was primarily done 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. This table lists the publications in chronological order (focusing on the year and not month of publication) with their reference, year of publication, type of publication, 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

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 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 apply 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 they obviously 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 observed 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 is was described as universally applicable or if there could not be defined a specific domain or even target system (e.g., if the aim of the publication was on the methodological approach). In context of the domain, 'Other' constitutes of 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 distrubtion of these domains over the literature body. 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.  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 falls 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 the purpose of the system model have been extracted from each publication as well. Due to readability, the table has been added to the appendix (Table A6). 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, have 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 publication regarding graphical languge models had references to MBSE, the publications to mathematical models and domain models did mention MBSE not so often. Figure 9 displays the dominant model formats for these definitions.  When it comes to 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 see 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 portion 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 sw-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 ways to combine multiple viewpoints and system aspects, while from a software centric view behavior and data models are often sufficient.

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.

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 linked to MBSE. Furthermore, system models have been defined as mathematical models in form of DEQs, domain specific models like Matlab models and as a interconnection 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 did not mention MBSE that often, it is still seen as feasible form of modeling a complex engineered system. Therefore, they should still be considered as a kind of system models. 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 provides great benefits.

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 the judgment 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. Furthermore, it turned out that 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. Also 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. Thus, it is proposed, that multiple system models per system are feasible.

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 means connect 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. 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 number 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 across 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 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 exhibit a set of desired properties, suggests that the drivers would ultimately all trace to 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 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 differnt verbiage but were 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 a 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 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 compatibilities 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 amongst 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.  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 amount 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 as well as 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 in 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 based 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 that 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 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 authors perspective and the context this can manifest itself as improved consistency, improved communication, improve collaboration or other terms to 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 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. When it comes to 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 key words and putting more emphasis on manual review of a larger literature body. Across the body of 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 the 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.

Validation of hypotheses
Considering these discussion points, the hypotheses defined in the beginning shall be validated shortly.
• 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 limited to the domain of System Engineers: This hypothesis was false considering all kinds of system models defined in the previous subsections. As one kind of system models 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.
Thus two hypotheses could be confirmed and one was neglected. This can be used to enrich the definition of Hart [3] to a more precise form.

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.

Conclusion
Defining the term "system model" is particularly challenging, considering the fact that there are multiple definitions for both the words 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 probably does not exist) there is a broad consensus about the benefits and the need for system models. Innovations appear therefore mostly driven by use-case studies and experiments as opposed to an overall theory of system modeling in engineering. More academia heavy 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 SW 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 Model Based Systems Engineering beyond high-level approaches or the mere application of specific methods that are supposed to support model based approaches to systems engineering. 20    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 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")  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 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   Table A6. Continued

Reference Definition Purpose
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  entrypub= e n t r y . published entrypub = entrypub . encode ( e r r o r s = " r e p l a c e " ) entrypub = entrypub . r e p l a c e ( " \r " , " " ) entrypub = entrypub . r e p l a c e ( " \n " , " " ) e n t r y t i t l e = e n t r y . t i t l e e n t r y t i t l e = e n t r y t i t l e . encode ( e r r o r s = " r e p l a c e " ) e n t r y t i t l e = e n t r y t i t l e . r e p l a c e ( " \ r " , " " ) e n t r y t i t l e = e n t r y t i t l e . r e p l a c e ( " \n " , " " ) # e n t r y t i t l e = " t i t l e " a u t h o r s t r i n g = a u t h o r _ s t r i n g . encode ( e r r o r s = " r e p l a c e " ) entrysummary = e n t r y . summary entrysummary = entrysummary . encode ( e r r o r s = " r e p l a c e " ) entrysummary = entrysummary . r e p l a c e ( " \r " , " " ) entrysummary = entrysummary . r e p l a c e ( " ; " , " , " ) entrysummary = entrysummary . r e p l a c e ( " \n " , " " ) f i l e w r i t e r . writerow ( [ e n t r y i d , entrypub , e n t r y t i t l e , l i n k . h r e f , a l l _ a u t h o r s , entrysummary , p r i m a r y _ c a t ] ) count = count + 1 # a u t h o r s t r i n g p r i n t ' t o t a l R e s u l t s f o r t h i s query : %s ' % fe ed . fe e d . o p e n s e a r c h _ t o t a l r e s u l t s