MBSE example: a CubeSat modeled from needs to verification

Why one example, end to end

Most explanations of model-based systems engineering show one activity at a time, which hides the point. MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. pays off because the activities share one model, so the output of each step is the input of the next, and a change made in one place can be traced to everything it touches. The only way to see that is to follow a single system through every step.

This page does that with a small, fully public example: EO-1, a fictional 6U CubeSat that images farmland in four spectral bands at 4.5 m ground sample distance and delivers calibrated image products within 6 hours of downlink. It is small enough to read in an afternoon and still has a customer, a requirements baseline, interfaces with data rates, budgets, a test campaign with failures, and a change after the baseline.

The steps follow the technical processes of ISO/IEC/IEEE 15288 in their usual order: stakeholder needs, system requirements, architecture definition, analysis, verification. Real projects loop back through them many times.

Get the example model

The whole model is available two ways:

• Download it: CubeSat-EO-1-Example.holarch.json (Holarch project file, about 830 KB). Import it with Manage Projects → Project Files ▾ → Import Project (.json)…. See import and export.
• Create it in Holarch: Manage Projects → Project Files ▾ → New Demo Project builds the same CubeSat EO-1 model in a new project. See open the demo project.

The model uses the Lifecycle Modeling Language (LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models.) for its element types and relationships, and shows SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. diagrams such as block, use case and parametric diagrams as views of the same elements. Nothing in the walk-through depends on the language: the same chain exists in any well-built MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. model. To write such a model as text, see the SysML v2 tutorial.

Step 1: mission and stakeholder needs

A model starts with the people the system serves and what they need from it. For EO-1 there are two main stakeholders: an Imagery Customer, an agricultural analytics company that tasks the mission and receives products, and a Mission Operator who plans passes and watches the spacecraft's health.

The needs are captured three ways, each as part of the model rather than a separate file:

• Use cases. The use case diagram Operate EO-1 System shows six: Request Imagery, Plan Imaging Campaign, Collect Imagery, Receive Image Products, Monitor Spacecraft Health and Recover from Safe Mode. Collect Imagery includes planning; safe-mode recovery extends health monitoring.
• Measures of effectiveness (MOEsMeasure of Effectiveness A measure of how well a system meets the mission need, from the user's point of view.). Six measures on the mission say how well it serves the customer: image quality, daily coverage, data latency, pointing performance, power margin and link availability, each with a threshold and an objective value.
• Raw needs. A whiteboard from the customer workshop holds statements such as "Alert me to crop stress within one day of an overpass" and "Revisit my fields twice a week in the growing season". They are the material requirements are written from.

The link to the next step is explicit. Each requirement records its Source, for example Customer Needs Statement CNS-1 or Mission Concept Review, so a reviewer can ask of any requirement where it came from and get an answer from the model. Tracing each requirement back to its source is the backward half of requirements traceability.

Step 2: system requirements

The needs become a system requirements specification, SRS-001, with 32 requirements in six sections: mission imaging, attitude determination and control, electrical power, command and data handling, communications, and ground segment and operations. Each requirement is a model element with attributes, not a paragraph:

Three practices make the set usable later:

• Rationale on every requirement. The 15% margin in 3.1's rationale is what a reviewer checks when the load changes. Without it, a later change cannot be judged.
• Decomposition and derivation. 1.6 Revisit Time (72 hours) has two children: 1.6.1 Ground Track Repeat (3 days) and 1.6.2 Off-Nadir Imaging (25 degrees). 3.1 is derived from 1.5 Daily Collection Volume, because the imaging load sets the power need.
• A quality check before approval. Three requirements in the example are deliberately weak. 2.5 reads "The spacecraft should recover from safe mode quickly and resume imaging as appropriate": a non-binding verb, an unmeasurable term and an escape clause. A rule-based check flags it, and it stays in Draft.

When the requirements were approved at the System Requirements Review, the specification was saved as a baseline with three sign-offs. Everything after that point is a change against the baseline, which matters in step 8. See the Requirements docs. The verification method chosen here is the first column of the requirements verification matrix.

Step 3: functional analysis

Functional analysis asks what the system must do, before deciding what it is made of. Working from the specification, EO-1 has a top-level function, F0 Perform EO-1 Mission, decomposed into eleven functions, from F1 Separate and Detumble to F11 Process and Deliver Images. Each function is linked to the requirements it satisfies: F3 Generate and Store Power satisfies 3.1 to 3.4, F7 Capture Images satisfies 1.2 to 1.5.

Order and logic go into a functional flow block diagram (FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths.). After separation and array deployment, power and attitude control run in parallel. The imaging cycle repeats each orbit: receive commands, capture, store, then either transmit (nominal) or enter safe mode (fault). Products are delivered at the end.

The table that comes out of this step is the allocation of requirements to functions. Its value is in the gaps: a requirement no function satisfies is either not needed or a missing function. In the example, 2.5 Safe Mode Recovery and 3.5 Battery Thermal Control start without a function, which matches their weak wording; both get attention for the same reason. See the Functional Analysis docs and the guide to functional analysis in systems engineering.

Step 4: physical architecture and allocation

The physical architecture says what the system is made of. EO-1's mission decomposes into the spacecraft, the ground segment, the rideshare launch vehicle and the orbit environment. The spacecraft has six subsystems (payload camera, ADCSAttitude Determination and Control System The spacecraft subsystem that senses and controls which way the spacecraft points., EPSElectrical Power System The subsystem that generates, stores and distributes electrical power, such as solar arrays and batteries., C&DHCommand and Data Handling The spacecraft subsystem that runs the flight computer, handles commands and stores and routes data., communications, structure and thermal) and below them the parts: four reaction wheels, two solar array panels, a battery pack, a power distribution unit, radios.

Allocation connects this structure to the two earlier steps:

• Functions to components. Each function is performed by a component. F3 Generate and Store Power goes to the EPS; its subfunctions go one level lower, F3.1 Convert Sunlight to Power to the solar arrays and F3.2 Store Battery Energy to the battery pack.
• Requirements to components. A requirement is satisfied by the component that answers it: 1.2 to 1.4 by the payload camera, 3.1 by the solar arrays, 3.2 by the battery pack.

With both allocations in place, the model can answer questions that documents answer poorly: which requirements does the EPS carry, which functions stop if the star tracker fails, which parts have no requirement behind them. See the Traceability docs; the functional analysis guide covers allocating functions to components step by step.

Step 5: interfaces

Interfaces are where integration problems appear, so the model records each one as an element with two ends, the items it carries and a capacity. EO-1 has interfaces from IF-01 to IF-15 and a few part-level ones: power lines from the EPSElectrical Power System The subsystem that generates, stores and distributes electrical power, such as solar arrays and batteries. to each subsystem, data buses between the flight computer and the payload, ADCSAttitude Determination and Control System The spacecraft subsystem that senses and controls which way the spacecraft points. and radios, the RF links to the ground, and the customer portal.

The items come from the functional analysis: the function Capture Images produces an Image Strip, the function Store Payload Data receives it, and the interface between the components that perform them, IF-05 Payload Interface, carries it. Because the strip has a data rate (480 Mbps) and the link has a capacity (400 Mbps), the model can check one against the other:

IF-05 is over capacity: 480 Mbps on a 400 Mbps link. In a document-based project that mismatch sits between two documents written by two people. In the model it is a check result with three possible fixes, each traceable: raise the link rating, add on-board compression and lower the strip's rate, or record the open point as a TBRTo Be Reviewed A requirement value that is filled in but still needs to be confirmed. against a requirement.

Interface control documents (ICDsInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram.) are views of the same elements. The ICD for IF-10 Space-to-Ground Link shows the spacecraft and the ground segment with the UHFUltra High Frequency Radio frequencies from 300 MHz to 3 GHz, often used for spacecraft command links. uplink and S-band downlink beneath it, and exports to Word. See the Interfaces docs and the guide to interface control documents and interface management.

Step 6: budgets and analysis

Budgets turn the architecture into numbers that can be held against limits. Each part carries a mass and a power draw with a basis (estimated, calculated or measured), and each basis has its own contingency. The tree rolls them up:

Both totals meet the required 10% margin, but the roll-up shows where the risk sits: the payload camera, at 2.64 kg with contingency against a 2.75 kg allocation, has 4% margin and is flagged low. Measuring the camera would cut its contingency from 10% to 3% and bring it back above 10%.

Three technical performance measures (TPMsTechnical Performance Measure A key technical parameter, such as mass or power, tracked over time against its target and threshold.) track the numbers that matter most over time: spacecraft mass, orbit-average power margin and payload downlink rate. The power margin is marked at risk because it dropped at the Preliminary Design Review when a payload heater load was added.

Engineering analysis lives in the same model. A parametric diagram, EPSElectrical Power System The subsystem that generates, stores and distributes electrical power, such as solar arrays and batteries. Power Budget, holds the equations that size the arrays and the battery (solar power generation, battery depth of discharge, orbit-average array power and a power margin check), with each variable bound to a value on a part. Those equations satisfy 3.1 and 3.3, so they appear in the trace like any other element. A simulation of the operations scenario for one imaging pass, with durations and battery and storage resources, estimates the planning cycle time against requirement 6.5. See the Budgets and TPMs docs and the Simulation docs. Two guides take the analysis further: a trade study with a weighted decision matrix for choosing between design options, and Monte Carlo simulation for turning a point estimate into a probability of meeting the requirement.

Step 7: verification and the RVTM

Verification closes the loop back to the requirements. Each requirement has a planned method (inspection, analysis, demonstration or test) and is verified by one or more test cases. EO-1 has 19 test cases in two suites: spacecraft qualification tests, and communications and ground tests. Each records its procedure, setup, expected result and actual result.

The requirements verification traceability matrix (RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result.) rolls the results up per requirement:

Reading it the way a review board would:

• 11 of 32 passed. The rest is the remaining work, sorted by kind.
• 2.1 Pointing Accuracy failed. TC-04 measured 0.14 degrees on 3 of 20 targets against a 0.1 degree limit. Because 2.2 Pointing Stability shares TC-04, it fails too. In the model the failed test has an issue linked to it, and the risk Reaction Wheel Failure is mitigated by a task to diagnose wheel friction.
• 4.3 Fault Detection failed. TC-09 measured safe-mode entry at 14 seconds against 10, because the watchdog polls too slowly. A task to fix it and rerun TC-09 is on the engineering board.
• 1.6 Revisit Time has no test of its own. Its status rolls up from its children: 1.6.1 passed by analysis, 1.6.2 is not run yet, so 1.6 is not run.
• 2.5 Safe Mode Recovery is unverified. It has no method and no test, the same weak requirement from step 2. Gaps tend to cluster on the requirements that were never written well.

See the Verification docs and the guide to the requirements verification matrix (RVTM).

Step 8: a change, and how it propagates

Here is the reason to keep all of this in one model. After the Preliminary Design Review, the orbit-average load grew to 26 W. Requirement 3.1 changes from 28 W to 30 W, with a new rationale: "Orbit-average load grew to 26 W after PDRPreliminary Design Review A milestone review that confirms the preliminary design meets the requirements and is ready for detailed design.; 30 W keeps 15% margin."

Two things happen at once:

• The requirement leaves Approved. Its text changed after approval, so it goes back to In Review, and the comparison with the SRRSystem Requirements Review A milestone review that confirms the system requirements are complete and agreed before design starts. baseline lists the change word by word.
• Its downstream links become suspect. Every element that satisfies or verifies 3.1 was judged against 28 W. Each of those links is now flagged for review.

The six suspect items span four of the earlier steps:

Each review ends with a decision on the record. TC-06 expects at least 72 W peak power and measured 75.1 W. Through EQ-1.3 (orbit-average power = peak power × 0.62 sunlit fraction × 0.6 power path efficiency), 75.1 W gives about 27.9 W orbit average, short of the new 30 W; the arrays need about 80.6 W peak. So the TC-06 link stays suspect, and the review opens a task to re-check the array sizing and rerun the test against an 80.6 W limit. The solar arrays stay suspect for the same reason until the sizing closes. The RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result. shows a warning sign next to 3.1 and TC-06 until the review is done, so nobody reads the old "Passed" as current.

The same set can be found before a change: an impact analysis from 3.1 one level out highlights the same six elements. That is the practical difference between MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. and a set of documents: the question "what does this change affect?" has an answer that comes from the links, not from memory. See suspect links and the guide to requirements traceability and change impact.

Step 9: documents generated from the model

Reviewers still read documents, and contracts still name them. In an MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. workflow the documents are produced from the model, so they cannot drift from it:

• The specification is a view. SRS-001 in step 2 is the requirements themselves, in document order. Exporting it to Word fills the revision history and approvals from its baselines.
• Matrices are live blocks. A verification status report can contain an RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result. block scoped to SRS-001. The block stores only what to show; the rows are rebuilt each time the document is displayed or exported, and gaps are highlighted.
• Interface and allocation documents come from the ICDInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram. and the functional analysis, as Word files.

When TC-09 is rerun and passes, the report shows 4.3 as passed the next time anyone opens or exports it, without anyone editing the report. See the Document Generation docs; the guide to interface control documents shows the same idea for an ICD.

The whole chain in one table

Following one need through the model shows every link built above:

Try it in Holarch

1. Create the model with Manage Projects → Project Files ▾ → New Demo Project, or import the downloaded file with Import Project (.json)… in the same menu.
2. Open Needs & Requirements → Documents → EO-1 System Requirements Specification and read requirement 3.1.
3. Open Behavior → Functional Analysis for the allocation table and Flow & FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths..
4. Open Interfaces → Interface Register and point at IF-05's Over capacity.
5. Open Architecture → Budgets & TPMsTechnical Performance Measure A key technical parameter, such as mass or power, tracked over time against its target and threshold. and switch Quantity to Power Draw.
6. Open Verification → RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result. and click the Failed card.
7. Open Needs & Requirements → Suspect Links, click Diff on the TC-06 row to see the change it was judged against. Leave it suspect until the rerun; Clear… with a comment records a review that found no impact.
8. Create a document with + New Document, click into its description, choose + → Matrix…, pick the RVTM with the scope EO-1 System Requirements Specification and click Insert.

To build a model of your own system the same way, start from getting started and follow the stages in the SE process guide.

Where to go next

• What is MBSE?: the ideas behind this walk-through.
• Holarch features: requirements, behavior, architecture, interfaces, verification and documents in one model.
• Traceability docs: matrices, impact analysis and coverage.
• LML: the modeling language behind the example.