DID FinderBack
Source
DI-SESS-82364

Digital System Model

Provides a consistent, digitally traceable representation of a system, including its metadata, organization, elements, and views, to serve as an authoritative source of truth for systems engineering.

Approval DateFebruary 1, 2022
AMSC Number10279
Preparing ActivityMDA
Project NumberSESS-2021-036
OPR—
DTIC ApplicableNo
GIDEP ApplicableNo
Limitation—
Applicable Forms—
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantYes
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Supersedes
—
Related
—

Description & Purpose

—

Application & Interrelationship

—

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.

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

This Data Item Description (DID) contains the format, content, and intended use for the data product resulting from the work task described in the contract Statement of Work/Performance Work Statement.

Preparation Instructions

1Reference documentsThe 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.
2FormatThe Digital System Model shall be delivered in the native file format(s) of the modeling tool(s) or developed directly in the Integrated Digital Data Environment (IDDE) as identified in the Contractor's Systems 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.
3ContentsThe Digital System Model shall be organized into the following sections:
3.1ScopeThis section shall be divided into the following sub-sections:
3.1.1IdentificationThis 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.2System overviewThis 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.3Document overviewThis 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.2Referenced documentsThis section shall list the number, title, revision, and date of all documents referenced in the Digital System Model.
3.3Model OverviewThis section shall contain the following:
3.3.1Design assumptions and design decisions about the model.
3.3.1.1Assumptions and decisions about requirements.
3.3.1.2Assumptions and decisions about verification and validation.
3.3.1.3Assumptions and decisions about architecture.
3.3.1.4Assumptions and decisions about use cases.
3.3.1.5Assumptions and decisions about the structural aspects of the model.
3.3.1.6Assumptions and decisions about behavioral aspects of the model.
3.3.1.7Assumptions and decisions about the model infrastructure including tool interfaces and data flows.
3.3.1.8Assumptions and decisions about model integration requirements.
3.3.1.9Assumptions and decisions about functional, allocated, and product baselines.
3.3.2Model infrastructureThis sub-section shall contain the following:
3.3.2.1Modeling language(s) and version(s).
3.3.2.2Incorporated profiles.
3.3.2.3Model and data repositories.
3.3.2.4External dependencies.
3.3.2.5Data integration and digital thread with external tools, data flows, data dictionaries, databases, and other repositories to maintain data consistency.
3.3.2.6Interfaces (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.7Means of synchronization between the model and the implementation.
3.3.2.8Dashboards and/or visualizations to interrogate or visualize the model.
3.3.2.9Authoritative Data Source(s) with certification plan.
3.3.2.10Associated 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.3Model Development MethodologyThis sub-section shall contain the following:
3.3.3.1The model development plan including:
3.3.3.1.1Model requirements formulation.
3.3.3.1.2Model development process.
3.3.3.1.3Model documentation and release schedule.
3.3.3.1.4Discrepancy reporting and tracking.
3.3.3.1.5Facility or facilities (if multiple locations) where the model will be developed.
3.3.3.1.6Enforcement of proprietary restrictions.
3.3.3.1.7Conformance with Government cybersecurity and classified system requirements.
3.3.3.1.8User training and documentation.
3.3.3.2Tool set and development environmentincluding all information needed for the Government to independently reproduce the development, verification, validation, configuration management, and test environment.
3.3.3.3Model style guidelinesshall 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.4Methodology to evaluate and optimize modularity and extensibility (e.g., use of interfaces and boundary blocks or classes).
3.3.3.5Methodology to evaluate and optimize abstractions and encapsulation to minimize dependencies on the internals of elements.
3.3.3.6Verification, validation, and testing methods.
3.3.3.7Configuration management methods and tools.
3.3.3.8Programmatic methods and tools, such as cost, schedule, and risk information linked to the technical aspects of the model.
3.3.4Model OrganizationThis sub-section shall contain the following:
3.3.4.1Package diagrams that capture and describe the model organization.
3.3.4.2Organization rationale (e.g. by diagram type, by hierarchy, or by Integrated Product Team.)
3.3.4.3Description of model navigation and views that depict model organization.
3.3.4.4Description and purpose for model diagrams, elements, and outputs (including all external referenced models).
3.3.5Views and exportsThis sub-section shall contain a description of model views and exports for system engineering and program management including: DoD Architectural Framework (DoDAF) and Unified Architecture Framework (UAF) views. Integrated Master plan and schedule. Dashboards, diagrams, reports, and presentation material in support of milestone technical reviews. Performance Requirements Specifications (Reference: DI-IPSC-81431A) Interface Requirements Specifications (Reference: DI-IPSC-81434A) Requirements Trace (Reference: DI-MGMT-82133) System Documents, including allocation of software to hardware (Reference: DI-IPSC-81432A) Software Design Documents (Reference: DI-IPSC-81435A) Interface Control Documents (Reference: DI-SESS-81248) Interface Design Descriptions (Reference: DI-IPSC-81436) Requirements Verification Matrices, Verification Summary Sheets, Verification Reports, and Verification Change Notices Developmental Evaluation Framework Test plans and procedures for tests required for verification Technical Orders (Reference: MIL-PRF-38311) Risk, Issue, and Opportunity Applicability and Effectivity Matrices with mapping to tests, design elements, and corrective builds Reliability, Availability and Maintainability Reporting per design elements Mission and Reliability Critical Items Lists Mission Assurance Provisions Metrics Obsolescence, Limited Life Items, DMSMS, and spares management data Spectrum Certification Spectral Characteristics Data (Reference: DI-EMCS-81827) Electromagnetic Environmental Effects (E3) Integration and Analysis Reports (Reference: DI-EMCS-81540B) E3 Verification Procedures (Reference: DI-EMCS-81541B) E3 Verification Reports (Reference: DI-EMCS-81542B) Deviations and Waivers (Reference: DI-SESS-80640E) Government Industry Data Exchange Program (GIDEP) and Supply Chain Risk Management (SCRM) Advisories.
3.4Modeling of System RequirementsThis section shall be divided into the following sub-sections:
3.4.1Requirements completenessThis sub-section shall describe how inclusion of all requirements from the technical baseline is ensured.
3.4.2Requirements rationaleThis sub-section shall describe the rationale for all requirements.
3.4.3Requirements satisfaction and verificationThis sub-section shall link all model elements that satisfy system each requirement and to all verification methods for each requirement.
3.4.4Requirements relationshipsThis 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.5Government-provided profilesThis sub-section shall detail the use of Government provided profiles applied to requirements.
3.4.6AnnotationsThis sub-section shall specify annotations by hierarchical level.
3.4.7Requirements tablesThis 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.5Use CasesThis section shall contain the following:
3.5.1Description of use cases that capture mission objectives and requirements.
3.5.2Description of use cases that capture system operations.
3.5.3Description of use cases that describe error conditions and alternatives.
3.5.4The tracing of use cases to requirements.
3.5.5The tracing of actors, including inanimate systems, to other model elements.
3.6Structural DiagramsThis section shall contain the following:
3.6.1Diagrams:
3.6.1.1Domain 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.2System 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.3Diagrams, such as Block Definition Diagrams (BDDs) and IBDs, which show subsystem decomposition and the relationship between components.
3.6.1.4Logical architecture diagrams, such as BDDs and IBDs, which show the relationships of system functions to requirements.
3.6.1.5Physical 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.6Parametric 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.7Categorization and grouping methods (e.g. stereotypes) to categorize and group types of components.
3.6.2Interfaces:
3.6.2.1Description of all system and human interfaces, each defined as an interface block with a reference and hyperlink to the interface specifications.
3.6.2.2Description of all operations and receptions within interfaces, with pre-conditions, post-conditions, and exceptions, if applicable.
3.6.2.3Naming convention for interfaces.
3.6.2.4Description of all stereotypes and profiles for interfaces.
3.6.3Blocks and Classes:
3.6.3.1Description of all definitions, including the purpose, roles, and responsibilities.
3.6.3.2Description of the use of all blocks and classes in behavioral diagram and structural diagrams.
3.6.3.3Description of naming conventions for blocks and classes.
3.6.3.4Description of all properties and attributes and typing.
3.6.3.5Description of all operations, including purpose, description, pre-conditions, post-conditions, exceptions, parameters, and return values.
3.6.3.6List of all application of profiles and stereotypes.
3.6.3.7List of all boundary classes that communicate with externals (e.g. external systems, external hardware, or externally developed software).
3.6.4Relationships on Block Definition Diagrams:
3.6.4.1Description of structural and non-structural relationships between classes and blocks.
3.6.4.2Naming conventions for relationships.
3.6.4.3Justification for any class or block with no relationships to model elements.
3.6.5Connectors on Internal Block Diagrams:
3.6.5.1Naming conventions for connectors.
3.6.5.2List and description of flow of inputs and outputs between parts.
3.6.5.3List and description of invocation of operations on parts.
3.6.5.4List and description of sending and receiving signals between parts.
3.6.5.5List and description of flow properties (at least type and direction).
3.7Behavioral ContentThis section shall contain the following:
3.7.1Behavioral Content Requirements:
3.7.1.1Methods for capturing system behavior.
3.7.1.2Identification of what behaviors are not captured.
3.7.1.3Description of pre-conditions, post conditions, alternatives, and error conditions.
3.7.1.4Description 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.5Identification of state-based behavior for all blocks and classes (e.g. control classes).
3.7.1.6Identification of design assumptions or design decisions about dynamic views.
3.7.2Activity Diagrams:
3.7.2.1Name and purpose of each activity diagram.
3.7.2.2Mapping of classes and blocks in class and block definitions from the static model to behavior diagrams.
3.7.2.3Mapping of activity and sequence diagrams to use cases.
3.7.2.4Naming conventions on actions, data, and control flows.
3.7.2.5Description 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.3Sequence Diagrams:
3.7.3.1Name and purpose of each sequence diagram.
3.7.3.2Naming conventions for messages and sequence fragments.
3.7.3.3Identification of data, data type, format, and communication type (e.g. synchronous, asynchronous) for all message flows.
3.7.3.4Mapping of blocks and classes to lifelines.
3.7.4State Machine Diagram Requirements:
3.7.4.1Name and purpose of each state machine diagram.
3.7.4.2Mapping of structural elements to state machine diagrams.
3.7.4.3Mapping of state charts to other behavior diagrams.
3.7.4.4Naming conventions for states, triggers, events, and actions.
3.7.4.5Identification of state charts that address error conditions and alternative paths.
3.8Model DataThis section shall contain the following:
3.8.1Description of the data in the model.
3.8.2Description of the data governance including data protection and access control requirements in the model.
3.8.3Description of data types for all attributes and properties.
3.8.4Description of meta-data and data tagging attributes.
3.8.5Naming conventions for names of parent and child entities and for names of mapping entities.
3.8.6A glossary with a list of all model elements.
3.9Non-Functional RequirementsThis section shall contain the following:
3.9.1Performance Modeling:
3.9.1.1Identification 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.2A 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.3A description of how parameters and data are imported from the results of external analyses.
3.9.1.4A description of the software used to execute performance modeling.
3.9.1.5A 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.6A description of how the performance models are used to validate system use cases, behavior, interfaces, and requirements implementation.
3.9.1.7Cross-references between all analyses and associated data for each parameter within the model.
3.9.2Reliability Modeling:
3.9.2.1Identification 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.2A description of how reliability parameters and data are exported to quantitative analysis tools and simulations.
3.9.2.3A description of how parameters and data are imported from the results of external reliability analyses.
3.9.2.4A description of the software used to execute reliability modeling.
3.9.2.5A 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.6A description of how the reliability models are used to validate system use cases, behavior, interfaces, and requirements implementation.
3.9.2.7A description of how the model allows for the input, storage, and export of data necessary to support a Failure, Modes, Effects, & Criticality Analysis (FMECA)
3.9.2.8Cross-references between all analyses and associated data for each parameter within the model.
3.9.3System Safety Modeling:
3.9.3.1A 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.2A 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.3A 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.4A 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.5A 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.6A description of the software used to execute system safety modeling.
3.9.3.7A 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.8A description of how the system safety models are used to validate system use cases, behavior, interfaces, and requirements implementation.
3.9.3.9A 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.4Cybersecurity Modeling:
3.9.4.1A 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.2A 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.3A 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.4A 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.5A description of the software used to execute cybersecurity modeling.
3.9.4.6A 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.7A description of how the cybersecurity models are used to validate system use cases, behavior, interfaces, and requirements implementation.
3.9.4.8A 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.5Maintainability and Sustainability Modeling:
3.9.5.1A 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.2A 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.3A 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.4A description of the software used to execute maintainability and sustainability modeling.
3.9.5.5A 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.6A description of how the maintainability and sustainability models are used to validate system use cases, behavior, interfaces, and requirements implementation.
3.9.6Environment Modeling:
3.9.6.1A 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.2A 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.3A 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.4A 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.5A description of the software used to execute environment modeling.
3.9.6.6A 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.7A description of how the environment models are used to validate system use cases, behavior, interfaces, and requirements implementation.
3.9.7Quality, Safety, and Mission Assurance (QSMA) Modeling:
3.9.7.1A 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.2A 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.3A 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.4A 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.5A description of the software used to execute QSMA modeling.
3.9.7.6A 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.7A description of how the environment models are used to validate system use cases, behavior, interfaces, and requirements implementation.
3.9.8Human Performance (HP) Requirements Modeling:
3.9.8.1Identification of all parameters and data necessary to analyze and calculate quantitative HP attributes using analytical techniques.
3.9.8.2A 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.3A description of how HP parameters and data are exported to quantitative analysis tools and simulations.
3.9.8.4A description of how parameters and data are imported from the results of external HP analyses
3.9.8.5A 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 performance requirements and safety.
3.9.8.6A description of the software used to execute HP modeling.
3.9.8.7A 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.8A description of how the HP models are used to validate system use cases, behavior, interfaces, and requirements implementation.
3.9.8.9Cross-references between all analyses and associated data for each parameter within the model.

References

—
Schema v3.0Community-maintained · Verify against ASSIST
Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer