Attachment_0091_Digital_System_Model_Rev003.docx

Attachment 0091 Digital System Model Revision No.: 003 Solicitation No.: W56HZV-22-R-0026 Date: 15 Aug 2022

Distribution Statement A: Approved for public release; distribution is unlimited (PENDING OPSEC REVIEW)

Attachment 0091 - Digital System Model Rev003 Solicitation No.: W56HZV-22-R-0026

b. Updates to Tables 1-3 in sections 3.3.5.1 for correctness and consistency with RFP

b. Updates to section 3.3.5 to refer to the CDRL Architecture Model (Attachment 0067) as a guide as opposed to a requirement

c. Added note to section 3.3.5 to clarify that both SysML 1.x and UML 2.x are acceptable modeling languages for the system architecture model.

d. CDRL E011 deleted from Table 1 in section 3.3.5. This was originally included in Table 1 in error.

e. Modified section 3.3.2.9 as follows to capture actual information needed for authoritative data sources.

WAS: “Authoritative data source(s) with certification plan” IS: “List of authoritative data sources, to include:

· Authoritative data source usage

· Authoritative data source pedigree

· Justification for selection of specific authoritative”

b. Update to section 3.9.2.7 to reflect Design Failure Modes and Effects Analysis and Criticality Analysis (DFMEA/CA).

Use/relationship: The Digital System Model provides a consistent and cohesive representation of the system. It includes digitally traceable interrelationships between data and information grounded in an authoritative source of truth.

a. The model contains metadata. The metadata describes the organization, elements, and views in a model. Packages and internal data structure are elements in a model. Representations are the types of elements used and shown in views. Supporting analysis is represented by the organization, certain element types, and views

b. This attachment contains the format, content, and intended use for the data product resulting from the work task described in the contract Statement of Work (SoW).

Requirements:

1. Reference documents. The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as specified in the contract.

2. Format. The Digital System Model shall be delivered in the native file format(s) of the modeling tool(s) or developed directly in the Integrated Digital Engineering Environment (IDEE) as identified in the Contractor’s Digital Engineering Management Plan. The Digital System Model shall include documentation regarding necessary software tool(s) configurations, access types (e.g., read-only or write access), dashboards, views, data integrations, data flows, reporting mechanisms outside of dashboards (e.g., report building tools), security, size, and configuration management details.

3. Contents. The Digital System Model shall be organized into the following sections:

3.1. Scope. This section shall be divided into the following sub-sections:

3.1.1. Identification. This sub-section shall fully define the system and elements to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

3.1.2. System overview. This sub-section shall state the purpose of the system to which this document applies. It shall describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other related documents.

3.1.3. Document overview. This sub-section shall summarize the purpose and contents of the Digital System Model and shall describe any security or privacy considerations associated with its use.

3.2. Referenced documents. This section shall list the number, title, revision, and date of all documents referenced in the Digital System Model.

3.3. Model Overview. This section shall contain the following:

3.3.1. Design assumptions and design decisions about the model.

3.3.1.1. Assumptions and decisions about requirements.

3.3.1.2. Assumptions and decisions about verification and validation.

3.3.1.3. Assumptions and decisions about architecture.

3.3.1.4. Assumptions and decisions about use cases.

3.3.1.5. Assumptions and decisions about the structural aspects of the model.

3.3.1.6. Assumptions and decisions about behavioral aspects of the model.

3.3.1.7. Assumptions and decisions about the model infrastructure including tool interfaces and data flows.

3.3.1.8. Assumptions and decisions about model integration requirements.

3.3.1.9. Assumptions and decisions about functional, allocated, and product baselines.

3.3.2. Model infrastructure. This sub-section shall contain the following:

3.3.2.1. Modeling language(s) and version(s).

3.3.2.2. Incorporated profiles.

3.3.2.3. Model and data repositories.

3.3.2.4. External dependencies.

3.3.2.5. Data integration and digital thread with external tools, data flows, data dictionaries, databases, and other repositories to maintain data consistency.

3.3.2.6. Interfaces (internally or externally) with external software, such as Requirements Management Tools; Product Lifecycle Management tools; reliability, availability, maintainability, and testability tools and databases; risk, issue, and opportunity tools and databases; and/or Model Based Simulation & Analysis (MBS&A) tools.

