Project Logs

Collapse

• v0.7.0 — Generated Runtime Skeletons

  Fabrizio Rovelli • 4 days ago • 0 comments

  OrbitFabric v0.7.0 introduces the first generated runtime-facing contract binding layer.

  This is a significant step, but the boundary is important.

  Generated Runtime Skeletons are not flight software.

  They are not an onboard runtime, not a scheduler, not a HAL, not a command dispatcher and not a command queue.

  They are contract-facing software artifacts derived from the validated Mission Model.

  Why this release matters

  Previous OrbitFabric releases focused on making the mission data chain explicit.

  The project could already describe telemetry, commands, events, faults, payload contracts, data products, storage intent, downlink intent, contact windows, commandability assumptions and end-to-end data-flow evidence.

  v0.7.0 is the first release where that contract becomes directly visible to implementation code.

  The chain now becomes:

  Mission Model
          -> validation and linting
          -> RuntimeContract
          -> generated C++17 contract bindings
          -> host-build smoke validation
          -> user implementation outside generated/

  This is the key shift.

  OrbitFabric is no longer only producing documentation, reports and deterministic scenario evidence.

  It can now generate a software-facing boundary that implementation code may include, compile and implement against.

  RuntimeContract

  v0.7.0 introduces RuntimeContract.

  RuntimeContract is an intermediate model representing the software-facing subset of the validated Mission Model.

  It is the bridge between the declarative mission contract and generated runtime-facing files.

  The generation flow is:

  Mission Model
          -> structural and semantic validation
          -> engineering linting
          -> RuntimeContract construction
          -> profile-specific generator
          -> generated runtime-facing artifacts

  The current generation profile is:

  cpp17

  This is deliberately narrow.

  The goal is not to generate onboard behavior.

  The goal is to expose the validated contract surface in a deterministic software-facing form.

  The new generator command

  The new command is:

  orbitfabric gen runtime examples/demo-3u/mission/

  orbitfabric gen runtime examples/demo-3u/mission/ 

  The default generated output is:

  generated/runtime/cpp17/ 

  The generated C++17 profile currently emits:

  generated/runtime/cpp17/runtime_contract_manifest.json
  generated/runtime/cpp17/CMakeLists.txt
  generated/runtime/cpp17/include/orbitfabric/generated/mission_ids.hpp
  generated/runtime/cpp17/include/orbitfabric/generated/mission_enums.hpp
  generated/runtime/cpp17/include/orbitfabric/generated/mission_registries.hpp
  generated/runtime/cpp17/include/orbitfabric/generated/command_args.hpp
  generated/runtime/cpp17/include/orbitfabric/generated/adapter_interfaces.hpp
  generated/runtime/cpp17/src/orbitfabric_runtime_contract_smoke.cpp

  These are generated artifacts.

  They are reproducible and disposable.

  User implementation code must live outside generated/.

  What the generated bindings expose

  The generated runtime-facing contract bindings expose several kinds of information.

  Identifier headers provide deterministic strongly typed identifiers for model elements such as:

  ModeId
  TelemetryId
  CommandId
  EventId
  FaultId
  PacketId
  PayloadId
  DataProductId
  StoragePolicyId
  DownlinkPolicyId 

  Static registries expose contract metadata such as model IDs, symbol names, value types, units, command targets, event severities, fault metadata and data product attributes.

  Command argument structs expose the declared shape of command arguments.

  For example:

  struct PayloadStartAcquisitionArgs {
      std::uint16_t duration_s;
  };

  This struct defines the contract-facing command argument shape.

  It does not parse packets.

  It does not validate permissions.

  It does not enqueue commands.

  It does not execute the command....

  Read more »

