What Is a Concept of Operations (ConOps) for Space Systems?

A Concept of Operations — ConOps — is the document that answers the question: how will this system actually be used? It is written before requirements are derived, before interfaces are defined, and well before any hardware is designed. Its purpose is to describe the operational environment, the actors who interact with the system, the mission scenarios the system must support, and the high-level functional flows that must occur for the mission to succeed.

In most engineering domains, a ConOps is valuable. In space systems, it is foundational in a way that has no real equivalent. The decisions embedded in a ConOps — how often a spacecraft can communicate with the ground, what level of onboard autonomy is assumed, what the fault management philosophy will be, what the ground system architecture looks like — cascade into every subsequent engineering decision across every discipline. A propulsion engineer sizing fuel margins, a guidance engineer selecting an attitude control architecture, and a software engineer defining safe mode behavior are all, whether they know it or not, executing decisions that were locked in when someone wrote the ConOps.

This article defines what a ConOps is in the space systems context, describes the NASA and ESA frameworks that govern how ConOps documents are structured, explains how a ConOps feeds into system requirements and Model-Based Systems Engineering (MBSE) models, and examines how modern platforms allow ConOps-level scenarios to become traceable, living artifacts rather than static documents.

What a ConOps Is — and What It Is Not

The single most common ConOps failure mode is treating it as an early draft of the requirements document. It is not. The distinction matters operationally.

A requirements document specifies what the system shall do. A ConOps describes how the system will be operated to accomplish its mission. Requirements are normative — they establish testable, verifiable constraints. A ConOps is descriptive — it establishes context, intent, and operational assumptions.

This distinction has a practical consequence: a ConOps is written in the language of operators and mission stakeholders, not systems engineers. It should be readable by a mission operations manager who has never written a requirement in their life. If your ConOps reads like a requirements document, it is doing the wrong job. If your requirements document reads like a ConOps, your requirements are not verifiable.

A well-formed space systems ConOps contains, at minimum:

  • Mission overview and objectives: What the mission is trying to accomplish, stated in operational terms.
  • Operational environment: The orbital regime, radiation environment, thermal environment, communication architecture, and any constraints imposed by the launch vehicle or ground network.
  • Stakeholder and user roles: Who interacts with the system — mission operators, ground system teams, payload scientists, safety officers — and what authority each role holds.
  • Mission phases: Typically launch and early operations (LEOP), commissioning, nominal operations, contingency operations, and end of life. Each phase has distinct operational characteristics.
  • Operational scenarios: Specific narrative descriptions of how the system behaves during representative events — a nominal data downlink pass, a safe mode entry, a maneuver sequence, a ground contact loss recovery.
  • System modes: The discrete operational states the spacecraft can occupy, the conditions that drive mode transitions, and the expected operator actions at each transition.
  • Autonomy and ground interaction model: Explicitly, how much the spacecraft decides on its own versus waits for ground commands, and what the assumed ground contact cadence is.
  • Fault management philosophy: At a high level, what happens when something goes wrong — is the default to safe mode? To continue on backup hardware? To wait for ground intervention?

NASA and ESA ConOps Frameworks

NASA: ANSI/AIAA G-043 and NPR 7123.1

NASA’s primary reference for ConOps development is ANSI/AIAA G-043, Guide for the Preparation of Operational Concept Documents, which NASA has adopted as a foundational reference across programs. NASA’s own systems engineering requirements are codified in NPR 7123.1, the NASA Systems Engineering Processes and Requirements document, which defines the ConOps as a required product at the System Definition Review (SDR) and as an input to the System Requirements Review (SRR).

The NASA ConOps structure emphasizes mission phases as the organizing principle. For each mission phase, the ConOps must describe the operational concept — what the system is doing, what the operators are doing, what the ground system is doing, and what the critical constraints are. This phase-centric structure reflects NASA’s operational experience: the difference between LEOP and nominal operations is not merely procedural, it is architectural. Systems that assume nominal-operations contact schedules during LEOP will fail.