3.3.2.7. Means of synchronization between the model and the implementation.

3.3.2.8. Dashboards and/or visualizations to interrogate or visualize the model.

3.3.2.9. List of authoritative data sources, to include:

· Authoritative data source usage

· Authoritative data source pedigree

· Justification for selection of specific authoritative

3.3.2.10. Associated descriptions of Tools, Add-ins, Dictionaries, Software, and Applications used to develop, maintain, update the model(s) to details on any installation, customization, or configuration requirements (e.g., compute, hardware needs, memory, networking, cyber, training, etc.)

3.3.3. Model Development Methodology. This sub-section shall contain the following:

3.3.3.1. The model development plan including:

3.3.3.1.1. Model requirements formulation.

3.3.3.1.2. Model development process.

3.3.3.1.3. Model documentation and release schedule.

3.3.3.1.4. Discrepancy reporting and tracking.

3.3.3.1.5. Facility or facilities (if multiple locations) where the model will be developed.

3.3.3.1.6. Enforcement of proprietary restrictions.

3.3.3.1.7. Conformance with Government cybersecurity and classified system requirements.

3.3.3.1.8. User training and documentation.

3.3.3.2. Tool set and development environment, including all information needed for the Government to independently reproduce the development, verification, validation, configuration management, and test environment.

3.3.3.3. Model style guidelines shall cover the following:

· Naming.

· Properties and attributes.

· Ports.

· Interface definitions including Data Dictionaries, Data Flows, and Meta-data Tagging.

· Operations.

· Receptions.

· Parts.

· Documentation standards.

· Design patterns for structural and behavioral modeling.

· Inheritance including:

· Specialized classes having attributes or operations that are not in the parent class.

· Limitations on the number of inheritance levels and multiple inheritance.

· Avoiding cyclic inheritance relationships.

· Use and limitations on use of redefines.

· Use of multiplicities Use of flows and flow properties.

3.3.3.4. Methodology to evaluate and optimize modularity and extensibility (e.g., use of interfaces and boundary blocks or classes).

3.3.3.5. Methodology to evaluate and optimize abstractions and encapsulation to minimize dependencies on the internals of elements.

3.3.3.6. Verification, validation, and testing methods.

3.3.3.7. Configuration management methods and tools.

3.3.3.8. Programmatic methods and tools, such as cost, schedule, and risk information linked to the technical aspects of the model.

3.3.4. Model Organization. This sub-section shall contain the following:

3.3.4.1. Package diagrams that capture and describe the model organization.

3.3.4.2. Organization rationale (e.g. by diagram type, by hierarchy, or by Integrated Product Team.)

3.3.4.3. Description of model navigation and views that depict model organization.

3.3.4.4. Description and purpose for model diagrams, elements, and output including all external referenced models.

3.3.5. CDRL Data Model Views. This sub-section shall contain the model views that capture and communicate CDRL data for each CDRL included in Tables 1-3. The CDRL Architecture Model (Attachment 0067) may be used as a guide for developing model views and viewpoints for each CDRL in the SysML System Architecture Model (CDRL E041).

The timing of the CDRL data delivery via the System Architecture Model (CDRL E041) shall align with the technical baseline requirements IAW EIA-649-1A and the design review checklist criteria (Attachment 0021).

The formal (final, document-based) delivery of each CDRL listed in Table 1-3 shall be IAW the OFMV contract. The CDRL data being communicated via the system model does not supersede the CDRL data requirements specified in the contract. The model views of CDRL data is intended to provide the USG access to CDRL data in addition to the traditional document-based CDRL deliverables per the RFP SOW and CDRL list.

The following tables in section 3.3.5.1 include the list of CDRLs from the RFP SOW that are associated with the Contractor System Architecture Model (CDRL E041). The CDRLs are split into three tables based on their level of CDRL data scope and data development and delivery via the Contractor System Architecture Model (CDRL E041). The expectations for all CDRLs listed in Tables 1-3 is that some level of CDRL data is to be delivered via the SysML model for awareness and insight into the deliverable data as it is developed and matures, reducing the number of formal (document-based) CDRL deliveries.

The Contractor may refer to the CDRL Architecture Model (Attachment 0067) as guidance in determining which CDRL data is to be communicated via SysML and how that data can be presented. Given that the CDRL Architecture Model is to be used as a guide, it is the Contractor’s responsibility to determine the actual SysML CDRL views and viewpoints to communicate the CDRL content via the system architecture model.