• v0.6.0 — End-to-end mission data flow evidence

  Fabrizio Rovelli • 5 days ago • 0 comments

  OrbitFabric v0.6.0 adds the first end-to-end Mission Data Flow Evidence slice.

  The previous logs walked through the individual contract layers:

  payload contracts,
  data products,
  storage intent,
  downlink intent,
  contact windows,
  downlink flows,
  commandability rules,
  and autonomy assumptions.

  v0.6.0 connects those layers into one inspectable evidence chain.

  It does not make OrbitFabric a runtime.

  It makes the declared mission-data path traceable.

  From contract layers to evidence

  Until now, each release added another part of the Mission Data Contract.

  v0.3.0 made data products and storage intent explicit.

  v0.4.0 connected data products to contact windows and downlink flow contracts.

  v0.5.0 added commandability and autonomy contracts, making command sources, command rules and recovery assumptions visible.

  v0.6.0 adds the next question:

  if a command is expected to produce mission data, can OrbitFabric trace that declared data product through storage intent, downlink intent, eligible downlink flow, contact window assumption and scenario evidence?

  The contract chain now becomes:

  command expected effect
          -> data product
          -> storage intent
          -> downlink intent
          -> eligible downlink flow
          -> matching contact window
          -> scenario evidence
          -> generated documentation
          -> JSON report evidence

  This is the first end-to-end evidence slice in OrbitFabric.

  What changed in v0.6.0

  v0.6.0 introduces:

  • command-declared data product effects
  • command linting for expected data product references
  • scenario data-flow assertions
  • scenario reference validation for data-flow expectations
  • deterministic data-flow evidence recording during simulation
  • JSON simulation reports with data_flow_evidence
  • generated data_flow.md documentation
  • a dedicated data-flow documentation generator
  • a new demo scenario: payload_data_flow_evidence.yaml

  The important part is not that another generated file exists.

  The important part is that the Mission Model can now describe and check a declared path from command intent to mission-data movement assumptions.

  Command-declared data product effects

  Commands may now declare that they are expected to produce or trigger one or more data products.

  A shortened example looks like this:

  expected_effects:
    data_products:
      - payload.radiation_histogram

  This makes the command-to-data-product relationship explicit.

  If a command claims to produce a data product that is not declared in data_products.yaml, OrbitFabric should fail early.

  That is where the new command diagnostics are useful:

  OF-CMD-008
  OF-CMD-009

  The intent is simple:

  a command expected effect should not silently point to a non-existing mission-data object.

  Scenario data-flow assertions

  Scenarios can now assert that a declared data-flow path exists.

  A shortened example looks like this:

  expect:
    data_flow:
      data_product: payload.radiation_histogram
      triggered_by_command: payload.start_acquisition
      storage_intent_declared: true
      downlink_intent_declared: true
      eligible_downlink_flow: science_next_available_contact
      contact_window: demo_contact_001

  This does not execute real storage.

  It does not execute real downlink.

  It asks whether the declared Mission Model contains a coherent contract-level path for that data product.

  The scenario loader validates references before execution.

  The new scenario diagnostics cover missing or invalid references in data-flow expectations:

  OF-SCN-014
  OF-SCN-015
  OF-SCN-016
  OF-SCN-017

  What the simulator records

  During deterministic host-side scenario execution, OrbitFabric records contract-level data-flow evidence when an accepted command declares data product effects.

  The demo scenario exercises a chain like this:

  payload.start_acquisition
  ...

  Read more »

