The Foundation for Digital Engineering

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.

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.

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.