1 Introduction

Fast, reliable, and uncomplicated digital collaboration is one of the prerequisites for innovation, as cyber-physical systems become ever more intricate and interconnected. Take the maritime industry as an example: Design, commissioning, assurance, and operation become more difficult with increased levels of complexity and integration of equipment and software from independent suppliers [1].

The main difficulty lies with predicting the combined behavior of entire systems, such as an offshore vessel during a demanding subsea operation. Naturally, system simulation becomes a valuable tool for studying and analyzing system behavior during all product phases, from early virtual design concepts all the way to decision support in operations.

1.1 Co-simulation as an enabler

Co-simulation [2, 3] is the concept of coupling independent stand-alone models for the purpose of building full-system models for simulation. Models communicate with each other only at discrete communication time points, between which they advance in time locally and independently.

In practical terms, co-simulation enables to build full-system simulations collaboratively in an efficient and flexible way using domain-specific tools and expertise. It thus opens the door for efficient reuse of modeling assets and knowledge across teams and organizations, while protecting IPRs thanks to a black box modeling approach. Computational speed-ups due to improved opportunities for parallelization and the possibility to distribute the simulation across computers and operating systems are highly relevant additional benefits. Several industries and research fields have recognized these advantages and have adopted co-simulation to varying degrees and with varying track records. For a closer look, refer to [4,5,6,7] and the comprehensive surveys on the state-of-the-art of co-simulation given by [8, 9].

1.2 Co-simulation in the maritime industry

Co-simulation has also gotten a hold in the maritime industry, which typically concerns itself with large and complex multi-domain simulations, such as operations of larger ships or oil rigs. Maritime system simulations are often constructed from many sub-system models and can span various phenomena on vastly different time scales. Consider, for example, wave dynamics (seconds) and electric components such as switchboard breakers (microseconds). In addition, a vast number of different equipment suppliers must be involved in the construction of a vessel, which makes it important to share models for collaborative virtual prototyping while protecting sensitive information and know-how. Because the resulting ships are often one-of-a-kind solutions built with a specific purpose and operational profile in mind, methods which facilitate the efficient reuse of existing domain models help speed up the design process significantly. Considering this, co-simulation is now considered an inevitably important part of the maritime industry’s evolution. Indeed, numerous maritime research and industry initiatives have been carried out over the past ten years or so with co-simulation as a key element [1, 3, 10,11,12,13].

1.3 Research gaps

While co-simulation solves many of the challenges related to constructing system simulations, connecting models developed by independent parties can be a difficult, tedious, and error-prone task due to different variable naming approaches and a lack of common semantics. This point is illustrated in Fig. 1a which depicts the typical workflow for integrating multiple third-party component models (the system integrator): Often, there is no or little indication for how to connect the component models. And once all connections are established, it is difficult to know whether the connections are correct and make sense physically.

Fig. 1
Fig. 1The alternative text for this image may have been generated using AI.
Full size image

Illustrative comparison of typical simplified workflows for assembling a full-system co-simulation from third-party component models without (a) and with (b) the proposed approach using OSP-IS. a Typically, there is little indication for how to set up the connections correctly, and the required manual communication, documentation, and coordination are not easily achieved in practice. More so, the potential for errors is high, and the process takes a long time. b Model developers create FMUs in isolation and use OspModelDescription.xml to describe the interfaces using semantic variable groups and language suited for their engineering discipline. This makes it much easier and faster for the system integrator to assemble the full-system simulation from the delivered component models by defining a OspSystemStrucure.xml simulation configuration, which can then be automatically validated, for example with the free OSP validation tool [14]. Note that the use of OSP-IS is not strictly required for all models

While tools like systems modeling language (SysML) [15, 16] and system structure and parameterization (SSP) [17, 18], further discussed in Sect. 2, aim to simplify the setup of system simulations, they do not address the issue of verifying that connections are correct. Research is needed to develop generic approaches for modular, stable, and accurate simulation coupling, as well as expressing the adaptations required to validate that the couplings are correct [9].

To further illustrate this point, consider a simple toy system consisting of three separate sub-systems: a mass, a spring, and a damper. In a collaborative modeling setting, each sub-system model may be delivered by separate parties as an functional mock-up unit (FMU) to be assembled into a full-system simulator, for example, to perform some analysis or to validate a design. As shown in Fig. 2, while it is easy enough to identify each model, it is not immediately clear how each variable should be connected. Even when documentation is available with each FMU, it is still possible to make mistakes when connecting variables. Moreover, connections that are fully compatible with the functional mock-up interface (FMI) standard [6, 19, 20] may not make physical sense, because the current validation process of simulation configurations using FMI only checks for correct data types for input and output variables. Thus, it is necessary to run simulations to verify if a configuration makes physical sense. For simple systems like the mass-spring-damper system, this may be feasible, but for more realistic and complex systems, it quickly becomes very challenging.

Here, we present a framework for describing and validating model interfaces with machine-readable metadata: The open simulation platform interface specification (OSP-IS) [21]. OSP-IS facilitates collaboration in the construction of system simulations and bridges the gap between model developers and model integrators and users by providing a way to share variable naming conventions and verify that connections make physical sense. The metadata used by OSP-IS is defined in an ontology, along with rules for signal connections. While FMI provides primitive types, OSP-IS provides types closer to the engineering domain (such as Force, Velocity, and Position) by grouping FMI variables semantically into VariableGroups. All of this is significant for multiple reasons:

  • It simplifies co-simulation configurations, especially for simulations of large and complex systems (such as a marine vessel).

  • It makes collaborative system modeling and simulation easier across teams and organizations.

  • It improves modularity by making it easier to swap a model for another with the same interface, but not necessarily the same connection variable names.

The present paper is organized as follows. First, we discuss related prior work in Sect. 2, before giving a detailed description of the OSP-IS ontology in Sect. 3. Section 4 presents a real case study from the maritime domain. Finally, we conclude the paper in Sect. 5.

2 Background

The work presented in this paper is based on results from the open simulation platform (OSP) [14], which began in 2019 in Norway with the collaboration of DNV, Kongsberg Maritime, SINTEF, and NTNU. In addition, 20 international academic and industry partners from the maritime and automotive industries participated in the OSP Joint Industry Project (JIP) to guide the research direction and provide feedback from usage. OSP provides open-source tools and working processes to enable collaborative system simulations based on co-simulation.

Fig. 2
Fig. 2The alternative text for this image may have been generated using AI.
Full size image

Illustrative example for individual input and output variables of three FMUs representing a spring, a mass, and a damper. There are several ways in which this simple system can be connected without breaking FMI connection rules, but there is only one that makes physical sense

Our work builds on an early version called marine systems model interface (MSMI), which is presented in [22]. Since then, we have further developed the specification and published it as OSP-IS [21]. We have also conducted several case studies including a study on digital twin modeling of ship power and propulsion systems [23] and a design study of a hybrid power system for a ferry [24]. Another case study is presented here in Sect. 4 to demonstrate the use of OSP-IS. All OSP project results, including OSP-IS, the ontology, a validation software tool, and more information on OSP case studies are available on the OSP website [14].

Before we present our work in more detail, let us provide some more context and background to set the stage.

2.1 Interface and configuration standards

First, let us briefly review the interface and configuration standards that are available for use with co-simulation.

2.1.1 Functional Mock-up Interface (FMI)

FMI [19, 20] is an open interface standard for model exchange and co-simulation which defines an API for binary compatibility across different simulation tools and programming languages. FMI provides a set of stringent definitions and declarations realized as a C header file and an XML schema containing model metadata. A model following the FMI standard is called a functional mock-up unit (FMU) and is a zipped folder containing platform-specific binary code adhering to the API and a platform-independent modelDescription.xml file describing its interface. The latest release as of today is FMI 3 which, among other improvements, adds support for array interface types and introduces Terminals that facilitate domain-specific connection rules.

Although FMI provides a standardized interface for model exchange and co-simulation, it only defines model interfaces based on primitive types and arbitrary user-defined variable names, without consideration for higher-level semantics. In practice, a semantically richer language closer to the engineering domain is needed to describe model interfaces in an unambiguous way, which is both human- and machine-readable. Some efforts have been made toward variable name standardization. For instance, [25] recognized the need for a common vocabulary within the automotive industry to formally categorize numerical models and their interfaces, and [7] proposed standardizing FMI variable names to enable automatic connections in the building industry.

However, naming conventions alone are insufficient for higher-level reasoning to check or enforce the validity of connections. There is a need for machine-readable rules to ensure the correctness of the connections between the variables, something that is not addressed by FMI.

2.1.2 Distributed Co-Simulation Protocol (DCP)

DCP is an application-level communication protocol for the integration of models or real-time systems into simulation environments [26]. It adds higher-level semantics for underlying transport protocols such as UDP, TCP, and CAN. Its intention is to make simulation-based workflows more efficient and reduce the effort needed for integration. The DCP is standardized by the Modelica Association, where it is maintained as a Modelica Association Project (MAP).

