Discover how Arcadia/Capella is used to model and simulate concept of operations scenarios for CubeSat-based missions. During this webinar, Danilo Pallamin de Almeida, who worked as a Space Systems Engineer for the NanosatC-BR2 mission at INPE, the Brazilian Institute for Space Research, will present how CubeSat-based missions have been modeled with Capella. The model describing an initial architecture mission and concept of operations (CONOPS) is used to generate a script that configures a satellite simulator with the corresponding mission parameters. You will see how it allows the INPE to: - run concept of operations scenarios simulations, - use the results for power/data-budget analyses and trade studies

4. Modelling & Simulation of CubeSat-based
Missions' Concept of Operations
An application using Arcadia/Capella
Danilo Pallamin de Almeida

5. Introducing Myself
Danilo Pallamin de Almeida
● MSc. Space Systems Engineering & Management @INPE
○ NanosatC-Br2 – SPORT – CRON-1 CubeSat missions
● Mechatronics Engineer @EESC/USP
● Space exploration enthusiast & advocate for democratized access to space
● Why I got into modelling:
○ The higher the complexity of a system, the greater the significance of communication
○ Models can greatly improve communication in engineering
● Currently - Systems Engineer @ EnduroSat

7. Summary
● Introduction
● INPE/CPRIME’s “ForPlan” Satellite Simulator
● Conops2M Modelling Process
● Example Model
● CapellaToForplan (C2F) Plugin
● Trade-study example

8. Introduction
● Work developed during Masters @Brazil’s National Institute for
Space Research (INPE)
○ 2018-2020
○ Dr. Fátima Mattiello Francisco & Dr. Fabiano Luis de Sousa
● Began by investigating modelling practices to assist the early-stage
design phase of Space Missions
● Operation scenario simulation is used for trade-studies at INPE’s
Concurrent Engineering Center CPRIME
○ ForPlan Simulator
● Resulted in a modelling process developed to guide the modelling
of CubeSat-based missions and their CONOPS for early-stage
design studies, preparing for operation scenario simulation
○ Generic (Non-specific) Mission Model
○ NanosatC-Br2 Model
INPE’s CPRIME

9. Concept of Operations (CONOPS)
● How the system will operate to meet stakeholder expectations
● Description of the system’s characteristics from an operational perspective.
● CONOPS at early stages include:
○ Initial physical and logical architecture – space and ground segments
○ Interfaces between elements of the architecture
○ Mission objectives and constraints analysis
○ Operation timelines, modes and scenarios
○ End-to-end communications strategy and data-flow
○ Power and data budget analysis
● Different institutions use different documentation standards
○ European Cooperation for Space Standardization (ECSS): MOCD, MAR, SSUM
○ Large documentation volume, redundant information
○ Use of models can concentrate & simplify – especially for CubeSats (“simpler” operation)

10. Why Capella/Arcadia
● Integrated tool & method
○ Methodological Guidance – Great combination for a
step-by-step process
● Open source tool
○ Reduced barriers of entry
○ Allowed for our plugin development
● Domain-specific Modelling Language
○ Intuitive & comprehensive – friendly when discussing
model with people not used to model standards
● Great previous experiences from colleagues (former
INPE students)
○ Community
Source: Arcadia/Capella website

11. ● Introduction
● INPE/CPRIME’s “ForPlan” Satellite Simulator
● Conops2M Modelling Process
● Example Model
● CapellaToForplan (C2F) Plugin
● Trade-study example

12. INPE/CPRIME’s ForPlan Satellite Simulator
● Functional simulation of satellites and associated
ground segment to reflect operational scenarios of
the mission under analysis
● Verification of mission concept of operations
● Early stage studies at CPRIME
● Simulation core modules​
○ Space environment​
○ Equipment​
○ Power​
○ OBDH / TT&C
● Written in Julia
○ INPE’s Dr. Ronan A. Chagas
○ https://www.ronanarraes.com/
○ ronan.arraes@inpe.br

