Classical Approaches to Concept of Operations (ConOps) Document Structuring in Systems Engineering.

Abstract.

The Concept of Operations (ConOps) document plays a pivotal role in the systems engineering process by aligning stakeholders’ objectives with system design and operational requirements.

ConOps serves as a bridge between operational needs and technical specifications, ensuring a shared understanding of how the system will be used.

This article examines ConOps by exploring key standards such as IEEE Std 1362-1998 (R2007), ANSI/AIAA G-043B-2018, ISO 29148, and the guidelines from the U.S. Department of Transportation Federal Highway Administration (FHWA).

It also provides an analysis of real-world applications of these standards, in projects like NISAR and LSST, declaring a distinction between ConOps and OpsCon (Operational Concept) and the importance of using UML and SysML in the development process.

Additionally, the document discusses how to maintain ConOps as a living document throughout the system’s lifecycle.

Keywords— Concept of Operations, ConOps, Operational Concept, OpsCon, IEEE 1362-1998, ANSI/AIAA G-043B-2018, NASA Appendix S, FHWA, UML, SysML, Systems Engineering, Lifecycle Support, NISAR, LSST.

1. Introduction.

This article is inspired by the work of Ph.D. Rafael Ferreira da Silva [8].

The Concept of Operations (ConOps) document is a crucial document that outlines how a system will function from the users' perspective, ensuring that operational goals and stakeholder expectations are clearly communicated to developers and system architects.

ConOps provides a high-level, non-technical description of a system's intended use and bridges the gap between operational needs and technical requirements. This document is essential for guiding complex systems development, particularly in industries like aerospace, transportation, defense, and software engineering, where operational reliability and stakeholder alignment are paramount.

The development of ConOps documents is guided by several standards and templates, such as IEEE Std 1362-1998 (R2007), ANSI/AIAA G-043B-2018, ISO 29148, and NASA’s System Engineering Handbook Appendix S Concept of Operations Annotated Outline.

These standards provide structure and consistency, helping ensure that ConOps documents address the system's lifecycle, stakeholders, and environment.

However, the specific structure and content of a ConOps document can vary depending on the governing standard or the specific industry in which it is applied.

This article presents an overview of the structures proposed by these different standards and templates.

2. Overview of the Concept of Operations (ConOps).

2.1. Definition and Purpose.

The Concept of Operations (ConOps) is a formal, high-level document that describes how a system will be used from an operational perspective.

It provides a narrative that outlines the system's objectives, stakeholders, operational environment, and key capabilities.

According to IEEE Std 1362-1998 (R2007), ConOps serves as a bridge between the sometimes vague operational needs of stakeholders and the specific technical requirements of system development [1].

The U.S. Department of Transportation Federal Highway Administration (FHWA) adds that a ConOps document is non-technical and should be presented from the viewpoints of the various stakeholders involved. Its primary role is to create a shared understanding of how the system will operate, what roles each stakeholder will play, and how the system will meet user requirements. It also defines the criteria for validating the system once it is completed [2].

2.2. Objectives of ConOps.

A well-constructed ConOps document serves several key objectives [1], [2]:

• Stakeholder Agreement: Ensures that all stakeholders agree on how the system will be operated and who will be responsible for different parts of the system.
• High-Level System Concept: Defines the high-level system concept and justifies why it was chosen over other alternatives.
• Operational Environment: Describes the environment in which the system will operate, including both the physical and operational environments.
• Requirements Derivation: Helps derive high-level system and user requirements.
• Validation Criteria: Provides the criteria for validating the completed system to ensure it meets operational goals and stakeholder needs.

3. Structure of a ConOps Document.

The structure of a ConOps document can vary significantly depending on the organization or industry creating it. Below, we explore several different ConOps structures, governed by standards from various entities.

3.1. IEEE Std 1362-1998 (R2007) Structure.

The IEEE Std 1362-1998 (R2007) standard provides a well-structured framework for creating ConOps documents, especially for software-intensive systems.

This standard focuses on defining how software systems should operate and interact with users and other systems throughout their lifecycle [1].

Structure:

Introduction.

• Project background and rationale.
• Assumptions and constraints.

Operational Overview.

• High-level overview of system operation.
• System scope and objectives.

Operational Scenarios.

• Nominal and off-nominal operational scenarios.
• Stakeholder roles and responsibilities.

System Description.

• Functional description of system components.
• Interfaces with external systems.

Operational Modes.

• Description of different modes of system operation.

Support Requirements.

• Maintenance, repair, and support strategies.

3.2. ANSI/AIAA G-043B-2018 Structure.

