Model Signatures for the Integration of Simulation Models into System Models

Abstract

Model-based systems engineering (MBSE) is an auspicious approach to the virtual development of cyber-physical systems. The behavior of the system’s elements is thus represented by specialized simulation models that are integrated into the descriptive SysML-based system model. Although many simulation models have been developed in research for the common system elements for various purposes and fidelities, their integration remains a major challenge: the parameter interfaces of the simulation models must be coupled with each other and with the parameters of the system elements in such a way that they are correctly parameterized. So far, this coupling can only be carried out by model experts in a time-consuming and error-prone manner. Therefore, in this paper, we first propose a concept that structures the system element parameters for targeted use in validation and design cases. Second, we propose a model signature for simulation models that differentiates its parameters by input, internal, output, and model parameters and specifies them with spatial and temporal dimensions as well as admissible ranges, among others. Based on the two contributions, domain models can be validly and automatable coupled and used for the virtual development of system elements in model-based systems engineering.

1. Introduction

Model-based systems engineering (MBSE) is a promising approach for the accelerated, virtual development of cyber physical systems (CPS) with reusable models [1]. Thereby, the system to be developed (e.g., a connected vehicle) is represented by a system model consisting of a hierarchical structure of system elements for the individual subsystems (e.g., top-down: mechatronic drive train, electric engine, bearing, cylindrical roller bearing, lubricated rolling contact) in accordance to [2]. Low-level system elements are also referred to as solution elements in [3,4]. Regardless the terminology, however, the modular and generic entities describe fundamental interrelationships, which are often reused in a wide variety of higher-level systems. Therefore, these low level system elements can be identified as enablers for accelerated virtual development of CPS [3,5].

Testing requirements and ensuring the functionality of the overall system concerning the mechanical domain, requires all system elements to be validated with regard to their behavior. To validate the behavior of a system element, different purposes (e.g., lifetime, friction losses, pressures, temperatures, lubrication conditions) have to be considered [3]. Since the behavior usually cannot be validated with a descriptive, SysML-based system model alone [6,7], a system element needs appropriate domain models to account for all the different purposes. A domain model is, by its nature, a representation of the original system that has been shortened or abstracted in terms of scale, detail and/or functionality [8] and typically a specialized simulation model that runs in an external software tool and needs to be integrated into the SysML-based system model [6,9,10,11,12,13]. One of the open challenges with such an integration is to provide a well-defined, modular and consistent interface between domain models and their system element counterparts, for instance to assure a correct parameter exchange. The term parameter is used in this paper analogously to [3] as a generic term for all quantitative attributes of the interfaces of domain models.

In the current state of research, numerous domain models for a specific purpose are published, which differ in terms of their used parameters, fidelity, model assumptions, computational effort, and other criteria. This leads to the challenge of selecting the most appropriate domain models, which in return requires that domain models must be identifiable with respect to relevant criteria in order to be able to clearly assign them to system elements [14]. To this end, suitable and efficient methods must be explored that enable the large variety of existing models to be sustainably utilized for model-based product development.

Another challenge is that many purposes of a system element are interdependent and coupled. As an example, pressure, temperature, and manufacturing accuracy result in certain lubrication conditions, which in turn affect service life. Neglecting these coupling effects via an isolated consideration of these purposes is not sufficient in the development process und would lead to significant errors in the system model [15,16]. Instead, it must be possible to couple the respective domain models in order to virtually represent and validate their feedback mechanisms. In doing so, it is crucial that the coupling of the domain models is consistent and correct for the specific validation question. Hence, this calls for novel research approaches to evaluate the compatibility of individual domain models in a systematic and potentially automated way. Methods for the latter are actively being worked on, yet proposed solutions are often restricted to specific simulation tools or data exchange standards.

While a decomposition of the system model into system elements is often used and common practice, low-level domain models are individually proposed and investigated in the literature, yet not analyzed in the context of a system model. Domain models are hence not systematically structured by an appropriate taxonomy that would be accessible from system models: Up to now, it has not been possible to standardize the descriptions of the numerous and often only gradually different domain models in terms of content and form. As a result, system engineers have not yet been able to identify domain models unambiguously and efficiently, assign them to associated system elements, and reuse them. Instead, system elements are usually modeled individually, often with considerable effort and expert knowledge, although they and their domain models are actually fundamentally known [14]. Since there are no standardized concepts or methods either for the parameter interfaces of the domain models or for the parameters of the system element, a great deal of effort is involved, especially in linking these parameters.

