Untitled design (47)

 

The Foundation for Digital Engineering

Creating a Conceptual Data Model (CDM) & Data Storage Plan (DSP)

 

DOWNLOAD PDF

Introduction

Successful Digital Engineering (DE) efforts depend upon the quality of the underlying data. Two foundational products that aid in ensuring the data’s integrity are the Conceptual Data Model (CDM) and the Data Storage Plan (DSP). The Conceptual Data Model (CDM) is a high-level data plan that illustrates data types, locations, and relationships. The Data Storage Plan (DSP) is a lower-level data plan which builds upon the CDM. It describes data numbering, naming, and labeling conventions necessary to ensure that the desired output products can be produced.

This document will focus on the design of CDM and DSP products to support Lifecycle Modeling Language (LML) and Innoslate-based DE efforts. The concepts described herein can be applied to other modeling languages and toolsets.

Conceptual Data Model (CDM) Documentation Strategy

The CDM illustrates data types (i.e., LML or extended classes), locations (i.e., Innoslate projects), and relationships.  Data types and relationships can be modeled as an Innoslate Spider Diagram. It is recommended that different classes and their associated subclasses be assigned a color within the Spider Diagram. The selected colors should be used consistently throughout all documentation when showing class-related objects. Entities used when constructing the Spider Diagram should be of the class being represented (i.e. use an Action Entity to represent an Action). This will ensure that only valid relationships are reflected in the CDM.  It is also recommended that the class name be entered in the entity’s number field.  CDM data modeled as a Spider Diagram is shown in Figure 1.

 

Picture1-Sep-18-2023-10-24-26-6829-PM

Figure 1. Spider Diagram CDM Classes and Relationships

 

To complete the CDM, a transparent PNG of the CDM Spider Diagram is imported into PowerPoint and annotated with project information as shown in Figure 2.

 

Picture2-Sep-18-2023-10-25-26-5930-PM

Figure 2. Conceptual Data Model

CDM Development Process

The CDM development process consists of five steps: Identify Data Scope, Identify Data Elements to be Represented, Identify Data Element Classes, Identify Relationships between Data Elements, and Establish Project Boundaries.  Each of these steps will be described in the following sections.

CDM Step 1: Identify Data Scope

The first step in creating a CDM is to identify the data scope.  The scope should include the types of data (i.e. technical, programmatic, etc.) and the level of detail required.  It is important to clearly state what data will not be covered by the CDM.

CDM Step 2: Identify Data Elements to be Represented

The second step is to identify the data elements to be represented within the CDM.  The data elements are a high-level refinement of the data scope.  Data elements may include systems, subsystems, functions, requirements, and interfaces.  Additional examples of data elements are reflected in the entity names in Figure 1.

CDM Step 3: Identify Data Element Classes

The third step is to identify classes that correspond to the data elements from Step 2.  The classes should correspond to LML classes.  Resist the urge to create new subclasses by modifying the schema, as it will create incompatibilities across projects and is usually not necessary.  Subclasses should only be used when there is no other way to represent data other than through adding attributes or new relationships to a class. 

CDM Step 4: Identify Relationships between Data Elements

The fourth step is to identify the relationships between the data elements from Step 2.  The relationships should correspond to LML relationships.  Avoid schema modification to add relationships unless it is absolutely necessary.  Generally accepted relationships, such as ‘decomposes’/’decomposed by’ for hierarchies, should be used as described in the LML ontology.  Adopting non-standard relationship implementations will likely impact out-of-the-box reports, such as those designed to produce DoDAF artifacts.

CDM Step 5: Establish Project Boundaries

Data elements should be grouped in projects according to content and the need to regulate access through controls.  Innoslate redacts cross-project information for users without access.  It also allows multiple permission levels within a project.  For example, assets, actions, and requirements associated with different subsystems could be grouped into different projects.  Each subsystem team could be given Collaborative access to their own project and Viewer access to the other subsystems’ projects.

Data Storage Plan (DSP) Documentation Strategy

