Collaborative Model-Based Systems Engineering Using Dataspaces and SysML v2

Abstract

Collaborative Model-based Systems Engineering between companies is becoming increasingly important. The utilization of the modeling possibilities of the standard language SysML v2 and the multilateral data exchange via Dataspaces open new possibilities for efficient collaboration. Based on systemic approaches, a modeling concept for decomposing the system into sub-systems is developed as a basis for the exchange. In addition, based on the analysis of collaboration processes in the context of Systems Engineering, an architectural approach with a SysML editor and Dataspace for the exchange is elaborated. The architecture is implemented on the basis of open-source solutions. The investigations are based on an application example from precision engineering. The potential and challenges are discussed.

1. Introduction and Motivation

Product development faces many challenges, such as increasing individualized stakeholder demands, rapid technological evolution, regulatory compliance, etc. An important challenge is the increased and growing focus on the realization of needs-oriented solutions [1,2]. The dynamic nature of these challenges leads to a further increase in product complexity (e.g., transition from primary mechanical to mechatronic to cyber-physical systems [3,4]), as well as demands on quality, reliability, safety, etc. [5]. In order to fulfill these requirements, valid product information is needed from all phases of the product life cycle [6,7].

Due to different boundary conditions (e.g., knowledge in the companies, specializations, capacity utilization, global sales, etc.), many products are developed and finally also produced with partners across companies [8,9,10,11,12]. One company assumes overall responsibility and distributes the entire product. This company is usually referred to as the OEM [13]. The OEM defines the scope of what suppliers need to deliver. The share of suppliers in the products varies depending on the industry sector. Surveys show a share of around 50 to 78% [14]. The suppliers are given different requirements and boundary conditions for the development of the scope of supply. To enable the OEM to evaluate the supplier’s development results in the context of the overall product and make any necessary modifications to the overall product or to the requirements of the scope of supply, it is increasingly necessary to hand over not only the product specific to the scope of supply, including the necessary verification results, but also its specification, among other things [15,16].

The development of complex mechatronic products is increasingly supported by model-based approaches [17]. The approaches range from semi-formal models, including the associated tools, to formal models for the detailed specification and the simulation of products to determine specific properties [18]. Semi-formal models play a decisive role in the early development phases in particular, as essential information for the specification is not yet available with a sufficient degree of maturity, several variants have to be described and analyzed, and numerous changes and iteration loops are necessary due to increasing knowledge during development [19]. In this context, the term Model-Based Systems Engineering (MBSE) is used. Complex mechatronic products can be described for development and specification using systems theory approaches [20,21]. One of the approaches to systems theory is that systems (hereafter referred to as the overall system) can be decomposed into several sub-systems (see Figure 1), and the overall system itself can be a sub-system of superordinate systems. The decomposition of the overall system into sub-systems is basically arbitrary [22]. The decomposition is often based on functional or organizational aspects [23], for example, in combination with the distribution of development to different suppliers. In the case of complex mechatronic products, decomposition often results in several system levels with mechatronic sub-systems. The SysML modeling language has become established for the semi-formal modeling of the overall system and the mechatronic sub-systems in MBSE [7,24,25].

During development, it is important to note that SysML tools alone are not sufficient to comprehensively specify and analyze the product. Against this background, several solutions already exist today for linking SysML models with requirements, detailed formal specification models (e.g., CAD models [26] or software models [27]), or simulation models [28,29] in order to create a consistent and traceable overall description [30]. In this contribution, the focus is on SysML models.

During product development, numerous decisions must be made to detail the product. These decisions require information on the current product, including its requirements or specifications, as well as existing knowledge [31] and findings from verification and validation [32]. Product information is often distributed across partners due to collaboration with suppliers [15]. In order for the individual partners to be able to carry out their development in a target-oriented manner, the relevant information and its relationships must be available to the partners. Various aspects must be considered for Collaborative Model-Based Systems Engineering (CMBSE); some relevant aspects are as follows:

• OEMs and suppliers need means to exchange their model-based descriptions of the requirements in connection with the defined division of tasks and responsibilities as well as solution descriptions in a version-consistent form [15].
• Product development, especially in a network with partners, is highly dynamic, as new findings, e.g., from verification and validation [32], can lead to new decisions. This requires the information and its relationships to be updated, which leads to new versions of the models. For efficient CMBSE, the new versions of the models must be exchanged with the partners.
• The information in product development is highly sensitive [33]. Against this background, the partners must decide selectively and comprehensibly who receives which information and for what purpose.

