GoMyRobotOS Documentation

GoMyRobotOS is a partition and execution platform for heterogeneous safety-critical space computers. It defines a hypervisor-independent contract for execution, isolation, communication, startup, and recovery, then realizes that contract through target-specific backends.

Attention

Project status: M0 Architecture and Contract Freeze GoMyRobotOS is documentation-first. The architecture, the Partition Contract, and the backend model are frozen as a specification. No target system has been implemented yet. Every maturity statement in these pages therefore uses one of the labels: Stable, Experimental, Research, Planned, or Not implemented.

How to read this documentation

• These pages are the documentation source of truth for GoMyRobotOS - the architecture, the contract, and the process are defined here and in the accompanying schema and examples.

• ROS 2 Rolling is the authoritative external reference for all ROS 2 concepts: see the official ROS 2 Rolling documentation. This project never duplicates ROS 2 documentation, it links to it and documents only GoMyRobot-specific integration and guarantees (compatibility/ros2).

• Architecture changes are traceable to numbered Architecture Decision Records (ADR-0001 … ADR-0013) in development/architecture-decisions.

Contents

• Getting started
  • Overview
    • The five core responsibilities
    • Where to read next
  • Installation
    • What is available today
    • Building this documentation locally
    • What M1 will add
  • Development environment
    • Documentation toolchain (available today)
    • Planned platform environments (from milestone M1 onward)
      • x86-64 development and reference
      • NG-ULTRA flight reference
      • PIC64-HPSC RISC-V research
• Concepts
  • Concepts overview
    • The core definition
    • Key terms
    • Architecture in one diagram
    • What GoMyRobotOS is and is not
    • Reading order
  • Architecture principles
    • 1. Describe the semantics once; realize them per target
    • 2. The hypervisor is a backend, not the abstraction
    • 3. The contract contains intent and constraints, not backend syntax
    • 4. The product stays a platform, not an “everything safety” monolith
    • 5. The robotics workload stays a workload
    • 6. Recovery must be independent of the domain it recovers
    • 7. Targets are honestly staged
    • 8. Evidence, not assertions
    • 9. The documentation is versioned with the software
  • Partitioning
    • What a partition is
    • Why partition, and not process / container / VM
    • A mixed-criticality system is a set of partitions
    • Partition and partition contract: the distinction
  • Isolation
    • Isolation dimensions in the contract
    • What GoMyRobotOS specifies vs. what a backend realizes
    • Isolation and assurance
  • Execution model
    • The realization pipeline
    • What “execution” means per partition
    • Runtime integration
    • Non-partition execution
  • Assurance positioning
    • The boundary
    • What GoMyRobotOS contributes to an assurance argument
    • What GoMyRobotOS explicitly does not claim
    • Why the boundary exists
• Architecture
  • Architecture overview
    • The final architecture
    • The surrounding ecosystem
    • Backend matrix (summary)
    • Five core responsibilities
  • Layered model
    • The layers
      • 1. Partition Contract
      • 2. IR (GoMyRobotOS Intermediate Representation)
      • 3. Target backend
      • 4. Runtime
      • 5. GoMyRobotRT and the workload
    • Invariant vs. target-specific
  • The Partition Contract
    • The central innovation
    • Why this is the center of the architecture
    • Minimum conceptual fields
    • The hard rule: no backend syntax
    • Contract ≠ IR
    • Status
    • Example
  • GoMyRobotOS IR (Intermediate Representation)
    • Purpose
    • Naming: contract vs IR
    • Shape
    • Guarantees the IR is responsible for
    • Status
  • Backend model
    • The rule
    • A backend is a mapping, not a product
    • Initial backends and their status
    • Backend Capability Manifest
    • Bare-metal backends
    • What backends must never do
  • Runtime model
    • Hosting the workload: GoMyRobotRT
    • The runtime responsibilities of GoMyRobotOS
    • Service domains (Linux)
  • Recovery model
    • What a partition must do when something goes wrong
    • The detect → contain → recover → resume pipeline
    • The independence boundary (ADR-0011)
    • Recovery as assurance evidence
  • Frozen baseline scope notes
    • Naming rule
    • Not in the v1 baseline
    • Platform position
    • Status