Furthermore, due to the poor documentation described above, it is not possible to clearly and efficiently evaluate if two domain models can be coupled in an automated way. As a result, system engineers either need a lot of time to reliably assess the compatibility or domain models are partially coupled incorrectly. Depending on when these errors become apparent, this leads to change costs in the development phase or, in the worst case, high recall costs in the use phase of the system.

Imagining an ideal development process, each system element and domain model would have an unambiguous and machine-readable interface description of its relevant model parameters, so that within the required time, cost and quality for the development of CPS

• A clear and automated assignment of domain models to system elements is possible;
• The compatibility of domain models can be automatically evaluated;
• The most appropriate combination of domain models given a certain requirements-driven goal can be identified.

To reach this goal, we propose a parameter concept for system elements (cf. Section 4) as well as an unambiguous and machine-readable model signature for domain models (cf. Section 5). Finally, we discuss to what extent the parameter concept and model signatures help in combination to uniquely identify and correctly link domain models for system elements (cf. Section 6). For exemplary application and explanation of the results, in this paper we use the lubricated rolling contact as a typical machine element in mechanics: Two convex or convex/concave cylinder surfaces touch each other in a lubricated state at a narrow contact area where a thin lubricant film transfers mechanical forces from one surface to the other (Figure 1) [17].

2. State of the Art

Nowadays, and in the future, increasingly, CPS are being developed. CPS are characterized by interacting subsystems of the mechanical, electrical and software domain. The different subsystems and development processes of the domains lead to an immanent complexity in the development of CPS [18,19].

2.1. Function-Oriented Model-Based Systems Engineering

A promising approach to multidisciplinary CPS development is function-oriented model-based systems engineering whose key element is a cross-domain functional architecture typically modeled with the Systems Modeling Language (SysML) [7] or an advanced profile based on SysML [20]. This functional architecture is derived from the requirements and comprises functional flows as interfaces between the functions [20,21]. Based on this functional architecture, all involved domains develop system elements that realize the individual functions assigned to them. These system elements inherit the functional flows of the functions and can thus be developed modularly within the specific domains. Due to this encapsulation, the system elements have a low complexity and jointly represent the behavior of the superordinate system. As a rule, several function-oriented decomposition steps are necessary to reduce the typical CPS complexity within the system elements to a manageable level. This results in a system architecture consisting of system elements across multiple hierarchy levels. The elementary system elements at the lowest level describe very small and fundamental relationships (Figure 2) [3]. One example of such a function-oriented and model-based development approach is the motego method, which has already been applied in several research projects and is continuously being extended [4,22,23,24].

Figure 2 shows the system element lubricated rolling contact which comprises three main constituents: The principle solution, domain models and workflows [3].

The principle solution is an established concept in design methodology to describe solutions based on physical effects and active surfaces with certain geometric and material properties [21,25,26,27]. The physical effect is modeled as a constraint and typically establishes a mathematical relationship between active surfaces, material properties and functional flows. This means that the equation of the physical effect comprises, e.g., the length l, which is of course also a parameter of the two active surfaces (Figure 2). To avoid redundant or inconsistent parameters, these parameters must be linked. Even if system elements sometimes describe only a small scope of a technical system, the parametric description of the active surfaces including material properties, the physical effect, the incoming and outgoing functional flows as well as other relevant physical quantities quickly result in a large number of parameters, most of which must be linked together. When domain models are integrated into the system element, the number of parameters (to be linked) increases again significantly. Since there is no simplifying structuring for the parameters occurring in the system element so far, the linkage is complex, effortful and error-prone [3,21].

The domain model section in the system element contains and structures all models relevant for the development of the scope (e.g., Lubricated rolling contact). At the top level, a differentiation is made between engineering, production and controlling models, whereby only the engineering domain is considered in this publication which typically applicates models of analytical and numerical nature calculating the physical behavior of system elements. Here, the models are classified according to their computational purpose, such as the deformation of the active surfaces or the temperature in the lubricated rolling contact [3,4,14].

Workflows are the third area in the system element. Since domain models must be coupled for specific issues in the development process [14,24,28,29], these coupled models are also stored in a reusable manner and differentiated between validation, design and optimization workflows [3].

The joint storage of principle solution, domain models and workflows enables the specification of the system element (principle solution) to be reusable and consistently linked to the behavior description (domain models) and efficiently applicable in the development (workflows) [3].