NASA also places explicit emphasis on user roles and responsibilities. The ConOps must name the human elements — flight director, spacecraft controller, ground system engineer, payload scientist — and describe their authorities and interactions with the system. This is not bureaucratic formalism; autonomous spacecraft still have humans making decisions about software updates, maneuver approvals, and anomaly responses. Failing to define those roles in the ConOps means failing to design the command and data handling architecture that supports them.

ESA: ECSS-E-ST-10C

ESA’s framework is the ECSS-E-ST-10C, System Engineering — Part C: System Concept Document, which ESA programs use in conjunction with ECSS-M-ST-10C for project planning. The ESA approach centers on operational scenarios and system modes as the primary structuring elements, rather than mission phases.

ECSS-E-ST-10C requires that the ConOps — which ESA typically calls a Mission Operations Concept or Mission Concept Document at early stages — define a complete set of operational scenarios covering nominal operations, degraded operations, and contingency operations. Each scenario must identify the triggering conditions, the system’s response, the operator actions required, and the success criteria.

The ESA framework also requires explicit treatment of the ground segment interface: how the spacecraft is commanded, what telemetry is expected, what monitoring is performed, and what the turnaround time for ground decisions is. For ESA science missions operating at L2 or beyond, this ground segment model drives autonomy requirements that then drive avionics architecture choices. The ConOps is where that chain starts.

Where the Frameworks Converge

Despite structural differences, NASA and ESA ConOps frameworks converge on a common principle: the ConOps must be specific enough to drive requirements derivation, but not so specific that it becomes a requirements document. Both frameworks treat the ConOps as a bridge document — it translates mission objectives and stakeholder needs into the operational vocabulary that systems engineers then use to write requirements.

Both frameworks also treat the ConOps as a living document through at least Phase B (NASA) or Phase B/C (ESA). Operational assumptions change as mission design matures, and the ConOps must reflect those changes. A ConOps frozen at mission formulation that is never updated is not a ConOps — it is a historical artifact.

How ConOps Feeds Requirements and MBSE Models

The ConOps-to-requirements path has a defined logic, and breaking that logic is expensive.

Step one: Operational scenarios become functional requirements. Each scenario described in the ConOps implies a set of functions the system must be capable of performing. A scenario describing a ground contact loss recovery implies requirements for onboard storage, safe mode entry logic, beacon transmission, and ground acquisition procedures. These functional requirements are traceable to the scenario — which means if the scenario changes, the requirements that derived from it are identified immediately.

Step two: System modes become mode transition requirements. Every mode defined in the ConOps must be specified in the requirements as a discrete system state with defined entry conditions, exit conditions, and behavior in mode. This is where ConOps vagueness causes the most damage. A ConOps that says “the spacecraft shall enter safe mode when an anomaly occurs” without defining what constitutes an anomaly forces the requirements team to make that decision — without the operational context that the ConOps was supposed to provide.

Step three: Autonomy assumptions drive software architecture requirements. The autonomy level defined in the ConOps — typically expressed as a level on the NASA Autonomous Control Tier (ACT) scale or an equivalent framework — directly drives what the onboard software must be capable of deciding without ground intervention. This is not a software requirement that appears from nowhere; it is a direct derivation from the operational model in the ConOps.

Step four: ConOps scenarios become use cases in MBSE models. In a model-based approach, operational scenarios from the ConOps are formalized as use cases or operational activity models in SysML or the equivalent modeling language being used. The ConOps scenario provides the narrative; the MBSE model provides the formal structure that enables analysis. The two must be consistent — and maintaining that consistency requires that the ConOps scenarios are not buried in a PDF that no one links to the model.

How Modern Platforms Implement ConOps-Level Traceability

The traditional approach to ConOps in space programs is to write it in a word processor, review it, approve it, and baseline it as a PDF. The document then lives in a document management system, and the connection between the operational scenarios it describes and the requirements that derived from them exists only in the minds of the engineers who did the derivation work.

This approach has a failure mode that is so common it has become normalized: requirements change, scenarios change, and the ConOps stops reflecting what the system is actually being designed to do. By the time the program reaches Critical Design Review, the ConOps has become archaeological — a record of what the team thought in Phase A, not a living description of operational intent.

