企业官网建设流程全解析

做卫星载荷应用方案和做地面系统的方案，完全是两种思维方式。地面系统上线之后还能迭代、还能打补丁，卫星不行——载荷跟着火箭上去之后，所有硬件决策基本就冻结了，后面只能靠软件尽量补，但天花板就是当初设计时那套指标。我见过太多项目，需求书第一页写得很大气，等做方案论证时才发现，决定成败的往往不是用户点名要的那个核心载荷，而是被忽略的链路、存储、姿态配合这些"配角"。"卫星载荷应用方案"这个题目看着很大，拆开其实就三件事：搞清楚要把什么信息带回来、怎么带回来、以及上天之前怎么证明这套路数行得通。这篇文章就沿着这几个角度，把我自己做载荷方案论证和评审的经验完整讲一遍，给正在做任务规划或者方案设计的同行做一个参考。

1. 先切开"任务需求"这团乱麻

1.1 载荷、平台与应用方案的边界

很多人做方案时容易把"载荷"和"卫星"混成一件事。严格说，卫星平台是那辆卡车——提供电源、姿控、轨道维持、热控、数传这些公共资源；载荷则是卡车上的专用货箱——负责完成具体任务的设备。平台是标准化、可复用的，载荷才是任务差异的来源。遥感卫星装的是相机或者SAR，通信卫星装的是转发器和天线，科学卫星装的是各种探测仪。搞"载荷应用方案"，核心工作就是把"用户想实现什么"翻译成"载荷需要什么样的指标、平台需要提供什么支持、地面要怎么配合"。

这个边界一旦切不清楚，方案就会失控。比如用户说"我要一个能看云图的相机"，如果你直接按"相机"去选型，忽略了云图产品需要的是特定波段和重访频率，最后很可能做出一台指标很高但产品不满足气象判读要求的载荷。我自己的习惯是：任何方案动笔之前，先画一张资源归属图——哪些要求落给载荷，哪些落给平台，哪些落给地面段。这张图后面就是全项目接口协调的依据。

1.2 方案的三层骨架：任务链、数据链、工程链

我习惯把方案拆成三层来看：任务链路、数据链路、工程链路。这不是什么标准文档的强制结构，而是我做了几个项目以后发现，所有卫星载荷方案的问题几乎都能归到这三条链上。

任务链路回答"拍什么、什么时候拍、在哪个轨道位置拍"。这层直接和用户需求挂钩。比如要做某个区域的水体变化监测，就得先确定重访周期、拍摄幅宽、光谱波段和辐亮度动态范围。这一层是用户最能参与讨论的，因为他们懂业务，但不太懂怎么把业务需求变成工程参数。

数据链路回答"数据在星上产生之后怎么存、怎么压缩、怎么传回地面、地面怎么处理成产品"。这是最容易被低估的一层，也是很多方案后期崩盘的地方。后面我会单独详细讲。工程链路回答"载荷装在哪、功耗怎么供给、热量怎么排、指向精度够不够、在轨寿命内会不会坏"。这一层是方案能不能通过结构、热、电、辐射等专业评审的保障。

方案文档写得再厚，本质上就是这三条链的排列组合，然后给每条链上每个环节一个确定的数字和接口定义。我在评审别人方案的时候，第一件事就是检查这三条链有没有闭环。任务链说"要每天拍一次"，数据链就得算清楚每天产生的数据量在可用地面站资源的条件下能不能传下来，工程链又得保证姿控系统能让相机在每次过境需要拍摄时指向目标。只要有一条链断了，方案就站不住，不管PPT做得再漂亮。

1.3 一句话说清方案的边界

这是我在需求阶段反复逼自己做的事：用一句话说清楚"谁在什么轨道上用什么东西对什么目标做什么，数据怎么到用户手里"。

举个例子。"在550km太阳同步轨道上，用一台多光谱相机对重点地区进行两天一次的重访监测，数据经X频段下传到国内站，经过辐射定标和几何校正后形成标准影像产品"。这句话一旦能说出来，方案的技术状态就有了一半基础，后面所有工作都在往这句话里面填数字。如果说不出来，说明需求还没理清，这时候不管选型多么热闹，都是空中楼阁。

一句话边界还有一个作用：约束范围。很多项目做着做着就发散，用户今天说想看水体，明天说也想看植被，后天说最好能兼顾夜间。每加一个需求，载荷重量、功耗、数据率都是指数级上涨。边界锁定以后，新增需求要排队评估，而不是无脑塞进来，这是方案能按期走完的必要条件。

2. 载荷选型：把需求翻译成硬件指标

2.1 先算一笔物理账，再谈选相机