13. INPE/CPRIME’s ForPlan Satellite Simulator
Modelled simulator
functions
Required inputs
from the user

14. Configuring ForPlan
# 2. Equipment list
# ==============================================================================
equip_1= ForplanSimulatorCore.Equipment{Float64}(
name = "OBC",
f! = ForplanSimulatorCore.equip_always_on!,
params = [torb, 0.0, 0.383, 30.0])
equip_2= ForplanSimulatorCore.Equipment{Float64}(
name = "Receiver",
f! = ForplanSimulatorCore.equip_always_on!,
params = [torb, 0.0, 0.193, 0.0])
equip_3= ForplanSimulatorCore.Equipment{Float64}(
name = "Transmitter",
f! = ForplanSimulatorCore.equip_on_ground_station!,
params = [torb, 0.0, 0.0, 1.078, 0.0, 0.0, 0])
equip_4= ForplanSimulatorCore.Equipment{Float64}(
name = "Magnetometer",
f! = RoiOp,
params = [torb, 0.016, 96.0,
[[-60.0, 0.0, -90.0, -20.0]]])
equip_5= ForplanSimulatorCore.Equipment{Float64}(
name = "EPS",
f! = ForplanSimulatorCore.equip_always_on!,
params = [torb, 0.0, 0.250, 0.0])
Core method
Equipment name
Operation function
Operation parameters
Equipment instance

15. ● Introduction
● INPE/CPRIME’s “ForPlan” Satellite Simulator
● Conops2M Modelling Process
● Example Model
● CapellaToForplan (C2F) Plugin
● Trade-study example

16. Conops2M Modelling Process
● Developed based on Arcadia
● A set of sequential steps
○ generate a model of a space mission concept
of operations
○ prepare operation scenarios for simulation
● Begin at high-level abstraction: Mission
objectives as operation capabilities
● Iteratively decompose functions until we reach
equipment-level on spacecraft & facilities for
ground segment
● Model parameters for operation scenario
simulation
○ Transform model into simulator input

17. Generating the Simulator Configuration Script
● ForPlan is configured through a Julia script
● Capella is Eclipse-based
○ Language built on EMF
○ Capella 1.3.1
● Developed a plugin to retrieve model elements and generate Julia
code based on their attributes
○ ADVANCE Project – Budapest University of Technology and Economics
○ Bence Graics & Dr. Vince Molnár
○ Xtend
■ Specifically designed for model transformation and code generation
● Defined rules for a Class Diagram architecture and the creation of
class instances according to each model element
○ Traverse instance models and derive arbitrary code

18. ● Introduction
● INPE/CPRIME’s “ForPlan” Satellite Simulator
● Conops2M Modelling Process
● Example Model
● CapellaToForplan (C2F) Plugin
● Trade-study example

19. NanosatC-Br2 Mission
● Second satellite NanosatC-BR programme
○ INPE & UFSM Cooperation​
● Scientific & Technological mission:​
○ Collect data to better understand the Magnetic Anomaly
of the Southern Atlantic (SAMA) (SLP Payload)
○ Collect data to better understand the formation of
plasma bubbles in the ionosphere (SLP Payload)​
○ Validate in-orbit the Fault Tolerant Attitude
Determination System (SDATF Payload)
○ Validate in-orbit a radiation tolerant FPGA and
ASIC system (SMDH Payload)
● Develop human resources with experience in
space mission
NanosatC-BR2 moments after completing AIT at LIT​

20. Operational Analysis
Define objectives
as Operational
Capabilities
Associate
capabilities to
entities and actors
involved
“What the users of
the system need to
accomplish”

21. Operational Activities and Architecture

22. System Analysis
Define System
boundaries and
what your sollution
will perform

23. Logical Data Flow – Non-specific mission
Logically how data
will be collected
Ground Segment
Functions
Space Segment
Functions
External actor
functions