• Ecosystem components
  • GoMyRobotRT
    • Overview and responsibilities
    • ROS 2 Rolling integration
      • rcl / rclcpp / rclpy client libraries
      • Executors
      • Publishers, subscriptions, services, actions, parameters
      • QoS
      • Middleware / RMW, DDS
      • Graph and lifecycle
    • Deterministic execution
    • Hardware abstraction and health monitoring
    • Flight workload integration
  • ROS 2 (Rolling) as the workload reference
    • The position
    • The reference: ROS 2 Rolling, exclusively
    • What this documentation does not do
    • When GoMyRobotRT behavior differs from ROS 2
    • Linking rule
  • GoMyRobotBSP
    • Inputs and outputs
    • Yocto’s role
    • Relationship to GoMyRobotOS
  • GoMyRobotGuard
    • Architecture
    • Division of labor with GoMyRobotOS
    • Independence staging
    • HPSC: hardware independence
  • GoMyRobotFault
    • Fault classes
    • Radiation belongs here, not in GoMyRobotOS
    • Ladder from model to physics
  • GoMyRobotBench
    • Division of labor with GoMyRobotOS
    • Where Bench shows up in the plan
    • Bench does not redefine platform behavior
  • GoMyRobotVerify
    • The flow
    • What GoMyRobotVerify owns
    • What GoMyRobotOS contributes to verification
    • Boundaries
  • GoMyRobotAssure
    • The role
    • Why the boundary exists
    • The research hook: assurance portability
• Partition Contract
  • Partition Contract Overview
    • Where the contract sits
    • What this section contains
    • Channel semantics
    • Capability requirements
    • Two rules to remember
    • Status
  • Partition Contract v1 Specification
    • 1. Identity
    • 2. Execution
    • 3. Memory
    • 4. Devices, interrupts, DMA
    • 5. Communication
    • 6. Startup
    • 7. Security
    • 8. Recovery
    • 9. Requirements and verification
    • Non-goals of the contract
  • Partition Contract v1 Schema
    • Location
    • Format
    • What the schema enforces today
    • How the schema is validated
  • Example contract: flight-control
    • Why each group matters
• Platforms
  • Platform: x86-64
    • Realization path
    • What x86-64 is used for and not for
    • Plans for this platform in the milestones
  • Platform: NG-ULTRA
    • Why NG-ULTRA
    • Realization path
    • Honest status notes
    • Role in the research program
  • Platform: PIC64-HPSC
    • What the M0 baseline records
    • The research path
    • Why HPSC is interesting for the science
• Backends
  • Backends
    • The initial backend matrix
    • Pages in this section
    • What every backend maps
    • Rules for backend work (frozen at M0)
  • Backend: Xen
    • Role in the model
    • x86-64 status
    • HPSC status research track
    • What Xen must never be
  • Backend: XtratuM
    • Role in the model
    • Ecosystem basis (recorded facts from the M0 baseline)
    • What M2 must produce
    • Documentation discipline
  • Backend: XNG
    • What XNG is in the GoMyRobotOS model
    • Why a separate page
    • Status and scope at M0
• Validation
  • Validation Methodology
    • First rule: what validation is and is not
    • The declared validation areas
    • How the results feed the rest of the ecosystem
    • Ladder of where validation runs
  • Validation: Temporal isolation
    • What “temporal isolation” means here
    • What gets measured
    • Experimental plan (research, not implemented)
    • Status
  • Validation: Spatial isolation
    • What “spatial isolation” means here
    • The isolation invariants (per contract field)
    • How the invariants are tested
    • Status
  • Validation: Interference
    • The question
    • The experimental design
    • Measured quantities
    • Status
  • Validation: Fault injection
    • The boundary, stated again
    • The fault classes validated against a contract
    • What each validation run produces
    • Radiation: the honesty rule
    • Space fault responsibility split
    • Status
  • Validation: Recovery
    • The pipeline under test
    • The fault classes exercised
    • What “passing” means
    • Status
• Assurance
  • Assurance: Evidence model
    • The evidence inputs
    • Requirement → field → test → result chain
    • Why this shape
    • Timing evidence classification
    • What this is not
  • Assurance: Reproducibility
    • Three reproducibility pillars in GoMyRobotOS
      • 1. Reproducible boot
      • 2. Reproducible measurements
      • 3. Reproducible artifacts
    • How far reproducibility reaches
    • Status
  • Assurance: Evidence graph
    • Graph inputs GoMyRobotOS emits
    • Graph nodes vs. edges (blank at M0)
    • The portability question