2.2. Integration and Coupling of Simulation Models

The system model with the central functional structure and the system elements provides a descriptive representation of the system under development. In order to validate system elements against requirements or to design them with respect to requirements during development, domain models that describe the behavior of the system element need to be integrated and correctly linked to parameters of the other constituents of the system element [30].

Furthermore, typically not only one but several domain models of different purposes and suitable fidelities are necessary to test and design system elements during development. This results in the fact that several domain models must be coupled with each other [3,15,30]. In order for the coupled domain models to perform valid calculations, it is essential that the domain models themselves and their parameter interfaces must be compatible with each other.

Research on the design and of mechanical system elements has built up a large number of models over the last decades. Even within a certain scope (e.g., lubricated rolling contact) and purpose (e.g., lubrication), a large number of domain models of different fidelities can be found, resulting from different (empirical) approaches, boundary conditions and simplifications [31,32]. As a result, a high two- or even three-digit number of domain models is typically available for common system elements such as bearings, gears, shaft-hub connections, or fasteners, respectively. If several domain models have to be coupled with each other, e.g., for service life calculations and wear predictions, a simple combinatoric consideration results in a very large number of potential model configurations. The naive number of model combinations can be significantly reduced, when focusing on the model configurations that are physically compatible. To avoid manual efforts and to use the potential of existing domain models, an unambiguous and machine-processable description of the models and their parameter interfaces is necessary.

For this reason, several approaches for the interaction of system model and domain models have been developed in the past. A good overview of the basic strategies for data exchange between models in general is provided by [33] and with a focus on the parameter exchange between SysML-based system models and domain models by [9,34,35]. In some approaches, SysML profiles were developed to enable data exchange, e.g., for the model transformation between system models and Modelica-based simulation models [36] or for the automatic generation of analysis models from system models [10]. In this context, [9] states that the developed interfaces are often limited to specific simulation tools and compatibility issues frequently arise due to different versions of exchange standards (e.g., FMI [37,38]). Another approach is to orchestrate the data exchange between domain models and the system model by SysML diagrams [30,39].

Often, the approaches develop a specific interface and do not address the fundamental question of how the parametric interfaces of a domain model must be formalized generally in order to enable the valid coupling of domain models inside system elements.

Therefore, it makes sense to analyze the parameter and model definitions of data exchange standards such as Functional Mock-up Interface (FMI) [37], which among other things aim to integrate Modelica domain models into SysML-based system models [40]. The FMI standard requires in particular that each functional mock-up unit contains an XML file describing the model. In addition to their name and description, the parameters of the model are characterized by their causality and variability.

The causality specifies whether the parameter is an input or output parameter, a parameter that controls the model, or a calculated, independent or local parameter. The variability defines whether a parameter is constant, fixed after the initialization, tunable or discrete. Thereby, the FMI standard allows only certain combinations of the attributes ‘causality’ and ‘variability’. In addition, it is possible to specify start, nominal, minimum and maximum values for the different types of parameters [37]. Since the FMI standard is relatively advanced, the model signature developed in this contribution should ensure its logical compatibility to FMIs.

In addition to FMI as a cross-tool standard, there is also research on model classification or signatures for specific tools. [41] aims to improve the quality of Modelica models by adding information on traceability, uncertainty and calibration in a standardized way; [42] proposes a signature for Simulink subsystems as a generalization of the interface including input and output ports as well as data stores. [43] introduces a model identity card capturing classifiers of input and output parameters as well as the expectable quality. Preliminary work on validity and credibility exists in a fundamental nature by [44] and with a focus on software intense embedded systems by [45], who developed a framework to assess and formalize the validity range of simulation models. Many of the approaches mentioned contain classifiers that are very specifically adapted to the needs and possibilities of certain software tools and only partially offer generally valid methods for the lack of logical systematization of domain models in the context of system elements for model-based development described in the introduction.

Another important research approach that has been established in software engineering is contract-based design algebra. Here, system components can be combined to form systems on the basis of predefined sets of rules [46], for example in order to automatically generate consistent design variants that meet requirements [47]. A modeling approach for evaluating compatibility between SysML blocks was introduced in [48]. This approach considers the conformance and direction of data types as well as the compatibility of the value ranges of two parameter interfaces but not on domain model level.

3. Research Question

