给购买波束供电的 EO 卫星星座用的电力调度与结算 OS——把更多成像和下行小时跑出来。

1. 新一轮机构资金到位，说明轨道电力正从科研概念升级为运营方必须提前布局的商业基础设施品类。
2. 兼容标准太阳能板、又不需要定制接收器，让软件层能先落地，不必等整轮硬件换代。
3. 7 份 购电协议 和明确披露的商业 销售管线，意味着很快就会出现真实的供电预订、优化和结算需求，而不只是盯着 演示 看。
4. 国防背书和前太空军高层的信用，抬高了早期买家的任务紧迫性，也更容易撑起高溢价运营工具预算。
5. 在既有纪录和子系统演示之后，2026 年底的波束供电任务给运营方设下了一个近在眼前的准备期限：必须把 具备电力感知能力 的任务流程先搭起来。

催化因素。 Star Catcher 的融资、无需改装的兼容性主张、7 份 购电协议 和 2026 年底演示时间表，说明轨道电力正在从物理演示，转成眼下就要解决的商业采购问题。

产品会接入轨道参数、电池状态、载荷 占空比、成像积压、下行窗口和可用的波束供电时段，给出每颗卫星什么时候该买外部电力的建议。接着，它把建议落成运营 操作手册、供给方预订请求，以及和具体客户 SLA 或突发事件绑定的任务级 ROI 预测。结算层再把购入电力映射到新增图像、完成的推理任务或下传的数据量，让运营方看清这笔电费到底有没有换来赚钱的任务产出。时间一长，平台会学到各个星座自己的电力响应曲线，最后变成轨道能源采购和调度的 核心记录系统。

差异化。 这不是通用卫星任务规划软件，也不是押注供电网络硬件本身。它做的是轨道上一个全新公用事业市场里的编排和结算层，核心抓手是：只有当任务高峰真能 证明值不值y 这笔成本时，才去买额外的瓦数。真正能守住的优势，是跨多家星座和供给方，持续积累 供电窗口 可用性、电池响应曲线、载荷 提升，以及电力到收入转化的数据。

待完成任务

flowchart LR
  Buyer[EO constellation operator] --> Pain[Cannot decide when purchased orbital power is worth using]
  Pain --> Product[Orbital power dispatch OS]
  Product --> Outcome[More profitable imaging and downlink from the same fleet]

高管要点

• Star Catcher 已把轨道电力从“科学项目”叙事，往近期开采购的现实问题上推：它拿到了一轮大额 Series A，展示了无需改装的波束供电，签下了 购电协议，并正瞄准一次在轨演示。
• 滩头买家真实存在，但很窄：EO 和 ISR 运营方本来就在卖速度、重访和分析，因此只有当突发任务或星上处理场景的任务价值足够明确时，增量电力才最值钱。
• 竞争更像替代品之争，而不是正面冲突。通用地面软件套件、自动化创业公司和垂直一体化运营商都在打相邻流程痛点，但目前看，还没人真正占住“中立电力预订 + 任务产出结算”这一层。
• 这家创业公司最大的风险来自外部：供给方落地节奏、不清楚的波束供电定价 / SLA，以及进入贴近飞行的规划闭环所需要的漫长信任建立。

市场定义

这类软件用来预测轨道电力需求、预订外部波束供电窗口、重排任务优先级，并结算其对 EO 与 ISR 星座任务产出的影响。它夹在轨道电力供给方和通用 任务运营 栈之间，而不是和供电硬件本身竞争。

用户与买方

主要用户是 EO / ISR 星座运营商里的 任务运营、规划和 chief architect 团队；他们本来就在管理跨时段任务下达、电池约束和客户 SLA。真正掏钱的是掌握星座 uptime、紧急采集毛利和客户交付风险的运营或项目负责人。

购买触发点

• 某个星座签下试点购电协议或演示合作，需要一套安全流程来判断什么时候该消耗外部电力。 [1][7][9]
• 国防或主权客户开始为快速重访和低时延 ISR 付费，使每一次额外成像或下行窗口的价值都上升。 [14][15][18][20]
• 运营方开始把星上 AI、SAR 或更重的分析工作负载叠到本就功率紧张的卫星上，尤其在峰值运营时段。 [3][12][18][24]

支付意愿

