The DAF Digital Transformation Office (DTO) is working to provide recommended model-based contract language based on a program’s digital strategy to our program offices. Some initial work has been done and is explained below.
In the left column are files that include briefing slides that explains a recommended process for programs to use the digital features based on their digital strategy. Also included is a “read first” and “FAQs” file to help programs start, and finally the latest key feature MS Excel spreadsheet to use in the process. Also included is a DTO produced video that explains the process using the briefing slides. In the left column is a table with the digital features listed with descriptions.
Below is the table of Key Digital Features and their descriptions that a program should consider as factors for a contract effort. This table is also in the MS Excel spreadsheet after the table with more explanation to use.
The digital enterprise is the computing environment that enables DE tools and processes to design, develop, test, verify, validate, and certify the system. A digital enterprise may consist of multiple environments all of which operate at the necessary security levels. The digital enterprise will be a combination of contractor and Government environments that contain the appropriate system access, licensure, roles, and permissions.
Model Based Systems Engineering (MBSE), Product Lifecycle Management (PLM), physics-based, Model Based Definition (MBD) and Other Models should have bi-directional traceability. Traceability up/down the authoritative source(s) of truth (ASOT) data (e.g., mission needs, operations, capabilities, CONOPS, operational concepts, system requirements, design, product, test, with programmatic and resource relationships) that traces, links and ties the MBSE, PLM, physics, MBD and Other models.
MBSE, physics-based, MBD, other models, and supportability data should be interfaced with a PLM system to support program management, CM, effectivity management, BOM management, workflows, etc. The level of integration in either the Government or contractor environment is dependent on program specific requirements.
The program-specific MBSE model should encompass applicable Government reference architectures and models (if available). The program-specific MBSE model should include all user and program office requirements as well as all known interfaces. The program-specific MBSE model can either be created by the Government or contractor depending on the needs of the program. The program-specific MBSE model should define hardware/software/firmware requirements, analysis of requirements, system architecture design, interfaces, failure modes effects analysis/failure modes effects criticality analysis, hazard tracking/analysis, certifications, integrity program compliance, functional thread analysis, (to include Safety Critical Functional Thread Analysis (SCFTA)) and associated allocations.
Integrated business operations has elements of a Digital representation supporting financial analysis and decision support that includes Earned Value Management (EVM), cost, risk and schedule analysis as deemed necessary by program leadership. Assessments based on baseline program schedule, subsystem development and integration relationship and estimated value over time. Decision analytics should be supported by data modules to ensure the program is meeting cost, schedule, and performance requirements.
The Government establishes and uses a Digital Reference Library to manage its models and model artifacts. Acquisition programs select specific contents for use by potential bidders to provide proposals in response to an RFP.
Model access is the ability to copy, read, edit, use, or download contractor models for analysis, review, and/or acceptance. Intent is timely insight into and usage of MBSE, PLM, physics-based, MBD, and other models prior to / outside of delivery of any data or actual models including the Software Development Environment. Model access doesn’t normally include that ability to modify models unless specified as a contract requirement. User roles should be defined and managed. Multiple use methods/feature choices are possible.
Digital Twins are models that provide a representation of the system, sub-system, or product at a sufficient level of fidelity to meet organizational objectives. These digital twins uses the best available data, models, sensor information, and input data to mirror and predict activities and/or performance over the life of its corresponding physical twin. Sometimes we us the term partial digital twin to recognize the fact integrated multi-physics, multiscale, probabilistic simulation of an entire weapon system is very difficult to achieve. Note: Before physical asset exists, digital twin is a “model.”
ASOT is the authoritative/definitive technical data and associated digital artifacts shared across all IPT members and functions. Ideally implemented within a digital system model. Includes Gov’t artifacts not necessarily created by contractor. The ASOT enables “delivery” of the right data to the right person for the right use at the right time. The ASOT is both configuration and data managed.
Assess maturity of Digital Engineering (DE) Implementation on the program at regular intervals, and set program goals to improve by each milestone. [Using metrics available on AF Digital Guide.] Secondly, include any metrics that would benefit the program by being implemented within a program’s digital ecosystem. Example: Dashboard linked to DE data vs. monthly status reports delivered.
Models that are needed to define performance characteristics; math and physical models and algorithms. These models can often be considered partial digital twins.
System verification, validation, certification, and accreditation requirements should be managed within the Program-specific MBSE system model or requirements management system. System verification, validation, certification, and accreditation data/artifacts should be contained within the digital environment and routed through a PLM workflow. The level of VVC&A depends on the types and criticality of decisions to be made. It is recommended to use models for preliminary phases of VVC&A with the final release using real-world testing to verify/validate the models.
The MBD contains an integrated view of the entire system (a.k.a. “fly through”) to show design maturity and ensure consistent communication between different designers. The MBD should contain fully annotated 3D digital models of the system including dimensions, tolerances, materials, finishes and other notes to specify a complete product definition.
This feature provides additional approaches complementing existing statute and regulation for negotiation of data rights (Unlimited, limited, Government Purpose Rights, Specially Negotiated Rights). Refer to AF Data Rights Guidebook for additional information on how to require, acquire, and manage technical data in a digital acquisition program. Intellectual Property Identification is applicable to MBSE, PLM, physics-based, MBD and other models developed by contractors.
Model Data Delivery defines the format and availability of the data from the model to either provide deliveries against CDRL/DID requirements and/or the capability to produce digital views from model viewpoints to provide user information. CDRLs/DIDs specify format, views, and review/audit event information; views and delivered data permit digital acceptance. Model Data Delivery includes delivery of the MBSE, PLM, physics-based, MBD or Other models and associated model scripts.
Model Configuration items are connected model elements that provide information to identify functional, allocated, and product baselines. Model Configuration Items (CIs) have attributes of performance measures such as Key Performance Indicators (KPIs) or Technical Performance Measurements (TPMs); they identify digital twins or digital threads; and they identify intellectual property interfaces as well as security marking. Model CIs are trackable connected model elements under configuration management control.
Models and the authoritative source(s) of truth are configuration managed as Model Configuration Items. Model Configuration Items are trackable connected model elements under configuration management control and may make up a functional, allocated, and product baseline. Model-based baseline management is performed as specified within the program CDRLs /DIDs.
Model Portfolio Management is an activity to manage a collection of MBSE, PLM, physics-based, MBD or Other models. Model Portfolio Management may include both Government and Contractor Models, governance, model construction, model repositories, model re-use, and model developments. Model Portfolio Management is not model configuration management of specific models.
An MBSE model should be developed in a consistent manner with reference architectures, models and style guides. A system model maintenance strategy needs to be considered up front. Model construction specifies the model language, ontologies (mid-level, reference, or domain), tool versions, organizational practices, and Application Programming Interfaces (APIs). Appropriate compliance and reference standards should be identified.
Model Based Reviews and Audits use the models to generate information against the review and audit criteria. This will depend on the Government placing a reference document such as ISO/IEC/IEEE 15288.2 on contract to identify the information the model needs to generate to complete the review and audit events. The Government may tailor the reference standard to focus on what is most important and to also ensure that compliance is achievable with unambiguous requirements. Model-based reviews and audits may lend themselves to continuous design review rather than milestone based design reviews — this should be considered when tailoring review and audit requirements.