Safe and scalable model splicing for digital engineering models for software code definition digital threads

Abstract

A method and system are provided for generating shareable model splices of digital engineering (DE) models. The method includes receiving a DE model file in a native file format, extracting model data, storing the model data in storage, generating an externally accessible splice function that enables external access to a digital artifact derived from the model data, and generating a shareable model splice that includes access to a selection of the digital artifact and access to at least one of the splice functions. The splice function provides an addressable API endpoint or SDK endpoint that enables third-party applications and users to access the digital artifact without accessing the entire DE model file and without requiring direct involvement using DE tools associated with the DE model type. These endpoints also provide a unified programming interface to shareable model splices generated from DE models having the same DE model type.

Description

Technical Field

[0001] Reference to Related Applications If an Application Data Sheet ("ADS") or PCT Request Form ("Request") has been filed on the filing date of this application, it shall be incorporated herein by reference. Any application claimed in the ADS or Request for priority under 35 U.S.C. §§ 119, 120, 121, or 365(c), and any and all parent applications of such application, its grandparent application, its great-grandparent application, etc., shall also be incorporated herein by reference, including any priority claims made in those applications and any materials incorporated by reference, to the extent that their subject matter is not inconsistent with this specification.

[0002] Furthermore, this application is related to the following U.S. patent applications, which are hereby incorporated herein by reference in their entirety as if fully set forth herein. ● PCT Patent Application No. PCT / US24 / 14030 ( docket number IST-01.001PCT), entitled "Artificial Intelligence (AI) Assisted Digital Documentation for Digital Engineering," filed on February 1, 2024, describes AI-assisted documentation for digital engineering platforms. ● U.S. Provisional Patent Application No. 63 / 442,659 ( docket number IST-01.001P), entitled "AI-Assisted Digital Documentation for Digital Engineering with Supporting Systems and Methods," filed on February 1, 2023, describes AI-assisted tools for digital engineering ("DE") including applications for modeling and simulation of digitally designed products, and certification. ● U.S. Provisional Patent Application No. 63 / 451,545 (IST-01.002P), filed on March 10, 2023, entitled "Digital Threads in Digital Engineering Systems, and Supporting AI-Assisted Digital Thread Generation," describes a model splicer and digital threading technology. ● U.S. Provisional Patent Application No. 63 / 451,577 (IST-02.001P1), filed on March 11, 2023, entitled "Model Splicer and Microservice Architecture for Digital Engineering," describes model splicer technology. ● U.S. Provisional Patent Application No. 63 / 462,988 (IST-02.001P2), filed on April 29, 2023, entitled "Model Splicer and Microservice Architecture for Digital Engineering," describes model splicer technology. ● U.S. Provisional Patent Application No. 63 / 511,583 (Reference Number IST-02.002P), filed on June 30, 2023, entitled "AI-Assisted Model Splicer Generation for Digital Engineering," describes AI-assisted model splicer technology. ● U.S. Provisional Patent Application No. 63 / 516,624 (IST-02.003P), filed on July 31, 2023, entitled "Document and Model Splicing for Digital Engineering," describes document splicing technology. ● U.S. Provisional Patent Application No. 63 / 520,643 (Reference Number IST-02.004P), filed on August 20, 2023, entitled "Artificial Intelligence (AI)-Assisted Automation of Testing in a Software Environment," describes software testing using AI assistance. ● U.S. Provisional Patent Application No. 63 / 590,420 (IST-02.005P), filed on October 14, 2023, entitled "Commenting and Collaboration Capability within Digital Engineering Platform," describes collaborative capabilities. ● U.S. Provisional Patent Application No. 63 / 586,384 (IST-02.006P), filed on September 28, 2023, entitled "Artificial Intelligence (AI)-Assisted Streamlined Model Splice Generation, Unit Testing, and Documentation," describes AI-assisted streamlined model splicing, testing, and documentation. ● U.S. Provisional Patent Application No. 63 / 470,870 (IST-03.001P), filed on June 3, 2023, entitled "Digital Twin and Physical Twin Management with Integrated External Feedback within a Digital Engineering Platform," describes the management of digital and physical twins and the integration of external feedback within a DE platform. ● U.S. Provisional Patent Application No. 63 / 515,071 (IST-03.002P), filed on July 21, 2023, entitled "Generative Artificial Intelligence (AI) for Digital Engineering," describes an AI-enabled digital engineering task execution process within a DE software platform. ● U.S. Provisional Patent Application No. 63 / 517,136 (IST-03.003P), filed on August 2, 2023, entitled "Machine Learning Engine for Workflow Enhancement in Digital Engineering," describes a machine learning engine for model splicing and DE script generation. ● U.S. Provisional Patent Application No. 63 / 516,891 (IST-03.004P), filed on August 1, 2023, entitled "Multimodal User Interfaces for Digital Engineering," describes a multimodal user interface for DE systems. ● U.S. Provisional Patent Application No. 63 / 580,384 (IST-03.006P), filed on September 3, 2023, entitled "Multimodal Digital Engineering Document Interfaces for Certification and Security Reviews," describes a multimodal user interface for certification and security reviews. ● U.S. Provisional Patent Application No. 63 / 613,556 (IST-03.008P), filed on December 21, 2023, entitled "Alternative Tool Selection and Optimization in an Integrated Digital Engineering Platform," describes tool selection and optimization. ● U.S. Provisional Patent Application No. 63 / 584,165 (IST-03.010P), filed on September 20, 2023, entitled "Methods and Systems for Improving Workflows in Digital Engineering," describes workflow optimization in a DE platform. ● U.S. Provisional Patent Application No. 63 / 590,456 (IST-04.001P), filed on October 15, 2023, entitled "Data Sovereignty Assurance for Artificial Intelligence (AI) Models," relates to the assurance of data sovereignty during AI model training and evaluation. ● U.S. Provisional Patent Application No. 63 / 606,030 (IST-04.001P2), filed on December 4, 2023, entitled "Data Sovereignty Assurance for Artificial Intelligence (AI) Models," provides further details on guaranteeing data sovereignty during AI model training and evaluation. ● U.S. Provisional Patent Application No. 63 / 419,051, titled "Interconnected Digital Engineering and Certification Ecosystem," filed on October 25, 2022. ● U.S. Non-Provisional Patent Application No. 17 / 973,142 (Reference Number 54332-0057001) titled "Interconnected Digital Engineering and Certification Ecosystem," filed on October 25, 2022. ● U.S. Non-Provisional Patent Application No. 18 / 383,635 (Reference Number 54332-0059001) titled "Interconnected Digital Engineering and Certification Ecosystem," filed on October 25, 2023. ● U.S. Provisional Patent Application No. 63 / 489,401, titled "Security Architecture for Interconnected Digital Engineering and Certification Ecosystem," filed on March 9, 2023.

[0003] Copyright and Trade Dress Notice Some disclosures in this patent document include copyrighted material. This patent document may indicate and / or describe matters that are or may become the rights holder's trade dress. The copyright holder and the rights holder of the trade dress will not object to any reproduction by any person of the patent disclosure as it appears in the U.S. Patent and Trademark Office application or record, but reserves all other copyright and trade dress rights.

[0004] ISTARI DIGITAL is a trademark name that conveys embodiments of the present invention, and therefore the aforementioned trademark name may be used interchangeably in the specification and drawings to refer to the products / processes provided by embodiments of the present invention. The terms ISTARI and ISTARI DIGITAL may be used herein to describe the present invention and the company providing the invention.

[0005] Field of Invention This disclosure relates to tools for digital engineering, including modeling, simulation, validation, verification, and certification of digitally designed products. Specifically, the invention relates to robust and efficient communication, integration, and coordination between large-scale, multidisciplinary digital engineering models. [Background technology]

[0006] The background information provided in this invention is intended to aid in understanding the invention and its applications and uses, and may not constitute prior art.

[0007] Digital engineering tools, including modeling and simulation tools that accurately represent or virtualize physical systems or processes in relation to real-world decisions, enable the iterative and effective development of components and / or systems. To enable digital engineering from the design of complex systems to validation, verification, and certification, heterogeneous engineering tools from multiple disciplines are required, and these digital engineering tools and the models they generate are still siloed across different engineering software tools. Robust and efficient integration of data and models from siloed tools is one of the most expensive aspects of digital engineering, requiring large teams of highly specialized engineers and software developers. Cross-platform collaboration is often hindered by software skill set mismatches between subject matter experts, given the vast number of different digital engineering model types used today, making it extremely costly. Furthermore, large-scale multi-disciplinary integration into digital threads and digital twins for system-level assessment is not yet mature enough to efficiently model complex interactions in large and complex systems.

[0008] Furthermore, the authentication of these components and / or systems is complex, requiring the integration of data from engineering models designed using heterogeneous tools, along with human-readable documentation, throughout the entire authentication process. Authentication requires information and testing that primarily occurs in the physical world, using the physical manifestation of digitally designed components and / or systems (sometimes referred to herein as “products”), but physical testing that is completed in a single attempt, or by a third-party stakeholder (e.g., a component supplier), often needs to be repeated due to intellectual property or data ownership concerns. This results in redundant physical testing that adds cost and delay to development and authentication work. Data integrity, security, auditability, traceability, and accountability are all critical in the management of digital models and digital data.

[0009] Therefore, considering the aforementioned issues, there is an unresolved need to provide engineering collaboration systems and platforms that enable the rational design, validation, verification, and certification of complex systems. Thus, enabling the integration of multidisciplinary engineering models from heterogeneous and fragmented tools, along with human-readable documentation, within an integrated, scalable, and collaborative digital engineering platform would represent a technological advancement.

[0010] Based on this background technology, various embodiments of the present invention have been developed. [Overview of the Initiative]

[0011] This summary of the invention provides a general overview of the present invention, its applications, and use, and is not intended to limit the scope of the invention, which will become clear from the detailed description when read in conjunction with the drawings.

[0012] According to a first aspect of the present invention, in one embodiment, a non-temporary physical storage medium for storing program code is provided. The program code is executable by a hardware processor. When the hardware processor executes the program code, it causes the hardware processor to perform a computer implementation process for generating a shareable model splice of a digital engineering (DE) model. The program code may include code for receiving a DE model file of a DE model having a DE model type, wherein the DE model file is in a native file format. The program code may include code for extracting model data from the DE model file in the native file format. The program code may include code for storing the model data in a model data storage area. The program code may include code that generates one or more externally accessible splice functions that enable external access to one or more digital artifacts derived from model data stored in a model data storage area, wherein one or more externally accessible splice functions may provide addressable application programming interface (API) endpoints or software development kit (SDK) endpoints that are accessible to third-party applications and users, and the API endpoints or SDK endpoints may enable access to the digital artifacts without accessing the entire DE model file and without requiring direct involvement from third-party applications and users using DE tools associated with the DE model type.Furthermore, the program code may include code that generates a shareable model splice of a DE model, wherein the shareable model splice may include access to a selection of one or more digital artifacts, may include access to at least one of one or more externally accessible splice functions, may be accessible by third-party applications and users via an API endpoint or SDK endpoint, and the API endpoint or SDK endpoint may provide a unified programming interface to the shareable model splice generated from a DE model having a DE model type.

[0013] In some embodiments, access to a selection of one or more digital artifacts may be provided by one of the addresses, pointers, links, uniform resource locators (URLs), and copies of the one or more digital artifacts. In some embodiments, access to at least one of one or more externally accessible splice functions may be provided by one of the addresses, pointers, links, uniform resource locators (URLs), and copies of at least one of the one or more externally accessible splice functions.

[0014] In some embodiments, the non-temporary physical storage medium may further include program code that executes at least one of one or more externally accessible splice functions to access a selection of one or more digital artifacts from a shareable model splice of the DE model and to perform at least one action or calculation on the selection.

[0015] In some embodiments, the shareable model slice may include metadata associated with one or more digital artifacts, and the metadata may indicate a given version of the DE model file and a timestamp of the time when one or more digital artifacts were derived from the DE model file having the given version.

[0016] In some embodiments, at least one of the one or more digital artifacts may be one of the model data stored in the model data storage area, and at least one of the one or more externally generally accessible slice functions may be a read-type function.

[0017] In some embodiments, one or more externally generally accessible slice functions may be written in a scripting language.

[0018] In some embodiments, the program code for extracting model data from the DE model file may include a model crawling script that can involve a DE tool associated with the DE model type via the API or SDK interface of the native tool.

[0019] In some embodiments, the shareable model slice may include at least one of a first information security tag indicating the level of access to a selected portion of one or more digital artifacts and a second information security tag indicating the level of access to at least one of the one or more externally generally accessible slice functions.

[0020] In some embodiments, the non-transitory physical storage medium may further include program code for generating an update to the DE model file using one or more externally generally accessible slice functions.

[0021] In some embodiments, the DE tool may be a first DE tool, and the unified programming interface may be configured to interface with a first DE tool and a second DE tool that cannot directly interoperate with the first DE tool, so that a plurality of DE tools can be used interoperably in parallel.

[0022] In some embodiments, the shareable model price may be a first shareable model price, the DE model file may be a first DE model file, and a selected portion of one or more digital artifacts may be incorporated by a second shareable model price generated from a second DE model file.

[0023] In some embodiments, the program code for generating one or more externally generally accessible splice functions may further include code for receiving user input and, based on the user input, obtaining access to at least one of the externally generally accessible splice functions from a splice function data store.

[0024] In some embodiments, the program code for generating one or more externally generally accessible splice functions is code for sending a request from a customer environment to an API gateway service cell provided by a DE platform, where the customer environment is not managed by the DE platform and requests from the customer environment cannot change the production software associated with the DE platform, and code for receiving access in the customer environment from the API gateway service cell to one or more externally generally accessible splice functions.

[0025] In some embodiments, access to at least one of one or more externally generally accessible splice functions may be REST-compliant.

[0026] In some embodiments, program code that generates one or more externally accessible splice functions may include code that runs an AI algorithm trained on existing externally accessible splice functions associated with existing model splices for the same DE model type and / or similar DE models.

[0027] In some embodiments, program code for extracting model data from a DE model file may include code that receives a microservice request for model splicing, code that constructs file information for the DE model file based on the DE model type, code that sends the DE model file and file information to a native API server for the DE tool associated with the DE model type, and code that runs on the native API server to receive multiple model data files generated from a data extraction process or model crawling process for the DE model file.

[0028] In some embodiments, the DE tool associated with a DE model type may be selected from a group consisting of model-based systems engineering (MBSE) tools, augmented reality (AR) tools, computer-aided design (CAD) tools, data analysis tools, modeling and simulation (M&S) tools, product lifecycle management (PLM) tools, multi-attribute transaction space tools, simulation engines, requirements model tools, electronic model tools, test plan model tools, cost model tools, scheduling model tools, supply chain model tools, manufacturing model tools, cybersecurity model tools, and mission effectiveness model tools.

[0029] According to a second aspect of the present invention, one embodiment provides a computer implementation method for generating a shareable model splice of a DE model. The computer implementation method may include receiving a DE model file of a DE model having a DE model type, wherein the DE model file is in a native file format. The computer implementation method may include extracting model data from the DE model file in the native file format. The computer implementation method may include storing the model data in a model data storage area. The computer implementation method may include generating one or more externally accessible splice functions that enable external access to one or more digital artifacts derived from the model data stored in the model data storage area, wherein one or more externally accessible splice functions may provide addressable application programming interface (API) endpoints or software development kit (SDK) endpoints that are accessible to third-party applications and users, and the API endpoints or SDK endpoints may enable access to the digital artifacts without accessing the entire DE model file and without requiring direct involvement by third-party applications and users using DE tools associated with the DE model type.Furthermore, a computer implementation method may include generating a shareable model splice of a DE model, wherein the shareable model splice may include access to a selection of one or more digital artifacts, may include access to at least one of one or more externally accessible splice functions, may be accessible by third-party applications and users via an API endpoint or SDK endpoint, and the API endpoint or SDK endpoint may provide a unified programming interface to the shareable model splice generated from a DE model having a DE model type.

[0030] The embodiments described in the first aspect are similarly applicable to the third aspect.

[0031] In addition, in some embodiments, generating one or more externally accessible splice functions and generating a shareable model splice for a DE model may be performed by a digital agent located within a secure customer environment.

[0032] According to a third aspect of the present invention, in one embodiment, a model splicing system is provided for generating a shareable model splice of a DE model. The model splicing system comprises at least one hardware processor and at least one non-temporary physical storage medium for storing program code. The program code is executable by at least one hardware processor. When the program code is executed, at least one hardware processor can cause the at least one hardware processor to execute a computer implementation process for generating a shareable model splice of a DE model. The program code may include code that receives a DE model file of a DE model having a DE model type, wherein the DE model file is in a native file format. The program code may include code that extracts model data from the DE model file in a native file format. The program code may include code that stores the model data in a model data storage area. The program code may include code that generates one or more externally accessible splice functions that enable external access to one or more digital artifacts derived from model data stored in a model data storage area, wherein one or more externally accessible splice functions may provide addressable application programming interface (API) endpoints or software development kit (SDK) endpoints that are accessible to third-party applications and users, and the API endpoints or SDK endpoints may enable access to the digital artifacts without accessing the entire DE model file and without requiring direct involvement from third-party applications and users using DE tools associated with the DE model type.Furthermore, the program code may include code that generates a shareable model splice of a DE model, wherein the shareable model splice may include access to a selection of one or more digital artifacts, may include access to at least one of one or more externally accessible splice functions, may be accessible by third-party applications and users via an API endpoint or SDK endpoint, and the API endpoint or SDK endpoint may provide a unified programming interface to the shareable model splice generated from a DE model having a DE model type.

[0033] The embodiments described in the first aspect are similarly applicable to the second aspect.

[0034] In yet another aspect or embodiment of the present invention, a computerized server is provided which includes at least one processor, memory, and a plurality of computer codes embodied on the memory, wherein, when executed, the plurality of computer codes cause the processor to execute a process including the steps described herein. Other aspects and embodiments of the present invention include methods, processes, and algorithms including the steps described herein, and also include processes and operating modes of systems and servers described herein.

[0035] Features described in the context of different aspects and / or embodiments of the present invention may be used together and / or interchangeable wherever possible. Similarly, where features are described in the context of a single embodiment for the sake of brevity, those features may also be provided separately or in any suitable partial combination. Features described in relation to non-temporary physical storage media may have corresponding features that are definable and / or combinatable with respect to digital documentation systems and / or methods and / or systems, and vice versa, as these embodiments specifically envision.

[0036] Further other aspects and embodiments of the present invention will become apparent from the modes for carrying out the invention when read in conjunction with the accompanying drawings.

[0037] The accompanying drawings are incorporated into and constitute part of this specification, illustrating embodiments of the invention and are used in conjunction with this description to illustrate the principles of the disclosed embodiments. For clarity, brevity, and flexibility, not all elements, components, or specifications are defined in all drawings. Not all drawings corresponding to specific steps or embodiments of the invention are drawn to scale. Instead, emphasis is placed on the description of the properties, functions, and products of the manufacturing methods and devices described herein.

[0038] The embodiments of the present invention described herein are illustrative and not limiting. Hereinafter, embodiments will be described by reference to the accompanying drawings. [Brief explanation of the drawing]

[0039] [Figure 1] The following describes exemplary interconnected digital engineering platform (IDEP) form architectures according to several embodiments of the present invention. [Figure 2]This document illustrates exemplary embodiments of IDEP as an interconnected digital engineering (DE) and certification ecosystem, as well as exemplary digitally certified products, according to several embodiments of the present invention. [Figure 3] This document presents another exemplary embodiment of IDEP, illustrating the services and features provided by some embodiments of the present invention. [Figure 4] This invention presents potential scenarios for instantiating an IDEP connected to a customer's physical system and IT environment, according to several embodiments of the present invention. [Figure 5] This document presents exemplary multimodal interface designs for feedback integration in IDEP according to several embodiments of the present invention. [Figure 6] This is a schematic diagram comparing exemplary digital threads connecting DE models according to several embodiments of the present invention. [Figure 7] This is a schematic diagram illustrating an exemplary DE model splicing setup according to several embodiments of the present invention. [Figure 8] This is a schematic diagram illustrating the digital threading of a DE model by model splicing according to several embodiments of the present invention. [Figure 9] This is a schematic diagram illustrating the linking of DE model splices in a splice plane according to several embodiments of the present invention, and a comparison between digital threading with model splicing and digital threading without model splicing. [Figure 10] The following are exemplary directed acyclic graph (DAG) representations of pipelined DE tasks related to digital threads according to several embodiments of the present invention. [Figure 11] A flowchart shows an exemplary process for generating a DE model splice according to several embodiments of the present invention. [Figure 12] This document illustrates an exemplary system for generating DE model splices according to several embodiments of the present invention. [Figure 13]The following describes a general process within IDEP for performing model splicing and generating model splices for all types of models, according to several embodiments of the present invention. [Figure 14] This invention presents a set of exemplary representations and editing interfaces for computer-aided design (CAD) of aircraft propeller engines, according to several embodiments of the present invention. [Figure 15] This document illustrates exemplary examples of splicing results of CAD models in IDEP according to several embodiments of the present invention. [Figure 16] This is a screenshot of an exemplary model splicer interface showing a visual representation of an input aircraft propeller engine file according to several embodiments of the present invention. [Figure 17] Figure 16 shows a screenshot of an exemplary model splice "Hide Part & Share 2D File" generated from an input CAD file, according to some embodiments of the present invention. [Figure 18] This is a screenshot of an exemplary user interface for receiving user input to add a splice function to the exemplary model splice in Figure 17, according to some embodiments of the present invention. [Figure 19] Figure 18 shows a screenshot of an exemplary model splice from Figure 17 after user modification, according to some embodiments of the present invention, and is performed to provide output. [Figure 20] This is a schematic diagram of an exemplary data structure for storing model data and digital artifacts extracted or derived from computer-aided design (CAD) or computer-aided design and drafting (CADD) models, according to some embodiments of the present invention. [Figure 21] This invention illustrates a model splicing process for hiding parts of a CAD model according to several embodiments of the present invention. [Figure 22]This is an exemplary schematic diagram showing exemplary computing and simulation scripts for defining an optimization problem according to some embodiments of the present invention, as well as exemplary data structures for storing data extracted from such scripts. [Figure 23] This is an illustrative schematic diagram illustrating how information can be extracted from scientific or engineering computing and simulation scripts representing mathematical functions according to some embodiments of the present invention, and how this information can be used to construct a model splicer user interface. [Figure 24] The present invention presents graphical user interfaces for viewing model splices of mathematical function scripts and for performing model splicing of input functions related to the left wing of an aircraft under design, respectively, according to several embodiments of the present invention. [Figure 25] This is a schematic diagram of an exemplary embodiment illustrating the integration of IDEP with a simulation module using model splicing, according to several embodiments of the present invention. [Figure 26] This invention presents several embodiments of a model-based systems engineering (MBSE) model and an exemplary script defining an exemplary data structure for storing data extracted from such an MBSE model. [Figure 27] The following are screenshots of an exemplary model splicer GUI for receiving user input for model splicing an MBSE model of an airplane propeller, according to some embodiments of the present invention. [Figure 28] The following are screenshots of exemplary GUIs provided to collaborators by IDEP to view digital artifacts from received model splices, according to several embodiments of the present invention. [Figure 29] The following are screenshots of exemplary GUIs or web portals provided by IDEP to collaborators for viewing, executing, and updating received model splices, according to several embodiments of the present invention. [Figure 30] The following are exemplary examples of document splicing or document model splicing within an IDEP according to several embodiments of the present invention. [Figure 31] The following are screenshots of exemplary GUIs used with a digital documentation system according to several embodiments of the present invention. [Figure 32] This is an exemplary microservice architecture for implementing various DE tools and model splicers for model type files, according to several embodiments of the present invention. [Figure 33] A more detailed microservice architecture for implementing various DE tools and model splicers for model type files, according to several embodiments of the present invention. [Figure 34] The fundamentals of neural network operation according to several embodiments of the present invention will be described. [Figure 35] This document outlines the IDEP neural network training process according to several embodiments of the present invention. [Figure 36] This is an exemplary flowchart illustrating different phases and datasets involved in training an IDEP machine learning model according to several embodiments of the present invention. [Figure 37] This invention provides illustrative schematic diagrams of a server (management computing entity) and a client (user computing entity) used for documentation within an IDEP, according to several embodiments of the present invention. [Modes for carrying out the invention]

[0040] In the following description, many specific details are given for illustrative purposes to provide a complete understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be implemented without using these specific details. In other examples, structures, devices, activities, methods, and processes are shown using schematic diagrams, use cases, and / or illustrations to avoid obscuring the invention. The following description contains many details for illustrative purposes, but those skilled in the art will understand that many variations and / or modifications to the details presented fall within the scope of the invention. Similarly, many of the features of the invention are described in relation to or in relation to each other, but those skilled in the art will understand that many of these features can be provided independently of others. Accordingly, this description of the invention is written without prejudice to the generality of the invention and without imposing limitations on the invention.

[0041] Broadly speaking, the present invention relates to methods and systems that enable the integration, collaboration, and communication between multidisciplinary digital engineering (DE) models from heterogeneous, disconnected DE tools, along with human-readable documentation, within a unified, scalable, secure, generalized, and interconnected digital engineering platform (IDEP). More specifically, methods and systems for DE model splicing are disclosed. Model splicing encapsulates and partitions DE model data and model data manipulation and access functions. Model splices thus generated can be shared, executed, revised, or further spliced ​​independently of the native DE tools and development platforms used to generate the input DE models. User-instructed and / or autonomous linking between model splices creates software-defined digital threads, and the extensibility of model splicing across many different types of DE models allows for the scaling and generalization of digital threads to represent each and every stage of the DE lifecycle. Furthermore, embodiments of the present invention provide a secure, zero-trust solution for sharing, revising, and reviewing DE data with rigorous auditability, traceability, and stakeholder accountability to ensure compliance with industry standards and government regulations throughout the entire lifecycle of DE products.

[0042] Embodiments of the present invention will now be described in detail with reference to the drawings. First, general DE system and model splicing-specific terminology will be introduced. Next, IDEP will be described in detail. Finally, model splicing systems that can be considered subsystems of IDEP will be described in detail.

