Security Architecture for Interconnected Digital Engineering and Authentication Ecosystems

Abstract

A method, system, and apparatus comprising a computer program encoded on a computer storage medium for securely authenticating a product within an ecosystem. In some implementations, a digital platform receives a user request to access a digital model. The digital platform determines whether the user is authorized to access the digital model. Accordingly, the digital platform generates a transaction request to send to the location of the digital model, the transaction request containing data that identifies the action to be performed using the digital model. The digital platform sends the generated transaction request to the location of the digital model, which triggers the execution of the action. The digital platform receives data representing the result of the performed action. The digital platform provides the data representing the result to the user interface of the user device. The digital platform audits the data related to the transaction request and the data representing the result.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Application No. 63 / 489,401, filed on March 9, 2023, entitled "SECURITY ARCHITECTURE FOR INTERCONNECTED DIGITAL ENGINEERING AND CERTIFICATION ECOSYSTEM", the contents of which are incorporated herein by reference.

[0002] This disclosure relates to the secure provision and use of tools for the certification of digital engineering and digitally engineered products (including modeling and simulation applications).

Background Art

[0003] Digital engineering tools, including modeling and simulation tools that accurately virtualize physical systems or processes for real - world decision - making, enable the agile development of components and / or systems. The certification of these components and / or systems still largely occurs in the physical world using the physical manifestation of digitally engineered components and / or systems (which may sometimes be generally referred to herein as "products").

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Means for Solving the Problems

[0005] This specification describes an interconnected digital engineering and certification ecosystem that offers several advantages over existing technologies for designing, engineering, testing, and certifying products.

[0006] In recent years, digital engineering tools such as modeling and simulation (M&S) tools, computer-aided design (CAD) tools, model-based systems engineering (MBSE) tools, augmented reality (AR) tools, product lifecycle management (PLM) tools, and simulation engines have become available to access corresponding digital engineering models. These digital engineering models may include, for example, requirements models, electronics models, test planning models, cost models, scheduling models, software models, supply chain models, manufacturing models, cybersecurity models, multi-attribute trade-space tools, and mission effects models. The proliferation of digital engineering tools and models has increased the agility of hardware development and manufacturing by virtualizing physical systems and / or processes for real-world decision-making. However, given the current state of these digital engineering tools and models, several challenges remain.

[0007] Firstly, there are numerous and diverse digital engineering tools and models (often designed by different parties), which presents interoperability challenges and can lead to vendor lock-in problems. In particular, directly integrating individual digital engineering tools with each other is costly in terms of both time and money, and the number of interfaces between digital engineering tools increases in proportion to the square of the number of different digital engineering tools (i.e., N). 2(Computational complexity). The numerous and diverse digital engineering tools that exist can also present challenges in implementing scalable applications, automation, machine learning, and / or artificial intelligence across these tools. Better interoperability between digital engineering tools can be crucial in product development, testing, and certification processes that may involve several different digital engineering tools used in parallel or sequentially. Therefore, seamless interoperability between digital engineering tools is desirable to implement such processes by enabling the development of “digital threads” or pipelines that connect the inputs and outputs of multiple digital engineering tools for a particular task.

[0008] Secondly, due to the highly technical nature of many digital engineering tools and models, effectively operating such tools often requires a highly specialized skill set, which limits the number of individuals qualified to use these digital engineering tools. Furthermore, an individual skilled in using one digital engineering tool (e.g., a CAD tool manufactured by a first software company) may not be qualified to use a different type of digital engineering tool (e.g., an MBSE tool), or even a similar digital engineering tool manufactured by a different company (e.g., a CAD tool manufactured by a second software company). This applies not only to the use of the tools through their custom graphical user interfaces, but also to their use through their tool-specific or vendor-specific APIs, which can also require a highly specialized skill set.

[0009] Thirdly, products and solutions designed using a particular digital engineering tool may not be shareable across digital engineering tools (for example, due to a lack of interoperability). In some cases, previously designed products and solutions may not be shareable or searchable by others using the same digital engineering tools to solve similar problems. For example, a repository of previously designed products and solutions may not exist for sharing information about such products and solutions among individuals within the same team, company, or technical field. Furthermore, even if such a repository of previously designed products and solutions exists, it is unlikely to contain information about how and why those products and solutions were arrived at, or to contain a simple way to reuse previous engineering work from models that could potentially limit redundant effort and / or provide useful insights to individuals working on similar, but slightly different, products or problems. This can result in many engineering problems requiring development from scratch rather than being built upon the results of past efforts.

[0010] Fourth, products and solutions designed using digital engineering often require the use of many different tools that not everyone knows how to use. For example, a digital engineering model may be built using a specific MBSE tool, i.e., a digital engineering tool, and someone who needs access to the model (or data generated from the model) may not know how to use this tool. This problem, combined with the fact that many complex systems use many different types of tools, means that in order to understand such a system, an individual may have to know how to use many different tools, which may be extremely rare. This problem is further exacerbated by the fact that someone reviewing information for product certification may not be familiar with some or all of the digital engineering tools and may try to review all the data in legacy formats (such as PDF reports). This poor usability between different modeling tools can cause significant delays and cost increases when developing new products, especially when different people or organizations have different technical skill sets, as models cannot be easily shared between those people or organizations.

[0011] For the reasons stated above, most digital engineering tools today are still built by humans for humans, in a world increasingly driven by machine autonomy. For example, when designing complex systems such as aircraft, various regulatory standards must be complied with, which may require many different models and simulations (and consequently, the use of many different digital engineering tools) for evaluation. Today, such endeavors require the collaboration of numerous highly specialized subject matter experts who examine many regulatory standard documents, inevitably involving many slow and costly human steps in the design and engineering process. Furthermore, current certification processes typically require the manufacture of a physical manifestation of the digitally engineered component and / or system for evaluation in the physical world (e.g., for physical testing), which can slow down the iterative design and engineering process.

[0012] The interconnected digital engineering and certification ecosystems described herein (sometimes referred to as the “digital engineering metaverse”) address each of these issues and others. In particular, the interconnected digital engineering and certification ecosystems may include computing systems (e.g., including networked centralized or distributed computing subsystems or components) that interface with various centralized or distributed digital engineering tools (e.g., via application programming interfaces (APIs) and / or software development kits (SDKs)), where those digital engineering tools can be separate from the computing system or can be considered part of the computing system itself. Digital engineering tools can interface with APIs, and / or SDKs may enable users of the ecosystem (including providers of digital engineering tools) to develop their own APIs for their tools or models to enable their tools or models to interact with the system. For example, a new company might create a new MBSE tool and then add its tool to the ecosystem using an SDK, thereby enabling that tool to automatically interoperate with other tools in the ecosystem via APIs. Furthermore, the new company may be able to maintain its APIs over time, so that the administrator of the entire ecosystem does not have to maintain all the different APIs for all the different tools. This architecture can have the advantage of increasing the ease of interoperability between digital engineering tools.For example, rather than requiring each individual digital engineering tool to integrate with every other individual digital engineering tool in the ecosystem, a computing system can enable the interoperable use of multiple digital engineering tools implemented in multiple other computing systems (or, in some cases, within the same computing system), as long as each tool is integrated with the computing system. Furthermore, rather than requiring users of digital engineering tools to interact separately with various digital engineering tools to perform modeling and simulation, a computing system can enable users to interact with and utilize a single user interface for the computing system in the ecosystem, and furthermore, the computing system in the ecosystem can interface with many digital engineering tools. This can result in a flatter learning curve for users, who only need to be familiar with a single user interface (e.g., the user interface associated with the computing system) rather than several different user interfaces (e.g., associated with various digital engineering tools). Also, this can increase the number of interfaces between digital engineering tools to N. 2 The computational complexity can be simplified from n to N, where N represents the number of digital engineering tools included in the ecosystem. This, in turn, can easily generate scalable applications, automation, and / or machine learning and artificial intelligence that span various digital engineering tools.

[0013] An interconnected digital engineering and certification ecosystem also has the advantage of including digitized regulatory and certification standards, compliance, computation, and testing (for example, for the development, testing, and certification of products and / or solutions), which can enable users to directly integrate relevant regulatory and certification standards, compliance, computation, and testing data into their digital engineering workflows. Regulatory and certification standards, compliance, computation, and testing may be referred to herein as "common validation and verification (V&V) products." In some implementations, the ecosystem's computing systems can 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 the authority that may be critical to the products the user is designing. In some implementations, users can upload digitized common V&V products to the ecosystem themselves. Including digitized common V&V products in the ecosystem can be particularly beneficial for completing complex system engineering projects where many regulatory requirements may need to be met using several different digital engineering tools. By integrating both digital engineering tools with digitized common V&V products, the entire product design and engineering process (or parts thereof) can be digitized, eliminating or reducing time-consuming and costly steps such as human review of regulatory standards to identify regulatory requirements, human determination of which digital engineering tools are needed, and human assessment of whether regulatory requirements are met.For example, a computing system in a digital engineering and certification ecosystem may be configured to process regulatory and / or certification data corresponding to a digitized common V&V product, as well as engineering-related data output received from one or more digital engineering tools, to automatically assess whether one or more specified regulatory and / or certification requirements are met in the common V&V product. The computing system can generate reports, which can be presented to the user in an easy-to-read format and may even include recommendations for improvements to the user's digital prototype of the product (e.g., to meet unsatisfied regulatory and / or certification requirements). Importantly, all of this can be done without physical testing, without requiring any physical manifestation of the manufactured product. As digital models and simulations continue to become increasingly high-fidelity, certification of products such as unmanned aerial vehicles or other aircraft can also be performed digitally, saving time, cost, and materials associated with the physical evaluation and certification of the product. Throughout this specification, unmanned aerial vehicles and other aircraft are referred to as exemplary products, but the ecosystem can be developed using digital engineering tools and / or can be readily used for the design, engineering, testing, and / or certification of any product or solution (e.g., automobiles, pharmaceuticals, medical devices, processes, etc.) subject to regulatory and / or certification requirements.

[0014] An interconnected digital engineering and certification ecosystem also has the advantage of providing a single computing system (which may be centralized or distributed) through which various types of data flow throughout the entire design, engineering, testing, and / or certification process. Furthermore, this unlocks collaborative computing techniques even when models or model-like files are maintained at the edge, such as on client devices. The security architecture provides zero-trust access to digital models on a one-off basis for individual models, and also provides higher security through machine learning and data analysis related to the security implementation of other models and model transactions in the digital engineering ecosystem. For example, data related to prototypes, common V&V products, the use of digital engineering tools to satisfy specific common V&V products, the success or failure of specific digital engineering models and simulations, and various iterations of product designs can all be configured to flow securely through the ecosystem's computing system (e.g., using zero-trust security) and corroborated by the ecosystem's computing system. In some implementations, this data may be tracked and stored. This stored data may be audited for various purposes (e.g., to prevent security breaches or to perform data quality control). The stored data can also be explored (for example, using a machine learning engine) to identify patterns within the data. For example, patterns in stored data can be used to determine which digital engineering tools are most useful to meet specific regulatory requirements after extensive use of the digital engineering and certification ecosystem by experts in the subject, to suggest adjustments to inputs or parameters to effectively run models and simulations, to perform sensitivity analyses for specific designs, and to design or partially design systems using machine learning and artificial intelligence.This could have the advantage of making the digital engineering and certification ecosystem increasingly user-friendly for non-experts in the subject, and accelerating the entire engineering and certification process, as it can be supported by computing systems throughout the entire design and engineering process based on data collected from more professional and / or experienced users.

[0015] An interconnected digital engineering and certification ecosystem may have the added benefit of enabling the development of a repository of previously evaluated designs and / or solutions related to one or more common V&V products that can be easily reused with minimal additional engineering effort. Such designs and / or solutions can be offered to users (e.g., both human and artificial intelligence users) for use as is or as a starting point for modification, thereby reducing redundant work and streamlining the design, engineering, testing, and certification processes. In some implementations, the repository may be searchable by users to identify previous designs and / or solutions generated by others. In some implementations, the repository (or specific elements within the repository) may also be specific to users with specific credentials (e.g., users associated with a particular company, team, technology field, etc.) to avoid disclosing confidential information while still facilitating effective collaboration. In some cases, user credentials may be used additionally or alternatively in an interconnected digital engineering and certification ecosystem for other purposes, such as coordinating the types of digital engineering tools (or functions within digital engineering tools) that users may access. For example, user credentials may correspond to the user's skill level and may be checked to ensure that the user is not overwhelmed by the capabilities of digital engineering tools that exceed their skill set.

[0016] An interconnected digital engineering and certification ecosystem can offer further advantages, such as enabling the sharing of high-value digital models, including digital engineering models, while continuing to protect the intellectual property contained within the models. Many recent technology development projects involve multiple stakeholders working together (e.g., customers, prime integrators, suppliers, etc.) and require access to each other's models, but with different access permissions to the data. This system allows for precise specification of which data within a model should be shared with each individual stakeholder, without exposing all data to all data stakeholders. This selective sharing of information enables measurement and tracking of which data is consumed by each stakeholder (e.g., sharing only the inputs and outputs of a hydrodynamic pressure model) and how much data is consumed (e.g., how many times the hydrodynamic model is run). This measurement and tracking enables new business models based on the creation of models and data that can be monitored and monetized. In some implementations, this measurement and tracking can extend beyond the initial sharing of data to measuring and / or tracking subsequent or derivative uses of the data by third parties not involved in the initial sharing agreement. For example, a prime contractor might share data with a first government agency, and that first government agency could freely share data with a second government agency, and the prime contractor might have the ability to allow / not allow this further sharing, track it, and potentially monetize it. Such an implementation has the advantage of enabling extremely granular capture and the traceability of model data.

[0017] Maintaining the security of assets within an interconnected digital engineering ecosystem (e.g., models, model inputs, model outputs, user information, and data flows throughout the interconnected digital engineering ecosystem) is crucial for avoiding legal liability and maintaining the trust of stakeholders who may interact with the interconnected digital engineering ecosystem (e.g., users, model providers, regulatory authorities, certification authorities, etc.). Therefore, this specification discloses various implementations of security architectures and security-related processes for interconnected digital engineering ecosystems that are particularly well-suited to the structure and purpose of interconnected digital engineering ecosystems compared to existing security solutions. These security architectures and security-related processes aim to protect digital models and their data in addition to conventional zero-trust security measures for users and computer networks. The zero-trust security architecture includes policies, embodiments, and exemplary implementations of a secure storage environment, restricted access to models, attribute-based access control, read-query versus write query handling, traceability and auditability, and a model trust policy.

[0018] In some implementations, the security architectures and security-related processes described herein may have the advantage of implementing zero trust not only for users and networks within an interconnected digital engineering ecosystem, but also for the models themselves. In other words, the security architectures and security-related processes can ensure that (i) with respect to certain types of data, the correct authenticated user can access the correct authenticated model (and only the correct authenticated parts of the model); (ii) that the model is authentic because read and write access must be explicitly permitted; and (iii) that complex computations involving multiple models can be performed securely because access must be explicitly permitted for each step at the user, network, model, and model splice levels.

[0019] The security architectures and security-related processes described herein may also have the benefits of least privilege. In some implementations, the security architectures and security-related processes can extend the traditional least privilege implementation, which grants the least amount of access, to include extensions such as the least amount of data existing within the digital engineering platform itself, since the model remains in the customer's (e.g., model owner or model developer) own storage. This reduces the potential infringement of intellectual property, reduces the amount of legal processes required to share a model (e.g., sharing parties signing NDAs), and, when used in the security architectures described throughout this specification, allows the model to evaluate integration without leaving each customer's environment.

[0020] The security architectures and security-related processes described herein may also offer advantages in traceability, auditability, and model integrity. In some examples, endpoint transactions may be logged to allow for comprehensive traceability of all actions on models connected via the digital engineering ecosystem. Furthermore, the output from authorized actions generates an updated model, and the hash of the updated model is stored in an endpoint transaction database, which can be implemented in various embodiments, including secure databases, distributed databases, or ledgers, to name a few. This ensures the integrity of the model used in further actions without requiring the customer (e.g., a model owner or model developer) to entrust their complete model to the digital engineering platform.

[0021] In one general embodiment, the method is performed by a server. The method includes the steps of: receiving a request from a user device by the digital platform to access a stored digital engineering model; extracting data from the received request by the digital platform to identify the stored digital engineering model that the user intends to access; retrieving the location of the stored digital engineering model by the digital platform based on the data extracted from the request; providing the request to the location of the stored digital engineering model by the digital platform; receiving a request to access the stored digital engineering model by a digital agent at the location of the stored digital engineering model; determining by the digital agent that the request is authenticated to access the stored digital engineering model; and the request is stored in the digital engineering The process includes the steps of: determining the type of request to access a stored digital engineering model by a digital agent in response to a decision that the user is authenticated to access a ring model; generating a copy of the stored digital engineering model by a digital agent in response to a decision that the type of request to access the stored digital engineering model is for updating the stored digital engineering model; performing actions on the copy of the digital engineering model that are relevant to the type of request by a digital agent; providing the revised copy of the digital engineering model to a digital platform by a digital agent; and providing the revised copy of the digital engineering model to the user interface of a user device by the digital platform for user review.

[0022] Other embodiments of the present disclosure, and others thereof, include corresponding systems, devices, and computer programs configured to perform actions of methods encoded on computer storage devices. One or more computer systems may be configured in such a way by software, firmware, hardware, or combinations thereof installed in the system to cause the system to perform actions during operation. One or more computer programs may be configured in such a way by having instructions that cause a device to perform actions when executed by a data processing device.

[0023] The above and other embodiments can each optionally include one or more of the following features, either alone or in combination. For example, one embodiment includes all of the following features in combination.

[0024] In some implementations, the method comprises steps of storing, by a digital agent, one or more digital engineering tools in a tool database, wherein the one or more digital engineering tools include model-based system 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, and storing one or more digital engineering models, wherein the one or more digital engineering models include simulation engines, requirement models, electronics models, test plan models, cost models, schedule models, software models, supply chain models, manufacturing models, cybersecurity models, multi-attribute trade space tools, and mission effect models.

[0025] In some implementations, the step of determining the type of request to access the stored digital engineering model includes at least one of reading data from the stored digital engineering model or writing data to the stored digital engineering model.

[0026] In some implementations, the method includes the steps of the digital platform using the user device to obtain one or more credentials of the user before accessing the stored digital engineering model, and determining based on the one or more obtained credentials that the user is eligible to access the stored digital engineering model.

[0027] In some implementations, the digital platform and the digital agent communicate bidirectionally through one or more firewalls.

[0028] In some implementations, the method includes the steps of, in response to a determination that the type of request to access the stored digital engineering model is for reading data from the stored digital engineering model, the digital agent retrieving a splicer that enables access to one or more functions of the stored digital model, the digital agent providing the retrieved splicer to the digital platform, and the digital platform providing the retrieved splicer of the stored digital model to the user interface of the user device for the user's review.

[0029] In some implementations, the retrieved splicer is configured to restrict user access to a subset of the functions of the stored digital engineering model.

[0030] In some implementations, the extracted splicer is configured to redact a portion of the stored digital engineering model.

[0031] In some implementations, the extracted splicer is configured to protect a subset of the functionality of the digital engineering model stored on the user device.

[0032] In some implementations, the step of performing an action related to the type of request on a copy of the digital engineering model includes performing the action related to the type of request on a copy of the digital engineering model without modifying the stored digital engineering model.