Against the background of the needs discussed above, this contribution discusses an approach to supporting CMBSE. The following two technologies are used:

• Modeling in the context of MBSE is performed using the standardized language SysML version v2 [34].
• Dynamic data exchange between the partners are discussed with the utilization of a Dataspace [35].

Using an example collaboration process (based on the Prostep ivip recommendation [15]) and a prototypical implementation of the CMBSE with SysML v2 and a Dataspace, the current possibilities and open challenges will be discussed in order to overcome the limitations of the current CMBSE (see Section 2). The authors of the contribution are aware that, despite the desire for consistent Model-Based Systems Engineering, not all information is currently available in a model-based form. For the objectives of this contribution, however, it is assumed that the information is validly represented in the models to a sufficient extent. In addition to the approaches presented in this contribution, further information must be transferred via additional documents or something similar.

The following research questions are relevant to this contribution:

• How can CMBSE be implemented efficiently using SysML v2 and Dataspaces? Details of the main research questions are provided in the following sub-questions.
  • How do development partners need to structure the system models in SysML v2 for CMBSE?
  • How can the necessary SysML v2 models be exchanged using Dataspaces?
  • How should a collaborative development process be designed?
• What future developments in the context of SysML v2 and Dataspaces are necessary to support the CMBSE in a targeted manner?

2. State of the Art

2.1. Systems Modeling Using SysML

The extension of Systems Engineering methods and processes with models is called Model-Based Systems Engineering (MBSE) [36]. The most widely used modeling language in MBSE is the Systems Modeling Language (SysML) [24,37]. SysML is a semi-formal graphical modeling language [38] for modeling the product at the mechatronic system levels as well as the system context (where the requirements, use cases, and scenarios of the stakeholders and the surrounding systems, including the required interfaces, are described) [2,39,40] or the System of Systems [25,41]. Diagrams (views of the system model elements) are used for the definition of model elements as well as for the use of model elements in further development steps, allowing context- and task-specific further use of model elements [24,42].

Semi-formal modeling offers a certain degree of freedom in modeling. For data exchange with binding requirements, however, sufficient formalization via at least modeling guidelines are necessary [39,43,44,45].

SysML v2 is the latest version of the System Modeling Language, which addresses the limitations of SysML v1.x [46]. In contrast to SysML v1.x, SysML v2 includes not only the graphical notation but also textual notation, which is a different presentation of the same underlying model syntax. SysML v2 provides a more formal specification of its abstract syntax, concrete syntax and semantics, and mappings between them, which improve the language’s precision and integrity [34].

In system modeling with SysML (both v1.x and v2), the package is used as a container for other elements to organize the model. To realize the reusability of modeling elements in SysML v2, the model elements are divided into two important parts: definition and usage. In general, a definition package contains different definition elements that classify different types of elements, while usage elements can be stored in different packages to describe the usage of a definition in a specific context [47]. Moreover, existing knowledge, such as standard, generic context, or specific [48] terminology, can be stored in packages and imported by other packages for reuse.

SysML v2 contains the modeling language and standard API, but in this contribution only the modeling language will be discussed.

2.2. Collaboration in Engineering

In complex development projects, a targeted division of work is an essential approach for achieving goals efficiently and effectively utilizing resources and complementary skills [11]. Among other things, economic, geographical, and technical boundary conditions increasingly require collaboration between companies. The process of collaboration is very complex, as not only the tasks and responsibilities but also the information relevant to the collaboration must be exchanged between companies [10]. In addition to the organizational and technical challenges, there are also human, legal, cultural, and other challenges that cannot be discussed in this article [49].

A major organizational challenge is the synchronization of development activities [50]. While documents in particular have played a role in collaboration for a long time, collaboration processes using models are becoming increasingly important in the context of digitalization. The use of models creates the potential for collaborative development processes to be increasingly synchronized as relevant, up-to-date information can be exchanged. However, synchronization based on models or model artifacts requires coordinated configuration management [51,52].

Since models always involve a degree of formalization, content and formal modeling definitions for the models must always be coordinated in addition to the product or project information [53,54]. The definitions can include, for example, the specification of units, the use of specific model elements, or terminology.

