Project Logs

Collapse

• v0.4.0 — Contact windows and downlink flow contracts

  Fabrizio Rovelli • 2 hours ago • 0 comments

  V0.4.0 — CONTACT WINDOWS AND DOWNLINK FLOW CONTRACTS

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

  The new focus is contact and downlink assumptions.

  This is an important boundary.

  OrbitFabric does not compute real orbital passes.
  It does not schedule real ground contacts.
  It does not simulate RF links.
  It does not execute downlink.
  It does not 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?

  Before v0.4.0, 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

  That does not make OrbitFabric an operational downlink system.

  It makes the declared assumptions explicit.

  In the current model, 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.
  They may live in a spreadsheet.
  They may be discussed during integration.
  They may be embedded in test scripts.
  They may be implicit in ground-facing configuration.
  They may be known by the person who planned the first demo pass.

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

  The synthetic demo mission includes a simple contact/downlink slice:

  primary_ground_contact
          link: uhf_downlink_nominal
          window: demo_contact_001
          flow: science_next_available_contact
          eligible data product: payload.radiation_histogram

  This is intentionally simple.

  It is not a real pass.
  It is not based on TLE propagation.
  It is not derived from a ground station network.
  It is not a real RF budget.
  It is not 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.

  At this stage, the important value is consistency.

  If a downlink flow references an unknown data product, that should fail early.

  If a contact window references an unknown profile, that should fail early.

  If a link profile or contact profile is missing, the generated documentation should not silently hide that gap.

  If the mission claims that a data product is intended for downlink, there should be a visible contract-level assumption describing 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 source of truth.

  The source of truth remains the Mission Model.

  The current flow is:

  contacts.yaml
       ...

  Read more »

• Payload contracts, data products and storage intent

  Fabrizio Rovelli • 2 hours ago • 0 comments

  PAYLOAD CONTRACTS, DATA PRODUCTS AND STORAGE INTENT

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

  A payload may produce mission data.

  That distinction matters.

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

  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 files, histograms, images, 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 current v0.4.0 model includes optional Payload Contracts and Data Product Contracts.

  A payload contract can describe a declared payload behavior at contract level:

  which subsystem owns the payload,
  which telemetry it produces,
  which commands it accepts,
  which events it may generate,
  which faults may be associated with it,
  which lifecycle states are expected,
  which command preconditions and effects are declared.

  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.

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

  It can declare:

  producer reference,
  product type,
  estimated size,
  priority,
  storage intent,
  retention intent,
  overflow policy,
  downlink intent.

  That is the important part.

  OrbitFabric is not trying to store the data.

  It is trying to make the storage assumption explicit.

  For example, the synthetic demo mission includes a payload data product similar to this contract-level idea:

  payload.radiation_histogram
          producer: demo_iod_payload
          type: histogram
          estimated size: 4096 bytes
          storage: science
          retention: 7d
          overflow policy: drop_oldest
          downlink intent: next_available_contact

  This is not a real payload output.

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

  But it demonstrates the intended engineering chain:

  Payload Contract
          -> declared payload behavior
          -> generated mission data object
          -> Data Product Contract
          -> Storage Intent
          -> Retention Intent
          -> Overflow Policy
          -> Downlink Intent

  That chain is useful because it creates places where consistency can be checked.

  If a data product references an unknown producer, that should fail early.

  If a payload contract references missing telemetry, commands, events or faults, that should not remain hidden.

  If a storage intent is declared, it should be visible in generated documentation.

  If a downlink intent is declared, it should become part of the wider mission-data chain.

  The current OrbitFabric implementation can load the optional data_products.yaml model domain, validate references, lint storage and downlink intent assumptions, and generate data product documentation.

  The generated data_products.md file is not the source of truth.

  It is a reproducible artifact.

  The source of truth remains the declared Mission Model.

  That distinction is central to OrbitFabric.

  Generated...

  Read more »

• From mission model to reproducible artifacts

  Fabrizio Rovelli • 3 hours ago • 0 comments

  FROM MISSION MODEL TO REPRODUCIBLE ARTIFACTS

  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.

  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:

  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 the mission-data assumptions explicit before they become scattered across code, tests, documents and ground tooling.

  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.

  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

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

  telemetry.md
  commands.md
  events.md
  faults.md
  modes.md
  packets.md
  payloads.md
  data_products.md
  contacts.md

  Those 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.

  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 an OBC.

  It is a deterministic host-side scenario derived from declared mission contracts.

  That distinction is intentional.

  OrbitFabric is trying to answer a narrow engineering question:

  can we keep mission-data assumptions explicit enough that validation, documentation and scenario evidence all come from the same source?

  The current answer is still partial, but useful enough to...

  Read more »

• Why OrbitFabric exists

  Fabrizio Rovelli • 3 hours ago • 0 comments

  WHY ORBITFABRIC EXISTS

  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.

  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.

  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 current project is intentionally narrow.

  OrbitFabric is not flight software.
  It is not an OBC firmware.
  It is not a ground segment.
  It is not a spacecraft dynamics simulator.
  It does not execute real downlink.
  It does not implement CCSDS/PUS/CFDP.
  It does not replace cFS, F Prime, Yamcs, OpenC3 or OpenMCT.

  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 and downlink flow contracts.

  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.

  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

  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, tests, generated documentation and ground-facing artifacts.

  Not as a complete flight stack.

  Not as a ground segment.

  Not as a simulator.

  As a mission data contract layer.

  Feedback is welcome, especially...

  Read more »

View all 4 project logs