[0033] In one general embodiment, the method is performed by a server. The method includes: receiving a user request by a digital platform via a user device to access one or more digital models; determining by the digital platform whether the user of the user device is authorized to access one or more digital models; and, in response to the determination that the user is authorized to access one or more digital models, generating a transaction request to send to the location of one or more digital models, wherein the transaction request includes data that identifies one or more actions to be performed using one or more digital models; sending the generated transaction request to the location of one or more digital models by the digital platform to cause the execution of one or more actions using one or more digital models; receiving by the digital platform data representing the results of one or more actions performed using one or more digital models; providing the user interface of the user device with data representing the results of one or more actions performed using one or more digital models; and auditing by the digital platform the data related to the transaction request and the data representing the results of one or more actions performed using the digital models.

[0034] Other embodiments of this disclosure, including other aspects thereof, include corresponding systems, devices, and computer programs configured to perform coded actions on a computer storage device. One or more computer systems may be configured in this way by software, firmware, hardware, or a combination thereof installed on the system that causes the system to perform actions during operation. One or more computer programs may be configured in this way by having instructions that cause a device to perform actions when executed by a data processing device.

[0035] The other embodiments described above may optionally include one or more of the following features individually or in combination. For example, one embodiment may include all of the following features in combination.

[0036] In some implementations, the step of sending a generated transaction request to the location of one or more digital models by the digital platform includes sending the generated transaction request to the cloud network by the digital platform, which triggers the execution of one or more actions using one or more digital models.

[0037] In some implementations, the step of sending a generated transaction request by the digital platform to the location of one or more digital models includes sending the generated transaction request by the digital platform to a digital agent, causing the digital agent to perform one or more actions using one or more digital models.

[0038] In some implementations, the method includes the steps of: using a digital agent to store one or more digital tools in a tool database, wherein one or more digital tools include model-based systems engineering (MBSE) tools, augmented reality (AR) tools, computer-aided design (CAD) tools, data analysis tools, modeling and simulation (M&S) tools, and product lifecycle management (PLM) tools; and storing one or more digital models, wherein one or more digital models include a simulation engine, requirements model, electronics model, test plan model, cost model, schedule model, software model, supply chain model, manufacturing model, cybersecurity model, multi-attribute trade space tool, and mission effectiveness model.

[0039] In some implementations, the digital platform and digital agent communicate bidirectionally through one or more firewalls.

[0040] In some implementations, sending a generated transaction request to cause a digital agent to perform one or more actions on one or more digital models includes sending a generated transaction request to cause the digital agent to copy one or more digital models and then perform write actions on the copied versions of one or more digital models without modifying the original versions of the digital models.

[0041] In some implementations, one or more actions performed using one or more digital models include at least one of the following: reading data from one or more digital models, writing data to one or more digital models, accessing one or more digital artifacts from one or more digital models, or accessing one or more digital models.

[0042] In some implementations, the step of determining whether a user is authorized to access one or more digital models includes the digital platform obtaining one or more user credentials using the user device before receiving a user request to access one or more digital models, and determining, based on the one or more obtained credentials and permission models, that the user is authenticated to access the digital platform.

[0043] In some implementations, the method includes the steps of: determining one or more types of operations to be performed by a digital platform on one or more digital models; sending generated transaction requests to the locations of one or more digital models in response to the determination of the types of operations to be performed on one or more digital models; receiving splicers from the digital platform that enable access to one or more functions of one or more digital models; and providing the received splicers to the user interface of a user device for user interaction to one or more functions of one or more digital models.

[0044] In some implementations, the received splicer is configured to restrict user access to a subset of the functionality of one or more digital models.

[0045] In some implementations, the received splicer is configured to edit parts of one or more digital models.

[0046] In some implementations, the received splicer is configured to protect a subset of the functionality of one or more digital models on the user device.

[0047] In some implementations, the method includes the steps of: extracting data from an received user request that the digital platform identifies one or more digital models that the user intends to access; and retrieving the location of one or more digital models based on the data extracted from the received user request.

[0048] In some implementations, the method includes the step of determining whether a user is authorized to access the digital platform before the digital platform receives a user request to access one or more digital models.

[0049] In some implementations, the step of providing data representing the results of one or more operations performed on one or more digital models includes providing, by a digital platform, at least one of one or more digital models, copies of one or more digital models, or wrappers to one or more digital models to the user interface of a user device for the user to review.

[0050] In some implementations, the step of auditing data further includes the digital platform storing data related to transaction requests and data representing the results of one or more actions performed using the digital model, and the digital platform auditing the stored data with respect to at least one of the following: a security breach, data quality control, or improvement of one or more actions performed using the digital model.

[0051] Details of one or more embodiments of the subject matter of this specification are described in the accompanying drawings and the following description. Other features, aspects, and advantages of the subject matter will become apparent from the description, drawings, and claims. [Brief explanation of the drawing]

[0052] [Figure 1] This figure illustrates an exemplary interconnected digital engineering and certification ecosystem, as well as digitally certified products. [Figure 2A] This flowchart illustrates an exemplary workflow, including an interconnected digital engineering and certification ecosystem. [Figure 2B] This flowchart illustrates an exemplary workflow, including an interconnected digital engineering and certification ecosystem. [Figure 3] This figure shows a series of exemplary displays shown on the user device, corresponding to the exemplary workflows in Figures 2A and 2B. [Figure 4] This flowchart illustrates an exemplary product design process using an interconnected digital engineering and certification ecosystem. [Figure 5] This diagram illustrates how interconnected digital engineering and certification ecosystems can be monetized. [Figure 6] This flowchart illustrates the process for product development, executed by computing systems within an interconnected digital engineering and certification ecosystem. [Figure 7] This figure illustrates an exemplary zero-trust embodiment in which the model remains within the customer environment or in secure storage that is unaffiliated with any single customer. [Figure 8] This diagram shows a sequence of actions to request a customer's access to a digital model within a secure computing environment. [Figure 9] This figure shows an implementation example of security where the user request is a read query. [Figure 10] This diagram shows an implementation example of security where the user request is a write query. [Figure 11] This flowchart illustrates the security implementation steps for sharing digital models. [Figure 12] This flowchart illustrates the security implementation steps for sharing edited portions of a digital model. [Figure 13] This flowchart illustrates the sequence of steps taken when a user interacts with a digital model, where specific actions occur either within the digital engineering ecosystem, the customer computing environment, or the model storage environment. [Figure 14] This flowchart illustrates the sequence of steps taken when a user interacts with a digital model, where specific actions occur either within the digital engineering ecosystem, the customer computing environment, or the model storage environment. [Figure 15-1] This diagram illustrates a zero-trust flowchart for accessing a model, where the model is hosted in secure storage that is not linked to any specific customer or user. [Figure 15-2] This diagram illustrates a zero-trust flowchart for accessing a model, where the model is hosted in secure storage that is not linked to any specific customer or user. [Figure 16] This diagram illustrates the implementation of security measures that extend to accessing and coordinating with multiple models in a computing environment. [Figure 17] This figure shows an example of a computing environment. [Figure 18-1] This figure shows an exemplary architecture of an interconnected digital engineering and certification ecosystem. [Figure 18-2] This figure shows an exemplary architecture of an interconnected digital engineering and certification ecosystem. [Modes for carrying out the invention]

[0053] This disclosure describes an interconnected digital engineering and certification ecosystem that can enable new capabilities and improve processes for digital product development, including digital design, digital engineering, digital testing, and digital certification of products. For the purposes of this disclosure, the terms “design” and “engineer” are used substantially synonymously and are generally defined to encompass the process of intelligently developing a product to solve a particular problem (e.g., to improve performance, enhance aesthetic appeal, meet one or more regulatory requirements, etc.).

[0054] Figure 1 shows an exemplary interconnected digital engineering and certification ecosystem 100 and examples of digitally certified products 112A–112C (collectively referred to as digitally certified products 112). For example, in some implementations, digitally certified product 112A may be an unmanned aerial vehicle (UAV) or other aircraft, digitally certified product 112B may be a pharmaceutical or other chemical or biological compound, and digitally certified product 112C may be a process, such as a manufacturing process. Generally, digitally certified products 112 may include any product, process, or solution that can be developed (partially or entirely) using digital engineering tools (e.g., digital engineering tool 102). In some implementations, digitally certified products 112 may not be limited to physical products and may also include non-physical products (e.g., processes, software, etc.). While physical and physically interacting systems often require multiple digital engineering tools simply for M&S needs to assess compliance with common V&V products, many complex non-physical systems may also require multiple digital engineering tools for product development, testing, and / or certification. With this in mind, various other possibilities regarding digitally certified products will be recognized by those skilled in the art.