2.1.3 System Structure and Parameterization (SSP)

While FMI makes it possible to share individual simulation models between different simulation tools, SSP [17] enables sharing of entire simulation configurations (consisting of models, connections, and parameterizations) between tools. However, SSP does not provide any higher-level semantics for FMI’s variable types to allow for any physics-based reasoning with, and validation of, connections.

2.1.4 Daccosim NG

The Daccosim NG co-simulation environment [27] defines a declarative domain-specific language to support the definition of model outputs and inputs and references to, and connections between, model equations. This formal description can be used to generate compatible models to be executed in Daccosim NG and graphical representations of the interfacing. What it is missing, in contrast to the work presented here, is support for a hierarchical structure of variable definitions and groups.

2.1.5 Systems Modeling Language (SysML)

SysML is a language used in model-based systems engineering. It has been combined with FMI in the INTO-CPS project [28,29,30] to create tools for validating modelDescription. xml files according to specific rules defined in [31]. Although some researchers have proposed exploring an approach to group variables with domain-related interfaces [32], there is a lack of publications following through on this proposal. In addition, a recent state-of-the-art study on multi-domain simulations utilizing SysML [16] has shown that FMI support is still limited.

2.2 Ontology in modeling

The literature suggests that ontologies can be used to enrich models and interfaces with verifiable and machine-readable semantic information:

  • Ontologies have been proposed as a solution to address the problem of mismatching units for signal connections of the same physical quantity [33], albeit not intended for the interfacing of simulation models.

  • The framework for adaptive modeling and ontology-driven simulations (FAMOS) [34] explores ontologies as a way to ensure syntactic and semantic correctness when composing high-level system simulations from (not physics-based) components developed by independent groups.

  • An ontology-based method for searching for candidate models during system simulator construction is presented in [35], including checking for matching FMI variables and units.

  • Three ontologies are proposed in [36] for the purpose of large-scale interdisciplinary co-simulations of energy systems, one of which is an FMI-based specification of variables.

  • A model ontology methodology for the building industry is introduced in [37], which defines the model type together with the required FMI variables.

  • A model interface ontology for biophysical agricultural models is discussed in [38] in the context of environmental modeling.

  • Data management issues for digital twins based on system simulations are treated in [39] by means of an ontology of physics-based building blocks (such as “a damper”).

However, these proposals are either domain-specific or do not deal with variable matching beyond units and binary compatibility. Moreover, they focus more on minimizing the number of candidate components during system modeling, and regard the practical problem of model interfacing as a secondary issue at best. A common, domain-independent approach for validating connections between sub-system models of system simulations is still missing.

One attempt at addressing this gap is the PHYSYS ontology [40, 41], which is a library of reusable engineering components with rule-sets for their connections based on bond graph theory. Bond graph concepts are also used in [42, 43] where the definition of a Port is extended to the location of an (intended) exchange of matter, energy or information.

2.3 Component-based and service-based development research

Finally, let us comment on similarities and distinguishing features between the present work and research outside of the simulation domain.

An ontology is used in [44] to facilitate the integration of physical products for collaborative product development and design. The conceptual design of systems with an emphasis on system architecture, the configuration of sub-systems, and the interactions between them is discussed in [45], also using an ontology. Both approaches are quite similar in spirit to OSP-IS, albeit for the physical domain and with a focus on product development and design. Another similar approach is discussed in [46] where an ontology of software components is proposed for contract verification and to help ensure that software components are functionally compatible. An ontology is also used in [47] for describing component-based services and ensuring compatibility on the software level. For co-simulation, such binary compatibility is already ensured by the FMI standard, see Sec. 2.1.1, while the focus of OSP-IS is on the compatibility of signals.

Type annotation is used in [48] for capturing physical units to make signals interoperable. Compatibility of units is an important part of the model interfacing task. But by itself, it is insufficient, which is why OSP-IS also provides multi-ports and signal groups to ensure physical compatibility and automatic validation. Note also that signals can be incompatible despite having matching units (for example, with respect to dimensionality or different reference frames).

Another approach is the use of contracts and compatibility guarantees. A comprehensive software engineering framework that supports software composition at design time and runtime with compatibility guarantees is presented in [49]. It combines UML modeling and ontology techniques, but with a focus on the specification of component properties, their validation, and their transformation to code.

2.4 Scope and contribution