用户要"看得清"，第一件事就是算地面采样距离（GSD）。GSD = 轨道高度 × 像元尺寸 / 焦距。这个公式很简单，但很多人忽略它的连锁反应。

想提高分辨率，只有三条路：降低轨道高度，换来大气阻力、轨道衰减、寿命缩短和更小的覆盖幅宽；用更长的焦距，直接带来光学系统体积、重量、加工成本和装调难度的指数级上升；用更小的像元，带来灵敏度和信噪比的下降。没有一样是白来的。

我举个例子。轨道高度500km，像元尺寸10微米，想做到1米分辨率，需要的焦距是：H × pixel_size / GSD = 500000 × 0.00001 / 1 = 5米。5米焦距的光学系统在卫星上是什么概念？主镜口径通常要做到1米以上，整个相机体积堪比一个小房间，对平台的承载能力和热稳定性要求极高，这个方案的成本直接上一个数量级。而如果任务其实只需要5米分辨率，同样的传感器配置，焦距只要1米，整套系统的复杂度立刻降下来。

所以方案设计的第一步永远是算账，把任务需求里的每个定性词（"看得清""摸得准""覆盖全"）翻译成定量指标，再反推光学、电子学、结构上要付出什么代价。而不是先拿到一个相机型号，再反过来论证它够不够用——那是本末倒置。

2.2 光学载荷与SAR载荷，选哪个不是看先进

同样是"看地面"，光学和SAR两类载荷的方案逻辑几乎是相反的。光学载荷被动成像、图像直观、便于判读，但受光照和云层影响，晚上和阴天基本不能用。SAR是主动发射微波，全天时全天候，能穿透云层，但图像解译难度大、功耗高、数传压力大、系统复杂度高。

选哪个不是看哪个更"先进"，而是看任务对时效性和可靠性的要求。做海洋溢油监测，目标区域经常有云雨覆盖，SAR往往是更可靠的选择；做土地覆盖分类，光谱信息是核心变量，光学载荷不可或缺。还有一类折中方案是双模式互补——卫星上同时装光学和SAR，但这意味着整个系统的成本、重量、功耗、数传压力都会明显上升，一般只有国家级综合观测任务才承受得起。商业小卫星方案里，我更倾向于把一种载荷做到极致，而不是追求大而全。

这里还有一个经常被忽视的选型维度：数据是否好卖。SAR原始数据和处理软件的复杂度决定了它的准入门槛高，光学影像则有成熟的开源工具链和多年的用户使用习惯。如果方案的目标是快速形成业务化产品，光学通常更容易在短期内让终端用户用起来。

2.3 通信类载荷：链路预算才是主角

通信载荷和遥感载荷的方案逻辑差异很大。遥感关心"拍得清不清"，通信关心"连得上连不上、能传多少数据"。星上转发器的功率、天线增益、带宽，直接决定了地面终端能用多小的天线、多低的功耗入网。这背后是通信系统的基本功——链路预算，也就是把发射功率、天线增益、自由空间路径损耗、大气损耗、接收灵敏度全部折算成分贝数，算出最终的载噪比余量。

低轨通信星座的难点又不一样，重点在移动性管理。卫星以7公里每秒左右的速度划过天际，波束要跟着地面终端做切换，多普勒频移需要实时补偿，单颗星的覆盖时间只有十几分钟。这和同步轨道通信卫星那种"定点覆盖、几乎静止"的方案完全是两套思路。所以做载荷应用方案，必须先明确轨道体制，再谈载荷类型和指标。一个同步轨道通信载荷的方案，抄到低轨星座上，性能会崩得一塌糊涂。

2.4 "够用"比"最强"重要

选型时最容易犯的错是追求最高指标。高指标背后是更高的价格、更重的结构、更严格的加工精度、更大的功耗和更复杂的热控，这些都会挤压平台的余量，还会把整个系统的可靠性拖下水。

我的经验是：先把任务的底线指标列出来——最低分辨率、最大延迟、最小覆盖率、最坏气象条件下的可用性，然后选一个刚好能覆盖这些底线的配置，再保留15%到20%的余量。这个余量不是拍脑袋定的，而是考虑元器件性能衰减、在轨标定误差、数据处理算法损失之后的合理缓冲。

选"够用"的方案还有一个好处：留给软件和算法的空间更大。同样的硬件，算法优化好的团队能把产品指标再提一档，而指标已经顶到物理极限的硬件，算法再好也救不回来。方案设计的思路应该是"硬件留余地，软件挖潜力"，而不是反过来。

3. 链路设计：卫星方案的隐形骨架

3.1 数据的产生速率，远比你想象的快