The ANSI/AIAA G-043B-2018 standard, developed by the American Institute of Aeronautics and Astronautics (AIAA), is broader in scope than IEEE 1362-1998 and applies to a wide range of systems, including both hardware and software systems [3].

This standard is widely used in aerospace and defense applications, where systems often involve multiple stakeholders and operational environments.

Structure:

Introduction.

• Purpose and objectives of the document.
• Stakeholder overview.

System Concept.

• High-level description of the system concept.
• Justification for the selected system approach.

Operational Environment.

• Physical and operational environments.
• External interfaces.

Operational Scenarios.

• Use cases and design reference missions (DRMs).
• Nominal and off-nominal conditions.

Support Environment.

• Maintenance, upgrade, and support requirements.

3.3. U.S. Department of Transportation Federal Highway Administration (FHWA) Structure.

The FHWA ConOps structure, provided by the U.S. Department of Transportation Federal Highway Administration, offers a specific template designed for transportation systems, emphasizing integration and operational impacts.

Structure [2]:

Title Page.

• Includes project name, agency, contract number, and approval date.

1.0 Purpose of Document.

• Brief description of the purpose and rationale for the system under development.

2.0 Scope of Project.

• Overview of system objectives, geographic area covered, and agencies involved.

3.0 Referenced Documents.

• Lists supporting documentation and resources used for system development.

4.0 Background.

• Describes the current system, its limitations, and the justification for the new system.

5.0 Concept for the Proposed System.

• Describes alternative system concepts, evaluation of alternatives, and the selected approach.

6.0 User-Oriented Operational Description.

• Focuses on how the goals and objectives are currently accomplished and the strategies and policies employed.

7.0 Operational Needs.

• Describes the vision, goals, and objectives driving the system’s requirements.

8.0 System Overview.

• Provides a structural overview of the system, its interfaces, users, and planned capabilities.

9.0 Operational Environment.

• Describes the facilities, hardware, software, and personnel required to operate the system.

10.0 Support Environment.

• Outlines the physical and operational support necessary for system maintenance.

11.0 Operational Scenarios.

• Details sequences of events for normal and failure conditions.

12.0 Summary of Impacts.

• Analyzes how the proposed system impacts stakeholders and documents constraints.

13.0 Appendices.

• Contains glossary, notes, and background material.

The FHWA structure places a strong emphasis on stakeholder roles, operational scenarios, and the integration of systems, which is crucial in the transportation sector where multiple systems must work together seamlessly.

4. Notes on the Standards and Guidelines for ConOps.

The standards and guidelines help ensure that ConOps documents are thorough, consistent, and meet stakeholder expectations.

4.1. IEEE Std 1362-1998 (R2007).

The IEEE Std 1362-1998 (R2007) standard is particularly useful for developing ConOps for software-intensive systems.

It provides a detailed outline for documenting how software systems will interact with users and other systems throughout their lifecycle [1].

The standard emphasizes:

• Stakeholder communication: Ensuring that all stakeholders are aligned on how the system should operate.
• Operational scenarios: Including both nominal (normal) and off-nominal (failure) operational conditions.
• Support requirements: Addressing system maintenance, repair, and lifecycle support.

The IEEE standard is designed for systems where software plays a significant role in performance and system behavior, such as in IT, aerospace, and defense systems.

It provides a clear structure to manage software complexity by defining key operational scenarios and user interactions.

4.2. ANSI/AIAA G-043B-2018.

The ANSI/AIAA G-043B-2018 standard is broader in scope and applies to both hardware and software systems.

It is widely used in the aerospace and defense industries, where systems often involve complex interactions between hardware components, software, and multiple stakeholders [3].

The standard covers:

• System concept and justification: High-level system design and the rationale for selecting specific approaches.
• Operational environments: Describing both physical and operational conditions, ensuring that the system can function in different contexts.
• Support environment: Maintenance and upgrade strategies over the system’s lifecycle.

ANSI/AIAA G-043B-2018 also emphasizes the importance of stakeholder collaboration, ensuring that all parties involved in the system's development understand their roles and the system’s purpose.

This standard is highly applicable to large-scale projects like space missions and military systems, where complex operational scenarios must be managed across a system's lifecycle.

4.3. ISO/IEC/IEEE 29148:2011.

The ISO/IEC/IEEE 29148:2011 standard provides a framework for capturing system requirements and operational concepts.

It is particularly well-suited for systems that are being developed incrementally, where updates and enhancements are made to existing capabilities over time [4].

This standard focuses on:

• Incremental development: Structuring ConOps to support projects where systems are gradually upgraded or extended.
• Lifecycle flexibility: Providing guidelines for evolving operational requirements as systems grow more complex.

