Towards an Open Platform for Democratized Model-Based Design and Engineering of Cyber-Physical Systems

This paper reports on the development of GitWorks, an open platform for democratizated Model-Based Design of cyber-physical systems (CPS). The GitWorks platform is currently under development by Perpetual Labs Ltd in collaboration with the Open Source Modelica Consortium (OSMC) 1 and the OpenCAESAR project 2 . In this paper, we present our vision for the platform, its system architecture and a prototype implementation. We also present a case study that demonstrates the use of the proposed platform for enabling the seamless integration of Modelica models into a broader range of systems engineering processes for complex product development. In the long-term, the platform also aims to enable the integration of Modelica tools with advanced systems engineering processes that rely on other domain specific languages (e.g. SysML v2, BPMN, etc.).


Introduction
The Modelica language (Elmqvist, Mattsson, and Otter 1998;Fritzson and Engelson 1998) has a growing user community that produces a large and constantlyincreasing code base of models.However, there is a lack of tools to address a number of advanced modelmanagement use cases, such as semantic search, analysis, cross-referencing, checking, component selection automation, for a large body of models (Johansson, Pop, and Fritzson 2005).Despite recent developments (Sirin et al. 2015;Isasi, Noguerón, and Wijnands 2015;Hussain et al. 2022), tool support for the integration of Modelica models into advanced Model-Based Systems Engineering (MBSE) practices remains limited (Larsen et al. 2016).This hinders the reuse of models within the Modelica community, and particularly in an industrial context, can greatly limit the potential for adoption of Modelica tools within integrated Model-Based Design (MBD) and product development processes.
There are multiple engineering processes that precede modeling and simulation within a complex product development lifecycle.The information generated by these processes defines the structure, configuration, and input parameter data used by the executable system models.For example: 1.The definition of operational scenarios and associated system requirements.These define the critical behaviors that the system must achieve, the circumstances under which they must be achieved, and other non-functional properties of the product.
2. The definition of the high-level architecture of the system.This includes the system's hierarchical division into different subsystems, their components, parameter values, and interconnections.Alternative design solutions can be evaluated against the criteria defined in (1) via simulation.
Many tools and formalisms can be used in these phases to capture the system information as part of an MBSE framework, such as UML, SysML, AADL, FMDesign, BDPM, and OPM (J.Ma et al. 2022;Basnet et al. 2022).Integration of system simulation and analysis with such MBSE models is difficult to achieve, particularly during the early phases of the system lifecycle, because domain-specific models often lack a common notation (Madni and Sievers 2018).Collecting, aggregating and exchanging information at the system level is complex and often errorprone, which hampers system-wide visibility in a multidisciplinary concurrent design setting (McDermott et al. 2020).This limits the ability to analyze system-level requirements (such as performance and dependability) in the early design phases, causing the postponement of design decisions to later phases.This, in turn, reduces possible opportunities to study alternative solutions and validation of fitness for purpose.It also increases costs, in terms of time and skill, of design refinements if irreversible consecutive design decisions are made in the early stages of the development (Stirgwolt, Mazzuchi, and Sarkani 2022).
The limitations of current MBSE frameworks and their poor integration with system simulation environments, such as Modelica-based tools, contribute to an increased barrier-to-entry for the adoption of MBD.These issues are especially acute for Small and Medium Enterprises (SMEs) that typically do not have the resources to link Commercial-Off-The-Shelf (COTS) tools into integrated tool chains and lack the in-house expertise to develop custom models from scratch.
GitWorks aims to democratize access to MBD for SMEs, independent developers and academia.GitWorks has been designed as a turn-key solution for model management and integration provided with the convenience of a Software as a Service (SaaS) product.It includes the GitWorks Commons which provides a searchable repository of models, tools and services with a try-before-youbuy business model.It also includes a Web application for integrated data and knowledge management, as well as a web-based collaborative Modelica editor.
This paper describes the early design and implementation of GitWorks.Specifically, the contributions of this paper are three-fold: First, we propose a system architecture for the platform to support model-based design and engineering of cyber-physical systems.Second, we develop a prototype implementation of the GitWorks platform that is focused on enabling the seamless integration of Modelica models into a broader range of MBSE activities.Third, we conduct a preliminary case study to demonstrate the use of the proposed platform for the federated design and engineering of an aircraft passenger air conditioner (PACK) system.
The rest of this paper is organized as follows.Section 2 provides an overview of our vision for the GitWorks platform, describing its design goals, conceptual system architecture, and user interfaces.Section 3 describes the prototype implementation of GitWorks and tooling for enabling the use of Modelica in the larger MBSE process.Section 4 presents a preliminary case study to demonstrate the use of the GitWorks for the federated design and engineering of a PACK system.Finally, Section 5 concludes the paper and provides some brief remarks on directions for future work.