这是载荷应用方案里最容易被漏算的一笔账。举一个具体例子：一台推扫式多光谱相机，幅宽对应地面20公里，地面分辨率3米，那么焦平面上每一行大约有6667个像元（20000米除以3米）。假设4个波段、每像元量化12比特，卫星地面速度大约7.5公里/秒，所以每秒钟要扫描2500行。数据率算下来是：6667 × 4 × 12 × 2500 = 800 Mbit/s。这是一个非常夸张的数字，意味着每秒钟要产生100兆字节的数据。

如果换成面阵相机，数据率也不低。2048×2048的探测器、12比特量化、每秒5帧，数据率约250Mbit/s。这还没算上图像压缩、数据封装和信道编码的额外开销。如果做高光谱，上百个波段直接把数据率推到几十Gbit/s量级，这时候常规数传设备根本跟不上了，必须在星上先做降维、波段选择和压缩。

很多方案在PPT阶段写着"X波段数传，速率300Mbps"，看起来已经不错了，但拿着上面的数据率一算，8分钟过境窗口里能传的数据量，根本覆盖不了单次任务产生的数据。方案没有闭环，评审一卡一个准。

3.2 数传通道是硬约束，只能提前算清楚

数传通道的瓶颈是系统性的，不只是星上发射机一件事。X波段在几百兆波特率级别，常用QPSK、8PSK等调制方式，配合一定的编码效率，实际净数据速率大约在300到800Mbit/s之间。Ka波段带宽大，能做到1.5到3Gbit/s，但对雨衰更敏感，对地面天线和功放的要求也更高。

光算速率还不够，关键是算可用过境时间。低轨卫星绕地球一圈约90分钟，但只有经过地面站上空时才能下传数据。一次过境的可视窗口短则5分钟，长则十几分钟，而且一天内可见的过境次数往往只有两到四次。算一笔账：一天3次过境、每次有效下传8分钟，X波段375Mbit/s的净速率，一天能传的数据量大约是：3次 × 8分钟 × 60秒 × 375Mbit/s ÷ 8 = 67.5GB。这和上面一节算出来的单次任务百兆字节级数据量一对比，就知道余量有多紧张了。

所以链路设计从来不是最后才做的事，它必须在载荷选型的同时就参与方案迭代。数据率定了，才知道存储器要配多大、压缩算法要用多狠、地面站网络要建几个、中继卫星要不要租。我见过最典型的返工，就是载荷都定标完事了，数传负责人拿着160Mbit/s的速率来说"你们每天最多传20GB"，整个任务规划只能推倒重来。

3.3 星上预处理不是可选项，是必选项

顺着上面的数字往下走，结论很清楚：对于高分辨率或多光谱类任务，把原始数据全部下传是不现实的。星上预处理是必选项，不是加分项。

最基础的手段是压缩。静止图像可以用JPEG2000或CCSDS 122.0标准，无损压缩一般能做到2到3倍，有损做到4到10倍对很多应用完全够用。多光谱、高光谱数据可以用CCSDS 123标准做无损压缩，利用谱段间的相关性，压缩比往往比单波段高不少。压缩算法的选型要考虑星上处理器的算力、内存、功耗和可靠性，不是精度越高越好，而是算力、功耗、压缩比三者的平衡。

第二层预处理是筛选。我在遥感任务里经常建议加一道云检测：可见光波段把亮度阈值和均匀性判据结合，快速剔除被云覆盖的无效影像。很多区域一年里有一半天数有云，不筛掉这些数据，星上存储和数传都在做无用功。更进阶一点，可以做变化检测，只下传相对上次观测发生变化的区域，这对灾害监测这类任务是质变级的效率提升。

第三层是面向产品端的处理，比如辐射校正、几何校正、地理配准，部分任务甚至可以在星上完成正射校正。并不是说这些处理一定要全放在星上——星上算力毕竟有限，工程上要在星上处理和地面处理之间找分界线。我一般的原则是：不依赖高精度地面控制点、不依赖外部参考数据、算法复杂度可控的环节尽量前置；需要全球参考影像、需要人工干预的环节留在地面。

4. 工程约束：方案能不能落地的分水岭

4.1 SWaP三角：功率、重量、体积没有白来的

SWaP是Size、Weight and Power的缩写，这是载荷方案里最残酷的三角形。你要的功能越多，消耗的SWaP越大，而平台的承载能力是有限的。我做方案的时候，会把载荷的功率消耗单独拉一张表：正常工作模式、峰值模式、待机模式各是多少，每种模式每天累计运行多久。然后折算成轨道平均功耗，再乘以电池充放电效率（大约85%），才知道平台需要配多大的太阳电池阵和蓄电池。

