Skip to content

spec.md

Latest commit

 

History

History
305 lines (208 loc) · 22.8 KB

spec.md

File metadata and controls

305 lines (208 loc) · 22.8 KB
Raw

AUNIX

AUNIX = A Unified UNIX-like OS

它不是"又一个 Linux 发行版"，也不是"又一个 RTOS"，而是一个面向异构多核设备、从零实现的统一操作系统。机器人、无人机这类设备的硬件本质是"一颗强大的主控核 + 一个或多个实时控制核（MCU）"；AUNIX 用一个自研微内核（AUNIX-MK）承载多个"个性"（Personality）——通用个性（AUNIX-G）、实时个性（AUNIX-RT），且可扩展更多——把这套异构多核在逻辑上融合为一台单一的计算机：开发者只看到一个文件系统、一个进程空间（含实时任务）、一个网络命名空间，实时任务获得确定性保证，通用任务获得完整的通用 OS 能力（多进程、虚拟内存、网络栈、文件系统，全部自研）。

文档定位：本文档仅为 顶层架构设计（Top-Level Design），界定 AUNIX 的整体目标、分层结构与关键设计决策；不包含协议细节、数据结构、接口定义、算法与具体实现方案。本文档范围限定在 单一物理设备内 的"通用主控核 + 实时控制核"异构多核；多设备集群不在本文档范围内。

核心目标

  • 用户只看到 一个文件系统、一个进程空间（含实时任务）、一个网络命名空间
  • 实时任务获得 硬实时确定性保证（固定周期、有界可调度），通用任务获得 完整通用 OS 能力（自研文件/网络/进程栈）
  • 一个微内核、多个个性：AUNIX-MK 提供最小机制与隔离，通用个性与实时个性共享同一内核底座、同一条工具链、同一套代码
  • 硬件差异（指令集、中断、外设）被彻底抽象化：开发者用统一 API 访问传感器与执行器，无需关心任务跑在哪个核
  • 故障隔离：主控个性崩溃不影响实时控制层继续工作

设计哲学：一个大脑，副脑分管反射

AUNIX 的架构思想直接取自人体：一个大脑负责认知，脑干等副脑负责反射。

人体 AUNIX 职责
大脑皮层 主控核 AP（AUNIX-G 个性） 认知、规划、感知——"想"的活
脑干/小脑 实时核 RP（AUNIX-RT 个性） 姿态、电机、反射控制——"准"的活
脊髓与神经 核间通信层 大脑与副脑之间的通路
反射弧 RP 上的硬实时闭环 不经过大脑的自动反应
皮层受损、脑干维持生命 故障隔离 主控个性崩溃，实时控制继续

由此导出三条架构原则：

  1. 意图-执行分离：大脑不微操肌肉，只发"往左走"的意图。AUNIX 中 AP 下发目标（setpoint、目标姿态、路径点），RP 在本地闭环执行；AP 与 RP 之间是粗粒度的意图接口，不是逐样本的数据搬运。
  2. 反射不经过大脑：安全降落、看门狗等"保命反射"完全不依赖主控，是系统不经大脑的自动反应，构成底线保障。
  3. 逻辑统一，物理分区：大脑与脑干本是分离器官、靠神经相连。AUNIX 的"统一"是逻辑视图层的统一（一个 /、一个进程空间、一套 API），物理层各核/各域保持分区。这不仅与人体一致，也满足汽车 ISO 26262 的干扰自由（freedom-from-interference）要求与机器人的功能安全认证——"统一"从来不是"熔进一颗芯片"。

一、架构设计

1.1 整体架构

┌──────────────────────────────────────────────────────────────────────────────┐
│                       统一视图层 (Single System Image)                       │
│ ┌───────────────┐  ┌────────────────┐  ┌────────────────┐  ┌───────────────┐ │
│ │ 统一进程空间  │  │统一文件系统视图│  │统一网络命名空间│  │ 统一设备抽象  │ │
│ │ (含实时任务)  │  │   (全局统一)   │  │   (同一IP栈)   │  │(传感器/执行器)│ │
├──────────────────────────────────────────────────────────────────────────────┤
│                           个性化层 (Personalities)                           │
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
│ │ AUNIX-G 个性（通用进程/网络/文件）│ AUNIX-RT 个性（确定性调度/周期任务） │ │
│ └──────────────────────────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────────────────────────┤
│                     微内核层 AUNIX-MK（机制，不含策略）                      │
│       线程/IPC   │   内存分区   │   调度机制   │   中断分发   │   能力       │
├──────────────────────────────────────────────────────────────────────────────┤
│                                  核间通信层                                  │
│      共享内存(RPMsg)     实时以太网(EtherCAT/TSN)     车载总线(CAN-FD)       │
├──────────────────────────────────────────────────────────────────────────────┤
│                                   物理核层                                   │
│          AP          │              RP1               │         RP2          │
│  AUNIX-MK + G 个性   │       AUNIX-MK + RT 个性       │  AUNIX-MK + RT 个性  │
│                   反射层：AP 崩溃，实时控制与保命反射继续                    │
└──────────────────────────────────────────────────────────────────────────────┘

1.2 分层详解

第一层：物理核层

  • 主控核（AP，Application Processor）：运行 AUNIX-MK + AUNIX-G 个性，承载视觉/导航、规划、网络、文件系统、AI 推理等通用负载
  • 实时控制核（RP，Real-time Processor）：一个或多个，运行 AUNIX-MK + AUNIX-RT 个性，承载电机控制、姿态解算、传感器采样等固定周期任务
  • 加速器：NPU/GPU 等，由主控核统一调度

副脑并非扁平的一层，而是可以组成 控制层级：高层副脑（整机控制/力控）向下层副脑（关节伺服）下发更低层的意图，形成「规划 → 整机控制 → 关节 → 伺服」的链条，对应人体「大脑 → 小脑 → 脊髓 → 肌肉」。人形/具身机器人典型是这种多级副脑结构。

第二层：核间通信层

AP 与 RP 之间通过共享内存 + 无锁队列 + 邮箱中断通信（RPMsg 模式）。这一层是"统一系统"的物理基础：跨核数据传递不经过完整协议栈，延迟控制在微秒级。

第三层：微内核层（AUNIX-MK）

一个微内核，每核一份（AMP：各核独立运行、内存分区自治、互不共享）。它只提供最小机制、不含任何策略：

  • 线程/进程原语：线程运行机制（运行队列、上下文切换、优先级数字）、进程隔离
  • IPC 原语：消息传递、共享内存、事件/信号；跨核 IPC 与同核 IPC 由同一套接口统一封装
  • 内存分区机制：物理内存分区、页表切换、能力（capability）授权
  • 调度机制：决定"下一个该跑哪个线程"的最底层裁决（固定优先级 + 时间片轮转）——但不包含调度策略
  • 中断分发机制：中断向量、中断→事件/消息的投递、屏蔽/使能——不含中断业务逻辑

AUNIX-MK 短小（目标万行级）、中断路径极短、禁抢占区间可证明，这是硬实时时延上界的根基；也正因只含机制，调度策略与中断处理可以上移到个性，微内核本身无需随需求演进而频繁改动。

第四层：个性化层（Personalities）

微内核之上，以用户态服务 + 策略代码的形式实现不同的"个性"，每个核加载对应的个性：

  • AUNIX-G 个性（通用个性）：进程模型、虚拟内存管理、文件系统、网络栈、通用调度策略（公平/动态优先级）——给通用任务完整的 OS 能力
  • AUNIX-RT 个性（实时个性）：确定性调度策略（固定周期、截止时间/优先级驱动，如 RM/EDF）、实时任务模型、可调度性分析——给实时任务硬实时保证
  • 个性可扩展：未来可按需新增（如安全个性、信号处理个性），只需加载新的用户态服务，微内核不动

第五层：统一视图层（SSI）

用户和开发者看到的统一抽象：

  • 一个 / 文件系统（实时层持有受限的只读视图）
  • 一个 ps 命令能看到所有核上的进程（含实时任务）
  • 一个统一的设备节点抽象：传感器、执行器、电机控制器都是一等公民
  • 一个网络命名空间：实时任务也能收发网络命令（经主控转发或独立网口）

二、关键技术模块

2.1 实时性与确定性

问题：通用 OS 的任务调度抖动（jitter）在微秒/毫秒级，无法满足电机控制等硬实时周期任务。

AUNIX 的解法：