GitWorks Platform Overview
This section provides an overview of the GitWorks platform, describing its design principles and conceptual system architecture.GitWorks aims to overcome several of the limitations of current systems engineering practices (Elaasar et al. 2019) by introducing three key concepts and their related functionalities: DEMOps: DevOps for Digital Engineering and Manufacturing.Poor configuration management (CM) practices exacerbate trust issues in current MBSE practices.DEMOps introduces the notion of a Git-like history of changes made across inter-related model fragments.Enables traceability of information provenance and design decisions.This refers to the ability to trace from an authority to its design decisions and constraints, and from the latter to their rationales.Without this capability, a system description becomes a disorganized collection of information artifacts.Enables repeatability.This refers to the ability to encapsulate the analysis of the system description, including its dependencies, such that it becomes repeatable.This is important to maintain confidence in the analysis over time and use it to assert desirable properties.Enables durability.This refers to the ability to version control the information that describes or analyzes a system in such a way that versions become immutable.Without this, it is impossible to perform audits and repeat analyses.Enables efficiency.This refers to the ability to automate processes using CI/CD practices that would otherwise be manual and tedious (Elaasar et al. 2019).Without this, such processes become expensive and error-prone.In Git-Works, these functionalities are fulfilled by the Projects environment described in Section 2.1.
Semantic Twin.System information is captured using a precise language that is rooted in mathematics and formal logic.System descriptions are specified using common vocabularies consisting of concepts and their properties and relationships all expressed in a formal language.This enables digital continuity, which refers to the interoperability of system information contained in different information artifacts that are produced by different parties during different phases of the product lifecycle.It also enables the augmentation or, in some cases, the replacement of typically human-led processes (such as reporting, model transformation, and validation & verification of system information) through the use of powerful automations such as logical reasoning, machine learning, data mining, etc.In GitWorks, these functionalities are fulfilled by the OML language and the versioned triple store and associated reasoner (see Section 2.1).
Digital Prototype.In the context of DEMOps, Digital Prototype refers to the usage of digital environments to facilitate the co-simulation of engineering models, connection with HardWare-In-the-Loop (HWIL) frameworks and real-time system data to support Virtual system Integration, Validation and Verification from the early stages of the product lifecycle.In GitWorks, these functionalities are fulfilled by the Modelica Studio environment (see Section 3).In its current version, Modelica Studio only supports editing and simulation of Modelica-based models.In the future, we aim to introduce advanced functionalities and analyses, such as co-simulation of FMUs, HWIL, model surrogatization, optimization, uncertainty quantification, etc.The Digital Prototype must be supported by a scalable, cloud-based computational infrastructure to enable the more computationally-demanding workflows, and must also be integrated with the CI/CD pipeline to enable automation.In GitWorks, this is achieved via the integration of a standard CI/CD pipeline with a scalable HPC environment (see Section 2.1).
It should be noted that the concepts of the Digital Proto- type and the Semantic Twin are tightly linked and that the integration of the two enables the realization of new and powerful workflows.The Digital Prototype acts as a backbone to organize and facilitate access to system-related information scattered through the different engineering artifacts.An example application of this idea is provided in the PACK case study in Section 4. The system architecture information contained in a SysML model is used to automatically generate the high-level structure of the Modelica model.Also, queries against the GitWorks Commons, enabled by the OML language representation of Modelica, can be used to find suitable, port-compatible components to complete the model.

Conceptual System Architecture
The high-level software architecture of the GitWorks platform is shown in Figure 1.From the perspective its users, GitWorks provides multiple application environments for interacting with the platform, to include the GitWorks Commons for the publishing and reuse of digital engineering artifacts, the GitWorks Projects environment for Semantic Twin-powered DevOps for digital engineering, analysis, reporting and management of the digital thread.In addition to these environments, through Git, OSLC and REST-based APIs, GitWorks is also designed to integrate with third-party adapters and plugins for authoring and reporting.