Product Data Management (PDM), Product Lifecycle Management (PLM) [55,56], or System Lifecycle Management tools [57] have already been established for managing heterogeneous models, including the necessary configuration management within companies [58]. PLM tools support the processes within companies that are represented in the tools with sufficient formalization. Depending on the company, these are highly formalized (especially in larger companies) or less formalized (in smaller and medium-sized companies) [59]. However, it can be seen that the processes are developed differently in several companies. This is a major challenge when using PLM tools for cross-company collaboration. The potential and challenges of cross-company collaboration using PLM tools are discussed in the work of Messaadia [60] and Tilioua [61], among others. Software-as-a-Service (SaaS) PLM approaches are discussed as a new technology [62].

In recent years, the concept of Dataspaces [35] have been developed for targeted, secure, and trustworthy data exchange, which will be examined for the CMBSE in this contribution and is therefore presented in the next section.

2.3. Dataspaces

Nowadays, Dataspaces are instrumental in fostering collaborative data exchange among multiple organizations [63]. The concept of Dataspace was initially introduced as a framework for managing diverse yet interconnected data sources, aimed at facilitating the coexistence of heterogeneous data while avoiding complete data control [64]. Numerous research efforts have further supported the services within Dataspace, such as data modeling [65], data integration [66], data dependences [67], and querying in context [68]. There are different definitions of Dataspaces [69,70,71]. According to the initiatives of the European Data Strategy [72], key objectives addressed by Dataspaces include data exchange, data interoperability, and data sovereignty. Data exchange refers to the use and reuse of data among different entities. Interoperability primarily focuses on applying standards and sharing compatible formats or protocols for data from diverse sources. Data sovereignty involves ensuring entities have control over data, including the rights to collect, store, share, and allow others to use the data [70,73]. The European Commission further elaborated on the key features of the Common European Data Spaces, such as data protection and governance, in a staff working document on Dataspace [74]. This article will adopt the definition provided by the Data Spaces Support Centre (DSSC) [72], as follows:

“A distributed system defined by a governance framework that enables secure and trustworthy data transactions between participants while supporting trust and data sovereignty. A data space is implemented by one or more infrastructures and enables one or more use cases”.

Many Dataspaces are currently under development, and associated use cases are being implemented in various fields with different levels of maturity. This includes sectors such as agriculture, automotive, manufacturing, energy, logistics, smart cities, supply chains, and more [75]. For example, Catena-X aims to establish unified standards for data exchange across the entire automotive value chain based on a Dataspace, ensuring transparency in data sharing among stakeholders while adhering to supply chain laws [76]. The Smart Connected Supplier Network (SCSN) [77] provides open communication standards for exchanging order-related data between enterprises or organizations. It includes the definition of a common language to facilitate the exchange of data such as orders, dispatch advice, Technical Product Data, Bills of Materials (BoM), and more.

Furthermore, some research has explored the exchange of Digital Twins within a Dataspace. For instance, Volz et al. [78] proposed the modeling process of a Digital Twin using the Asset Administration Shell (AAS) standardized template and integrated AAS into a Dataspace by extending the Dataspace technical components (Eclipse Dataspace Connector). Usländer et al. [79] analyzed the close relationship between Digital Twins and Dataspaces, proposing an assigned reference model for the development of collaborative Digital Twins.

Considering the latest advancements in the field as discussed in the state of the art, it is crucial to address the open research question mentioned in the introduction section of this paper that enables collaboration in the Systems Engineering process by integrating MBSE with Dataspaces.

3. Approach

3.1. General Approach

As explained in the introduction, many products are often developed and produced by several companies. The OEM is responsible for the overall product. In order for the development tasks to be distributed across the suppliers, the OEM must make defined specifications for the sub-systems in the context of the overall system and the expected scenarios in the product life cycle phases (scenarios during usage of the product, but also during production, transport, maintenance, etc.) [2,80]. These specifications are in the form of requirements [81]. Using model-based approaches, the requirements are at least partially described using models [44,82]. Model-based requirements include, among other things, descriptions of scenarios for the use cases, the associated system contexts, and the black box of the sub-system with the required interfaces [2]. The supplier must analyze the requirements, develop a solution for the sub-system for the OEM and describe it in terms of the requirements (usually also requirements beyond the OEM, e.g., for regulatory purposes) [83]. The sub-system must be described so that the OEM can verify that the requirements are satisfied and that the solution can be integrated into the overall product. Figure 2 shows one scenario of collaboration between OEMs and suppliers.