• v0.5.0 — Commandability and autonomy contracts

  Fabrizio Rovelli • 5 days ago • 0 comments

  OrbitFabric v0.5.0 adds the first Commandability and Autonomy Contract slice.

  The previous logs focused on the mission-data chain:

  what the spacecraft produces,
  where data products are intended to be stored,
  how they become eligible for downlink,
  and which declared contact assumptions support that path.

  v0.5.0 adds the next contract question:

  how are commands intended to be used, constrained, confirmed, and referenced by declared autonomous or recovery assumptions?

  This is still contract-level modeling.

  It is not command execution.

  Why commandability belongs in the contract layer

  A small spacecraft mission does not only need to describe telemetry, data products, storage intent and downlink assumptions.

  It also needs to describe how commands are expected to be used.

  For example:

  Can this command be dispatched from ground?
  Does it require a contact assumption?
  Which mode should allow it?
  Does it require explicit confirmation?
  What event or telemetry evidence is expected after it runs?
  Can an autonomous recovery assumption dispatch a command?
  Which fault should lead to which recovery intent?

  Those are not only runtime questions.

  They are also mission-data contract questions.

  If a payload acquisition command exists, but nobody declares when it is commandable, which source may dispatch it, what confirmation is expected, or how recovery should stop it during a battery fault, then part of the mission behavior is still implicit.

  OrbitFabric v0.5.0 tries to make that implicit layer visible.

  What v0.5.0 adds

  The new optional domain is:

  mission/commandability.yaml 

  It can describe:

  • command sources
  • commandability rules
  • command confirmation intent
  • autonomous action assumptions
  • recovery intents

  The chain now extends one step further:

  Payload Contract
          -> Data Product Contract
          -> Storage Intent
          -> Downlink Intent
          -> Contact Window Assumption
          -> Downlink Flow Contract
          -> Commandability and Autonomy Contract

  This does not turn OrbitFabric into a command system.

  It adds another declared consistency layer.

  Example from the demo mission

  A shortened excerpt from the synthetic demo mission looks like this:

  commandability:
    sources:
      - id: ground_operator
        type: ground
        requires_contact: true
        contact_profile: primary_ground_contact
  
      - id: onboard_autonomy
        type: autonomous
        requires_contact: false
  
    rules:
      - id: payload_start_ground_rule
        command: payload.start_acquisition
        sources:
          - ground_operator
        allowed_modes:
          - NOMINAL
        confirmation: required
        expected_events:
          - payload.acquisition_started
        expected_effects:
          telemetry:
            payload.acquisition.active: true
          mode_transition:
            to: PAYLOAD_ACTIVE
  
    autonomous_actions:
      - id: stop_payload_on_battery_low
        trigger:
          fault: eps.battery_low_fault
        dispatches:
          command: payload.stop_acquisition
          source: onboard_autonomy
        expected_events:
          - payload.acquisition_stopped
  
    recovery_intents:
      - id: payload_battery_low_recovery
        fault: eps.battery_low_fault
        target_mode: DEGRADED
        commands:
          - payload.stop_acquisition

  This is intentionally minimal.

  It is not a real operator...

  Read more »