Supporting these application environments, GitWorks
Server is designed as a middleware of essential services, as well as a nexus for accessing data across organizations and third-party tools and systems.The GitWorks Server is implemented as a Spring Boot application and depends on a GitLab server to provide Git repository hosting and CI/CD capabilities.GitLab4 is an open-source DevOps platform based on the popular Git version control system.GitLab provides a REST API for programmatic access and manipulation of resources, such as repositories, artifacts and users.This API is used to implement much of the Git-centric capabilities provided by GitWorks through GitLab4J5 .
Unlike traditional version control systems, such as CVS, where changes are managed at the file level, Git manages changes at the repository level so that for any particular commit one can recover the precise state of entire repository at that point.To facilitate the management of artifacts developed and owned by different stakeholders, repositories can be organized into groups that capture the hierarchical relationships between systems and their components or the relationships among the different entities participating in a supply chain.
Leveraging Git's repository level change management mechanism, from the artifacts contained in a GitWorks project repository, GitWorks constructs a versioned Semantic Twin that captures the interdependencies and trace- ability links that relate heterogeneous artifacts through the product lifecycle.The Semantic Twin forms a federated knowledge graph that is stored as RDF triples in a custom versioned triple store, which is developed by Perpetual Labs and is based on Jena (Carroll et al. 2004) TDB2.By creating trace links between heterogeneous elements, such as requirements, simulation models, simulation results, and test results, GitWorks provides traceability of design changes and branches at the system level and throughout the product lifecycle, while also allowing each stakeholder the necessary flexibility in managing their own datasets and internal development cycles.
GitWorks provides multiple adapters for automatically enriching the Semantic Twin from a project repository.While the focus of this paper is on the Modelica adapter (see Section 3.3), Perpetual Labs is actively working on adapters for other representations, including SysML and CAD.These adapters read artifact files from the Git repository, for example a Modelica library, and extract a semantic representation in the Ontology Modeling Language (OML).
OML serves as the core ontological language for the GitWorks platform and was originally developed by the Jet Propulsion Laboratory as part of the CAESAR project (Wagner et al. 2020).One of the goals of CAESAR has been to provide a set of OML vocabularies that capture some of the common concepts and relations used in systems engineering (Bayer et al. 2021).OML provides a foundation with well-defined semantics that can be used to model different types of engineering artifacts in a semantically consistent and interoperable fashion.OML extends OWL 2 DL (Web Ontology Language 2 -Description Logic) in such a way that retains the benefits of OWL 2 DL while addressing some of its limitations (Wagner et al. 2020).
GitWorks Commons.The GitWorks Commons enables the seamless reuse of design and engineering artifacts across tool, domain and organization boundaries.Within the GitWorks platform, an artifact is considered as the basic unit of reuse, where its coarsity depends on the tool and domain vocabulary.As shown in Figure 2, a single Modelica file, for example, may contain multiple models, each of which would be considered an artifact in the Commons.When the artifacts from a project repository are ready for release, these artifacts along with their dependencies are bundled together as package and then uploaded to the Commons as a versioned artifact.The GitWorks leverages GitLab Package Registries to support multiple package managers, including Maven and npm.The Commons also supports semantic discovery and integration of artifacts through a SPARQL endpoint that can be used to query the metadata extracted from artifacts via specific adapters (see Section 3.3).
The GitWorks Commons also provides vendors with multiple publication and deployment possibilities.Vendors can choose whether to allow users to download sources and/or binaries, or only provide cloud-based access.For example, a Modelica model can be published as: (1) source code (i.e. a model library), (2) compiled FMU (Model-Exchange or Co-Simulation), and/or (3) as a REST service that can be used in a federated cosimulation.We are investigating different monetization strategies for the GitWorks similar to those proposed for the Digital Manufacturing Commons (DMC) (Beckmann et al. 2016), including (1) payment for each download or execution, (2) payment based on computational usage, and (3) freemium software as a service.To support federated collaboration for enhanced data security and intellectual property protection, we are also actively working on the integration of co-simulation engines, specifically Maestro2 by the INTO-CPS project (Larsen et al. 2016).
GitWorks Projects.The Projects environment is a Semantic Twin-powered Web application for integrated data and knowledge management, and exploration and visualization of the digital thread across multiple disciplines, organizations and product lifecycle stages.It enables the exploration, querying, and modification of OMLbased knowledge base using a Web-based GUI, similar to WebProtégé (Tudorache, Vendetti, and Noy 2008) for OWL2, and provides customizable OML vocabularies for different cyber-physical system lifecycle activities, such as requirements analysis, system modeling, verification and maintenance.At its core, a project corresponds to a Git repository of OML vocabularies and descriptions, which can be cloned and edited using an OML IDE, such as Rosetta6 or Luxor7 .
The GitWorks platform leverages GitLab to provide DevOps capabilities for project repositories, to include Git-based version control, issue management, and CI/CD.To enable Semantic Twin-powered authoring and reporting, every project repository on GitWorks is backed by both a Git repository and a corresponding RDF triple store.The versioned RDF triple store serves as a cache to accelerate semantic queries against the repository and can be reconstructed directly from the files in the Git repository.A project can import artifacts from the GitWorks Commons as dependencies, forming a federated knowledge graph that enables all the stakeholders of a complex engineering system to make specific system information and data available to other project participants independently of the specific tools that they are using (i.e. a Semantic Twin).
An HPC CI environment based on GitLab Runner and the Slurm Workload Manager8 is under active development, and enables computational expensive analyses such as simulation-based requirements verification, uncertainty quantification and optimization to be seamlessly integrated into the DEMOps pipeline.We have already tested different analysis toolkits using our HPC CI environment, to include UncertainPy (Tennøe, Halnes, and Einevoll 2018) and Dakota (Adams et al. 2020).We are working to provide seamless support for surrogate-assisted methods to accelerate computationally expensive analyses using methods such as pre-trained surrogate models for accelerated simulation, as done by JuliaSim (Rackauckas et al. 2021), and dynamically generated surrogates, as done by GreyOpt (Nachawati and Brodsky 2021), for enhanced optimization.
GitWorks Community.Finally, the Community environment enables users and organizations on the platform to connect with one another in a kind of social network for Digital Engineering.Each user is provided with a profile page that contains a public bio with an activity stream and links to associated published artifacts, project workspaces, and organizations.