[0043] term To aid in understanding the present invention, several illustrative terms used with IDEP are given below, but these should not be read as limiting the scope of the invention. Terms may be used in noun, verb, or adjective form within the scope of their definition. ● Digital Engineering (DE): According to the Defense Acquisition College (DAU) and the U.S. Department of Defense (DOD) Digital Engineering Strategy published in 2018, digital engineering is "an integrated digital approach to systems engineering that supports lifecycle activities from concept to disposal using trusted sources and models of system data as a cross-disciplinary continuum." Digital engineering reinforces the paradigm shift in systems engineering from traditional design-build-test methodologies to new model-analysis-build methodologies, thereby incorporating digital innovations into an integrated model-based approach that enables system design, prototyping, and testing all within a virtual environment. ● DE Data: Digital Engineering (DE) data includes project management, program management, product management, design review, and / or engineering data. ● DE Data Field: For example, a data field for DE data within a DE document template. ● Phases: Stages within the DE product lifecycle, including but not limited to stakeholder analysis, conceptual studies, requirements definition, preliminary design and technical review, system modeling, final design, implementation, system assembly and integration, prototyping, verification and validation at the system, subsystem, and component levels, and operation and maintenance. ● DE Model, also called a "Digital Model": A computer-generated model that represents the characteristics or behavior of a complex product or system. A DE model can be created or modified using DE tools, and a DE model may be represented by one or more DE model files. A DE model file is a computer model file created or modified using DE tools. In this disclosure, the terms “Digital Model,” “DE Model,” and “DE Model File” may be used interchangeably where the context requires. A DE Model in IDEP disclosed herein refers to any digital file uploaded to the platform, including documents that are appropriately interpreted as defined below. For example, in various embodiments of the invention, a computer-aided design (CAD) file, a system modeling language (SysML) file, a system requirements definition (SDR) text file, and a neural network model JSON file may each be considered a DE model. A DE model may be machine-readable only, human-readable but written in programming code, or human-readable but written in natural language-based text. For example, a document processing document containing a product's technical specifications, or a spreadsheet file containing technical data about a product, may also be considered a DE model. ● Interconnected Digital Engineering Platform (IDEP), also known as a “Digital Engineering and Certification Ecosystem”: According to the DAU, a “DE Ecosystem” is “an interconnected infrastructure, environment, and methodology (processes, methods, and tools) used to store, access, analyze, and visualize data and models of evolving systems to address the needs of stakeholders.” Embodiments of IDEP disclosed herein include a software platform operating on hardware to achieve the aforementioned capabilities under zero-trust principles. DE and certification ecosystems perform verification and validation tasks as defined below. ● Verification: According to DAU, verification "confirms that system elements meet design or construction specifications. Throughout the system lifecycle, design solutions at all levels of the physical architecture are verified by a cost-effective combination of analysis, inspection, demonstration, and testing." Verification refers to evaluating whether a product, service, or system meets specified requirements and is suitable for its intended purpose, and to externally check the needs of customers or stakeholders. For example, in the aviation industry, the verification process may include testing aircraft components to ensure that they can withstand the forces and conditions encountered during flight. ● Validation: According to the DAU, validation is "1) the review and approval of capability requirements documents by a designated validation body, 2) the process by which the contractor tests publications / technical manuals for technical accuracy and validity (or in a manner directed by the DoD component procurement activity), and 3) the process of evaluating a system or software component during or at the end of the development process to determine whether it meets the specified requirements." Therefore, validation refers to evaluating whether the overall performance of a product, service, or system is suitable for its intended use, including compliance with regulatory requirements, and its ability to meet the needs of its intended users, and internally checking against specifications and regulations. For example, in the manufacturing of industrial products, the validation process may include consumer surveys to inform the product design, modeling and simulation to validate the design, prototype testing for failure limits, and surveys of feedback from buyers. ● Common Verification and Validation (V&V) Products: Regulatory and certification standards, compliance, calculations, and tests (e.g., for the development, testing, and certification of products and / or solutions) are referred to herein as “Common V&V Products.” ● DE Tool: A tool or DE tool is a DE application software (e.g., CAD software), a computer program, and / or a script that creates or manipulates a DE model during at least one stage or phase of the product lifecycle. A DE tool may include multiple functions or methods. ● Application Programming Interface (API): A software interface that provides software programs with programmatic access to services, enabling application software to exchange data and communicate with each other using standardized requests and responses. This allows different programs to work together without revealing the internal details of how each program operates. DE tools typically provide API libraries for code interface access. ● Script: A sequence of instructions that are interpreted and executed within another program, or executed by another program, without being compiled into a binary file that can be executed on its own through a computer processor without the support of other programs. ● API Script: A script that implements specific functionality available through IDEP, such as those disclosed herein. An API script may be an API function script encapsulated in a model splice, or an "orchestration script" or "platform script" that orchestrates a workflow through digital threads built on interconnected model splices. ● Platform API or ISTARI API: A library of API scripts available in IDEP, such as those disclosed herein. ● API function scripts, "splice functions," "splice methods," "ISTARI functions," or "function nodes": A type of API script. When executed, API function scripts input to or output from DE models or DE model splices. "Input" functions, input methods, or "input nodes" allow updating or modifying the input DE model. "Output" functions, output methods, or "output nodes" allow data extraction or derivation from the input DE model via its model splice. API function scripts may also invoke native API function calls of native DE tools, and the terms "native" and "primal" may refer to existing DE model files, functions, and API libraries associated with a particular third-party DE tool, including proprietary and open-source ones. ● Endpoint: In the context of software and networking, an endpoint is a specific digital location or destination from which different software systems communicate with each other. This allows external systems to access the functionality or data of an application, operating system, or other service. An API endpoint is a point of interaction where an API receives a request and returns data in response. Software Development Kit (SDK) endpoints or SDK-defined endpoints similarly provide service handles for use with the SDK. References to API endpoints in this disclosure are equally applicable to SDK endpoints. ● Deliverables: According to DAU, digital deliverables are “deliverables created within or generated from the DE ecosystem” for “providing data for alternative views, to visualize, communicate, and deliver data, information, and knowledge to stakeholders.” In this disclosure, “digital deliverables” or “deliverables” are the results of execution from output API function scripts within a model splice. Multiple deliverables may be generated from a single DE model or DE model splice. ● Model Splice: Within this disclosure, a “model splice,” “model wrapper,” or “model graft” of a given DE model file includes (1) DE model data or digital artifacts extracted or derived from the DE model file containing model metadata, and (2) locators or copies thereof for splice functions (e.g., API function scripts) applicable to the DE model data. Splice functions provide unified and standardized input and output API endpoints for accessing and manipulating the DE model data. The DE model data is model type specific, and the model splice is associated with model type specific input and output schemas. One or more different model splices may be generated from the same input DE model file(s), depending on the specific user application under consideration and the data access restrictions. Depending on the context, the shorter terms “splice,” “wrapper,” and / or “graft” may be used to refer to a spliced, wrapped, and / or grafted DE model. ● Model splicing or DE model splicing: The process for generating model splices from DE model files. DE model splicing encompasses human-readable document model splicing, where the DE model being spliced ​​is a human-readable text-based document. ● Model Splicer: Program code or script (uncompiled) that performs model splicing of a DE model. When applied to a specific DE model file of a given DE model type, a DE model splicer retrieves, extracts, or derives the DE model data associated with the DE model file, generates and / or encapsulates a splice function, and instantiates an API endpoint according to the input / output schema. ● Model splice linking: Generally refers to jointly accessing two or more DE model splices via an API endpoint or splice function. For example, data may be retrieved from one splice to update another (e.g., the input splice function of the first model splice calls the output splice function of the second model splice). Data may be retrieved from both splices to generate a new output (e.g., the output splice functions from both model splices are called). Data from a third splice may be used to update both the first and second splices (e.g., the input splice functions from both model splices are called). In this disclosure, "model linking" and "model splice linking" can be used interchangeably because linked model splices are mapped to correspondingly linked DE models. ● Digital Thread, Software-Defined Digital Thread, Software Code-Defined Digital Thread, or Software Digital Thread: According to DAU, a digital thread is "a large, configurable, enterprise-level analytical framework for components that informs decision-makers throughout the system lifecycle by seamlessly facilitating the controlled interaction of trusted technical data, software, information, and knowledge in an enterprise data information knowledge system based on a digital system model template, providing the ability to access, integrate, and transform heterogeneous data into actionable information." Within the IDEP disclosed herein, a digital thread is a platform script that calls platform APIs to facilitate, manage, or orchestrate workflows through linked model splices to provide the aforementioned capabilities. That is, a digital thread within an IDEP is a script that connects data from one or more DE models, data sources, or physical artifacts to accomplish a particular mission or business objective, and may be referred to as a “software-defined digital thread” or “software digital thread,” implementing a communication framework or data-driven architecture that connects traditionally siloed DE models to enable a seamless flow of information between DE models via model splices. ● Tool linking: Similar to model splice linking, tool linking generally refers to jointly accessing two or more DE tools via a model splice, where a model splice function that encapsulates heterogeneous DE tool functionality is jointly called to execute DE tasks. ● Zero Trust Security: An information security principle that assumes there is no implicit trust between any element, agent, or user. Zero trust can typically be implemented by implementing systematic mutual authentication and least privilege access through strict access control, algorithmic fairness, and data isolation. Within the IDEP disclosed herein, least privilege access through strict access control and data isolation can be implemented by model splicing and the IDEP system architecture. ● Hyperscale capability: The ability of a system architecture to scale appropriately when faced with massive demand. ● IDEP Enclave or DE Platform Enclave: A central command hub responsible for managing and functioning DE Platform operations. An enclave is an independent set of cloud resources that is partitioned to be accessed by a single customer (i.e., single-tenant) or market (i.e., multi-tenant) without depending on the resources of other enclaves. ● IDEP Exclave or DE Platform Exclave: A secondary hub located within the customer environment to support the customer's DE tasks and operations. An exclave is a set of cloud resources outside the enclave, managed by IDEP, for performing work for individual customers. An example of an exclave is a virtual machine (VM) and / or server maintained by IDEP to run DE tools for customers who may require such services. ● Digital Twin: According to DAU, a digital twin is "a virtual replica of a physical entity synchronized across time. Digital twins exist to replicate the configuration, performance, or history of a system. Two main subcategories of digital twins are digital instances and digital prototypes." A digital instance is "a virtual replica of the physical configuration of an existing entity. Digital instances typically exist to replicate the individual configurations of a product during construction or maintenance." A digital prototype is "an integrated multi-physical, multi-scale probabilistic model of a system design. Digital prototypes can use sensor information and input data to simulate the performance of the corresponding physical twin. Digital prototypes can exist before the physical counterpart materializes." Therefore, a digital twin is a real-time virtual replica of a physical object or system with a bidirectional flow of information between the virtual and physical domains. ● Reliable Twin: A reference design configuration at a given stage in the product lifecycle. In the design phase, the reliable twin is the twin configuration that best represents the design objectives. In the operational phase, the reliable twin is the twin configuration that best responds to actual field conditions, or "ground truth." ● Administrator or Administrator: A project manager or other authorized user. Administrators may have high-level privileges to create templates in the documentation system and manage settings in IDEP. ● Requester: A user who uses the platform to implement modeling and simulation for authentication and other purposes, and who can generate documentation in the digital documentation system, but who does not have administrator privileges to change the necessary templates, document formats, or other system settings. ● Reviewer / Approver: A user who reviews and / or approves templates, documents, or other system data. ● Contributors: Users who contribute to IDEP by providing comments or in other ways. ● Document: An electronic file that provides information as an official record. An example document (i.e., a document with one or more previously completed data fields) may serve a similar role to a template in the methods and systems described below, and its data fields can be replaced. Documents include human-readable files that can be read without specialized software, and machine-readable documents that can be viewed with the help of software such as Microsoft Word (DOCX, DOC) and Adobe (PDF). ● DE Documents: Documents containing digital engineering (DE) data, such as project management, program management, design review, and / or engineering data. ● Digital documentation: The creation of documents in a digital format on computer-based systems. A digital document is created based on specified input.

[0044] Interconnected Digital Engineering Platform (IDEP) Architecture Figure 1 shows an exemplary interconnected digital engineering platform (IDEP) architecture according to several embodiments of the present invention. IDEP 100 streamlines the product development process from concept to production by using a virtual representation or digital twin (DTw) 122 of the product to optimize and refine features before building a physical prototype or physical twin (PTw) 132, and by iteratively updating DTw 122 until DTw 122 and PTw 132 are synchronized to achieve desired performance targets for the product.

[0045] Specifically, manufacturers of products (e.g., airplanes, spacecraft, exploration rovers, missile systems, automobiles, railway systems, ships, remotely operated underwater vehicles, robots, drones, medical devices, biomedical devices, pharmaceutical compounds, drugs, power generation systems, smart grid measurement and management systems, microprocessors, integrated circuits, buildings, bridges, tunnels, chemical plants, oil and gas pipelines, refineries, etc.) may use the IDEP platform 100 to develop new products. Engineering teams from manufacturers may create or instantiate a digital twin (DTw) 122 of the product within a virtual environment 120 that includes detailed computer-aided design (CAD) models and finite element analysis (FEA) or computational fluid dynamics (CFD) simulations of component systems such as fuselages, wings, engines, propellers, tails, and aerodynamics. The DTw 122 virtually represents the design and performance characteristics of the product, allowing the team to optimize and refine its features before building a physical prototype 132 in the physical environment 130. In some embodiments, PTw132 may be an existing entity, while DTw122 is a digital instance that replicates the individual configurations of PTw132 in a built-out or maintained state. For illustrative purposes only, DTw122 and PTw132 are described in the context of building a new product, but those skilled in the art will understand that the instantiation of DTw122 and PTw132 may be performed in any order based on the specific use case under consideration.

[0046] The digital models (e.g., CAD models, FEA models, CFD models) used to create DTw122 are shown within the model plane 180 in Figure 1. The model plane 180 also shows a neural network (NN) model 184, which can provide machine learning-based predictive modeling and simulation for the DE process. DE models such as 182 can be spliced ​​into one or more model splices, such as 172 and 173, within the splice plane 170. Individual DTws, such as 122, are instantiated from the splice plane 170 via the application plane 160. Model splices, such as 172, can be linked to other model splices, such as 171, by platform scripts or application 162 on the application plane 160, forming digital threads. Multiple digital threads, such as 162 and 163, can be further linked across different stages or phases of the product lifecycle, from concept, design, test, to production. Digital threads further enable seamless data exchange and collaboration between departments and stakeholders, ensuring optimized, validated designs.

[0047] Model splicing provides input and output splice functions that can access and modify DE model data. Therefore, DE tasks associated with design updates and digital threads can be represented by scripted, interconnected, and pipelining tasks arranged in a directed acyclic graph (DAG) such as 124. An example of a DAG for DE tasks is illustrated in more detail with reference to Figure 10.

[0048] To enhance the design, external sensor data 140 can be collected, processed, and integrated into the application plane 160. This process involves linking data from different sources, such as physical sensors 134 on the prototype 132, physical environment sensors 136, and other external data streams, such as simulation data from the model plane 180. API endpoints provide access to digital artifacts from various environments (e.g., data from the physical twin (PTw) sensor 134) and integrate them into the splice plane 170 of the DTw 122. Model splices on the splice plane 170 enable autonomous data linkage and digital thread generation, ensuring that the DTw 122 accurately represents the real-world performance and characteristics of the product.

[0049] To verify the accuracy of DTw122, the engineering team may build or instantiate PTw132 based on the same twin configuration (i.e., digital design). The physical prototype 132 may be equipped with numerous sensors 134, such as accelerometers and temperature sensors, to collect real-time performance data. This data can be compared with simulations of DTw to verify the product's performance and validate its design.

[0050] Processed sensor data 144 can be used to estimate parameters that are difficult to measure directly, such as aerodynamic forces or tire contact force. Such processed sensor data provides additional data to DTw 122, further improving its accuracy and reliability. Processed sensor data 144 may be generated from physical environment sensors 136 using the physical environment 130, or it may be obtained from other external databases 142, as described below.

[0051] During development, feedback from customers and market research may be collected to identify potential improvements or adjustments to the product design. In the Analysis and Control Plane (ACP) 150, subject matter experts (SMEs) can analyze processed sensor data 144 and external expert feedback 114 to make informed decisions regarding necessary design changes. Such analysis 154 may be enhanced or made entirely possible by algorithms (i.e., static program code) or artificial intelligence (AI) modules. Linking of digital threads such as 162, physical sensors 134 and 136, processed sensor data 144, and expert feedback data 114 is performed in the ACP 150, and sensor and performance data are compared and analyzed to lead to modifications of the underlying model file through the digital threads.

[0052] In particular, sensor data 144 from the physical environment 130 and performance data 126 from the virtual environment 120 may be supplied to the comparison engine 152. The comparison engine 152 may include tools that enable platform users to compare various design iterations with each other and with design requirements, identify performance degradations and trends, and run verification and validation (V&V) tools.

[0053] Model splicing will be explained in more detail with reference to Figures 7-9 and 11-33. Model splicing enables the scripting of any DE operation, including the DE model file of model plane 180, with each DE model associated with heterogeneous, siloed DE tools. By coding DE models and DE operations using a unified corpus of scripts, IDEP 100 can become an aggregator where a large space of DE activities associated with a given product (e.g., airplanes, spacecraft, exploration rovers, missile systems, automobiles, railway systems, ships, remotely operated underwater vehicles, robots, drones, medical devices, biomedical devices, pharmaceutical compounds, drugs, power generation systems, smart grid measurement and management systems, microprocessors, integrated circuits, buildings, bridges, tunnels, chemical plants, oil and gas pipelines, refineries, etc.) can be threaded through program code. Thus, model splicing enables the linking and manipulation of all model files (e.g., 182, 184) associated with a given product within the same interconnected DE platform or DE ecosystem 100. As a result, the creation and training of AI modules for the purpose of manipulating DE models (e.g., 182), digital threads (e.g., 162), and digital twins (e.g., 122) becomes possible on a programmable and unified IDEP100.

[0054] Virtual and physical feedback loops Figure 1 illustrates the various stages of the product lifecycle using letter labels "A" through "H". At each stage, IDEP100 enables a feedback loop in which data originating from PTw or DTw is analyzed in ACP150, leading to the generation of a new twin configuration based on design modifications. The new twin configuration is stored in the twin configuration set and may be applied through the application and splice plane, thereby obtaining a modified model file registered in the digital thread.

[0055] The virtual feedback loop 104 begins with a decision 106 to instantiate a new DTw 122. The DAG of hierarchical task 124 enables the automatic instantiation of DTw 122 in the virtual environment 120 based on the twin configuration applied in process step 108 from the twin configuration set 156. DTw 122 and / or its components are then tested in the virtual environment 120, generating DTw performance data 126. Simultaneously, DTw 122 and / or its components may be tested and simulated on the model plane 180 using DE software tools, generating test and simulation performance data 174. The performance data 126 and 174 are combined, compared by the engine 152, and analyzed by the ACP 150, which may lead to the generation and storage of a new twin configuration. The virtual feedback loop 104 is completed by the final decision to instantiate DTw from the new twin configuration.

[0056] The physical feedback loop 102 begins with a decision 106 to instantiate a new PTw 132. The PTw 132 can be instantiated within the physical environment 130 from the model file of the model plane 180, associated with the applied twin configuration from the twin configuration set 156. The PTw 132 and / or its components are then tested within the physical environment 132, generating sensor data from the PTw sensor 134 and environmental sensor 136 located within the physical environment 130. This sensor data can be combined with data from an external database to obtain processed sensor data 144.

[0057] Data from the PTw sensor 134 may be directly added to the model file in the model plane 180 by the DE software tool used in the design process of the PTw 132. Alternatively, the PTw sensor data may be directly added to the digital thread 162 associated with the PTw 132 via the application plane 160. Furthermore, the processed sensor data 144 may be directly integrated into the IDEP 100 via the application plane 160. For example, the processed sensor data 144 may be sent to the ACP 150 for analysis, which may lead to the generation and storage of a new twin configuration. The physical feedback loop 102 is completed by the final decision to instantiate the PTw from the new twin configuration.

[0058] At each stage A through H of the product lifecycle, the system may be labeled as a single twin configuration as the current design criterion, and is described herein as the “reliable twin” or “reliable criterion.” The reliable twin represents the design configuration that best responds to the actual situation (i.e., ground truth). U.S. Provisional Patent Application No. 63 / 470,870 (IST-03.001P) provides a more complete description of reliable twins and their determination, which is incorporated herein by reference in whole.

[0059] With a faster feedback loop from sensor data and expert recommendations, the system updates DTw122 to reflect the latest design changes. This update process may include the engineering team analyzing feedback154 and implementing changes through IDEP100, or automated changes enabled by IDEP100, where updates to DTw122 are generated through programmed algorithms or AI modules. This iterative update process continues until DTw122 and PTw132 are synchronized and the product performance meets the desired targets. While IDEP100 itself may not specify a trustworthy criterion between DTw or PTw, the platform provides configurable mechanisms such as policies, algorithms, voting schemas, and statistical support, thereby allowing agents to designate a new DTw as a trusted DTw, or equivalently, specify when a PTw is a trustworthy and true source of information.

[0060] If significant design improvements are made, a new PTw prototype may be constructed based on the updated DTw. This new prototype will undergo further testing and validation to ensure that the product's performance and design are consistent with the project objectives.

[0061] Once DTw122 and PTw132 are validated and optimized, the product is ready for production. The digital thread connecting all stages of development can be queried via the splice plane 170 to generate documentation as needed to meet validation and verification requirements. The use of model splicing, along with the feedback architecture shown in Figure 1, improves the efficiency of the entire product innovation process.

[0062] Interconnected DE Platform and Product Lifecycle In Figure 1, the letter labels "A" through "H" indicate the following key steps in the product lifecycle according to several embodiments of the present invention. A. Digital models reside within the customer environment: A product can be represented by model files accessible through software tools located within the customer environment. Model plane 180 encompasses all model files associated with the product (e.g., 182). B. Preparation steps for design in the digital realm: Splice plane 170 encompasses model splices (e.g., 172) generated from the DE model file through model splicing. As will be explained in detail with reference to Figures 7-9 and 11-33, model splicing enables the integration and sharing of DE model files within a single platform. C. Linking threads between model splices as needed: To implement the product, model splices are linked through scripts in the application plane 160. A digital twin (DTw) 122 encompassing the product features as designed may be generated from the application plane 160 to run in a virtual environment 120. The complete twin configuration of the generated DTw is stored in a twin configuration set 156 located in the analysis and control plane (ACP) 150. Features or parts of the DTw 122 may be simulated in the model plane 180 using performance data 174 accessed through the splice plane 170. In one embodiment, features or parts of the PTw 132 or DTw 122 configuration may be simulated outside the platform, and the performance data is received by the ACP 150 for processing, as is the performance data 126 received from the DTw 122. D. Determining the "Design State": Performance data 126 from DTw122, or simulation performance data 174 obtained through the model plane 180 and accessed through model splicing, may be collected and sent to ACP150 for analysis. Performance data from different iterations of DTw122 may be compared to the design requirements via engine 152. Analysis of the differences may lead to the generation of new twin configurations stored in twin configuration set 156. Each twin configuration in twin configuration set 156 may be applied in the application plane 160 and splice plane 170 via process step 108 to instantiate the corresponding DTw. Multiple DTws may be generated and tested sequentially or simultaneously against the design requirements via comparison engine 152 and analysis module 154. Verification and validation tools may operate on various iterations of DTw. E. Determining the “Manufacturing State”: Once DTw122 meets the design requirements, the corresponding PTw132 prototype can be instantiated from the spliced ​​model file (e.g., 172). Sensor data may be collected from PTw134 or from within the physical environment 136 and combined with other external data 142 (e.g., sensor data from other physical environments). The resulting processed sensor data 144 may be sent to the analysis and control plane 150 and compared with performance data 126 from DTw and simulation (e.g., 174), leading to further iterations of DTw122 and PTw132, including a twin configuration set 156. The processed sensor data 144 can also be mapped to digital threads (e.g., 164) and model splices (e.g., 172) that manage the PTw132 tested through the application plane 160. F. Determining the “Assembled State”: Once the manufacturing process for the various parts as DTw and PTw is complete, the next step is to determine the assembled configuration. This involves creating a digital representation of the assembly to ensure that the assembly meets the specified requirements. The digital assembly takes into account the dimensions and tolerances of the parts in the “manufactured state.” To verify the feasibility of the digital assembly, testing is performed using measurement data obtained from the physical assembly and its individual components. The measurement data from the physical component parts serves as a reliable standard for the digital assembly, ensuring consistency with the real-world configuration. The digital assembly is compared to the actual physical assembly requirements to validate the assembled configuration. Subsequently, the testing and configuration of the digital assembly serve as a reliable standard for instructions to guide the physical assembly process and ensure accurate replication. The components of IDEP100 described above can be used in the assembly process. In its reliable iteration, DTw122 ultimately captures the precise details of the physical assembly, enabling comprehensive analysis and control in subsequent stages of the process. G. Determining the “Operating State”: Multiple digital twins 122 may be generated as needed to assess the performance of the physical assembly or its individual component parts. These digital twins are created based on specific performance metrics and function as virtual replicas of the physical system. The digital twins 122 are continuously updated and improved in real time using operational data (e.g., 144) collected from monitoring the performance of the physical assembly or its components. This data may, but is not limited to, processed sensor data, performance indicators, and other relevant information. By incorporating this real-time operational data, the digital twins 122 maintain synchronization with the actual system and provide an accurate representation of its operational performance. Any changes or improvements observed via sensor data 144 during the assembly's real-world operation are reflected in the DE model within the digital twin and recorded in the twin configuration set 156. This ensures that the digital twins remain up-to-date and consistent with the current state of the physical system. H. Predictive Analytics / Future Performance: The design process can be iteratively continued in a virtual environment 120 through new DTw122 configurations while the product is operating. Multiple digital twins can be created to evaluate the future performance of a physical assembly or its components based on specific performance metrics. Simulations are performed with various control policies to assess their impact on performance targets and costs. The results of these simulations help determine which specific control policies should be implemented (e.g., tail volume coefficient and sideslip angle for an aircraft product). Digital twin DE models (e.g., 182) are continuously updated and refined using the latest sensor data, control policies, and performance metrics to improve predictive accuracy. This iterative process ensures that the digital twins (e.g., 122, 156) provide reliable predictions of future performance and support informed decision-making.

[0063] The hardware components that make up IDEP100 (e.g., servers, computing devices, storage devices, network links) can be centralized or distributed across various entities, including one or more DE service providers and DE clients, as further illustrated in the context of Figures 3 and 4. Figure 4 shows examples of various potential configurations for instantiating the DE platform within a customer's physical systems and information technology (IT) environment, which is typically a virtual private cloud (VPC) protected by a firewall.

[0064] DE documentation using live or magic documents The methods and systems described herein enable the updating and generation of DE documents using all the functions of IDEP shown in Figure 1. In Figure 1, the IDEP virtual feedback loop 104 enables the scripting of program code within the digital thread 162 for the generation, storage, and updating of the digital twin 122 and twin configuration 156. Similarly, the IDEP virtual feedback loop 104 also enables the scripting of program code within the digital thread 162 for the generation, storage, and updating of DE documents. This enables the creation and maintenance of so-called live digital engineering documents.

[0065] Live DE documents are more similar to DTws than traditional static documents in that they are configured to be continuously updated through a digital thread to reflect the latest changes within a particular twin configuration. In particular, trusted live DE documents are configured to reflect the latest trusted twin configuration. "Printing" a live DE document corresponds to generating a frozen (i.e., static) timestamped version of the live DE document. Thus, "printing" a live DE document is equivalent to "instantiation" in DTw.

[0066] Live DE documents can also be known as magic documents because changes made within the twin configuration (for example, through modifications to model files) may instantly appear in the relevant data fields and sections of the live DE document. Similarly, reliable live DE documents can also be known as reliable magic documents because they continuously reflect data from the reliable twin and therefore always represent a reliable and true source.

[0067] Given the large amount of data and potential modifications performed during the product lifecycle, scripts implementing live DE documentation may be configured to account for a predefined maximum delay between modifications to model files and the execution of corresponding changes in the live DE documentation. Furthermore, for similar reasons, scripts implementing live DE documentation are limited to operations on a specified subset of model files within the DTw, and therefore reflect only changes to critical parameters and configurations of the DTw.

[0068] In one embodiment of the present invention, an IDEP script (e.g., an IDEP application) that accesses model data via one or more model splices and DE document templates for creating and / or updating a live DE document may dynamically update the live DE document using a software-defined digital thread on the IDEP platform. In such an embodiment, the IDEP script may dynamically receive user interactions. In response to a user updating data for the model and / or specific parameter settings, the IDEP script may dynamically propagate the user's updates to the DE document through the corresponding digital thread.

[0069] In another embodiment of the present invention, an IDEP script may instantiate a DE document having sufficient specifications to generate a physical twin (PTw). In such an embodiment, the IDEP script may receive a digital twin configuration of a physical twin, generate a live DE document associated with the digital twin configuration, receive a predetermined timestamp, and generate a printed DE document (i.e., a statically timestamped version of the live DE document at the predetermined timestamp). Such operation is sometimes referred to as "printing the digital twin."

[0070] In yet another embodiment of the present invention, when an IDEP script detects an update, it may instantiate (i.e., "print") a DE document specifying the updated digital twin. In such an embodiment, the IDEP script may detect modifications to the DE model or associated digital thread. In response to detecting a modification, the IDEP script may update the relevant data fields and sections of the live DE document based on the detected modification, and always generate an updated printed DE document having the updated relevant data fields and sections based on the updated live DE document.

[0071] In some embodiments, receiving user interactions with a DE model, modifications to a DE model, or modifications to an associated digital thread may be performed through a push configuration, in which case the model splicer or digital thread script sends any relevant updates occurring to the IDEP script immediately or within a specified maximum delay time. In other embodiments, receiving user interactions with a DE model, modifications to a DE model, or modifications to an associated digital thread may be performed through a pull configuration, in which case the model splicer or digital thread script flags recent modifications until the IDEP script queries the associated DE model or associated digital thread (via the model splice) for flagged modifications. In these embodiments, the IDEP script may extract modified information from the modified DE model or modified digital thread (via the model splice) to update the live DE document. In further embodiments, receiving user interaction with a DE model, a modification of a DE model, or a modification of an associated digital thread may be performed through a pull configuration, and the IDEP script periodically checks the relevant DE model or associated digital thread (via model splicing) against the modified data fields by comparing the data found in the live DE document with the periodically extracted model and digital thread data. In these embodiments, the IDEP script may update the live DE document with the modified data.