ISO 29148 is especially useful for projects involving regional integration or incremental improvements to existing systems, such as transportation systems or public infrastructure.

4.4. U.S. Department of Transportation Federal Highway Administration (FHWA).

The FHWA’s ConOps template is designed for transportation systems where operational integration and collaboration between multiple local and regional stakeholders is critical [2].

It emphasizes:

• Stakeholder roles: Ensuring clear communication and delineation of responsibilities among transportation agencies.
• Operational and failure scenarios: Documenting how the system will operate in both normal and failure conditions.
• Integration: Managing how different systems are integrated to create a cohesive regional or national transportation system.

The FHWA template is particularly valuable for large, multi-agency transportation projects where systems must be automated, integrated, or coordinated across jurisdictions.

It also provides a checklist to ensure that critical operational details, stakeholder roles, and environmental conditions are clearly documented.

5. Real-World Examples.

To better understand how Concept of Operations (ConOps) documents are used in practice, several real-world examples from large-scale systems demonstrate how ConOps helps define operational objectives and guide system development.

Below, we examine different cases.

5.1. NISAR ConOps.

The NISAR (NASA-ISRO Synthetic Aperture Radar) mission is a joint venture between NASA and the Indian Space Research Organisation (ISRO), designed to measure changes in Earth’s surface.

The NISAR ConOps provides a comprehensive guide for how the satellite system will collect, process, and distribute geospatial data.

The NISAR ConOps addresses key operational scenarios, detailing how satellite sensors will capture data, the interactions between the satellite and ground stations, and how scientists will access and interpret the data.

This document is indeed a mix of the following concepts into a single document [9]:

• Science and Applications.
• Mission Science Requirements.
• Mission Design and ConOps.
• Flight System Characteristics.
• Radar and Measurement Principles.
• Data Products.
• Revisions include errata corrections and some updates.

Key aspects include:

• Operational Scenarios: Describes how the satellite operates under normal conditions and in response to system failures or environmental anomalies.
• Stakeholder Roles: Outlines the roles of both NASA and ISRO, as well as other stakeholders responsible for data analysis and mission control.
• Support Requirements: Details the operational support needed throughout the satellite's lifecycle, including maintenance, upgrades, and decommissioning.

NISAR’s ConOps is a detailed example of how complex space missions require a structured approach to system operations, aligning with both NASA and IEEE standards for system development.

5.2. LSST ConOps.

The Large Synoptic Survey Telescope (LSST) project, now known as the Vera C. Rubin Observatory, provides a strong example of ConOps [6] applied in the astronomical research domain.

The LSST is designed to capture vast amounts of astronomical data over its 10-year operational lifespan, and its ConOps document emphasizes:

• Data Collection and Distribution: Describes how the telescope will gather astronomical data and distribute it to the scientific community.
• Stakeholder Roles: Details the roles of scientists, data analysts, and support staff responsible for ensuring the system operates efficiently.
• Operational Environment: Outlines the environmental conditions the telescope will encounter, including temperature, altitude, and weather impacts on data collection.

6. Maintaining ConOps Document as a Living One.

One of the critical aspects of a successful ConOps document is that it should be considered a living document.

This means that the ConOps must evolve throughout the lifecycle of the system, adapting to changes in requirements, technology, and operational environments.

The BSR/AIAA G-043A-201X standard emphasizes that the ConOps document and the System Operational Concept (OpsCon) document should be updated as the system transitions from development through deployment, maintenance, and eventual decommissioning [3] [7].

Updates to the ConOps may include:

• Changes in Stakeholder Requirements: As new stakeholders become involved or as operational requirements shift, the ConOps should reflect these changes.
• System Upgrades and Enhancements: When systems are incrementally upgraded, such as in transportation or IT projects, the ConOps should document how these upgrades will affect operations.
• Lifecycle Transitions: The ConOps should be updated to reflect changes in the system’s lifecycle, including transitions from testing to full operation, as well as updates to support and maintenance procedures.

In large-scale projects such as NISAR and LSST, where system lifecycles span several years or even decades, maintaining an updated ConOps ensures that the system can continue to meet its operational objectives despite changes in technology or stakeholder needs.

7. Use of UML and SysML in ConOps Development.

In modern systems engineering, the use of Unified Modeling Language (UML) and Systems Modeling Language (SysML) plays an increasingly important role in the development of ConOps documents.

These modeling languages allow systems engineers to create visual representations of system interactions, operational scenarios, and stakeholder roles, providing a clearer picture of how the system will function.

7.1. UML in ConOps.