The OSP-IS presented here expands on ideas put forth in [40,41,42,43] to develop a domain-independent interface standard for the coupling of simulation models that allows to validate whether they are physically correct. It defines variable groups with assigned types in an ontology for simulation model signals with definitions for physical quantities and units, along with rules for connections. Before we dive into the details on the technical implementation in Sect. 3, let us briefly revisit the example introduced in Sect. 1.3 to illustrate how this works in practice.

Fig. 3
Fig. 3The alternative text for this image may have been generated using AI.
Full size image

Illustration of the example encountered in Fig. 2 when using OSP-IS to describe the model interfaces. The spring FMU has all its variables grouped into a LinearMechanicalQuasiPort (a Force-Position pair), the damper FMU has all its variables grouped into a LinearMechanicalPort (a Force-Velocity pair), and the mass FMU has its variables grouped into one LinearMechanicalQuasiPort and one LinearMechanicalPort. There is now only one valid way to connect this specific (but admittedly simplistic) system. A realistic case study is shown in Sect. 4

Table 1 Structure of the variables and variable groups for each model used as illustrated by Figs. 2 and 3
Full size table

Using OSP-IS to describe the model interfaces greatly simplifies the task of interpreting and making the correct connections as exemplified by Fig. 3 and Table 1. Each model now represents its input and output variables using appropriate variable group types: One LinearMechanicalQuasiPort containing one Force variable group and one Position variable group is used to couple the spring simulator with the mass simulator, and one LinearMechanicalPort containing one Force variable group and one Velocity variable group is used to couple the damper simulator with the mass simulator. Because OSP-IS demands that only variable groups of the same type can be connected, there is only one valid way to connect this specific and, admittedly, rather simple system. For more realistic cases, OSP-IS allows the use of a validator to produce high-level error messages that simplify the process of tracking down and fixing any connection errors. One such validator is available on the OSP website [14].

It is important to emphasize that the approach laid out here is by no means meant to be complete or unique. Our aim is to provide a useful method to help interfacing simulation models for maritime co-simulation. We encourage the reader to contribute to the further development of the openly available OSP-IS tools and processes, or to define their own variable groups and ontologies based on what they may deem useful with our approach.

3 Technical implementation

Let us now describe the OSP-IS in more detail and explore its key components: First, we will introduce an ontology which defines a set of variable group types, and rules for variable group connections, using the Web Ontology Language (OWL) [50]. Next, we discuss how the OspModelDescription.xsd schema defines the structure of the OspModelDescription.xml files used to relate model FMI variables to the ontology’s variable group types. Lastly, we will briefly show how a dedicated configuration file, OspSystemStructure.xml, can be implemented to describe a given co-simulation configuration.

3.1 OSP-IS ontology

The OSP-IS ontology is implemented using OWL with an open world assumption, the \(\mathcal {SHOIQ}\) Description Logic, and SWRL rules. Its main building blocks are:

Class::

A representation of a specific concept (e.g., Human).

Individual::

A specific instance belonging to one or more classes (Alice and Bob belong to the class Human).

Object property::

A specific relation between individuals (Spouse relates Alice and Bob).

An ontology contains statements (axioms) about classes, individuals, and object properties. These can be constructed using a subset of the operators defined in description logic and enable reasoning to be performed. Validation, for example, is a type of reasoning that verifies that all of the stated axioms are logically consistent, and classification is the process of inferring axioms from others (if \(A \implies B\) and \(B \implies C\) then \(A \implies C\)).

3.1.1 Ontology design

One way of designing an ontology is such that it will become logically inconsistent if a simulation configuration is wrong according to the specification. Logical inconsistency explanations are time-consuming to calculate, however, and the generated explanation in description logic syntax is cumbersome to parse into useful user error messages. We therefore decided on a different approach that demands that the OSP-IS ontology should always be logically consistent and which instead uses classification to identify errors. This has at least three benefits:

  1. 1.

    Checking an invalid simulation configuration is faster (because classification is faster than validation).

  2. 2.

    We can define explicit and useful error messages to display to the user.

  3. 3.

    Simulation configuration errors can easily be distinguished from errors on how the ontology is populated. If the ontology ever does become inconsistent, it means that there are flaws in the validator implementation.

Classification is used in the OSP-IS ontology to generate inferred axioms stating that invalid individuals belong to specific predefined error classes. For example, if two variables,

  • x1 is a Variable,

  • x2 is a Variable,

are assigned different Datatypes,

  • real is a Datatype,

  • string is a Datatype,

  • x1 hasDatatype real,

  • x2 hasDatatype string,