• New public minislices: from generic CubeSat to communications-oriented mission data contracts

  Fabrizio Rovelli • 6 days ago • 0 comments

  Today I added a new set of public minislice examples to OrbitFabric.

  The goal was to move beyond a single synthetic demo and show how the same model-first contract approach can be specialized into several small, recognizable CubeSat-style mission data patterns.

  The new examples are:

  examples/university-cubesat-minislice/
  examples/oresat-inspired-minislice/
  examples/finch-inspired-minislice/
  examples/spacelab-inspired-communications-minislice/
  

  Each minislice is intentionally small, public-material-derived or synthetic, and focused on OrbitFabric’s core scope:

  telemetry
  commands
  events
  faults
  modes
  packets
  payload contracts
  data products
  contact windows
  downlink flows
  scenario evidence
  generated documentation
  

  OrbitFabric is still not flight software, not an OBC firmware, not a dynamic simulator and not a ground segment.

  These examples are contract-layer demonstrations.

  1. Generic university CubeSat minislice

  The first example is the baseline:

  examples/university-cubesat-minislice/
  

  It models a generic university CubeSat mission-data chain:

  payload data generated
  → low-power warning
  → constrained low-rate contact
  → health and critical data prioritized
  → payload data partially downlinked
  → remaining data kept pending onboard
  → scenario evidence explains the result
  

  This example is fully synthetic and acts as the clean baseline for the more specific public-inspired examples.

  2. OreSat-inspired minislice

  The second example is:

  examples/oresat-inspired-minislice/
  

  This is a public conceptual demo inspired by the OreSat ecosystem.

  It focuses on a CubeSat-style pattern involving:

  beacon / housekeeping priority
  power-aware operations
  C3-style command and data handling
  CFC-style payload data
  constrained downlink
  retained payload backlog
  

  It is not an official OreSat model. It is not endorsed by OreSat, PSAS or Portland State University. It is not a conversion of OreSat configs or CANopen object dictionaries. It does not replace OreSat software, OLAF, Yamcs, configs or ground tools.

  The point is narrower: use public inspiration to test whether OrbitFabric can express a realistic constrained-downlink mission data contract.

  3. FINCH-inspired minislice

  The third example is:

  examples/finch-inspired-minislice/
  

  This one is focused on an imaging-payload workflow.

  It models:

  acquisition parameters loaded
  → OBC schedules image acquisition
  → ADCS readiness checked
  → payload camera readiness checked
  → image acquisition
  → data compression
  → constrained downlink
  → compressed image data partially pending
  → scenario evidence records the outcome
  

  It is not an official FINCH model. It is not endorsed by UTAT Space Systems, the University of Toronto Aerospace Team or the University of Toronto. It is not a conversion of FINCH architecture diagrams. It does not replace FINCH firmware, data-processing tools or systems-engineering tools.

  The purpose is to show a different vertical slice: acquisition readiness, payload data generation, compression and partial downlink.

  4. SpaceLab-inspired communications minislice

  The fourth example is:

  examples/spacelab-inspired-communications-minislice/
  

  This one is communications-oriented rather than payload-oriented.

  It is inspired by public SpaceLab UFSC / FloripaSat / GOLDS-UFSC material and focuses on a compact TT&C / OBDH data-flow contract:

  periodic beacon available
  → synthetic ground contact starts
  → TT&C receives an abstract data-request command
  → OBDH accepts the request
  → OBDH selects stored telemetry/data frames
  → OBDH packages frames for downlink
  → beacon and critical housekeeping are prioritized first
  → requested frames are partially downlinked
  → remaining frames stay pending onboard
  → decoder evidence records partial completion
  

  It is not an official SpaceLab, FloripaSat or GOLDS-UFSC model. It is not endorsed by SpaceLab UFSC or UFSC. It is not a claim that SpaceLab uses OrbitFabric. It is not a conversion of FloripaSat architecture, firmware, packet formats...

  Read more »