Modelica Tooling for the GitWorks
This section describes the prototype implementation of the GitWorks tooling for enabling the use of Modelica in the larger MBSE process.Specifically, we report on the progress of our development of: (1) Modelica Studio, a Semantic Twin-powered Modelica text and diagram editor for VSCode for Web, (2) OMFrontend.js9 , a reusable and open-source AGPLv3-licensed library for the parsing and analysis of Modelica source code, which serves as the foundation of Modelica Studio, and (3) the Mod-elicaOML adapter, also based on OMFrontend.js, for automatically enriching the Semantic Twin from Modelica artifact repositories.

Modelica Studio
We have developed Modelica Studio as a VSCode for Web extension that serves as a Semantic Twin-powered authoring environment for Modelica.Modelica Studio, shown in Figure 3, is designed to support three levels of collaboration: (1) federated, in-the-large collaboration enabled by the GitWorks Commons, (2) Git-based collaboration, using branches and pull requests, and (3) real-time collaboration, using the VSCode LiveShare extension10 .
While several attempts have been made towards the development of a Web-based Modelica editor, significant limitations preclude their use as a collaborative Modelica development environment for the GitWorks: Modelon Impact (Elmqvist, Malmheden, and Andreasson 2019) is a closed-source, cloud-based platform that provides a Modelica diagram and code editor that runs in a Web browser.While it runs in the browser, the implementation appears to require an independent serverside session for each editor instance, where the Optimica Compiler Toolkit (OCT) is used to construct and maintain a semantic model that mirrors what is opened in the editor.This approach simplifies the logic on the client-side, however, the critical dependency on continuous serverside processing for each editor instance can quickly add up 102 In response to a request to run a simulation on a model, OMFrontend.js sends the flattened simulation model to OMWebService.The results of the simulation are then returned as a CSV file, which can then be plotted in Modelica Studio or a third-party application.OMWebService is developed in Python and uses the OMPython interface to communicate with the OMC.