公开资料没有披露波束供电价目表，但付费意愿已经能看见：Star Catcher 说自己签下了 购电协议；BlackSky 在卖合同保障接入；Capella 在工作流里直接展示预估 任务下达 成本；EO 买家也越来越习惯采购“硬件 + 软件 + 商业数据”的打包方案。这说明，只要软件能证明任务提升，而不是只给一个通用 看板，预算就能挤出来。 [1][7][15][17][20]

品类动态

增长信号 广义 EO CAGR 7.9%；EO smallsat CAGR 15.9%

验证信号

• Star Catcher 在真实服务上线前就已披露 7 份 购电协议、多项政府合同和一条足够大的合格 销售管线。
• Payload 报道显示，主权客户越来越倾向于把软件和商业数据与硬件一起打包采购。
• BlackSky、Capella 和 ICEYE 都在卖快速重访、低时延或快速交付，这说明在紧急采集场景里，额外电力很可能真有价值。
• Cognitive Space 和 NASA 都指出，人工卫星运营又慢又贵，而且随着 星座 变大越来越不适合继续沿用。

监管与技术约束

• 新型商业航天活动仍落在不断演进的美国监管框架和基于条约的国家责任之下。
• 小卫星电力系统依旧受质量和体积强约束，尤其在日蚀期和峰值 duty operation 里更明显。
• 地面与任务运营依然高度依赖 API、指令系统和通信流程之间的复杂集成。
• 国家安全场景会比标准商业 EO 工作流多出安全、主权和审批负担。

今天这个市场主要由替代品定义：现有 任务运营 套件、较新的自主化厂商、开源或自研控制栈，以及自己优化自家星座的垂直 EO 运营商。一个中立、可跨供给方的调度与结算层，目前基本还空着。

为什么现有厂商不会默认胜出

• 广谱任务运营套件. 它们本来就覆盖 C2、排程和遥测，但公开资料看不出这些系统是围绕外部电力预订、供电窗口 仲裁或收入归因设计的。
• 自动化专长厂商. AI 原生运营厂商能减少人工规划，但它们公开对外讲的是更广义的星座自动化，而不是围绕电力市场的专门编排。
• 垂直 EO 运营商. Planet、BlackSky、Capella 和 ICEYE 都在优化重访和交付，但它们先卖的是图像结果或主权能力，不是给第三方星座用的中立软件。
• 开源与自研栈. 这类方案依然有吸引力，因为运营方能以较低成本拼出灵活控制层，但集成、安全和经济性建模的负担也会重新压回客户自己身上。

轨道电力调度 OS 卡在一个很窄、但时间点极对的工作流上：当轨道电力从物理演示变成采购问题时，它帮 EO 星座运营商判断买来的波束供电值不值得用，并证明这笔支出有没有抬高任务产出。第一位客户会是美国或欧洲一家拥有约 8-30 颗卫星的 EO 运营商：它正准备启动首个外部供电试点、突发采集合同，或在标准太阳能平台上跑高功耗星上推理项目。产品起步是调度与结算层：预测需求、预订供电窗口、给出经运营方审批的任务重排建议，并把购入电力对上新增图像、分析任务或下行产出。研究给出的时机信号也很强：Star Catcher 拿到一轮大额 Series A，披露了 7 份 购电协议，声称无需改装即可兼容，并计划在 2026 年底做演示；与此同时，EO 和主权 ISR 买家本来就在为更快重访和更低时延交付买单。战略上之所以先从 EO 星座切，而不是更广的 任务运营 软件，是因为紧急成像和下行事件能最清楚地做出“买电前后”的 ROI 对照。这个市场暂时仍小，也受外部供给约束：近端 SAM 估算只有 $4.5M，最大风险在于供给方落地节奏和商业电力定价仍不清晰。公开资料里还没有真实波束供电的 SLA 和价格条款，所以前 12 个月必须证明的不只是有人感兴趣，而是——在供电还没常态化前，运营方也愿意为调度软件真掏钱。

问题

• EO 运营商现在仍靠表格、固定飞规和人工 任务运营 电话来处理电池上限、占空比 权衡和事件驱动的任务高峰，所以他们没法稳定判断：多买一点轨道电力，究竟能不能换来正向任务 ROI。
• 如果外部电力能在不改装硬件的情况下买到，瓶颈就会从硬件稀缺转向另一件事：怎样在跨星座层面预订、排序和结算电力使用，让运营和财务团队都信。

解决方案

• MVP 会接入轨道参数、电池状态、载荷 占空比、成像积压、下行窗口和供给方可用电力，给出哪颗卫星该买电、什么时候买、用在哪个任务事件上的建议。
• 同一套工作流还会生成预订请求、运营 操作手册 和结算报告，把购入电力映射到新增图像、更快交付或额外完成的星上推理。