In the introduction (cf. Section 1), three challenges were described. First, the parameters occurring in system elements are not classified in such a way that parameter associations cannot be efficiently identified when integrating domain models and workflows. Secondly, it is not possible to assess without expert knowledge and high effort whether an existing simulation model is suitable for the calculation of certain properties of a system element. Third, multiple simulation models can only be coupled manually and with a certain error rate, which can potentially lead to high damages and costs [16].

These challenges have not yet been overcome by the current state of research (cf. Section 2). Therefore, the research question addressed in this publication is:

How can an unambiguous parameter relationship be established between system elements and domain models for their identification and coupling?

Two subordinate questions can be derived from this research question:

• How can the parameters in the system element be structured for testing and design with domain models?
• How can model signatures for domain models be defined unambiguously and machine-readable?

The following two sections address the two derived questions: In Section 4 a parameter concept for system elements is proposed and in Section 5 a model signature for domain models based on requirements from the development process is elaborated. In Section 6, research findings are discussed, concluded, and an outlook on necessary and possible future research directions are outlined.

4. System Element Parameter Concept

As described in Section 2.1, system elements which are typically used in function-oriented model-based development consist of inherited function ports, physical effects, active surfaces with material properties, domain models, and other physical parameters. All these constituents of the system element are formalized with parameters [3,21] resulting in a large number of parameters, which can complicate the integration of domain models with their parameter interfaces. Therefore, we propose the differentiation of the following three types of parameters:

Functional flow parameters are all parameters comprised in the functional flows entering and leaving the system element. These parameters are imposed on the system element by the environment or functionally dependent system elements and reflect operating and environmental conditions. Examples include the pressure of a fluid flow and the rotational speed of a mechanical energy flow.

Design parameters can be set directly by the engineer, written into the engineering drawing, and imposed on the real product via manufacturing. These parameters may also change over time due to operation (e.g., wear) or the environment (e.g., ambient temperature), but the initial value is set by the engineer and the manufacturing process. Examples might be the diameter of an active surface or the Young’s modulus of a material.

State variables cannot be set directly by the engineer. These parameters (e.g., tensile stress) adjust themselves depending on the functional flows from the environment and operation (e.g., force) as well as the design parameters (e.g., cross-sectional area) according to the laws of physics.

It is the engineer’s task to define the design parameters in such a way that the state variables are within certain value ranges in all relevant operational and environmental scenarios experienced by the system element via the functional flows.

The proposed differentiation of parameter types helps in the integration and coupling of domain models for validation and design of system elements. The validation of system elements with workflows [30] involves checking whether the behavior of the system element meets the requirements. These requirements can relate to state variables (e.g., a maximum permissible temperature) or to functional flow parameters (e.g., the minimum required torque of a drive system). In both cases the design parameters are already known or at least estimated. This means that such domain models have to be selected and coupled with each other, which take known design parameters as input and calculate the state variable or functional flow parameter to be validated as output (Figure 3, orange).

In the case of the design of a system element, it is the other way around. One or more design parameters are to be determined such that the state variables are within the ranges of validity and the functional flow parameters are generated as required by the operating case. Therefore, such domain models must be selected and coupled in a way that the desired functional flow parameters and limits of the state variables can be taken as input and the sought design parameters are calculated as output (Figure 3, green). Of course, in addition to the sought design parameter, there are also design parameters that are already fixed or at least should not be calculated in the design workflow under consideration. These subordinate design parameters may also be an input. Figure 3 only shows the flow directions of the main parameters considered in the respective workflow in a simplified way.

Thus, the parameters of the system element are meaningfully structured for validation and design. For the appropriate selection and coupling of the domain models, these still lack an unambiguous description of the parameter interfaces, which is proposed in the following section.

5. Model Signature for Domain Models

Model signatures are an approach to describe domain models and their interfaces unambiguously and in a machine-processable way, thus enabling the valid selection and combination of domain models within a system element. Since a large number of individually and inconsistently documented domain models is actively being used, our approach to tackle the research question is to consider a collection of well-known domain models for a specific example, and to derive requirements for model signatures based on their content and form (Section 5.1). From these requirements we propose an approach for model signatures (Section 5.2).

5.1. Domain Model Requirements for the Model Signature