Note: While the system architecture model will be largely based on SysML 1.x, UML 2.x may be used for applicable software modeling.

3.3.5.1. System Architecture Model CDRLs

The System Architecture Model (E041) CDRLs are categorized as follows:

Table 1: All data within these CDRLs are expected to be fully developed and delivered via the System Architecture Model (E041) IAW their respective DIDs and the CDRL requirements per the RFP SOW. The CDRL Architecture Model (Attachment 0067) may also be used as a guide. The CDRL Architecture Model (Attachment 0067) will provide guidance on which working/draft data within each CDRLs can be delivered via the SysML model on a regular basis, how that data can be communicated via the SysML model (potential views and viewpoints), and how certain data might relate to the technical baselines defined in EIA-649-1A.

Table 1 - Full SysML Model CDRLs

Table 2: Table 2 includes the list of CDRLs in which parts of the CDRL data may be developed and managed outside of the SysML model; however, initial deliveries of the CDRL data need to be represented and made available to the USG via the SysML Model (E041). The CDRL Architecture Model (Attachment 0067) may also be used as a guide. The CDRL Architecture Model (Attachment 0067) will provide guidance on which working/draft data within each CDRLs can be delivered via the SysML model on a regular basis, how that data can be communicated via the SysML model (potential views and viewpoints), and how certain data might relate to the technical baselines defined in EIA-649-1A. The RFP SOW and CDRL list indicate the delivery requirements for each CDRL outside of the SysML model (i.e. traditional document-based CDRL deliveries).

Table 2 - Partial SysML Model CDRLs

Attachment 0088

Table 3: The CDRLs in Table 3 are expected to be mostly, or fully developed and managed outside of the SysML model; however, there is some level of reference in or traceability to the SysML model. Examples include outputs from tests and analyses tagged to model elements, reference to object IDs of data within other tools, etc. The CDRL Architecture Model (Attachment 0067) may also be used as a guide. The CDRL Architecture Model (Attachment 0067) will provide guidance on which CDRL reference data can be delivered via the SysML model on a regular basis, how that data can be communicated via the SysML model (potential views and viewpoints), and how certain data might relate to the technical baselines defined in EIA-649-1A. The RFP SOW and CDRL list indicate the delivery requirements for each CDRL outside of the SysML model (i.e. traditional document-based CDRL deliveries).

Table 3 - Referenced/Traced SysML Model CDRLs

3.4. Modeling of System Requirements. This section shall be divided into the following sub-sections:

3.4.1. Requirements completeness. This sub-section shall describe how inclusion of all requirements from the technical baseline is ensured.

3.4.2. Requirements rationale. This sub-section shall describe the rationale for all requirements.

3.4.3. Requirements satisfaction and validation. This sub-section shall link model elements to the system requirements.

3.4.3.1. Link all requirements to the model element or elements representing the system element or elements designed to satisfy each requirement.

3.4.3.2. Link each system requirement to diagrams and model elements used to validate linked requirements.

3.4.4. Requirements relationships. This sub-section describes relationships among requirements (e.g. contain, derive, refine, copy), between requirements and test cases (e.g. verify), between requirements and system behavior, interface, and structural elements in the architecture model, and between requirements and other model elements (e.g. performance analysis models).

3.4.5. Government-provided profiles. This sub-section shall detail the use of Government provided profiles applied to requirements.

3.4.6. Annotations. This sub-section shall specify annotations by hierarchical level.

3.4.7. Requirements tables. This sub-section shall include all tables showing the relationship of any set of requirements to any other set of requirements, test cases, or model elements.

3.4.7.1. Requirements Verification Plans. This sub-section shall include the planned requirement verification activities for each OMFV platform (PSPEC) and SSS requirement, including but not limited to the planned:

· Verification Method(s) (i.e. examination, analysis, demonstration, test)

· Verification Activity(s) (i.e. type of analysis, type of test)

· Verification Activity Timeline(s)

· Verification Activity Relationships (i.e. if multiple verification activities are planned, such as analysis and test, when is the analysis taking place and how is it supporting the test)

· Verification Location of verification event (if applicable; i.e. test location)