The DSP describes data numbering, naming, and labeling conventions necessary to ensure that the desired output products can be produced.  When completed, it should be a comprehensive guide to entering and retrieving data from the digital engineering environment.  The DSP should be broken down into sections covering logical subsets of the CDM data (e.g., interface specification, functional architecture, etc.).

Data Entry

DSP data entry documentation should include data element classes, data element relationships, numbering and naming formats, and labeling requirements.  It is recommended that this information be captured in a diagram format, as shown in Figure 3, with similar color coding to that used in the CDM.  It should also indicate, when possible, which data will be used for different output products.  DSP data entry documentation may also include additional formatting instructions for diagrams, such as the color coding of conduit types (e.g., Red = Power, Black = Grounding, Blue = Data) within Asset Diagrams.

Picture3-Sep-18-2023-10-31-09-4844-PM

Figure 3. Data Storage Plan (DSP) Data Entry Documentation

 

Data Extraction

DSP data extraction documentation should include instructions for producing the desired output product with diagrams illustrating report settings.  When possible, depictions of sample output should be shown.  An example of data extraction documentation is shown in Figure 4.

 

Picture4-Sep-18-2023-10-32-55-6147-PM

Figure 4. Data Storage Plan (DSP) Data Extraction Documentation

 

Schema Modifications

The DSP should comprehensively document any schema modifications.  This should include the following: new entity classes or subclasses, new relationship types, new attributes, new labels, and modifications to existing LML entity classes.  Subclasses should be used as a means to avoid modifications to existing LML entity classes, which is highly discouraged.

DSP Development Process

The DSP development process consists of five steps: Identify Outputs, Establish Conventions for Filtering, Establish Relationship Targets, Revisit the CDM, and Document Output Methods.  Each of these steps will be described in the following sections.

DSP Step 1: Identify Outputs

The first step in creating a DSP is to identify the desired output products from the DE.  Examples of output products include Action Diagrams depicting the interaction of system functions, equipment hierarchies, and traceability reports from requirements to functions.  It is important that the list of desired output products be comprehensive, as it will impact design decisions within the following steps and may place constraints upon future expansion of the DE environment.

DSP Step 2: Establish Conventions for Filtering

The second step is to establish numbering, naming, and labeling conventions that facilitate entity filtering.  The main goal of this step is to be able to unambiguously define and retrieve the data necessary to produce the desired output products identified in Step 1.  For example, if you need to produce a report showing which system functions are performed by each subsystem then it may be beneficial to label the subsystem assets with a ‘Subsystem’ label.  All assets that are not subsystems should be excludable during the initial filtering.  Do not be concerned if there are many ways to filter and get the desired results.  This is beneficial to future DE expansion and not an indication of poor design.

DSP Step 3: Establish Relationship Targets

The third step is to identify the relationship targets for any traceability reports from Step 1.  In general, relationships and their corresponding target entities should match up with the CDM.  There may be cases where traceability reports include unwanted data among the relationship targets.  If this happens you can either eliminate the unwanted data through post-processing or use additional relationships to better distinguish the target entities for the traceability report.

DSP Step 4: Revisit the CDM

The fourth step is to revisit the CDM.  Incorporate any changes that were necessary due to DSP Steps 2 and 3.

DSP Step 5: Document Output Methods

The final step is to clearly document the methods for producing the desired output products.  Be sure to include all report settings and any required data filtering.  Indicate if any post-processing (e.g., tech editor document formatting, spreadsheet data reduction, etc.) will be required.

Additional Considerations

The CDM and DSP should be reviewed and revised after major program milestones and whenever the data scope changes.  An example of a change in data scope would be the inclusion of safety-related data or the decision to incorporate lower-level requirement specifications.

The DSP is a complicated plan.  Minor changes may have unforeseen impacts on output products.  It is a best practice to create a prototype of your DE environment with mocked-up data in order to verify that the DSP provides the intended outputs.  Experiment with any changes prior to adopting them.

Conclusion

DE efforts are data-driven approaches requiring intentionally designed and verified environments. Establishing a CDM and DSP will aid in ensuring the integrity of input data and the availability of output products.

GET STARTED FREE