Based on the general approach, several related requirements for the CMBSE approach must be addressed:

• OEM needs means to transfer the requirements specification to the supplier (in the context of MBSE, at least partly model-based, even if many textual or graphical requirements are knowingly still necessary today in parallel to the models [84]). The known requirements regarding consistency of information, versioning, etc. apply to the transfer [51].
• The supplier aims to develop the sub-system based on the black-box description provided by the OEM and subsequently sends the developed description back to the OEM for comparison. Additionally, it is also necessary to ensure that configuration management rules [51] are applied for the return transfer so that the versions of the sub-system models can be assigned to the versions of the requirements.
• Product development includes highly iterative processes, as there are always uncertainties and new findings lead to adapted decisions. It is therefore important that the exchange of information between OEMs and suppliers can also take place dynamically and that partners can use the respective model versions consistently.
• During the collaboration, relevant information on the requirements and the solution description is exchanged. For such sensitive information, it must be determined specifically and selectively who receives which information in order to guarantee information sovereignty and security [33]. This means that the OEM and the suppliers must extract and provide relevant parts of the respective models for the overall system and the required sub-systems (including the requirements for the required functions, interfaces, and other properties; possibly further information on the context).
• To ensure consistency between models from suppliers and OEMs, it is essential that the modeling methodology and other definitions, including units, are aligned [85]. The agreed-upon definitions must be accessible to all partners. For this article, it is assumed that the OEM provides the definition, the supplier can make additions if necessary, and then provides these as a supplemented description.

The outlined requirements are addressed for the approach in the following sections.

3.2. System Modeling with SysML v2 in the Context of CMBSE

In the context of CMBSE, the bidirectional exchange of selected model parts is necessary. If the system models are not modeled exclusively for the partner(s) on the OEM and supplier sides, the selected model part must always be extracted from a more comprehensive system model. Utilizing models in SysML v2 for CMBSE presents significant advantages. One of them is the consistent model description between graphical and textual notations; therefore, it is feasible to derive the graphical notations from the textual notations. For data exchange during collaboration, this means that only the textual description needs to be transferred, and the graphical representation can be rendered unambiguously in the target SysML v2 software tool. The authors are aware that the implementation of SysML v2 is currently still under development and only available in a few software tools, and that software-specific changes may occur. However, this cannot be estimated at the present time. The statements in this paper refer to the possibilities of the standard and the already available pilot implementation of SysML v2 (“SysML v2 Pilot Implementation” [86] with Eclipse plugin version 0.37.0). By transferring a purely textual description, the approach ensures the interoperability of the data and reduces the file size.

The exchange of model parts requires that the corresponding model parts can be extracted from the overall model. In the SysML v2 specification, this is supported by the package structure (see Figure 3). Structuring via packages was already possible with SysML 1.x. In combination with the textual description, this structure supports the exchange even more with SysML v2. It is important that the individual model parts (e.g., the required sub-system for the transition from OEM to supplier or the specification of the solution for the sub-system for the transition from supplier to OEM) are each described within a package. Further packages can be imported within the package, e.g., the definition package. In addition, it is important that there are no references to SysML model elements from the package to be extracted if they are not considered during the exchange. These references would become unresolvable when imported by the partner. (e.g., model B has some references to elements in model A; A and B are representative here for any models.) If model B is exchanged without model A, the partner will obtain an unresolvable error about these references in model B. At this point, there is a need for concrete modeling guidelines.

In the context of system modeling using SysML v2, leveraging a general definition package (cf. Section 2.1) as a foundational framework for interdisciplinary development is an appropriate approach, especially for definitions that remain stable or independent with different product variants. Sharing general definition packages among different companies contributes to maintaining a unified understanding of the product and its modeling among different developers throughout the multilateral collaboration process. This can help reduce model compatibility issues resulting from disparate modeling processes.

After importing the general definition package, subsequent definition packages can seamlessly extend existing definitions by introducing additional attributes or specifications. Consequently, emerging usage elements defined under these new definition packages undergo further development, enabling the systematic development and refinement of the system model.

Figure 4 shows one possible collaboration process based on the system model using SysML v2. For the approach in this contribution, it is recommended that the OEM create a general definition package that it uses for its modeling. This package can include definitions of parts, interfaces, etc. (see Figure 5). Specific definitions can be derived from the general definitions of collaboration. By refining specialized definition packages, the OEM can define elements of the overall system model based on the refined definitions.

According to systems theory, sub-systems are decomposed from the overall system. For collaborative development, the OEM needs to transfer the definitions and relevant descriptions of the requirements and context associated with the sub-systems to the suppliers. The transmitted data are depicted as “Sub-system 1 Requirements” in Figure 4.

On the supplier’s side, they generate corresponding specialized definitions using not only their general definitions but also the requirements provided by the OEM. Subsequently, suppliers develop sub-systems for the solutions required by the OEM. In this process, suppliers should further align the system model and definitions with the general definitions shared by OEM, thereby avoiding potential model semantic conflicts due to divergent definitions for the same concept. Suppliers provide the OEM with the as-is specification of the sub-system, aligning it with the properties required by the OEM to facilitate the implementation of the sub-system within the overall system. On the supplier side, the definition package may need to be supplemented, e.g., with additional interface specifications. This must be transferred to the OEM to supplement its definition.

Due to continuous updates in requirements and the gaps between the as-is description and the required properties, the modeling and implementation of the system in the collaborative process undergo iterative cycles. Consequently, there is a demand for an efficient and secure exchange approach for the SysML models to effectively facilitate collaborative development.

3.3. Data Exchange via Dataspace

Before exchanging data through the Dataspace, it is imperative for both OEMs and suppliers to institute comprehensive data usage policies. Furthermore, access and use rights should be granted to this data within the appropriate contractual period to ensure data sovereignty. To facilitate collaboration with SysML models, model data needs to be systematically stored in Data Management Tools (see Figure 6) and annotated with detailed descriptions, including data types, version information, etc. This model data is categorized and organized by corresponding metadata, which includes titles, descriptions, license information, contract lists, etc. Additionally, the corresponding models have references to different contracts or agreements. In the Dataspace, links are created for the model data, establishing mutual connections with the relevant metadata, contracts, and usage policies.

The following describes a data model for the Dataspace Connector (the International Data Spaces (IDS) Dataspace Connector [87] is one of the core technical components for communication between IDS Dataspace participants), illustrating the fundamental structure of data provided by data providers within a Dataspace.

In Figure 7, every artifact represents a singular set of data and describes the information, such as a modified date. A specific contract, which describes the usages agreed upon between the data provider and consumer, are then referred to the artifacts during the data exchange. Representations present a detailed description (e.g., data type, standard) of the artifacts. Additionally, the metadata of a data object (representation) are referred to as the resource, which includes information about the title, license information, and a list of contracts. These resources are organized within catalogs. Catalogs are regarded as the top level of navigation for data.

In the Dataspace, the catalogs are contained in the self-description of the connector (data provider). The other connectors (as the data consumers) can request the resource metadata in the catalog only using the specific Dynamic Attribute Token (DAT) [89] within the valid “DescriptionRequestMessage”. Further agreements about the data usage policy and contract must be negotiated between the data provider and consumer for the retrieval and access of each specific artifact in the metadata.

Figure 8 outlines a simplified process of data exchange (based on the preconfiguration collection file of IDS-testbed [90]) between data consumers and providers, omitting the role of data brokers and the specific details of data transmission. Initially, the data consumer requests and reviews the self-description of the data provider through a data broker to locate the desired resources. Subsequently, the consumer requests metadata for specific resources, extracting information about representations and artifacts, along with their corresponding usage rules. Next, concerning specific artifacts, the data consumer engages in contract negotiations with the data provider. At this stage, the consumer may modify the contract. It signifies the consumer’s acceptance of the contract when consumers add received contract rules or modified contracts to the request sent to the data provider. The provider can then check the contract and respond with either approval or refusal of data access. Upon receiving approval, the consumer gains unrestricted access to the data within the specified contract period.

Based on the agreements reached through negotiations on contracts and usage policies, OEMs and suppliers can adopt appropriate approaches for data exchange. Leveraging the Dataspace allows engineers to share the well-classified metadata (resources and representations) first, followed by the dynamic implementation of specific model data updates. In the CMBSE process, the OEM may need to update requirements based on the as-is properties of sub-systems received from suppliers. With relevant contracts in place, suppliers have the ability to access the latest requirements documentation at any time or refer to previous versions. This flexibility also extends to the data provided by suppliers. Therefore, this implies that iterative development of the system through the Dataspace is feasible during collaboration. Furthermore, different versions of the same model can be accessed and utilized through the Dataspace based on corresponding (maybe the same) contracts and usage policies. Access to several versions of the models (including older versions) can be important for configuration management [52].