[0072] Dynamic document updates Some embodiments described herein focus on documentation, or the preparation and updating of documents, as well as document management (e.g., for review). As described, some embodiments of the system enable dynamic updates to documents, relating to software-defined digital threads in the IDEP platform and associated documentation.

[0073] It has been proposed to use an ML engine along with model data and templates to create and / or update documents almost instantaneously as a single action. Furthermore, the digital engineering platform dynamically interacts with the user. When a user interacts with the system and updates model data or specific parameter settings, these changes can be propagated to the associated documentation through the corresponding digital thread. The AI ​​architectures involved include locally instantiated large-scale language models (LLMs, for data security reasons) and non-LLM approaches (e.g., NLP-based) to create, update, or predict documentation in the form of sentences, paragraphs, and entire documents. At the same time, attempting to update the entire system of digital threads with each update can be extremely slow and may pose a security risk to the system. Therefore, it may be more efficient to generate live DE documents that are updated within the maximum latency based on a subset of the system's DE models.

[0074] Interconnected Digital Engineering and Certification Ecosystem Figure 2 shows exemplary embodiments of IDEP as an interconnected digital engineering (DE) and certification ecosystem 200 according to several embodiments of the present invention, as well as exemplary digitally certified products. The interconnected DE and certification ecosystem 200 can be seen as a specific instance or implementation of IDEP 100 shown in Figure 1. IDEP may also be referred to as the “DE metaverse”.

[0075] The Interconnected DE and Certification Ecosystem 200 is a computer-based system that links models and simulation tools with their associated requirements to fulfill the purposes of verification, validation, and certification. Verification refers to a method of evaluating whether a product, service, or system meets specified requirements and is suitable for its intended purpose. For example, in the aviation industry, the verification process may include testing aircraft components to ensure that they can withstand the forces and conditions encountered during flight. Verification also includes externally checking customer or stakeholder needs. Validation refers to a method of evaluating whether the overall performance of a product, service, or system is suitable for its intended use, including compliance with regulatory requirements, and its ability to meet the needs of its intended users. Validation also includes internal checks against specifications and regulations. The Interconnected DE and Certification Ecosystem 200 disclosed herein is designed to connect and bridge a large number of heterogeneous DE tools and models from numerous engineering domains and fields, or from separate organizations that may wish to share models with each other but have no other interaction. In various embodiments, the system implements a robust, scalable, and efficient DE model collaboration platform using an extensible model splice with widely distributed DE model types and DE tool data structures and associated functionalities, an application layer for linking or connecting DE models via APIs, digital threads for connecting live engineering model files for collaboration and sharing, digital documentation management to assist in preparing engineering and certification documents suitable for verification and validation (V&V) purposes, and AI assistance with the functionalities of the aforementioned system components.

[0076] More specifically, Figure 2 shows an example of an interconnected DE and certification ecosystem, as well as examples of digitally certified products 212A, 212B, and 212C (collectively referred to as digitally certified products 212). For example, in some embodiments, digitally certified product 212A may be an unmanned aerial vehicle (UAV) or other aircraft, digitally certified product 212B may be a drug or other chemical or biological compound, and digitally certified product 212C may be a process, such as a manufacturing process. Generally, digitally certified products 212 may include any product, process, or solution that can be developed, tested, or certified (partially or entirely) using DE tools such as 202. In some embodiments, digitally certified products 212 may not be limited to physical products, but may include non-physical products such as methodologies, processes, and software. Physical systems and systems that physically interact often require multiple DE tools to assess compliance with common V&V products, simply for modeling and simulation (M&S) needs. However, many complex non-physical systems may also require multiple DE tools for product development, testing, and / or certification. With this in mind, various other possibilities for digitally certified products will be recognized by those skilled in the art. By including regulatory and certification standards, compliance, calculations, and tests (for example, for product and / or solution development, testing, and certification), users can directly incorporate relevant regulatory and certification standards, compliance, calculations, and test data into their DE workflows. Regulatory and certification standards, compliance, calculations, and tests are sometimes referred to herein as “common validation and verification (V&V) products.”

[0077] The digital authentication product 212 in Figure 2 may be designed and / or authenticated using an interconnected DE and authentication ecosystem 200. The interconnected DE and authentication ecosystem 200 may include a user device 206A, an API 206B, or other similar human-to-machine or machine-to-machine communication interface operated by the user. The user may be a human 204 with varying skill levels, or an artificial user such as an algorithm, artificial intelligence, or other software that interfaces with the ecosystem 200 through API 206B. The ecosystem 200 may further include a computing and control system 208 (hereinafter, "computing system 208") connected to and / or including a data storage unit 218, an artificial intelligence (AI) engine 220, and an application and service layer 222. In some embodiments, the artificial intelligence (AI) engine 220 is a machine learning (ML) engine. References to "machine learning engine 220" or "ML engine 220" may be extended more generally to artificial intelligence (AI) engine 220. For clarity, any user selected from a variety of potential human or artificial users will be simply referred to herein as User 204. In some embodiments, the computing system 208 may be a centralized computing system. In some embodiments, the computing system 208 may be a distributed computing system. In some cases, User 204 may be considered part of the ecosystem 200, while in other embodiments, User 204 may be considered separate from the ecosystem 200. The ecosystem 200 may include one or more DE tools 202, such as data analysis tools 202A, computer-aided design (CAD) and finite element analysis (FEA) tools 202B, simulation tools 202C, drug modeling and simulation (M&S) tools 202D-202E, and manufacturing M&S tools 202F-202G.Ecosystem 200 may also include a repository of common V&V products 210, such as regulatory standards 210A-210F related to UAV development and certification, medical standards 210G (e.g., CE marking (Europe), FCC Declaration of Conformity (USA), IECEE CB scheme (Europe, North America, parts of Asia and Australia), CDSCO (India), FDA (USA), etc.), medical certification rules 210H (e.g., ISO13485, ISO14971, ISO9001, ISO62304, ISO10993, ISO15223, ISO11135, ISO11137, ISO11607, IEC60601, etc.), manufacturing standards 210I (e.g., ISO9001, ISO9013, ISO10204, EN1090, ISO14004, etc.), and manufacturing certification rules 210J (e.g., General Conformity Certification (GCC), etc.).

[0078] In Figure 2, the computing system 208 is centrally located within the architecture and configured to communicate with (e.g., receive data from and send data to) user devices 206A, or APIs 206B such as APIs associated with artificial users, DE tools 202 via APIs or software development kits (SDKs) 214, and a repository 210 of common V&V products via API / SDK interfaces 216. For example, the computing system 208 may communicate with user devices 206A and / or API 206B to send or receive data corresponding to design prototypes, user information (e.g., user credentials), engineering-related inputs / outputs associated with DE tools 202, digitized common V&V products, product design evaluations, user instructions (e.g., search requests, data processing instructions, etc.). The computing system 208 may also communicate with one or more DE tools 202 to send engineering-related inputs for performing analysis, modeling, simulation, testing, etc., and receive engineering-related outputs associated with the results. The computing system 208 may also be configured to communicate with the Common V&V Product Repository 210 to retrieve data corresponding to one or more digitized Common V&V Products 210 and / or upload new Common V&V Products to the Common V&V Product Repository 210, such as those received from user 204. All communications may be transmitted and verified securely, for example, using methods that rely on zero-trust security. In some embodiments, the ecosystem's computing system may interface with regulatory and / or certification authorities (for example, via a website operated by the authority) to retrieve digitized Common V&V Products published by regulatory authorities that may be relevant to the product the user is designing. In some embodiments, the user may upload digitized Common V&V Products to the ecosystem itself.

[0079] The computing and control system 208 may process and / or store incoming data to perform analytical and control functions, and in some embodiments, as further described herein, may access a machine learning engine 220 and / or an application and service layer 222 to identify useful insights based on the data. Centering the computing system 208 within the ecosystem architecture offers many advantages, including reducing the technical complexity of integrating various DE tools, improving the user's product development experience, intelligently connecting common V&V products such as standards 210A-210F to the DE tools 202 most useful for meeting the requirements associated with the common V&V products, and enabling monitoring, storage, and analysis of various data flowing between elements of the ecosystem throughout the entire product development process. In some embodiments, data flowing through and potentially stored by the computing system 208 may also be auditable for purposes such as preventing security breaches and performing data quality controls. Similarly, any analytical and control functions performed via the computing system 208 may be trackable for auditability and traceability considerations.

[0080] Referring to one specific example shown in Figure 2, user 204 may use the DE and certification ecosystem to produce a digitally certified UAV 212B. For example, user 204 may be primarily interested in certifying the UAV as meeting the requirements of a specific regulatory standard 210E related to the failure conditions of the UAV (e.g., "MIL-HDBK 516C 4.1.4 - Failure Conditions"). In this use scenario, user 204 may develop a digital prototype of the UAV on user device 206A or using API 206B and send the prototype data to computing system 208 (e.g., as at least one of a CAD file, MBSE file, etc.). Along with the prototype data, user 204 may transmit additional data via user device 206A, including indications of common V&V products that user 204 is interested in authenticating (e.g., regulatory standard 210E), user credentials information for accessing one or more capabilities of computing system 208, and / or instructions for running one or more digital models, tests, and / or simulations using a subset of DE tools 202.

[0081] Referring to another example shown in Figure 2, user 204 may use the DE and certification ecosystem to produce a digitally certified drug, compound, or biologic 212A. For example, user 204 may be primarily interested in certifying the drug, compound, or biologic 212A as meeting the requirements of specific medical standards 210G and medical certification rules 210H. In this use scenario, user 204 can develop a digital prototype of the drug, compound, or biologic on user device 206A or using API 206B, and send the prototype data (e.g., as a molecular modeling file) to computing system 208. Along with the prototype data, user 204 may transmit additional data via user device 206A, including indications of common V&V products that user 204 is interested in authenticating (e.g., medical standards 210G and medical certification rules 210H), user credentials information for accessing one or more capabilities of computing system 208, and / or instructions for running one or more digital models, tests, and / or simulations using a subset of DE tools 202 (e.g., drug M&S tools 202D-202E).

[0082] Referring to yet another example shown in Figure 2, user 204 can use the digital engineering and certification ecosystem to create a digitally certified manufacturing process 212C. For example, user 204 may be primarily interested in certifying the manufacturing process 212C as meeting the requirements of a specific manufacturing standard 210I and manufacturing certification rule 210J. In this use case, user 204 can develop a digital prototype of the manufacturing process on user device 206A or using API 206B and send the prototype data to computing system 208. Along with the prototype data, user 204 may transmit additional data via user device 206A, including indications of common V&V products that user 204 is interested in authenticating the process (e.g., manufacturing standard 210I and manufacturing certification rule 210J), user credentials information for accessing one or more capabilities of computing system 208, and / or instructions for running one or more digital models, tests, and / or simulations using a subset of DE tools 202 (e.g., manufacturing M&S tools 202F-202G).

[0083] In any of the examples described above, the computing system 208 can receive data transmitted from the user device 206A and / or API 206B, process the data, and evaluate whether the common V&V product in question (e.g., regulatory standard 210E, medical standard 210G, medical certification rule 210H, manufacturing standard 210I, manufacturing certification rule 210J, etc.) is met by the user's digital prototype in the context of the analysis and control plane 150 shown in Figure 1. For example, this may involve communicating with the common V&V product repository 210 via API / SDK 216 to retrieve the relevant common V&V product in question, and processing the regulatory and / or certification data associated with the common V&V product to identify one or more requirements for a UAV prototype, a drug, compound, or biologic prototype, a manufacturing process prototype, etc. In some embodiments, the repository 210 for common V&V products may be hosted by a regulatory and / or certification authority (or another third party), and retrieving regulatory and / or certification data may involve interfacing with one or more data resources maintained by the regulatory and / or certification authority (or another third party) using the API / SDK 216. In some embodiments, regulatory and / or certification data may be provided directly by user 204 (e.g., along with prototype data) via user device 206A and / or API 206B.

[0084] Evaluating whether the target common V&V product is met by the user's digital prototype may also involve processing the prototype data received from the user device 206A or API 206B to determine whether one or more identified requirements are actually met. In some embodiments, the computing system 208 may include one or more plug-ins, local applications, etc., for processing the prototype data directly on the computing system 208. For example, model splicing and digital threading applications will be described in detail later with reference to Figures 6-9. In some embodiments, the computing system may simply preprocess the received prototype data (for example, to derive input to the DE tool 202) and then send instructions and / or input data to a subset of the DE tool 202 via the API / SDK 214 for further processing.

[0085] Not all DE tools 202 are necessarily required to meet specific regulations and / or certification standards. Therefore, in the example of the UAV provided in Figure 2, the computing system 208 may determine that only the data analysis tool 202A and the finite element analysis tool 202B are required to meet the regulatory standard 210E for failure conditions. In the example of a drug, compound, or biologic provided in Figure 2, the computing system 208 may determine that only the drug M&S tools 202D-202E are required to meet the medical standard 210G and the medical certification rule 210H. In the example of a manufacturing process provided in Figure 2, the computing system 208 may determine that only the manufacturing M&S tools 202F-202G are required to meet the manufacturing standard 210I and the manufacturing certification rule 210J. In other embodiments, if user 204 is a qualified subject matter expert (SME), user 204 may identify the specific subset of DE tools 202 that should be used to meet the common V&V product in question. In other embodiments, user 204 may input several proposed DE tools 202 to satisfy the common V&V product of interest into computing system 208, and computing system 208 may recommend a modified subset of DE tools 202 to user 204 for final approval, provided that user 204 is a qualified SME. After the subset of DE tools 202 has been identified, computing system 208 may then send instructions and / or input data to the identified subset of DE tools 202 to perform one or more models, tests, and / or simulations. The results of these models, tests, and / or simulations (or “Engineering-Related Data Outputs” or “Digital Artifacts”) may be returned to and received by computing system 208.

[0086] In yet another embodiment, user 204 may input the necessary DE tools, such as 202F, to satisfy common V&V product 210I, and computing system 208 may determine that another DE tool, such as 102G, is also required to satisfy common V&V product 210I. The computing system may then send instructions and / or input data to both DE tools (e.g., 202F and 202G), and the outputs of these DE tools may be transmitted and received by computing system 208. In some cases, the input data submitted to one of the DE tools (e.g., 202G) may be derived (e.g., by computing system 208) from the output of the other DE tool (e.g., 202F).

[0087] After receiving engineering-related data output or digital artifacts from the DE tool 202, the computing system 208 may then process the received engineering-related data output to evaluate whether the requirements identified for the common V&V product in question (e.g., regulatory standard 210E, medical standard 2110G, medical certification rule 210H, manufacturing standard 210I, manufacturing certification rule 210J, etc.) are met. For example, the application and service 222 may provide instructions for orchestrating validation or verification activities. In some embodiments, the computing system 208 may generate a report summarizing the evaluation results and send the report to device 206A or API 206B for review by user 204. If all requirements are met, the prototype can be certified, resulting in a digitally certified product 212 (e.g., a digitally certified drug, compound, or biologic 212A, a digitally certified UAV 212B, a digitally certified manufacturing process 212C, etc.). However, if some regulatory requirements are not met, additional steps may need to be taken by User 204 to certify the product prototype. In some embodiments, the report sent to the user may include recommendations for these additional steps (e.g., suggestions for one or more design changes, suggestions for replacing one or more components with previously designed solutions, suggestions for one or more adjustments to the inputs for models, tests, and / or simulations). If the requirements for the common V&V product are partially met or exceed the collective capabilities of the distributed engineering tools 202, the computing system 208 may provide User 204 with a report recommending partial certification, compliance, or performance of the common V&V product (e.g., digital certification of a subsystem or subprocess of the prototype). The process for generating recommendations for User 204 is described in more detail below.

[0088] In response to the report review, user 204 can make local design changes to the digital prototype and / or send one or more instructions to computing system 208 via user device 206A or API 206B. These instructions may include, for example, instructions for computing system 208 to re-evaluate the updated prototype design, use one or more different DE tools 202 for the evaluation process, and / or modify the inputs to DE tools 202. Computing system 208 then receives the user instructions, performs one or more additional data operations in accordance with these instructions, and may provide user 204 with an updated report. Through this iterative process, user 204 can leverage the interconnected digital engineering and certification ecosystem to design and ultimately certify (for example, by providing certification compliance information) prototypes (e.g., UAV prototypes, drug prototypes, manufacturing process prototypes, etc.) with respect to the common V&V product of interest. Importantly, because all of these steps occur in the digital world (e.g., using digital prototypes, digital models / tests / simulations, and digital certifications), a considerable amount of time, cost, and material can be saved compared to processes involving physical prototyping, evaluation, and / or certification, such as similar UAVs, drugs, and manufacturing processes. If the requirements associated with the common V&V product are partially met or exceed the collective capabilities of DE tool 202, computing system 208 may provide user 204 with a report recommending partial certification, compliance, or performance (e.g., digital certification of a subsystem or subprocess of a prototype) of a subset of the common V&V product.

[0089] While the above example focuses on the use of an interconnected digital engineering and authentication ecosystem by a single user, additional benefits of the ecosystem can be realized through repeated use by multiple users. As mentioned above, by placing computing system 208 at the center of the ecosystem architecture, computing system 208 can monitor and store various data flows through the ecosystem. Therefore, as the number of users utilizing the ecosystem for digital product development increases, data associated with each use of the ecosystem can be stored (e.g., in storage 218), tracked (e.g., with metadata), and analyzed to yield various insights. These insights can be used to further automate the digital product development process and make it easier to navigate the digital product development process for non-subject experts.

[0090] In fact, in some embodiments, user credentials for user 204 can indicate user 204's skill level and control the amount of automated assistance provided to the user. For example, non-subject experts may only be permitted to use the ecosystem to browse pre-made designs and / or solutions, use DE tool 202 with specific default parameters, and / or follow a predetermined workflow while automated assistance guides user 204 through the product development process. On the other hand, more skilled users may still be provided with automated assistance, but may be given more opportunities to override default or suggested workflows and settings.

[0091] In some embodiments, the computing system 208 may host applications and services 222 that automate or partially automate expected or common data transmissions from users 204, including components of common V&V products and data transmission components; expected or common interfaces and / or data exchanges between various DE tools 202, including interface components; expected or common interfaces and / or data exchanges with machine learning (ML) models implemented on the computing system 208 (e.g., models trained and / or implemented by the ML engine 220); and expected or common interfaces and / or data exchanges between applications and services themselves (e.g., within the application and service layer 222).

[0092] In some embodiments, data from multiple uses of the ecosystem (or a portion of the data described above) may be aggregated to develop a training dataset. For example, usage records 222 collected via computing system 208 may be despecificated or anonymized before being added to the training set. Such usage records may include model parameters and metadata, tool configurations, common V&V products that match a particular model or tool, user interactions with the system including inputs and actions, and other user-defined or system-defined configurations or decisions when using the ecosystem for digital engineering and authentication. For example, an exemplary despecificated usage record may include a combination of a specific DE tool, a specific target metric, a specific quantitative deviation, and a corresponding specific user update to the DE tool under this configuration. Another exemplary despecificated usage record may include a user-specific subset of DE tools 202 that should be used to meet the common V&V product in question.

[0093] This training dataset can then be used to train an ML model (for example, using the ML engine 220) to learn the steps and actions about the certification process, and to perform various tasks including identifying which DE tool 202 to use to satisfy specific common V&V products, identifying specific models, tests, and / or simulations (including their inputs) to be performed using DE tool 202, identifying common V&V products that need to be considered for specific types of products, identifying one or more recommended actions for user 204 to be taken in response to failure to meet regulatory requirements, and estimating the sensitivity of the model / test / simulation to specific inputs. The output of the trained ML model can be used to implement various features of the interconnected digital engineering and certification ecosystem, including automatically suggesting inputs (e.g., inputs to DE tool 202) based on previously performed inputs, predicting time and cost requirements for developing a product, predictively estimating the results of sensitivity analysis, and further suggesting design changes, original designs, or design alternatives to the user's prototype (e.g., via assistive AI or generative AI) to overcome one or more requirements (e.g., regulatory and / or certification requirements) associated with common V&V products. In some embodiments, with sufficient training data, the ML engine 220 may independently generate new designs, models, simulations, tests, common V&V products, and / or digital threads based on data collected from multiple uses of the ecosystem. Furthermore, such new designs, models, simulations, tests, common V&V products, and digital threads generated by the ML engine 220 may be added to the training set for further fine-tuning of the ML algorithm in a reinforcement learning setup, once approved and refined by the user.

[0094] As illustrated in the context of Figures 7-9 and 11-33, the aforementioned collection of training datasets, as well as the training of ML and AI modules, including the ML engine 220, can be enabled by model splicing techniques. The model splicing described herein enables the scripting of DE model behavior, encompassing heterogeneous DE tools within a corpus of prescriptive program code, and facilitates the code-definition digital threading of a large space of DE activities involving DE models across different domains. Using ML and AI techniques, scripts may be created to perform virtually any DE task and any digital thread, enabling programmable and machine-learnable dynamic changes to DE model files, digital threads, and ultimately digital or physical twins throughout the product lifecycle. For example, in the embodiment shown in Figure 2, the ML engine 220 can manage or orchestrate interactions between spliced ​​DE models, DE tools, and common V&V products (e.g., DE requirements) based on user intent and input-specific digital thread options. Sample DE tasks that can be performed by the ML engine 220 include, but are not limited to, (1) aligning models / analyses to authentication lifecycle requirement steps, (2) optimizing computations by determining appropriate fidelity for each model, (3) optimizing computational resources for a specific tool / model, or (4) optimizing computational resources across multiple models. The ML-enabled execution of DE tasks is not limited to authentication or resource optimization, but encompasses the entire DE operation space. Rather, the ML engine 220 can function as an AI multiplexer for the DE platform.

[0095] In addition to storing data used to enable the development of ML models, previous prototype designs and / or solutions (e.g., previously designed components, systems, models, simulations, and / or other engineering representations thereof) may be stored within the ecosystem (e.g., within storage 218) to enable users to search for and build upon the work of other users. For example, previously designed components, systems, models, simulations, and / or other engineering representations thereof may be searched by user 204 and / or suggested to user 204 by computing system 208 to meet one or more requirements associated with a common V&V product. Previously designed components, systems, models, simulations, and / or other engineering representations thereof may be used as is by user 204 or as a starting point for additional modifications. This store or repository of previously designed components, systems, models, simulations, and / or other engineering representations (whether they are ultimately certified or not) may be monetized to create a marketplace for digital products, which may be used to save time during the digital product development process, to allow users to recall alternative design ideas, and to avoid redundant efforts. In some embodiments, data corresponding to previous designs and / or solutions may be stored only if the user who developed the design and / or solution chooses to share the data. In some embodiments, the repository of previous designs and / or solutions may be containerized for private use within a single company, team, organizational entity, or technical field for private use (for example, to avoid the undesirable disclosure of confidential information). In some embodiments, user credentials associated with user 204 may be checked by computing system 208 to determine which designs and / or solutions stored in the repository are accessible to user 204.In some embodiments, the use of previously designed components, systems, models, simulations, and / or other engineering representations thereof may be available only to other users who pay a fee for their use.

[0096] Exemplary IDEP implementation architecture with services and features Figure 3 shows another exemplary embodiment of IDEP, illustrating the services and features provided by several embodiments of the present invention. Specifically, Figure 3 shows an exemplary implementation architecture, 300, which includes several exemplary components, namely, an IDEP enclave 302, a cloud service 304, and a customer environment 310, which optionally includes an IDEP exclave 316. This exemplary architecture 300 of IDEP is designed in accordance with zero-trust security principles and is further designed to support scalability and robust, resilient operation. Both the IDEP enclave 302 and the IDEP exclave 316 instantiate IDEP 100 shown in Figure 1, and the IDEP exclave 316 implements model splicing and splice plane 170 in several embodiments of the present invention. An enclave is an independent set of cloud resources that are partitioned to be accessed by a single customer (i.e., single-tenant) or market (i.e., multi-tenant) without depending on the resources of other enclaves. An exclave is a set of cloud resources outside of an enclave, managed by IDEP, for performing work for individual customers. An example of an exclave would include virtual machines (VMs) and / or servers that IDEP maintains to run DE tools for customers who require such services.

[0097] In particular, the IDEP enclave or DE platform enclave 302 may function as the origin of services rendered by IDEP and may be visualized as a central command and control hub responsible for managing and orchestrating all platform operations. For example, enclave 302 may be implemented using the interconnected DE and authentication ecosystem computer system 208 shown in Figure 2. The DE platform enclave 302 is designed to integrate both a zero-trust security model and hyperscale capabilities, resulting in a secure and scalable processing environment tailored to individual customer needs. Zero-trust security features include, but are not limited to, strict access control, algorithmic fairness, and data isolation. Enclave 302 also supports ML engines such as 220 for real-time analytics, auto-scaling features for workload adaptability, and API-based interoperability with third-party services. Security and resource optimization are enhanced through multi-tenant support, role-based access control, and data encryption both at rest and in transit. The DE platform enclave 302 may also include one or more of the features described below.

[0098] Firstly, the IDEP Enclave 302 may be designed in accordance with zero-trust security principles. In particular, the DE Platform Enclave 302 may adopt zero-trust principles to ensure that no implicit trust is assumed between any elements within the system, such as the digital model, platform agents, or individual users (e.g., user 204) or their actions. That is, there are no agents that can inherently be trusted, and the system can always authenticate or authorize for a particular job. The model is further reinforced through a strict access control mechanism, restricting even the management team (e.g., a team of individuals associated with the platform provider) to predetermined limited access to the enclave resources. To further enhance this robust security stance, data encryption is applied both at rest and in transit to effectively mitigate the risk of unauthorized access and data breaches.

[0099] IDEP Enclave 302 can also be designed to maintain isolation and independence. A key aspect of the Enclave's architecture is its focus on fairness and isolation. DE Enclave 302 enforces a strong isolation policy by not allowing cryptographic dependencies from external Enclaves. The Enclave's design also allows for both single-tenant and multi-tenant configurations, further enhancing data and process isolation between customers 306 (e.g., user 204). Additionally, DE Enclave 302 is designed with a decoupled set of resources, minimizing interdependencies and thereby promoting system efficiency and autonomy.

[0100] The IDEP Enclave 302 can also be designed to better accommodate changing operating requirements for scalability and adaptability. For example, the Enclave 302 can incorporate hyperscale-like characteristics in conjunction with zero-trust principles to enable scalable growth and effectively handle high-performance workloads.

[0101] IDEP Enclave 302 can also be designed to accommodate various customer workflows and DE models through a rigorous access control mechanism for workflow adaptability. This configurability enables a modular approach that integrates different functions from data ingestion to algorithm execution without compromising a zero-trust security posture. The adaptability of Platform 300 ensures high versatility for numerous use cases while maintaining consistent performance and robust security.

[0102] The IDEP Enclave 302 may be further designed to enable analytics for robust platform operation. The core of the Enclave's operational efficiency is a machine learning engine (e.g., machine learning engine 220) capable of performing real-time analytics. This improves decision-making and operational efficiency across the entire Platform 300. An auto-scaling mechanism may also be included to enable dynamic resource allocation based on workload demands, further enhancing the platform's responsiveness and efficiency.

[0103] In the exemplary embodiment shown in Figure 3, the IDEP enclave 302 includes several components, which will be described in further detail herein.