An extract of known domain models for the system element ‘lubricated rolling contact’ is shown in Figure 4. As already mentioned, they can be distinguished by purpose and fidelity [14] whereby the term fidelity is used here in the combined sense of validity and detail of [44]. In our example three domain models of various fidelity can be differentiated for the purpose ‘temperature calculation’ ranging from the assumption of a constant temperature to a fully spatially resolved, transient temperature evolution. Depending on the required modeling fidelity of (thermo-)elastohydrodynamic lubrication calculations in the lubricated rolling contact, different modeling strategies can be applied as demonstrated in Figure 4. For instance, in order to model the lubrication film, either temperature (represented by Barus equation) or pressure dependencies of the viscosity (represented by Vogel equation) in the lubrication film or the combination (represented by Eyring, Barus, and Vogel) can be considered to reach the desired fidelity levels in simulations. Analogously, different approaches for temperature, deformation and pressure calculations can be used [31,32,49]. Please note that the domain models shown are only a small excerpt. Both in the published research literature and in companies, such as a bearing manufacturer, a significantly higher number of models will be found. Based on the extent shown here, an elastohydrodynamic (EHD) calculation (Figure 4, green line) and a thermo-elastohydrodynamic (TEHD) calculation (Figure 4, yellow line) can be found as meaningful model configurations and performed as calculation.

The Assessment of the domain model compatibility requires expert knowledge or a formalized and evaluable domain model signature. Only the latter can later be utilized in automated validation tests.

Figure 5 shows the parameters which are exchanged between the domain models if a TEHD calculation is executed. The depicted workflow (Figure 5, top left corner) combines the Reynolds equation, half-space theory, energy equation and fluid models for viscosity. After iteratively solving the equations for required parameters with given boundary conditions, the film thickness and pressure distribution in the contact area will be achieved as the result of the simulation model (Figure 5, top right corner).

Apparently, mainly state variables as well as design parameters are exchanged, which constitute input and output parameters of the domain model. Besides these input and output parameters, however, also internal parameters are needed within the individual domain models. These internal parameters only exist inside domain models, where they can be changed in the model’s code, and cannot be accessed from outside. This leads to the challenge of possible inconsistencies between invisible instances of the same internal parameter in two different domain models, which is still a common problem in system modeling. This consideration leads to the conclusion that the model signature of a domain model should not only contain input and output parameters, but also internal parameters explicitly.

Another challenge are undefined spatial and temporal resolutions of parameters. If a parameter occurs in several domain models, these instances must be linked together (e.g., the dynamic viscosity between both domain models in Figure 5) and match in particular with respect to their spatial and temporal resolutions as well as admissible physical or operational regimes. While, e.g., the spatial dimensions (x, y and z) of the parameters have to match completely, a partial match of the regimes can be sufficient to execute two coupled domain models. As a final point, it can be stated that also properties resulting from the model building must be compatible to each other. For instance, the computation times of coupled models should be harmonized in order to guarantee an efficient execution.

While input and output relations can be represented in today’s SysML the admissibility regimes require a linguistic extension of SysML. This is also the case if regime compatibility at higher hierarchical levels is to be tested with the system element parameter concept building on this contribution.

Another important aspect for the model signature is the variability of parameters. Depending on the validation and design question, the developer may want to specifically keep individual parameters constant or allow them to change. Therefore, when integrating a domain model, it must be transparent whether the model keeps the individual parameters constant or varies them partially during the calculation. Hence, the model signature for domain models should explicitly contain the variability of the parameters in addition to the classification according to input, internal and output, dimensions, regimes and execution times.

5.2. Proposal of a Model Signature for Domain Models

From the requirements identified based on domain models (cf. Section 5.1), the following proposal of a domain model signature is derived comprising four constituents (Figure 6).

Among the input parameters all parameters are collected, which are needed as input for the specific calculation purpose of the domain model. Similarly, the output parameters are also specified, which are result of the calculation purpose of the particular domain model. In addition to the input and output parameters, the internal parameters are also included as a third constituent, which are characterized by the fact that they cannot be specified or read out externally of the domain model calculation.

The domain model signature specifies all input, output and internal parameters, concerning their name, dimension, data type, physical quantity and unit, spatial and temporal resolution as well as admissible regimes (Figure 6). Additionally, it is indicated whether the parameter is fixed or tunable inside the model. For example, it is defined that the domain model ‘Eyring, Barus, Vogel’ needs an input parameter ‘pressure’ with unit ‘Pa’, which is resolved in x and y direction as well as in time. This parameter is fixed since it is not changed or optimized inside this particular domain model. This fluid model is valid for moderate temperatures [50] and low pressures [49]. To fix the admissible regimes in the proposed model signature, temperatures up to 100 °C and pressures of 100 kPa to about 1 GPa are assumed as an example. The parameter specification (Figure 6, right) is a suggested notation that allows an algorithm-based evaluation of parameter compatibilities. For example, the unit Pascal is expressed via the exponents of the power product of the seven standardized SI units [51].

