Data-Driven Systems Engineering (DDSE) poses distinct challenges in Configuration Management. This guide aims to outline strategies for implementing Configuration Management in an Innoslate-powered Digital Engineering Environment (DEE). Innoslate, a comprehensive model-based systems engineering and requirements management solution, offers a rich feature set that establishes an authoritative source of truth in an integrated DEE.
Configuration Management (CM) refers to the methods used for maintaining control of a system’s requirements, architecture, state, and supporting processes throughout its lifecycle. It is typically described, to varying levels of detail, within a program’s Systems Engineering Plan (SEP) and Configuration Management Plan (CMP).
NIST SP 800-53 CM-21 defines baseline configurations as “documented, formally reviewed, and agreed-upon specifications” that “serve as a basis for future builds, releases, or changes.” Configuration change controls formalize how changes to a baseline configuration are made. NIST SP 800-53 CM-32 states that configuration change control includes:
Two additional aspects of configuration management are:
Figure 1‑1 shows the CM actions that will be discussed within this guide. These actions fall within three major categories: Configuration Baselining, Change Management, and Configuration Control.
An Innoslate baseline consists of any approved configuration, such as a specification functional architecture, or physical architecture. It includes specified Innoslate entities along with designated relationships.
Innoslate Documents include specifications and plans. They consist of hierarchically sequenced Statements and Requirements entities. Innoslate Documents can be baselined by using Innoslate’s Document Baseline feature. The Document Baseline feature leverages entity history to capture and store document baselines (i.e., snapshots in time). Document baselining prevents modifications to the baseline, but not the current state of the entities comprising the document. Document baselining does not prohibit document deletion, which must be addressed through other configuration controls.
Baselined Innoslate Documents should be retained in the organization’s CM system. For CM purposes retain:
Architectures include any set of related Innoslate entities. Typically, this will include entities supporting physical, functional, or hierarchical models. These entities may align to DoDAF or UAF Viewpoints. Architectures are baselined through management declaration. This declaration should be supported by CM policies, clearly state what constitutes the baseline, and institute baseline configuration controls. For example, a physical architecture baseline may include component level Asset entities with ‘decomposes’, ‘connected to’, and ‘performs’ relationships while specifically excluding ‘decomposed by’ relationships.
Baselined architectures should be retained in the organization’s CM system. For CM purposes retain:
Change Management is the process of managing changes to configuration baselines. It consists of seven CM actions: Define, Identify, Review, Decide, Implement, Verify, and Retain.
Policies should be established which define the types of changes that are configuration-controlled at a given point in time. A notional configuration-controlled change policy is shown in Table 2‑1. Configuration-controlled changes require formal approval before implementation.
Proposed changes to configuration-controlled items within Innoslate should be identified in a Change Request (CR) or Engineering Change Proposal (ECP). A CR establishes the impact of proposed baseline changes and documents the Innoslate implementation steps. CR formats may vary, but should include the following key elements:
The Proposed Solution Table consists of sequentially executed steps to be followed in Innoslate by the implementer. It should minimally include the following columns:
CRs are reviewed by a Change Control Board (CCB). The CCB should be comprised of management, CM personnel, and technical experts. CCB meetings held to review CRs should include both the CR originators and implementers in attendance.
The CCB will approve or disapprove proposed baseline changes detailed in CRs. CCB decisions must be formally documented and retained. This can occur within the CR form or through the use of related Decision entities (i.e., Decision ‘enabled by’ Artifact).
Approved CRs are implemented by a designated implementer with the appropriate Innoslate project permissions. The CR’s Proposed Solution Table steps should be implemented in the sequence provided. Failure to adhere to the CR’s step execution sequence may result in broken dependencies (e.g., a link to an entity that has not yet been created) or confusion as to which parts of the table remain to be implemented. For large tables, the implementer should consider marking the individual steps as complete.
CM personnel should monitor and verify changes to configuration-controlled data. Erroneous or unauthorized changes should be backed out and logged.
For Innoslate Documents, CM personnel should review Post Baseline Change Reports (PBCRs). PBCRs provide a detailed log of all changes occurring to a document’s entities following each baseline. PBCRs should be compared against the approved CR’s Proposed Solution Table.
For architectures, CM personnel should review CR project modifications by comparing individual entities against the approved CR’s Proposed Solution Table.
Retain records of all configuration-controlled changes. If CRs are implemented as Innoslate Documents, retain them for CM purposes as externally viewable documents. To generate an externally viewable document from within Documents View, select ‘Report’ then ‘Basic Document Output (DOCX).’
Innoslate employs multiple data control mechanisms that can be used to prevent unauthorized data modifications as shown in Figure 2‑1.
Project access permissions control the privileges that users have within a project. Segregation of data across projects allows different users and user groups to have permissions appropriate to the program phase. For example, as shown in Table 2‑2, all developer users may initially have Collaborator access to a system-level project. Following PDR, non-SE users may be downgraded to Reviewer access.
Optimal use of project access permissions requires upfront planning in conjunction with the development of a Conceptual Data Model (CDM).
Document baselining prevents modifications to the baseline, but not the current state of the entities comprising the document. Document baselining does not prohibit document deletion, which must be addressed through other configuration controls.
Entity locking prevents changes to entity attributes, labels, and relationships. Entities can only be unlocked by the locking collaborator or project owners. Entity locking is frequently used to provide protection from inadvertent or unauthorized changes being made by project Collaborators.
There are two primary options for implementing CRs within Innoslate. Option 1 consists of an Innoslate-based CR form implemented within Documents View. This CR form can contain either a textual (Option 1a) or dynamically constructed (Option 1b) Proposed Solution Table. Option 2 consists of storing Excel CR forms as Artifact entity attachments. The benefits and required effort for the CR implementation options are shown in Figure 3‑1.
CR Implementation Option 1a consists of creating and saving a CR template within Documents View.
First, use the Schema Editor to create a “CR Document” label for class Artifact. Then, create a blank document of type ‘CR Document’ and add content sections as specified in 2.2.2 Identify. The Proposed Solution Table should be inserted with the ‘Table…’ insert option. Back up your document by running a ‘Document ZIP Export (INNO)’ report.
Add the CR template to the project from Documents View by selecting ‘More’, selecting, ‘Template,’ entering, “Change Request,” for the template name, and selecting, ‘Create.’ This will result in a new Artifact named, ‘Change Request,’ being created. It is recommended to lock that entity to prevent inadvertent deletion.
New CRs are created by selecting document type ‘CR Document’, template ‘Custom Template’, and custom template ‘Change Request’.
CR Implementation Option 1b is implemented in the same way as Option 1a with the exception of the Proposed Solution Table. Option 1b’s Proposed Solution Table is dynamically created by querying the project database for the associated solution steps.
Use the Schema Editor to create a “CR Solution Step” class. “CR Solution Step” should be a subclass of Statement and minimally contain the attributes shown in Table 3‑1.
Create new CR Solution Step entities from the database view. CR Solution Steps should be numbered sequentially using their corresponding CR number prefix.
Add the Proposed Solution Table to the CR template by inserting it with the ‘Table Notation…’ insert option. Within the ‘Insert Table Notation’ pop-up as shown in Table 3‑2, enter the solution step query, select the ‘CR Solution Step’ attributes, and enter a query limit high enough to retrieve all of the CR’s solution steps.
When new CRs are created from the CR template, the table notation query will need to be updated by the user to retrieve CR Solution Steps corresponding to the new CR number.
A CR’s Proposed Solution Table can be exported as an Excel spreadsheet for the implementer. From Database View, query and sort for the CR’s solution steps (e.g., order:number class:”CR Solution Step” number:CR.###.% where ### is the CR number). Then, generate an Entity Table Report with the CR Solution Step attributes from Table 3‑1.
CR Implementation Option 2 consists of creating an Artifact entity for each Excel CR. This Artifact should be numbered to match the CR number contained within the Excel CR form. The Excel CR is added to the Artifact as an attachment.
CR workflow can be modeled in Innoslate as a State Machine Diagram (SMD) as shown in Figure 3‑2.
The CR workflow SMD can be implemented in a project’s schema by:
Use the Schema Editor to create a “Change Request” class. “Change Request” should be a subclass of Artifact and minimally contain an enumerated attribute named “Status”. “Status” should have values matching the states shown in Figure 3‑2: ‘Proposed’, ‘Approved’, ‘Rejected’, ‘Implemented’, and ‘Closed’. Set the default value for “Status” to ‘Proposed’.
If CRs are implemented as Innoslate Documents (Options 1a and 1b), then:
If CRs are implemented as Artifacts with Excel CR attachments (Option 2), simply create new ‘Change Request’ class entities for all future CRs. Existing CRs can be transformed from Artifact to the ‘Change Request’ class.
To implement the CR workflow state transitions, select, ‘Workflow,’ from within the Schema Editor. Select, ‘Add Workflow Class,’ and the ‘Change Request’ class. If necessary, select the ‘Status’ enumerated property. Define the workflow transitions for each ‘Status’ state by selecting ‘Add Transition’, the name of the target transition state, users/teams with permission to transition the state, and users/teams notified of the state transition.
For example, in Figure 3‑2 the ‘Proposed’ state has two transitions. When defining the workflow, ‘Add Transition’ will be used to select ‘Approved’ creating the ‘Proposed to Approved’ transition, and to select ‘Rejected’ creating the ‘Proposed to Rejected’ transition as shown in Figure 3‑3.
The Innoslate CR workflow should be used in conjunction with CR procedures defined in the organization’s CMP. From within Database View, CR status reports can be generated using the Entity Table Report with ‘Status’ selected as a column attribute.
Innoslate allows an organization to maintain control of a system’s requirements, architecture, state, and supporting processes throughout its lifecycle. It provides versatile features for controlling and tracking change at different levels of granularity. Innoslate provides the capability to implement and supplement and processes within an organization’s CMP.
[1]U.S. Department of Commerce, NIST SP 800-53, Rev. 5 Security and Privacy Controls for Information Systems and Organizations § (2020).
[2] U.S. Department of Commerce, NIST SP 800-53, Rev. 5 Security and Privacy Controls for Information Systems and Organizations § (2020).