手段 说明
专用实时核 实时任务独占 RP，不与通用核共享 CPU、cache、中断
极短中断路径 微内核中断分发路径极短且可证明，中断从到达硬件到唤醒 RT 线程的时延有上界
确定性调度策略 AUNIX-RT 个性采用固定周期/截止时间驱动的调度，周期任务可做可调度性分析
原生二进制 实时任务编译为本地机器码（Rust 交叉编译到每类 RP 架构），不使用 WASM/IR——JIT 抖动会破坏确定性
隔离 内存分区 + cache 划分 + 中断隔离，避免实时任务受通用负载污染
混合关键性 硬实时任务（电机）、软实时任务（感知融合）、非实时任务（日志）分层管理

2.2 统一调度器

调度器解决的不再是"多机之间放任务"，而是 "这个任务该放 AP 还是 RP"。而"放在哪个核之后按什么策略排"是机制与策略分离的：

  • 微内核只提供调度机制：固定优先级 + 时间片轮转的底层裁决，保证"最高优先级线程立即运行"这一确定语义
  • AUNIX-RT 个性提供实时策略：固定周期、截止时间/优先级驱动（RM/EDF），周期任务集合可做可调度性分析
  • AUNIX-G 个性提供通用策略：公平调度、动态优先级，承载软实时与通用负载
策略 适用任务 由谁提供
硬实时 固定放置到 RP，固定周期，可调度性分析保证 AUNIX-RT 个性
软实时 放置到 AP（软实时调度）或 RP 低优先级 AUNIX-G / AUNIX-RT 个性
算力密集 放置到 AP/加速器（视觉、SLAM、规划） AUNIX-G 个性
I/O 密集 就近放置到外设所在核 微内核统一 IPC

统一任务抽象：周期任务（Periodic Task）与事件任务（Event Task）是一等抽象，应用程序通过统一的调度 API 声明周期/截止时间/优先级，由系统决定放置位置。

调度器接口：提供类 pthread_create + 周期声明的 API（如 task_periodic(1000us, deadline)），系统自动把该任务放到可满足的核上，由对应个性接管调度。

2.3 跨核 IPC

模式 说明 延迟
同核 IPC 共享内存 + 无锁队列（微内核原生） < 1µs
跨核 IPC（短消息） 共享内存 + 邮箱中断（RPMsg 模式） 1-5µs
跨核 IPC（批量数据） 共享内存零拷贝 + 缓存一致性 由数据速率决定

跨核 IPC 与同核 IPC 暴露 同一套接口（均由 AUNIX-MK 统一封装），实时任务与通用任务之间可以透明通信——这正是"一个系统"的关键体现。

跨核通信遵循 意图-执行分离（见设计哲学）：AP 向 RP 发送的是目标/意图（setpoint、目标姿态、路径点），RP 本地闭环执行并回报状态；低频意图 + 本地高速闭环，避免逐样本跨核搬运，也让 RP 的确定性不被通信链路抖动影响。

核间通信抽象为 统一接口、多种物理通道：片内共享内存（RPMsg）、实时以太网（EtherCAT/TSN）、车载总线（CAN-FD）。不同设备的副脑挂在不同通道上——无人机走片内共享内存，机器人走 EtherCAT 总线，汽车走 CAN-FD/车载以太网——但上层看到的是同一套 IPC 接口。

2.4 统一设备抽象

  • 传感器（IMU、GPS、摄像头）与执行器（电机、舵机）抽象为统一的设备节点，挂载在统一的设备树//dev 下
  • 实时任务可直接映射设备（绕过通用内核驱动栈直达硬件），普通任务走标准驱动
  • 同一份应用代码可通过统一 API 访问任何设备，无需关心硬件挂在哪个核

2.5 统一文件系统与网络

  • 单一根文件系统：主控核持有完整读写文件系统，实时层通过共享内存获得受限的只读/日志视图
  • 单一网络命名空间：实时任务可经统一接口发送/接收网络消息（由主控转发或独立网口），对外表现为同一台设备
  • 统一日志：实时任务的调试输出写入统一日志系统，替代传统"MCU 串口 printf"的割裂开发方式

三、与现有方案的对比

3.1 与无人机/机器人双系统

现在的主流做法是"主控 Linux + 单独烧录的 MCU 固件"——两套工具链、两套代码、分开编译烧录调试。