[0104] The "Monitoring Service Cell" may provide "Monitoring Services" and "Telemetry Services." A cell may refer to a set of microservices, for example, a set of microservices running within a Kubernetes pod. These components are focused on maintaining, tracking, and analyzing the performance of Platform 300 to ensure good service delivery, including advanced machine learning capabilities for real-time analysis. The "Search Service Cell" provides "Search Services" to help efficiently retrieve information from DE Platform 300 and add it to its overall functionality. The "Logging Service Cell" and "Control Plane Service Cell" provide "Logging Services," "File Services," and "Job Services" to record and manage operational events and information flows within Platform 300 that assist in the functionality of Platform 300. The "Static Asset Service Cell" provides "Static Services" and may house user interfaces, SDKs, command-line interfaces (CLI), and documentation for Platform 300. The "API Gateway Service Cell" may provide the "API Gateway Service" and may provide DE Platform APIs (or APIs 214, 216) (e.g., APIs 214, 216), and may act as an intermediary for requests between client applications (e.g., DE Tools 202, Common V&V Product Repository 210, etc.) and the Platform Service. In some embodiments, the API Gateway Service Cell may receive and respond to requests from agents such as the DE Platform Exclaver 316 in order to provide splice functions for model splicing purposes.

[0105] As shown in Figure 3, the architecture of the DE platform 300 may also include cloud services 304 that provide services that can modify software for orchestration of DE platform operation, although they cannot interact with customer data. In exemplary embodiments, several cloud resources provide support and basic services to the platform. For example, in the embodiment of the DE platform 300 shown in Figure 3, cloud services 304 include a "Customer Identity and Access Management (IAM) service" that ensures secure and controlled access to the platform 300. Cloud services 304 also include a "Testing service" that tests tools for validating the operation of the platform. Cloud services 304 may also include an "Orchestration service" that controls and manages the lifecycle of containers on the platform 300. Cloud services 304 may also include "Artifacts services" and "Version Control and Build services" which may be used to manage artifacts created during the product development process while maintaining the evolution of projects, code, and instances within the system.

[0106] As shown in Figure 3, the architecture of the DE platform 300 may also include a customer environment 310 with a “trusted true source” 312, customer tools 314, and an optional DE platform exclave 316. The customer environment 310 is the environment in which customer data resides and is processed by the DE platform 300 in a zero-trust manner. As previously mentioned, the DE platform enclave 302 provides a robust and scalable environment for securely handling critical workloads according to customer-specific needs by focusing on both zero-trust principles and characteristics such as hyperscale. In some examples, the DE platform exclave 316 may be located within the customer environment 310 to assist customer(s) 306 with their DE tasks and operations, including model splicing and digital threading.

[0107] If a customer 306 (e.g., user 204) intends to perform DE tasks using a DE platform 300 (e.g., IDEP 100), typical operations may include secure data ingestion and controlled data retrieval. Derived data generated through DE operations, such as revisions to updated digital model files or digital model parameters, may be stored only within the customer environment 310, and the DE platform 300 may provide tools to access metadata of the derived data. Here, metadata refers to data that can be viewed without opening the original data and may include version control information, timestamps, access control characteristics, etc. An exemplary embodiment may include secure data ingestion, which leverages zero-trust principles to ensure that customer data is securely uploaded to the customer environment 310 through a pre-verified secure tunnel, such as a Secure Sockets Layer (SSL) tunnel. This may enable direct and secure file transfer to designated cloud storage, such as a Simple Storage Service (S3) bucket, within the customer environment 310. An exemplary embodiment may also include controlled data retrieval, in which a temporary, pre-authenticated URL generated by a secure token-based mechanism is used for controlled data access, thereby minimizing the risk of unauthorized interaction. An exemplary embodiment may also include immutable derived data, in which transformed data generated through operations such as data extraction is securely stored within the customer environment 310 in compliance with zero-trust security protocols. An exemplary embodiment may also include a tokenization utility, in which a dedicated DE platform tool called a “tokenizer” is deployed within the customer environment 310 for the secure management of derived metadata in accordance with zero-trust guidelines.

[0108] The customer environment 310 may interact with other elements of the secure DE platform 300 and includes several features that handle data storage and secure interaction with the platform 300. For example, one element of the customer environment 310 is the “Trusted True Source” 312, which is the primary repository of customer data and guarantees data integrity and accuracy. Nested within this is the “Customer Bucket,” where data is securely stored with strict access control and data access is restricted to authorized users or processes through pre-authenticated URL links. This setup provides seamless interaction with other elements of the DE platform 300 while ensuring uncompromising data security within the customer environment 310.

[0109] The customer environment 310 may also include additional software tools, such as customer tools 314, which can be used based on specific customer requirements. For example, the “DE Tool Host” component may handle the DE applications necessary to manipulate customer data. It may include a DE Tool Command Line Interface (DET CLI) that enables user-friendly command-line operation of DE tools (e.g., DE Tool 102). The “DE Platform Agent” ensures smooth communication and management between the customer environment 310 and the elements of the DE Platform 300. Furthermore, there may be another set of optional DE tools designed to support customer-specific DE workflows. Native DE tools are typically restricted in access by proprietary licenses and end-user license agreements for which the customer pays. IDEP platform functions call native DE tools running within the customer environment 310, thereby strictly adhering to the zero-trust principle of the system design. Exemplary DE tools include, but are not limited to, proprietary and open-source versions of model-based systems engineering (MBSE) tools, augmented reality (AR) tools, computer-aided design (CAD) tools, data analysis tools, modeling and simulation (M&S) tools, product lifecycle management (PLM) tools, multi-attribute transaction space tools, simulation engines, requirements modeling tools, electronic modeling tools, test plan modeling tools, cost modeling tools, scheduling modeling tools, supply chain modeling tools, manufacturing modeling tools, cybersecurity modeling tools, or mission effectiveness modeling tools.

[0110] In some cases, an optional "IDEP Exclaver" 316 may be deployed within the customer environment 310 to support the customer's DE tasks and operations, oversee data processing, and provide hyperscale-like platform performance while strictly adhering to zero-trust principles. The IDEP Exclaver 316 is maintained by IDEP to run DE tools for customers requiring such services. The IDEP Exclaver 316 may include a "DE Tool Host" that runs the DE tools and a "DE Platform Agent" necessary for their operation. In this case as well, the native DE tools are typically restricted in access by proprietary licenses and end-user license agreements for which the customer pays. The IDEP Exclaver 316 utility manages proprietary DE tools hosted in the customer environment 310, for example, to implement model splicing and digital threading capabilities.

[0111] IDEP Deployment Scenario Figure 4 illustrates potential scenarios for instantiating an IDEP connected to a customer's physical system and IT environment according to several embodiments of the present invention. Specifically, Figure 4 illustrates various potential configurations for instantiating or instantiating an IDEP ("DE Platform") 402 connected to a customer's IT environment and physical system 404. The IT environment may reside on a firewall-protected virtual private cloud (VPC). The physical system may refer to a physical twin, as described with reference to Figure 1. In some embodiments, IDEP 402 may be instantiated as an enclave, such as 302 shown in Figure 3. For example, IDEP 402 may be instantiated on the cloud, perhaps in a Software as a Service (SaaS) configuration. The platform instance in these embodiments includes software and algorithms and may be described as follows: 1. External Platform Instance 410: This option presents the IDEP as a separate platform instance. The platform interacts with the physical system through the customer's virtual environment or the customer's virtual private cloud ("Customer VPC"), which is connected to the physical system. 2. External Platform Instance 420 with Internal Agent: The IDEP is instantiated as a separate platform connected to an internal agent ("DE Agent") fully instantiated within the customer's VPC. For example, the IDEP may be instantiated as enclave 302, and the DE Agent may be instantiated as exclave 316 in the customer's VPC linked to a physical system. 3. External Platform Instance 430 with Internal Agent and Edge Computing: This scenario views the IDEP as a separate instance, connected to an internal DE agent fully instantiated within the customer's VPC, with the internal DE agent further linked to edge instances on the physical system ("DE Edge Instances"). The DE agents are nested within the customer's environment with smaller edge computing instances attached to the physical system. 4. Edge Instance Connection 440: This option indicates a DE platform directly linked to a DE edge instance on a physical system. The DE platform and physical system are shown separately, connected by an intermediate edge computing instance, illustrating the data flow. 5. Direct API Connection 450: This deployment scenario illustrates a DE platform that connects directly to a physical system via API calls. In this depiction, arrows extend directly from the platform's domain to the physical system's domain, signifying direct interaction through the API. 6. Air-Gapped Platform Instance 460: This scenario demonstrates that IDEP, as a DE agent, is fully instantiated on an air-gapped or isolated physical system. The platform operates independently of any network or internet connectivity, providing an additional layer of security by eliminating external access points and potential threats. Interaction with the platform in this context occurs directly on the physical system, and any data exchange outside the physical system is controlled according to strict security protocols to maintain the air-gapped environment.

[0112] Throughout these deployment scenarios, IDEP plays a crucial role in bridging the gap between the digital twin (DTw) established through IDEP and its physical counterpart. Regardless of how IDEP is instantiated, IDEP interacts with physical systems directly or through the customer's virtual environment. The use of edge computing instances in some scenarios demonstrates the need for localized data processing and the trade-off between real-time analytics and more precise insights in digital-physical system management. Furthermore, the platform's ability to connect directly to physical systems via API calls highlights the importance of interoperability in facilitating efficient data exchange between the digital and physical worlds. In all cases, the DE platform operates with robust security measures in place.

[0113] In some embodiments, IDEP deployments for the same physical system may include combinations of the deployment scenarios described above. For example, for the same customer, some physical systems may have direct API connectivity to the DE platform (Scenario 5), while others may have edge instance connectivity (Scenario 4).

[0114] Multimodal User Interface Figure 5 illustrates the use of a multimodal user interface 590 for an interconnected DE platform capable of handling various input and output modalities, including virtual reality (VR), mixed reality (MR), auditory, text, and code. These interfaces are designed to manage the complexity of data streams and decision-making processes, and to provide decision support, including option visualization, impact prediction, and invocation of specific decisions. Specifically, data streams 502 and 504 are processed by the analysis and control plane (ACP) 150 in Figure 1. The user interface can receive data streams from physical feedback loops 102 and virtual feedback loops 104, as well as from external expert feedback 114, analysis module 154, and a twin configuration set 156 of the ACP 150.

[0115] The multimodal interface shown in Figure 5 is configured to perform all DE tasks and actions described in the context of Figure 1 by accommodating both humans and bots / algorithms, and by handling complex issues such as the frequency and complexity of data streams, the timescale of decision-making, and the impact of latency. For human decision-makers, the user interface may need to manage inputs and outputs, while for algorithmic decision-making, the user interface may need to present rationale and decision analysis to the human user. Some examples of human interfaces include a dashboard interface 594, a workflow-based interface 596, a conversational interface 598, a spatial computer interface 592, and a code interface 599.

[0116] The dashboard interface 594 provides a customizable overview of data visualizations, performance metrics, and system status indicators. This enables monitoring of relevant information, partial review of documents, and decision-making based on dynamic data updates and external feedback. Such interfaces may be accessible via web browsers and standalone applications on various devices.

[0117] The workflow-based interface 596 guides the user through the decision-making process, presentation of relevant data, options, and contextual information at each stage. It integrates external feedback and is designed as a progressive web or mobile app. In the context of alternative tool selection, the workflow-based interface 596 may provide options on individual tools at each stage, or it may provide combinations of tool selections across various stages to achieve better accuracy or efficiency for the overall workflow.

[0118] The conversational interface 598 converts various input formats, such as text, prompts, voice, and audiovisual, into input text, which is then integrated into the DE platform workflow. Output from the DE platform may undergo the reverse process. This enables interoperability with the DE platform and, specifically, the manipulation of model splices. In the broader context of audiovisual input, the conversational interface may include data acoustics, which involves using sound to represent data, information, or events, and using auditory cues or patterns to communicate critical information to users, operators, or reviewers. Acoustic alerts (e.g., alerts transmitted via speakers, e.g., by voice) are particularly useful when individuals need to process information quickly without needing to visually concentrate on a screen. For example, acoustic alerts can be used to notify security analysts of potential threats or breaches.

[0119] Figure 5 also illustrates the use of the spatial computing interface 592 and the code interface 599 in the management of DTw and PTw. The spatial computing interface enables a more immersive and intuitive user experience and allows for real-time synchronization between DTw and PTw. The code interface allows bots and digital engineers to interact with the DE platform through scripts and code. The code interface also allows for the collection of user preferences, task history, and tool usage patterns for the purpose of selecting alternative tools.

[0120] Digital threads and autonomous data linkages As mentioned above, a "digital thread" is intended to connect two or more digital engineering (DE) models for traceability throughout the entire system engineering lifecycle and for collaboration and sharing among individuals performing DE tasks. In a digital thread, appropriate outputs from a preceding digital model may be provided as inputs to a subsequent digital model, thereby enabling information and process flow. In other words, a digital thread can be seen as a communication framework or data-driven architecture that connects traditionally siloed elements to enable the flow of information and actions between digital models.

[0121] Figure 6 illustrates the architecture and inherent complexity of digital threads by example disclosed herein. Specifically, Figure 6 is a schematic diagram comparing exemplary digital threads 600 of various complexityes for manipulating and / or connecting DE models by several embodiments of the present invention. In its most basic sense, a digital thread may “thread” DE models into a simple daisy-chain architecture 602, where any modification of an upstream DE model affects all downstream DE models of the modified DE model. For example, any modification of a parameter or process in DE model B causes a change in DE model C, which in turn causes a change in DE model D. Changes in causality thus cascade downstream. As another example, Figure 604 represents a more complex digital thread where a change in one DE model may affect one or more downstream models. In both 602 and 604, the digital threads are represented by a directed acyclic graph (DAG).

[0122] DAGs are frequently used in many types of data processing and structuring tasks, such as task scheduling and data compression algorithms. In the context of service platform and network complexity, DAGs may be used to represent relationships between different components or services within a platform. In digital threads 604, different models may depend on each other in different ways. Model A may influence models B, C, and D, models B and C may influence model E, and models D and E may influence model G. Such dependencies can be represented as a DAG, where each node is associated with a component (e.g., a model) and each directed edge represents a dependency.

[0123] A major problem with dealing with interdependent DE models is that the consistency of the graph can be polynomial in complexity, and potentially exponential. Therefore, if a node fails (e.g., the model becomes unreliable), this can cascade to the rest of the digital thread, potentially disrupting the entire design. Furthermore, adding nodes or dependencies to the graph does not result in a linear increase in complexity due to interdependencies between models. If a new model is added that affects or depends on several existing models, the resulting increase in graph complexity is essentially multiplicative, and therefore potentially exponential. The multiplicative nature of digital thread consistency is exacerbated by the enormous number of interconnected models, which can reach hundreds or even thousands. Diagram 606 is a partial representation of a real-world digital thread, illustrating the complexity of a digital thread and its multiplicative growth.

[0124] Figure 6 further illustrates specific cases 603, 605, 607, 608, and 609 of exemplary simple digital threads. Diagram 607 represents a degenerate digital thread where data is shared from a single DE model. Diagram 608 represents a model-versus-document digital thread, where data extracted from a single DE model (e.g., system attributes, performance attributes) can be used to generate or update a text-based document (e.g., a Capability Development Document (CDD)). Diagrams 603 and 605, generalized from 608, represent cases where data extracted from a single model can be used to update multiple models, and vice versa. Specifically, diagram 605 may represent the dynamic updating of a live document or magic document as described in the context of Figure 1. Here, the logic connecting the DE models shown is very simple, with data extracted from multiple DE models A, B, and C to update document model D. There is no interaction between the extracted data. Furthermore, diagram 609 illustrates a special case of digital threads where data is loaded into and extracted from a single model A. For example, as discussed below in the context of Figure 7, the input splice function of model A shown in 609 may be executed to update the model, and the output splice function of model A shown in 609 may be executed to produce a digital artifact for sharing. For these special simple threads, IDEP may provide the user with a GUI-based interface to connect the models and execute the digital threads. For complex threads like those in 606, a code-based interface may be required.

[0125] Model splicing for digital threading and digital twin generation As disclosed herein, model splicing encapsulates and partitions digital engineering (DE) model data and model data manipulation and access functions. Therefore, model splicing provides selective access to model data within a DE model file without exposing the entire DE model file, using access control to the encapsulated model data based on user access rights. Model splicing also provides DE models with a common, externally accessible application programming interface (API) for programmatically executing the DE model. Model splices thus generated can be shared, executed, modified, or further spliced ​​independently of the native DE tools and development platforms used to generate the input digital models. Standardization of DE model data, as well as generalization of API interfaces and functions, enables access to DE model type files outside of native software environments and allows linking of different DE model type files that might previously be incompatible. Model splicing further enables the scripting and coding of DE behavior, encompassing heterogeneous DE tools within a corpus of prescriptive program code, and facilitates the generation and training of artificial intelligence (AI) and machine learning (ML) models for the purpose of manipulating DE models through various DE tools across different stages of the DE process, DE workflow, or DE lifecycle.

[0126] Digital threads are created through user-instructed and / or autonomous linking of model splices. Digital threads are intended to connect two or more DE models for traceability throughout the entire system engineering lifecycle, as well as for collaboration and sharing among individuals performing DE tasks. In a digital thread, appropriate outputs from a preceding digital model are provided as inputs to a subsequent digital model, enabling information flow. In other words, a digital thread can be seen as a communication framework or data-driven architecture that connects traditionally siloed elements, enabling the flow of information between digital models. The extensibility of model splicing across many different types of DE models and DE tools allows for the scaling and generalization of digital threads to represent each and every stage of the DE lifecycle.

[0127] A digital twin (DTw) is a real-time virtual replica of a physical object or system with a bidirectional flow of information between a virtual domain and a physical domain, enabling monitoring, analysis, and optimization. Model splicing allows individual DE model files to be created into executable splices that can be linked autonomously and securely, thereby enabling the management of numerous DE models as a unified digital thread. This capability extends to linking previously incompatible DE models to create a digital thread, receiving external performance and sensor data streams (e.g., aggregated data from DE models or linked data from physical sensor data), calibrating the digital twin using data streams from physical sensors outside the native DTw environment, and receiving expert feedback that provides opportunities to improve simulation and model parameters.

[0128] Unlike a digital twin (DTw), a virtual replica, or simulation, is a mathematical model that mimics real-world behavior to predict outcomes and test strategies. While a digital twin uses real-time data and has bidirectional communication, a simulation focuses on scenario analysis and outcome prediction. In other words, a DTw reflects the state of a physical system in time and space. A simulation is a series of actions performed on a digital model that reflect potential future states or outcomes that the digital model may undergo in the future. A simulation model is a DE model in the context of an IDEP, as disclosed herein.

[0129] When testing different designs, such as variations in wing length or chord dimensions, multiple DTws (sometimes numbered 100-1000) may be created to bridge the gap between the system's design specifications and real-world embodiments, enabling seamless updating and tracking of variations across a vast number of variables, as detailed in the context of Figure 1. For example, if three variations of a system are created, each will have its own DTw with specific measurements. These DTws may be accessed and updated via API function scripts, allowing for easy input of new measurements from physical parts during the manufacturing process. By autonomously linking with appropriate data, DTws may be updated to reflect actual measurements of the part, maintaining traceability and ensuring accurate data representation across hundreds or thousands of models.

[0130] Exemplary Model Splicing Setup Figure 7 is a schematic diagram showing an exemplary model splicing setup according to several embodiments of the present invention. Specifically, Figure 7 is a schematic diagram showing an example of embedded CAD model splicing.

[0131] In this disclosure, a “model splice,” “model wrapper,” or “model graft” of a given DE model file includes (1) DE model data or digital artifacts extracted or derived from the DE model file, including model metadata, and (2) locators or copies thereof for splice functions (e.g., API function scripts) applicable to the DE model data. A model splice may take the form of a digital file or a group of digital files. A locator refers to a link, address, pointer, index, access key, uniform resource locator (URL), or similar reference to the aforementioned DE digital artifacts and splice functions, which themselves may be stored in an access-controlled database, a cloud-based storage bucket, or other type of secure storage environment. Splice functions provide unified and standardized input and output API endpoints or SDK endpoints for accessing and manipulating the DE model data. The DE model data is model type specific, and the model splice is associated with model type specific input and output schemas. One or more different model splices may be generated from the same input DE model file, based on a particular user application under consideration and subject to data access restrictions. In some contexts, the shorter terms “splice,” “wrapper,” and / or “graft” are used to refer to spliced, wrapped, and / or grafted models.

[0132] Model splicing is the process of generating model splices from DE model files. Correspondingly, a model splicer is program code or an uncompiled script that performs model splicing of a DE model. A DE model splicer for a given DE model type, when applied to a specific DE model file of that DE model type, retrieves, extracts, or derives the DE model data associated with the DE model file, generates and / or encapsulates a splice function, and instantiates an API endpoint or SDK endpoint to the DE model according to its input / output schema. In some embodiments, a model splicer includes a collection of API function scripts that can be used as templates for generating DE model splices. "Model splicer generation" refers to the process of setting up a model splicer, which includes establishing a comprehensive framework or template from which individual model splices can be inferred.

[0133] Therefore, a DE model type-specific model splicer extracts or derives model data from a DE model file and / or stores such model data in a model type-specific data structure. The DE model splicer further generates or enumerates splice functions that can call native DE tools and API functions for the application to the DE model data. A DE model splice for a given user application contains or wraps DE model data and splice functions specific to the user application, allowing access to only a limited portion of the original DE model file and enabling modification of that limited portion for collaboration and sharing with stakeholders of the given user application.

[0134] Additionally, a document splicer is a specific type of DE model splicer specific to a document model. A “document” is an electronic file that provides information as a public record. Documents include human-readable files that can be read without specialized software, and machine-readable documents that can be viewed and manipulated by humans with the help of specialized software such as word processors and / or web services. Thus, a document may include natural language-based text and / or graphics that are directly readable by humans without requiring additional machine compilation, rendering, visualization, or interpretation. A “document splice,” “document model splice,” or “document wrapper” for a given user application may be generated by wrapping document data and splice functions (e.g., API function scripts) specific to that user application, thus revealing text at the component or part level (e.g., title, content table, chapter, section, paragraph) via an API endpoint or SDK endpoint, allowing access to portions of the original document or document template for collaboration and sharing with stakeholders of a given user application, enabling modification while minimizing manual referencing and human error.

[0135] In the CAD model splicing example shown in Figure 7, the CAD model file diesel-engine.prt704 proceeds through a model splicing process 710, which includes a data extraction step 720 and a splice function generation step 730. This input DE model 704 is in a file format specific to the particular DE tool, .prt. Data extraction is performed via a DE model crawling agent, implemented as a model crawling script within the model splicer, which crawls the input DE model file and distills the model data with metadata 722. Metadata is data that can be viewed without opening the entire input DE model file and may include entries such as file name, file size, file version, last modified date and time, and potential user input options identified from user input 706. Model data is extracted and / or derived from the input DE model and may include, but is not limited to, parts (e.g., propeller, engine cylinder, engine cap, engine radiator, etc.), solids, surfaces, polygon representations, and materials. When the model splicer crawls the model files, it determines how to organize and access the model data as essentially defined by the DE tool 702 used for splicing the DE model, and establishes a model data schema. This data schema describes the structure and format of the model data, and parts of it are used to translate into or create input / output API endpoints using the corresponding input / output schemas. In some embodiments, the model data with metadata 722 may be stored in access-restricted storage 726, such as a “customer bucket” 312 in the customer environment 310 in Figure 3, so that model splices such as 742, 744, and 746 can be generated on demand when the input DE model 704 is crawled.

[0136] The model splicer further generates splice functions (e.g., API function scripts) 732 from the native API 702 associated with the input CAD model. In this disclosure, “native” and “primal” refer to existing DE model files, functions, and API libraries associated with a particular third-party DE tool, including both proprietary and open-source options. The native API 702 may be provided by a proprietary or open-source DE tool. For example, the model splicer may generate an API function script that calls the native API of a native DE tool to execute functions such as HideParts(parts_list) and Generate2DView(). These model-type specific splice functions may also be stored in a splice function database 736, also for on-demand generation of individual model splices. A catalog or specification of splice functions provided by different model splices supported by IDEP, and orchestration scripts linking multiple model splices, constitute the platform API. This platform API is a common, universal, externally accessible platform interface that masks the native API 702 of any native DE tool integrated into IDEP, thus enabling engineers from different disciplines to interact with unfamiliar DE tools and allowing previously incompatible DE tools to freely interoperate.

[0137] Next, based on user input or a desired user application 706, one or more model splices or wrappers 742, 744, and 746 may be generated and wrapped with splice functions or API function scripts that can apply a subset or all of the model data required by the user application to the original input model and / or wrapped model data to perform the desired operations and complete the task requested by the user. In various embodiments, the model splice may take the form of a digital file or a group of digital files, and the model splice may include, in any combination or permutation, locators to the aforementioned DE digital artifacts and splice functions or copies thereof. Any number of model splices / wrappers may be generated by combining a selection of model data, such as 722, with an API function script, such as 732. Since the API function scripts provide unified and standardized input and output API endpoints for accessing and manipulating DE models and DE model data, such API handles or endpoints can be used to execute model splices and establish links with other model splices without directly calling native APIs. Such API endpoints may be formatted according to an input / output scheme that matches the DE model file and / or the DE tool being used, and may be accessed by orchestration scripts or platform applications that act on multiple DE models.

[0138] In some embodiments, when executed, API function scripts input to or output from a DE model or DE model splice. An "input" splice function, or "input node" such as 733, is a model modification script that enables updates or modifications to the input DE model. For example, a model update might include changes made to model parameters or model configurations via the input splice function. An "output" splice function, or "output node" 734, is a data / artifact extraction script that enables data extraction or derivation from the DE model via its model splice. API function scripts may invoke native API function calls of native DE tools. Artifacts are the results of execution from the output API function script within the model splice. Multiple artifacts may be generated from a single DE model or DE model splice. Artifacts may be stored in restricted access cloud storage 726, or other similar restricted access customer buckets.

[0139] One advantage of model splicing is its inherent minimal privileged access control capability for zero-trust implementations of IDEP, such as those disclosed herein. In the various deployment scenarios described with reference to Figure 4, and within the context of the IDEP implementation architecture described with reference to Figure 3, the original DE input model 704 and model data storage 726 may reside in a customer bucket 312 in the customer environment 310 in Figure 3. The splice function 732 stored in the database 736 calls the native API 702. The execution or invocation of the splice function 732 may depend on job-specific authentication or authorization via a proprietary license of the DE tool (e.g., residing in the customer environment 310 in Figure 3), and / or the information security clearance level of the requesting user. Thus, model splicing debunks monolithic access to the digital model type file as a whole file and instead provides specific access to a subset of functions, enabling limited, purposeful, and auditable interactions with a subset of model type files constructed from component parts or atomic units assembled into parts.

[0140] Digital Threading of DE Models via Model Splicing Figure 8 is a schematic diagram illustrating the digital threading of DE models via model splicing according to several embodiments of the present invention. The digital thread is intended to connect two or more DE models for traceability throughout the entire system engineering lifecycle, as well as for collaboration and sharing among individuals performing DE tasks.

[0141] Model splice linking generally refers to jointly accessing two or more DE model splices via an API endpoint or splice function. For example, data may be retrieved from one splice to update another (e.g., the input splice function of a first model splice calls the output splice function of a second model splice), data may be retrieved from both splices to generate a new output (e.g., output splice functions from both model splices are called), and data from a third splice may be used to update both the first and second splices (e.g., input splice functions from both model splices are called). In this disclosure, "model linking" and "model splice linking" can be used interchangeably because linked model splices are mapped to correspondingly linked DE models. Similarly, linking DE tools generally refers to jointly accessing two or more DE tools via model splices, where model splice functions encapsulating heterogeneous DE tool functionality may interact and call each other, or be jointly called by orchestration scripts to perform DE tasks.

[0142] Therefore, model splicing makes it possible to transform individual digital model files into model splices that can be linked autonomously and securely, enabling the management of numerous digital models as a unified digital thread written in scripts. Within the IDEP disclosed herein, a digital thread is a platform script that calls platform APIs to facilitate, manage, or orchestrate workflows through linked model splices. Model splice linking provides a communication framework or data-driven architecture that connects traditionally siloed elements, enabling the flow of information between digital models through corresponding model splices. The extensibility of model splicing across many different types of digital models allows for the scaling and generalization of digital threads that represent each and every stage of the DE lifecycle, instantiating and updating DTw as needed.

[0143] In the specific example shown in Figure 8, the orchestration script 894 is written in Python code and designed to interact via API endpoints such as 892 to determine whether the CAD model meets the total mass requirements. API endpoint 892 is an output splice function and is part of the platform API 890. The platform API 890 includes not only splice functions but also platform scripts or orchestration scripts themselves, such as 894.