and then connected,

  • vc is a VariableConnection,

  • vc hasVariable1 x1,

  • vc hasVariable2 x2,

classification allows to infer that the vc VariableConnection individual belongs to the VariableConnectionDatatypeError class. The ontology can then, in general, be queried to return all individuals belonging to the VariableConnectionDatatypeError class containing all VariableConnection individuals where hasVariable1.Datatype != hasVariable2.Datatype. Classifications such as this one make it possible to generate meaningful error messages.

3.1.2 Ontology definitions

The OSP-IS ontology defines available variable group types, the validation rules for their structure, and the rules for valid connections. A variable group connection is defined as valid if it is between two variable groups of the same type and if all of the resulting individual variable connections adhere to the following:

  1. 1.

    Variables must have opposite causality.

  2. 2.

    Variables must have the same data type.

  3. 3.

    Variable base units must be identical.

The OSP-IS ontology also contains classes needed to describe co-simulation configurations built from individual models. This means that given a simulation configuration described in some format, a tool can be developed which populates the OSP-IS ontology with individuals representing variables, variable groups, and connections according to the rules defined by the OSP-IS. Because the ontology is designed in such a way that all individuals that violate any of the rules will be assigned appropriate error classes during classification, it can then be queried for individual-based errors to produce meaningful error messages. An example of this could be “Variable group of type LinearMechanicalPort cannot be connected to variable group of type LinearMechanicalQuasiPort”. Figure 4 shows the defined validation error classes and their hierarchical structure. Note that the validations shown in this figure could also be implemented via simple constraint checks or type annotations without the need for ontologies. The ontology makes these checks come automatically, however, in addition to also allowing for hierarchies of variable groups (e.g., variable groups of variable groups).

Fig. 4
Fig. 4The alternative text for this image may have been generated using AI.
Full size image

Hierarchical structure of the validation error classes defined in the OSP-IS ontology

There are currently 51 variable groups defined in OSP-IS. While it is not feasible to describe them all here, we provide descriptions for the ones we use in the examples in Table 2. More details and descriptions of the remaining variable group types are available in the OSP-IS documentation [21].

Table 2 Description of the variable groups defined in OSP-IS which are used in this paper.
Full size table

3.1.3 Populating the ontology

Figures 5, 6, 7, 8, 9 and 10 illustrate how the OSP-IS ontology is structured and how a validator populates it with specific simulation configuration information. All of these figures use the following symbols:

  • is a class defined by OSP-IS.

  • is an object property defined by OSP-IS.

  • is an individual defined by OSP-IS.

  • is an individual populated by a validator tool at runtime and related to existing individuals and classes using predefined object properties.

The relationships between individuals and classes is defined by object properties, and if there are no object properties between classes and individuals the relationship is a standard is-a relationship.

Fig. 5
Fig. 5The alternative text for this image may have been generated using AI.
Full size image

Illustration showing how a Variable is defined by the OSP-IS ontology. A variable must have a Causality (input or output), a Datatype (real, integer, Boolean, string or enum), and a Unit

Figure 5 shows how a Variable is defined by the OSP-IS ontology with predefined Causality and Datatype individuals. A new Variable individual must be related to one of the causality individuals and one of the data type individuals through the has object property. The validation tool must also define Unit individuals according to the rules defined by OSP-IS and relate them to the variable individuals via has object properties.

Fig. 6
Fig. 6The alternative text for this image may have been generated using AI.
Full size image

Example of how a validation tool would populate the OSP-IS ontology with a specific variable. The variable individual my variable is established with a is-a relationship to the Variable class. Its data type is defined by relating it to the Real Datatype individual through the is type object property. Its causality is defined by relating it to the Input Causality individual through the has causality object property. Finally, its unit is defined by relating it to the [m/s] individual, itself assigned an is-a relationship with the Unit class, through the has unit object property

Figure 6 illustrates how the OSP-IS ontology is populated with a Variable individual. First, the individuals my variable and [m/s] are created (here, [m/s] exemplifies the use of units of velocity in meters per second). Then, my variable is assigned an is-a relationship with the Variable class; related to a predefined data type individual through the is type object property; related to a predefined causality individual through the has causality object property; and finally related to the [m/s] individual through the has unit object property. The unit individual [m/s] is assigned an is-a relationship with the Unit class.

Fig. 7
Fig. 7The alternative text for this image may have been generated using AI.
Full size image