维度 双系统分治 AUNIX
开发 两套代码/工具链，跨系统协议手写 一套代码、一个系统
进程视图 实时任务对主控不可见 一个 ps 看到全部
通信 手写串口/CAN 协议 + 状态机 原生跨核 IPC，统一接口
部署 分别烧录/升级固件与系统 统一镜像、统一升级
调试 printf + 示波器 统一日志、统一调试器

3.2 与 Linux PREEMPT_RT

PREEMPT_RT 能让 Linux 获得"软实时"，但抖动仍不可保证，且实时任务与通用负载共享资源，难以给出硬实时上界。AUNIX 从零实现，用 专用实时核 + 极短微内核中断路径 承载硬实时任务，通用侧（AUNIX-G 个性）只负责软实时与通用负载。

3.3 与现有 AMP/虚拟化方案（OpenAMP、ACRN）

维度 OpenAMP/RPMsg ACRN 等 Hypervisor AUNIX
本质 通信库 + 协议 虚拟机隔离 原生异构统一 OS（微内核 + 个性）
统一视图 无，仍需各自编程 无，客机各自为政 一个文件系统/进程/网络
实时性 依赖各自 RTOS 受虚拟化开销影响 专用核原生确定性
开发者体验 仍像"两个系统" 仍像"两个系统" 一个系统

一句话：OpenAMP 解决了"怎么连"，ACRN 解决了"怎么隔离"，AUNIX 解决"怎么像一台电脑"。

四、技术挑战与解决方案

4.1 确定性保证

挑战：通用负载可能通过 cache 争用、总线竞争、中断干扰污染实时任务。

解决方案：

  • 专用核 + 内存分区/cache 划分/独占，隔离实时任务与通用负载
  • 可调度性分析：周期任务集合在上线前验证最坏情况执行时间（WCET）
  • 中断隔离：实时核的关键中断直通，不经主控分发

4.2 时钟同步

挑战：AP 与 RP 各自有独立时钟，实时任务与通用任务协作时需要一个共同时间基准。

解决方案：

  • 硬件同步：共享高精度定时器 / 跨核 PTP 时间基准
  • 提供两种时钟：单调本地时钟（实时任务内）与统一墙钟（跨核事件排序）

4.3 故障隔离

挑战：主控核崩溃或过热，不能导致飞行器/机器人失控。

解决方案：

  • 反射层（一等架构要素）：安全降落、看门狗等"保命反射"作为不经大脑的自动反应存在——与人体反射弧一致，完全独立于主控逻辑，主控故障时自动接管
  • 安全等级（混合关键性）：任务标注安全等级（汽车 ASIL、机器人 SIL），调度、隔离与通道按等级区分——高等级任务独占资源，低等级任务不可干扰其关键时序（与"逻辑统一、物理分区"原则一致）
  • 实时层独立运行：AUNIX-RT 个性是微内核之上独立于 AUNIX-G 个性的用户态实体；主控个性崩溃时，实时控制（电机、姿态）继续工作，进入安全降落等降级模式
  • 看门狗：AP 与 RP 互喂看门狗，异常时接管控制
  • 实时任务状态检查点：关键周期任务的状态可被记录，便于恢复

五、项目路线图（无 AI 版本）

Phase 1: 微内核 + 实时个性（AUNIX-MK + AUNIX-RT，单核）

目标：在 QEMU（RISC-V / Cortex-M 模拟）上运行最小的 AUNIX-MK，并在其上跑起 AUNIX-RT 个性。

  • 微内核：线程、IPC、内存分区、中断分发（机制）
  • AUNIX-RT 个性：周期任务模型与确定性调度策略（策略）
  • 可调度性分析工具

Phase 2: 异构双核（AP + RP）

目标：AP 与 RP 并行启动（AMP），各核运行 AUNIX-MK，AP 加载 AUNIX-G 个性、RP 加载 AUNIX-RT 个性，两者经共享内存 + 邮箱通信。

  • AUNIX-MK 在 AP 与 RP 上独立运行（内存分区自治）
  • 共享内存 + 邮箱中断的跨核 IPC
  • AUNIX-G 个性雏形（通用进程模型与调度策略）
  • 统一任务放置（AP/RP）与统一进程视图雏形（主控 ps 可见实时任务）

Phase 3: 统一视图

目标：把两个核"变成一台电脑"。

  • 统一文件系统（实时层受限只读视图）
  • 统一设备抽象（传感器/执行器统一 API）
  • 统一网络命名空间
  • 统一日志与调试