[0144] Orchestration script 894 is divided into three main steps. 1. Retrieving data from CAD model splice: A POST request can be sent via the IDEP platform API to execute the computer-aided design (CAD) model splice 871. This model splice provides a uniform interface for modifying and retrieving information about the CAD model 881. Parameters of the CAD model, such as hole diameters, notch openings, and flange thicknesses, can be sent in the request and set via the input splice function. The total mass of the CAD model can be derived from the model parameters and retrieved via the output splice function. The response from the platform API includes the total mass of the CAD model 881 and the uniform resource identifier / locator (URL) of the CAD model. The response may further include a URL for an image of the CAD model. 2. Retrieving data from a SysML model splice: Another POST request may be sent via the IDEP platform API to execute a System Modeling Language (SysML) model splice 872. SysML is a general-purpose modeling language used in system engineering. The output function 892 of model splice 872 retrieves the total mass requirements of the system from the SysML model 882. The response from the platform API will include the total mass requirements of the system. 3. Align variables and check if requirements are met: Compare the total mass from CAD model 881 with the total mass requirement from SysML model 882. If the two values ​​are equal, a message is printed indicating that the CAD model is aligned with the requirements. Otherwise, a message is printed indicating that the CAD model is not aligned with the requirements.

[0145] In short, the orchestration script 894, which may be implemented in the application plane 160 of IDEP100 shown in Figure 1, links digital models 881 and 882 via model splice API calls. The orchestration script 894 is a scripted platform application that modifies the CAD model, obtains the total mass of the modified CAD model, obtains the total mass requirements from the SysML model, and compares the two values ​​to check if the CAD model meets the requirements. In some embodiments, the platform application within IDEP100 operates on one or more DE models by utilizing a set of functions.

[0146] Model Splice Plane Figure 9 is a schematic diagram illustrating the linking of DE model splices in a splice plane and a comparison of digital threading with and without model splicing, according to several embodiments of the present invention. The lower model plane 180 shows an example of current digital threading practice, where each small ellipse represents a DE model, and linking between any two DE models, such as models 982 and 984, requires their respective connections to a central platform 910, requiring potential additional linkages from any model to any other model. The central platform 910 includes program code that can interpret and manipulate the original DE models of distinct model types. For example, under the control of a subject expert, platform 910 may prepare data from digital model 982 in a format that can be accessed by digital model 984 via the native API of digital model 984, thus enabling modifications of digital model 982 to be propagated to digital model 984. Any feedback from digital model 984 to digital model 982 requires similar processing via platform 910 so that the data from digital model 984 is converted into a format that can be accessed by digital model 982 via its native API. This hub-and-spoke architecture 934 is not scalable to the enormous number of digital models (e.g., hundreds or thousands) contained within a typical large-scale DE project, because model updates and feedback are only possible through the central platform 910.

[0147] In contrast, when DE models are spliced, each original model is represented by a model splice that includes the relevant model data and unified and standardized API endpoints for input / output, as shown in the upper splice plane 170. The splices in splice plane 170 may be connected through scripts (e.g., Python scripts) that call API endpoints or API function scripts, and may follow a DAG architecture as illustrated with reference to Figures 1 and 6. Note that in Figure 1, only the set of generated splices is shown in splice plane 170, but in Figure 9, the scripts that link the model splices are also shown in the splice plane for illustrative purposes. Such scripts orchestrate the workflow through digital threads built on interconnected DE model splices, and are therefore referred to in this disclosure as orchestration scripts or platform scripts. Furthermore, while the splice plane 170 is shown in Figure 1 as part of IDEP 100 for illustrative purposes, it should be noted that in some embodiments, the splice plane 170 may be implemented inside the customer firewall and be part of the DE platform agent, as illustrated in the various deployment scenarios shown in Figure 4. That is, individual API function scripts generated via model splicing by the DE platform agent may be tailored to call proprietary tools that the customer can access in a private environment. A centralized platform 910 with unique access to all native tools associated with all individual digital models shown in Figure 9 is not required. Instead, the orchestration script calls a universal API function script, which may be implemented differently in different customer environments.

[0148] Therefore, model splicing enables model splices, such as model splice 972 from digital model 982 and model splice 974 from digital model 984, to access each other's data in a purposeful and direct manner, thus enabling the creation of model-based "digital meshes" 944 by platform scripts, which can be linked autonomously without input from subject matter experts.

[0149] An additional benefit of moving from the model plane 180 to the splice plane 170 is that the DE platform allows the creation of multiple splices for each native model (see, e.g., Figure 7), each having a different subset of model data and API endpoints tailored to the splice's target application. For example, a model splice could be used to generate multiple digital twins (DTws) that map the design of a physical product or object into a virtual space. Bidirectional data exchange between the physical object and its digital object twin enables testing, optimization, verification, and validation of the physical object in the virtual world by selecting the optimal combination of digital model configurations and / or architectures from the parallel digital twins built on the model splice, each potentially responding differently to the same feedback from the physical object.

[0150] The IDEP disclosed herein, supported by model splicing, digital threading, and digital twinning capabilities, connects DE models and DE tools to enable easy and secure collaboration of digital engineering data across engineering fields, tool vendors, networks, and model sources such as government and public agencies, special program offices, builders, small businesses, federally funded research and development centers (FFRDCs), and university-affiliated research centers (UARCs). An IDEP application example 950 is shown on the right side of Figure 9, illustrating how data from many different organizations can be integrated to enable cross-domain collaboration while maintaining data security, traceability, and auditability. Here, DE models from multiple vendors or component builders are spliced ​​or wrapped by the IDEP agent, and data artifacts are extracted with data protection. Transforming DE models into data artifacts enables cross-domain data transfer and protection of critical information. This allows model owners to retain complete control over their DE models using their existing security and IT stacks, continue using the DE tools best suited to their purpose, and preserve the same modeling schema / ontology / profile best suited to their purpose. IDEP transforms the DE model into a microservice, providing minimal privilege data bits that traverse to relevant stakeholders without the DE model ever leaving its home server, or without being replicated or delegated. IDEP also offers easy data access and digital threading options via a secure web application or secure API.

[0151] DAG representation of threaded tasks Model splicing provides a unified interface between DE models, enabling model and system updates to be represented by interconnected, pipelining DE tasks. Figure 10 shows an exemplary directed acyclic graph (DAG) representation 1000 of pipelining DE tasks related to digital threads according to several embodiments of the present invention. In diagram 1000, tasks executed through a digital thread orchestration script (e.g., 894) are structured as nodes in the DAG. Thus, actions are interconnected and executed in a pipeline linking DE model splices to ranges of corresponding parameter values. Digital threads can thus be created by establishing correct connections between any model splices of corresponding models at relevant endpoints via an interpretable DE platform script.

[0152] Referring to Figures 1 and 8, the DAGs of threaded tasks are constructed from digital threads and are part of the application plane 160 of the DE platform. Different DAGs can target different DE actions. For example, in Figure 1, constructing or updating DTw 122 within the virtual environment 120 has its own DAG 124. Model splicing transforms DE models into data structures accessible via APIs, thus enabling the use of software development tools ranging from simple Python scripts to complex DAGs to perform DE actions. Digital threads in model splicing eliminate the scalability issues of digital thread management and accelerate the digital design process, including design updates based on external feedback.

[0153] Following the above description of the basic elements and core aspects of IDEP disclosed herein, a documentation system that enhances the functionality of IDEP with respect to model splicing will now be described in detail.

[0154] Challenges of sharing, integrating, and collaborating on digital engineering (DE) models Designing, creating, and operating large-scale and complex systems typically requires the use of a wide variety of DE platforms and model types employed across various interdisciplinary and multidisciplinary engineering fields. Some examples include numerous software tools for computer-aided design (CAD) and drafting, modeling and simulation (M&S), cost analysis, requirements management, validation and verification (V&V), certification and documentation, engineering product lifecycle management, and various other aspects of systems engineering. Systems engineering is the field that aims to coordinate the design and management of parts of complex engineering systems throughout their lifecycle to facilitate interfaces and monitor collective behavior in a way that produces intended results that meet requirements generated based on stakeholder needs. Digital engineering incorporates innovations in digital technologies into an integrated digital model-based approach.

[0155] Sharing and integrating DE models for collaboration among different stakeholders, such as managers, frontline engineers, suppliers, and vendors, presents several challenges, including the siloed nature of DE tools, the lack of interoperability and integration between different DE tools, and concerns about intellectual property (IP) protection, data security, auditability, and / or confidentiality, which can make organizations hesitant to share DE models. Sharing DE models as printed output for review is inefficient, time-consuming, and costly, while there is a need for more experts or subject matter experts (SMEs) who are proficient in handling digital engineering workflows using multiple tools. Furthermore, sharing entire models or files among different teams, suppliers, and partners can make version control and access control management difficult. Key challenges include the time and cost involved in mapping requirements to digital deliverables, the lack of transparency and visibility across the entire digital engineering process, the restriction of access to DE models and engineering data by different stakeholders, including regulators, customers, and investors, due to the absence of standardization and data sharing protocols, and the difficulty in scaling and adapting DE processes and tools to changing business requirements and market demands due to a lack of flexibility, modularity, and compatibility between different systems and tools. Furthermore, iterative web-based approaches that share data via, for example, web servers, on-demand cloud computing, and storage services with API handles are generally unacceptable for sharing DE models from highly sensitive industries. For example, aerospace and defense companies hold some of the nation's most sensitive security-related information, and allowing global access to these models and related data would violate both their corporate policies and government regulations.

[0156] Some other specific examples include, but are not limited to, manufacturing companies struggling to manage version control and data integration when they must share digital models of product requirements, designs, and simulations with different teams and suppliers; construction companies facing challenges integrating data from various sources and tools when they must share digital models of architectural designs with regulators and partners; aerospace companies or their original equipment manufacturers (OEMs) facing challenges managing version control and IP protection when they want to collaborate on designs without creating duplicate models; utility companies that must manage designs as digital models that need to be linked to bills of materials and cost forecasts, as well as printed design documents for regulatory review and approval; architectural firms attempting to collaborate on architectural design projects but facing challenges integrating different design tools or software systems, leading to costly errors and delays; research institutions attempting to share complex digital models of scientific data with colleagues and collaborators but facing challenges with data formatting, validation, and visualization; and shipbuilders facing challenges sharing data and easily linking validation when they must share design data and blueprints with regulators and standardization bodies.

[0157] To circumvent the aforementioned challenges, organizations may resort to manual model sharing, such as exporting data from one tool to another, adopting file formats supported across several different tools, or manually creating reports or presentations summarizing relevant data. For example, a team of expert users might tune a model in real time within the same physical space, such as the Apollo Mission Control Center. Data and related files may be shared in a common internal development environment or integrated development environment (IDE), which is likely to introduce security risks. Data and related files may also be shared through an Enterprise Service Bus (ESB), which is a pre-cloud architecture and can be useful when the set of DE tools is known and fixed. However, ESBs are not cloud-native, can be a single point of failure, and may lack the flexibility to dynamically change the set of tools and requirements.

[0158] Organizations may share data via email or other file-sharing services, or they may manually consolidate data from different tools into a single location. The use of password-protected files, requiring users to sign non-disclosure agreements (NDAs), or restricting access to sensitive data that needs to be known are also used in addition for IP protection and confidentiality. However, these workarounds may still provide access to the entire digital model or file, which may be undesirable or unnecessary.

[0159] In some cases, companies use secure cloud infrastructure (e.g., Google Cloud Buckets or Amazon Web Services (AWS)) as a starting point, but this alone is not sufficient for DE integration. Currently, access to secure cloud infrastructure for DE models is prevalent either through direct access to the IDE or in pre-cloud architectures using an enterprise service bus to link to the entire model. Under such setups, it is impossible to target specific digital artifacts and / or data slices that may reside within such storage.

[0160] The difficulties in managing version control and access control can be addressed through naming conventions, the use of version control software, or assigning roles and permissions to specific users. The inefficiencies, slowness, and costs of the review process when sharing models as printed output can be addressed through online collaboration tools that enable real-time feedback and editing, or through digital tools that enable easier and faster review or auditing of digital models; however, the auditability and traceability of changes, and the accountability of stakeholders involved in such changes, cannot be guaranteed.

[0161] In summary, despite the measures described above, current workarounds for sharing DE models remain universally limited, slow or time-consuming, inefficient, and sometimes even ineffective. These methods often lack robust mechanisms for auditability and traceability, leading to data inconsistencies and errors that are not easily traced or corrected. The lack of clear audit trails and the inability to trace changes back to their origins hinders stakeholder accountability and data integrity. Furthermore, such mitigation measures are often considered unacceptable in industries handling sensitive information, such as aerospace and defense, where stringent requirements for auditability and traceability are undeniable, as they can have far-reaching impacts on safety and security.

[0162] Overview of Digital Engineering (DE) Model Splicing The Interconnected Digital Engineering Platform (IDEP), described within the context of Figure 1, is a computer-based system that can be used to support various DE product lifecycle activities from concept to decommissioning in a zero-trust setup. The DE model splicing system and methodology, provided by IDEP, integrates previously siloed DE tools, DE models, and relevant digital artifacts from different disciplines into secure, shareable model splices, and software-defined digital threads and digital twins in a zero-trust setup. By enabling the right stakeholders to access the right information from the right sources with the right tools at the right time, in the right context, for the right purpose, DE model splicing facilitates secure, auditable, traceable, iterative, and effective development and review of components and / or systems, from design to validation, verification, and certification.

[0163] As illustrated in the context of Figure 7, “Model Splicer” refers to program code or an uncompiled script that performs model splicing of a DE model. A DE model splicer for a given DE model type, when applied to a specific DE model file of that DE model type, retrieves, extracts, or derives DE model data, digital artifacts, and associated metadata; generates and / or encapsulates splice functions (e.g., in the form of API function scripts) that can be applied to the model data or digital artifacts; and instantiates API endpoints according to the input / output schema. A DE model is a computer-generated digital model representing the characteristics or behavior of a complex product or system, and can be created or modified using DE tools. A DE model within an IDEP disclosed herein refers to any digital file uploaded to the platform, including appropriately interpreted documentation. Digital artifacts are generated within model splicing or produced from spliced ​​model data. In some embodiments, digital artifacts are the results of executing a particular splice function; that is, digital artifacts may be retrieved model data or derived data generated from extracted model data. A "model splice," "wrapper," or "graft" of a given DE model file for a given user application may be generated by wrapping such digital artifacts and splice functions specific to the user application, allowing only limited access to the original DE model file in a controlled time instance and enabling modification of the limited portion for collaboration and sharing with stakeholders of the given user application.

[0164] More specifically, a model splice for a given DE model file includes (1) DE model data or digital artifacts extracted or derived from the DE model file, including model metadata, and (2) locators or copies thereof for splice functions (e.g., API function scripts) applicable to the DE model data or digital artifacts. The model splice may take the form of a digital file or a group of digital files. In some embodiments, the model splice may include links to the aforementioned DE digital artifacts and splice functions, or locators / addresses (e.g., pointers, indexes, uniform resource locators (URLs), etc.) for the DE digital artifacts and splice functions, which themselves may be stored in an access-controlled database, a cloud-based storage bucket, or other type of secure storage environment. The splice functions provide a unified, standardized, addressable application programming interface (API) endpoint or software development kit (SDK) endpoint that is externally accessible to third-party applications and users via a code interface or graphical user interface (GUI). Such API or SDK endpoints enable access to digital artifacts without accessing the entire DE model file and without direct involvement by third-party applications and users using specific DE tools required to view, process, or modify the DE model file. In other words, the splice function masks heterogeneous DE tools that require subject matter expert (SME) and / or software programming knowledge. One or more different model splices may be generated from the same input DE model file, based on the specific user application under consideration and depending on data access restrictions.Furthermore, metadata associated with digital artifacts and / or splice function calls ensures the auditability and traceability of the execution of any particular function (e.g., splice functions, DE tool functions, third-party API calls) for a particular version of a particular DE model at a given point in time.

[0165] As disclosed herein, one characteristic of model splicing is that the system is designed to meet the complex requirements of DE model sharing by incorporating rigorous auditability and traceability to ensure compliance with industry standards and government regulations, while guaranteeing the secure and zero-trust shareability of model data. The challenges in sharing, integrating, and collaborating on DE models are recognizable. Furthermore, it is clear that improving the shareability of DE models and related data sources through internet technologies could lead to significant advancements in the ability of businesses and government agencies to collaborate. However, no simple approach to model sharing via conventional methods such as web servers, on-demand cloud computing and storage services using API handles, email, instant messaging, and government data transfer services meets the stringent security and auditability requirements of highly sensitive industries such as aerospace and defense, and military. By partitioning and encapsulating model data and splice functions while tracking data sources and function execution using metadata, model splicing goes beyond traditional web-based and API-based approaches to adequately address the core requirements of zero-trust principles, audit trails, and traceability of data access and modification, thereby ensuring compliance with the most stringent security protocols.

[0166] The second characteristic of model splicing is model data access control, specifically, debunking monolithic access to the DE model as a whole file and instead providing specific access to a subset of functions that allows limited, purposeful, and auditable interactions with a subset of digital artifacts built from component parts. In this case too, selective access to and modification of specific functions within the larger engineering model enables a secure and collaborative engineering workflow without the need to duplicate the model or expose sensitive or confidential technical information. In addition to model sharing, model splicing enables the efficient abstraction and editing of model data and functions without requiring complete transparency to the entire model and its sensitive technical details, and potentially without requiring full access to native DE engineering tools and / or software platforms.

[0167] A third characteristic of model splicing is that it facilitates interoperability between DE tools. By encapsulating the functionality of various native DE tools within model splice functions and providing a standardized, platform-wide API, the complexity required for specialized engineers, subject matter experts, and software developers to deeply engage with multiple native DE tools is significantly reduced. Furthermore, model splicing enables linking or joint access of heterogeneous native DE tools that are not directly interoperable, and allows for seamless calls to model splice functions that encapsulate separate DE tool functionalities and execute DE tasks collaboratively.

[0168] A fourth characteristic of digital model splicing is that the diverse linking of DE model splices creates software-defined digital threads for purposes such as testing, authentication, or validation. Model splice linking, or model linking, generally refers to jointly accessing two or more DE model splices via API endpoints or splice functions. Interconnected model splices significantly improve the scalability and versatility of DE model use by supporting the core capabilities and functions of IDEP and reducing the need for expert skills when managing multiple models. Within the IDEP disclosed herein, a digital thread is a platform script that calls platform APIs to facilitate, manage, or orchestrate workflows through linked model splices, providing the ability to access, integrate, and translate heterogeneous data into actionable information. For example, a digital thread may be used to propagate requirements and / or design changes from individual model splices across a complex engineering system, enabling seamless and accountable collaboration between individuals performing DE tasks.

[0169] Another characteristic of model splicing is its ability to provide core training data for AI-assisted capabilities such as digital threading and autonomous data linkage in DE systems. Specifically, user actions during model splicing and user input to the model splice API endpoint can provide a data stream that serves as training data for fine-tuning AI algorithms that can assist users in creating digital threads. The model splicer's action dataset can also be used to automate user actions or to feed machine learning engines that perform predictive analytics on typical user actions, security audits, etc. The training dataset can also be enhanced using synthetic data generation and customized to train enterprise-specific models for customers.

[0170] In short, DE model splicing encapsulates, containerizes, and partitions digital model data and functions to ensure model confidentiality and accessibility, while digitally threading model splices using a generalized API interface enables scalability and generalization from heterogeneous models to a cohesive digital continuum throughout the entire system development lifecycle.

[0171] Model splicing process The following describes in more detail embodiments of the model splicing process and exemplary model splicer embodiments within the context of IDEP.

[0172] Figure 11 shows a flowchart illustrating an exemplary process for generating a DE model splice according to several embodiments of the present invention. In this exemplary embodiment, a DE model file may be received in step 1120 during initialization in step 1110, and the DE model file is, for example, a DE model having a native format DE model type. The native file format of a DE model refers to a file format or file structure created, used, and maintained by a particular DE tool or software application from which the DE model originates. This format is designed to store all information that the DE tool or software application can handle, including, for example, geometry, features, metadata, and other design parameters specific to the capabilities of the software. Each DE tool typically has its own native file format, which is optimized for use within that particular tool and may not be fully compatible with other DE tools without some form of conversion or data exchange process. For example, some proprietary CAD software uses ".dwg" as the native file format for 2D and 3D design data, while others use ".prt" files for component parts. Native file formats are typically preferred for working within DE tools because they allow for full utilization of the software's features and capabilities. However, for sharing and interoperability purposes, DE models can be exported from their native format to other open-source and / or neutral file formats that can be opened by a variety of different DE tools, often at the expense of some loss of unique data or features inherent to the native file format.Model splicers implemented according to embodiments of the present invention disclosed herein are also applicable to neutral file formats that can facilitate limited interoperability between a selected number of different DE tools for the same DE model type (for example, different CAD software may be used to open CAD model files and to perform limited editing on CAD model files). In this disclosure, native DE file formats and associated native DE tools may also be interpreted as neutral DE file formats and any associated DE tools that may be used to edit files in this neutral DE file format.

[0173] Next, in step 1130, model data may be extracted from the DE model file. As illustrated with reference to Figures 20, 22, and 26, in various embodiments, the model data and model splicers may be model type specific. The user may select a specific model splicer for splicing the input DE model in its native file format. Alternatively, the model splicer may first identify the native file format of the input DE model and then call a model crawler specific to that native file format to extract the model data. Different model crawlers may be applied to DE models of different model types, and the extracted model data may be placed into a data structure tailored to a particular decomposition of the input DE model. In some embodiments, as illustrated with reference to Figure 7, such model data may include metadata about the DE model. For example, metadata about an input computer-aided design (CAD) model may include a list of parts, named parameters, potential user input options, a version number for the DE model file, and timestamps of the last modification or last access date and time for the model file or individual model data items.

[0174] In an exemplary embodiment of a model crawler for crawling an input DE model using the original native DE tool or an alternative DE tool associated with a DE model type or native file format, one or more of the following steps may be performed: First, the input DE model file in native file format may be opened using the original DE tool that created it, or using a relevant compatible tool or software that can read and interpret the model data. Second, the native functionality, methods, or features of the DE tool being used may be required to identify and list all components in the model. This may include navigating the structure of the model, such as an assembly tree or bill of materials. Third, relevant data about each component may be extracted using the DE tool's data extraction capabilities, scripting capabilities, or native API. This model data may include names, part numbers, descriptions, material specifications, lists of variables, parameters, and other attributes. Fourth, the extracted model data may be structured in a format such as JavaScript Object Notation (JSON), where objects are created for each component, with relevant attributes as name-value pairs. JSON is a data exchange format that stores human-readable plain text data in key-value or attribute-value pairs and arrays. Fifth, structured data can be stored using the export function of DE tools or custom scripts, as described below.

[0175] In step 1140, model data may be stored in a model data storage area. For example, structured model data (e.g., a .zip file containing multiple JSON files and component files, a directory containing multiple image files, and an .xml file) may be saved using the export function of the DE tool. If the DE tool does not support direct export to the desired format, a script using the DE tool's API or SDK may be executed. Such a script may be written by a subject expert (SME) familiar with the DE tool's API or SDK, or it may be automated with AI assistance (e.g., using a generative AI algorithm) to investigate the DE tool's API library and API specifications. As illustrated with reference to Figures 3 and 7, such model data storage may be restricted in access, cloud-based, or located in a customer bucket within the customer environment for a zero-trust implementation. In some embodiments, model data and / or metadata may be placed in one or more files, such as JSON files.

[0176] In step 1150, one or more externally accessible splice functions may be generated to enable external access to one or more digital artifacts derived from the model data stored in the model data storage area. One or more externally accessible splice functions provide addressable application programming interface (API) endpoints or software development kit (SDK) endpoints that are accessible to third-party applications and users, and the API endpoints or SDK endpoints enable access to the digital artifacts without accessing the entire DE model file and without direct involvement by third-party applications and users using DE tools associated with the DE model type (e.g., native DE tools associated with the native DE file format).

[0177] In some embodiments, the splice function is defined and programmed by a subject expert (SME), and the process of generating the splice function may include receiving code input from a user. In some embodiments, the splice function may be prewritten by the SME or by an AI-based generator engine, and the process of generating the splice function may include retrieving a link to or a copy of the splice function from a data store. In some embodiments, the process of generating the splice function may include receiving a user selection of a splice function from a list of prewritten splice functions in a database, and retrieving a link to or a copy of the selected splice function. In some embodiments, the process of generating the splice function may include receiving user input defining input / output schemas and / or the functionality of the splice function, prompting an AI-based recommender engine to locate a prewritten splice function, or prompting an AI-based generator to write / create a splice function script. In some embodiments, the process of generating a splice function may include using an AI-based recommender engine to recommend one or more prewritten candidate splice functions based on one or more of the following: user input, DE model type or file format, and other appropriate contextual information such as the user's role in the specific project in which the model splice will be used.

[0178] In some embodiments, third-party applications and users may refer to entities outside the model splicing system or service (e.g., software applications, human or non-human users) that may access their functionality or data by utilizing the interface (e.g., API) provided by the model splice. Thus, model splice functions mask separate DE tool functions, significantly reducing the complexity for users (e.g., specialized engineers, subject matter experts, and software developers) to deeply engage with multiple DE tools and native DE files. In addition to the exemplary splice function 732 described in the context of the CAD model example in Figure 7, other exemplary splice functions include, but are not limited to, read functions (e.g., function 734) and write functions (e.g., function 733) that can retrieve digital artifacts (e.g., retrieve from the model splice or retrieve from secure storage using addresses contained in the model splice), and model update functions that can be used to configure model parameters and provide updated DE model files. In some embodiments, this generation step 1150 may include retrieving a prewritten splice function script from a splice function database in response to user input or a request. In some embodiments, such retrieval may include interacting with a service cell as shown in Figure 3.

[0179] In step 1160, a shareable model splice of the DE model may be generated. The shareable model splice includes access to or a copy of a selection of one or more digital artifacts, and includes access to or a copy of at least one of one or more externally accessible splice functions, and is accessible to third-party applications and users via an API endpoint or SDK endpoint, the API endpoint or SDK endpoint provides a unified programming interface to the shareable model splice generated from the DE model having the DE model type. The model splicing process ends in step 1170. The model splice may take the form of a digital file or a group of digital files (e.g., in a file directory or nested directory). The generation of a shareable model splice may include creating such a digital file(s). Access to a digital artifact and / or splice function may refer to a locator (such as a reference, address, pointer, index, or uniform resource locator (URL)) to such a digital artifact and / or splice function, and / or a copy of the digital artifact and / or splice function.

[0180] In some embodiments, each digital artifact referenced by or included in a model splice may be associated with metadata that can be used to track the origin of the digital artifact. For example, such metadata may include the version of the DE model file from which the digital artifact was derived and a timestamp indicating when the digital artifact was derived. In some embodiments, access to the splice function or unified programming interface may be Representation State Transfer (REST) ​​enabled, so that subsequent execution of the splice function can be performed as a web service via a web application or portal.

[0181] Exemplary Model Splicer Embodiment Figure 12 shows an exemplary system 1200 for generating DE model splices according to some embodiments of the present invention. In this exemplary embodiment, a non-temporary physical storage medium 1290 is provided for storing program code 1292, which is executable by a hardware processor 1295, causing the hardware processor to perform a computer implementation process that includes generating a shareable model splice 1270 from an input DE model file 1210 for model splicing or DE modeling.

[0182] In some embodiments, program code 1292 includes code for receiving a DE model file 1210 of a DE model having a DE model type in a source file format (e.g., a native DE file format). In some embodiments, the DE model file 1210 may be received from a user 1202 through a user interface (UI) 1204. User 1202 may be a human or a computing entity, and UI 1204 may be a graphical user interface (GUI), a code interface such as an API / SDK interface, or a multimodal interface as described with reference to Figure 5. For example, user 1202 may represent an artificial intelligence (AI) module intended to perform a DE task as part of a digital thread by linking the generated model splice 1270 to another existing model splice. In some embodiments, user 1202 may provide additional input for model splicing. Exemplary user inputs include, but are not limited to, requests for specific digital artifacts, selection of splice functions, intended use of the model splice, access restriction requirements for the generated model splice, authentication and / or authorization credentials, specific DE tools used for crawling through the input DE model file and / or generating the model splice function, requests for proprietary or open-source DE tools, and proprietary licenses or access codes for using proprietary DE tools during model splicing. In some embodiments, the DE model file 1210 may be received directly from a data source, for example, from an internal database or a cloud-based storage service. In some embodiments, the DE model file 1210 may include physical artifacts collected from a physical twin and organized in a predefined source file format.

