Aerospace Systems Engineer

Operations Concept Document

The Operations Concept Document

The Operations Concept document is a technical design document derived from the customers Concept of Operations (CONOPS) and developed through systems engineering’s functional and behavioral decomposition and synthesis into a viable system architecture meeting all project requirements.

The key objective of the Operations Concept document is to capture system behavior. System behavior analysis (Use Case analysis) is the systematic application of requirements, constraints and system behavior goals (CONOPS) to derive a desired behavior. System behavior is captured in the Operations Concept document and expressed in system design implementation


The Operations Concept Document is an architecture driving document. The three components of system design; HW design, SW implementation and Operations Procedures are all equal elements of the system architecture. The Operations Concept Document defines & drives SW and HW implementation providing the context of system behavior.


Documentation reduces risk.


Good requirements specifications buy down programmatic risk. The risk of delivering the wrong thing. Or the perceived wrong thing.


Interfaces present technical risk. Two or more developer’s efforts meet at an interface. The interface must be well understood and documented, and early. A solid IRD will buy down technical risk documenting both “nuts and bolts”, and higher level design. Un- validated and undocumented interface assumptions are very dangerous.


System Behavior is documented in the Operations Concept document. The Operations Concept document buys down both programmatic AND technical risk. The Operations Concept document defines the systems behavior; as such the Operations Concept document is a design document. Its how the system MUST behave, it must be complied with by the developers.


The Operations Concept document also defines the behavior the customer and User sees. The Operations Concept document is generally the most “approachable” document to the customer and User.


Operations Concept Development


The Operations Concept document is developed in conjunction with the derivation of system design. Functional decomposition derives and allocates functions to sub- components of the overall system. But this is always done with a concept of behavior in mind. Therefore these functional allocations captured as requirements in B and C level specifications carry with them expectations of behavior. While these must also be captured as requirements in the specifications they are detailed as system behavior in the Operations Concept document.


The analysis package technique, used during system design derivation, facilitates the flow of derived requirements into the requirements documents and the scenario, captured in the Operations Concept document facilitates validation, verification and O&M procedures development.


ocd_hierarchy_med

The Operations Concept document is a design driving document that describes the mission of the system, its operational and support environments, and the functions and characteristics of the system within an overall operational environment.


Collateral Benefits


*      System design derived or validated

*      System requirements derived or validated
*      Critical timelines derived or validated
*      Architectural design derived or validated
*      Integration steps & stages derived
*      Requirement verification groups derived
*      Development of verification procedures fac
*      Development of operations procedures facilitated
*      Development of System Documentation facilitated
*      Troubleshooting or anomaly investigation facilitated

The Operations Concept document is developed in conjunction with system design development capturing system behavior detailing the interactions between HW, SW and operators. The Operations Concept document IS NOT the operations manual, but it paves the way towards development of the Operations and Maintenance documents.


Detailing system scenarios of operations also facilitates development of verification plans and procedures as well as pre-deployment readiness activities (rehearsals and training).



Operations Concept document Structure and Function


Operations Concept document Functions

*       Provides BIG picture to contractor team members.
*       Describes functions and interfaces to software developers.
*       Reassures Customer that we are all on the same page.
*       Quickly orients stakeholders to the new system; operators, maintainers, customer, testers, system engineers, managers....
*       Guides the contractor team as it develops and deploys its System.

Operations Concept document Characteristics

*       Written in the user’s language.
*       Written in narrative prose (in contrast to a technical requirements specification).
*       Uses visual forms (diagrams, illustrations, graphs) and story boards whenever possible.
*       Provides a bridge between the users needs and the developer’s technical requirements documents.
*       Helps bring to the surface the users’ views and expectations.
*       Contains a series of scenarios from different stakeholder viewpoints (customer, maintainer, operators, developers, testers, system engineers / architects, managers, etc.).
*       Integrates the scenarios into a composite system behavioral timeline with internal and external system inputs/outputs.

The Operations Concept document follows the AIAA and IEEE standard for Operations Concept documents typically organized as follows;


1.0 Scope

2.0 Referenced Documents
3.0 Operations
3.1 Operational Overview
3.2 Personnel
3.3 Operational Processes
4.0 Operational Needs
5.0 System Overview
5.1 System Scope
5.2 Users
5.3 System Interfaces
5.4 System States & Modes
5.5 System Capabilities
5.6 System Goals & Objectives
5.7 System Architecture
6.0 Operational Environment
7.0 Maintenance Environment
8.0 System Operational Scenarios

While the organization and structure of the AIAA and IEEE Operations Concept document is very good the key elements from a design capture perspective are the System Overview (Sect 5) with emphasis on system interfaces, states & modes and architecture. The other key section is System Operational Scenarios (Sect 8). Section 8 captures the behaviors of the system.


System Behavior Scenarios

System Behavior scenarios are Use Cases. They are depicted as threads of behavior across the system. Not all Use Cases are equally important, during the system design process the Use Cases are prioritized based on risk and the high priority Use cases are elaborated.


       Mission Success Risk- Essential Mission Functionality

       Integration Risk -Complex Interfaces & Interactions

       Development Risk - New technology or application

Analysis of thread path variants may indicate additional potential risk areas.


>>Warning<< - Potential for infinite path variations is possible Alternate-path Use Cases rarely warrant full elaboration during system design efforts and are generally not captured in the Operation Concept document. The typical approach is to identify significant risks with the major ones understood to the extent that contingency strategies are definable. Contingency processes and procedures are the domain of the 0&M documentation not the Operations Concept document.


Each System Behavior is introduced in the Operation Concept document with explanatory text and illustrated using several key elements from the behavior analysis process; Context Diagram, Message Sequence Chart and Event Flow Table.