EO-1 Open MBSE Reference Model

What EO-1 is

EO-1 is a model of a small satellite mission written to teach systems engineering on one connected example. It is small enough to read in an afternoon and complete enough that every step of the lifecycle has real content: needs that trace to requirements, requirements that functions satisfy, functions allocated to logical and physical elements, interfaces between them, analyses that size them, and tests that verify them, with results, failures and a requirement change still being worked.

The model is deliberately imperfect. It holds the gaps, open items and suspect links a real project has at a design review: requirements no function satisfies yet, a failed pointing test with an open issue, a requirement change whose impact is still under review. Finding and closing them is the exercise.

All names, people, organizations and results in the model are invented. EO-1 is not a real spacecraft.

Mission and system context

EO-1 is a 6U CubeSat in a 500 km sun-synchronous orbit that images farmland in four spectral bands at 4.5 m ground sample distance over a 22 km swath, and delivers calibrated vegetation products to an agricultural analytics company within 6 hours of downlink.

In numbers: 3 stakeholder needs, 32 system requirements in six sections, functions F1 to F11 with their decomposition and flows, 6 physical subsystems and 6 logical elements for power and data handling, 26 interfaces, power and mass budgets with technical performance measures, a downlink band trade study, a Monte Carlo imaging-pass simulation, 22 test cases in three suites, 7 risks and one requirement change in work.

The model through the lifecycle

Each stage below names what EO-1 holds there and the guide that teaches the method on it. Read them in order to follow the system from needs to evidence.

1. NeedsNeeds N1 to N3, six use cases and six measures of effectiveness from the customer workshop.How to write good requirements
2. RequirementsSRS-001 with 32 requirements, their parents, derivations and sources, each need traced to the requirements that formalize it.Requirements traceability
3. FunctionsFunctions F1 to F11, decomposed and connected by the items that flow between them, with the requirements each satisfies.Functional analysis
4. ArchitectureLogical elements L1 to L6 for power and data handling, and the physical breakdown that performs the functions.Functional, logical and physical architecture
5. Interfaces26 interfaces with connectors, media, capacities and items, and the C&DH to communications interface control document.Interface control document
6. AnalysisPower equations and margins, budgets, a downlink band trade study and a Monte Carlo imaging pass.Trade study and Monte Carlo guides
7. Verification19 verification test cases in two suites, a validation suite for the needs, and the RVTM that rolls their results up.Requirements verification matrix
8. EvidenceRecorded results with testers, configurations and evidence files, failures with issues, and the impact record of a change to requirement 3.1.Change impact analysis

The MBSE example walk-through follows the whole chain in one page, the verification vs validation guide uses the needs and the validation suite, and the Monte Carlo guide runs the imaging pass. The SysML v2 tutorial writes the power subsystem as text.

Downloads

Every file is version 1.0 of the model and carries the version in its name, so a course or paper can point to exactly the copy it used. The CSV files are UTF-8 with a header row and open in any spreadsheet; they are views of the project file, so you can use EO-1 without Holarch.

To open the model in Holarch, use Manage Projects → Project Files ▾ → Import Project (.json)…. Holarch 2.2.1 and later also build it with New Demo Project.

Use it in a class

EO-1 is built for teaching: every stage has content to inspect and something left to do. Some assignments that work on the model as it ships:

• Trace a need. Follow N2 Twice-Weekly Revisit to requirement 1.6, its children, the functions that satisfy them and the tests that verify them. What evidence is still missing before the need counts as validated?
• Find the gaps. List the requirements no function satisfies and the items nothing traces to, and say for each whether a function is missing or the requirement is not needed.
• Work the change. Requirement 3.1 went from 28 W to 30 W after the design review. Decide what to do with the test that passed against the old value, using the impact record.
• Plan a validation. Write the procedure and acceptance criteria for VAL-01 Customer Alert Pilot in the customer's terms.
• Extend the architecture. Add logical elements for attitude control, allocate functions F4.1 to F4.4 to them, and find the interfaces that follow.

Students can work from the CSV files in any tool, or import the project file into Holarch, which is free for students and instructors. When you hand out the files, keep the credit line with them; the license allows changing them for your course.

Versions

This is EO-1 Reference Model v1.0. A new version gets new file names; earlier versions stay available at their addresses.

• v1.0: first release. The CubeSat EO-1 example with stakeholder needs N1 to N3, the TS-3 Mission Validation suite and a logical architecture layer L1 to L6.

How to cite

Cite the version you used:

Holarch, Angry Pixie Electronics LLC. EO-1 Open MBSE Reference Model, version 1.0 [data set]. https://holarch.app/reference-models/eo-1/. Licensed under CC BY 4.0.

License

The EO-1 Reference Model files are licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0). You may copy, share and adapt them for any purpose, including commercially, if you give appropriate credit, link to the license and say whether you made changes. Credit: "EO-1 Reference Model v1.0, Holarch, Angry Pixie Electronics LLC, CC BY 4.0". Each download carries this notice.

The license covers the model files only. The Holarch software is not covered by it.