Example of how a validation tool would populate the OSP-IS ontology with a specific variable connection. The variable connection individual represents the connection between the variables v1 and v2, by first establishing a is-a relationship to the Variable Connection class, and then relate to each of the variable individuals through the has variable object property

Populating the OSP-IS ontology with a variable connection is illustrated by Fig. 7. The individual variable connection is created to represent a connection and assigned an is-a relationship to the Variable Connection class. To complete the connection, the individual must be related to the connected variable individuals v1 and v2 through the has variable object property.

Fig. 8
Fig. 8The alternative text for this image may have been generated using AI.
Full size image

Illustration of variable group types defined in OSP-IS. All the available variable group types are defined in the OSP-IS ontology as predefined individuals which have a is-a relationship with the Variable Group Type class

Figure 8 shows how OSP-IS structures the definition of variable group types. The class Variable Group Types predefines individuals to represent each specific type. Note that the figure only shows a subset of variable groups defined by OSP-IS.

Fig. 9
Fig. 9The alternative text for this image may have been generated using AI.
Full size image

Example of how a validation tool would populate the OSP-IS ontology with a specific variable group. The my variable group individual is first created and assigned a is-a relationship to the Variable Group class. Its type is defined by relating it to the predefined Force variable group type individual through the is type object property. The variables contained in the variable group is defined by relating the variable group individual to the variable individuals through the has variable object property

The structure required to populate the ontology with individuals representing a specific variable group is shown in Fig. 9. First, an individual my variable group must be created to represent the specific variable group and assigned an is-a relationship with the Variable Group class. Next, the type of the variable group is assigned by relating it to a predefined Variable Group Type individual through the is type object property. Lastly, the variable group individual must relate to the variable individuals contained within the variable group through the has variable object property.

Fig. 10
Fig. 10The alternative text for this image may have been generated using AI.
Full size image

Example of how a validation tool would populate the OSP-IS ontology with a specific variable group connection. The variable group connection individual represents the connection between the variable groups vg1 and vg2, by first establishing a is-a relationship to the Variable Group Connection class, and then relate to each of the variable group individuals through the has variable group object property

Variable group connections are defined analogous to variable connections: The individual representing the connection has an is-a relationship with the Variable Group Connection class and relates to the connected variable groups through the has variable group object property, as illustrated by Fig. 10.

3.2 OSP model description

An FMU is made compliant with OSP-IS by creating an OspModelDescription.xml file according to the OspModelDescription.xsd XML-schema [14]. For any given FMU, the OspModelDescription.xml file groups and relates variables in the FMU’s modelDescription.xml to types defined in the OSP-IS ontology. It is also possible to define variable units according to FMI 2.0 unit definitions, with the addition of percent as a base unit.

Listing 1 shows an example of an OspModelDescription.xml file. The root element is , which in turn contains one and one element. Each element contained under represents a variable group type as defined in the OSP-IS ontology. The XML schema validates the structure of each variable group type, while the ontology validates more complex rules not suitable for XSD validation.

The example in Listing 1 defines a variable group. It, in turn, consists of a and a variable group, each of which contains two variables. The attribute in each element must match exactly with the corresponding variable name in the FMUs modelDescription.xml file. This is how FMI variables are tied to, and grouped with, OSP-IS types. The attribute in each element refers to the attribute of the corresponding element defined under . The latter, in turn, are specified as the exponents of the corresponding SI base units defined by FMI (e.g., for meter per second).

figure yThe alternative text for this image may have been generated using AI.

Table 3 lists the three different variable groups used in Listing 1, with a description of what is validated by the XML-schema and what is validated by the rules in the ontology. A similar description of all OSP-IS variable groups can be found in the OSP-IS specification [21].

Table 3 Three different exemplary variable groups are validated by the XSD and the OSP-IS ontology
Full size table

3.3 OSP system structure

Aside from the OSP-IS, the OSP project also maintains the libcosim C++ co-simulation software library. This tool requires a system configuration file named OspSystemStructure.xml. Listing 2 illustrates how a co-simulation can be configured using this approach using local OspModelDescription.xml files. It defines all the simulators (under ) and their connections (under ) that make up this specific co-simulation configuration. As shown, both single variable connections and variable group connections can be used. All variable groups referred to in any variable group connection (using ) must be defined in an OspModelDescription.xml file and provided with the FMU of the corresponding simulator instance.

figure apThe alternative text for this image may have been generated using AI.

3.4 The workflow