[0055] A digitally certified product 112 may be designed and / or certified using an interconnected digital engineering and certification ecosystem 100. The interconnected digital engineering and certification ecosystem 100 may include user devices 106A or API 106B (or other similar machine-to-machine communication interfaces) operated by users (e.g., human users 104A of varying skill levels, or artificial users 104B such as algorithms, artificial intelligence, or other software), and a computing system 108 connected to (and / or including) a data storage unit 118, a machine learning engine 120, and an application and service layer 122. For the purposes of clarity, all users selected from various potential human users 104A or artificial users 104B are simply referred to herein as user 104. In some implementations, the computing system 108 may be a centralized computing system, while in other implementations, the computing system 108 may be a distributed computing system. In some cases, user 104 can be considered part of ecosystem 100, while in other embodiments, user 104 can be considered separate from ecosystem 100.Ecosystem 100 includes one or more digital engineering tools 102 (e.g., data analysis tools 102A, CAD and finite element analysis tools 102B, simulation tools 102C, pharmaceutical M&S tools 102D-102E, manufacturing M&S tools 102F-102G, etc.) and common V&V products 110 (e.g., regulatory standards 110A-110F related to UAV development and certification, medical standards 110G [e.g., CE marking (Europe), FCC Declaration of Conformity (USA), IECEE CB scheme (Europe, North America, Asia and parts of Australia), CDSCO (India), FDA (USA), etc.], medical certification regulations 110H [e.g., ISO 13485, ISO 14971, ISO 9001, ISO 62304, ISO 10993, ISO 15223, ISO 11135, ISO 11137, ISO This further includes repositories of manufacturing standards such as 11607, IEC 60601, etc., manufacturing standards 110I [e.g., ISO 9001, ISO 9013, ISO 10204, EN 1090, ISO 14004, etc.], and manufacturing certification regulations 110J [e.g., General Certification of Conformity (GCC), etc.].

[0056] The computing system 108 of ecosystem 100 is centrally located within the architecture of ecosystem 100 and is configured to communicate with user devices 106A or API 106B (e.g., APIs associated with artificial users 104B), digital engineering tools 102 (e.g., via application programming interfaces [APIs] / software development kits [SDKs] 114), and the repository of common V&V products 110 (e.g., via API / SDK 116) (e.g., to receive data from them and send data to them). For example, computing system 108 may be configured to communicate with user devices 106A and / or API 106B to send or receive data corresponding to design prototypes, information about users (e.g., user credentials), engineering-related inputs / outputs associated with digital engineering tools 102, digitized common V&V products, product design evaluations, user instructions (e.g., search requests, data processing instructions, etc.), and various other things. The computing system 108 may also be configured to communicate with one or more digital engineering tools 102 to transmit engineering-related inputs for performing analyses, digital models, such as digital engineering models, simulations, and tests, and to receive engineering-related outputs related to the results. The computing system 108 may also be configured to communicate with the repository of common V&V products 110 to retrieve data corresponding to one or more digitized common V&V products 110 and / or upload new common V&V products (e.g., new common V&V products received from user 104) to the repository of common V&V products 110. All communications may be transmitted and backed up securely, for example, using methods that rely on zero-trust security.

[0057] In some implementations, computing system 108 can employ zero-trust security with respect to various components within the digital engineering and authentication ecosystem. In particular, computing system 108 can employ zero-trust security under various industries where computing system 108 can be utilized. For example, these industries may include the automotive, aerospace, and medical device industries. Computer system 108 may include secure storage of various models in a customer environment (for example, an environment owned, accessible, or operated by a customer, such as a model developer or owner) or in a secure storage environment from a digital engineering platform. Computer system 108 can provide restricted access to models through attribute-based access control, read-for-write request handling, traceability and auditability through digitally signed endpoint transactions, and model credibility policies that assess model truth and user credibility. Aspects of zero-trust security related to computing system 108 are further described below.

[0058] In some implementations, computing system 108 can utilize security architecture policies to adopt zero-trust security features. Security architecture policies may include, for example, model storage policies, model access policies, data restriction policies, traceability and auditability policies, and authenticity policies. In some cases, computing system 108 may employ model storage policies for zero-trust purposes. Model storage policies can ensure the secure storage of models within the customer environment or in a secure storage environment separate from the digital engineering platform. Furthermore, models may be linked to the platform through private model storage. By implementing model storage policies, computing system 108 can ensure the confidentiality and integrity of the models themselves and the data of those models.

[0059] In some implementations, computing system 108 may employ model access policies for zero-trust purposes. Model access policies can restrict access to a specific subset of API functions by model wrappers or model splicers. For example, model wrappers and model wrapping may be used interchangeably with model splicers and model splicing. Restricted access may be based, for example, on the user's authentication level. Furthermore, model access policies may enable model and user authentication from various endpoints. In some cases, a customer (e.g., model owner or model developer) may provide additional access control policies that may be enforced at various endpoints. For example, additional access control policies may include read access to and write access to the model. In some examples, model and user authentication may be achieved through attribute-based access control. To enhance the overall traceability and auditability of the model, as will be further discussed below, the model may be watermarked (e.g., in digitally signed endpoint transactions).

[0060] In some implementations, computing system 108 may employ data restriction policies for zero-trust policies. These data restriction policies allow and permit customers to set policies regarding the handling of data in their respective models. In this implementation, customers can determine how their digital models should be protected. For example, customers may enforce policies that include data restrictions such as encryption, security controls, and zero-knowledge techniques. Furthermore, customers may configure a digital engineering ecosystem to provide a consensus mechanism for verifying transactions for open-access storage models and validating the output from the models. The consensus mechanism may allow a group of nodes containing different digital engineering tools for evaluating or validating a particular digital model or multiple digital models within open-access storage to agree on the output from a particular model. The consensus mechanism may include methods such as Proof of Stake (PoS) or Proof of Reputation (PoR). These consensus mechanisms can ensure that all nodes in a network of open-access storage digital engineering models have the same view of the data in a particular model, even if there are faulty or malicious nodes. For example, the PoR method may include a blockchain consensus mechanism that relies on the reputation of participants to maintain network security. The PoS method may include a consensus mechanism for blockchain networks where holders of cryptocurrency can verify the validity of block transactions through staking transactions.

[0061] In some implementations, computing system 108 may employ traceability and auditability policies for zero-trust purposes. These policies can ensure that recorded transactions at endpoints are in a standard format within a secure database, on a cloud network, on a blockchain network, or any combination of the aforementioned networks. Furthermore, computing system 108 can utilize various data analysis techniques to support threat detection, warning, threat mitigation, and threat debugging. Additionally, traceability and auditability policies can help computing system 108 meet specific standards, such as those established by standardization bodies like NIST, or various customer needs or criteria.

[0062] In some implementations, computing system 108 may employ an authenticity policy for zero-trust purposes. The authenticity policy ensures that the correct or accurate authenticated user can access the correct authenticated model attributes. The correct authenticated model attributes may include models from which the user is authenticated to access the authenticated model and to perform updates on the authenticated model. The authenticity policy ensures that the correct authenticated user can access the correct authenticated model attributes by addressing (i) user identity, (ii) continuity, and (iii) accord issues in order to assess model authenticity and user trustworthiness. In some examples, computing system 108 may employ an authenticity policy to help ensure the validity and trustworthiness of the model, along with the validity and trustworthiness of the data used by the model.

[0063] In some implementations, the authenticity policy addresses user identity by ensuring that the correct authenticated user can access the model and that the correct authenticated user can access specific data from the correct authenticated model. The authenticity policy ensures that the user accessing the authenticated model is a trusted user. Furthermore, continuity is addressed by evaluating user trustworthiness within a digital engineering platform, such as the digital engineering platform of computing system 108. In addition, the authenticity policy addresses accords by determining how model truthfulness should be evaluated. In particular, model truthfulness may be addressed when the model owner possesses the ground truth, or when the model owner does not possess the ground truth of the model data.

[0064] The computing system 108 can process and / or store data it receives, and in some implementations (for example, using storage 118), it can access a machine learning engine 120 and / or an application and service layer 122 (either included as part of the computing system 108 or located outside of the computing system 108) to identify useful insights based on the data, as further described herein. The centralized placement of the computing system 108 within the architecture of the ecosystem 100 has many advantages, including reducing the technical complexity of integrating various digital engineering tools 102, enhancing the user 104's product development experience, intelligently linking common V&V products (e.g., criteria 110A-110F) to the digital engineering tools 102 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 100 throughout the entire product development process. In some implementations, data flowing through (and potentially stored by) computing system 108 can also be auditable for purposes such as preventing security breaches and performing data quality control.

[0065] Referring to one specific example shown in Figure 1, user 104 can manufacture a digitally certified UAV 112B using the digital engineering and certification ecosystem 100. For example, user 104 may be primarily interested in certifying the UAV as meeting the requirements of a specific regulatory standard 110E (e.g., "MIL-HDBK 516C 4.1.4 - Failure Conditions") regarding the failure condition of the UAV. In this use scenario, user 104 can develop a digital prototype of the UAV on user device 106A or using API 106B, and send the prototype data (e.g., as at least one of a CAD file, MBSE file, etc.) to computing system 108. Along with the prototype data, user 104 may transmit additional data via user device 106A, including indications of common V&V products (e.g., regulatory standard 110E) that user 104 is interested in certifying the product, user credential information for accessing one or more capabilities of computing system 108, and / or instructions for running one or more digital models, tests, and / or simulations using a subset of digital engineering tools 102.

[0066] Referring to another example shown in Figure 1, user 104 can use the digital engineering and certification ecosystem 100 to manufacture digitally certified pharmaceuticals, chemical compounds, or biological agents 112A. For example, user 104 may be primarily interested in certifying pharmaceuticals, chemical compounds, or biological agents 112A as meeting the requirements of specific medical standards 110G and medical certification regulations 110H. In this use scenario, user 104 can develop a digital prototype of the pharmaceutical, chemical compound, or biological agent on user device 106A or using API 106B, and send the prototype data (for example, as a molecular modeling file) to computing system 108. Along with the prototype data, user 104 may transmit additional data via user device 106A, including indications of common V&V products (e.g., medical standards 110G and medical certification regulations 110H) for which user 104 is interested in certifying the product, user credential information for accessing one or more capabilities of computing system 108, and / or instructions for running one or more digital models, tests, and / or simulations using a subset of digital engineering tools 102 (e.g., pharmaceutical M&S tools 102D-102E).

[0067] Referring to yet another specific example shown in Figure 1, user 104 can use the digital engineering and certification ecosystem 100 to manufacture a digitally certified manufacturing process 112C. For example, user 104 may be primarily interested in certifying the manufacturing process 112C as meeting the requirements of a specific manufacturing standard 110I and manufacturing certification regulation 110J. In this use case, user 104 can develop a digital prototype of the manufacturing process on user device 106A or using API 106B and send the prototype data to computing system 108. Along with the prototype data, user 104 may transmit additional data via user device 106A, including indications of common V&V products (e.g., manufacturing standard 110I and manufacturing certification regulation 110J) that user 104 is interested in authenticating the process, user credential information for accessing one or more capabilities of computing system 108, and / or instructions for running one or more digital engineering models, tests, and / or simulations using a subset of digital engineering tools 102 (e.g., manufacturing M&S tools 102F-102G).

[0068] In any of the above examples, the computing system 108 can receive data transmitted from the user device 106A and / or API 106B, process the data, and evaluate whether the common V&V products of interest (e.g., regulatory standard 110E, medical standard 110G, medical certification regulation 110H, manufacturing standard 110I, manufacturing certification regulation 110J, etc.) are met by the user's digital prototype. For example, this may include communicating with a repository of common V&V products 110 (via API / SDK 116) to retrieve relevant common V&V products of interest, and processing regulatory and / or certification data related to the common V&V products to identify one or more requirements for a UAV prototype, pharmaceuticals, chemical compounds, or biological drug prototype, manufacturing process prototype, etc. In some implementations, the repository for common V&V product 110 may be hosted by a regulatory and / or certification authority (or another third party), and retrieving regulatory and / or certification data may involve using API / SDK 116 to interface with one or more data resources maintained by the regulatory and / or certification authority (or another third party). In some implementations, regulatory and / or certification data may be provided directly by user 104 via user device 106A and / or API 106B (for example, together with prototype data).

[0069] Evaluating whether a common V&V product of interest (e.g., regulatory standard 110E, medical standard 110G, medical certification regulation 110H, manufacturing standard 110I, manufacturing certification regulation 110J, etc.) is met by the user's digital prototype may also involve processing prototype data received from the user device 106A or API 106B to determine whether one or more identified requirements are actually met. In some implementations, the computing system 108 may include one or more plug-ins, local applications, etc., for direct processing of the prototype data within the computing system 108. In some implementations, the computing system may simply preprocess the received prototype data (e.g., to derive inputs for the digital engineering tool 102) and then send instructions and / or input data to a subset of the digital engineering tool 102 via API / SDK 114 for further processing.

[0070] Not all digital engineering tools 102 are necessarily required to meet specific regulatory and / or certification standards. Therefore, in the example of a UAV given in Figure 1, the computing system 108 may determine that only data analysis tool 102A and finite element analysis tool 102B are required to meet regulatory standard 110E regarding failure conditions. In the example of a drug, chemical compound, or biological agent given in Figure 1, the computing system 108 may determine that only drug M&S tools 102D-102E are required to meet medical standard 110G and medical certification regulation 110H. In the example of a manufacturing process given in Figure 1, the computing system 108 may determine that only manufacturing M&S tools 102F-102G are required to meet manufacturing standard 110I and manufacturing certification regulation 110J. In other implementations, user 104 may, provided that user 104 is a qualified subject matter expert, identify specific subsets of digital engineering tools 102B that should be used to meet common V&V products of interest. In other implementations, user 104 may input several proposed digital engineering tools 102 into computing system 108 to satisfy common V&V products of interest, and computing system 108 may recommend a modified subset of digital engineering tools 102 to user 104 for final approval, provided that user 104 is a qualified subject matter expert. After the subset of digital engineering tools 102 has been identified, computing system 108 may send instructions and / or input data to the identified subset of digital engineering tools 102 to run one or more digital models, tests, and / or simulations. The results of running these models, tests, and / or simulations (or "engineering-related data output") may be sent back and received by computing system 108.

[0071] In some implementations, user 104 may input a digital engineering tool (e.g., digital engineering tool 102F) required to satisfy common V&V product 110I, and computing system 108 may determine that another digital engineering tool (e.g., digital engineering tool 102G) is also required to satisfy common V&V product 110I. The computing system may then send instructions and / or input data to both digital engineering tools (e.g., digital engineering tools 102F and 102G), and the outputs of these digital engineering tools may be transmitted and received in computing system 108. In some cases, input data sent to one of the digital engineering tools (e.g., digital engineering tool 102G) may be derived (e.g., by computing system 108) from the output of another digital engineering tool (e.g., digital engineering tool 102F).

[0072] After receiving engineering-related data output from the digital engineering tool 102, the computing system 108 can process the received engineering-related data output to evaluate whether the requirements identified in the common V&V product of interest (e.g., regulatory standard 110E, medical standard 110G, medical certification regulation 110H, manufacturing standard 110I, manufacturing certification regulation 110J, etc.) are met. In some implementations, the computing system 108 can generate a report summarizing the evaluation results and send the report to the user device 106A or API 106B for review by the user 104. If all requirements are met, the prototype can be certified, resulting in a digitally certified product 112 (e.g., digitally certified pharmaceutical, chemical compound, or biological agent 112A, digitally certified UAV 112B, digitally certified manufacturing process 112C, etc.). However, if some regulatory requirements are not met, additional steps may need to be taken by the user 104 to certify the product prototype. In some cases, a prototype may be partially certified if some regulatory requirements are not met. In some implementations, reports sent to the user may include recommendations regarding these additional steps (e.g., suggesting one or more design changes, suggesting replacing one or more components with previously designed solutions, suggesting 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 102, the computing system 108 may provide user 104 with a report recommending partial certification, compliance, or fulfillment of a subset 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 104 is described in more detail below.

[0073] In response to reviewing the report, user 104 can make design changes to the digital prototype locally and / or send one or more instructions to computing system 108 via user device 106A or API 106B. These instructions may include, for example, instructions to computing system 108 to re-evaluate the updated prototype design, use one or more different digital engineering tools 102 for the evaluation process, and / or modify the inputs to the digital engineering tools 102. Furthermore, computing system 108 can receive the user's instructions, perform one or more additional data operations in accordance with these instructions, and provide user 104 with an updated report. Through this iterative process, user 104 can leverage the interconnected digital engineering and certification ecosystem 100 to design prototypes (e.g., UAV prototypes, pharmaceutical prototypes, manufacturing process prototypes, etc.) and ultimately certify them with respect to common V&V products of interest (e.g., by providing certification compliance information). Importantly, since all of these steps are performed in the digital world (e.g., using digital prototypes, digital models / tests / simulations, and digital certifications), significant time, cost, and material savings can be achieved compared to processes involving physical prototyping, evaluation, and / or certification, such as similar UAVs, pharmaceuticals, and manufacturing processes. If the requirements related to the common V&V product are partially met or exceed the collective capabilities of the digital engineering tools 102, the computing system 108 may provide user 104 with a report recommending partial certification, compliance, or fulfillment of a subset of the common V&V product (e.g., digital certification of a subsystem or subprocess of a prototype).

[0074] While the above example focuses on the use of the interconnected digital engineering and certification ecosystem 100 by a single user, further benefits of the ecosystem 100 can be realized through repeated use of the ecosystem 100 by multiple users. As mentioned above, the centralized positioning of the computing system 108 within the architecture of the ecosystem 100 allows the computing system 108 to monitor and remember the various data flows through the ecosystem 100. Thus, as an increasing number of users utilize the ecosystem 100 for digital product development, the data associated with each use of the ecosystem 100 can be stored (for example, in storage 118) and analyzed to yield various insights, which can then be used to further automate the digital product development process and make it more navigable for non-experts.

[0075] In some implementations, user credentials for user 104 can indicate user 104's skill level and control the amount of automated assistance provided to the user. For example, a non-expert in the target group may only be allowed to use the ecosystem 100 to browse pre-built designs and / or solutions, use digital engineering tools 102 with specific default parameters, and / or follow a predetermined workflow, with automated assistance guiding user 104 through the product development process. A more skilled user, on the other hand, may still be provided with automated assistance, but may be given more opportunities to override the default or suggested workflows and settings.

[0076] In some implementations, the computing system 108 may host applications and services 122 that automate or partially automate expected or common interfaces and / or data exchanges, including components of common V&V products, expected or common data transmissions, including components of data transmissions, from users 104, expected or common interfaces and / or data exchanges, including components of interfaces, between various digital engineering tools 102, expected or common interfaces and / or data exchanges, including components of interfaces, with machine learning models implemented on the computing system 108 (e.g., models trained and / or implemented by the machine learning engine 120), and expected or common interfaces and / or data exchanges, between applications and services themselves (e.g., within the application and service layer 122).

[0077] In some implementations, data from multiple uses of ecosystem 100 (or a portion thereof) may be aggregated to develop a training dataset. This training dataset may then be used to train a machine learning model (for example, using a machine learning engine 120) to perform a variety of tasks, including identifying which of the digital engineering tools 102 should be used to satisfy a particular common V&V product, identifying specific models, tests, and / or simulations (including their inputs) to be performed using the digital engineering tools 102, identifying common V&V products that need to be considered with respect to a particular type of product, identifying one or more recommended actions that a user 104 should take in response to unsatisfied regulatory requirements, and estimating the sensitivity of a model / test / simulation to a particular input. The output of a trained machine learning model may be used to implement various features of an interconnected digital engineering and certification ecosystem 100, including automatically suggesting inputs (e.g., inputs to a digital engineering tool 102) based on previously inputs, predicting time and cost requirements for developing a product, predictively estimating the results of sensitivity analysis, and even suggesting design changes, original designs, or design alternatives (e.g., by assistive or generative AI) to a user's prototype to overcome one or more requirements (e.g., regulatory and / or certification requirements) associated with a common V&V product. In some implementations, given sufficient training data, the machine learning engine 120 may independently generate new designs, models, simulations, tests, and / or common V&V products based on data collected from multiple uses of the ecosystem 100.

[0078] In addition to storing usage data to enable the development of machine learning 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 100 (e.g., within storage 118) to enable users to search for and build upon the work of others. For example, previously designed components, systems, models, simulations, and / or other engineering representations thereof can be searched by user 104 and / or proposed to user 104 by computing system 108 to meet one or more requirements related to a common V&V product. Previously designed components, systems, models, simulations, and / or other engineering representations thereof can be used as is by user 104 or as a starting point for additional modifications. This store (repository) of previously designed components, systems, models, simulations, and / or other engineering representations thereof (whether they were ultimately certified or not) can be monetized to create a marketplace for digital products, which can be used to save time in the digital product development process, provide users with alternative design ideas, avoid redundant effort, and more. In some implementations, data corresponding to previous designs and / or solutions may only be stored if the user who developed the design and / or solution chooses to share the data. In some implementations, the repository of previous designs and / or solutions may be containerized for private use (e.g., to avoid the undesirable disclosure of extremely non-information) for private use within a single company, team, organization, or technology field.In some implementations, user credentials associated with user 104 can be checked by computing system 108 to determine which designs and / or solutions stored in the repository can be accessed by user 104. In some implementations, 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 license fee.

[0079] Referring here to Figures 2A and 2B, an example of an exemplary digital product development and certification workflow 200 that can be implemented using the integrated digital engineering and certification ecosystem 100 (shown in Figure 1) is provided. Although not intended to be restrictive, the workflow 200 is used to illustrate a descriptive and practical example of the kind of workflow made possible by the ecosystem 100 and its various features. In Figures 2A and 2B, the individual steps of the workflow 200 are grouped by elements of the ecosystem 100 that execute them (i.e., a user device 106A or API 106B operated by user 104, a computing system 108 connected to (and / or containing) storage 118, a machine learning engine 120, and an application and service layer 122, digital engineering tools 102, and a repository of common V&V products 110).

[0080] In step 202, user 104 can upload an MBSE file corresponding to the digital representation of the product (e.g., a UAV) from user device 106A or API 106B to computing system 108. In step 204, user 104 can also upload a CAD file corresponding to the digital representation of the product from user device 106 to computing system 108.

[0081] The computing system 108 can receive an MBSE file (206), process the MBSE file to extract weight requirements (208), and send the data to an MBSE tool (210). For example, the data sent to the MBSE tool may include updated weight data, and the computing system 108 can request the MBSE tool to update the MBSE file. The request may be made, for example, via API 114 shown in Figure 1.

[0082] Similarly, the computing system 108 can receive (212) a CAD file, process the CAD file to calculate (for example, the mass properties (214) of a digital prototype), and send the data to a CAD tool (216). For example, the data sent to the CAD tool may include identified weight problems, and the computing system 108 can request the CAD tool to update the CAD file with its identified weight problems (for example, by highlighting the problems identified within the CAD file). This request can also be made, for example, via the API / SDK 114 shown in Figure 1.

[0083] In step 218, the MBSE tool (for example, one of the digital engineering tools 102) can receive data sent from the computing system 108 to the MBSE tool. The MBSE tool can then update the weight data in the MBSE file (220) and export the updated MBSE file to the computing system 108 (222).

[0084] Similarly, in step 224, a CAD tool (for example, another of the digital engineering tools 102) can receive data sent to the CAD tool from the computing system 108. The CAD tool can then update the CAD file to highlight issues within the CAD file (226) and export the updated CAD file to the computing system 108 (228).

[0085] In step 230, the computing system 108 can receive the updated CAD files and MBSE files exported by the CAD tool and MBSE tool, respectively.

[0086] In step 232, the computing system 108 may send a request for data (e.g., regulatory and / or certification data) corresponding to one or more common V&V products (232). For example, the request may be sent via the API / SDK 116 shown in Figure 1 so that it is processed in a repository of common V&V products 110, which may be off-the-shelf and / or hosted by a certification authority or another third party, as described above. Step 232 is shown in the workflow 200 after the communication of the computing system 108 with the digital engineering tool 102 (e.g., steps 210, 216, 222, 228, and 230), but in some implementations, the computing system 108 may retrieve data corresponding to one or more common V&V products from the repository of common V&V products 110 before communication with the digital engineering tool 102. In the example shown in Figures 2A and 2B, the data requested in step 232 may correspond to “MIL HDBK 516c 5.5.2 (JSSG-2006)”—a regulatory standard that specifies the weight and center of gravity requirements for an aircraft to be certified as “airworthy.” The repository for common V&V product 110 receives a request for data corresponding to one or more common V&V products (236), transmits data corresponding to the computing system 108 (238), and the computing system 108 can then receive data corresponding to one or more common V&V products (e.g., regulatory and / or certification data) (240).

[0087] In step 242, the computing system 108 can process the updated CAD and MBSE files (received in step 230) and the data corresponding to one or more common V&V products (received in step 240) to identify and evaluate one or more certification requirements. For example, the computing system can automatically process the CAD and MBSE files to calculate the weight and center of gravity of the physical manifestation of the digital prototype. The computing device can then compare these to the aircraft weight and center of gravity requirements identified in the data corresponding to "MIL HDBK 516c 5.5.2 (JSSG-2006)".

[0088] In step 244, based on the computing system's evaluation of the requirements identified in the data corresponding to "MIL HDBK 516c 5.5.2 (JSSG-2006)", the computing system 108 may generate a report and send it to the user device 106A or API 106B. The report may summarize the evaluation results, including an indication of whether the identified requirements have been met. In some implementations, the report may also include one or more recommended actions for the user. The recommendations may be generated using the machine learning engine 120, for example, as previously described above in relation to Figure 1.

[0089] In step 246, the user device 106A or API 106B may receive a report, and user 104 may review the report. For example, the report may be presented on the display of user device 106A for review by human user 104A and / or received by API 106B for processing by artificial user 104B. Depending on the review of the report, user 104 may operate user device 106A or API 106B to update the prototype design and / or send data representing one or more user instructions to computing system 108 (248). As previously stated, such user instructions may include instructions to computing system 108 to re-evaluate the updated prototype design, use one or more different digital engineering tools 102 for the evaluation process, and / or modify the inputs to the digital engineering tools 102. In step 250, computing system 108 may receive one or more user instructions and perform one or more data operations in accordance with one or more user instructions. In this way, workflow 200 can enable iterative design of digital prototypes using an interconnected digital engineering and certification ecosystem 100 to design and certify products such as UAVs, pharmaceuticals, and manufacturing processes entirely within a digital world.

[0090] Figure 3 shows a series of exemplary displays 300 shown on user device 106A. In implementations including an artificial user 104B that interfaces with the computing system via API 106B, it should be noted that displays are not necessary, as the artificial user 104B can directly process the digital computer files received in API 106B without further visualization. The series of exemplary displays 300 may correspond to the exemplary workflow 200 described in relation to Figures 2A-2B. In this case as well, these displays are not intended to be restrictive, but merely to illustrate the kind of user experience that user 104 (and especially human user 104A) may encounter while using the interconnected digital engineering and certification ecosystem 100 for digital product development. The series of exemplary displays 300 described herein highlight the ease of use of the ecosystem 100 and the complexity avoided, which would require the user to interface separately with individual digital engineering tools and manually review complex common V&V products in order to evaluate whether a product prototype should be certified.

[0091] Display 302 shows a login screen that may be displayed on user device 106A. The login screen may prompt user 104 to enter user credentials (e.g., username and password) to access computing system 108 and the rest of the interconnected digital engineering and authentication ecosystem 100. User credentials associated with user 104 can perform various functions. For example, as mentioned above, user credentials can be associated with the user's skill level, which can control which functions of ecosystem 100 user 104 can access. In some implementations, user credentials can additionally or alternatively be associated with the user's affiliation (e.g., a specific company and / or organization), which can determine previously designed products and / or solutions that the user may search for and / or be offered by computing system 108. In general, user credentials can help ensure that user 104 can only access information within ecosystem 100 that user 104 is entitled to and / or authorized to access.

[0092] When user 104 logs in from user device 106A, user device 106A may be used to develop a digital prototype of a product. For example, display 304 shows a modeling screen that user 104 might see while developing a digital model of a UAV (for example, using a CAD tool). Once the prototype is developed, the user can upload prototype data, such as CAD files and / or MBSE files, to computing system 108 (for example, as in steps 202 and 204 of workflow 200). Thus, display 306 shows a screen that can prompt user 104 to upload MBSE files and CAD files to computing system 108.

[0093] When a user uploads MBSE and CAD files to the computing system 108, the computing system 108 can perform several steps (for example, steps 206, 207, 210, 212, 214, 216, 230, 232, 240, 242, and 244 of workflow 200) to evaluate the prototype with respect to one or more requirements identified within the common V&V product and generate a report summarizing the evaluation. In doing so, the computing system 108 may communicate with the digital engineering tools 102 and the repository of the common V&V product 110, which themselves can perform actions (for example, steps 218, 220, 222, 224, 226, 228, 236, and 238 of workflow 200) to facilitate the evaluation of the prototype. These steps may take some time to complete (for example, ranging from a few seconds to several hours), during which time display 308 may be shown on the screen of the user device 106A, providing information about the current status of the prototype evaluation.

[0094] Once the prototype evaluation is complete (for example, in step 244 of workflow 200), the generated report may be sent from computing system 108 to user device 106A. Display 310 shows the screen of user device 106A presenting the report to user 104. The report may present information indicating whether one or more requirements identified within the common V&V product of interest have been met, and may present information about one or more issues that resulted in unsatisfied requirements (for example, a problematic component of the device). In some implementations, the information presented may also include more detailed data from the evaluation and / or proposed solutions to resolve one or more issues in order to meet the requirements. The easy-to-understand format of the report presented on display 310 can help user 104 understand why the prototype may not meet one or more requirements and can provide user 104 with immediately actionable suggestions for improving the digital prototype. Even in implementations that include an artificial user 104B (where screen display is not required), a concise or standardized report in the form of a digital computer file sent to API 106B can similarly help the artificial user 104B understand why the prototype may not meet one or more requirements, and can provide the artificial user 104B with readily actionable suggestions for improving the digital prototype.

[0095] Figure 4 depicts a flowchart 400 illustrating an exemplary product design process using an interconnected digital engineering and certification ecosystem 100. By translating elements and properties such as physical laws from the physical world 402 to the digital world 406 via transfer function models and tools 404, product development and certification can be made entirely (or nearly entirely or partially) within the ecosystem 100. It should be noted that the entire physical world may not be perfectly replicated at once, and in some cases, a very specific subset of the physical world may be digitally described by any number of models or simulations (for example, a model describing turbulent air between 200 knots and 600 knots, complemented by another model describing turbulent air between 500 knots and 800 knots), and that these models or simulations together constitute a sufficient representation of the physical world to enable certification of a particular system or product. An interconnected digital engineering and certification ecosystem (e.g., ecosystem 100) can enable the digital representation of the physical world to be built in a modular and complementary manner, without requiring coordination and with coherent incentives (e.g., protection of intellectual property, monetization of models or valuable digital representations), allowing each of these parts to be individually added by many different people and many different entities, enabling each model or simulation to connect with and build upon the others. For example, digital product development 408, digital product testing 410, and digital product certification 412 can all take place within ecosystem 100, entirely within the digital realm or “metaverse” to produce a finalized digital product design 414. Following this product design process, the finalized digital product design only needs to be translated into the physical world (e.g., by manufacturing 416) at the very end of the product design process to manufacture the final product 418 in the physical world.This is in stark contrast to current product development and certification workflows, which utilize digital engineering tools but often still require the physical manufacturing, testing, and certification of prototypes throughout the iterative product development, product testing, and product certification process. Compared to such workflows, the product design process enabled by an interconnected digital engineering and certification ecosystem can therefore result in significant savings in time, cost, materials, and environmental impact.

[0096] In Figure 5, the interconnected digital engineering and authentication ecosystem 100 provides various different opportunities for monetization (shown as blocks 500A-500D). In some implementations, the interaction between user 104 and computing system 108 may include monetization opportunity 500A. For example, user 104 may be charged for sending commands to computing system 108, and / or user 104 may be charged for downloading data (e.g., authentication reports) from computing system 108. The pricing can be subscription-based (e.g., charging a monthly or annual fee for using computing system 108), usage-based (e.g., charging user 104 based on the number of interactions with computing system 108, the amount of time spent interacting with computing system 108, etc.), or a hybrid (e.g., using a freemium model).

[0097] In some implementations, the interaction between the computing system 108 and the digital engineering tool 102 may include a monetization opportunity 500B. For example, a user 104 may be charged for sending data between the computing system 108 and / or the digital engineering tool 102. In some implementations, the fees paid by the user 104 may be split between the third-party provider of the digital engineering tool 102 and the operator of the computing system 108. In some implementations, the third-party providers of the digital engineering tool 102 themselves may pay a fee to the operator of the computing system 108 in order to include their digital engineering tools in the ecosystem 100. The user 104's fees can be subscription-based (e.g., a monthly or annual fee for accessing a specific digital engineering tool 102), usage-based (e.g., the user 104 is charged based on the amount of data transferred between the digital engineering tool 102 and the computing system 108, the amount of processing time required by the digital engineering tool 102, etc.), or a hybrid (e.g., using a freemium model).

[0098] In some implementations, the interaction between the computing system 108 and the repository of the common V&V product 110 may include a monetization opportunity 500C. For example, a user 104 may be charged for sending data between the computing system 108 and / or the repository of the common V&V product 110. In some implementations, the fees paid by user 104 may be split between the authority operating the repository of the common V&V product 110 and the operator of the computing system 108. The user 104's fees can be subscription-based (e.g., a monthly or annual fee for accessing the repository of the common V&V product 110), usage-based (e.g., user 104 is charged based on the amount of data transferred between the repository of the common V&V product 110 and the computing system 108, the number of common V&V products requested, etc.), or a hybrid (e.g., using a freemium model).

[0099] In some implementations, the final authentication of the digitally authenticated product 112 by the computing system 108 may also include a monetization opportunity 500D. For example, user 104 may be charged a fee for performing formal authentication of their product. Additionally or alternatively, user 104 may be charged a fee for downloading proof of authentication.

[0100] Referring now to Figure 18, an exemplary architecture of the Digital Engineering (DE) Platform 1800 (including an interconnected digital engineering and authentication ecosystem 100) is shown. The exemplary architecture of the Digital Engineering Platform 1800 is designed in accordance with zero-trust security principles and further designed to support scalability, as well as robust and resilient operation.

[0101] In one embodiment, the architecture of the digital engineering platform 1800 includes several components, namely a digital engineering (DE) platform enclave 1802, a cloud service 1804, and a customer environment 1810. The customer environment 1810 optionally includes a DE platform exclave 1816.

[0102] The DE Platform Enclave 1802 can serve as the starting point for services provided by Platform 1800. Enclave 1802 can be visualized as a central command hub responsible for managing and functioning operations. For example, Enclave 1802 can be implemented using the computer system 108 of the interconnected digital engineering and authentication ecosystem 100 described above. The DE Platform Enclave 1802 acts as a centralized command and control hub responsible for orchestrating and managing the operations of all platforms. Designed to integrate both a zero-trust security model and hyperscale capabilities, the DE Platform Enclave 1802 delivers a secure and scalable processing environment tailored to the individual customer needs. Zero-trust security features include, but are not limited to, rigorous access control, algorithmic fairness, and data isolation. Enclave 1802 also supports a machine learning engine for real-time analytics (e.g., machine learning engine 120), auto-scaling features for workload adaptability, and API-based interoperability with third-party services. Security and resource optimization are enhanced by multi-tenancy support, role-based access control, and data encryption both at rest and in transit. The Digital Engineering Platform Enclave 1802 may also include one or more of the features described below.

[0103] First, the Digital Engineering Platform Enclave 1802 can be designed in accordance with the principles of zero trust security. In particular, the DE Platform Enclave 1802 employs the zero trust principle to ensure that no implicit trust is assumed between any element, such as the digital model, platform agents, or individual users (e.g., users 104A, 104B) within the system, or their actions. The model is further reinforced by a strict access control mechanism that restricts even the management team (e.g., a team of individuals associated with the platform provider) to predetermined limited access to the Enclave's 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.

[0104] The DE platform enclave 1802 can also be designed to maintain isolation and independence. A key aspect of the enclave's architecture is its emphasis on fairness and isolation. Enclave 1802 enforces a strong isolation policy by not allowing cryptographic dependencies from external enclaves. Furthermore, the enclave's design allows for both single-tenant and multi-tenant configurations, further enhancing the isolation of data and processes between customers 1806 (e.g., users 104A, 104B). In addition, Enclave 1802 is designed with a decoupled resource set to minimize interdependencies, thereby increasing system efficiency and autonomy.

[0105] The DE platform enclave 1802 can be designed for scalability and adaptability. The enclave 1802 is engineered to be scalable and adaptable, and can effectively handle a variety of operating requirements. For example, the enclave 1802 can incorporate hyperscale-like characteristics in conjunction with zero-trust principles to enable scalable growth and effectively handle high-performance workloads.

[0106] The DE Platform Enclave 1802 can be further designed for workflow adaptability, supported by a rigorous access control mechanism. The DE Platform Enclave 1802 is designed to accommodate various customer workflows and DE models through its rigorous access control mechanism. This configurability allows for a modular approach to integrating different functions, from data ingestion to algorithm execution, without compromising a zero-trust security posture. The adaptability of Platform 1800 gives it high versatility for many use cases while ensuring stable performance and robust security.

[0107] The DE platform enclave 1802 can be further designed to enable analysis for robust platform operation. At the heart of the enclave's operational efficiency is a machine learning engine (e.g., machine learning engine 120) capable of performing real-time analysis. This improves decision-making and operational efficiency throughout platform 1800. An auto-scaling mechanism can also be included to enable dynamic resource allocation based on workload demands, further enhancing the platform's responsiveness and efficiency.

[0108] In an exemplary implementation, the DE platform enclave 1802 may include several components, as shown in Figure 18 and as will be described in further detail herein.

[0109] In the embodiment of the DE platform enclave 1802 shown in Figure 18, the DE platform enclave 1802 includes “monitoring services” and “telemetry services” as part of a “monitoring service cell.” These components focus on maintaining, tracking, and analyzing the performance of platform 1800 to ensure optimal service delivery, including advanced machine learning capabilities for real-time analysis.

[0110] In the embodiment of the DE platform enclave 1802 shown in Figure 18, the DE platform enclave 1802 also includes a "Static Assets Service Cell" that houses the user interface, SDK, command line interface (CLI), and documentation for platform 1800.

[0111] In the embodiment of the DE platform enclave 1802 shown in Figure 18, the DE platform enclave 1802 includes DE platform APIs (e.g., APIs 114, 116) and further includes an "API gateway service cell" that acts as an intermediary for requests between client applications (e.g., digital engineering tools 102, a repository of common V&V products 110, etc.) and platform services.

[0112] In the embodiment of the DE platform enclave 1802 shown in Figure 18, the DE platform enclave 1802 further includes a “search service cell.” This component facilitates the efficient retrieval of information from the DE platform 1800 and enhances the overall functionality of the DE platform 1800.

[0113] In the embodiment of the DE platform enclave 1802 shown in Figure 18, the DE platform enclave 1802 further includes a “logging service cell” and a “control plane service cell.” These components help record and manage operational events and the flow of information within platform 1800.

[0114] As shown in Figure 18, the architecture of the digital engineering platform 1800 also includes cloud services 1804, which include services that can modify the software for orchestrating the operation of the digital engineering platform, although they cannot interact with customer data. In an exemplary implementation, several cloud resources provide support and foundational services to the platform. For example, in the embodiment of the DE platform 1800 shown in Figure 18, cloud services 1804 include a “Customer IAM Service,” where “IAM” stands for “Identity and Access Management.” The Identity and Access Management Service ensures secure and controlled access to the platform 1800.

[0115] In the embodiment of the DE platform 1800 shown in Figure 18, the cloud service 1804 also includes a “testing service” which includes test tools for verifying the validity of the platform’s operation.

[0116] In the embodiment of the DE platform 1800 shown in Figure 18, the cloud service 1804 also includes an "orchestration service" for controlling and managing the lifecycle of containers on the platform 1800.

[0117] In the embodiment of the DE platform 1800 shown in Figure 18, the cloud service 1804 also includes an "Artifact service" and a "Version control and build service." These cloud services are crucial for maintaining the progress of projects, code, and instances within the system, while also managing artifacts generated during the product development process.

[0118] As shown in Figure 18, the architecture of the Digital Engineering Platform 1800 also includes a Customer Environment 1810 with an Authoritative Source of Truth 1812, Customer Tools 1814, and an optional DE Platform Exclav 1816. The Customer Environment 1810 is where customer data resides and is processed in a zero-trust manner by the Digital Engineering Platform 1800. As previously mentioned, the DE Platform Enclave 1802 provides a robust and scalable environment for securely handling critical workloads according to the customer's unique needs, with an emphasis on both zero-trust principles and hyperscale-like characteristics. In some examples, the DE Platform Exclav 1816 is located within the Customer Environment 1810 to support the customer's digital engineering tasks and operations.

[0119] When a customer 1806 (e.g., users 104A, 104B) intends to perform a digital engineering task using a digital engineering platform 1800 (e.g., an interconnected digital engineering and authentication ecosystem 100), typical operations include secure data ingestion and controlled data retrieval. Derived data generated through digital engineering operations, such as updated digital model files or revisions of digital model parameters, is stored only within the customer environment 1810, and the digital engineering platform 1800 may provide tools for accessing metadata of the derived data. An exemplary implementation may include secure data ingestion that leverages zero-trust principles to ensure that customer data is securely uploaded to the customer environment 1810 through a pre-validated secure tunnel, such as a Secure Sockets Layer (SSL) tunnel. This may enable direct, secure file transfers to designated cloud storage, such as an S3 bucket, within the customer environment 1810. An exemplary implementation may also include controlled data retrieval, where temporary, pre-authenticated URLs generated via a secure token-based mechanism are used for controlled data access, thereby minimizing the risk of malicious interaction. Exemplary embodiments may include immutable derived data, such as transformed data generated through operations like data extraction, while adhering to zero-trust security protocols, and securely stored within the customer environment 1810. Exemplary embodiments may also include a tokenization utility, a specialized digital engineering (DE) platform tool called a “tokenizer,” which is deployed within the customer environment 1810 for the secure management of derived metadata in accordance with zero-trust guidelines.

[0120] The customer environment 1810 interacts with other elements of the secure digital engineering (DE) platform 1800 and includes several features that handle data storage and secure interaction with the platform 1800. For example, one element of the customer environment 1810 is the “Trusted Authoritative Source” 1812, which is the main repository of customer data, ensuring data integrity and accuracy. Nested within this is the “Customer Bucket,” where data is securely stored with strict access control that restricts access to the data to authorized users or processes through pre-authenticated URL links. This setup ensures uncompromising data security within the customer environment 1810 while providing seamless interaction with other elements of the DE platform 1800.

[0121] The customer environment 1810 also includes additional software tools (e.g., customer tools 1814) that may be used based on specific customer requirements. For example, the "DE Tool Host" is a component that handles the data engineering applications necessary for working with customer data. The "DE Tool Host" includes the DET CLI (Digital Engineering Tools Command Line Interface), which enables user-friendly command-line operation of DE tools (e.g., Digital Engineering Tools 102). The "DE Platform Agent" ensures smooth communication and management between the customer environment 1810 and the elements of the DE Platform 1800. Furthermore, there may be another set of optional DE tools designed to support customer-specific data engineering workflows.

[0122] In some cases, an optional feature known as “DE Platform Exclave” 1816 may be used within the customer environment 1810 for enhanced security. Exclave 1816 operates within the customer's network, overseeing data processing and strictly adhering to zero-trust principles while providing hyperscale-like platform performance. Exclave 1816 includes a “DE Tool Host” that runs the DE tools and agents necessary for its operation.

[0123] Figure 6 shows an exemplary process 600 for product development. In some implementations, process 600 may be performed by a computing system (e.g., computing system 108) of an interconnected digital engineering and certification ecosystem (e.g., ecosystem 100).

[0124] The operation of process 600 includes receiving design and / or engineering data (D / E data) corresponding to a prototype representation of the product from a user device (602). For example, the user device may correspond to user device 106A or API 106B, and the D / E data may correspond to MBSE files, CAD files, and / or other digital files or information related to the digital prototype, as described above. In some implementations, the product may be a UAV or other type of aircraft, automobile, boat, submersible, industrial robot, spacecraft, satellite, structure, tool, physical device, mobile device, pharmaceutical, chemical product, or biological agent, manufacturing process, or any other complex system (either physical or non-physical) that may be evaluated against a common V&V product.

[0125] The operation of process 600 also includes sending one or more inputs derived from D / E data to one or more digital engineering tools for processing (604). For example, one or more digital engineering tools may correspond to the digital engineering tool 102 described above. In some implementations, at least a subset of one or more digital engineering tools may include model-based systems engineering (MBSE) tools, augmented reality (AR) tools, computer-aided design (CAD) tools, robotics simulation and programming tools, data analysis tools, modeling and simulation (M&S) tools, geographic information system (GIS) tools for spatial analysis, product lifecycle management (PLM) tools, Internet of Things (IoT) platforms, virtual and augmented reality design tools, human-machine interface (HMI) design tools, and simulation engines. Digital engineering models may include requirements models, electronics models, test planning models, cost models, scheduling models, software modeling, supply chain models, manufacturing models, cybersecurity models, multi-attribute trade space tools, finite element analysis models, computational fluid dynamics models, computational electromagnetism models, noise, vibration, and harshness (NVH) simulation models, control system design and simulation models, structural analysis and optimization models, power system analysis and simulation models, thermal analysis and simulation models, failure analysis and prediction models, digital twin models, artificial intelligence and machine learning models, environmental impact models, mission effect models, or other similar digital engineering tools that may be recognized as engineering design tools by those with the usual skills in the relevant field.

[0126] The operation of process 600 also includes receiving engineering-related data output from one or more digital engineering tools (606). For example, the engineering-related data output may correspond to the results of models, tests, and / or simulations performed by the data engineering tool 102, as described above.

[0127] The operation of process 600 also includes receiving data corresponding to one or more common V&V products associated with the product (608). For example, one or more common V&V products may be digitized regulatory and / or certification standards and may correspond to common V&V products 110A to 110J stored in the repository of common V&V product 110 described above. In some implementations, data corresponding to one or more common V&V products may be received from a user device (for example, by user upload). In some implementations, data corresponding to one or more common V&V products may be received from a regulatory and / or certification authority (for example, via a repository of common V&V products hosted or maintained by the regulatory and / or certification authority).

[0128] The operation of process 600 also includes identifying one or more requirements for a product based on data corresponding to one or more common V&V products (610). For example, one or more requirements may correspond to requirements that must be met in order to certify a product according to a particular common V&V product.

[0129] The operation of process 600 also includes determining whether one or more requirements have been met based on engineering-related data output and data corresponding to one or more common V&V products (612). In some implementations, instead of performing a binary decision, the operation of process 600 may include determining whether one or more requirements are likely to be met by the prototype representation of the product (for example, based on estimated probabilities). In some implementations, determining whether one or more requirements have been met (or are likely to be met) based on engineering-related data output may include determining whether one or more requirements have been met with or without human input.

[0130] The operation of process 600 is to present information on the user device corresponding to engineering-related data output and / or data corresponding to one or more common V&V products, including presenting (614) information that includes indications of whether one or more requirements have been met. In some implementations, the presented information may include indications of the probability that one or more requirements are met by the prototype representation of the product. For example, the information may be presented on the user device in the form of a report, as shown in display 310 of Figure 3 and as described above. In some implementations, the presented information may further include recommended actions that the user of the user device may take to meet one or more requirements. In such implementations, recommended actions may include suggestions to use a specific digital engineering tool from one or more digital engineering tools, suggestions to modify one or more inputs sent to one or more digital engineering tools, suggestions to modify one or more components of the prototype representation of the product, suggestions to replace one or more components of the prototype representation of the product with a previously designed solution, and / or suggestions for a completely or partially new design generated by the system (for example, using the machine learning engine 120).

[0131] The operation of the process includes presenting information on the user device that corresponds to engineering-related data output and / or data corresponding to one or more common V&V products, and then receiving a command from the user device, the command corresponding to one or more user interactions with the user device (616).

[0132] The operation of the process also includes performing one or more operations on the D / E data in response to receiving a command from a user device (618). In some implementations, performing one or more operations on the D / E data may include modifying the D / E data and / or deriving a modified input from the D / E data for transmission to one or more digital engineering tools.

[0133] Additional operations of process 600 may include: In some implementations, process 600 may include storing usage data in a storage device representing received data corresponding to one or more common V&V products, received D / E data, engineering-related data output from one or more digital engineering tools, indications of whether one or more requirements have been met (or are likely to be met), one or more user interactions with user devices, and / or one or more operations on D / E data. Process 600 may also include incorporating applications and services (e.g., application and service 122) that automate or partially automate the determination of whether one or more requirements have been met or partially met. Process 600 may further include incorporating at least a portion of the usage data into a training dataset and training a machine learning model on the training dataset. In some implementations, a machine learning model may be configured to receive as input information about another product designed by another user and to output suggestions for the other user to use one or more digital engineering tools, suggestions to modify one or more inputs sent to one or more digital engineering tools by another user, suggestions to modify one or more components of another prototype representation related to another user, and / or suggestions to replace one or more components of another prototype representation with a previously designed solution. In some implementations, process 600 may also include using stored usage data for one or more sensitivity analyses. In some implementations, process 600 may also include using stored usage data to improve the performance of applications and services (e.g., application and service 122).

[0134] In some implementations, additional actions of process 600 may include checking one or more user credentials before performing one or more operations on the D / E data, and determining, based on the credentials, whether the user is qualified or authorized to perform one or more operations on the D / E data.

[0135] An interconnected digital engineering and authentication ecosystem can be implemented using methods and techniques that employ zero-trust approaches in user interaction with the system. Furthermore, an interconnected digital engineering and authentication ecosystem can apply zero-trust techniques to computer networks in which users interact, and extend these zero-trust techniques to access and computation of data related to individual digital models, tools, or MBSE files used by users as part of the purpose of a V&V product.

[0136] In some examples, security architecture policies may include model storage policies, model access policies, attribute-based access control, read-query versus write query handling, traceability and auditability, and model credibility policies. Implementation details are outlined in the examples described throughout this specification. For example, this may include restricting model access to specific API functions, authenticating users and models at endpoints, allowing customers (e.g., model owners or model developers) to set additional access control policies, enforcing data restriction and encryption, logging endpoint transactions in a secure database, and incorporating watermarks for traceability and auditability. The purpose of implementing a security architecture is to ensure that the correct authenticated user can access the correct authenticated model, and to assess model authenticity and user credibility.

[0137] As shown in Figure 7, zero trust for models in digital engineering and authentication ecosystems can differ in terms of the location of model storage. In some implementations, models can remain within the customer environment and be associated with a specific customer. In other implementations, models are stored in secure, unconnected storage isolated from any single customer. This allows for more secure, centralized, and openly accessible storage of models, but also means there are no guarantees about the accuracy of a particular model, its location, its current state and historical history, or its performance and output.

[0138] In some implementations, the digital engineering and certification ecosystem 700 shown in Figure 7 may be employed by the computing system 108. Within the digital engineering and certification ecosystem 700, the computing system 108 can enforce model storage policies. In particular, model storage policies can ensure that digital models, such as digital engineering models, remain within the customer environment (for example, as shown in Case 1) or in a secure storage environment separate from the platform (for example, as shown in Case 2). More specifically, the model storage policy may include private model storage 708 linked to the digital engineering and certification ecosystem 700.

[0139] In some implementations, computing system 108 may enforce model access policies based on various criteria. In particular, computing system 108 may restrict access to model data to a specific subset of API functions through model wrappers. More specifically, computing system 108 may restrict access to model data by enabling user authentication at the endpoint with respect to model wrappers. User 702 may be authenticated at endpoint 704 (for example, a user device using attribute-based access control). These attribute-based access controls may include, for example, username, password, email, and security key. Furthermore, a customer (for example, a model owner) or user 702 attempting to access model data may provide additional model access control policies enforced at endpoint device 704. These control policies may include, for example, read and write capabilities. Model access policies may provide security related to watermarking the model, such as through digitally signed endpoint transactions.

[0140] In some implementations, computing system 108 may enforce data restriction policies. These policies allow customers to configure specific security policies and, where applicable, implement encryption and zero-knowledge succinct non-interactive argument of knowledge (zk-snarks). Customers can configure computing system 108 to enforce desired security, encryption, and zk-snarks policies when desired for accessing model data. Where implicit trust in the model is not present, computing system 108 may provide similar configuration policies for its users.

[0141] In some implementations, computing system 108 can enforce traceability and auditability policies. These policies allow computing system 108 to record endpoint transactions in a standardized format. In some examples, recorded endpoint transactions may be stored in a secure database. In some examples, recorded endpoint transactions may be stored in a private blockchain. In some examples, recorded endpoint transactions may be stored in both a secure database and a private blockchain. Furthermore, traceability and auditability policies enable computing system 108 to perform threat detection, threat mitigation, and threat alerts. These threat level features, for example, allow computing system 108 to provide customers with updates if any threat is detected against their model.

[0142] Furthermore, as stated, the model may be watermarked by computing system 108. Various watermarks may include human-readable watermarks such as Joint Photographic Experts Group (JPEG), digitally signed hash values, one or more blockchains that store non-fungible tokens (NFTs), and / or GPT-Zero regarding how the file was modified and / or constructed. Other types of watermarks are also possible.

[0143] The digital engineering and authentication ecosystem 700 illustrates various cases related to model trust. In some implementations, the digital engineering and authentication ecosystem 700 illustrates a first case in which the model owner or model organization provides implicit trust in the model and determines the output of the model's identity and continuity. In the first case, a user 702 (for example, a third-party user) can interact with a user device 704 to access the model data of user 702 from the digital engineering platform 706. The digital engineering platform 706 may not trust the user's network. Upon receiving a request, the digital engineering platform 706 can access the model storage 708 and access the respective model.

[0144] To access each model, the owner can provide an implicit trust in the model. This implicit trust in the model can be used within the customer environment and provide a continuity of output. The model owner (i.e., the "model owner") may possess ground truth about the model. The model owner can execute transactions on the model, such as executing transactions that are read queries that comply with the model owner's access restrictions on data and functionality. Furthermore, the model owner can execute transactions on the model, including writes to the model. The digital engineering platform 706 can receive and execute the requested transactions. For example, when a write transaction is executed, the digital engineering platform 706 can instruct the platform agent 710 to create a copy or fork of the model within the customer environment and apply the write transaction to the forked copy. The model owner can then decide whether to accept the edits made to the forked copy or reject the forked copy. Furthermore, Accord allows the model owner to determine which models are valid and select specific tools to verify the validity of the models themselves.

[0145] In some implementations, the digital engineering and authentication ecosystem 700 exhibits a second case where there is no implicit trust in the models, model identities, and continuity outputs. Similar to the first case, a user 702 (e.g., a third-party user) can interact with a user device 704 to access the user's respective model data from the digital engineering platform 706. The digital engineering platform 706 may not trust the user's network. Upon receiving a request, the digital engineering platform 706 can access the model storage 708 and access the respective models. However, the model storage 708 may not include an implicit trust in the models, or in the model identities and continuity outputs.

[0146] In the second case, the model storage 708, which does not have implicit trust, stores the model in secure storage. In particular, the model storage 708 can store multiple secure model identifiers. Multiple secure model identifiers may include a model identifier and a pointer to the model address in secure storage. In some examples, the model ID and the pointer to the model address can be stored in individual elements of the blockchain and / or tokenized and stored in individual elements of the blockchain. In this way, if an unauthorized user were to access the model storage, which does not have implicit trust, the unauthorized user would not be able to access the model data thanks to the storage of the model data in a separate secure area. Regarding continuity, the digital engineering platform 706 can approve endpoint transactions after the historical history of model V&V transactions has been verified. In this way, the digital engineering platform 706 can ensure that subsequent transactions, such as write functions that may modify the model, do not break the previously validated state of the model.

[0147] In some implementations, the transaction history of a model may be stored in various databases. In some examples, the transaction history of a model may be stored in a secure database of edit history along with the associated cryptographic hashes. In some examples, the transaction history of a model may be stored in a private transaction blockchain in a tokenized manner.

[0148] To enforce the accord, a digital engineering platform may seek consensus among a distributed set of models or DE tools for validation. The consensus mechanism may allow a group of nodes containing different digital engineering (DE) tools for evaluating or validating a particular digital model or multiple models in open access storage to agree on the output from a particular model. The consensus mechanism may include PoS or PoR techniques to ensure that all nodes in the network of open access storage digital engineering models have the same view of the data for a particular model, even in the presence of a faulty or malicious node. DE tools on different nodes may perform similar validation or evaluation operations on a particular model. A zero-trust policy regarding the model also applies to these DE tools. Evaluations of a single DE tool are not relied upon; instead, a consensus across various nodes with different DE tool evaluations is used to seek the accord. Other implementations of the consensus mechanism may ensure that the models known to the network are the same, validated, and known set that can be queried and updated. Different consensus mechanisms may use an additional layer of validation and verification in a digital engineering sense to act as a different voting metric within the system. In such consensus methods, the model must pass thresholds of requirements specified in the document or other metrics that must be met. Once these are achieved in the simulation space, the model is assigned a score or weight that gives the model its voting weight. In other implementations, the accord output for the model may also be managed as an entry in a model transaction database or as a fungible token within a blockchain transaction. Other examples are possible.

[0149] To ensure the secure sharing of models within a digital engineering platform, the system for secure model sharing should meet audit and assurance requirements. In some examples, the digital engineering platform 706 can perform traceability by tracking any specific changes to the system or a particular model, such as changes made by the model owner or other users. In some examples, the digital engineering platform 706 can perform monitoring and prevention functions. These functions may include maintaining a constant alert security posture of the system, such as detecting attacks, blocking attacks, detecting threats, and providing users with warnings indicating threats and / or attacks. Furthermore, the digital engineering platform should strive to comply with NIST 800-171 and NIST 800-53.

[0150] In some implementations, the digital engineering platform 706 can share models and access to models with users authenticated on the platform. In some cases, user 702 can authenticate with the digital engineering platform 706 by providing their respective credentials (i.e., username and password). The digital engineering platform 706 can authenticate user 702 once it determines that the credentials provided by user 702 match the stored credentials. Depending on the authentication of user 702, the digital engineering platform 706 can provide the authenticated user 702 with access to an integrated development environment (IDE) that stores various models. The IDE may store one model, thousands of models, or even more. In some examples, user 702 may have access to a specific model as an entire file. These models may include, for example, M&S tools, CAD tools, MBSE tools, AR tools, PLM tools, simulation engines, requirements models, electronics models, test planning models, cost models, scheduling models, software models, supply chain models, manufacturing models, cybersecurity models, multi-attribute trade space tools, and mission effect models. Other models that can be accessed are also available. In some implementations, each digital model may contain one or more digital artifacts that can be accessed and / or acted upon by an authenticated user.

[0151] In some implementations, the digital engineering platform 706 can provide an authenticated user 702 with access to multiple IDEs. In some examples, IDEs may be associated with specific themes. For example, the first IDE may contain models related to finance, the second IDE may contain models related to manufacturing, and so on. The digital engineering platform can provide the authenticated user 702 with access to one IDE, a subset of IDEs, or all of IDEs, according to specified criteria. In particular, the digital engineering platform 706 can provide an authenticated user with access to one or more IDEs based on the authenticated user's desired use.

[0152] In some implementations, the digital engineering platform 706 can provide authenticated users 702 with access to a subset of the functionality of models within IDEs. For example, the digital engineering platform 706 can provide authenticated users 702 with restricted or limited access to limited functionality (e.g., "slices") or limited APIs of models in various IDEs, using wrappers for a specific model or multiple models. For instance, the digital engineering platform 706 may enable user 702 to access a first functionality or first slice of a model in a first IDE, a second functionality or second slice of a model in a second IDE, and a third functionality or third slice of a model in a third IDE. In this example, the digital engineering platform 706 can restrict the user's access to other functionality of each of the models in the first, second, and third IDEs. In some examples, the digital engineering platform 706 can provide authenticated users 702 with access to a subset of slices in various IDEs. In this way, authenticated users 702 can access only the slices provided by the digital engineering platform in each of the various IDEs. Therefore, the digital engineering platform 706 can enable authenticated users 702 to access any combination of slices from each of multiple IDEs.

[0153] The various implementations of the computing environment shown in Figure 8 differ in the location of the computing environment relative to the customer's computing environment 809. In some implementations, the computing environment can be separate from the customer's computing environment 809. In some implementations, the agent 810 of the customer's computing environment 809 may be instantiated behind the customer's firewall. This allows agent 810 to operate within the customer's firewall and access control, enabling more secure access to the digital model 812 within the customer's computing environment 809 and faster overall computation. However, having a computing environment separate from the customer's computing environment 809 can enable greater scalability and flexibility in accessing the digital model.

[0154] In some implementations, the digital engineering and authentication ecosystem 800 in Figure 8 shows a user 802 interacting with an interconnected digital engineering platform 804. The interconnected digital engineering platform 804 can communicate with a customer's computing environment 809 behind a firewall. In particular, a company may protect its network with a firewall and restrict the information the company shares outside of its network. This specific feature of restricting access to the company network can be extended to include the feature of model sharing.

[0155] When a network is not trusted, information linked to a model can be effectively shared across the entire network, for example, behind a firewall. In some implementations, the model 812 remains stored within the customer's company network 809 and cannot be extracted from those networks. The model owner can own and maintain the ground truth of their model without, for example, moving the model behind a firewall. Similarly, another advantage of the digital engineering and authentication ecosystem 800 is that the model wrapper 808 can link to a specific subset or slice of the model's functionality within the company's own network. In this way, an authenticated user 802 requesting access to the slice can receive the API or output from the model slice from behind the company network without the model ever leaving the company network. Furthermore, the model owner can define permissions for slices of their model.

[0156] As shown in the digital engineering and authentication ecosystem 800, a user 802 can submit a request to an interconnected digital engineering platform 804. A user experience (UX) or user interface (UI) component 806 can receive and log the request. In particular, the UX / UI component 806 can log the request to an endpoint transaction database or a private blockchain. The endpoint transaction data or private blockchain may reside within the interconnected digital engineering platform 804 or outside of the interconnected digital engineering platform 804, such as in a cloud network. After logging the request, a model and feature wrapper 808 can communicate with the UX / UI component 806 to analyze which model the request is asking for by extracting data indicating the model from the request. Using the extracted data indicating the model from the request, the model and feature wrapper 808 can access model IDs from a model ID database or private blockchain. The model ID database or private blockchain may store data including, to name a few, multiple model IDs, model locations, and other data that indexes the model IDs along with the model locations. A private blockchain that stores data including multiple model IDs and other information can be separate from a private blockchain that stores logs of user requests. In some cases, the private blockchains may be similar.

[0157] Upon receiving a model ID from a model ID database or a private blockchain, the model and function wrapper 808 can send a forwarding request to the customer's environment network 809 through a firewall or other network component. The customer's environment network 809 may include an agent 810 that monitors activity requests. The agent 810 receives forwarding requests from the model and function wrapper 808 of the interconnected digital engineering platform 804 and can verify the permission of the request, indicating that it may access model data within the customer's environment network 809. The agent 810 can verify the permission of the request in a database that stores user access control policy information. Verifying the permission of the request includes verifying that the user is permitted to access data stored in one or more models 812 in the customer's environment network 809. If access is denied, the agent 810 can provide a denial to the model and function wrapper 808. If access is permitted, the agent 810 can verify the permission of the request in a database that stores model access control policies. If access is denied, the agent 810 can provide a denial to the model and function wrapper.

[0158] If permitted, agent 810 can perform actions on one or more customer models 812 within the customer's environment network 809. In some implementations, actions may include read actions, write actions, or any other type of action. In response to the action, agent 810 may return the updated model or data indicating the updated model to the model and function wrapper 808 of the interconnected digital engineering platform 804 through the firewall. Accordingly, the model and function wrapper 808 may provide the data indicating the updated model to the UX / UI component 806, which can then provide the same data to user 802 via the user's endpoint device or user device. Other examples are possible.

[0159] In some implementations, the Digital Engineering and Authentication Ecosystem 800 ensures that models remain within the customer environment (with implicit trust in the models) or in secure storage (without implicit trust in the models). In particular, the Digital Engineering and Authentication Ecosystem 800 provides various data security protections. Specifically, the Digital Engineering and Authentication Ecosystem 800 can track and authorize user access on endpoints or user devices. Tracking and authorization may be performed using attribute-based access control (ABAC). For example, an interconnected digital engineering platform 804 can track and authenticate user profiles and enable access restrictions that may be enforced by a central policy server stored on or outside the interconnected digital engineering platform. In some examples, the central policy server may be updated by an endpoint transaction database or a private blockchain, to name a few examples.

[0160] In some implementations, the interconnected digital engineering platform 804 can record transactions at endpoints. In particular, the interconnected digital engineering platform 804 can standardize transaction recording at endpoints. Furthermore, platform 804 may store various information or metadata related to transaction recording, such as the model owner organization, model owner ID, user ID, user access rights, device ID, device location according to the IP number and geographic location identifier, model and function wrapper IDs, transaction commands related to the invocation of model and function wrappers, time associated with each transaction command, and values ​​associated with the transaction. Other examples may include the function ID, the type of method called, the transaction start time, the transaction end time, the duration, the parameters of the invocation made by the model and function wrappers, the success of the invocation (e.g., either "TRUE" or "FALSE"), CPU cost time expressed in monetary, time, and cycles, and GPU cost time expressed in monetary, time, and cycles. Other examples may also exist.

[0161] In some implementations, the interconnected digital engineering platform 804 can store transaction history using cryptographic hashes. Specifically, the interconnected digital engineering platform 804 can tokenize previous transactions and store the tokenized previous transactions on a private blockchain or an external private blockchain on a cloud network. In this way, the interconnected digital engineering platform 804 can securely track and analyze end transactions from users interacting with the interconnected digital engineering platform 804 over time.

[0162] In some implementations, user 802 can access the interconnected digital engineering platform 804 through their end device. Specifically, user 802 can access the platform via their end device, which connects to the platform's user experience. Once connected, user 802 can submit requests to access a model, multiple models, or a specific slice of a model. As described, the interconnected digital engineering platform 804 can record access requests in an endpoint transaction database or private blockchain via the model and feature wrapper 808 or an API. Furthermore, the interconnected digital engineering platform 804 can fetch model information (e.g., model ID and other data) from the model ID database or private blockchain via an API. The model and feature wrapper 808 can then forward the access request to an agent in the model owner's environment or the customer owner's environment 809. The customer owner's environment 809 may be located behind one or more firewalls.

[0163] The firewall may accept or reject the access request provided by the model and feature wrapper 808. If the firewall accepts the access request, the request is forwarded to agent 810 in the customer owner's environment 809. Agent 810 can verify the permissions of the access request with the user access policy server and the model access control policy. Accordingly, agent 810 may return the requested model to the interconnected digital engineering platform 804 via the model and feature wrapper 808. Where applicable, the firewall may either accept or reject the agent's access to provide the requested model. If accepted, the firewall may provide the requested model or data indicating the requested model to the model and feature wrapper 808. Accordingly, the model and feature wrapper 808 may display the model wrapper to user 802 via user 802's end device.

[0164] Figure 9 shows a digital engineering and authentication ecosystem 900 in which read operations are performed. Figure 10 shows a digital engineering and authentication ecosystem 1000 in which write operations are performed. Generally, the difference between implementations of read queries and write queries may be seen in their ability to modify the state of the model. For example, a read query does not modify the model, while a write query may. To ensure the security of the model, an implementation for write queries may include creating a copy of the model and enabling open access, while read queries are parsed through a wrapper and authorized at the endpoint. Output data from both queries may be transmitted in their entirety, edited, using zero-knowledge techniques, or watermarked. These security implementations aim to balance the need for access to the model with the need to protect the state and data of the model. Figure 9 may include components similar to those shown in other figures described herein.

[0165] In the digital engineering and authentication ecosystem 900 where the read operation is performed, the read operation can be linked to a model in the customer environment. In some implementations, a user 902 can access the interconnected digital engineering platform 904 through their end device. In particular, the user 902 can access the platform 904 through their end device, which connects to the platform's user experience. Once connected, the user 902 can submit requests to access a model, multiple models, or a specific slice of a model. As described, the interconnected digital engineering platform 904 can record access requests to an endpoint transaction database or private blockchain via the model and function wrapper 908 or an API. Furthermore, the interconnected digital engineering platform 904 can fetch model information (e.g., model ID and other data) from the model ID database or private blockchain via an API. The model and function wrapper 908 can then forward the access request to an agent 910 in the model owner's environment or the customer owner's environment 909 in order to access one or more stored models 912 in the customer owner's environment 909. The customer-owned environment 909 may be located behind one or more firewalls.

[0166] The firewall may accept or reject the access request provided by the model and feature wrapper 908. If the firewall accepts the access request, the request is forwarded to agent 910 in the customer owner's environment 909. Agent 910 verifies the permissions of the access request with the user access policy server and model access control policy and can retrieve data from the requested model 912. Accordingly, agent 910 can return the requested model or data indicating the requested model to the interconnected digital engineering platform 904 via the model and feature wrapper 908. Where applicable, the firewall may either accept or reject the agent's access to provide the requested model. If accepted, the firewall can provide the requested model or data indicating the requested model to the model and feature wrapper 908. Accordingly, the model and feature wrapper 908 can display the model wrapper to user 902 via user 902's end device.

[0167] As shown in Figure 10, in the digital engineering and authentication ecosystem 1000 where write operations are performed, write operations are performed by creating a copy or forking a copy without modifying the source material of the model. The process performed for write operations in the digital engineering and authentication ecosystem 1000 is similar to the process performed for read operations, but with several differences. In some implementations, user 1002 can access the interconnected digital engineering platform 1004 through their end device. In particular, user 1002 can access platform 1004 via their end device that connects to the platform's user experience (e.g., UX / UI components 1006). Once connected, user 1002 can send requests to access a model, multiple models, or a specific slice of a model. As stated, the interconnected digital engineering platform 1004 can record access requests to an endpoint transaction database or private blockchain via model and function wrappers 1008 or APIs. Furthermore, the interconnected digital engineering platform 1004 can fetch model information (e.g., model ID and other data) from a model ID database or a private blockchain via an API. The model and feature wrapper 1008 can then forward access requests to an agent 1010 in the model owner's environment or the customer owner's environment 1009. The customer owner's environment 1009 may be located behind one or more firewalls.

[0168] The firewall may accept or reject the access request provided by the model and function wrapper 1008. If the firewall accepts the access request, it forwards the request to agent 1010 in the customer owner's environment 1009. Agent 1010 can verify the permissions of the access request with the user access policy server and the model access control policy. Accordingly, agent 1010 may create a fork of the requested model and, according to the request, apply changes (e.g., modifications) to the forked model 1014. In some examples, creating a fork of the requested model may involve creating one or more copies of the model and copies of the model in various formats. The forked model 1014 can be a copy of model 1012 stored in the customer owner's environment 1009. At this point, the model owner can review the changes made to the forked model 1014 and decide whether to accept or reject the changes made to the forked model 1014. If the model owner accepts the changes, the stored model 1012 may be updated. If the model owner rejects the changes, the changes will not be applied to the stored model 1012, thus preserving the integrity of the stored model 1012.

[0169] Accordingly, agent 1010 can return the model update to the interconnected digital engineering platform 1004 via the model and feature wrapper 1008. Where applicable, the firewall may either accept or deny the agent's access to provide the model update. If accepted, the firewall can provide the model update or data indicating the model update to the model and feature wrapper 1008. Accordingly, the model and feature wrapper 1008 can display the updated model wrapper to user 1002 via user 1002's end device.

[0170] In some implementations, the Digital Engineering and Certification Ecosystem 1000 outlines various processes for creating forks from the original digital model, which are then subject to approval or rejection by the model owner. In some implementations, the Digital Engineering and Certification Ecosystem 1000 provides a permission-based approach for managing access and modification within the Digital Engineering (DE) model, with a focus on read, write, and own roles. By utilizing the permission model, the owner can generate a specific fork and invite designated collaborators on the front end who have pre-assigned read, write, or own permissions to participate in the development process.

[0171] In some implementations, by incorporating a permission model into the Digital Engineering and Authentication Ecosystem 1000, the ecosystem facilitates the generation of "edited" versions of the model. Using the edited version of the model, the owner creates a derived model containing selected data points, where collaborators are given roles—read, write, or owner—to establish a structured and controlled environment for handling the data. Authors of the digital engineering model are authorized to modify the model, while facilitating a collaborative and regulated modification process with attribute-based access control. Nevertheless, incorporating modifications from Model 2 into the original model is left to the sole discretion of the model owner, a critical step in maintaining the integrity and reliability of the primary model. As a result, the Digital Engineering and Authentication Ecosystem 1000 includes model merging through manual intervention by authorized users or through the implementation of a set of rule-based scripts.

[0172] In some implementations, the design and intended functionality of the permission model system are incorporated into the interconnected digital engineering platform 1004. This implementation is designed to protect the integrity and security of the digital model before performing write operations. The conceptual design allows for manual or external integration of updates from secondary models to the original model, providing flexibility for adaptation and future improvements. Thus, by incorporating permission-based models, the digital engineering and authentication ecosystem 1000 aims to enhance the controlled and collaborative management and development of digital models.

[0173] In some implementations, Model 1012 storage can further advance data security policies. In particular, Model Storage 1012 may include a public or private database linked to an interconnected digital engineering platform. Data security policies can advance various policies. These policies may include Model Identity, Model Continuity, and Model Accord. Model Identity may include the identity of a model, such as a Model Identifier. Model Identifiers can be stored in a secure database, for example, using cryptographic hashes, or tokenized on a blockchain network. The blockchain network can store Model Identifiers, or pointers to addresses that store addresses to various models. Model Continuity may relate to tracking and analyzing metadata of endpoint transactions or standardized endpoint transactions with respect to continuity. Tracking and analyzing endpoint transactions can be stored using cryptographic hashes or by tokenizing transaction records on a private blockchain. Furthermore, new transactions may be verified and added to a private blockchain if the V&V's previous track record is not overturned. Finally, model accords may include analyzing the model with multiple DE tools and utilizing the ZK-snarks accord.

[0174] The difference between the security implementation for sharing a digital model and the security implementation for sharing an edited portion of a digital model, as shown in Figures 11 and 12, lies in the amount of data shared. In the first implementation, the entire digital model is shared, as shown in Figure 11. In the second implementation, only the edited portion of the model is shared (i.e., a subset of model attributes), as shown in Figure 12. Both implementations include user and endpoint authentication, request parsing through a wrapper, and authorization of the request at the endpoint. The output data may also be watermarked for traceability. The choice of whether to share the entire model or only the edited portion may depend on the specific security and privacy needs of the data used by the model, as well as the level of user access and the user's intended and authorized use of the requested data from the model.

[0175] Figure 11 shows different implementations for sharing models in the digital engineering and authentication ecosystem 1100. The first implementation shows model sharing without a customer firewall. The second implementation shows model sharing with a customer firewall. In the first implementation, a user can first select a model to share, define user and attribute access policies associated with the model to be shared, and upload the model to the interconnected digital engineering platform (1102). The interconnected digital engineering platform can log the received sharing requests to a transactional database (1104). Accordingly, the interconnected digital engineering platform can add and / or update the database with the model ID and information associated with the model (1106). The interconnected digital engineering platform can then send the model and wrapper to the client device for application (1108). The client device can, at the user's discretion, apply the model wrapper wherever the model is stored (1110). In some examples, cloud-based security techniques can be unlocked by enabling model wrapping or model splicing on edge devices. When models or model-like files are maintained on edge devices such as client devices, these models or model-like files can be viewed and / or modified on the edge devices in a secure manner through model splicing. Accordingly, interconnected digital engineering platforms can store model wrappers with appropriate security and access control protections (1112). In some implementations, if the digital engineering and authentication ecosystem 1100 includes the use of permission models, a user may be granted or denied access to one or more digital engineering models at this stage.

[0176] In the second implementation, the user can select a model to share, define user and attribute access policies associated with the model to be shared, and upload the model to the interconnected digital engineering platform (1114). In some cases, if the interconnected digital engineering platform includes a permission model, the permission model may authorize user access at this stage, prior to the user being able to select a model to share, define user and attribute access policies associated with the model to be shared, and upload the model to the interconnected digital engineering platform. The interconnected digital engineering platform can log the received sharing requests to a transactional database (1116). Accordingly, the interconnected digital engineering platform can add and / or update the database with the model ID and information associated with the model (1118). The interconnected digital engineering platform can then send the model and wrappers to a digital engineering agent behind the firewall in the customer environment for application (1120). The digital engineering agent can apply the model wrappers and functionality (1122). Outside of the digital engineering agent, the customer environment can apply model wrappers and functions in a location where the model is stored, such as a specific IDE (1124). Accordingly, the interconnected digital engineering platform can receive the model wrappers through a firewall and store them with appropriate security and access control protections (1126).

[0177] Figure 12 shows different implementations for sharing edited models in the Digital Engineering and Certification Ecosystem 1200. The first implementation shows edited model sharing without a customer firewall. The second implementation shows edited model sharing with a customer firewall. The first implementation of the Digital Engineering and Certification Ecosystem 1200 (1202 to 1212) is similar to the first implementation of the Digital Engineering and Certification Ecosystem 1100 (1102 to 1112). Similarly, the second implementation of the Digital Engineering and Certification Ecosystem 1200 (1214 to 1226) is similar to the second implementation of the Digital Engineering and Certification Ecosystem 1100 (1114 to 1126).

[0178] However, the first implementation of Ecosystem 1200 differs from the first implementation of Ecosystem 1100 on the client side. In particular, the client can use the model wrapper to reduce the polygon count of the shared wrapper model and apply the reduced or edited shared model where the original model is stored (1210). The interconnected digital engineering platform can then receive the model wrapper and store it with appropriate security and access control protections (1212). Similarly, the second implementation of Ecosystem 1200 differs from the second implementation of Ecosystem 1100 in the customer environment behind a firewall. In particular, the digital engineering agent can apply the model wrapper and functions to reduce the polygon count of the shared wrapped model and create a reduced shared model (1222). Outside the digital engineering agent, the customer environment can apply the model wrapper and functions where the model is stored, such as in a specific IDE (1224). Accordingly, interconnected digital engineering platforms can receive model wrappers through firewalls and store the model wrappers with appropriate security and access control protections (1226).

[0179] In some cases, reducing the polygon count may involve reducing the polygon count of the polygon mesh representation of a CAD model. Reducing the polygon count of the polygon mesh representation of a CAD model can blur or obfuscate CAD models that have sparse or dense mesh models. In some implementations, digital agents and / or interconnected digital engineering platforms can perform various methods of editing. For example, one method of editing may involve reducing the polygons of a mesh representation that have a specific attribute type, such as geometry or material properties, or allowing access to specific model attributes. These editing controls can be nested and configured by the model owner. For example, editing controls can be wrapped to include only properties, and the owner can specify that the shine property should not be revealed.

[0180] The difference between the two implementations shown in Figures 13 and 14 lies in the visual representation of the components of the digital engineering ecosystem and the user's computing environment. While both flowcharts illustrate the sequence of processes involved when a user interacts with the digital model, the visual representation of these components and environments differs in each implementation. This difference in representation provides further clarity to the relationship between the components and the user's computing environment within the overall zero-trust security of the model. These flowcharts can be viewed in conjunction with Figure 8 for a complete understanding of the various elements involved in the security implementation.

[0181] The processes shown in Figures 13 and 14 may be performed by a digital computing system such as the digital computing system 108, an interconnected digital engineering platform, a customer firewall, a digital engineering agent, one or more customer models stored in the customer environment, and other components described throughout this specification. Figure 13 shows a process 1300 related to user reading and writing to a model. Figure 14 shows another implementation of a process 1400 related to user reading and writing to a model.

[0182] In some implementations, the digital computing system 108 that performs the processes related to Figure 13 may provide permission enforcement. Permission enforcement may be performed by the permission model described with respect to Figure 10.

[0183] In process 1300, the interconnected digital engineering platform can provide a user interface to the user's end device. The user interface can check user and model access control policies to display authorized models to the user (1302). The user interface can receive user interactions and provide data indicating the interactions to the interconnected digital engineering platform (1304). For example, the user interface can receive a user request to access one or more models. Accordingly, the user interface can provide the user request to the interconnected digital engineering platform. The interconnected digital engineering platform can log the user request or access request to a transactional database (1306).

[0184] In some implementations, an interconnected digital engineering platform can fetch model identifiers and model information from a model database (1308). In particular, the interconnected digital engineering platform can extract data indicating the type of model being requested, and for example, it can use the extracted data indicating the type of model being requested from the model database as an index to fetch model identifiers and model information. In response to the retrieval of model identifiers and model information from the model database, the interconnected digital engineering platform can forward the user request along with the model identifiers and model information to the model location (1310).

[0185] As shown in Figure 13, an interconnected digital engineering platform can forward or send user requests along with model identifiers and model information to a model location, which may be behind a company or customer firewall, API gateway, messaging service, network blocking function, or another type of network system that considers accepting or denying network traffic. The company or customer firewall can receive requests forwarded from the interconnected digital engineering platform (1312). The firewall can accept the forwarded request and decide whether to forward the request to a digital engineering agent behind the firewall or to reject the forwarded request. When the firewall accepts the forwarded request, the agent receives the forwarded request and validates the request against user and model access policies (1314). For example, the agent may validate the permissions of the user request against user access control policies and model access control policies. If the agent validates that the user request is authorized, the agent can forward the received request to a locally stored model (1316). If the agent determines that a user request is not authorized against one or more user access control policies or model access control policies, the agent may discard or reject the user request.

[0186] In some implementations, the agent can determine the type of user request when the user request is validated against user access control policies and model access control policies. For example, the agent can determine whether the user request is a read or write request. If the agent determines that the user request is a read request, the agent can access the appropriate wrapper or API for the requested model (1318). Alternatively, if the agent determines that the user request is a write request, the agent can fork or create a copy of the requested model (1320). The agent can apply the requested write changes to the forked copy of the requested model, and thus the stored model retains the data of that stored model. Depending on whether the write changes have been applied to the forked copy, the agent can return the forked copy to the model owner (1322). The model owner can review the changes in the forked copy and decide whether to accept or reject the changes. If the model owner decides to accept the changes, the changes in the forked copy may be applied to the stored model. If the model owner decides to reject the changes, the agent can discard the forked copy.

[0187] In some implementations, the agent can perform the aforementioned actions on each of the stored customer models. In some cases, the agent can perform read or write actions on each of the stored customer models within the customer environment. In some cases, the agent can perform read or write actions on each of the stored customer models outside the customer environment.

[0188] In response to read actions, write actions, or both, the agent can return a model to the customer firewall. In particular, after an agent performs a read operation, the agent can return the model or a wrapper of the model to the interconnected digital engineering platform via the customer firewall (1324). Similarly, after an agent performs a write operation, the agent can return a forked model or a copy of the model with the edits to be written applied to the interconnected digital engineering platform via the customer firewall (1326). If both operations are requested in a user request, the agent can provide both the model or wrapper and the forked model to the interconnected digital engineering platform via the customer firewall.

[0189] In some implementations, the customer firewall can receive data from agents (1328). In particular, the customer firewall can receive responses to user requests from agents. Responses to user requests may include, for example, a model or a wrapper for a model, a forked copy of a model, or both. The customer firewall can decide whether to accept or reject the response to the user request. If the customer firewall rejects the request, it can ignore the response. If the customer firewall accepts the request, it can provide the response to the user request to the interconnected digital engineering platform.

[0190] In some implementations, the interconnected digital engineering platform can receive responses to user requests from the customer firewall (1330). The interconnected digital engineering platform can provide the responses to user requests to the user interface on the end device or endpoint of the user who sent the user request. Before displaying the responses to user requests on the end device's user interface, the interconnected digital engineering platform can verify that the user is an authenticated user to view these results. Verification can be performed by comparing the user's credentials with the user access policy and the model access policy. Depending on the successful authentication of the verification against the policy, the interconnected digital engineering platform can display the responses to user requests on the user interface of the authenticated user's end device. This process can be repeated for each user request sent by the user to the interconnected digital engineering platform.

[0191] In some implementations, the interconnected digital engineering platform may be located within or behind the customer firewall. In this implementation, the processes performed by the interconnected digital engineering platform shown in Figure 13 may run within the customer firewall. Other examples and deployments of the interconnected digital engineering platform are also possible.

[0192] In some cases, an interconnected digital engineering platform may utilize a permission model that enforces user authentication before using the platform. For example, the permission model may be implemented in the user interface, the backend, or at another stage of the process described with respect to Figure 13. In some implementations, the permission model can enforce permission-based access to various digital models within the interconnected digital engineering platform.

[0193] For example, permission models include mechanisms for calculating access and making permission decisions using relation-based access control (ReBAC) systems. ReBAC systems can define an authorization paradigm in which the tasks of those accessing a particular resource are defined by the existence of relationships between those individuals and the resource. Generally, authorization in ReBAC systems is performed by traversing a directed graph of relationships using nodes and edges of a directed graph in Resource Description Framework (RDF) format. In some examples, ReBAC systems allow for hierarchies of relationships, and in some cases, allow for complex definitions involving algebraic operators on relationships such as union, intersection, and difference.

[0194] The permission database can track relationships between resources within an interconnected digital engineering platform. For example, a user might have a relationship "editor" with a particular model, or a file might have a relationship "output metadata" with a particular digital engineering job. When an actor, such as a human or computer, attempts to access a resource, such as a particular digital engineering model, the permission system evaluates a policy document at the time of access. During evaluation, the permission system scans a relationship graph linking actors and resources in the ReBAC system, then maps that graph to the policy document to make a decision about a specific action, such as granting or denying permission.

[0195] Figure 13 shows, for example, process 1300, which takes place in the user interface and begins at 1302. In some implementations, process 1300 and, in particular, permission checks may be performed in the backend, for example, the digital engineering platform. For example, permission checks may be performed in the backend after the user has submitted their request and the attempt to submit the request has been logged to the transaction database (1306). If the user does not have the appropriate permissions to access the digital engineering platform and permission authentication fails, process 1300 terminates. Alternatively, if the user has the appropriate permissions at 1306, process 1300 continues to 1308.

[0196] Utilizing a permission model to check user permissions at the backend rather than the frontend of the user interface can further enhance zero-trust security for the digital model. For example, the user interface is directly exposed to the user, allowing a malicious user to potentially breach the interface and skip all permission checks there. Furthermore, a malicious user may choose to interact directly with the backend, completely bypassing the user interface and its checks. Thus, the user interface can introduce security vulnerabilities that hinder secure permission enforcement. Therefore, only by enforcing permissions at the backend can an interconnected platform of digital engineering ensure that users only perform secure actions that they are permitted to perform. For example, by performing permission checks after transaction logging, e.g., after 1306, a digital engineering platform can log failed / unauthorized transactions and, in some implementations, include a threat detection step that uses a machine learning model trained on user transaction access logs.

[0197] In some implementations, the use of access and transaction logs in a digital engineering platform provides a critical part of zero-trust security practices. Engineering processes critically rely on provenance to meet legal, regulatory, and other compliance requirements and to ensure the correctness and completeness of the output of the digital engineering process. For example, it is not enough to know that a design has been approved as meeting requirements; what needs to be known is who approved the design and when that approver approved it. Sufficient and complete access and transaction logs provide this critical provenance data—these logs enable a precise reconstruction of all modifications, changes, approvals, evaluations, and other actions taken on the design, allowing for a complete track of who was responsible for which aspect of the outcome and when that person performed their work.

[0198] Similarly, a sufficient and complete log of failed accesses is a crucial tool for investigating potential misconduct, detecting security breaches, and ensuring that information protection and distribution policies are properly followed and enforced. For example, a user reviewing access logs can determine whether a user "gone rogue" or attempted to disrupt a project, whether a compromised account is making a number of unusual or unexpected requests, or whether policies regarding the use of digital models are being properly followed.

[0199] As explained below with respect to Figure 15, accessing and storing transaction logs on a blockchain or distributed ledger can offer further advantages. For example, one such advantage includes enabling third parties with access to the blockchain to perform the same verification and auditing processes described above. As explained below with respect to Figure 16, comprehensive logging is particularly important in multi-enclave / multi-tenant environments, because in such situations, one organization or tenant may not have an overview of the entire digital engineering process. Access logs can reveal a complete view by tracking actions on the model across all enclaves and all tenants, enabling the synthesis of a complete view, allowing for end-to-end auditing of digital engineering products, compliance checks, and more.

[0200] Figure 14 shows another implementation of process 1400 related to user read and write access to a model. In process 1400, the interconnected digital engineering platform can verify the user's authenticity against user and model access control policies to ensure that the user is authenticated to review authorized model information (1402). Upon successful authentication, the user can send user requests from their respective end devices to the UX / UI components of the interconnected digital engineering platform (1404). The interconnected digital engineering platform receives the user requests and can log the access requests to a transactional database (1406). The interconnected digital engineering platform can then extract model identification information from the user requests and use the extracted model identification information to locate the model ID and model information from the model database (1408). The model database may be connected locally to the interconnected digital engineering platform or connected to the interconnected digital engineering platform via the internet.

[0201] Depending on access to the model ID and model information from the model database, the interconnected digital engineering platform can forward user requests to the location of the requested model (1410). The interconnected digital engineering platform can use the model ID and model information as a destination address to identify the location of the requested model. In some cases, the model ID and model information may be forwarded to the model location along with the user request.

[0202] In some implementations, the model may be located behind a customer firewall in the customer environment. The customer firewall can receive user requests and decide whether to accept or reject them (1412). If the customer firewall accepts the user request, it can forward the user request to a digital engineering agent behind the firewall. The digital engineering agent receives the forwarded user request and can validate the user request's access against user access policies and model access policies (1414). If the digital engineering agent determines that the user access request is validated against user access policies and model access policies, it can forward the user request to the requested model (1416).

[0203] In some implementations, a digital engineering agent can determine the type of action to be performed from a user request. If the digital engineering agent determines that the type of action is a write request, it can create a copy or fork of the requested model and apply the changes of the write request to the forked model (1420). The forked copy with the written changes may then overwrite the stored model or send it to the model owner for review. The model owner may either accept the written changes, which then apply to the stored model, or reject the written changes, which may cause the digital engineering agent to discard the forked copy (1422). The digital engineering agent can then return the forked model to the interconnected digital engineering platform (1424).

[0204] If the digital engineering agent determines that the type of action is a read request, the digital engineering agent may access an API or model wrapper for the requested model (1418). The digital engineering agent may return the API or model wrapper to the model owner for review in order to access data from the model (1426). Furthermore, the digital engineering agent may return either the model or the API to an interconnected digital engineering platform.

[0205] The customer firewall receives either a forked copy of the model or a model wrapper (i.e., a response to a user request) and can decide whether to pass the response to the user request through the interconnected digital engineering platform (1412). If the customer firewall decides to pass the response to the user request through the interconnected digital engineering platform, the interconnected digital engineering platform can receive the response and verify again that the user can access the model data (1428). This additional security step ensures that the interconnected digital engineering platform verifies the authenticity of the user reviewing the response to the user request, which may be a different user from the user who submitted the user request.

[0206] Upon successful user authentication to view the response to the request, the interconnected digital engineering platform can display the response to the user request (1430). The response to the user request may be displayed in a variety of ways. For example, the response may be displayed via the user interface of the end device, via the user interface of a display connected to the interconnected digital engineering platform, or provided as a message to the end device, for example, via email, text, or audio message.

[0207] In some implementations, an interconnected digital engineering platform can apply digital watermarks to one or more digital models within a secure digital engineering ecosystem. Digital watermarking may include, for example, the use of endpoint data, cryptographic techniques, blockchain tokenization, human- and machine-readable watermarks, concealment of watermarks within the model, creation of unique digital signatures, and incorporation of DRM technology. Other methods for digital watermarking may include, for example, steganography, which can add watermarks by concealing information within the model. An interconnected digital engineering platform may employ adding digital watermarks to digital models to provide additional protection and traceability for those digital models. In some examples, a digital engineering agent may watermark each of the stored digital models. Furthermore, the model owner may instruct the digital engineering agent and / or the interconnected digital engineering platform to indicate which of the stored models should be watermarked.

[0208] In some examples, watermarking may include platform-specific patterns of edits to a model. In other examples, watermarking may include adding a signed cryptographic hash of the most recent recorded transaction to the stored model to the model's file header, which does not change how the model may be used by other systems but provides a digital indication that the model was transactionally executed within an interconnected digital engineering platform. The watermarking process may be described with reference to any of the systems described throughout this specification. The watermarking process may be useful in situations where a digital model or data from a digital model is leaked outside the digital engineering and authentication ecosystem. For example, watermarking of a leaked model or data may be seen to identify where the leak occurred, and / or the last transaction performed on the leaked model and / or data. Thus, watermarking can provide protection for traceability purposes.

[0209] Figure 15 shows various flowcharts 1501 and 1502 for digital engineering and authentication actions using a model in zero trust. The model may be hosted in secure storage isolated from any specific customer or user. Implementing zero trust security includes authentication, authorization, data security, and secure communication between the customer's computing environment and the model storage. To achieve zero trust, policies for authentication may include secure and tamper-resistant records of the model ID and location, authorization of the model based on authentic and tamper-resistant records of transactions, and validation of the model output using a consensus mechanism to validate the model in the absence of ground truth. Figure 15 shows two different processes for protecting a digital model in zero trust, flowcharts 1501 and 1502. In the process associated with flowchart 1501, protecting a digital model in zero trust may be performed using a centralized or decentralized secure database. In the process associated with flowchart 1502, protecting a digital model in zero trust may be performed using technologies associated with blockchain technology. Processes 1501 and 1502 can be performed, for example, by an interconnected digital engineering platform.

[0210] In process 1501, secure off-chain storage for the model is created (1502). Off-chain storage can be network storage, cloud storage, or local storage, to name a few. Furthermore, a distributed database linked to an interconnected digital engineering platform may be created to store a set of pointers or memory addresses related to the model stored in the off-chain storage (1504). In some implementations, the system designer can create the secure database, which may be connected to an interconnected digital platform.

[0211] In some implementations, a secure database can store data related to each model and the actions performed on it. Specifically, the secure database can store a pointer to each model, the transaction history associated with each model, and one or more cryptographic hashes of the address history associated with each model. The secure database can be accessed to locate each model.

[0212] An interconnected digital engineering platform can track the execution of endpoints associated with a model (1506). In particular, each transaction received by the interconnected digital engineering platform may be recorded in a transaction database. In this way, each transaction can be reviewed at any time, such as by the model owner, to see all transactions applied to their respective model. A consensus mechanism across the distributed database may be used to validate the execution of the chain, such as on a blockchain. The consensus mechanism may include PoS or PoR techniques and may ensure that all nodes in the network of open-access storage digital engineering models have the same view of transactions for a particular model, even if a faulty or malicious node is present. Digital engineering tools on different nodes may perform similar validation or evaluation operations on a particular model, and a consensus across various nodes with evaluations of different DE tools may be used instead to validate the execution of the chain.

[0213] In some implementations, users can link to or connect to an interconnected digital engineering platform via their end devices (1508). Users can communicate with the interconnected digital engineering platform. In some cases, users can communicate with the interconnected digital engineering platform to determine and validate actions taken on each model. In particular, users can communicate with the interconnected digital engineering platform by checking whether the generated file hash matches the result of a similar transaction recorded in the database. For example, the cryptographic hash of a digital model or model type file should match a hash stored in the endpoint transaction database, such as by string compare, math compare, or other functions, where the hash stored in the endpoint transaction database is the cryptographic hash of the output of the corresponding transaction. If the hash matches the transaction performed on each model, the user can assure that the action on each model has been validated. Once the system validates and validates a model, the corresponding transaction on that model is automatically authenticated and added to the transaction database (1510). This process ensures that all transactions performed on each model are secure and authenticated.

[0214] In process 1502, secure off-chain storage for the model is created (1512). Off-chain storage can be network storage, cloud storage, or local storage, to name a few. Furthermore, a blockchain is created and linked to an interconnected digital engineering platform. The blockchain may be created to store a set of pointers or memory addresses related to the model stored in the off-chain storage. In some implementations, the system designer can create the blockchain.

[0215] A blockchain can contain a list of linked records, called blocks. Each block contains a pointer as a link to the previous block. Multiple parties can record transactions on the blockchain or verify previous transactions of others. A blockchain is sometimes called a ledger. For example, cryptocurrency transactions and other transactions over a period of time may be stored in blocks, and then those blocks are appended to the end of a previously created blockchain, thereby extending the blockchain. A blockchain can be kept private (for example, in a centralized manner) or publicly in a way that is never centralized.

[0216] In some implementations, interconnected digital engineering platforms can mint non-fungible tokens, NFTs, that represent pointers to digital models in a database. A model identity includes the model ID, its associated metadata, and the location of the model's address on secure storage. These details about the model identity are cryptographically hashed and added as entries to a block on the blockchain. Such an addition to a block is also called minting the token of the model identity. The token is non-fungible because the model identity must be immutable.

[0217] In some implementations, interconnected digital engineering platforms can mint an NFT representing a pointer to a model in a database after a transaction has been executed (1514). When a model is edited or modified, the transaction's endpoint metadata is either stored in the endpoint transaction database or minted as a separate token linked to the non-fungible identity token of the source model on the blockchain. For each model minted on that identity blockchain, there is an associated transaction blockchain that verifies the valid edit operation on the model and the verification or validation completed by the model. To add a new edit operation to the transaction blockchain, the system performs verification against the historical V&V history. Digital engineering tools on different nodes may perform similar verification or evaluation operations on a particular model, and instead, a consensus across various nodes with evaluations of different DE tools may be used to validate the transaction of the model.

[0218] For example, an interconnected digital platform mints NFTs by converting model transactions into crypto-transactions or digital assets recorded on a blockchain. These crypto-transactions or digital assets can be stored in a distributed ledger or decentralized database that can only be viewed, but cannot be edited, modified, or deleted. In this way, the execution of every transaction performed against a model can be recorded in a block on the blockchain (1516). An interconnected digital engineering platform can utilize a consensus mechanism to validate transactions on a distributed database or blockchain. The consensus mechanism may include PoS or PoR techniques and may ensure that all nodes in the network of open-access storage digital models have the same view of transactions for a particular model, even in the presence of faulty or malicious nodes. Different nodes' digital engineering tools may perform similar validation or evaluation operations against a particular model, and a consensus across various nodes with evaluations of different DE tools may be used instead to validate transactions for a model.

[0219] In some implementations, customers can link to or connect to an interconnected digital engineering platform (1518). In particular, customers can link to the interconnected digital engineering platform to view recorded transactions on the blockchain. Customers can validate transactions on models on the blockchain. Customers can validate transactions by checking whether the file hash generated for a transaction matches the result of a similar transaction recorded on the blockchain. For example, the cryptographic hash of a file for a digital model or model type should match the hash stored in the endpoint transaction database, which is the cryptographic hash of the output of the corresponding transaction. In some implementations, customers can monitor recorded transactions using a forked copy of their own. Once the interconnected digital engineering platform has verified and validated the model, it can automatically authenticate the transaction and mint a new NFT representing the model after the validated transaction was made (1520). The NFT can present a transaction or record of the model that is immutable and represents the user's contribution to the model. NFTs may also include supplementary information about the model, such as performance or other relevant metrics.

[0220] In some implementations, every change or update to a model creates a copy of the NFT, and thus two versions may exist independently on interconnected digital engineering platforms. In blockchain technical terminology, this is called NFT sharding. More specifically, NFT sharding means dividing an NFT into multiple sharded NFTs or multiple fragmented NFTs (1522). In some implementations, a new shard may have different associated metrics due to further validated transactions. For example, if an update to a model improves performance in a certain dimension, the associated metric for the shard of the new model's NFT may be larger. If the new sharded NFT is irrelevant, this may not be associated with any metric. At this point, the gain is re-evaluated and validated.

[0221] The implementation of zero-trust security can extend to access to and collaboration with multiple models in the computing environment shown in Figure 16, such as the digital engineering and authentication ecosystem. User 1602 can access the interconnected digital engineering platform 1604 through the UX / UI component 1606. Model and function wrappers 1608 can forward user 1602's requests to the customer's network environment 1609, which may be behind a firewall. Agent 1610 can receive requests within the customer's network environment 1609. In some implementations, system 1600 can ensure the secure execution of a complex workflow where the output from one function on protected model 1612-1 can be used as input to another function on another protected model 1612-2. This process may take place within the customer environment 1609 and / or behind a customer firewall. In some cases, this process may span multiple customer environments. This cascading process of multiple models facilitates collaboration among multiple stakeholders in complex projects with multiple models, eliminating user dependencies that interrupt the workflow to advance each step one by one. The zero-trust mechanism is applied consistently and modularly at each step for each model involved in the set of functions within the environment.

[0222] In some implementations, digital engineering and authentication ecosystems can be implemented and tested using industry-recognized penetration testing ("penetration testing") protocols. Penetration testing is a security exercise in which cybersecurity experts or cybersecurity tools are deployed to find and exploit vulnerabilities in a computer system, i.e., the digital engineering and authentication ecosystem. The purpose of penetration testing is to identify all weaknesses in the system's defenses that an attacker could potentially exploit. For example, penetration testing techniques may consist of live testing, including evaluation against standard (COTS) hacking tools and scanners, dedicated ("custom") hacking tools, human expert exploration, and validation of security properties.

[0223] The penetration testing process can vary considerably in detail, as results from earlier steps may be used to guide later steps, but the overall approach may resemble the following sequence or process. In some cases, many of the steps in this process are repeated and performed concurrently with others. First, the penetration testing team may run a set of automated hacking tools and scanners against the digital engineering and certification ecosystem. These tools are generally COTS tools, although some penetration testing teams augment these COTS tools with internally developed tools. Second, the penetration testing team may evaluate the results of the automated tools and scanners to select specific areas of the platform for further evaluation. These may include areas that could expose potential vulnerabilities in the digital engineering and certification ecosystem. Third, the penetration testing team explores and delves deeper into the areas of the platform selected in step 2, both through manual exploitation and by developing and running dedicated, for example, custom-made automated tools. Fourth, the penetration testing team may manually or automatically evaluate, validate, and verify all potential issues found in previous steps of the penetration testing process.

[0224] In some cases, the first step can be performed by an automated process, while the second and fourth steps can be performed by manual processes, and the third step can be performed by a combination of manual and automated processes. Therefore, the first step may be performed quickly, for example, in a few seconds, minutes, or hours. However, the remaining steps may be completed in hours, days, or weeks.

[0225] In general, each potential issue can be identified, whether discovered manually during penetration testing or by automated tools. In particular, each potential issue can be manually validated and verified by the penetration testing team before being formally reported as a vulnerability. For example, potential vulnerabilities that were not validated or could not be validated due to time constraints, project priorities, technical limitations, or contractual limitations can be explicitly stated when reported. The implementation described throughout this disclosure was penetration tested to validate and verify the platform's zero-trust security policy.

[0226] In some implementations, a digital engineering and authentication ecosystem can detect when an unauthorized user, such as an unauthorized computing system, attempts to access the ecosystem's computing systems and respond to such attempts to prevent unauthorized users from accessing the ecosystem. The digital engineering and authentication ecosystem is configured to deploy countermeasures when it detects communication with an unauthorized computing system. Typically, the ecosystem instead performs a simulation of its own behavior in response to commands received from the unauthorized computing system. The ecosystem can then send simulated parameter values ​​to the unauthorized computing system. The ecosystem can monitor, characterize, and / or store (for example, locally and / or in a cloud computing system) data representing the behavior of the unauthorized computing system. In this way, data about attempted cyberattacks is stored and analyzed by the ecosystem or other authorized computing systems, and the ecosystem's operation is not interrupted. When an ecosystem detects communication with an unauthorized computing system, the processes for deploying countermeasures, running simulations, and monitoring, characterizing, and storing data representing the unauthorized computing system are similarly described in U.S. Patent Application No. 17 / 903,730, the disclosure of which is incorporated herein by reference in its entirety with additional features and modifications described herein.

[0227] In some implementations, security features of digital engineering platforms include the use of machine learning models to assist in the detection of adversarial threats. Zero trust security for digital engineering models or digital models may include, for example, authorizing individual user queries to those relevant digital models based on the principle of least privilege. Digital engineering platforms can store usage data, network traffic data, and access logs, and this stored information can be used to assist in the detection of adversarial threats.

[0228] In some implementations, interconnected digital engineering and authentication platforms can leverage machine learning (ML)-based threat detection models to address security vulnerabilities. These ML-based threat detection models can use binary classification methods to handle network traffic metadata, effectively classifying network traffic into normal and potentially threatening instances. In some implementations, ML-based threat detection models can utilize a variety of other classification models. These other models may include, for example, anomaly detection models.

[0229] Input to ML-based threat detection models may include network traffic data captured directly from the service mesh essential to the digital engineering platform. This network traffic data may include, for example, volume, metadata, data rate, and timing related to communications between digital engineering tool agents and the digital engineering platform, as well as transactions involving front-end users. Data may be input as, for example, network traffic values ​​and other data types. However, all data originating from intermediaries bypassing the digital engineering platform or attributed to customer data storage may be excluded from the model's scope. With a focus on protecting privacy and maintaining a robust security standard, the model ensures that sensitive metadata is either encrypted to an undecipherable degree or completely omitted.

[0230] In some implementations, the output from ML-based threat detection models may include binary classifications. These models can generate binary classifications that clearly distinguish between normal and threat levels. In some implementations, the output from ML-based threat detection models may include values ​​ranging from normal to threat levels in severity. The digital engineering platform can compare the output values ​​to a threshold. If the output values ​​meet the threshold, the digital engineering platform can consider a threat to have been detected.

[0231] Furthermore, ML-based threat detection models can further classify threat classes into specific types of threats. This additional segmentation comes with the caveat of potential accuracy degradation due to the complexity involved in detailed threat categorization. Specific threat types may include, for example, low-risk, elevated-risk, or high-risk threats. Each of these threat types may also be related to different actions that a digital engineering platform can take to address the identified threat.

[0232] To refine the predictive capabilities of the models, the digital engineering platform can generate training datasets to further train and enhance the capabilities of ML-based threat detection models. These training datasets can be supplemented with synthesized attack data or other comprehensive databases such as CIDDS-001 or UNSW-NB15. These data types enable the digital engineering platform to effectively broaden the spectrum of identifiable features and optimize the threat detection capabilities of the models. The digital engineering platform can train ML-based threat detection models and further improve the accuracy of these models based on user feedback.

[0233] In some implementations, ML-based threat detection models can operate by collecting and analyzing network traffic metadata from a digital engineering platform's cloud network. For example, the digital engineering platform can leverage the aforementioned input characteristics to create its own classifiers and detectors. Simultaneously or substantially simultaneously, ML-based threat detection models can support advanced operating modes, such as performing a thorough analysis of the latent space or utilizing the output as input for subsequent ML-based threat detection models. This dexterity enhances the model's flexibility, usability, and security quotient. Furthermore, ML models on the platform can undergo rigorous testing to ensure they conform to industry standards.

[0234] Figure 17 shows examples of computing device 1700 and mobile computing device 1750 used to implement an implementation of this disclosure. Computing device 1700 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Mobile computing device 1750 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, VR devices, and other similar computing devices. The components, their connections and relationships, and their functions shown herein are intended to be examples only and not to be limiting. Computing device 1700 and / or mobile computing device 1750 may form at least part of the user device 106A or API 106B and computing system 108 described above. As stated above, in some implementations, computing system 108 may be a distributed computing system including multiple computing devices such as computing device 1700 and / or mobile computing device 1750. In other implementations, computing system 108 may include a single computing device. In some implementations, API 106B may be implemented on computing device 1700 and / or mobile computing device 1750 to relay digital computer files to a non-human artificial user 104B (e.g., an artificial intelligence and / or algorithmic user), and the non-human artificial user 104B may itself be implemented on computing device 1700 and / or mobile computing device 1750 (or on a separate instance of computing device 1700 and / or mobile computing device 1750).

[0235] The computing device 1700 includes a processor 1702, memory 1704, a storage device 1706, a high-speed interface 1708, and a low-speed interface 1712. In some implementations, the high-speed interface 1708 connects to memory 1704 and several high-speed expansion ports 1710. In some implementations, the low-speed interface 1712 connects to the low-speed expansion port 1714 and the storage device 1706. Each of the processor 1702, memory 1704, storage device 1706, high-speed interface 1708, high-speed expansion port 1710, and low-speed interface 1712 is interconnected using various buses and may be mounted on a common motherboard or in other ways as needed. The processor 1702 processes instructions for execution within the computing device 1700, including instructions stored in memory 1704 and / or on the storage device 1706, to display graphical information for a graphical user interface (GUI) on an external input / output device such as a display 1716 coupled to the high-speed interface 1708. In other implementations, multiple processors and / or multiple buses may be used as appropriate, along with multiple memory and multiple types of memory. In addition, multiple computing devices may be connected (for example, as a server bank, a group of blade servers, or a multiprocessor system) so that each device performs some of the necessary operations.

[0236] Memory 1704 stores information within the computing device 1700. In some implementations, memory 1704 is one or more volatile memory units. In some implementations, memory 1704 is one or more non-volatile memory units. Memory 1704 may also be another form of computer-readable storage medium, such as a magnetic or optical disk.

[0237] The storage device 1706 can provide high-capacity storage to the computing device 1700. In some implementations, the storage device 1706 is or may include a computer-readable storage medium such as a floppy disk device, a hard disk device, an optical disk device, a tape device, flash memory, or other similar solid-state memory device, or an array of devices including devices in a storage area network or other configuration. Instructions can be stored in the information carrier. When the instructions are executed by one or more processing devices such as the processor 1702, they perform one or more methods such as those described above. Instructions can also be stored in one or more storage devices such as a computer-readable storage medium or a machine-readable storage medium, such as memory 1704, the storage device 1706, or memory on the processor 1702.

[0238] The high-speed interface 1708 manages bandwidth-intensive operations related to the computing device 1700, while the low-speed interface 1712 manages less bandwidth-intensive operations. Such function allocations are merely examples. In some implementations, the high-speed interface 1708 is coupled to memory 1704, a display 1716 (e.g., through a graphics processor or accelerator), and a high-speed expansion port 1710 which may accept various expansion cards. In some implementations, the low-speed interface 1712 is coupled to the storage device 1706 and the low-speed expansion port 1714. The low-speed expansion port 1714, which may include various communication ports (e.g., Universal Serial Bus (USB), Bluetooth®, Ethernet, Wireless Ethernet), may be coupled to one or more input / output devices. Such input / output devices may include a scanner 1730, a printing device 1734, or a keyboard or mouse 1736. The input / output devices may also be coupled to the low-speed expansion port 1714 through a network adapter 1732. Such network input / output devices may include, for example, switches or routers.

[0239] The computing device 1700 may be implemented in many different forms, as shown in Figure 17. For example, the computing device 1700 may be implemented as a single standard server 1720, or multiple times within a group of such servers. Furthermore, the computing device 1700 may be implemented in a personal computer, such as a laptop computer 1722. The computing device 1700 may also be implemented as part of a rack server system 1724, a high-performance computing enclave, or a quantum and / or non-silicon-based computing system. Alternatively, the components of the computing device 1700 may be combined with other components of a mobile device, such as a mobile computing device 1750. Each of such devices may contain one or more of the computing device 1700 and the mobile computing device 1750, and the entire system may consist of multiple computing devices communicating with each other.

[0240] The mobile computing device 1750 includes, among other components, a processor 1752, memory 1764, input / output devices such as a display 1754, a communication interface 1766, and a transceiver 1768. The mobile computing device 1750 may also include a storage device, such as a microdrive or other device, to provide additional storage. Each of the processor 1752, memory 1764, display 1754, communication interface 1766, and transceiver 1768 is interconnected using various buses, and some of the components may be mounted on a common motherboard or in other ways as needed. In some implementations, the mobile computing device 1750 may include a camera device.

[0241] Processor 1752 can execute instructions within the mobile computing device 1750, including instructions stored in memory 1764. Processor 1752 may be implemented as a chipset of a chip containing multiple separate analog and digital processors. For example, processor 1752 may be a composite instruction set computer (CISC) processor, a reduced instruction set computer (RISC) processor, or a minimal instruction set computer (MISC) processor. Processor 1752 may coordinate other components of the mobile computing device 1750, such as the user interface (UI), applications run by the mobile computing device 1750, and / or control of wireless communication by the mobile computing device 1750.

[0242] The processor 1752 may communicate with the user through a control interface 1758 and a display interface 1756 coupled to the display 1754. The display 1754 may be, for example, a thin-film transistor liquid crystal display (TFT LCD), an organic light-emitting diode (OLED) display, or other suitable display technology. The display interface 1756 may include appropriate circuitry for driving the display 1754 to present graphical and other information to the user. The control interface 1758 may receive commands from the user and translate those commands for transmission to the processor 1752. In addition, an external interface 1762 may provide communication with the processor 1752 to enable near-area communication of the mobile computing device 1750 with other devices. The external interface 1762 may provide, for example, wired communication in some implementations and wireless communication in other implementations, and multiple interfaces may be used.

[0243] Memory 1764 stores information within the mobile computing device 1750. Memory 1764 may be implemented as one or more of the following: one or more computer-readable storage media, one or more volatile memory units, or one or more non-volatile memory units. Additionally, an expansion memory 1774 may be provided and connected to the mobile computing device 1750 via an expansion interface 1772, which may include, for example, a Single in Line Memory Module (SIMM) card interface. The expansion memory 1774 may provide additional storage space to the mobile computing device 1750, or it may store applications or other information of the mobile computing device 1750. In particular, the expansion memory 1774 may contain instructions that execute or supplement the processes described above, and may contain secure information. Therefore, for example, the expansion memory 1774 may be provided as a security module for the mobile computing device 1750 and may be programmed with instructions that enable the secure use of the mobile computing device 1750. Furthermore, SIMM cards may provide secure applications along with additional information, such as storing identification information on the SIMM card in a way that makes it impossible to hack.

[0244] The memory may include, for example, flash memory and / or non-volatile random-access memory (NVRAM), as considered below. In some implementations, instructions are stored on an information carrier. When an instruction is executed by one or more processing devices, such as processor 1752, it performs one or more methods, such as those described above. Instructions may be stored in one or more storage devices, such as one or more computer-readable or machine-readable storage media, such as memory 1764, extended memory 1774, or memory on processor 1752. In some implementations, instructions may be received as propagated signals, such as via transceiver 1768 or external interface 1762.

[0245] The mobile computing device 1750 may communicate wirelessly through a communication interface 1766, which may include digital signal processing circuitry as needed. The communication interface 1766 may provide communication under various modes or protocols, such as Global System for Mobile communications (GSM) voice calls, Short Message Service (SMS), Enhanced Messaging Service (EMS), Multimedia Messaging Service (MMS) messaging, Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Personal Digital Cellular (PDC), Wideband Code Division Multiple Access (WCDMA)®, CDMA2000, or General-Purpose Packet Radio Service (GPRS). Such communication may be conducted, for example, through a transceiver 1768 using radio frequencies. Furthermore, short-range communication may be conducted, such as using Bluetooth or Wi-Fi. In addition, the Global Positioning System (GPS) receiver module 1770 may provide the mobile computing device 1750 with further navigation and location-related wireless data that may be used as appropriate by applications running on the mobile computing device 1750.

[0246] The mobile computing device 1750 may also communicate via voice using an audio codec 1760 that can receive information spoken by the user and convert that information into usable digital information. Similarly, the audio codec 1760 may generate audible audio for the user, for example, through a speaker (on the handset of the mobile computing device 1750). Such audio may include voice from a voice call, recorded audio (e.g., voice messages, music files, etc.), or audio generated by an application running on the mobile computing device 1750.

[0247] The mobile computing device 1750 may be implemented in many different forms, as shown in Figure 17. For example, the mobile computing device 1750 may be implemented as a telephone device 1780, a personal digital assistant 1782, and / or a tablet device (not shown). The mobile computing device 1750 may also be implemented as a component of a smartphone, an augmented reality (AR) device, or other similar mobile device.

[0248] Computing devices 1700 and / or 1750 may also include a USB flash drive. The USB flash drive may store the operating system and other applications. The USB flash drive may include input / output components such as a wireless transmitter or a USB connector that may be inserted into a USB port of another computing device.

[0249] Other embodiments and applications not specifically described herein are also within the scope of the appended claims. Elements of different implementations described herein may be combined to form other embodiments. [Explanation of symbols]

[0250] 100 Interconnected Digital Engineering and Certification Ecosystems 102 Digital Engineering Tools 102A Data Analysis Tool 102B CAD and Finite Element Analysis Tools 102C Simulation Tool 102D~102E Chemical M&S Tools 102F~102G Manufacturing M&S Tools 104 users 104A Human user 104B Artificial User 106A User Device 106B API (or other similar machine-to-machine communication interface) 108 Computing systems, computer systems 110 Common V&V Products Regulatory standards related to the development and certification of 110A-110F UAVs 110G Medical Standard 110H Medical Certification Regulations 110I Manufacturing Standard 110J Manufacturing Certification Regulations 112, 112A~112C Digitally Certified Products 114 API / SDK 116 APIs / SDKs 118 Data Storage Units 120 Machine Learning Engines 122 Application and Service Layer 200 Digital Product Development and Certification Workflows 300 Series of Exemplary Displays 302 display 304 display 306 display 308 displays 310 displays 400 flowchart 402 The Physical World 404 Transfer Function Models and Tools 406 The Digital World 408 Digital Product Development 410 Digital Product Testing 412 Digital Product Certification 414 Finalized Digital Product Design 416 Manufacturing 418 Final products in the physical world 500A Monetization Opportunities 500B monetization opportunity 500C Monetization Opportunities 500D Monetization Opportunities 600 processes 700 Digital Engineering and Certification Ecosystem 702 users 704 Endpoint, User Device 706 Digital Engineering Platform 708 Private Model Storage 710 Platform Agent 800 Digital Engineering and Certification Ecosystem 802 users 804 Interconnected Digital Engineering Platform 806 UX / UI Components 808 Model Trumpet, Model and Function Trumpet 809 Customer computing environment, customer network environment 810 Agent 812 models, customer models 900 Digital Engineering and Certification Ecosystem 902 users 904 Interconnected Digital Engineering Platform 908 Model and Function Trumpet 909 Customer Owner's Environment 910 Agent 912 Model 1000 Digital Engineering and Certification Ecosystems 1002 users 1004 Interconnected Digital Engineering Platform 1006 UX / UI Component 1008 Model and Function Wrapper 1009 Customer Owner's Environment 1010 Agent 1012 Model, Model Storage 1014 Forked Model 1100 Digital Engineering and Authentication Ecosystem 1200 Digital Engineering and Authentication Ecosystem 1300 Process 1400 Process 1501 Flowchart, Process 1502 Flowchart, Process 1600 System 1602 User 1604 Interconnected Digital Engineering Platform 1606 UX / UI Component 1608 Model and Function Wrapper 1609 Customer's Network Environment 1610 Agent 1612-1 Protected Model 1612-2 Protected Model 1700 Computing Device 1702 Processor 1704 Memory 1706 Storage Device 1708 High-Speed Interface 1710 High-Speed Expansion Port 1712 Low-Speed Interface 1714 Low-Speed Expansion Port 1716 Display 1720 Server 1722 Laptop Computer 1724 Rack Server System 1730 Scanner 1732 Network Adapter 1734 Printing Devices 1736 Keyboard or Mouse 1750 Mobile Computing Devices 1752 processors 1754 Display 1756 Display Interface 1758 Control Interface 1760 audio codecs 1762 External Interface 1764 memory 1766 Communication Interface 1768 Transceiver 1770 GPS Receiver Module 1772 Expansion Interface 1774 Expansion Memory 1780 Phone Devices 1782 Mobile Information Terminal 1800 Digital Engineering Platform 1802 DE Platform Enclave 1804 Cloud Services 1806 Customer 1810 Customer environment 1812 Reliable and authoritative sources 1814 Customer Tools 1816 DE Platform Exclav

Claims

1. The steps include: receiving a user request via a user device through a digital platform to access one or more digital models; The steps include determining whether the user of the user device is authorized to access the one or more digital models by the digital platform, Steps of generating a transaction request to be sent by the digital platform to the location indicated in the user request of the one or more digital models, in response to a decision that the user is authorized to access the one or more digital models, the transaction request includes data specifying one or more actions to be performed using the one or more digital models; The steps include: sending the generated transaction request to the location of the one or more digital models via the digital platform, which causes the user device to perform one or more actions using the one or more digital models requested by the user device; The steps include: receiving data representing the results of one or more operations performed using one or more digital models via the digital platform; The steps include providing the user interface of the user device with the digital platform the data representing the results of one or more operations performed using the one or more digital models, The digital platform includes the steps of auditing the data related to the transaction request and the data representing the results of one or more operations performed using the digital model. A method performed by a computer, including the above.

2. The method performed by a computer according to claim 1, wherein the step of sending the generated transaction request to the location of the one or more digital models by the digital platform includes sending the generated transaction request to a cloud network by the digital platform, causing the execution of the one or more actions using the one or more digital models requested by the user device.

3. The method performed by a computer according to claim 1, wherein the step of transmitting the generated transaction request to the location of the one or more digital models by the digital platform includes transmitting the generated transaction request by the digital platform to a digital agent causing the digital agent to perform the one or more operations using the one or more digital models requested by the user device.

4. The steps include: storing one or more digital tools in a tool database using the digital agent, wherein the one or more digital tools include model-based systems engineering (MBSE) tools, augmented reality (AR) tools, computer-aided design (CAD) tools, data analysis tools, modeling and simulation (M&S) tools, and product lifecycle management (PLM) tools; A step of storing one or more digital models, wherein the one or more digital models include a simulation engine, a requirements model, an electronics model, a test plan model, a cost model, a schedule model, a software model, a supply chain model, a manufacturing model, a cybersecurity model, a multi-attribute trade space tool, and a mission effectiveness model. A computer-based method according to claim 3, further comprising:

5. The method implemented by a computer according to claim 3, wherein the digital platform and the digital agent communicate bidirectionally through one or more firewalls.

6. A method performed by a computer according to claim 5, wherein sending a generated transaction request causing the digital agent to perform one or more operations using the one or more digital models requested by the user device includes sending a generated transaction request causing the digital agent to copy the one or more digital models and then perform a write action on the copied version of the one or more digital models without modifying the original version of the one or more digital models.

7. A computer-based method according to claim 1, wherein one or more operations performed using the one or more digital models include at least one of reading data from the one or more digital models, writing data to the one or more digital models, accessing one or more digital artifacts from the one or more digital models, or accessing the one or more digital models.

8. The step of determining whether the user is authorized to access the one or more digital models is: The digital platform obtains one or more user credentials using the user device before receiving the user request to access one or more digital models, A computer-based method according to claim 1, comprising determining that the user is authenticated to access the digital platform based on one or more acquired credentials and permission models.

9. The steps include determining the type of one or more operations to be performed on the one or more digital models using the digital platform, Depending on the determination of the type of one or more operations to be performed on the one or more digital models, the digital platform sends the generated transaction request to the location of the one or more digital models. The steps include receiving a splicer that enables access to one or more functions of the one or more digital models via the digital platform, The steps include: providing the received splicer to the user interface of the user device via the digital platform for user interaction to one or more functions of the one or more digital models; A computer-based method according to claim 1, further comprising:

10. The method, carried out by a computer according to claim 9, wherein the received splicer is configured to restrict user access to a subset of the functions of the one or more digital models.

11. The method performed by a computer according to claim 9, wherein the received splicer is configured to edit a portion of one or more digital models.

12. The method implemented by a computer according to claim 9, wherein the received splicer is configured to protect a subset of the functions of the one or more digital models on the user device.

13. From the received user request, the digital platform extracts data that identifies one or more digital models that the user intends to access. The digital platform performs the steps of retrieving the location of one or more digital models based on the data extracted from the received user request. A computer-based method according to claim 1, further comprising:

14. The method performed by a computer according to claim 1, further comprising the step of determining that the user is authorized to access the digital platform before the digital platform receives the user request to access the one or more digital models.

15. The method performed by a computer according to claim 1, wherein the step of providing the data representing the results of one or more operations performed using the one or more digital models includes providing the user interface of the user device, by the digital platform, at least one of the one or more digital models, copies of the one or more digital models, or a wrapper to the one or more digital models, for the user to review.

16. The step of auditing the aforementioned data is, The digital platform stores the data related to the transaction request and the data representing the results of one or more operations performed using the digital model. The digital platform audits the stored data with respect to at least one of the following: security breaches, data quality management, or improvements to one or more operations performed using the digital model. A computer-based method according to claim 1, further comprising:

17. It is a system, The system includes one or more computers and one or more storage devices that store instructions that, when executed by the one or more computers, are operable to cause the one or more computers to perform the following operations: The aforementioned operation, Receiving user requests to access one or more digital models via a digital platform through a user device. The digital platform determines whether the user of the user device is authorized to access one or more digital models. In response to a decision that the user is authorized to access the one or more digital models, the digital platform generates a transaction request to send to the location indicated in the user request for the one or more digital models, wherein the transaction request includes data specifying one or more actions to be performed using the one or more digital models. The digital platform transmits the generated transaction request to the location of the one or more digital models, causing the user device to perform one or more actions using the one or more digital models requested by the user device. The digital platform receives data representing the results of one or more operations performed using one or more digital models. The digital platform provides the user interface of the user device with the data representing the results of the one or more operations performed using the one or more digital models, and The digital platform audits the data related to the transaction request and the data representing the results of one or more operations performed using the digital model. A system that includes this.

18. The system according to claim 17, wherein the digital platform transmits the generated transaction request to the location of the one or more digital models, and the digital platform transmits the generated transaction request to a cloud network, causing the execution of the one or more actions using the one or more digital models requested by the user device.

19. The system according to claim 17, wherein the digital platform transmits the generated transaction request to the location of the one or more digital models, and the digital platform transmits the generated transaction request to a digital agent, causing the digital agent to perform the one or more operations using the one or more digital models requested by the user device.

20. A non-temporary computer-readable storage medium for storing software that includes instructions executable by one or more computers, wherein when the instructions are executed, the software is stored in the one or more computers. Receiving user requests to access one or more digital models via a digital platform through a user device. The digital platform determines whether the user of the user device is authorized to access one or more digital models. In response to a decision that the user is authorized to access the one or more digital models, the digital platform generates a transaction request to send to the location indicated in the user request for the one or more digital models, wherein the transaction request includes data specifying one or more actions to be performed using the one or more digital models. The digital platform transmits the generated transaction request to the location of the one or more digital models, causing the user device to perform one or more actions using the one or more digital models requested by the user device. The digital platform receives data representing the results of one or more operations performed using one or more digital models. The digital platform provides the user interface of the user device with the data representing the results of the one or more operations performed using the one or more digital models, and The digital platform audits the data related to the transaction request and the data representing the results of one or more operations performed using the digital model. A non-temporary computer-readable storage medium that enables the execution of operations including [specific actions].

Images