这里有个很多人踩过的坑：只看峰值功率，不看平均功率。一台SAR载荷峰值功率能到数千瓦，但实际工作几分钟就要休息很久。如果按峰值去配电源，平台重量爆炸；如果只看平均功率，又可能忽略电池在短时间大电流放电时的电压跌落和热耗。正确的做法是同时确认峰值功率和占空比，再核算电池组的放电深度——低轨任务一般控制在20%到40%，深空任务由于太阳能远离太阳，逻辑又完全不同。

重量和体积同理。光学载荷对结构刚性和热稳定要求高，重量轻不下来；SAR的天线展开后体积巨大，对整星包络、运载整流罩、展开机构都有严格要求。SWaP这个三角，本质上就是在让方案团队面对一个事实：资源是稀缺的，任何指标提升都有代价，取舍要趁早。

4.2 空间环境：热、辐射和真空不是纸上谈兵

载荷在地面实验室里跑得好好的，上了天就不工作，这类事故在行业里并不少见。核心原因往往是方案阶段对空间环境的理解流于表面。

热问题尤其隐蔽。低轨卫星在天上交替经历太阳照射和地球阴影，一个轨道周期内温度可以波动几十度。光学载荷对温度最敏感，镜面微小的热变形会导致成像模糊，所以光学载荷一般都配有精密热控，把关键结构温度控制在某个小区间内，比如20±3℃。热控设计时要注意：功耗大的电子设备需要有直接通向散热面的导热路径，否则局部热点会加速元器件老化甚至直接烧毁。

辐射问题同样不可掉以轻心。低轨轨道总剂量效应较低，但单粒子效应才是主要杀手。高能粒子打进制片器件，可能引发存储单元翻转（SEU），甚至触发闩锁（SEL）导致器件短路发热。方案里必须设计看门狗、电流限制和闩锁保护电路，关键存储区要用检错纠错编码。我见过一个项目，星上固态存储器没有做EDDAC或者说校验不充分，在轨运行半年后就开始出现零星数据位翻转，图像上出现了随机噪声点，排查了很久才发现是单粒子效应，最后只能靠软件重传配合纠正，白白消耗了不少数传资源。

4.3 姿态指向：分辨率越高，对平台要求越苛刻

姿态指向精度这个指标，直接决定了载荷能不能用。为了说清楚这个，我经常把GSD换算到角秒。500km轨道高度、1米GSD，对应的地面张角是1/500000弧度，约等于0.4角秒。这意味着相机指向的一个像素只对应天上极小一个角，姿态如果想保证图像清晰，指向稳定度至少要优于一个像素几分之一，也就是零点几个角秒的量级。

现代星敏感器的姿态确定精度大约能做到1到3角秒，配合高精度反作用轮和陀螺，实现0.5到1角秒左右的指向稳定度是可能的，但这对平台来说是相当大的工程挑战。如果方案要求的是5米GSD，对应张角约2角秒，姿态控制的压力就小得多。这也是"分辨率每提高一档，不只是光学要跟上，整个平台都要跟着卷"的根本原因。

除了指向精度，还有敏捷性。很多任务要求卫星在一条轨道上连续拍多个目标，这需要卫星以每秒几度的角速度快速机动，机动到位后还要快速收敛振荡。机动越快，反作用轮的动量存储和卸载需求越大，姿态控制算法越复杂。方案阶段就要把成像任务序列和姿态机动能力放一起仿真，看看每天几十个目标拍下来，姿控系统能不能扛得住。

5. 真实项目里的取舍与踩坑复盘

5.1 一次指标分解的全过程

说一个我做过的典型项目，用户想做内陆湖泊藻华监测。需求描述很朴素："想在藻华爆发的时候能及时发现，并且能看到变化的趋势。"

从这句话出发，第一步是翻译指标。藻华爆发要求重访周期短，两到三天以内；单次观测能区分水体异常区域，地面分辨率20米足够；需要蓝绿波段、红边和近红外来识别藻类特征；监测需要有连续性，所以太阳高度角不能太低，季节变化导致的观测条件差异也要考虑。把这些综合起来，任务链上的指标清单就有了：GSD≤20米，幅宽≥100公里，波段数4个以上，重访周期≤3天。