· Verification Success Criteria (i.e. analysis and test thresholds and parameters)

· Required Verification Resources and Support Equipment

· Expected Verification Artifact(s) (i.e. EMI Test Report, Qualification Test Report, Thermal Analysis, Electrical Loads Analysis, Electrical Schematic, CAD, etc.)

3.4.7.2. Requirements Verification Results. This sub-section shall include the actual requirement verification activities and results for each OMFV platform (PSPEC) and SSS requirement, including but not limited to:

· Actual verification method(s) performed

· Deviations from planned verification method(s) with rationale

· Results of verification activity

· Problems, impacts, and corrective actions associated with issues during verification

· Link to latest verification results (including test results) within the model as results become available

· Requirement compliance status

· Reference to final verification artifact:

· Document title

· Document number

· Document Revision

· Location of or link to verification artifact within the IDE

3.5. Use Cases. This section shall contain the following:

· Description of uses cases that capture mission objectives and requirements.

· Description of use cases that capture system operations.

· Description of use cases that describe error conditions and alternatives.

· The tracing of use cases to requirements.

· The tracing of actors, including inanimate systems, to other model elements.

3.6. Structural Diagrams. This section shall contain the following:

3.6.1. Diagrams:

3.6.1.1. Domain and context diagrams to identify what is external to the system and the high level Input/Output interactions, and to establish the system boundary.

3.6.1.2. System architecture diagrams, such as a top level Internal Block Diagrams (IBD), or equivalent to show the logical components and their I/O interactions.

3.6.1.3. Diagrams, such as Block Definition Diagrams (BDDs) and IBDs, which show subsystem decomposition and the relationship between components.

3.6.1.4. Logical architecture diagrams, such as BDDs and IBDs, which show the relationships of system functions to requirements.

3.6.1.5. Physical architecture diagrams, such as BDDs and IBDs, which allocate the logical components to physical components that are implemented in hardware, software, data, and procedure.

3.6.1.6. Parametric diagrams to support engineering analysis in support of a functional, allocated, and product baseline (e.g., performance, reliability, availability, power, and other required engineering disciplines)

3.6.1.7. Categorization and grouping methods (e.g. stereotypes) to categorize and group types of components.

3.6.2. Interfaces:

3.6.2.1. Description of all system and human interfaces, each defined as an interface block with a reference and hyperlink to the interface specifications.

3.6.2.2. Description of all operations and receptions within interfaces, with pre- conditions, post-conditions, and exceptions, if applicable.

3.6.2.3. Naming convention for interfaces.

3.6.2.4. Description of all stereotypes and profiles for interfaces.

3.6.3. Blocks and Classes:

3.6.3.1. Description of all definitions, including the purpose, roles, and responsibilities.

3.6.3.2. Description of the use of all blocks and classes in behavioral diagram and structural diagrams.

3.6.3.3. Description of naming conventions for blocks and classes.

3.6.3.4. Description of all properties and attributes and typing.

3.6.3.5. Description of all operations, including purpose, description, pre- conditions, post-conditions, exceptions, parameters, and return values.

3.6.3.6. List of all application of profiles and stereotypes.

3.6.3.7. List of all boundary classes that communicate with externals (e.g. external systems, external hardware, or externally developed software).

3.6.4. Relationships on Block Definition Diagrams:

3.6.4.1. Description of structural and non-structural relationships between classes and blocks.

3.6.4.2. Naming conventions for relationships.

3.6.4.3. Justification for any class or block with no relationships to model elements.

3.6.5. Connectors on Internal Block Diagrams:

3.6.5.1. Naming conventions for connectors.

3.6.5.2. List and description of flow of inputs and outputs between parts.

3.6.5.3. List and description of invocation of operations on parts.

3.6.5.4. List and description of sending and receiving signals between parts.

3.6.5.5. List and description of flow properties (at least type and direction).

3.7. Behavioral Content. This section shall contain the following:

3.7.1. Behavioral Content Requirements:

3.7.1.1. Methods for capturing system behavior.

3.7.1.2. Identification of what behaviors are not captured.

3.7.1.3. Description of pre-conditions, post conditions, alternatives, and error conditions.

3.7.1.4. Description of interactions at each level of the system hierarchy. Interactions include within the system and inputs/outputs to the system including external interfaces and human interactions.