OMFrontend.js
To facilitate the development of Modelica Studio and other Modelica language tools, we have developed the OMFrontend.jslibrary that provides an API for analyzing and manipulating Modelica text documents in both Node.js and Web browser environments.This library handles Modelica parsing, instantiation, flattening, expression evaluation as well as diagram and SVG icon rendering.It simplifies the implementation of language service features in Modelica Studio (see Section 3.1), such as diagnostics, hovers, links, completion, folding, and formatting.We also use OMFrontend.js to implement the ModelicaOML adapter (see Section 3.3) for enriching the Semantic Twin automatically from Modelica source code.OMFrontend.js provides a context object that manages the collection of opened documents and Modelica libraries and serves as the mechanism for handling references to Modelica classes defined in different files.The context object seamlessly resolves Modelica files stored on the local file system, virtual Web browser file system, and via HTTP, depending on whether it is running in a Node.js or Web browser environment.
While the OpenModelica compiler uses a parser that is generated from an ANTLR3 grammar, to support browserbased editing we found the need to develop a new parser for OMFrontend.js.The new Modelica parser is built using the tree-sitter13 parser generator.The tree-sittermodelica14 project contains the Modelica grammar for the tree-sitter parser generator.OMFrontend.js then constructs an abstract syntax tree from the tree-sitter concrete syntax tree.This abstract syntax tree is akin to the class tree described in the Modelica Language Specification (MLS).Unlike the tree-sitter concrete syntax tree which is incrementally reparsed, the abstract syntax tree needs to be reconstructed every time the underlying text changes.To reduce latency, this is done in a lazy fashion inspired by the red/green trees15 .

ModelicaOML Adapter
The purpose of the ModelicaOML adapter is to handle the conversion of Modelica source code and OML conform-

PACK Case Study
This case study aims to demonstrate how the GitWorks platform enables collaborative and federated design and development throughout the systems engineering process.
The system under development is a simplified PACK unit, which is itself a subsystem of the Environmental Control System of a passenger aircraft.One of the primary goals of the PACK is to regulate the temperature, pressure and humidity of the cabin air (Jennions et al. 2020).

Federated Development of the PACK System
The PACK project comprises seven tasks with a focus on the systems engineering process: Define project; Define system requirements; Define system architecture; Define subsystem behavior; Perform analysis; Verify system requirements; Generate Reports.These tasks are to be performed by specialists with various roles: Project Manager, System Architect, Lead Systems Engineer and a team of Design Engineers.The tasks are performed using either third-party or GitWorks-hosted tools (e.g.Modelica Studio), and each task yields one or more artifacts with a particular filetype (e.g. a SysML or a Modelica model).The GitWorks platform supports this use case in the manner summarized in Figure 6.This diagram describes how OML adapters are employed to consolidate the knowledge contained in different modeling artifacts by creating a unified, RDF-based Semantic Twin.
In this case, the Project Manager creates an OML Git repository (corresponding to the project) using the Git-Works Workbench environment.The knowledge regarding the participating organizations, teams and people is captured by importing the relevant OML vocabularies and populating an OML description file.In the Workbench environment, the Project Manager defines the relevant project tasks and assigns responsibility to members of the project.A small section of the resulting OML description is presented in Listing 1, in which five roles have been defined and tasks assigned.ClassPrefix "partial" "input" "output" "encapsulated" Prefix "input" "output" "parameter" "constant" "replaceable" "flow" "stream" "inner" "outer" "innerouter" "final" hasType Once the Project Manager creates the first commit, the CI/CD pipeline runs the build scripts which interprets the OML code into RDF triples and ingests them into the triple store, effectively integrating the information into the Semantic Twin.The Project Manager can then save the resulting project structure as a template and publish it as an OML artifact in the GitWorks Commons for future reuse and sharing.Once the project repository has been created, the other participants can review the tasks that have been assigned to them, and begin contributing to the project.The lead Systems Engineer defines the overall systems requirements using a SysML tool.The three requirements for this system are defined as follows: 1.The mass of the PACK shall be no greater than 100kg.
2. The PACK shall produce Conditioned Air with a temperature to ±1°K of 293 °K.
3. The PACK shall produce Conditioned Air with a pressure to ±3kPa of 101 kPa.
The Systems Architect then defines the PACK architecture, also using a SysML tool.For the purposes of this case study, a simplified architecture for the PACK, comprising only the primary heat exchanger and the compressor, is developed.Figure 7 represents this composition of the PACK and the air flows into, out of, and within the system.It is also assumed that the three system requirements apply to the 'Cruise' scenario, during which the temperature and pressure of the input air flows are assumed to be fixed and known.By specifying the SysML repositories as dependencies within the overall project, the SysML artifacts created by the actors (in this case, requirements and architecture) are translated into OML and populate the Semantic Twin in accordance with the corresponding OML vocabularies.This translation is performed by the dedicated SysMLOML adapter within the GitWorks platform.An example of the resulting OML description (translated from SysML) is presented in Listing 2. In this listing, only a portion of the PACK architecture definition is presentedthe flows between the interfaces are also captured by the OML description but are not shown.