第二步是反推载荷方案。550公里轨道、20米GSD、10微米像元，算出来的焦距大约是275毫米，属于中小型相机，工程上完全可控。幅宽100公里对应的视场角是：2 × atan(50/550)，算出来约10.4度，对焦面拼接提出了一定要求，但也在可接受范围内。第三步是算数据率。20米GSD、100公里幅宽，一行5000个像元，4个波段12比特，地面速度7.5公里/秒，每秒扫3750米对应187.5行，数据率≈5000×4×12×187.5=45Mbit/s。再经过无损压缩降到20Mbit/s左右，每天任务时长累计10分钟，约1.5GB数据，X波段随便传。这个方案从头到尾没有被某个环节卡死，就是因为所有链条是同一个数量级，彼此匹配。

5.2 数传速率被严重低估的教训

另一个项目就没这么幸运了。用户选了一台3米分辨率、4波段、幅宽20公里的相机，指标很漂亮，但方案团队在做任务规划时，默认给了S波段数传通道，净速率大约2Mbit/s。

按3米GSD、20公里幅宽算，一行约6667个像元，每秒扫描2500行，4波段12比特，原始数据率高达800Mbit/s。就算星上做5倍压缩，仍有160Mbit/s。S波段2Mbit/s完全不够，差了整整两个数量级。这还不是最要命的，更尴尬的是存储器容量也按压缩前的数据量配了，结果重量和功耗全线超标。

最后是怎么收场的？压缩比调到8倍以上，牺牲了一部分影像质量；数传从S波段升级到X波段，增加了硬件投入；成像任务只有限幅宽和降线速率，相当于把指标主动往下砍。如果这个数据链路的问题能在方案初期暴露，这些代价大部分可以避免。所以我在所有方案评审中，第一个问题永远是"每天产生多少数据，传回地面多少，存不下、传不走的怎么办"，这三个问题答不上来，后面不用看了。

5.3 冗余设计的分寸

冗余设计是方案里最考验工程判断力的事。冗余少了，单点故障直接导致任务失败；冗余多了，重量、功耗、成本全线上涨，还可能引入新的复杂度和故障模式。

我的经验是区分对待。电源、数传、姿控这些平台级关键单机，必须做冗余，通常是冷备份加故障自主切换；载荷内部的探测器、处理器，视任务重要程度决定是整机冗余还是核心模块冗余；存储器的冗余则靠纠错编码和数据镜像来实现，而不是纯粹增加备份盘。

冗余不只是堆硬件，还要写清楚切换逻辑。谁来判断故障，判断依据是什么，切换之后中断的任务怎么恢复，这些都要在方案里明确。我见过一个方案做了双余度星务计算机，但没约定故障判据，结果在轨一次异常导致两台机器抢总线，差点把整星搞死。冗余设计的分寸，可以简单概括为：该有的保命措施一个不少，不该有的花哨备份一个不加。

5.4 评审时最常被挑战的四个问题

方案评审时专家的问题看似五花八门，翻来覆去其实就那么几类，这里整理出来，供大家自查。

第一，任务可用性怎么算。不是"相机能拍就行"，而是要回答"在寿命期内，考虑元器件失效率、单粒子效应、地面系统故障、气象条件，用户到底有多少天能拿到合格数据"。这一数字很多方案算不出来，或者算出来的可用性低得吓人。

第二，定标和验证怎么做。相机的响应是非线性的，会随温度和时间漂移。方案里必须有星上定标手段，比如太阳漫反射板、定标灯，还要有在轨替代定标方案，比如利用已知反射率的地面场景做交叉验证。没有定标方案的遥感载荷方案，评审时基本过不了关。

第三，寿命末期的处置。低轨卫星任务结束后必须进行钝化和离轨，保证在25年内再入大气层烧毁，这是空间碎片减缓的通行要求。方案里要写明推进剂预留量、离轨策略和可靠性评估。

第四，接口和控制权。载荷和平台的机械接口、电接口、数据接口必须定量定义，接口控制文档要详尽到每一根信号线、每一个时序参数。很多项目后期扯皮都发生在接口定义不清上，比如载荷说"我只要28V母线供电"，平台说"我的母线波动范围是26到32V"，两边都觉得对方应该迁就自己，等到联试才发现做出来的电源滤波器根本压不住纹波。

回顾这些年做载荷应用方案的经历，我的核心体会是：越早做链路闭环，越早把任务链、数据链、工程链的数字对齐，方案后期的返工就越少。卫星载荷的每一个指标都不是孤立的——分辨率连着光学、光学连着稳定度、稳定度连着姿控、数据率连着存储和数传、功耗连着电源和热控，牵一发而动全身。这也是为什么这个领域特别忌讳"先定硬件、再找理由"的做法。方案阶段多花一周去算链路、做权衡，往往能省下后面几个月的型号修改和归零分析。希望这篇文章能把这种"先算账、后定方案"的思路传达给正在写方案的你。