3.7.1.5. Identification of state-based behavior for all blocks and classes (e.g. control classes).

3.7.1.6. Identification of design assumptions or design decisions about dynamic views.

3.7.2. Activity Diagrams:

3.7.2.1. Name and purpose of each activity diagram.

3.7.2.2. Mapping of classes and blocks in class and block definitions from the static model to behavior diagrams.

3.7.2.3. Mapping of activity and sequence diagrams to use cases.

3.7.2.4. Naming conventions on actions, data, and control flows.

3.7.2.5. Description of interactions involved in error conditions and alternative paths in scenarios. Interactions include within the system and inputs/outputs to the system including external interfaces and human interactions.

3.7.3. Sequence Diagrams:

3.7.3.1. Name and purpose of each sequence diagram.

3.7.3.2. Naming conventions for messages and sequence fragments.

3.7.3.3. Identification of data, data type, format, and communication type (e.g. synchronous, asynchronous) for all message flows.

3.7.3.4. Mapping of blocks and classes to lifelines.

3.7.4. State Machine Diagram Requirements:

3.7.4.1. Name and purpose of each state machine diagram.

3.7.4.2. Mapping of structural elements to state machine diagrams.

3.7.4.3. Mapping of state charts to other behavior diagrams.

3.7.4.4. Naming conventions for states, triggers, events, and actions.

3.7.4.5. Identification of state charts that address error conditions and alternative paths.

3.8. Model Data. This section shall contain the following:

· Description of the data in the model.

· Description of the data governance including data protection and access control requirements in the model.

· Description of data types for all attributes and properties.

· Description of meta-data and data tagging attributes.

· Naming conventions for names of parent and child entities and for names of mapping entities.

· A glossary with a list of all model elements.

3.9. Non-Functional Requirements. This section shall contain the following:

3.9.1. Performance Modeling:

3.9.1.1. Identification of all parameters and data necessary, including environmental factors, to analyze and calculate response time, capacity, and schedulability at any architectural level.

3.9.1.2. A description of how parameters and data are exported to performance analysis tools and simulations and how results are imported back into the model.

3.9.1.3. A description of how parameters and data are imported from the results of external analyses.

3.9.1.4. A description of how performance and data parameters are rolled-up from components, to systems/sub-systems, to the vehicle level to show the status of key system attributes (i.e. power, weight, reliability, etc.)

3.9.1.5. A description of the software used to execute performance modeling.

3.9.1.6. A description of how the performance models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.1.7. A description of how the performance models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.1.8. Cross-references between all analyses and associated data for each parameter within the model.

3.9.2. Reliability Modeling:

3.9.2.1. Identification of all parameters and data necessary to analyze and calculate quantitative reliability attributes using analytical techniques, such as: reliability block diagrams, fault tree analysis, Markov modeling, and Petri net analysis.

3.9.2.2. A description of how reliability parameters and data are exported to quantitative analysis tools and simulations.

3.9.2.3. A description of how parameters and data are imported from the results of external reliability analyses.

3.9.2.4. A description of the software used to execute reliability modeling.

3.9.2.5. A description of how the reliability models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.2.6. A description of how the reliability models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.2.7. A description of how the model allows for the input, storage, and export of data necessary to support a DFMEA/CA.

3.9.2.8. Cross-references between all analyses and associated data for each parameter within the model.

3.9.3. System Safety Modeling:

3.9.3.1. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables in the 100, 200, 300, and 400 series of tasks in MIL-STD-882E, System Safety, that are required under the program contract.

3.9.3.2. A description of how the model allows for the input, storage, and export of data for the 100, 200, 300, and 400 series of tasks in MIL-STD-882E that are required under the program contract.

3.9.3.3. A description of how the model allows for the input, storage, and export of data for MIL STD 882E tasks 402 and 403 (related to explosive safety).

3.9.3.4. A description of how the model produces data deliverables for all tasks in MIL–STD- 882 that are required under the program contract.

3.9.3.5. A description of views to display the current status of activities that support safety or environmental certification approval by external agencies at any architectural level.

3.9.3.6. A description of the software used to execute system safety modeling.

3.9.3.7. A description of how the system safety models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.3.8. A description of how the system safety models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.3.9. A description of how the model specifies system requirements if any are concerned with preventing or minimizing unintended hazards to personnel, property, and the physical environment.