Due to the Dataspace’s functionality in achieving targeted control over the utilization and release of data, packages (in the context of exchanging SysML v2 models) are suitable to be provided and exchanged as individual items in the form of artifacts within the Dataspace. As an advantage of the SysML v2 model, different exchanged model data can be integrated by importing them into the same file. Additionally, these model data can be extended to incorporate new features or definitions for addressing emerging requirements. Consequently, updates to the model, in certain contexts, can be accomplished by exchanging concise updates based on the existing data. Dataspace serves as a highly suitable platform for facilitating these data exchanges in a secure manner, promoting collaboration in the development of complex mechatronic products.

3.4. Collaboration Approach

Figure 9 shows a possible approach for model-based collaboration in product development between OEM and supplier using a dataspace. On the OEM side, the general definition package is specialized in the black box under the concrete context of a new product, which is the basis for the development of the overall system (“Definition Package” is explained in detail in Section 2.1). The OEM decomposes the system model for sub-system requirements during the development of the overall system. One possible solution for the decomposition is the top-down process [85]. These requirements are subsequently transmitted to the supplier side via the Dataspace, along with the OEM General Definition Package.

On the supplier side, the sub-system is developed according to the OEMs requirements. The sub-system must be verified according to the supplier’s requirements, i.e., a comparison is made between the required and as-is properties [85]. When creating the model-based specification of the sub-system, the supplier should use the definition package provided by the OEM for compatibility, which may need to be specifically extended.

The solution from the supplier is provided to the OEM via the Dataspace, enabling the integration of the supplier’s solution into the overall system [15]. With each successful integration, potential new requirements may emerge, necessitating further solutions from the supplier. Consequently, this collaborative approach results in the continuous enhancement and refinement of the overall product through a collaborative development process.

In the practical process, there may be multiple levels of suppliers and several suppliers on each sub-system level (possibly even multilateral collaboration), but due to space limitations in this contribution, this is not discussed for now.

4. Implementation

In this paper, the implementation of the approach outlined in the preceding section involves the applications of SysML v2 modeling and Dataspace. This implementation is realized through the utilization of two open-source repositories available on GitHub.

• System modeling with SysML v2 in Eclipse

In accordance with the installation instructions for Eclipse outlined in the SysML-v2-Release repository (version 2023-11) [48], engineers can install the corresponding plugins and tools within Eclipse. This enables the creation of SysML files and modeling using SysML v2. Eclipse can automatically render corresponding diagrams based on the textual models. Furthermore, the model library provided by the SysML-v2-Release repository includes units or standards for various domains, facilitating engineers in model development.

• Data exchange with Dataspace in the IDS-testbed

The IDS-testbed repository [90] offers a composition of components that, in accordance with the International Dataspaces Association (IDSA) [91] regulations, can establish a Dataspace capable of secure and sovereign data exchange. Serving as a Minimum Viable Dataspace (MVDS), it incorporates sufficient features to serve as a starting point for experimenters and engineers to create a functional Dataspace, that can be customized and extended as needed to meet specific requirements [92].

Upon configuring Eclipse and IDS-testbed, the implementation of the approach can be achieved through the following steps:

• Modeling by Data Provider in Eclipse:

The data provider initiates the process by performing system modeling in Eclipse. Leveraging SysML v2 plugins and tools (e.g., PlantUML for graphical visualization), the data provider creates a SysML file with <.sysml> filename extensions to define the content of the system. Here is a simple example (all the used example models are as Supplementary Materials provided on GitHub [93]):

Figure 10 illustrates a simple model using SysML v2 within Eclipse. On the left is the text notation encoded by the author. The example definition package imports the International System of Quantities (ISQ) and the International System of Units (SI) stored in the model library, defining the names and characteristics of the parts. The temperature and mass properties of the parts refine the temperature and mass properties specified in the ISQ standard. The example usage package utilizes the imported example definition package to describe the system and its constituent structures, corresponding to the composition relationship in SysML 1.x. Parts inherit properties from their definitions and can redefine them at any level of nesting. Eclipse automatically generates the graphical representation on the right through textual notation. Different packages in the example can be saved in separate <.sysml> files and imported into other files, similar to how ISQ and SI packages are handled.