Graph-based requirements management platforms address this structurally. When ConOps scenarios are created as first-class model elements — not documents, but nodes in a graph — they can carry relationships to the requirements that derive from them. A scenario node for “Autonomous Safe Mode Entry on Bus Undervoltage” is linked to the functional requirements for fault detection, the mode transition requirements for safe mode entry, the power system requirements for bus voltage monitoring, and the software requirements for onboard fault response logic.

Flow Engineering implements this model explicitly. Operational scenarios from a ConOps are structured as graph artifacts in Flow Engineering’s requirements model, with defined relationship types — derives, traces, refines — connecting scenarios to system-level requirements and from there to subsystem requirements. When a ConOps scenario is updated because the mission operations team has revised the ground contact model, Flow Engineering surfaces every requirement that traces to that scenario, allowing the team to assess impact in minutes rather than weeks of manual document review.

This matters particularly for space programs because the ConOps-to-requirements chain in space systems is long and branching. A single ConOps scenario — the spacecraft’s behavior during a multi-day ground contact blackout — may drive requirements across five or six engineering disciplines simultaneously: power, thermal, communications, flight software, fault management, and operations procedures. Tracking those derivations manually in a document-based environment is where programs lose traceability integrity.

Flow Engineering’s graph-based structure also enables ConOps scenarios to connect directly into MBSE model elements. Rather than maintaining a parallel narrative document and a formal SysML model that are loosely synchronized, teams can use Flow Engineering to maintain scenarios as structured artifacts that serve both the narrative function — readable by mission operations stakeholders — and the formal traceability function that feeds systems engineering work products.

The deliberate trade-off in this approach is specialization: Flow Engineering is built for systems engineering teams doing requirements and traceability work, not for document authoring or program scheduling. Programs that need a single platform to manage ConOps documents, requirements, model views, verification records, and program schedules will need to integrate Flow Engineering with other tools rather than replace everything. For systems engineering teams focused on getting requirements traceability right from ConOps through verification, that focus is exactly what the platform is designed to deliver.

Practical Starting Points

For a program beginning ConOps development, the following practices reduce the downstream cost of ConOps-to-requirements disconnection:

Write scenarios first, sections second. Before filling in standard ConOps sections, write five to ten operational scenario narratives with the mission operations team. These scenarios will reveal what the operational model actually is — and where the team disagrees — faster than any other technique.

Name your autonomy level explicitly. Do not say “the spacecraft shall operate autonomously.” Say “the spacecraft shall execute fault responses at ACT Level 2, with ground intervention required for all mode transitions above safe mode.” That specificity is what makes the ConOps drive software architecture requirements rather than leaving them for later derivation.

Define mode transition triggers, not just modes. Listing system modes without defining what causes each transition gives the requirements team an incomplete picture. The trigger — the sensor reading, the timer expiry, the ground command — is often what drives the most consequential subsystem requirements.

Structure scenarios for traceability from day one. If your ConOps scenarios live in a structured model where they can carry explicit relationships to derived requirements, you avoid the retrofit problem of trying to reconstruct traceability after the fact. Starting in a graph-based environment costs less effort at the beginning than re-establishing lost traceability later.

Update the ConOps at every major design milestone. The ConOps is not frozen at SRR. Operational assumptions that change during design — because the ground network changed, because the autonomy budget changed, because the payload power profile changed — must be reflected in the ConOps before they propagate into requirements revisions that are not traceable to an updated operational rationale.

Honest Assessment

A ConOps done well is the most cost-effective systems engineering investment a space program can make. The decisions it captures — operational environment, autonomy model, fault philosophy, ground interaction model — are decisions that will be made by someone at some point. Making them explicitly, in the ConOps, in the presence of mission operations stakeholders, before requirements are written, is categorically cheaper than discovering disagreements during design reviews or, worse, during flight operations.

A ConOps done poorly is a different kind of expensive: it creates the illusion that operational assumptions have been agreed upon when they have not, and it generates requirements that turn out to be internally inconsistent because the operational model they derived from was never coherent. The solution is not a better document template. It is treating operational scenarios as engineering artifacts that carry the same traceability discipline as requirements — because they are the source from which requirements derive.