• v0.4.0 — Contact windows and downlink flow contracts

  Fabrizio Rovelli • 05/05/2026 at 12:51 • 0 comments

  OrbitFabric v0.4.0 extends the mission-data chain beyond payloads, data products and storage intent.

  This release is about contact and downlink assumptions.

  What v0.4.0 adds

  Before this release, OrbitFabric could already model a chain such as:

  Payload Contract
          -> Data Product Contract
          -> Storage Intent
          -> Downlink Intent

  With v0.4.0, that chain becomes:

  Payload Contract
          -> Data Product Contract
          -> Storage Intent
          -> Downlink Intent
          -> Contact Window Assumption
          -> Downlink Flow Contract

  This does not make OrbitFabric an operational downlink system.

  It makes declared assumptions explicit.

  The boundary: contract, not runtime

  This is an important boundary.

  OrbitFabric v0.4.0 does not:

  • compute real orbital passes
  • schedule real ground contacts
  • simulate RF links
  • execute downlink
  • replace a ground segment

  The v0.4.0 model works at contract level.

  It asks a narrower question:

  if a mission declares that a data product should be stored and later downlinked, are the declared contact and downlink assumptions coherent enough to be reviewed, linted and documented?

  What contacts.yaml can express

  The optional contacts.yaml domain can describe:

  • contact profiles
  • link profiles
  • contact windows
  • declared contact capacity
  • downlink flow intent
  • eligible data products

  This gives the Mission Model a way to express questions such as:

  • which contact assumption is being used?
  • which link profile applies?
  • what capacity is declared for that window?
  • which data products are eligible?
  • which downlink flow references them?
  • does the declared flow reference valid mission objects?

  For small spacecraft projects, those assumptions often exist anyway.

  They may live in an operations note, a spreadsheet, a test script, a ground-facing configuration file, or simply in the head of the person who planned the first demo pass.

  OrbitFabric v0.4.0 tries to move those assumptions into the Mission Data Contract.

  Example from the demo mission

  A shortened excerpt from the synthetic demo mission looks like this:

  contact_windows:
    - id: demo_contact_001
      contact_profile: primary_ground_contact
      link_profile: uhf_downlink_nominal
      start: "2026-01-01T00:00:00Z"
      duration_seconds: 600
      assumed_capacity_bytes: 512000
  
  downlink_flows:
    - id: science_next_available_contact
      contact_profile: primary_ground_contact
      link_profile: uhf_downlink_nominal
      queue_policy: priority_then_age
      eligible_data_products:
        - payload.radiation_histogram

  This is intentionally simple.

  What this example is not

  The example is not:

  • a real pass
  • based on TLE propagation
  • derived from a ground station network
  • a real RF budget
  • an operational schedule

  It is a declared contract-level assumption.

  That assumption is useful because it connects the data product model to the downlink model.

  The demo data product payload.radiation_histogram is produced by a synthetic payload contract, has storage intent, has retention intent, has overflow policy and has downlink intent.

  The v0.4.0 contact/downlink model then gives that data product a declared path toward downlink eligibility.

  What gets checked

  At this stage, the value is consistency.

  OrbitFabric should fail early when:

  • a downlink flow references an unknown data product
  • a contact window references an unknown profile
  • a link profile or contact profile is missing
  • a mission claims that a data product is intended for downlink but no visible contract-level assumption explains how it becomes eligible

  The generated contacts.md artifact is therefore not just documentation.

  It is a reproducible view of declared downlink assumptions.

  As usual in OrbitFabric, generated artifacts are not the...

  Read more »

• Payload contracts, data products and storage intent

  Fabrizio Rovelli • 05/05/2026 at 12:50 • 0 comments

  In OrbitFabric, a payload is not treated only as something that produces telemetry.

  A payload may also produce mission data products.

  That distinction matters.

  Payload data is not just telemetry

  Telemetry is usually about observability: state, health, counters, measurements, events and operational status.

  Mission data products are different.

  They are the objects the mission wants to preserve, reason about, store and eventually downlink.

  For a small spacecraft project, that difference can easily become blurred.

  A payload may expose telemetry.
  It may accept commands.
  It may raise events.
  It may enter lifecycle states.
  It may generate faults.
  It may produce histograms, images, files, packets, measurements or other mission-specific outputs.

  If those relationships are only described informally, integration debt appears quickly.

  The onboard software may know one version.
  The payload documentation may describe another.
  The test scenario may assume another.
  The storage plan may evolve separately.
  The downlink plan may be discussed later.
  The generated documentation may lag behind.

  OrbitFabric tries to make that chain explicit.

  The contract chain

  The current v0.4.0 model includes optional Payload Contracts and Data Product Contracts.

  A payload contract describes mission-facing payload behavior at contract level.

  A data product contract describes a mission-data object produced by a payload or subsystem.

  The intended chain is:

  Payload Contract
          -> declared payload behavior
          -> Data Product Contract
          -> Storage Intent
          -> Retention Intent
          -> Overflow Policy
          -> Downlink Intent

  This does not describe payload firmware.

  It does not describe payload drivers.

  It does not describe hardware buses.

  It does not simulate the physical payload.

  It describes the mission-facing contract.

  Payload contract excerpt

  The synthetic demo mission includes a clean-room IOD payload contract.

  A shortened excerpt looks like this:

  payloads:
    - id: demo_iod_payload
      subsystem: payload
      profile: iod
      lifecycle:
        initial_state: READY
        states:
          - OFF
          - READY
          - ACQUIRING
          - FAULT
      telemetry:
        produced:
          - payload.acquisition.active
      commands:
        accepted:
          - payload.start_acquisition
          - payload.stop_acquisition
      events:
        generated:
          - payload.acquisition_started
          - payload.acquisition_stopped

  This tells the model which mission-facing objects belong to that payload contract.

  It does not tell OrbitFabric how the payload firmware is implemented.

  Data product excerpt

  The same demo mission declares one synthetic payload data product.

  A shortened excerpt looks like this:

  data_products:
    - id: payload.radiation_histogram
      producer: demo_iod_payload
      producer_type: payload
      type: histogram
      estimated_size_bytes: 4096
      priority: high
      storage:
        class: science
        retention: 7d
        overflow_policy: drop_oldest
      downlink:
        policy: next_available_contact

  This is not a real payload product.

  It is a clean-room demo object used to exercise the model.

  The important point is not the histogram itself.

  The important point is that the data product has declared engineering intent:

  • who produces it
  • what type of product it is
  • how large it is expected to be
  • how important it is
  • where it is intended to be stored
  • how long it should be...

  Read more »