OMWebService
Simulation Results

ModelicaOML Adapter
Publishing Importing templates

Git push
Git push Git push  This simple example illustrates how the Semantic Twin can be constructed either directly via the GitWorks Workbench environment (e.g. of roles and tasks), or via translation from another artifact (e.g.translation of requirements and architecture from SysML to OML).The Semantic Twin can then be used to efficiently query information about the project and the (including time-travel queries to investigate evolution of system de- The generated partial model can be used as a starting point for the Design Engineers to define the behavior of the PACK's components: the heat exchanger and the compressor.Depending on the desired model fidelity, there are multiple ways of implementing the behavior.For example, the total heat transfer rate of the heat exchanger can be obtained from: where E e is the effectiveness of the heat exchanger, C a min is the heat capacity of the air stream and T bleed and T ram are the temperatures of bleed and ram air respectively (Poudel 2019).The pressure drop in the heat exchanger can be calculated via the following equation: where f is the friction factor, L tube is the total length of the heat exchanger, ρ is the air density as a function of temperature, v is the mean stream velocity and D h is the hydraulic diameter (Poudel 2019).Traditionally, Equation 1and Equation 2 can be implemented manually by engineers in Modelica language.This can be a time-consuming, error-prone and costly process.Alternatively, the engineers can sift through many third-party Modelica repositories available online in the hope of finding the component model they need (Hussain et al. 2022).Existing Modelica tools such as OpenModelica and Dymola (Dempsey 2006) can assist with this task by performing a basic keyword search.However, this comes with a significant limitation of only searching within classes currently loaded into the workspace.Furthermore, such a search is incapable of analyzing the inherent structural and semantic knowledge embedded in the models.
In order to alleviate such modeling bottlenecks and boost model exchange, the GitWorks Commons offers users a convenient interface to query an RDF database of published models and libraries to find required components and blocks.This approach is based on a physicsbased simulation ontology currently being developed in OML, and employs the SPARQL query language to offer a set of advanced search techniques such as aggregation, extensible value testing, subqueries, and negation (Hussain et al. 2022;Kollia, Glimm, and Horrocks 2011).For example, a SPARQL query can be designed to find another Modelica component with two compatible connector ports.The connector compatibility is established by ensuring that the connector variables have the same name, prefixes and type.Listing 3 shows an excerpt of such a query which outputs all compatible Modelica models containing two connector ports carrying the thermofluidic variables m_flow, p, h_outflow, Xi_outflow, C_outflow.We are searching for a model that has two connectors that contain these variables and the names, types and prefixes of the variables match.For example, Modelica.Fluid (Casella, Otter, et al. 2006) and ThermoPower (Casella and Leva 2005) libraries use distinct but compatible connectors which can only be identified manually or through a SPARQL query.As a result, the users are presented with compatible components from all libraries that use the same connector definition.The result of running the query in Listing 3 is given in Listing 4, and shows the three compressor models from the PL_Lib library that are matching.One can note that most Modelica tools support choicesAllMatching annotation which can help populate the dialogs with a list of matching models -this feature is limited to loaded libraries only and extending it would require tool changes.
Having the Modelica models expressed as individuals using an OML-based vocabulary and searching these using SPARQL queries against the GitWorks Commons populated with all the available libraries on the GitWorks platform is a paradigm-changing feature.
The GitWorks Commons displays a list of models and libraries obtained as a result of the search query and enables the user to inspect the documentation and the code.As highlighted in (Hussain et al. 2022), it is rare that a component model can be reused without any modifications.Therefore, if a suitable component is found, the engineer can import the selected model into the Modelica Studio workspace and invite the rest of the team to use the real-time collaborative functionality of the VSCode Liveshare extension to modify, complete and check the full model definition synchronously.The resulting model definition is shown in Figure 8b.Optionally, component models can also be seamlessly published in the GitWorks Commons with dependencies tracked through Modelica's uses annotation.
Development of Modelica models, therefore, is greatly aided by the proposed Semantic Twin technology through automatic generation of model architecture and facilitating model reuse and exchange within the community.

Simulation-based Requirements Verification and Reporting
Automating the requirement verification allows engineers to accelerate the iterative systems engineering process.In order to enable this capability, the requirements formally captured by the Semantic Twin in Section 4.1 can be expressed alongside a behavioral model developed in Modelica.
Several Modelica libraries for simulation-based requirements verification exist, such as Model-ica_Requirements, ReqSysPro discussed in (Bouskela et al. 2022), and vVDR outlined in (Mengist, Buffoni, and Pop 2021).In this case study, the requirements and scenario are captured in a vVDR-style verification scenario model through the ModelicaOML adapter.The resulting model is shown in Figure 9.The model contains the design block containing the PACK system defined in the previous section.It receives the inputs defined in the scenario block and outputs the calculated values of system mass and conditioned air temperature and pressure.These values are then used as inputs in the three requirements blocks to calculate the verification status of the corresponding The simulations are performed using the OMWebService (defined in Section 3.1), and the results can be committed to the relevant Git repository at the same time to preserve the traceability of the results.At the same time, the ModelicaOML adapter is invoked to pass the verification status of requirements to the Semantic Twin.Table 1 shows the verification status of each of the requirements defined in Section 4.1.
As a result, all the systems engineering knowledge generated throughout the project is unified and stored in the RDF-based Semantic Twin.This enables automated and intelligent reporting of necessary decision-making information via querying and reasoning across the whole dataset.For example, the Lead Systems Engineer may wish to take a closer look into the project management and requirement verification aspects of the project by constructing a SPARQL query corresponding to the following natural language expression: • Return all system-level requirements (with their proposed verification test cases) that have not been verified and the person responsible for performing the verification test case.
As another example, the Project Manager may wish to find out more about the model development and trace its metadata information: • Return the artifact that defines a heat exchanger component which 'presents' a particular interface and the original author of that artifact.
Such queries can be expressed using SPARQL within the Workbench environment, and the outputs can be displayed as tables or graphs.This allows the users to gain insight that would normally be difficult to attain through other means.
The PACK case study presented in this section has demonstrated how the GitWorks platform can be used to effectively integrate Modelica modeling and simulation environments into the systems engineering process to achieve simulation-based system verification from the early stages of the product lifecycle.Artifacts can be automatically generated from other model types (e.g.SysML to Modelica) via the OML adapters.Modelica models can be further defined by searching the GitWorks Commons for relevant and compatible components.Modelica simulation results can be automatically translated into RDF to automatically verify requirements.The resulting integrated Semantic Twin can then be queried.In this way, Modelica models become an invaluable link in the systems engineering chain by providing added value across multiple domains, all while maximizing automation and reducing the effort required.

Conclusions and Future Work
We have presented our vision for the GitWorks platform to enable the democratized model-based design and engineering of cyber-physical systems.We have proposed a system architecture for GitWorks and have developed a prototype implementation focused around enabling the use of Modelica in the larger MBSE process.We have conducted a preliminary case study that has demonstrated the use of GitWorks for the federated design and engineering of a passenger air conditioner system.
Plans for future work include further development of OML vocabularies and OML adaptors to increase the number of different modeling paradigms and COTS tools supported by the platform, increase the maturity of the user interface for the web applications, and demonstrate the application to other use cases including satellite systems and composite structures design and fabrication.

Figure 2 .
Figure 2. The GitWorks Commons UI for Modelica and other digital engineering artifacts

Figure 3 .
Figure 3. Modelica Studio, a Semantic Twin-powered Modelica editor extension for VSCode for Web ing to the ModelicaOML vocabulary presented in.This enables the automatic enrichment of the Semantic Twin directly from the Modelica artifact repositories based on the representation provided by OMFrontend.js.The ModelicaOML vocabulary 16 defines concepts such as Class, Block, Model, Package, Function, Record, Type to model the Modelica class restrictions and Component to model the components.The component and class prefixes are also modeled as scalar enumerations: Prefix and ClassPrefix.There are also relations that bind these concepts together such as hasType, hasPrefix, hasClassPrefix, contains, extendsClass, etc.

Figure 6 .
Figure 6.Data flow within the GitWorks platform for the PACK case study.

Figure 8 .
Figure 8. Stages of PACK Modelica model (a) Partial model, (b) Completed model

102
Figure 9. PACK system design model as a part of a verification scenario model.

Table 1 .
Requirements verification status