[0183] The model analysis engine 1232 analyzes the input DE model file 1210 to extract model data, which may be access-restricted, cloud-based, or located in a customer bucket within the customer environment for zero-trust embodiments. In some embodiments, the model analysis engine 1232 may include a crawler script that calls native functions of the native DE tool 1220 associated with the input file 1210 to analyze the input DE model in detail, determine the model type, extract component data, identify metadata associated with the model file and / or component data, and generate a list of variables. In some embodiments, the model analysis engine 1232 may generate derived data from the extracted model data with or without a splice function generator 1234 and / or AI assistance. Once the derived data is generated and stored in storage 1233, associated metadata may also be stored to identify, for example, the time of derivation, the code used for derivation, the user authorizing the derivation, and / or the version of the input model file at the time of derivation. Such metadata can be critical in applications requiring near-instantaneous auditability and clear traceability to the original source.

[0184] The splice function generator 1234 generates one or more externally accessible splice functions that enable external access to one or more digital artifacts derived from model data stored in the model data storage area. In this disclosure, digital artifacts are functional outputs. Any model data, derived data, metadata, or combinations thereof and functionalities may be considered digital artifacts and may be accessed or generated via the model splice output function. Both the model analysis engine 1232 and the splice function generator 1234 may call native functions of the native DE tool 1220, depending on the model type of the input DE model or at the user's request. For example, the splice function generator 1234 may generate an API function script that calls native DE tool functions to derive digital artifacts or to provide functionality based on user input. The user may specify which DE tool to use or which DE tool is preferred. In some embodiments, the splice function generator 1234 may interact with the user 1202 through the UI 1204 to receive user-defined splice functions, receive user selections from a list of existing splice functions previously defined by other users or previously generated and stored in the splice function database 1235, and / or receive user approval or revisions to the proposed splice function. In some embodiments, the user may match the model data with existing splice functions in the splice function database 1235 to identify a selected number of splice functions that may be included in the model splice function 1270.

[0185] In some embodiments, an artificial intelligence (AI)-based recommender / generator engine 1236 may assist in splice function generation. For example, the AI-based recommender / generator engine 1236 may be trained on existing splice functions associated with existing model splices of the same DE model type, similar DE model types, and / or similar DE models, and may be further fine-tuned based on user input. In some embodiments, the AI-based recommender / generator engine 1236 may utilize a Large Language Model (LLM) to write a functional script that calls the API of the native DE tool 1220. In some embodiments, the AI-based recommender / generator engine 1236 may retrieve a list of splice functions from a splice function database 1235 based on user input and other data such as file format, DE model type, and intended purpose / use / audience inferred from the input DE model. In some embodiments, the AI-based recommender / generator engine 1236 may autonomously match model types with existing splice functions to recommend a list of potential splice functions for the user to select. In this disclosure, a similar DE model or DE model type refers to DE models that are similar in some aspects, such as structure or behavior, but are not identical. Similar DE models can be identified by analyzing the characteristics of different DE models and determining shared common features, attributes, or components relevant to model splicing. Similar DE models may be used as a reference, baseline, or starting point for model splicing, leveraging their similarity to improve efficiency and utilizing verified splice functions. Similar models are particularly useful when following the same standard guidelines or reusing the same components or modules. For example, different variants of an aircraft may share a common propeller design but have different avionics. A splice function generated for one variant of an aircraft may be used as training data for the AI-based recommender / generator engine 1236 to generate splice functions for other variants of the aircraft.

[0186] The splice function thus generated provides an addressable API or SDK endpoint accessible to third-party applications and users. Such an API or SDK endpoint enables access to the digital artifact without accessing the entire DE model file and without requiring direct involvement from third-party applications and users using the DE tool 1220 associated with the DE model type or native DE file format. In other words, the splice function masks the native DE tool function and DE tool. Users of the generated model splice no longer need deep knowledge of the relevant native DE tool. Furthermore, different users may access the same API or SDK endpoint that deploys different underlying native DE tools during model splicing. For example, a first user with a first input CAD model file and access to a proprietary CAD tool, and a second user with a second input CAD model file and access to an open-source CAD tool, can both obtain a CAD model splice with the same splice function implemented in the proprietary and open-source CAD tools, respectively.

[0187] The model splicer generator 1237 bundles the splice data 1272 and splice function 1274 into a shareable model splice 1270 in the form of locators (e.g., links, addresses, pointers, indexes, URLs, etc.) and / or copies of data / code. The splice data 1272 may be a selection of digital artifacts obtained from the input DE model file 1210. This selection may be based on data access permissions, such as user input regarding the access level or security clearance level of another user to whom the generated model splice will be shared, or as needed, such as metadata indicating the DE task in which the model splice is being generated. The splice function 1274 may be selected from those stored in the splice function database 1235. The shareable model splice 1270 is accessible by third-party applications and users via API endpoints or SDK endpoints. These API or SDK endpoints provide a unified programming interface to all shareable model splices generated from various DE models having the same DE model type (e.g., CAD models in the same native file format, or CAD models in several native or neutral file formats). These endpoints may be utilized by applications 1280 within the IDEP to perform specific DE tasks, preferably under endpoint-specific zero-trust access control. Thus, model splicing may be perceived as a use-case specific or application-specific process, as the data and functions of a model splice may be selected or determined based on the intended use of the model splice.

[0188] In various embodiments, the generated model splice 1270 may be shared with another user, who may then run it to access and / or modify the digital artifact and / or input DE model. As illustrated in the context of Figure 7, in some embodiments, the splice functions may be categorized as input functions or model modification functions, and output functions or data / artifact extraction functions. Inputs to the model splice for execution may be input parameters to such input and output splice functions. The output of the model splice execution is a digital artifact and / or modified DE model that may be shared, viewed, further modified, linked to a digital thread, and used to complete a DE task.

[0189] The model analysis engine 1232, splice function generator 1234, model splice generator 1237, and AI-based recommender engine 1236 are shown as separate modules in Figure 12, but in various embodiments of the present invention, these modules may be integrated in any combination to facilitate seamless data exchange and functional coordination and optimize the overall performance of the DE model splicing process. In some embodiments, parts of the model splicer 1230 may be implemented in the customer environment behind the customer firewall, so that customer data in storage 1233 is fully protected under a zero-trust setting, and may be managed by an IDEP agent. The splice function database 1235 may be independent of specific model data, may be provided by IDEP, and may be accessed via an IDEP agent.

[0190] The description of the model splicing process and model splicer in the context of Figures 11 and 12 has so far focused on model splicing a single given DE model type. In some embodiments, the model splicer 1230 may first identify the model type of the input model file (e.g., using the model analysis engine 1231) and splice accordingly. For frequently used DE model types, the splice function may be manually written and tested by subject experts and stored in the splice function database 1235 for use in generating use-case specific model splices. Currently, there are so many DE model types employed in various interdisciplinary and multidisciplinary engineering fields that it is advantageous to scale the model splicer 1230 from a few widely used DE model types to a large number of model types. Furthermore, because model splicing is use-case specific, two different input DE model files of the same DE model type and intended for the same purpose may result in similar model splices with different model data but identical splice functions.

[0191] In some exemplary embodiments of the model splicing process, one or more of the following steps may be performed by the system shown in Figure 12. Firstly, the model analysis engine 1232 may perform preprocessing steps before the input DE model files are received or uploaded. Specifically, the model analysis engine 1232 may interpret the file structure and schema of the library of model type files and build a library of typical use cases for model splices based on customer interviews and user input. Machine learning (ML) or AI-based algorithms may assist in scaling the model splicer, and exemplary splice function and file structure details may be used to create archetypes of potential splice functions for a particular model type file. Herein, the term “model type” file refers to a DE model file of a particular DE model type.

[0192] In some embodiments, when a model type file is received or uploaded, the model splicer may translate user instructions for typical use cases into specific functions that appropriately link to the model type file. The model splicer may provide a selection of splices for common uses (e.g., querying a model or performing a specific action on model data). The user may provide the system with a specific query or desired action to select from a list of model splices, or optionally, enter a text prompt into an AI-assisted module to obtain a selection of model splices. Furthermore, in some embodiments, endpoint calls to model splices and their outputs may be tracked or audited as part of a security implementation. Tracking or auditing endpoint metadata may also serve as a training dataset for user workflows that can be implemented in an automated or AI-assisted manner.

[0193] In other words, for a given DE model file, the model splicer generates a model-type-specific data file or structure and an accompanying splice function or native API function wrapper, which is a "second set of API functions" in addition to the DE model's native API. The model-type-specific data file or database entry stores all or a subset of the model data extracted from the original DE model, while the splice function enables access to and modification of the model-type-specific data structure and / or extracted model data, metadata, and derived digital artifacts, allowing for easy collaboration and sharing via an optional, dedicated, and secure web application portal. In an exemplary use case for model splicing, the generated DE model splice or wrapper is similar to a document in an interactive portable document format (PDF) with macro functions embedded for annotation and collaboration. For example, an aircraft manufacturer might share an edited 3D view of a new wing design with Air Force officers without over-informing the officers or needing to share the original model file, which could be overly complex or unnecessary for the intended audience. Such edited 3D views can be generated using a splice function applied to data spliced ​​from the original wing design model file.

[0194] In some embodiments, a model splice makes a subset of the model available through a subset of API endpoints or a GUI / web application. While API endpoints may be directly accessible via code, a GUI / web application may provide not only handles to the API endpoints but also an interface for user interaction with the model splice. In some examples, one of the API endpoints may still point to the location of the entire model. In some examples, a model splice may be used to share submodels constructed from extracted model data. In other examples, if the splice provides only a limited set of API endpoints, a pointer to the entire model may be required in the context. For example, a model splice generated from a CAD model with hidden subassemblies may internally connect to the entire extracted model to understand the assembly structure.

[0195] The aforementioned splicing function allows users to share, modify, and edit a model while restricting the exposure of the entire model, which may contain proprietary technical information. This means that the model owner can control who has access to which parts of the model, while still allowing others to work collaboratively with the model. Furthermore, splicing can webify the model, abstract its native API, and expose only the aspects of the model that the owner intends to share. Model splicing enables secure and collaborative engineering workflows without the need to duplicate the model or expose sensitive technical information. This allows for efficient sharing, abstraction, and editing of model functionality without requiring complete transparency of the entire model.

[0196] Generalized model splicing process using basic model splices Figure 7 shows the inputs and outputs to the model splicing process for a CAD model, but it is important to note that, as explained in the context of Figures 11 and 12, the model splicer embodiments are generalizable across the width and range of various model type files. Figure 13 further illustrates a general process 1300 within IDEP for performing model splicing and generating model splices for all types of models, according to several embodiments of the present invention.

[0197] The following exemplary steps may be performed at the start of step 1310 in the generalized model splicing process shown in Figure 13.

[0198] In step 1320, the user uploads a DE model to IDEP. A DE model file may be represented by one or more DE model files, each having its own source file format. Keep in mind that a DE model is a computer-generated model that represents the characteristics or behavior of a complex product or system. A DE model may be created or modified using a DE tool. A DE model file is a computer model file created or modified using a DE tool. A DE model in IDEP disclosed herein refers to any digital file uploaded to the platform, including documentation that is appropriately interpreted. For example, in various embodiments of the invention, a computer-aided design (CAD) file, a computer-aided engineering (CAE) file, a computer-aided manufacturing (CAM) file, a system modeling language (SysML) file, a system requirements definition (SDR) text file, a cost model, a scientific / engineering computing and simulation model file, a model-based systems engineering (MBSE) file, or a neural network model JSON file may each be considered a DE model. A DE model may be machine-readable only, human-readable but written in programming code, or human-readable and written in natural language-based text. For example, a document processing document containing product technical specifications, or a spreadsheet file containing technical data about a product, can also be considered a DE model. A DE tool is a DE application software (e.g., CAD software), a computer program, and / or a script that creates or manipulates a DE model during at least one stage or phase of the product lifecycle. A DE tool may include multiple functions or methods.Exemplary DE tools include, but are not limited to, model-based systems engineering (MBSE) tools, augmented reality (AR) tools, computer-aided design (CAD) tools, data analysis tools, modeling and simulation (M&S) tools, product lifecycle management (PLM) tools, multi-attribute transaction space tools, simulation engines, requirements modeling tools, electronic modeling tools, test plan modeling tools, cost modeling tools, scheduling modeling tools, supply chain modeling tools, manufacturing modeling tools, cybersecurity modeling tools, and mission effectiveness modeling tools.

[0199] In step 1330, based on the type of input DE model, the system may send a request to an appropriate server, computing entity, or computing module to process the input model file and extract data (e.g., components, variables, metadata) from the DE model. In some embodiments, this model data extraction step may be performed using a model data crawler that interfaces with APIs / SDKs provided by native and / or open-source DE tools. In some embodiments, the data extracted from the model may not represent the entire model, but may be a subset or slice of the entire model and may depend on the DE tools and tool APIs used to access the model. In some embodiments, data extraction may depend on input from a human or AI expert who may provide a model crawling script to understand the model data structure using native model APIs and extract variables and parameters. In some embodiments, the system may generate a data structure to hold the model data and store the model data in a database. Such a data structure may be model type specific.

[0200] In step 1340, the system may construct and / or execute a script to generate one or more model splices based on the model type and / or user input. The user may provide feedback in step 1350 to update such model splices, and in step 1360, before the process ends in step 1370, the subsequent model splice(s) may be shared with collaborators. In some embodiments, the system may provide a base model splice (see, e.g., Figure 16) in step 1340 according to a typical use case of the input model type. The user may select the base model splice for further customization in step 1350 (see, e.g., Figures 17 and 18), and then in step 1360, the model splice is shared with relevant stakeholders (see, e.g., Figure 19). In some embodiments, the model splice is executed in step 130, for example, as part of a digital thread, by the user or collaborators. Model splicing execution refers to user-initiated or system-initiated execution or invocation of splice functions, for example, to access or manipulate digital artifacts or update DE models.

[0201] For example, CAD files are associated with common functions that can be applied to CAD models (e.g., behavior, delta), and CAD files are often reviewed in different representations, such as as-design and as-plan views of 3D models and 2D drawings, accompanied by geometric tolerances and technical specifications, attribute-based color cleaning, simulation results (e.g., calculated weight and balance, finite element analysis), and bill of materials (BOM) reports. Multiple basic or default model splices may be generated by the system from general functions based on typical usages of CAD models previously collected by the system or specified by user intent input. Such basic model splices may be presented to the user through the UI for further revision and approval.

[0202] In another example, a DE model of the type for scientific / engineering computing and simulation scripts may be spliced ​​into one or more mode splices by default, and the user may provide feedback by selecting specific inputs and outputs for a particular splice. In some examples, the model file may include existing methods that can be used directly as splice functions, in addition to new scripts or plugins generated by the model splicer system. Furthermore, a human or AI expert may identify a specific splice function or API endpoint for the splice, and a human or AI expert may create an initial function script for creating the model splice. The AI ​​expert may be implemented using a generative AI algorithm to automate any one of the embodiments described above. More schematically, during each of the process steps shown in Figure 13, all expert user actions, system actions, and user inputs may be logged in the system database 1380. Such system logs may be useful for generating API function scripts, linking splices of autonomous models, and auditing and collecting datasets for an orchestralable AI system.

[0203] In the context of Figure 13, model splicing can create several categories of model splice functions or API / SDK endpoints. The first category may be predefined based on the model type and can be seen as basic or default splice functions. For example, these may be written by human experts using APIs / SDKs provided by native DE tools. The second category may be extracted from scripts, as is the case with scientific / engineering computing and simulation models. The third category may be provided by AI algorithms trained on existing splice functions associated with existing model splices for the same and / or similar DE models or DE model types. Similarly, users may customize basic model splices written by human experts or AI algorithms, or model splices shared / received within the user's editing privileges. For example, a user may select / modify specific digital artifacts and / or functions within a model splice. A user may first select a single splice function and / or a single digital artifact, and then select several splice functions or entire model type files or splices. Such user selections can be stored in the system database 1380 to create the underlying model splice.

[0204] In short, model splicing may involve one or more of the following core processes: 1. Identify the DE model type (e.g., CAD, requirements, etc.). 2. Decompose the DE model into its smallest possible components or atomic units (e.g., solids, surfaces, edges, wireframes, parameters, assemblies into parts, owners, reviewers, etc.). 3. Crawl the model and determine the data structure of each atom (for example, in the case of CAD, you can crawl each part and then find each face, curve, line, code, etc.). 4. Create a data structure for one or more data files that represent the DE model. These data files may include the original file, an open-source clone, and one or more other data representations such as JSON files and metadata inputs. 5. Provide an interface for humans and / or machines to update the DE model. The DE model here is a collection of data files containing model data. 6. Provide an interface for humans and / or machines to extract digital artifacts from the model. A DE model is currently a collection of data files containing model data. 7. Identify how humans can interact with the model via a GUI or web application. 8. Identify how the machine interacts with the model via the API. 9. Automatically handle forks or modifications of the original model based on user changes. 10. Track all of the above functions using metadata for auditability, traceability, accountability, and security.

[0205] Model access control and tracking for zero-trust security As disclosed herein, model splicing makes it possible to selectively access and modify specific data and / or functions within a DE model while hiding the rest of the model. Thus, model splicing enables the implementation of IDEP in a zero-trust approach, where the user interacts with the system via a computer network. Such a zero-trust approach methodology extends, for example, to the access and manipulation of data related to individual DE models, DE tools, and digital threads in the model splice sharing step 1360 and / or model splice execution step 1390.

[0206] In some examples, security architecture policies implemented under zero trust may include model storage policies, model access policies, attribute-based access control, read-for-write query handling, traceability and auditability, and model trust policies. For example, model access may be restricted to specific splice functions, such as authenticating users and models to DE models at API endpoints, allowing customers (e.g., model owners or model developers) to set additional access control policies, implementing data restrictions and encryption, logging endpoint transactions in a secure database, and incorporating metadata and digital watermarks for traceability and auditability. The goal is to ensure that the correct authorized users can access the correct authorized models and to assess the authenticity of the models and the trustworthiness of the users.

[0207] Specifically, embodiments of the present invention enable the aforementioned zero-trust policy by restricting access to model data / digital artifacts to a specific subset of splice functions and by tracking API endpoint transactions, which are executions or calls to splice functions. In some embodiments, restrictions on access to model data and digital artifacts may be implemented by authenticating users, for example, using attribute-based access control. These attribute-based access controls may include username, password, email, security key, information security (infosec) level, expertise in DE models, role in digital review, etc.

[0208] In some embodiments, the model splice may include one or more information security tags or markings for “when needed”-based zero-trust access control, where the information security tags may indicate the level of access to one or more of the model splice itself, digital artifacts, and / or splice functions. Tagging individual or group digital artifacts and / or splice functions with information security information can implement zero-trust access control by categorizing each based on its confidentiality and security requirements for access. This approach can enable secure collaboration and data sharing among authorized users while minimizing the risk of unauthorized access and data breaches.

[0209] In a non-limiting example, information security levels may be defined based on the type of data handled within the DE model. Such levels can range from public to confidential and secret, or they may be specifically defined based on organizational levels, where a given information security level of a digital artifact or splice function can only be read and / or edited and / or executed by users with a matching or higher information security level, or by users with a specific role in the project. A model splice may inherit the information security level of the input DE model, and the same information security level may be assigned to each individual digital artifact or splice function contained within the model splice. In some embodiments, the DE model owner creating the model splice, or an administrator or administrative user who understands the nature of the data and the potential impact of its disclosure, may specify an information security level for individual digital artifacts or splice functions. Such information security metadata may travel with the model splice, digital artifact, or splice function to ensure that the security level is clear regardless of where the data is moved and how the function is invoked. When model splices are shared, access control policies may be implemented in accordance with defined information security levels to specify who can access model splices, data, or functions based on security clearance, roles within the organization, and / or the context of the access request. Using such information security metadata, access control may be implemented at all access points or API / SDK endpoints of the DE model. When a user attempts to call a splice function to access a digital artifact, the information security tags of the digital artifact and / or splice function may be checked against the user's credentials and any active access control policies. If the user's clearance level meets or exceeds the information security level, access may be granted.

[0210] In a zero-trust model, verification is not a one-time event. The system continuously monitors access and may re-verify credentials and security levels to ensure access is appropriate. Changes in user roles, clearance levels, or data / function information security levels can trigger a re-evaluation of access permissions.

[0211] In some embodiments, traceability and auditability policies may be enforced by tracking or tracing any access to or specific operations on a particular DE model via its model splice. In particular, detailed audit logs of both successful and unsuccessful access attempts may be maintained to enable traceability and facilitate the review of access patterns. Such event logs concerning any splice function execution or API endpoint transactions may be recorded, for example, as metadata in an endpoint transaction database or as non-fungible tokens on a private blockchain.

[0212] Table 1 below shows exemplary endpoint metadata related to the generation or execution of a model splice. Such metadata may be stored in a secure endpoint transaction database or on a private blockchain, may be linked from the model splice itself, or may be contained within the model splice itself. Such metadata may include the model owner organization, model owner ID, user ID, user access rights, device ID, device location according to IP number and geographic location identifier, as well as the IDs of the model splice and splice function, transaction commands related to the model splice and splice function calls, the time associated with each transaction command, and values ​​associated with the transaction. Other examples may include the function ID, the type of method of invocation, the transaction start time, the transaction end time, the duration, the parameters of the call made by the model splice and splice function, the success of the call (e.g., either "true" or "false"), the monetary, time, and CPU cost time for the cycle, as well as the monetary, time, and GPU cost time for the cycle. Other examples are possible.

[0213] [Table 1]

[0214] Model splicing enables zero-trust access for several reasons. 1. Model splices provide API endpoints for accessing model data. 2. Data security in IDEP may follow a zero-trust approach to users, networks, and models, with attribute-based access control for authorization. 3. Zero trust in a model implies that a user is authenticated and authorized to use a specific model splice to access a particular API function. 4. Endpoint metadata tracking enables access-based control to specific model features for authorized users and allows for digital watermarking of models for traceability and auditability.

[0215] Providing training data for AI As described with reference to the AI-based recommender / generator engine 1236 and system database 1380, in some embodiments, user inputs and actions, input DE models, and resulting model splices (e.g., data descriptors, model component details, specific digital artifacts computed from splice functions, etc.) may be stored and integrated to provide core training data for AI-assisted capabilities that can enable scalable sharing of large libraries of models and versatile linking of different models to digital threads. That is, such training data may be used to fine-tune AI algorithms that can assist users in creating model splices and / or digital threads.

[0216] IDEP may also take additional steps to ensure that the created model splices provide a continuous data stream that serves as training data for automation and AI-assisted capabilities. Illustrative steps include, but are not limited to, the following: 1. Determine which APIs and functions within the DE model are needed to perform the identified workflow and user actions. 2. Develop a model splice that links only the necessary APIs and functions, and capture data on user interactions with those APIs and functions. 3. Use model splices to create data streams that reflect user workflows and actions, as well as specific API functions within specific model type files. 4. Use the model splice action dataset to automate user actions and feed them into a machine learning engine that performs predictive analytics on typical user actions or security audits. 5. Use the resulting data stream as a training dataset to fine-tune an AI algorithm that can help users create digital threads and perform other tasks related to the DE system. 6. Continue capturing data using a model splicer to improve the accuracy and effectiveness of the training dataset over time. 7. Use synthetic data generation to scale the training dataset and customize enterprise-specific models for customers. 8. Continuously evaluate and update model splicers and training datasets to ensure they remain aligned with the evolving needs of digital engineering systems and user workflows and actions.

[0217] Thus, the Model Splicer action dataset can be used to automate user actions or to feed machine learning engines that perform predictive analytics on typical user actions, security audits, etc. The training dataset can also be augmented using synthetic data generation and customized to train enterprise-specific models for customers.

[0218] Exemplary Embodiments of Model Splicing Computer-Aided Design (CAD) Models As exemplary embodiments of the model splicing process and model splicer, exemplary embodiments of how an end user interacts with the model splicer via a user interface are described below. Specifically, Figure 14 shows a collection of exemplary representations and editing interfaces 1410, 1420, 1430, and 1440 for computer-aided design (CAD) of an aircraft propeller engine according to several embodiments of the present invention. Figure 15 shows an exemplary embodiment of the splicing result of a CAD model in IDEP, and Figures 16–19 are additional exemplary screen captures of uploading a DE model, model splicing, and splice sharing according to several embodiments of the present invention, respectively.

[0219] Figure 14 shows an exemplary computer-aided design (CAD) representation 1410 for an aircraft propeller engine, presented to a human user via a graphical user interface (GUI). This propeller engine or propeller assembly includes a two-bladed propeller and an accompanying propeller engine having engine cylinders, engine caps, and engine radiators. Figure 14 also shows corresponding human-readable and computer-readable text representations 1420 of the aircraft propeller engine design. A mechanical engineer would typically review the propeller engine design via the GUI 1410 and make measurements on this visual model, while bill of materials (BOM) cost analysis software would read the text-based descriptions 1420 of the design parameters.

[0220] Furthermore, Figure 14 shows an exemplary editing action 1430 relating to an aircraft propeller engine, in which one of the propeller blades is manually selected by the user for further visualization, modification, analysis, and / or optimization. For example, the user may choose to hide the blade from the view. Correspondingly, a function script 1440 for execution on the CAD model file is shown to perform the same component delete / hide functionality.

[0221] Generally, the creation and editing of DE models is performed via a GUI, using various DE tools provided by proprietary modeling software, or by scripting using API commands provided by the modeling software. Just as it takes time for users to learn a GUI, the learning curve for scripting languages ​​is steep. For example, commercially available API libraries are typically highly sophisticated, consisting of dozens of packages, each containing hundreds of nested classes, enumerations, methods, and properties.

[0222] Figure 15 shows an exemplary example of splicing results for a CAD model in IDEP according to several embodiments of the present invention. In this example, an input CAD file 1500 for a propeller engine is spliced ​​into model data and a splice function written as a script that calls a native DE tool API. The exemplary model data is shown in a GUI interface 1510 having input parameter fields on the left and output visualizations on the right. The data schema and / or API script may be accessed via a separate tab 1520 of the GUI that lists the input and output schemas for the API endpoint to pass the required values ​​to the CAD model or to provide the output location for the modified native file.

[0223] Figure 16 is a screenshot 1600 of an exemplary model splicer interface according to several embodiments of the present invention, showing a visual representation of an input aircraft propeller engine file and three default / basic model splices obtained from the model splicing process: Hide Parts & Share 2D File, Share 2D Image of Model, and Share Editable Parameters with 2D Image. Figure 17 is a screenshot 1700 of an exemplary model splice “Hide Parts & Share 2D File” generated from the input CAD file shown in Figure 16, according to an embodiment disclosed herein. Figure 18 is a screenshot 1800 of an exemplary user interface for receiving user input to add a splice function to the exemplary model splice of Figure 17, according to an embodiment disclosed herein. Figure 19 is a screenshot 1900 of the exemplary model splice of Figure 17 after user modification according to Figure 18, according to an embodiment disclosed herein, and is performed to provide output.

[0224] In some embodiments, model type-specific base model splices may be automatically generated by IDEP when a model file is uploaded. In this particular example, the input file is a CAD data file format containing 3D model attributes (e.g., surface and solid information) of the model parts. The base model splices shown in Figure 16, each containing one or more API scripts, may be automatically generated by the model splicer system and are specific to the input CAD file type. These base model splices represent a typical set of model data and functions used for model verification and sharing. For example, when a splice for hiding a selected part and sharing a 2D file model—for example, hiding a selected part(s) of an input 3D model of an aircraft propeller engine—is selected and executed by the user, one or more updated part files (e.g., engine_noPropeller.prt) may be generated. In Figure 17, user input is received to hide a selected propeller part of a propeller engine. This model splice includes component part data for an input propeller engine, such as the propeller, engine cylinders, engine caps, and engine radiator, and a splice function written as an API function script to hide one or more selected components from the view and to share the results of the wrapper's execution. The left side is an input panel for receiving user selections of component parts to hide. The right side is an output panel that visually displays the results of the wrapper's execution.

