Case Study: “MBSE in Aerospace: Designing a CubeSat Mission with SysML”
🚀 Launching Precision: How MBSE and SysML Transformed Our CubeSat Mission Design
In the new era of space democratization, CubeSats are enabling small teams—from universities to startups—to design, build, and launch satellites at a fraction of traditional costs. But just because they’re small doesn’t mean they’re simple.
When our team set out to design a CubeSat for Earth observation, we knew we needed more than PowerPoint slides and spreadsheets. We chose Model-Based Systems Engineering (MBSE) with SysML to take our mission from concept to model—and it changed everything.
🛰️ Mission Overview
Our CubeSat mission aimed to demonstrate a small Earth-imaging payload capable of capturing low-resolution imagery and transmitting it to a university-based ground station. The mission also included secondary objectives, such as evaluating the performance of a new battery management system and thermal regulation concept.
We were a multidisciplinary team of engineering students working under a university aerospace research initiative, with limited funding, tight timelines, and even tighter launch constraints. From thermal margins to antenna size, every detail had to be carefully coordinated.
🔧 Why We Chose MBSE and SysML
At first, we relied on traditional documents—spreadsheets for requirements, PowerPoint for subsystem interfaces, and Word docs for design notes. But very quickly, we ran into problems:
- Inconsistent requirements
- Manual traceability headaches
- Misaligned subsystem assumptions
That’s when we pivoted to MBSE. We wanted a way to:
- Ensure requirements traceability from top-level goals down to components
- Model interfaces and behaviors early to prevent integration issues
- Visualize complex relationships between components
- Build a digital thread from concept to testing
We selected SysML (Systems Modeling Language) because it’s open, tool-agnostic, and purpose-built for system design. We used Cameo Systems Modeler as our primary tool.
🧩 Modeling the CubeSat with SysML
MBSE helped us break down the complexity of our CubeSat into manageable, visual models.
🌐 System Context Diagram
We started with a context diagram showing external actors:
- Ground Station
- Launch Vehicle
- Orbital Environment
This clarified how our CubeSat interacted with its ecosystem and helped define initial interfaces and constraints.
🧱 Block Definition Diagrams (BDDs)
We used BDDs to decompose the system into high-level blocks:
- Bus
- Payload
- Power System
- Communication System
- Attitude Determination and Control System (ADCS)
- Thermal System
Each block was defined with key properties (mass, volume, power) and operations (e.g., image capture, data downlink).
🔄 Internal Block Diagrams (IBDs)
We used IBDs to define the internal architecture and physical/logical interfaces:
Power connections between solar panels, batteries, and avionics
Data connections between the payload, on-board computer, and downlink systems
🎯 Use Case Diagram
The Use Case diagram described major interactions, such as:
Operator sends command → CubeSat captures image → Data transmitted back
This helped align user expectations with system capabilities.
🔁 Activity and State Machine Diagrams
We modeled system behavior:
Activity diagrams represented mission operations like image acquisition
State machine diagrams defined transitions:
Launch → Deployment → Commissioning → Mission Operations → Deorbit
These behavioral models gave our software and testing teams a consistent operational flow to build against.
✅ Benefits We Observed
The results were immediate and powerful.
🔗 Traceability
We connected requirements to components, behaviors, and test cases. This traceability helped ensure no mission-critical requirement fell through the cracks.
🤝 Interface Clarity
Interface definitions in IBDs revealed mismatches between subsystems—issues we fixed before hardware integration.
🧪 Behavior Simulation
State machine diagrams allowed us to simulate operational modes, helping us identify design gaps like incomplete transitions during eclipse periods.
👥 Team Collaboration
SysML served as a shared visual language. Hardware and software engineers, systems leads, and even advisors could all understand the model—even if they couldn’t read C++ or wiring diagrams.
🧠 Lessons Learned
Start Simple
We didn’t model everything at once. We began with mission-critical paths (e.g., image capture and downlink), then expanded iteratively.
The Right Tool Matters
Cameo was powerful but required training. We also tested Papyrus and GENESYS but preferred Cameo’s simulation and plugin ecosystem.
Stakeholder Buy-In
Once we showed stakeholders a SysML model instead of a 60-slide deck, engagement skyrocketed. The clarity was undeniable.
🔄 What We’d Do Differently Next Time
1. Start parametric modeling earlier to analyze performance tradeoffs (e.g., battery sizing vs. mission duration).
2. Use automated model validation sooner to check for incomplete interfaces.
3. Invest more in model version control, as collaborative editing was occasionally chaotic.
🎯 Conclusion: MBSE is for Everyone
Model-Based Systems Engineering isn’t just for massive NASA missions. If you’re designing a CubeSat—or any complex system—you can benefit from the clarity, consistency, and confidence MBSE provides.
We didn’t just build a model. We built a system we could trust.
Are you working on a CubeSat or smallsat mission? Want help modeling it with MBSE? Please contact us!