24. Logical Data Flow – Br2
How each payload
will collect data

25. Logical Architecture – Br2
Separate into
Space and Ground
Segments

26. Physical Data Flow – Space Segment – Non-specific Mission
Decompose
logical
functions into
equipment-
level functions
Basic platform
functions

27. Physical Data Flow – Space Segment – Br2

28. Physical Architecture – Space Segment
Allocate
functions to
equipment at
the desired
subdivision
level
Iterative
process –
decomposing
functions into
specific
equipment

29. Physical Data Flow – Ground Segment
Decompose
logical functions
for Ground Station
& Mission Control
Center
Represent the
functional flow for
how users will acces
data

30. Physical Architecture – Ground Segment

31. Exchange Scenarios

32. ● Introduction
● INPE/CPRIME’s “ForPlan” Satellite Simulator
● Conops2M Modelling Process
● Example Model
● CapellaToForplan (C2F) Plugin
● Trade-study example

33. CapellaToForplan (C2F) Plugin
● Class Diagram
○ Organized in Data Packages
○ No support for multiple meta-levels
● Each Data Package has specific
conversion rules
○ Hard-coded names
● Each Class has specific attributes
● Equipment OperationFunction()
○ AlwaysOn, OnGroundStation,
TimedOp, RoiOp

34. Class Diagram – NanosatC-Br2

35. Class Diagram – Adding Property Values

36. Class Diagram – Operation Function

37. CapellaToForplan (C2F) Plugin

38. C2F Plugin Execution – Script Generation

39. Automatic Generated Code Example

40. Summary
● Introduction
● INPE/CPRIME’s “ForPlan” Satellite Simulator
● Conops2M Modelling Process
● Example Model
● CapellaToForplan (C2F) Plugin
● Trade-study example

41. NanosatC-Br2 Trade-Study Example
● NCBR2 had already passed design phase
● However, payloads and their operation were altered during development
● Power & Data budget limitations
● 3 Operation Scenarios balancing payload operation time with power and data budgets
● Polar orbit
● 2 Ground Stations
○ Natal & Santa Maria
● 2600 mAh battery pack
● No Sun-pointing

42. Scenario 1
● Three payloads AlwaysOn
○ Max operation parameters
● Battery depleted in 34 hours
● Data through the roof

43. Scenario 2
● TimedOp – 1 Payload each orbit
● Power balance stable
● Still too much data

44. Scenario 3
● SLP as RoiOP
○ AMAS & Equator
● 1 Orbit each for SMDH and SDATF
○ Lower sampling frequency
○ Lower data volume
● Valid operation scenario
○ Agreed with stakeholders
○ Using simulation results

45. Conclusion
● Model from mission operation objectives to initial architecture for simulation and analysis
● Quick way to generate different operation scenarios without having to directly code for the simulator
○ Also simpler than manually coding for every scenario
○ Can go directly to class diagram
● Result were used to drive the final CONOPS for NCBR2 mission
● Arcadia & Capella were great for developing the models and the process
○ Short learning curve for the basics

46. Danilo Pallamin de Almeida
Space Systems Engineer, MSc.
danilopallamin@gmail.com
danilo@endurosat.com
+359 089 959 3221
inpe.br/crs/nanosat/missao/nanosatc_br2
inf.mit.bme.hu
Thanks for
listening!
Any questions??

47. Danilo Pallamin de Almeida
Space Systems Engineer, MSc.
danilopallamin@gmail.com
danilo@endurosat.com
+359 089 959 3221
inpe.br/crs/nanosat/missao/nanosatc_br2
inf.mit.bme.hu

48. Danilo Pallamin de Almeida
Space Systems Engineer, MSc.
danilopallamin@gmail.com
danilo@endurosat.com
+359 089 959 3221
inpe.br/crs/nanosat/missao/nanosatc_br2
inf.mit.bme.hu