[0225] The user may further modify the selected base model splice / wrapper by adding one or more functions specific to the input model data file type. For example, by selecting the “+ New Input” icon in FIG. 17, a function library may be presented to the user, and the user may choose to add the Reduce Triangle Count(Select) function to reduce the fidelity of the model by decreasing the number of triangles in the rendering as shown in FIG. 18. When added, as shown in FIG. 19, a new input field is displayed and the user can then select from high, medium, low, and lowest fidelity options.

[0226] FIG. 19 shows an exemplary screen capture 1900 of a shared ready-to-splice model according to an embodiment disclosed herein. The model splicer wraps the input model file in a transformation for secure sharing. In this particular example, the transformation is a low-fidelity version of the input aircraft propeller engine without a propeller, visualized on the right side of FIG. 19. In general, the model splice / transformation, when executed, may provide various capabilities including, but not limited to, linking, querying, and managing DE models and digital artifacts. 1. Data queries, for example, a. For a given 3D CAD model, where is the centroid and what is the weight? b. For a given digital requirements model, what are the technical architecture components related to this requirement? c. For a given DE model, what is the cost associated with a particular requirement? 2. Selective modifications to model parameters, for example, a. Query and change a subset of requirements b. Change the scale of a particular sub-assembly c. Change the relevant properties or metadata of a selection 3. Data editing, for example, a. Edit the details of the assembly (e.g., hide sub - parts or sub - assemblies) b. Change the visual display to reduce fidelity or resolution c. Edit aspects of the technical architecture d. Obscure how the proprietary model calculations are performed 4. Creation steps, e.g., a. Create a new product or model from text input b. Create and link documentation associated with an existing model 5. Collaboration, e.g., a. The owner (e.g., the creator of the model spice) uploads files and shares them with collaborators i. Upload a CAD model file ii. Create a model spice using inputs to hide parts and reduce fidelity, and output digital artifacts such as 2D images iii. Run a wrapper iv. Share the wrapper with collaborators (multiple possible) and give them viewer rights b. Collaborators interact with the files from the owner i. View a low - fidelity 2D image containing the edited parts

[0227] API script generation In the foregoing example of an aircraft propeller engine, the model splicer can generate a HideParts(parts_list) API function script or splice function (see Figures 17, 18, or 19) that can hide parts within the CAD model, and a single function call can be executed via the model spice that shares the hidden & compressed 2D file. Settings.Operation == Operations.HideParts

[0228] By comparison, the following is pseudocode for HideParts, which illustrates the complexity of example code written using native API functions to implement the HideParts splice function, and the fact that CAD software users will need to write the code themselves by first learning the software's native API library.

[0229] Examples of pseudocode: / / Pseudocode for Hide_Parts code 1. Function RemoveComponents(): a. Clear the Session UpdateManager error list. b. Create a parts array and add the parts to it. c. Add the component to the UpdateManager's delete list. d. Get the most recently displayed undo mark (id) and perform the update. e. Catch the exception, log it, and then throw a new exception along with the error. 2. Main code: a. Loop through the ModelParts in modelAssembly.Parts. If part.Name is in removedParts, call RemoveComponents on the part. b. Create an EntityBuilder with theSession and retrieve the workPart. c. Obtain the root component and construct an entityBuilder object. d. Create a ModelAssembly and set its properties using the result of entityBuilder. e. Set ModelAssembly.Status to "Success" and set FilePath to InputFilepath. / / End of pseudocode

[0230] Code example: / / Hide_Parts / / First, it is necessary to remove components from the root assembly / / Next, reconstruct the model assembly object foreach {ModelPart part in modelAssembly.Parts) { if (removedParts.Contains(part.Name)) { part.RemoveComponents(); } } entityBuilder = new EntityBuilder(theSession); workPart = thesession.Parts.work; root = workPart.ComponentAssesbly.RootComponent; if {root != null) entityBuilder.Built(root); else entityBuilder.Build{workPart}; modelAsseably =new ModelAssembly{theSession); modelAssecbly.Root = entityBuilder.Root; modelAsseably.BillOfMaterials = entityBuilder.BillOfMaterials; modelAsseably.Parts = entityBuilder.Parts; modelAssecbly.Status= “Success”; modelAsseably.Fi\ePath = settings.InputFilepath; internal void RemoveComponents() { try { Session.UpdateManager.ClearErrorlist(); Open.TaggedObject[] Objects = new Open.TaggedObject[_components.Count]; for (int i = 0;i < _components.Count;++i) Objects[i] = _components[i]; int nErrs1; nErrs1 = Session.UpdateManager.AddObjectsToDeleteList(Objects); Open.Session.UndoMarkID id1; id! = _Session.NewestVisibleUndoMark; int nErrs2; nErrs2 = Session.UpdateManager.DoUpdate(id1); } catch (Exception ex) { Logger.Log(LogLevel.Error, $“Error removing {_part.Name}”); Logger.Log(LogLevel.Error, $“Message: {ex.Message}”); throw new Exception($“Error While hiding part \”{_part.name)\“”); } }

[0231] The HideParts function, when written using the native DE tool's API, is quite complex and clearly may require multiple script files. Users face a steep learning curve to interface with CAD models solely through native APIs, without relying on a graphical user interface (GUI). This becomes even more complex when considering multiple DE models with different tool APIs. In IDEP, this complexity is absorbed by the Model Splicer, which encapsulates tool-specific API commands into platform API scripts.

[0232] Furthermore, executing APIs may require expensive software licenses to interface with proprietary model file formats. While all current engineering design and simulation software platforms offer similar models, none have the best tools.

[0233] Various embodiments of the model splicer disclosed herein may employ both proprietary and / or open-source file formats and API functions. In a first embodiment, the model splicer may write splice function scripts for a customer, who may execute these scripts using their own license in accordance with an End User License Agreement (EULA). In a second embodiment, the model splicer uses a combination of open-source files and open-source APIs to transition, for example, from the use of proprietary files (e.g., *.prt) to the use of open-source files (e.g., *.obj, *.stl, *.stp). Many open-source model file types are available. In a third embodiment, the model splicer may use only APIs from open-source tools and finally convert back to a proprietary format. One challenge in this process is that there may be some data loss between conversions, however, proprietary tool providers may offer excellent import tools for importing from open-source file formats. Table 2 below lists exemplary combinations of proprietary and open-source file formats and DE tool functions / APIs that can be used in the model splicer embodiment. Three combinations are listed in the following three columns, but other combinations are equally possible.

[0234] [Table 2]

[0235] Exemplary model data and digital deliverables from computer-aided design (CAD) models Figure 20 is a schematic diagram of an exemplary data structure for storing model data and digital artifacts extracted or derived from computer-aided design (CAD) or computer-aided design and drafting (CADD) models, according to some embodiments of the present invention. As illustrated by the examples shown in Figures 16–19, computer-aided design is the use of computers to digitally create real-world products in 2D or 3D to assist in the modification, analysis, and optimization of designs..dwg, .dxf, .sldprt, .sldasm, .slddrw, .catpart, .catproduct, .prt, .asm, .ipt, .iam, .cas, .dat, .foam, .mph, .sim, .sce, .ans, .rst, .inp, .od b, .nas, .pch, .op2, .f06, .pdb, .bdf, .dxl, .alm, .eap, .eapx, .archimate, .rsa, .vpp, .adf, .rsk, .xls, .xlsx, .cstx, .dpl, .pfd, .tc, .wc, .enovi a, .rvt, .rfa, .rte, .pln, .lcf, .gsm, .dgn, .dgnlib, .vwx, .skp, .nlogo, .alp, .rs, .gaml, .java, .vmf, .vpm, .itm, .stmx, .adm, .bin, .spc, .mbd, .mvw, .vl, .hfss, .cst, .feko, .cir, .ckt, .asc, .ms14, .tsc, .ipk, .pdml, .zmx, .zda, .cv, .srf, .fred, .lt, .asap, .shp, .gdb, .mxd, .qgs, .gpkg,. gmw, .grass, .gvsig, .doe, .simproj, .fsm, .mox, .m, .mat, .vi, .df, .shm, .dem, .dtm, .tif, .asc, .grd, .simscale, .hm, .unity, .asset, .prefab, .uproject, .umap, .uasset, .html, .js, .max, .fbx, .pb, .ckpt, .pt, .pth, .pkl, .h5, .json, .bin, .gjf, .g03, .g09, .inp, .dat, .nw, .nwo, .inp, .ou There are numerous widely available types of proprietary and open-source CAD file formats, including, but not limited to, .t, .in, .out, .gro, .top, .mdp, .psf, .pdb, .conf, .crd, .psf, .inp, .prmtop, .inpcrd, .mdin, .lmp, .data, .in, .inp, .out, .bin, .inp, .out, .log, .hysplit, .inp, .out, .adms, .cfg, etc., in text or binary formats.CAD files can be parsed to obtain digital artifacts that may include technical drawings, blueprints, schematics, or renderings of real-world objects, and may also include model data, metadata, and derived data. In some embodiments, a CAD model splicer can splice a single CAD file format using an appropriate DE tool that supports this CAD file format (e.g., a native DE tool associated with the native CAD file format). In some embodiments, a CAD model splicer can splice a selected number of CAD file formats by first detecting the file format and then determining the available or accessible engineering toolboxes. As shown in Figure 20, a CAD model file can be broken down into component data that includes, but is not limited to, assemblies, parts (e.g., bodies, solids, surfaces / faces, curves / edges), model parameters, model history (e.g., feature trees), constraints, physical properties (e.g., material, dimensions, mass properties), product manufacturing information (PMI), geometric dimensions and tolerances (GD&T), user-defined data, drawings, views, and polygon representations with various levels of detail (LOD).

[0236] In IDEP, model data or digital artifacts from CAD models, and other types of digital models, can be stored as separate files and JSON metadata files. This universal and standardized setup helps maintain a unified data type across various model types. Such digital artifacts may include, but are not limited to, metadata, original CAD files in native formats, CAD model polygon representations for visualization and 3D printing, different views of the model, and bill of materials tables.

[0237] The following is an example data structure for digital artifacts extracted or derived from a CAD model, written in JSON format as a list of variables. { “rootAssembly”: { "id": 0, "name": "Gear", “type”: “Part”, “children”: null }, “billOfMaterials”: ​​[ { “partName Back: “Gear”, “type”: “Part”, “partCount”: 1, “weight”: 0.0, “mass”: 0.0, “volume”: 0.0, “area”: 0.0, “material”: null } ], “parts”: [ { "name": "Gear", “material”: null, “bodies”: [ { “name”: “”, “id”: 0, / / The type can be sheet or solid. “type”: “Solid”, / / The bounding box for the main body. “boundingBox”: { “minCorner”: { “x”: -363.29020457370183, “y”: -370.328341109766, “z”: 0.0 }, “maxCorner”: { “x”: 363.29020457370206, “y”: 370.32834110976592, “z”: 120.0}, “dimensions”: { “x”: 726.58040914740388, “y”: 740.65668221953183, “z”: 120.0 }, “center”: { “x”: 1.1368683772161603E-13, “y”: -2.8421709430404007E-14, “z”: 60.0 } }, “massProps”: { / / SurfaceArea: The total surface area of ​​the device. “surfaceArea”: 11182.427352959272, / / Volume: The volume of the main body. If the main body type is a sheet, it is zero. “volume”: 39681.4510976672, / / Mass: The total mass of the main body in grams. “mass”: 310731.15822343668, / / CenterOfMass: The coordinates of the mass of the main body in the World Coordinate System (WCS). “centerOfMass”: { “x”: -2.0251382073768754E-16, “y”: -5.4736686832914439E-15, “z”: 6.0 }, / / FirstMoments: The first moment (center of gravity) of the main body in WCS. “firstMoments”: { “x”: -6.2927354074075078E-11, “y”: -1.7008394096905041E-09, “z”: 1864386.94934062 }, / / MomentsOfInertiaWCS: Moment of inertia of the main body in WCS. “momentsOfInertiaWCS”: { “x”: 113042396.68129998, “y”: 113042396.68130012, “z”: 196254602.17315021 }, / / MomentsOfInertiaCentroidal: Moment of inertia (center of gravity) of the main body. “momentsOfInertiaCentroidal”: { “x”: 101856074.98525627, “y”: 101856074.98525642, “z”: 196254602.17315021 }, / / SphericalMomentOfInertia: The spherical moment of inertia of the main body. “sphericalMomentOfInertia”: 199983376.07183146, / / InertiaProductsWCS: The product of inertia of the main unit in WCS. “inertiaProductsWCS”: { “x”: -1.0635097345378154E-08, “y”: 6.4592450027546993E-10, “z”: -5.7042166671551855E-09 }, / / InertiaProductsCentroidal: The product of inertia of the main body (center of gravity). “inertiaProductsCentroidal”: { “x”: -4.3006088723513236E-10, “y”: 1.0234886247199205E-09, “z”: -5.7042166671551855E-09 }, / / PrincipalAxesWCS: The main axis of the WCS. “principalAxesWCS”: [ { “x”: 0.0, “y”: 0.0, “z”: 1.0 }, { “x”: 1.0, “y”: 0.0, “z”: 0.0 }, { “x”: 0.0, “y”: 1.0, “z”: 0.0 } ], / / PrincipalMomentsCentroidal: The main moment (center of gravity) of the main body. “principalMomentsCentroidal”: { “x”: 196254602.17315021, “y”: 101856074.98525627, “z”: 101856074.98525642 }, / / RadiiOfGyrationWCS: The rotation radius of the main body in WCS. “radiiOfGyrationWCS”: { “x”: 19.073407013460528, “y”: 19.073407013460542, “z”: 25.131448629202641 }, / / RadiiOfGyrationCentroidal: The rotational radius (center of gravity) of the main body. “radiiOfGyrationCentroidal”: { “x”: 18.105105774369981, “y”: 18.105105774369996, “z”: 25.131448629202641 }, / / SphericalRadiusOfGyration: The spherical radius of rotation of the main body. “sphericalRadiusOfGyration”: 25.369069951463558, / / Density: The density of the main body. “density”: 7.8306400000000007 } } ], “userDefinedExpressions”: [ { “name”: “HoleDiam”, “value”: 180.0, “exprString”: “HoleDiam=180” }, { “name”: “CogsCount”, “value”: 10.0, “exprString”: “CogsCount=10” } ], “features”: [ { “name”: “Extrude(1)”, “type”: “EXTRUDE”, “expressions”: [ { “name”: “p0”, “value”: 0.0, “exprString”: “p0=0” }, { “name”: “p1”, “value”: 120.0, “exprString”: “p1=120” } ] }, { “name”: “SKETCH_001:Sketch(2)”, “type”: “SKETCH”, “expressions”: [ { “name”: “HoleDiam”, “value”: 180.0, “exprString”: “HoleDiam=180” } ] }, { “name”: “Extrude(2)”, “type”: “EXTRUDE”, “expressions”: [ { “name”: “HoleDiam”, “value”: 180.0, “exprString”: “HoleDiam=180” }, { “name”: “p3”, “value”: 120.0, “exprString”: “p3=120” } ] }, { “name”: “SKETCH_002:Sketch(3)”, “type”: “SKETCH”, “expressions”: [ { “name”: “Pattern_p28”, “value”: 10.0, “exprString”: “Pattern_p28=10” }, { “name”: “Pattern_p29”, “value”: 360.0, “exprString”: “Pattern_p29=360” } ] }, { “name”: “Extrude(6)”, “type”: “EXTRUDE”, “expressions”: [ { “name”: “p4”, “value”: 0.0, “exprString”: “p4=0” }, { “name”: “p5”, “value”: 120.0, “exprString”: “p5=120” } ] }, { “name”: “Pattern Feature [Circular](7)”, “type”: “Pattern Feature”, “expressions”: [ { “name”: “CogsCount”, “value”: 10.0, “exprString”: “CogsCount=10” }, { “name”: “p16”, “value”: 360.0, “exprString”: “p16=360” } ] } ] } ], “status”: “Success”, “message”: null }

[0238] Figure 21 illustrates a model splicing process for hiding parts of a CAD model according to several embodiments of the present invention. Starting in step 2110, assuming the user is logged in, the user first uploads a CAD model to IDEP in step 2120. IDEP can process the input model file by sending messages to the appropriate server, microservice, computing entity, or computing module, and may extract data from the CAD model into a data structure in step 2122, as illustrated with reference to Figure 20, for example. Note that the data extracted from the model may not represent the entire model, and some fields in the data structure shown in Figure 20 may be empty / null. The system may store model-type-specific data structures in the system database 2130 and create a CAD model splice in step 2124.