As a last parameter group, the domain model signature also contains the model parameters. These model parameters have no equivalent on the modeled system, but arise from the way the model is built. These include, for example, the computation time, time steps or termination criteria.

6. Discussion, Conclusion and Outlook

In this section, we discuss and summarize the results and provide an outlook for future research.

6.1. Discussion

Besides the advantage of an unambiguous and machine-readable description, the model signature also offers the possibility to evaluate the formal compatibility of domain models. The domain models considered in this example for the system element ‘lubricated rolling contact’ can be combined theoretically to 81 different model chains (Figure 4). This example is still idealized, such that in reality many more combinations can be expected. Of course, not all of the model chains can be technical coupled. Even with in-depth knowledge of the domain models, it is not possible to reliably and reproducibly filter out incompatible model chains without error and with acceptable effort. The proposed model signatures allow to easily and unambiguously determine whether the respective coupled parameters match in terms of dimensions, data type, unit, spatial and temporal resolution, and regime.

In order to reduce the set of possible model configurations to compatible ones with the proposed model signature, it makes sense to implement the model signature as an extension of SysML in a language profile. For example, the mechanisms of structural expressions in system modeling environments such as Cameo could be used to automatically evaluate compatible domain models [52].

6.2. Conclusions

In function-oriented model-based system development, executable domain models must be integrated into the SysML-based descriptive system model in order to virtually validate and design its system elements. Since all constituents of a system element are formalized via parameters, the challenge arises on the one hand of how to structure these parameters in order to connect them in a meaningful way with the domain models. At the same time, a large number of domain models exist for typical mechanical system elements, which are not documented in a standardized manner, and therefore, on the other hand, can only be integrated into the system element and coupled with each other in a effortful and failure-prone manner. Therefore, we proposed a parameter concept for system elements and a domain model signature, which are harmonized with each other and allow the integration and unambiguous coupling of domain models inside system elements.

The parameter concept for system elements distinguishes its parameters into design parameters that need to be defined by engineers or models, state variables that cannot be set directly be engineers and adjust themselves according to the laws of physics, as well as functional flows that enter and leave the system element representing operating and environmental conditions.

The proposed notion of model signatures specifies domain models concerning the following attributes. All input, internal and output parameters are defined by their respective name and their physical quantity. Furthermore, the physical is indicated by the power of the seven standardized SI units. The admissible regime is specified by a basically unrestricted set of constraints. Thus, several disjoint ranges of validity can also be expressed by minimum and maximum values or a formulaic relationship. Furthermore, the spatial and temporal resolution as well as the variability are provided. The latter categorizes whether the value of a parameter is fixed or tunable through changes or optimizations inside the domain model. The domain model signature additionally includes the model parameters as a final parameter group. These model parameters are a result of how the model is constructed rather than having an equivalent in the modeled system.

This unambiguous and machine-processable description allows domain models to be validly coupled with each other. In combination with the parameter concept, the domain models can read and calculate parameters of the system element according to the certain validation and design cases.

6.3. Outlook

In this article, we motivated the necessity of model signatures and investigated its realization based on a specific example. The conceptual approach, however, is not restricted to system elements representing the lubricated rolling contact in a gearing box, but can be generalized to other system elements. In order to further develop and establish the concept of model signatures, it will therefore be important to apply it to additional, typical system elements in the course of further research. In this context, it makes sense to extend SysML with a possibility to specify resolutions and regimes in order to formulate model signatures with this language in the future. In preparation for application, it is also necessary to develop algorithms for automated compatibility checking and coupling of domain models.

The proposed notion of model signatures also reminds of software structures used in multi-physics software systems, that choose an object-oriented approach, in which ‘model classes’ exist that encapsulate a certain process model to facilitate hierarchical modeling [53], or reproducibility [54]. A specific simulation is then an object of class model with certain parameters (constraining the physical regime) and certain underlying mathematical and numerical methods (that define spatiotemporal resolution). Such an object-oriented software structure also helps to orchestrate high-throughput simulations such as needed for model-based uncertainty management. Additionally, ontologies could provide a way to semantically express and make usable the information needed to select and link simulation models from a model building perspective [55,56]. Combing these closely related concepts will offer new pathways towards a conceptual integration of system models with high-fidelity simulation models.