2.

Data Provider: import the model into Dataspace.

After exporting model files from Eclipse, the subsequent step involves uploading these files to a server (see Figure 6). This facilitates the Dataspace connector by utilizing an API to remotely import the files as artifacts. The following outlines a straightforward operational example:

• Upload the model to a server (e.g., a PDM/PLM tool for the companies, but using a simple web server in the investigation from the author’s side also works);
• Create a post request for the model address to the Dataspace connector address in Postman (one of the most famous API platforms for building and using APIs).
• Send the request.

3.

Data Provider: configures model data provision.

In accordance with the previous section, Dataspace Connector’s data model necessitates that data providers establish metadata descriptions pertaining to the model data. Additionally, data providers are required to define usage policies and contracts associated with the exchanged data. Subsequently, the data provider is expected to register and add resources, including representations, artifacts, and the corresponding contracts, within the relevant catalog.

4.

Data Consumers request and obtain model data.

By requesting descriptions of resources and relevant expressions from data providers, data consumers can determine the necessary artifacts corresponding to specific model data. If consumers submit contracts with the required artifact ID to data providers, either drafted by the providers or modified by the consumers, it signifies the consumer’s agreement to all terms, including stipulated timeframes and usage policies outlined in the contract. Through contract comparison, data providers furnish feedback to consumers regarding data access permissions. Once granted permission, consumers can consistently access data within the specified constraints defined by the contract.

5.

Data Consumers obtain a model and import it into Eclipse for subsequent modeling.

After acquiring the data, data consumers should convert the obtained data files to the <.sysml> filename extension using an extended API or program (since this open-source Dataspace cannot export files with specific extensions). Subsequently, by importing the SysML model files into Eclipse, engineers can engage in further collaborative development of the model. To import packages into different projects, engineers need to select the appropriate project references in the project’s properties.

Through these steps, the entire process, from system modeling to data provision and requests, have been implemented.

5. Example

The approach developed is applied in this contribution using a precision engineering application, specifically for a load cell. For this example, an OEM develops a measurement system that enables precise force measurement capabilities (see also [85]). To address this requirement, the OEM collaborates with a supplier specializing in load cell solutions.

The measurement system is engineered to quantify force accurately, tailored to specific application needs. It integrates various sub-systems (components) and functionalities. The load cell, as one of the key sub-systems provided by the supplier, operates based on fundamental principles such as the piezoresistive effect.

In the scope of this contribution, the collaboration between the OEM and the supplier focuses on aspects of model development and model exchange. On the one hand, the measurement system is modeled based on the requirements for accuracy class, the range of measuring force, and the temperature range. On the other hand, for research and modeling purposes, the parameters of the load cell are settled by the author based on the OIML standard [94]. Furthermore, models from both OEMs and suppliers are simplified and maintained with a significant degree of consistency to avoid ambiguity in description. This, therefore, cannot represent the complete model alignment process in real collaborative scenarios, such as differences in modeling the architecture or selecting terminologies for some ports, features, or units. The full models are provided on GitHub [93].

At the beginning of this CMBSE example approach, the OEM should model the measurement system and provide the requirements and boundary conditions for the development of the scope of supply.

Figure 11 shows the general definition and specific definition for the force measurement system from the OEM side. On the top side of Figure 11, the overall system is defined at a high-level with its parts, ports, requirements, etc. The corresponding graphical notation is shown below, which is generated directly in Eclipse. In the force measurement system definition file, the overall system definition from the general definition package is specified as force measurement system, which not only inherits all the attributes defined already but is also extended with the new attribute “load cell number” and the state machine about the required state.

OEMs can model the detailed system structure using the specified definitions. In this contribution, the modeling approach is based on the MagicGrid methodology [39], including the design of the system structure, system behavior, requirements, parameters, etc. Furthermore, the requirements for the load cell are derived based on the referred definitions and usages. These requirements, as black-box descriptions, contain specific information for the supplier to provide the solution for the load cell, and some information such as the state machine of the force measurement system is not included.