3.9.4. Cybersecurity Modeling:

3.9.4.1. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables for all cybersecurity standards or instructions required under the program contract.

3.9.4.2. A description of how the model enables data input, storage, and export for all tasks related to cybersecurity standards required under the program contract.

3.9.4.3. A description of the views and reports produced by the model for all tasks in all cybersecurity standards or instructions that are required under the program contract.

3.9.4.4. A description of the views and reports produced by the model to display the current status of activities required for cybersecurity accreditation or certification approval at any architectural level.

3.9.4.5. A description of the software used to execute cybersecurity modeling.

3.9.4.6. A description of how the cybersecurity models are used to verify the Digital System Model is internally consistent and compliant with the contractor's modeling style guide and modeling process.

3.9.4.7. A description of how the cybersecurity models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.4.8. A description of the model’s security, data protection, and/or privacy environment in which the system must operate, the type and degree of security, data protection, access controls, and/or privacy to be provided, the security, data protection, and/or privacy risks the system must withstand, required safeguards to reduce those risks, the security/privacy policy that must be met, the security/privacy accountability the system must provide, and the criteria that must be met for security/privacy certification/accreditation.

3.9.4.9. A Security Controls Traceability Matrix (SCTM) that cross examines the security controls against the systems requirements to identify gaps to controls, requirements, and Cybersecurity Survivability Attributes (CSA).

3.9.4.9.1. The SCTM shall identify the applicable policy controls, and how the system meets technical controls.

3.9.5. Maintainability and Sustainability Modeling:

3.9.5.1. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables for Logistics Product Data (LPD) (Reference: DI-SESS-81758A).

3.9.5.2. A description of the views and reports produced by the model all tasks in all maintainability, sustainability, storage, repair, packaging, shipping, and handling standards or instructions required under the program contract.

3.9.5.3. A description of the views and reports produced by the model to display the current status of activities required for all maintainability, sustainability, storage, repair, packaging, shipping, and handling standards or instructions required under the program contract.

3.9.5.4. A description of the software used to execute maintainability and sustainability modeling.

3.9.5.5. A description of how the maintainability and sustainability models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.5.6. A description of how the maintainability and sustainability models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.6. Environment Modeling:

3.9.6.1. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables for all environment standards or instructions required under the program contract.

3.9.6.2. A description of how the model enables data input, storage, and export for all tasks related to environments required under the program contract.

3.9.6.3. A description of the views and reports produced by the model for all tasks in all environments standards or instructions that are required under the program contract.

3.9.6.4. A description of the views and reports produced by the model to display the current status of activities required for environment requirement compliance at any architectural level.

3.9.6.5. A description of the software used to execute environment modeling.

3.9.6.6. A description of how the environment models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.6.7. A description of how the environment models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.7. Quality, Safety, and Mission Assurance (QSMA) Modeling:

3.9.7.1. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables for all QSMA standards or instructions required under the program contract.

3.9.7.2. A description of how the model enables data input, storage, and export for all tasks related to QSMA required under the program contract.

3.9.7.3. A description of the views and reports produced by the model for all tasks in all QSMA standards or instructions that are required under the program contract.

3.9.7.4. A description of the views and reports produced by the model to display the current status of activities required for QSMA requirement compliance at any architectural level.

3.9.7.5. A description of the software used to execute QSMA modeling.

3.9.7.6. A description of how the QSMA models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.7.7. A description of how the environment models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.8. Human Performance (HP) Requirements Modeling:

3.9.8.1. Identification of all parameters and data necessary to analyze and calculate quantitative HP attributes using analytical techniques.

3.9.8.2. A description of how the model incorporates HP requirements and elements facilitating human systems integration (HSI) activities and analyses for improved human performance, reducing total ownership costs during system design, and improving fidelity of the SE process to meet human capabilities and limitations

3.9.8.3. A description of how HP parameters and data are exported to quantitative analysis tools and simulations.

3.9.8.4. A description of how parameters and data are imported from the results of external HP analyses

3.9.8.5. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables to support human integration to achieve system x

3.9.8.6. A description of the software used to execute HP modeling.

3.9.8.7. A description of how the HP models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.8.8. A description of how the HP models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.8.9. Cross-references between all analyses and associated data for each parameter within the model.

image1.png