为什么我们会赢

• 公司卡住的控制点比通用星座软件更窄——它做的是跨运营商、跨供给方的中立外部电力调度与任务产出结算。
• 如果早期 试点 能赢下来，公司就会持续积累 星座 级电力响应曲线、供电窗口可靠性数据，以及电力到收入的归因数据；相邻的 任务运营厂商和自研栈并不会天然拥有这些东西。

里程碑

flowchart LR
  Wedge[EO power dispatch wedge] --> MVP[Shadow-mode dispatch and settlement MVP]
  MVP --> Proof[Paid pilots with mission-yield proof]
  Proof --> Expansion[Provider integrations and adjacent ISR or compute expansion]

创始团队

实验路线图

风险评估

必须成立的条件

• 未来 24 个月内，至少有 5-10 家滩头 EO / ISR 星座会评估外部电力调度软件。
• 即便真实波束供电还没常态化，任务和运营负责人也愿意为第三方规划与结算层付费。
• 至少有 1 家供给方会开放预订权、工作流 接口钩子 或 API，让中立软件层可以接入。
• 早期 试点 能证明可度量的任务产出 提升 或决策提速，而且价值高于软件成本。
• 通用 任务运营厂商和自研栈来不及补齐外部电力工作流缺口，给独立切入者留出窗口。

待尽调问题

• 早期电力供给方究竟会向运营方和软件伙伴开放哪些预订、定价和 SLA 原语？
• 哪些 EO 星座既有兼容平台，又有足够高价值的近期任务事件，能 证明值不值y 购电？
• 在运营方愿意把建议接进贴近飞行的规划闭环前，还需要做多少集成工作？
• 在拿不到敏感收入或载荷数据的情况下，公司能不能照样证明事件级 ROI？
• 如果真实波束供电拖到 2027 年或更晚，产品还能保持软件属性，还是会滑成重服务的仿真业务？

模型合理性

• 收入引擎. 基准情景的收入来自 Y1 的 2 个付费 试点，并在 Q1Y3 前复利到 6 个活跃 星座客户；到 Y3，每个客户的综合年收入约为 $220K。
• 必须跑通的环节. 供给方 集成和可复用 星座 适配器 必须把 接入 压到 4 周以内，毛利率才能在客户增长时往 70% 目标爬。
• 模型会失灵如果. 如果 供给方 落地慢了 1 个季度，而且综合 ACV 一直停在 $180K 左右，现金缓冲就会在 seed 融资前朝 downside 情景快速收缩。
• 下一轮融资证明点. 一个有说服力的 seed 故事应该是：到 Q4Y2 拿到 5 个付费 星座客户，再跑出 1 条有 供给方 背书的工作流，证明这正在变成可复制控制层，而不是定制服务。

情景

敏感性

flowchart LR
  DesignPartners --> PaidPilots
  PaidPilots --> AnnualContracts
  AnnualContracts --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

警示项: 近端 SAM 只有约 25 个 EO 或 ISR 项目，因此丢掉 1 个灯塔客户或 1 个 供给方 合作，就会明显改写增长曲线。 · Y1 毛利率刻意做低，因为早期部署在可复用 适配器 出来前，仍有相当一部分像服务项目。 · 基准情景到 Y3 结束时 EBITDA 仍略为负值，因此下一轮融资靠的是可复制性和扩张证明，而不是单纯盈利。 · Y3 的 ARPU 假设买家愿意接受适度的托管电力抽成或 供给方 侧 席位 提升，但公开语料里关于电力定价的 基准 依然很薄。

• 供给方落地延期. 如果轨道电力演示或商业服务可用时间拖到 2026 年之后，客户可能会推迟采购这类工作流软件。 缓解措施: 先从仿真、试点规划和合同就绪模块做起，在真实供电时段还不频繁时先交付价值。
• 集成摩擦. 任务规划、飞行软件和供给方预订系统很可能都足够定制化，导致每个星座的 接入 都慢又贵。 缓解措施: 先盯住使用相似平台和任务规划栈的一小批 EO 运营商，再把这些部署里沉淀出的 适配器 产品化。
• 初期市场过窄. 第一批既有能力、也有意愿购买外部轨道电力的星座可能很少，客户集中度风险高。 缓解措施: 先卖给相邻的国防载荷项目和新兴电力供给方，等供给起来后，再从 EO 扩到通信和在轨计算运营商。