After exporting the SysML model with the relevant requirements and definition packages from SysML v2 tools to Data Management Tools, OEMs can upload them as artifacts to their connectors (in the example in Figure 9, Connector A) in the Dataspace. Figure 12 shows the API in Postman and its response. In the response, a link is created for the artifact, which is always aligned with the up-to-date SysML model at this address.

When the artifacts aligned with its usage policy are organized in a specific catalog, the supplier can query them and start negotiations with the OEM. As Figure 13 shows, the supplier must provide the usage policy (“Provider_rule” with red box in Figure 13) as consent to all the contents of the requested artifact link (“Provider_artifact” with red box in Figure 13). With the received agreement ID, the supplier obtained access to the model within the contract period.

On the supplier side, the SysML model with the requirements and definitions can be accessed after the negotiation, and the development process can be carried out. For the solution specifications of the load cell sub-system, the definitions used in the load cell are from both the OEMs and supplier’s general definitions and further extended, as shown in Figure 14. Moreover, the as-is specifications in Figure 14, such as the parameters and interfaces of the load cell, are described and connected to satisfy the requirements of the OEM. After development, the supplier makes its specification model as the solution for the load cell sub-system available in the same way (see Figure 9). This is no longer described in detail in the contribution.

6. Conclusions and Outlook

Collaborative Model-based Systems Engineering between companies is gaining increasing significance. The modeling language SysML v2 serves as an important basis for facilitating the model data exchange in the collaboration. As data exchange becomes more prevalent, the secure and trustworthy sharing of data are progressively gaining importance. Against this background, the Dataspaces approach is coming into the focus of discussions. This contribution aims to investigate the possibilities and challenges of combining modeling with SysML v2 and data exchange via Dataspaces. Based on systemic approaches, a modeling concept for decomposing the system into sub-systems is developed as a basis for the exchange. In addition, based on the analysis of collaboration processes in the context of Systems Engineering, an architectural approach with a SysML editor and Dataspace for the exchange is elaborated. The implementation of the architecture is based on the open-source solutions “SysML-v2-Release” in the Eclipse environment and “IDS-testbed”. The investigations are based on an application example from precision engineering. The potential and challenges are discussed.

SysML v2 offers good preconditions for exchange with the new metamodel and the combined textual and graphical notation, among other things. Structuring via packages (already possible in SysML 1.x) is an essential basis for extracting sub-models (see research question 1a). Packages can be exchanged efficiently on the basis of textual modeling and the import options in SysML v2. Modeling guidelines are necessary to enable the extraction of sub-models in a targeted manner. These must make it possible for the packages to be exchanged independently (or only with references to other packages that are also exchanged) without references to the outside being lost during the exchange. This concerns the structuring of the models, the definition of relations (so that the models can be extracted), and the import of packages (possibly entire SysML models). This contribution also shows the potential of definition packages. Concrete modeling guidelines are also necessary for the definition packages and the formalization of requirements so that cross-company collaboration is possible. This also applies to context-specific extensions for the definition packages.

Dataspaces enable the exchange of models, even if the partners’ development processes are different. The processes are considered in the partners’ data management tools (e.g., in the PDM or PLM system). Decoupling of the individual processes takes place via Dataspaces. Based on the modeling in the editor, the SysML models are saved in the company’s data management tool, and their specific links are uploaded and provided in a secure way via the dataspace (see research question 1b).

The contribution discusses a possible cooperation process between the OEM and supplier. Both provide the required models according to the distribution of tasks (see research question 1c). Future work should address the relevant coupling points for synchronization, including the management and alignment of disruptive changes from new versions of sub-systems. As of today, the collaboration process can be linked to milestones. Closer collaboration with short iteration loops is possible and the subject of research. This contribution assumes a state-of-the-art collaboration process between companies. Dataspace’s search and access options also offer the potential for supporting open development or innovation processes. This potential must be discussed in further investigations.

The application of the approach described in this contribution (a combination of SysML v2 and Dataspace) shows significant potential with regard to the flexible exchange of sub-models and their integration into the models of the respective partner. With the help of Dataspaces, access to the models can be controlled. The main challenge is the necessary modeling guidelines from the engineers’ viewpoint. In addition, the IT data infrastructure must enable access to the models provided in the data management tools across company boundaries. This provision must be supported administratively. In order to make the process between the SysML editor, data management tool, and Dataspace as efficient as possible, workflows are required that must be implemented in the connectors.