[0239] Next, the system may prompt the user to determine whether the model contains sensitive model parts 2126. For example, the HideParts splice function may be made available, and the user may select this function in step 2140 (e.g., via an interface such as Figure 18) as an implicit indication that the model contains sensitive information. The system may enumerate parts from the variables extracted in step 2142, and further allow the user to select one or more sensitive parts to hide from the list in step 2144 (e.g., via an interface such as Figure 19). The system may then call the HideParts API in the background with the parts selected in step 2146 as parameters, while in step 2148 displaying the CAD model containing the hidden parts based on the user selection output. In various embodiments, the output of this model splicing and CAD part hiding process may include, but is not limited to, a 3D view (e.g., a visual representation of the model with the selected part hidden from the view), a downloadable link (e.g., a link to the CAD model with the part removed), 2D renderings from standard views such as top, left, right, and isometric views, a BOM table (e.g., a table showing the part's frequency and material attributes), and an STL file for 3D printing. After the user shares the model splice with a collaborator in step 2128, the process ends in step 2150.

[0240] Exemplary Embodiments of Model Splicing Computing and Simulation Scripts Figures 22-24 illustrate exemplary model splicing processes for scientific and engineering computing and simulation models. Figure 22 is an exemplary schematic diagram showing exemplary computing and simulation scripts defining an optimization problem according to several embodiments of the present invention, as well as exemplary data structures for storing data extracted from such scripts.

[0241] Specifically, Figure 22 enumerates the data items that may be extracted from a given computing and simulation script 2210 by parsing the file / script and by performing one or more of the following in step 2220: variables, functions, function signatures, function arguments, code comments, file load / save function calls, package dependencies, documentation strings, and execution dependency graphs for entry function extraction. Here, "function" refers to a script function or method contained in the input computing and simulation script. The extracted model data is stored, and the system may present all the extracted data when the user creates a new model splice, so the user may choose which data to share / execute.

[0242] In various embodiments, the exemplary extracted model data listed in Figure 22 may be defined as follows: 1. Function Signature: Represents the function name, input arguments, and return data. 2. Function arguments: The names of the arguments passed to the function, and potentially their types, even if they are not specified in the function signature. 3. Variables: System parameters that are usually defined outside of function definitions and allow the user to change system parameters. Note that not all input scripts have variables. a. Global variables b. Constant variables c. For example, a parameter defined in an input script outside of a function that is neither global nor a constant. 4. File Load / Save Function Calls: Similar to variables, but typically declared within functions. File load / save calls help identify files that need to be packaged along with the model splice. a. Load / Save (e.g., script files) b. csvread / csvwrite (for example, CSV file) c. xlsread / xlswrite (for example, spreadsheet file format) 5. Dependencies of input codes (e.g., codetools.requiredFilesAndProducts) that represent dependencies on system packages or user-defined packages. Such dependencies may not affect the model splicing process in some embodiments of the present invention. 6. Code Execution Dependency Graph for Extracting Entry Functions: A directed acyclic graph (DAG) is generated based on the dependencies between the extracted functions and their calls within the tool package. Having the roots of these DAGs allows for the identification of the main entry functions of the simulation package. As a result, instead of listing all functions within the scientific / engineering computing and simulation packages, entry functions can be listed for the user to select.

[0243] Exemplary model data and digital artifacts from computing and simulation script models The following is an example data structure for digital artifacts extracted or derived from scientific or engineering computing and simulation script models, again written in JSON format as a list of variables. { “output”: { “type”: “mt” }, “node_id”: “backend-01ab1010-88c7-4e3a-8247-2b753ce3f207”, “node_name”: “extract_signatures”, “result”: { “calculateAverage”: { “inputs”: [ “x” ], “outputs”: [ “ave” ] }, “testFn”: { “inputs”: [ “in1”, “in2” ], “outputs”: [ “out1”, “out2” ] } } }

[0244] Figure 23 is an exemplary schematic diagram 2300 illustrating how information can be extracted from scientific or engineering computing and simulation scripts representing mathematical functions according to several embodiments of the present invention, and how this information can be used to construct a model splicer user interface. Specifically, a script 2310 of a drag function having four inputs 2331, 2332, 2333, and 2334 may be spliced ​​via a computing and simulation script model splicing process 2320, so that when a user of the model splice updates the inputs, the corresponding output drag force 2335 is computed via a splice function (i.e., described in the IDEP platform script) that implements equation 2315 in the input script 2310, without requiring a native scientific or engineering computing and simulation platform to run the function script on the left.

[0245] Figure 24 shows two screenshots of GUI 2400, which can be used to view or run model splices of mathematical function scripts, according to several embodiments of the present invention, and GUI 2400, which can be used to model splice input functions related to the left wing of an airplane under design. In this case, too, these input functions are defined by scientific or engineering computing and simulation scripts. Similar to Figure 23, screenshot 2401 provides individual fields for the model splice user to set input arguments for the input functions, as well as to enable or hide selected input and / or output fields. Screenshot 2401 also provides a graph of the calculated output, as well as options given to the user to further modify or share the model splice. Screenshot 2402 shows a second input function related to the left wing of an airplane under design being spliced. The user may choose to include additional model data in the model splice or generate new digital artifact outputs. The user may run this model splice 2420 directly without accessing the scientific or engineering computing and simulation platform required to run this second input function.

[0246] Although not explicitly shown in Figure 24, the illustrated embodiments of the model splicer may provide the following exemplary functions, without limiting their scope: A data owner may create a model splice or wrapper by uploading scientific or engineering computing and simulation files, selecting inputs and outputs for a function, running the model splice, sharing the model splice with a collaborator(s), and granting viewers access to users. Collaborators may interact with the model splice from the owner by providing inputs(s) to the splice function(s) and receiving outputs(s) from the splice function(s).

[0247] Exemplary Embodiment for Integrating IDEP with a Simulation Engine Using Model Splice Figure 25 is a schematic diagram of an exemplary embodiment showing the integration of IDEP with a simulation module using model splicing according to several embodiments of the present invention. This exemplary architecture is applicable to event-based simulations, co-simulations, or any generalized simulation, with or without the use of computation and simulation scripts.

[0248] Generally, simulations do not start entirely from scratch, but instead require a set of input points in the form of models and simulation parameters. For example, data outputs 2506 from other DE tools and data sources such as SysML and OpenCAD may be directed to or shared with the simulation engineer 2504 via the user interface 2502. The simulation engineer may revise and update such data before sending it to the simulation platform via an API or GUI so that it becomes input for the simulation run performed by the simulation engine 2530. For example, the simulation engineer 2504 may appropriately link individual DE models and data points to digital threads, modify simulation parameters, and feed these to the API gateway 2508 in the IDEP via the user interface 2502. This API gateway may provide a REST API to various simulation scripts and actions and may be connected to object storage 2520 (e.g., a Cloud Storage Simple Storage Service (S3) bucket) used to access DE models, store digital threads, etc. Object storage 2520 may also be used to store simulation scripts that the simulation module 2530 may need to run the simulation. Such simulation scripts may be created as individual splices from reference scientific or engineering simulation software.

[0249] Orchestration scripts that execute commands to run the simulation on a digital thread can reach the module communication interface 2532 of the simulation module 2530 via a message queuing service 2522, for example, the IDEP's job service (for example, provided by the service cell of IDEP 302 in Figure 3). The simulation engine 2530 may further consist of an execution submodule 2534, a data extraction submodule 2536, and a simulation software interface 2538. Upon receiving a request message, the simulation module 2530 may process the message, extract data, access object storage 250, and run the simulation via the simulation software interface 2538.

[0250] In some embodiments, the module communication interface 2532 may be implemented as part of the customer-side IDEP agent of the platform (e.g., IDEP exclave 316 in Figure 3). Output from the simulation run may be fed back to the API gateway 2508 via a response queue in the message queuing service 2522, for review by a simulation engineer, for example. The user interface 2502 may present the simulation results for user review and enable further simulations as needed. Additional digital threads may further link the simulation results 2510 to output documents 2512 via API endpoints, or link DE tools such as SysML tools to validate requirements or perform other relevant DE tasks.

[0251] In some embodiments, the simulation output, which has a publicly accessible API endpoint, may be sent upstream or downstream of the digital thread 2514 to other DE tools in the customer environment, for example, as subsequent input or for validation and verification purposes. In some embodiments, such a digital thread may be managed by an IDEP agent (e.g., the IDEP exclave 316 in Figure 3), and the execution output 2510 (via message response queues and API gateways) may be further linked to an output document 2512.

[0252] Model splicing: An exemplary embodiment of a model-based systems engineering (MBSE) model. Figures 26–29 provide exemplary examples of how a user can interact with MBSE model splicers and model splices through different user interfaces, where the MBSE model is described in System Modeling Language (SysML).

[0253] Specifically, Figure 26 shows an exemplary script 2610 that defines an MBSE model and an exemplary data structure for storing data extracted from such an MBSE model, according to several embodiments of the present invention. When analyzed, the inputSysML file can be broken down into requirements, figures, and requirements exchange format (ReqIF) files and stored as such.

[0254] Figure 27 shows a screenshot of an exemplary model splicer GUI 2700 for receiving user input for model splicing an MBSE model of an airplane propeller, according to some embodiments of the present invention. In this example, data owner Rober Fox 2710 uploads the input MBSE model "Airplane Propeller Diagram Ver2.5" 2712, and the base model splice "Airplane Propeller Diagram Wrapper" is presented. On the left, under the "Input" panel of GUI 2700, the airplane requirements 2714 extracted from the input MBSE model file 2712 are presented. If the input model file already contains airplane architecture diagrams, a list 2716 of such diagrams may also be enumerated in the input panel, and an interactive field receives user input regarding which diagrams to present or render based on the user-updated requirements 2714. In some embodiments, the input model file may contain only requirements data, but the model splicer system may identify the list 2716 based on the requirements data and / or model metadata. In some examples, the user may select the "+ New Input" icon 2718 to select additional model data or additional splice functions specific to the input model file type to generate the desired digital artifacts. On the right, under the "Output" panel of the GUI 2700, user-selected diagrams, such as an aircraft requirements diagram 2720, may be rendered by the model splice function and presented via the GUI at the user's request. The user may further select the "+ New Output" icon 2722 to generate additional digital artifacts that will be included in the generated model splice.

[0255] Although not explicitly shown in Figure 27, embodiments of the model splicer described herein enable the following functions, which are non-exclusive, non-limiting, and for illustrative purposes only: The data owner 2710 may upload an MBSE file, create a first requirement splice to facilitate requirement updates or requirement validation, run a model splice, share the model splice with collaborators(s), grant them viewer permissions, create and run a second chart splice to show / hide charts, share the chart splice with collaborators(s), grant them viewer permissions. Collaborators may interact with the model splice from the owner to view charts, view requirements, and update requirement values.

[0256] Figure 28 shows a screenshot of an exemplary GUI 2800 provided by IDEP to a collaborator for viewing digital artifacts from a received model splice, according to several embodiments of the present invention. This exemplary GUI 2800 may be provided via a web portal. User Orville Wright 2810 can log in and then open the received requirements model splice to view the digital artifacts from the requirements model. A directory 2820 titled "Operational Architecture Extracted Data" contains requirements model digital artifacts 2830, including diagrams and requirements data files. Such digital artifacts may be included in the received model splice as part of a compressed .zip file. Alternatively, in some embodiments, digital artifacts such as operational architecture diagram images may be assigned a unique Uniform Resource Locator (URL) address so that they can be stored in a customer bucket and loaded upon user request. Similarly, this URL may be referenced in other model splices or documents. Furthermore, in this example, each listed digital artifact is assigned the same Information Security (Infosec) level 2840 as the domain security level shown in banner 2845. In some embodiments, a digital artifact may inherit security attributes or characteristics of its parent DE model. In some embodiments, the information security level of a digital artifact may be downgraded from the information security level of the source model, but never exceed it. In some embodiments, user authorization may be checked against the information security level when a user requests to view a digital artifact. For example, a user with a low information security level (e.g., level 1) may not be permitted to view details of a digital artifact with a higher information security level (e.g., level 2).Other fields shown in the exemplary GUI 2800 include additional metadata 2850 that may be recorded to track when, by whom, and using what code and / or parameters the digital artifact was created or updated, a comments and review / approval log 2860, user interface buttons 2870 (e.g., copy link, add comment, view document information, add new file, share access, etc.), and a browser window header 2880 with a digital thread link. A single model splice, such as the one shown in Figure 28 with an executable splice function, can be seen as a simple, addressable digital thread.

[0257] Figure 29 shows a screenshot of an exemplary GUI or web portal 2900 provided by IDEP to a collaborator for viewing, executing, and updating received model splices, according to several embodiments of the present invention. After logging in, user Orville Wright 2910 can open a received requirements model splice 2920 titled "Operational Architecture" and view a requirements model update splice function 2930, which includes options to update requirements, extract charts, and export charts. The splice function 2930 may also be viewed as a user intent to the digital thread, along with tags of the execution results. Furthermore, in this example, each listed splice function is assigned the same information security (Infosec) level 2940 as the domain security level shown in banner 2945. In some embodiments, the splice function may inherit security attributes or characteristics of the parent DE model. Other fields shown in the exemplary GUI 2900 include user interface buttons and data fields 2990 for executing digital threads to update the requirements model or requirements model splice and generate or export new charts and graphs; additional metadata 2950 that can be recorded to track when the model splice function was executed to update the requirements data; input and output panels 2960 that show and / or link to the input model, input data, and output summary; user interface buttons 2970 (e.g., copy link, open comment section, view document information, add new file, share access, and export); and a browser window header 2980 with a digital thread link. The model splice shown in Figure 29 is a simple, addressable digital thread similar to 609 in Figure 6 that can be executed to update the requirements model and extract digital artifacts (e.g., charts and graphs).

[0258] In some embodiments employing a zero-trust configuration as shown in Figure 3, zero-trust security in IDEP ensures that users interact with DE models and their associated splices / wrappers, splice functions, and digital artifacts under strict access control, embodying the principle of least privilege. Users can undergo multi-factor authentication and are credentialed according to the required information security level. Access is managed via an attribute-based access control (ABAC) system, authorizing users for specific functions, actions (e.g., viewing, editing, sharing), security levels, and durations within specific model splices of a particular DE model. Thus, model splicing enables the appropriate stakeholders to access the right information from the right sources with the right tools at the right time, in the right context, for the right purpose, facilitating secure, auditable, traceable, iterative, and effective development and review of components and / or systems.

[0259] Furthermore, encryption protects data at rest and in transit, improving confidentiality and integrity. Trust assumptions are continuously re-evaluated, and security is maintained across each session. IDEP can highlight the system's ability to proactively detect and mitigate threats and address security challenges in real time by employing continuous monitoring and detailed logging.

[0260] These measures, including multi-factor authentication, ABAC, continuous trust verification, encryption, and proactive threat detection, are integrated together within the IDEP enclave (e.g., 302 in Figure 3) along with cloud services (e.g., 304 in Figure 3) to maintain zero-trust security principles and significantly minimize unauthorized access and data breaches.

[0261] Exemplary Embodiments of Model Splicing Document Models Figures 30 and 31 show exemplary embodiments of model splicing a document model and performing document splicing. Model splicing of a document model is sometimes also called "document splicing."

[0262] Specifically, Figure 30 shows an exemplary embodiment 3000 of document splicing or document model splicing in IDEP according to several embodiments of the present invention. Figure 30 has a similar structure to Figure 15 for CAD model splicing. In Figure 30, the input document file is spliced ​​into chunks, parts, subunits, or components, with or without hierarchy, each having at least one API endpoint for access and handling. In this exemplary embodiment, the input document is written in paragraph format with text only and is parsed, split, or segmented into individual paragraphs separated by line breaks and paragraph spacing. In various embodiments, parts or subunits of the document may be classified according to type, formatting, spacing, syntax, sectioning, content, theme, or any other predefined or user-defined rules. For example, subunits may be chapters, sections, subsections, paragraphs, sentences, comments, hyperlinks, words, tables, graphs, formulas, and their subparts. In some embodiments, the parts identified from the same document may be of different types, such as title, version number line, author and publisher lines, table of contents, chapters, sections, and paragraphs. In some embodiments, the LLM may be deployed to understand user-defined rules for splicing the document.

[0263] Figure 30 shows exemplary model data in GUI 3010, which has input parameter fields on the left and output visualizations on the right. Also shown is API 3020 for document splicing, which has a single wrapper ID 3030 and individual API endpoints 3040 for each document part. The input document parts are first organized into sections (e.g., 1.0 Introduction, 2.0 Background, 3.0 Design Requirements, 4.0 Cost Requirements), then into individual paragraphs as subparts, each identified by a unique paragraph identifier (ID) that serves as an API endpoint 3040. An API wrapper / script titled "Hide Paragraphs & Share Document" is displayed in GUI 3010. The API wrapper's input parameter fields are listed on the left side of the GUI, with each document part / subpart represented by a label and arranged in a tree structure. The user has the option to select which part(s) to hide or conceal from view, and the result of this action is visualized on the right side of the GUI. In this particular example, "Hidden Text" is displayed with a strikethrough. In other words, the creator of a document splice can choose which paragraphs to hide from users sharing the document splice. Conversely, users of a document splice can submit changes or suggest modifications only to the parts or sections they need access to.

[0264] In various embodiments, a document splicer crawls through an input document file and extracts document data based on factors such as formatting, spacing, punctuation, sectioning, content, semantics, and syntax. As the document model splicer crawls through the document file, it essentially determines how the document data is organized and accessed, as defined by the document file's formatting and / or semantics, and by the document processing tools used when splicing the document, for example, to establish a document data schema. This data schema may describe the structure and format of the document data, and parts of it may be translated into or used to create input / output API endpoints using corresponding input / output schemas.

[0265] The following is an example set of input and output types / schemas. { “inputs”: [ { "id": 1, “type”: “Dropdown”, “name”: “Paragraph Selection”, “options”: “List of available paragraphs” }, { "id": 2, “type”: “Number”, “name”: “Paragraph ID”, “unit”: “integer” }, { "id": 3, “type”: “Text”, “name”: “Paragraph Content”, “unit”: “string” }, { “id”: 4, “type”: “Checkbox”, “name”: “Add New Paragraph” }, { “id”: 5, “type”: “Checkbox”, “name”: “Delete Paragraph” } ] } { “outputs”: [ { “id”: 1, “type”: “Text”, “name”: “Paragraph Content”, “unit”: “string” }, { “id”: 2, “type”: “JSON”, “name”: “Document Structure”, “unit”: “JSON object representing the document’s hierarchical structure” }, { “id”: 3, “type”: “Number”, “name”: “Total Paragraph Count”, “unit”: “integer” }, { “id”: 4, “type”: “File”, “name”: “Download .docx File” }, { “id”: 5, “type”: “Array”, “name”: “Extracted Numeric Variables”, “unit”: “Array of numeric variables found in the document” }, { "id": 6, “type”: “File”, “name”: “Export as .txt”, “unit”: “Text file (.txt) version of the document” }, { "id": 7, “type”: “File”, “name”: “Export as .pdf”, “unit”: “PDF file (.pdf) version of the document” } ] }

[0266] In one exemplary embodiment, once document splicing is complete, the “hide paragraph” document splice may include the following: 1. Instantiation of document data structure: A set of parts, possibly in a hierarchical order, stored in one or more files, including one or more of the following: ● For example, a metadata file (e.g., in JSON format) containing part names / titles and / or API endpoints, written according to the input / output schema of the document model splicer. ● Extracted data files with a unified data structure (for example, JSON or text format files containing pointers to hyperlinks), ● Open source files (e.g., JPG for graphs, OpenDocument for text), and ● Other files (e.g., PDF files, RAR files). 2. An API script, which is code that can be executed in the above 1 to achieve the desired functionality (e.g., hiding paragraphs). ● In some embodiments, some API scripts may already exist (for example, if the document has been previously uploaded and analyzed). During splicing, the user may select a specific subset of API scripts to use within the splice. ● In some embodiments, the platform may automatically generate business process-specific APIs for document splicing. For example, a set of business process-specific APIs, such as HideParagraphs(ParagraphsList), may be created for the input requirements validation report file. In some cases, a single splice may be created, and the user may add or remove functions to update the splice. ● Embodiments for creating and / or linking API endpoints via API scripts ● API scripts are executed through API endpoints. API endpoints are like URLs or address pointers. Each API endpoint may correspond to a specific function or resource, such as retrieving document data, updating document data, or deleting document data. 3. Optionally, the original document file is included in the splice as a separate entry. In this particular example of hiding a paragraph, only the modified document (after the "hide" function is used) may be shared, and the original complete document (with all parts or subparts) may not be shared.

[0267] It is important to note that document splicing involves the extraction of human-readable data accompanying the generation of programming code. Once spliced, subsequent processing of the new document splice may involve text searching for specific metadata (e.g., API endpoints of parts that need to be linked to the document splice in subsequent DE models or digital threads). In other words, text searching is a component within the data processing of document files or the newly created document. However, the search operation is accompanied by embodiments of logic through API scripts or context-specific insights (e.g., which document files might be linked, and which API endpoints need to be linked).

[0268] Figure 31 shows a screenshot of an exemplary graphical user interface (GUI) 3100 used with a digital documentation system according to one embodiment of the present invention. The GUI provides users of the IDEP with digital documentation capabilities. Figure 31 shows a browser window header 3102 containing document links for easy navigation. Below the header, a domain and security level banner 3104 displays the domain, platform software version, and security level, ensuring that users are aware of the domain they are operating in and the security protocols implemented. A security level indicator 3106 displays the maximum security access level for the user within the platform (e.g., "Level 1").

[0269] The interface also includes a search bar 3112, which allows users to perform comprehensive cross-platform searches of digital engineering models, files, and documents through IDEP, thus facilitating efficient information retrieval across the platform. Adjacent to this, user and domain fields 3110 provide information about the user's domain (e.g., client name). The user and domain fields may allow users to log in and access user profiles and subscription information.

[0270] The GUI's top menu provides additional functionality. For example, the document name field 3120 displays the name of the document and may include its version. The document security level indicator 3122 displays the security level of the document being accessed (e.g., "Level 1"). In one embodiment, using an expandable security level menu adjacent to the document security level indicator 3122, the user may select "Show" the target security access level of the document, thus filtering only the portion of the document accessible through a given security level. In other embodiments, the user may also use the document security level indicator 3122 to down-select the security level while sharing the document, resulting in sharing only the portion of the document corresponding to the specified security level. Only security access levels below the user's security level (e.g., "Level 1" in Figure 31) are available for the user to view and share. User interface buttons 3124 include options to request access to all models associated with this document, or to email review information to stakeholders.

[0271] Granular dynamic information security tags (e.g., 3106 and 3122) are an important but optional element of digital documentation systems and their associated GUIs. Model splicers and IDEP systems enable granular dynamic information security tags 3106 and 3122. In some embodiments, the digital documentation system uses metadata of DE models or documents to cross-reference for authorization, licensing, or regulation of updates. In some embodiments, granular dynamic information security tags 3106 and 3122 are dynamic and refresh before any document is updated to ensure that the correct authenticated user has the correct authorized access rights to the digital artifacts and data for performing or viewing the update.

[0272] For document organization and navigation, the GUI includes a document summary viewer 3130 on the left side of Figure 31, providing links to the document's headers and paragraphs and / or sections. Within the summary viewer 3130, a digital thread viewer 3132 displays sections of the document, along with linked digital engineering (DE) models(s), source IT domains, and last communication timestamps, each tagged with an appropriate security level (e.g., "L1"). In some examples, if a section of the document contains content requiring a higher security level for viewing, the user may be presented with the option to request access. If the user requests such access, authorized users with access at a higher security level are notified for review. In other examples, if a section of the document contains content requiring a higher security level for viewing, such sections are not displayed, and the user is not given any prompt to request access.

[0273] In the center of Figure 31, the section viewer 3140 displays the contents of each document section, ensuring that all paragraphs are updated based on the data of the DE model linked to them. Model data and associated security access can be provided through model splicing, as previously mentioned. Finally, on the right side of Figure 31, the digital thread metadata pane 3150 lists digital thread execution / transaction information.

[0274] Universality and extensibility of model splicers Figures 14–31 illustrate four types of digital engineering models: CAD models, MBSE / SysML models, scientific and engineering computing and simulation models, and document models. The IDEP user interfaces (UIs) for representing the splices of these model types are very similar. These UIs can be used to provide human users with easy visualization of digital models and to accept user input, requests, and / or commands to each model splice. While the visualizations of different model types differ (e.g., propeller engine 3D model vs. aircraft requirements diagram vs. multi-input mathematical function vs. airworthiness report), each model can be described in computer code or script. Furthermore, each different model type has or is associated with its own API structure or suite provided by the corresponding DE tool. Model splicers implemented in various embodiments of the present invention can construct splice functions in the form of API scripts to call their respective native APIs, creating, modifying, and interacting with all types of DE modes. Thus, extensibility and scalability can be achieved, as all DE models are treated similarly in the code domain.

[0275] Alternative Implementation of Model Splicers as a Microservices Architecture Figure 3 shows an exemplary embodiment of IDEP in which model splicing is built from microservices under zero-trust safeguards enabled by API services and endpoints. In particular, the agents in Figure 3 are not necessarily trusted and may require authentication / authorization for each specific job involved in generating and executing model splices. By comparison, Figures 32 and 33 provide an alternative embodiment in which IDEP provides a message bus to trusted agents participating in the model splicing process.

[0276] More specifically, Figure 32 is an exemplary microservice architecture 3200 that utilizes trusted agents connected via a message bus to implement model splicers for various DE tools and model type files, as disclosed herein. Microservices are a software development approach that builds large-scale applications as small sets of modular services. In the context of model splicing, the process steps performed by the model splicer can be implemented by modular software components that can be linked as individual services. In this exemplary embodiment, an API gateway is provided for uploading DE models to microservice modules, each having web service, database, and file storage capabilities. Individual microservice modules may crawl a model and determine the atomic-level data structure of the model (for example, in the case of CAD, crawling each part to discover each face, curve, line, and code), and may further create a data structure of multiple files to represent that model. These files may include the original file, open-source clones, and one or more of other data representations such as JSON files and database inputs. Microservice modules may communicate with each other and with native modeling tools via a message bus. Based on user instructions / requests or target applications, further microservices can be created or generated using the model splicer embodiment shown in Figure 32, in the form of model splices that can link to other model splices generated from different model type files.

[0277] Figure 33 shows a more detailed microservice architecture 3300 that utilizes trusted agents connected via a message bus to implement model splicers for various DE tools and model type files, according to several embodiments of the present invention. Extending the example shown in Figure 32, three microservices are provided: a file wrapper microservice, a wrapper execution microservice, and a user management / access control list (ACL). In this embodiment, the file wrapper microservice generates model splices, the wrapper execution microservice executes wrapped API scripts on the wrapped model data based on user instructions, and the user management microservice controls user access to a subset of data and API functions. A high-throughput, low-latency messaging service is provided between the microservice modules and a native digital engineering server or platform that clients may access through user licenses, using a message bus (e.g., an open-source platform such as Kafka). Note that the two CAD / CAM / CAE servers on the right represent instances where multiple CAD / CAM / CAE servers are used by the same client, depending on the client's work. These servers may need to be separated for contractual or economic reasons. While some of the data flow lines in Figure 33 connecting client applications, gateways, microservices, and message buses are depicted as unidirectional (e.g., with a single arrow) or without arrows, it should be understood that each data link is bidirectional to enable data exchange between connected modules.

[0278] In some embodiments, the microservices architecture shown in Figure 33 can be implemented on distributed servers. For example, a first server, Serv1, may store DE model files. This server may be hosted locally with the client, or it may be hosted within a product lifecycle management (PLM) system such as Teamcerter. A second server, Serv2, may implement IDEP, while one or more third servers, Serv3, may host DE tools. In some embodiments, additional servers, Serv4 and Serv5, may be used to host an API manager gateway and a message bus / microservices gateway, respectively, separate from the IDEP microservices module on Serv2.

[0279] In some embodiments, depending on confidentiality and security requirements, the IDEP may include packages or microservices installed on the client's IT stack. In some embodiments, the service may be split between cloud servers and on-premises servers, depending on which the customer uses. Furthermore, in some embodiments, the distributed servers shown in Figure 33 are not physically separated but logically separated (e.g., located on the same physical server but modular to adapt to the enterprise user's IT stack and other needs). In some embodiments, it is possible to deploy the service entirely on the enterprise customer's infrastructure. The distributed server embodiment shown in Figure 33 enables strict model access control by different parts of different organizations.

[0280] Next, an exemplary data flow through the microservice architecture of Figure 33 for implementing the CAD model splicer described with reference to Figures 14-21, according to several embodiments of the present invention, will be described. In particular, one or more of the following specific steps may be performed by embodiments of the present invention in place of, in addition to, or in combination with, any of the process steps described with reference to Figures 11-13.

[0281] Model splicing - Data structure creation 1. The user uploads a CAD model type file (for example, by dragging and dropping it onto the Model Splicer UI). 2. The "Upload File API" is called via the API Gateway (for example, the Amazon Gateway for cloud implementations of the API Gateway, or WS02 for on-premises implementations of the API Gateway). 3. A set of files and identifiers, including file ID, wrapper ID, and execution ID, is constructed on Serv2. 4. This file information, along with the user ID, size, etc., is uploaded to the database on Serv2. 5. (Producer) A message is sent to Kafka, which includes the model type / file format (e.g., CAD), file location, and the function to be called (e.g., "DataExtraction"). 6. Kafka forwards (consumer) messages to the server using the appropriate software tool (e.g., Serv3) based on the model type (e.g., CAD). 7. Kafka messages, which may be in JSON format, are parsed on the server hosting the software tools (e.g., Serv3) by a script (e.g., Wrapper.py) that creates the folder structure on this server. 8. The file folder structure is created on the tool server (e.g., Serv3).

[0282] Model splicing - Data extraction 9. The file is copied from Serv2 (e.g., the cloud server) to Serv3 (the tool server) (e.g., via Wrapper.py), and a JSON file is created with the necessary functions. When the file is first uploaded via the model splicer interface, the first function call (e.g., "DataExtraction") analyzes how the model file is constructed. This function is similar to other functions / model splice API scripts, but it is also a prerequisite for executing the other functions. 10. During file processing / data extraction, proprietary software tool APIs may be called to separate the model into its component parts (for example, by determining whether there is a main function and identifying nested functions). 11. Model files can also be “crawled” to determine their structure (e.g., features, dimensions, views, etc.), and the output may be saved as a JSON file. The term “crawling” broadly refers to traversing the model syntax tree through the text and / or proprietary or open-source software tool APIs that parse the model type files. Crawling different model type files may differ depending on the syntax and schema of the model type files, as well as the specific proprietary or open-source API tools involved. 12. This JSON file contains a simplified structure of the CAD model, which is valuable data for training the AI-assisted embodiment. 13. Additional output may include open-source neutral file formats (e.g., .obj, .stl) which may be used for visualization or rendering tasks without requiring the original proprietary files. 14. The spliced ​​file package, including .JSON and any derived files and data structures (e.g., .OBJ and .STL files), is returned by the splicing platform. 15. The message is returned to the file microservice via Kfka, signaling that the data extraction process is complete. 16. The file microservice parsed the message and updated the database (e.g., Couchbase) with the path to the extracted file (e.g., .JSON, .OBJ, .STL).

[0283] Model splicing - Function wrapping 17. The file wrapping / splicing API is called using the file ID and model file type. 18. The file wrapping / splicing service identifies a list of functions that apply to the model type (e.g., HidePart(list)). The splicing service can identify functions across multiple domains and tools (e.g., Figure 18). 19. Each function (e.g., ReducePolygonCount) includes information about the applicable file types, required parameters, etc. 20. The Model Splicer may create several starter function wrappers for each uploaded model type to help users get a general understanding of how to use the system. In the example CAD model shown in Figure 18, these basic functions are Generate 2D view(), Hide parts(List), Number(), Reduce Triangle Count(Select), etc. In some embodiments, these starter functions are learned by an AI module (e.g., Figure 16). 21. Next, the starter / default / basic model-splice / model-wrapper is generated step-by-step through a loop from a set of files in Serv2 (e.g., model / data parts) and a list of functions that apply to the model file type. 22. The Model Splicer Platform begins processing the files and functions shown below in step 21 to create the starter / default / basic splice / wrapper. To create the model splice / wrapper, an entry for the wrapper is first created in the database. 23. Model splice / wrapper nodes may be created under step 21 using functions and data from a descriptive JSON file. Each model splice node includes specific input API endpoints / user inputs (e.g., fidelity, resolution, size, parts to include, parts to exclude) and output API endpoints. Model splice nodes may start with default values ​​(for example, the airplane propeller example shown in Figure 19 may start with low fidelity, no parts hidden, and in 3D view). 24. Where applicable, users can add functions to update model splices / wrappers (e.g., Figure 18). 25. The user can also update parameters (for example, the user selects "All Parts - Propeller" in Figure 17), wh...

Claims

1. A non-temporary physical storage medium for storing program code, wherein the program code is executable by the hardware processor to cause the hardware processor to execute a computer implementation process for generating a shareable model splice of a digital engineering (DE) model, and the program code is A code that receives a DE model file of a DE model having a DE model type, wherein the DE model file is in a native file format, and the receiving code and Code for extracting model data from the DE model file in the aforementioned native file format, A code that stores the aforementioned model data in a model data storage area, Code that generates one or more externally accessible splice functions that enable external access to one or more digital artifacts derived from the model data stored in the model data storage area, wherein the one or more externally accessible splice functions provide addressable application programming interface (API) endpoints or software development kit (SDK) endpoints that are accessible to third-party applications and users, and the API endpoints or SDK endpoints enable access to the digital artifacts without accessing the entire DE model file and without requiring direct involvement from the third-party application and user using the DE tools associated with the DE model type, Code for generating the shareable model splice of the DE model, wherein the shareable model splice includes access to selected portions of one or more digital artifacts, includes access to at least one of one or more externally accessible splice functions, is accessible by the third-party application and the user via the API endpoint or the SDK endpoint, and the API endpoint or the SDK endpoint provides a unified programming interface to the shareable model splice generated from the DE model having the DE model type, The non-temporary physical storage medium, including the following.

2. The non-temporary physical storage medium according to claim 1, wherein access to the selected portion of the one or more digital artifacts is provided by one of the address, pointer, link, uniform resource locator (URL), and copy of the one or more digital artifacts.

3. The non-temporary physical storage medium according to claim 1, wherein the access to at least one of the one or more externally accessible splice functions is provided by one of the address, pointer, link, uniform resource locator (URL), and copy of the at least one of the one or more externally accessible splice functions.

4. A non-temporary physical storage medium according to claim 1, further comprising program code that executes at least one of the one or more externally accessible splice functions for accessing the selected portion of the one or more digital artifacts from the shared model splice of the DE model and for performing at least one action or calculation on the selected portion.

5. The non-temporary physical storage medium according to claim 1, wherein the shareable model splice includes metadata associated with one or more digital artifacts, the metadata indicating a given version of the DE model file and a timestamp of the time the one or more digital artifacts derived from the DE model file having the given version.

6. The non-temporary physical storage medium according to claim 1, wherein at least one of the one or more digital artifacts is one of the model data stored in the model data storage area, and at least one of the one or more externally accessible splice functions is a read-type function.

7. The non-temporary physical storage medium according to claim 1, wherein the one or more externally accessible splice functions are written in a scripting language.

8. The non-temporary physical storage medium according to claim 1, wherein the program code for extracting the model data from the DE model file includes a model crawling script that involves the DE tool associated with the DE model type via the API or SDK interface of the native tool.

9. The non-temporary physical storage medium according to claim 1, wherein the shareable model splice includes at least one of a first information security tag indicating the level of access to the selected portion of the one or more digital artifacts, and a second information security tag indicating the level of access to at least one of the one or more externally accessible splice functions.

10. The non-temporary physical storage medium according to claim 1, further comprising program code that generates updates to the DE model file using one or more externally accessible splice functions.

11. The aforementioned DE tool is the first DE tool, The non-temporary physical storage medium according to claim 1, wherein the unified programming interface is configured to interface with a first DE tool and a second DE tool that is not directly interoperable with the first DE tool, in order to enable the parallel and interoperable use of a plurality of DE tools.

12. The shared model splice is the first shared model splice, and the DE model file is the first DE model file. The non-temporary physical storage medium according to claim 1, wherein the selected portion of one or more digital artifacts is captured by a second shareable model splice generated from a second DE model file.

13. The program code that generates the one or more externally accessible splice functions, A code to receive user input, A non-temporary physical storage medium according to claim 1, further comprising: code for obtaining access to at least one of the externally accessible splice functions from a splice function data store based on the user input.

14. The program code that generates the one or more externally accessible splice functions, Code that transmits a request from a customer environment to an API gateway service cell provided by the DE platform, wherein the customer environment is not managed by the DE platform, and the request from the customer environment does not modify the production software associated with the DE platform. In the aforementioned customer environment, code that receives access from the API gateway service cell to one or more externally accessible splice functions, A non-temporary physical storage medium according to claim 1, further comprising:

15. The non-temporary physical storage medium according to claim 1, wherein the access to at least one of the one or more externally accessible splice functions is REST-enabled.

16. The non-temporary physical storage medium according to claim 1, wherein the program code that generates the one or more externally accessible splice functions includes code that executes an AI algorithm trained on existing externally accessible splice functions associated with existing model splices for the same DE model type and / or similar DE models.

17. The program code that extracts model data from the aforementioned DE model file is: Code that receives microservice requests about model splicing, Code to construct file information of the DE model file based on the DE model type, Code that sends the DE model file and the file information to the native API server for the DE tool associated with the DE model type, A non-temporary physical storage medium according to claim 1, comprising: code that runs on the native API server and receives from the native API server a plurality of model data files generated from a data extraction process or a model crawling process for the DE model file.

18. The non-temporary physical storage medium according to claim 1, wherein the DE tool associated with the DE model type is selected from the group consisting of model-based systems engineering (MBSE) tools, augmented reality (AR) tools, computer-aided design (CAD) tools, data analysis tools, modeling and simulation (M&S) tools, product lifecycle management (PLM) tools, multi-attribute transaction space tools, simulation engines, requirements model tools, electronic model tools, test plan model tools, cost model tools, schedule model tools, supply chain model tools, manufacturing model tools, cybersecurity model tools, and mission effectiveness model tools.

19. A computer implementation method for generating shareable model splices of digital engineering (DE) models, Receiving a DE model file of a DE model having a DE model type, wherein the DE model file is in a native file format, and the receiving Extracting model data from the DE model file in the aforementioned native file format, The aforementioned model data is stored in the model data storage area, To generate one or more externally accessible splice functions that enable external access to one or more digital artifacts derived from the model data stored in the model data storage area, wherein the one or more externally accessible splice functions provide addressable application programming interface (API) endpoints or software development kit (SDK) endpoints that are accessible to third-party applications and users, and the API endpoints or SDK endpoints enable access to the digital artifacts without accessing the entire DE model file and without requiring direct involvement from the third-party application and user using the DE tools associated with the DE model type, thereby generating the one or more externally accessible splice functions. Generating the shareable model splice of the DE model, wherein the shareable model splice includes access to selected portions of the one or more digital artifacts, includes access to at least one of the one or more externally accessible splice functions, is accessible by the third-party application and the user via the API endpoint or the SDK endpoint, and the API endpoint or the SDK endpoint provides a unified programming interface to the shareable model splice generated from the DE model having the DE model type, The computer implementation method, including the above.

20. The computer implementation method according to claim 19, wherein generating the one or more externally accessible splice functions and generating the shareable model splice of the DE model is performed by a digital agent located within a secure customer environment.

Images