• Research
  • Research agenda
    • The study question
    • The problem set
    • Where each problem lives
    • Milestone mapping (summary)
  • Research problems
    • RP1 Portable partition semantics
    • RP2 Multi-channel interference
    • RP3 Fault containment and recovery
    • RP4 Faults caused by the space environment
    • RP5 Assurance portability
    • Status of all five
    • How problems feed documents
  • Publications
    • Planned paper 1
      • “A Portable Partition Contract and Measurement Framework for
    • Planned paper 2
      • “Measuring Multi-Channel Interference on Heterogeneous Space
    • Planned paper 3
      • “Assumption Portability for Heterogeneous Flight Software
    • Relationship to the agenda
• Milestones
  • Milestones overview
    • Status snapshot (M0)
    • How milestones are written
  • M0 Architecture and Contract Freeze
    • Objective
    • Scope
    • Deliverables
    • Tests
    • Acceptance gate
    • Current status
    • Known limitations
  • M1 x86-64 Reference Partition
    • Objective
    • Scope
    • Deliverables
    • Tests
    • Acceptance gate
    • Current status
    • Known limitations
  • M2 NG-ULTRA Flight Reference
    • Objective
    • Scope
    • Deliverables
    • Tests
    • Acceptance gate
    • Current status
    • Known limitations
  • M3 Interference Laboratory
    • Objective
    • Scope
    • Deliverables
    • Tests / acceptance gate
    • Current status
    • Known limitations
  • M4 HPSC Research
    • Objective
    • Scope
    • Deliverables
    • Tests / acceptance gate
    • Current status
    • Known limitations
  • M5 Recovery and Assurance Integration
    • Objective
    • Scope
    • Deliverables
    • Tests / acceptance gate
    • Current status
    • Known limitations
  • M6 ServiceReady Reference Platform
    • Objective
    • Scope
    • Deliverables
    • Tests / acceptance gate
    • Current status
    • Known limitations
• Compatibility
  • Compatibility: ROS 2
    • Concept-by-concept status
    • What “compatible” could mean (future, not now)
• Development
  • Contributing to GoMyRobotOS
    • Development flow
    • Non-negotiable documentation rules
    • Status labels: the vocabulary
    • Forbidden conversions (anti-hallucination)
    • ROS 2 rules
    • Architecture decisions (ADRs)
    • Milestones
    • Page discipline
    • Code conventions
    • Reporting problems
    • License
  • Testing (project)
    • What is tested today (M0)
    • Declared test areas (from the validation section)
    • Ladder
    • Tooling policy
  • Architecture Decisions
    • Index
      • ADR-0001 GoMyRobotOS is a partition and execution platform
      • ADR-0002 Partition Contract is the central abstraction
      • ADR-0003 Hypervisors are target-specific backends
      • ADR-0004 x86-64 is the initial development/reference platform
      • ADR-0005 NG-ULTRA is the primary flight-oriented reference
      • ADR-0006 HPSC is the initial RISC-V research target
      • ADR-0007 GoMyRobotRT is separate from GoMyRobotOS
      • ADR-0008 ROS 2 Rolling is the primary ROS 2 documentation reference
      • ADR-0009 GoMyRobotBSP owns target build and image realization
      • ADR-0010 Fault and radiation modeling belongs outside GoMyRobotOS
      • ADR-0011 GoMyRobotGuard must be independent of the failure domain it recovers
      • ADR-0012 Verification and assurance are external platform services
      • ADR-0013 Documentation is versioned with the software
      • ADR-0014 IPC is described by channel class, not transport mechanism
      • ADR-0015 Backends publish a capability manifest; no silent semantic downgrade
      • ADR-0016 Guard independence is staged (0 / 1 / 2)
      • ADR-0017 WCET claims carry an evidence class
      • ADR-0018 The documentation site is the architecture source of truth
    • Supersession log
  • Architecture v2 (working draft), superseded for the M0 baseline
  • Changelog
    • [Unreleased]
      • Added
      • Changed
      • Fixed