• From mission model to reproducible artifacts

  Fabrizio Rovelli • 05/05/2026 at 12:48 • 0 comments

  The core idea behind OrbitFabric is simple.

  The Mission Model should be the source of truth.

  Not the generated documentation.
  Not the test log.
  Not a hand-written table.
  Not a partially outdated diagram.

  The model comes first

  In many small spacecraft projects, mission data definitions start clean and then drift.

  Telemetry is described in one place.
  Commands are implemented somewhere else.
  Events and faults are listed in a document.
  Payload behavior is captured in tests.
  Storage assumptions live in a planning sheet.
  Downlink assumptions are discussed during integration.
  Ground-facing artifacts are created later, often manually.

  OrbitFabric explores a different flow.

  The model comes first.

  The current demo mission lives under:

  examples/demo-3u/mission/

  It contains structured YAML files for the mission contract:

  examples/demo-3u/mission/
  ├── spacecraft.yaml
  ├── subsystems.yaml
  ├── modes.yaml
  ├── telemetry.yaml
  ├── commands.yaml
  ├── events.yaml
  ├── faults.yaml
  ├── packets.yaml
  ├── policies.yaml
  ├── payloads.yaml
  ├── data_products.yaml
  └── contacts.yaml

  Those files are not intended to be a pretty configuration layer over an existing implementation.

  They are intended to make mission-data assumptions explicit before they become scattered across code, tests, documents and ground tooling.

  The current v0.4.0 flow

  The current v0.4.0 flow is:

  Mission Model YAML
          -> structural validation
          -> semantic lint
          -> engineering lint
          -> JSON lint report
          -> generated Markdown documentation
          -> scenario validation
          -> deterministic scenario execution
          -> simulation report
          -> simulation log

  That matters because every generated artifact is derived from the same declared contract.

  If a telemetry point is renamed, the documentation should not silently keep the old name.

  If a scenario references a command that does not exist, that should fail early.

  If a payload data product references an invalid producer, that should be detected.

  If a downlink flow references an unknown contact profile or an ineligible data product, that should not remain a hidden integration assumption.

  CLI flow

  The current CLI reflects this model-first flow.

  Typical local checks are:

  orbitfabric lint examples/demo-3u/mission/
  
  orbitfabric gen docs examples/demo-3u/mission/
  
  orbitfabric sim examples/demo-3u/scenarios/battery_low_during_payload.yaml

  Generated documentation

  The generated documentation currently includes mission-facing artifacts such as:

  generated/docs/
  ├── telemetry.md
  ├── commands.md
  ├── events.md
  ├── faults.md
  ├── modes.md
  ├── packets.md
  ├── payloads.md
  ├── data_products.md
  └── contacts.md

  These files are generated outputs.

  They are useful for review, discussion and integration.

  But they are not the source of truth.

  The source of truth remains the Mission Model and the scenario definitions.

  Scenario evidence

  The same applies to simulation reports and logs.

  For example, the synthetic demo scenario battery_low_during_payload exercises a declared chain:

  payload.start_acquisition
          -> payload.acquisition_started
          -> mode transition into PAYLOAD_ACTIVE
          -> battery voltage degradation
          -> eps.battery_low
          -> mode transition into DEGRADED
          -> automatic payload.stop_acquisition dispatch
          -> payload.acquisition_stopped
          -> scenario passed

  This is not a physics simulation.

  It is not a flight software runtime.

  It is not running on...

  Read more »