UML is widely used in software engineering to model use cases, system interactions, and operational scenarios.

In the context of ConOps, UML can be used to visually depict how different system components interact during various operational modes.

For example:

• Use Case Diagrams: Show how different stakeholders interact with the system, outlining the roles and responsibilities of each participant.
• Sequence Diagrams: Depict the flow of communication between system components during normal operations and failure conditions, helping to visualize how the system responds to different scenarios.

UML is particularly valuable in software-intensive systems like those guided by IEEE Std 1362-1998 (R2007), where interactions between system components and users must be clearly defined to ensure system reliability.

7.2. SysML in ConOps.

SysML, an extension of UML, adds capabilities for modeling both hardware and software systems, making it highly applicable for complex systems that include physical components.

SysML is particularly useful in ConOps documents for aerospace, defense, and transportation systems, where both hardware and software components must interact seamlessly.

SysML diagrams can be used to:

• Model System Architecture: Providing a high-level view of the system’s structure, including hardware components, interfaces, and software integration. Block Definition Diagrams (BDDs) show the major components of the system and how they relate to each other in terms of structure and hierarchy. Internal Block Diagrams (IBDs) focus on the internal structure of a block (component), showing how its parts interact and communicate via interfaces. Package Diagrams organize model elements into packages, clarifying how different components or systems are grouped and interrelated.
• Operational Process Models: Show the sequence and interrelationship of activities, making it easier to document complex operations with multiple dependencies. Activity diagrams show the flow of control between different tasks in an operation, identifying who performs what task and when. Sequence diagrams illustrate the time-based interactions between system components, showing the order of messages exchanged between them.

For example, in NASA's NISAR mission, SysML is used to describe how the satellite’s sensors interact with ground systems, outlining the flow of data from the satellite to processing centers and how it is distributed to users.

SysML’s ability to handle both hardware and software elements makes it ideal for modeling operational scenarios in ConOps documents that span both domains.

Please, note that parametric modeling is a unique feature of SysML that allows the modeling of quantitative relationships within a system, something not natively supported by UML. This is especially useful in systems engineering, where physical properties such as mass, energy, and performance parameters need to be analyzed and optimized. A parametric model is a specialised form of internal block diagram used to analyse metrics for performance, safety, reliability, and measurable physical characteristics.

The use of UML and SysML in ConOps development aligns with modern systems engineering practices, providing a more dynamic and visual approach to understanding complex system behaviors.

By including detailed diagrams, ConOps documents can bridge the gap between technical and non-technical stakeholders, ensuring that everyone involved has a clear understanding of how the system will function under various conditions.

8. Conclusions.

The Concept of Operations (ConOps) is a foundational document in systems engineering that defines how a system will operate from a user’s perspective.

While the structure and content of ConOps documents vary depending on the industry and governing standards, the purpose remains the same: to align operational objectives with technical requirements and ensure that all stakeholders have a shared understanding of how the system will function.

Standards such as IEEE Std 1362-1998 (R2007), ANSI/AIAA G-043B-2018, and FHWA’s ConOps template provide structured frameworks for developing these documents, ensuring that critical operational scenarios, stakeholder roles, and support requirements are addressed.

Real-world examples from the NISAR and LSST projects demonstrate how ConOps documents are used in complex systems to ensure successful operation and lifecycle management.

As systems become more complex and evolve over time, maintaining ConOps as a living document is essential to ensuring that operational goals continue to be met.

Additionally, the use of modern modeling languages like UML and SysML helps bridge the gap between technical and non-technical stakeholders, making it easier to visualize system interactions and operational processes.

9. References.

Note: Specific hyperlinks have been intentionally omitted due to the nature of this platform.

[1] IEEE Std 1362-1998 (R2007), IEEE Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document, IEEE, 1998.

[2] U.S. Department of Transportation, Concept of Operations Template, Federal Highway Administration website, accessed September 2024.

[3] ANSI/AIAA G-043B-2018, Guide to the Preparation of Operation Concept Documents, AIAA, 2018.

[4] ISO/IEC/IEEE 29148:2011, Systems and Software Engineering – Life Cycle Processes – Requirements Engineering, ISO/IEC/IEEE, 2011.

[5] NASA, NASA-ISRO SAR (NISAR) Mission Science Users’ Handbook. 2019.

[6] Large Synoptic Survey Telescope (LSST). D. Petravick and M. Butler and M. Gelman. LDM-230. Concept of Operations for the LSST Data Facility Services, LSST, 2018.

[7] BSR/AIAA G-043A-201X, Operational Concept Guide for System Development, AIAA, 2011.

[8] Rafael Ferreira da Silva: ConOps.