Figure 1b illustrates a typical workflow for model developers and system integrators when using OSP-IS and the tools developed in the OSP project. Based on a specification from a system integrator, model developers can work independently of each other on their own models using domain-specific tools and modeling techniques best suited for the case at hand. The system integrator receives the separate models as FMUs, connects them together in a simulation tool, runs the simulation, and interprets the results.

By adopting OSP-IS, the system integrator and the model developers can use a shared vocabulary closer to the engineering domain. This makes communication much more efficient and reduces misunderstandings and confusion. In addition, the process of connecting the individual models is much simpler when using variable groups, because the number of connections to be handled on the interface level can be reduced substantially. Central to the communications and the workflow are the OspModelDescription.xml files provided with each model by the model developers to define the appropriate semantic variable groups of a model’s interface. The system integrator can even share a pre-populated OspModelDescription.xml file with a model developer up front to order a model with a desired semantic interface. Lastly, the system integrator can also feel more confident that the resulting co-simulation configuration is correct because of the added validation functionality provided by OSP-IS. Note also that it is not required for all parties to adhere to the OSP-IS. It is fully possible to include models that do not, in part or at all, at the expense of abandoning some of the outlined benefits.

Fig. 11
Fig. 11The alternative text for this image may have been generated using AI.
Full size image

Illustration of the DP case without using variable groups. White boxes denote FMUs responsible for converting and transmitting data between the simulation and the DP controller, while gray boxes denote sub-system model FMUs. Arrows indicate the computational causality (pointing from an output to a corresponding input). The dashed box contains the variables required to describe the NMEA messages. Note that there are three thruster models each with their own variable group connections, as indicated by the annotation “x3.” Naming of each individual connection is omitted to avoid clutter

Fig. 12
Fig. 12The alternative text for this image may have been generated using AI.
Full size image

Illustration of the DP case with the use of variable groups. White boxes denote FMUs responsible for converting and transmitting data between the simulation and the DP controller, while gray boxes denote sub-system model FMUs. Thick arrows represent variable group connections, and the thin arrow a single variable connection. Note that there are three thruster models each with their own variable group connections, as indicated by the annotation “x3”

4 Case study: dynamic positioning

Let us now move on to a real maritime case study from the OSP joint industry project [14] conducted by several partners from research and industry in a collaborative modeling environment. Our aim is to demonstrate the central advantages of the approach proposed in Sect. 3:

  1. 1.

    Grouping FMI interface variables into semantic types offers clear and efficient communication between model developers and system (simulation) integrators (either by using the variable groups already defined by OSP-IS directly, or by defining custom groups as needed).

  2. 2.

    The risk for errors during the interfacing process is greatly reduced by validating the entire system simulation via ontology classification, as explained in Sect. 3.1.

  3. 3.

    The interface complexity is greatly reduced by decreasing the number of connections that need to be handled during integration (via variable grouping).

The case presented here is, in our experience, representative of the interfacing-related problems that typically arise in real-world settings. One vendor’s commercial dynamic positioning (DP) hardware controller is connected to a full-system simulation consisting of hull, environment, thruster, and sensor models, each developed by different companies. The purpose of a DP controller is to hold a ship’s position and heading, or to follow a specific track (possibly with fixed heading) at low speeds. DP controllers are prime examples of maritime control systems and have been subject to simulation-based testing for several years.

Interfacing a simulator and a DP system can be an exhausting task because of the relatively high complexity in dealing with hundreds of inputs and outputs, as witnessed by the authors’ first-hand experience. First, one must get a complete overview of all the signals that need to be simulated, and then each of these must be matched with the corresponding DP controller signal. This process is typically based on composing and decomposing messages from the simulator and DP controller signals according to some protocol. Then, the configuration is verified by observing that each signal sent either way between the simulator and the DP controller is received at the correct address (or variable) and with the correct value. As of today, this is a purely manual process.

The models are all implemented as FMUs with accompanying OspModelDescription.xml files to add semantic meaning and groupings to the model interfaces. This greatly reduces the number of connections to handle; provides all parties with a common and easy-to-interpret language for interfacing; and enables the validation of the entire final system configuration.

Because the DP control system is running on actual production hardware, connecting it to the rest of the simulation requires some form of network communication orchestrated in a way that makes the control system agnostic to whether it is interacting with the real World or a simulation. In our case study, the DP controller uses an NMEA protocol over UDP. OSP-IS provides variable groups which can readily be used to represent all the NMEA messages required and enable simplified communications between the hardware and the relevant simulation models.