• Why OrbitFabric exists

  Fabrizio Rovelli • 05/05/2026 at 12:45 • 0 comments

  Small spacecraft projects rarely fail because nobody wrote a YAML file.

  They fail, or at least become painful to integrate, when several different descriptions of the same mission behavior start drifting apart.

  The problem: mission-data drift

  One description lives in the mission document.
  Another one lives in onboard software assumptions.
  Another one lives in test scripts.
  Another one lives in generated reports.
  Another one lives in ground-facing configuration.
  Another one may exist only in somebody's head.

  Telemetry, commands, events, faults, packets, payload outputs, storage expectations and downlink assumptions are often treated as separate artifacts.

  That separation is where integration debt starts.

  What OrbitFabric tries to do

  OrbitFabric exists to explore a different approach:

  define the mission data contract once,
  validate it,
  generate documentation from it,
  run deterministic host-side scenarios from it,
  and later use it as the basis for integration artifacts.

  The important point is not the file format.

  The important point is the engineering boundary.

  What does the mission claim to produce?
  What commands are expected?
  What events and faults can be raised?
  What data products exist?
  Where are they intended to be stored?
  When should they become eligible for downlink?
  Which contact assumptions are being used?

  In a small spacecraft project, those questions should not be answered differently by the README, the onboard code, the test scripts and the ground configuration.

  OrbitFabric is an attempt to make those assumptions explicit early, before they become hidden integration debt.

  Current v0.4.0 scope

  The current v0.4.0 release focuses on the contract layer.

  It can model:

  • spacecraft structure
  • subsystems
  • modes
  • telemetry
  • commands
  • events
  • faults
  • packets
  • payload contracts
  • data products
  • storage intent
  • contact windows
  • downlink flow contracts

  A simplified view of the current idea is:

  Mission Model
          -> validation
          -> lint report
          -> generated documentation
          -> scenario validation
          -> deterministic scenario execution
          -> simulation report
          -> simulation log
  
  Optional Payload Contract Model
          -> payload reference validation
          -> payload lifecycle validation
          -> payload documentation generation
  
  Optional Data Product Contract Model
          -> producer reference validation
          -> storage intent validation
          -> downlink intent validation
          -> data product documentation generation
  
  Optional Contact and Downlink Contract Model
          -> contact profile validation
          -> link profile validation
          -> contact window validation
          -> downlink flow consistency validation
          -> contact/downlink documentation generation
  

  What OrbitFabric is not

  The current project is intentionally narrow.

  OrbitFabric is not:

  • flight software
  • OBC firmware
  • a ground segment
  • a spacecraft dynamics simulator
  • a real downlink runtime
  • a CCSDS/PUS/CFDP implementation
  • a replacement for cFS, F Prime, Yamcs, OpenC3 or OpenMCT

  Those may become future integration directions or generated artifact targets, but they are not current capabilities.

  Why the boundary matters

  This is still a pre-1.0 engineering project.

  The examples are synthetic and clean-room.

  The current demo mission is not a real spacecraft.
  The contact windows are declared assumptions, not real orbital pass predictions.
  The downlink flow model is a contract-level consistency layer, not an operational downlink runtime.

  That boundary matters.

  OrbitFabric should be judged as a small open-source attempt to reduce drift between mission design, software assumptions,...

  Read more »

View all 8 project logs