Phase 4: 真实硬件适配

目标：在真实机器人/无人机硬件上运行。

  • STM32MP1 / i.MX8M 等 AP+RP 组合适配
  • 故障隔离与看门狗
  • 自研中间件与应用框架
  • 性能与抖动基准测试

六、总结

AUNIX 的核心哲学是："异构多核，用起来像一个系统。"

它不试图在单核性能上超越 Linux 或 RTOS，而是解决机器人/无人机领域"主控 + 实时控制层"双系统割裂的问题：两套代码、两套工具链、手写跨系统协议。

场景 当前方案 AUNIX 方案
给电机控制器下发实时命令 单独烧录 MCU 固件 + 手写协议 统一 API 调用，系统自动放置到实时核
查看实时任务状态 串口 printf 统一 ps 命令
实时任务访问传感器 MCU 直接接线 + 手动管理 统一设备抽象
主控升级/崩溃 分别升级，崩溃可能失控 统一升级，实时层故障隔离

AUNIX 不是一个"更好的 Linux"，也不是"更好的 RTOS"，而是一个从零实现、把通用计算与实时控制统一起来的原生异构操作系统。它的形态是 一个自研微内核（AUNIX-MK）+ 多个可扩展的个性（AUNIX-G / AUNIX-RT）：微内核提供最小机制与隔离，个性提供策略与完整服务。它汲取了 QNX（微内核 + 进程化服务）、seL4（能力与安全验证）、OpenAMP（核间通信）等系统的设计经验，用 Rust 从硬件引导层开始完整实现，目标是让"设备即电脑"成为现实。

七、最先进：五条可证伪承诺

定位声明：AUNIX 的"最先进"不是全能冠军，而是按特定轴线、以特定方法的第一。以下五条承诺全部可证伪——实现或验证失败即撤回对应声明，不靠形容词支撑。五条对应的设计出处见 MX（抽象宪章）与各里程碑文档。

# 承诺 验证方法 设计出处
C1 机制核心内存安全由构造保证：kernel/ 零 unsafe，unsafe 仅允许出现在 arch 汇编边界 CI lint：#![forbid(unsafe_code)] 编译期强制 MX §8 D26 / M0 §6
C2 调度/IPC 状态机与规范一致：TLA+ 为规范源，模型文件随里程碑入库 TLC 跑性质（互斥/无死锁/有限进步/唤醒正确）+ 运行期不变式断言 MX §8 D27/D28
C3 混合关键性 RT 调度（AMC 两模式 RTA + EDF-VD），运行时准入与 host 分析同源 sched-core 单一实现；基准任务集 0 违约 M5 D9 / M6 D7
C4 跨核只经单向消息传递，无锁、无并发读写竞争（AMP 确定性） TLA+ 证"每核状态机 + 跨核消息为唯一交互"；Phase 2 实测跨核时延预算 MX §9 D29–D32
C5 规范即代码：AI 生成实现、机器校验映射，里程碑三段式交付 每里程碑 TLC + 断言 + 微基准全绿才推进 本文档 §八

诚实边界：AUNIX 不声称 seL4 级全功能 refinement proof（无 Isabelle/HOL 证明链）。C1–C5 的组合——内存安全由构造保证 + 状态机机器校验 + 混合关键性确定性 + AMP 无竞争论证 + 规范即代码——是嵌入式微内核中罕见且可审计的定位，而非"证明比 seL4 更正确"。任何对外叙事必须按上表"承诺→验证方法"成对引用，禁止单独使用"最先进/可证明"字样。

八、开发方法：规范即代码（AI 原生）

每个里程碑三段式交付，文档与实现同步推进：

  1. 规范：TLA+ 模型 + 中文设计文档（docs/design/mN-*.md）——模型是唯一事实源，实现与之逐条映射。
  2. 生成：AI 按规范生成 Rust 实现（机制核心零 unsafe，见 C1）。
  3. 校验：TLC 跑性质 + 运行期不变式断言 + 微基准（超预算即败）+ QEMU 自检退出码。

三段全绿才算里程碑完成；模型与实现不一致即 bug，优先改实现。这是 seL4 时代不存在的生产范式：把"验证"从项目末尾的研究课题变成每个里程碑的强制门槛，也是 C5 承诺得以兑现的工程基础。