Figures 11 and 12 illustrate the structure of the full-system simulation without and with the use of variable groups, respectively. Note that some elements and connections have been omitted to better facilitate the present discussion.Footnote 1 As is immediately evident, the number of connections is drastically reduced when using variable groups: While there are a total of 156 variables in 78 connections in Fig. 11, Fig. 12 offers a total of 36 variable groups plus 2 variables in 19 connections. In addition, the only form of automatic validation that can be performed for the configuration without variable groups is the somewhat primitive validation given by FMI (checking for matching data types), while each variable group connection adds the benefit of automatic validation. For example, the NmeaMwv variable group in the Wind Sensor FMU in Fig. 12 can only be connected to exactly one other FMU in the configuration: The one which also has an NmeaMwv variable group. Connections to any other variable group types by mistake will be caught by the validator and produce a meaningful error message, such as “Variable group of type NmeaMwv can not be connected with variable group of type NmeaGst.”

But the benefits to the approach are not purely technical: Understanding a simulator with all its individual models and connections is much more cumbersome when given in a form such as in Fig. 11. This greatly increases the probability for interfacing mistakes and, together with a lack of validation, reduces the confidence that a given configuration is correct and, consequently, produces correct results. By contrast, a short glance at Fig. 12 provides a clear overview of how all sub-simulators are connected. Users obtain increased confidence in the system configuration by virtue of the validator, which checks that all variable groups are connected correctly.

5 Conclusion and outlook

In this paper, we demonstrated how the task of interfacing different sub-simulators in a co-simulation can be greatly simplified by enriching the individual FMUs with semantics close to the relevant engineering domains, formalized as an ontology. Enabling the grouping of FMI interface variables into semantic types provides several benefits: clearer communication, increased validation potential, and reduced number of connections to be handled. Our solution consists of the OSP-IS specification document, an OWL ontology defining the semantics used for validation, and OspModelDescription.xml files used to link individual models’ FMI variables to semantics in the OSP-IS ontology. Additionally, the open simulation platform project [14] has developed a reference implementation of a validator which can validate co-simulation models and simulation configurations using OspSystemStructure.xml and variable group connections. This package is openly available and provides a concrete solution to anyone seeking easier and more reliable interfacing of co-simulation models. In addition to variable group types, the ontology also defines validation error classes. Individuals in the ontology will be classified to belong to these error classes during classification, if the simulation configuration contains any errors. The ontology can then be queried for all individuals classified in a given error class in order to produce meaningful error messages to the user.

The application of OSP-IS to a real case study was discussed in which a DP hardware control system is interfaced with a simulated vessel consisting of models developed by different parties independently. We demonstrated the challenges in connecting all interface signals correctly and showed how OSP-IS greatly reduces the complexities and the error potential.

Because our primary focus lies with the maritime domain, from which the need for a more robust and efficient simulation model interfacing solution emerged, we cannot comment on the validity of the approach as applied to other domains and problems. We do believe, however, that the proposed solution will be applicable to the integration of FMUs for the purpose of full-system co-simulations regardless of domain, either directly or by adapting it to specific needs. Such adaption could, for example, be done by supplying any missing variable groups.

Even though we regard the present work as an important step toward faster, easier, and more reliable collaborative modeling and simulation, some research challenges still lie ahead:

  • How do we define interfaces for including environmental conditions into co-simulations? In the maritime domain, waves, wind, and currents act on the simulated objects. Simulating several floating bodies in the same co-simulation requires a common way to describe such an environment.

  • How do we handle signal algebra and quasi-instantaneous phenomena between models in a co-simulation? FMI poses a restriction here because all variables must be defined before compilation. This can be an issue for the summation of an arbitrary number of forces acting on the same rigid body, for example. In many cases, it is impossible to predict up front how many inputs and outputs a model needs, especially when it is used together with other models and across different use cases. This problem is pointed out in [37], where one-to-many connections are suggested as a solution. The libcosim tool developed in the OSP project has implemented three special connection types, called functions, to perform simple transformations between otherwise incompatible FMU variables: Sum, Vector Sum and Linear Transformation. These functions are placed between variable or variable group connections to perform calculations between co-simulation time steps. OSP-IS does not yet support these functions in the ontology, but will in future versions.

  • How do we standardize different coordinate systems across models to reduce the potential for mistakes and to speed up the interfacing process? If done properly, automatic conversions between coordinate systems are also feasible. This is an important point with respect to the co-simulation interface challenge: For example, two LinearMechanicalPort variable groups are currently compatible according to OSP-IS, even if their respective Force and Velocity components are given in different coordinate systems, rendering the connection physically invalid.