LabVIEW 让 984 块镜面 1 ms 完成对齐

一台主镜口径 42 m 的望远镜，镜面由 984 块六边形拼成，控制系统每一轮要算一个 3,000 × 6,000 的矩阵乘 6,000 维向量。这套闭环必须在 1 ms 内跑完，而最终用的是商用现货（COTS）软硬件。

望远镜拼接镜面阵列与执行器，界面呈现镜面共相对齐结果

01 要做什么：背景与技术难点

长期开发和部署大型望远镜的过程中，下一代项目的设计已经进入 phase B 阶段：主镜口径 42 m，整机集成 5 面镜子，初步设计与样机验证拿到了 1 亿美元（USD）经费，phase B 之后计划于 2010 年底开始建造。同期，还在参与建造一台 66 面天线的亚毫米波望远镜，预算约 10 亿美元（USD），计划 2012 年建成。

42 m 主镜 M1 是拼接镜：984 块六边形镜面，单块重近 330 lb，口径在 1.5 到 2 m 之间，拼出 42 m 的总口径。作为量级参照，一台在轨空间望远镜的主镜口径只有 2.4 m；这台望远镜的主镜尺寸是地面上任何光学望远镜的 4 倍。

控制要管两件事。主动光学（active optics）把传感器、执行器和控制系统组合起来，维持镜面的正确形状与准直（collimation），压低光学设计里的残余像差，提升效率与容错；这类校正整晚每一分钟都要做一次，让成像只受大气效应限制。自适应光学（adaptive optics）用类似的方法监测大气扰动，频率在数百赫兹量级，再用一面可变形的薄镜去修正；湍流的尺度长度决定了变形镜上要放多少个执行器。

过去的控制系统是自研的，基于虚拟机环境（VME）的实时控制，昂贵且耗时。这次的目标是换掉它：用商用现货（COTS）的软硬件，把主镜 M1 与自适应镜 M4 的实时控制跑起来。

02 难在哪：千万量级的矩阵乘，和一条不确定的网络

先看 M1 的计算量。984 块镜面之间可能互相倾斜，用边缘传感器监测偏差，执行器支腿必要时能让一块镜面朝任意方向倾斜 3 度。这些镜面配了 3,000 个执行器和 6,000 个传感器。软件要读回传感器值判断镜面位置，一旦偏移就用执行器把它掰回来——对应一次 3,000 × 6,000 的矩阵乘 6,000 维向量，而且每秒要完成 500 到 1,000 次。

M4 更难。它是一面 2.5 m 直径的薄变形镜，铺了 8,000 个执行器。控制逻辑和 M1 类似，但目标不是保持形状，而是根据测得的波前图像数据去改变形状。波前数据映射成一个 14,000 维向量，8,000 个执行器每几毫秒就要更新一次，构成一个 8 × 14 k 的控制矩阵乘 14 k 维向量；向上取整到 9 × 15 k 之后，计算量大约是 M1 的 15 倍。

这个规模直接决定了架构：M4 控制可以拆成 15 个 3 × 3 k 的子矩阵问题，所以需要 15 台机器，而且每台的核数越多越好。

再看通信。在这类实时高性能计算应用里，通信和计算是绑在一起的，通信一挂整个系统就挂，所以通信与计算的交互设计要贯穿开发全程。标准以太网不能用——底层网络协议不确定。改用 LabVIEW Real-Time Module 的时间触发网络特性，在控制系统和 M1 镜面模拟器之间交换数据，得到的是一条确定性传输 36 MB/s 的网络。

03 方案：硬件在环，把望远镜先"跑"起来

控制系统必须在望远镜真正建造之前完成，而系统的配置还可能反过来影响望远镜的建造特性，所以测试必须做到"就像在跑真望远镜一样"。

做法不只是实现控制系统，还实现了一个 M1 镜面的实时仿真，用它做硬件在环（HIL）测试；HIL 是汽车与航空航天控制设计里常用的方法，用一个准确的实时系统仿真器去验证控制器。整套控制与镜面仿真都用 LabVIEW 开发，部署到一台运行 LabVIEW Real-Time Module 的多核 PC 上，以获得确定性执行。

硬件规模是两台各含 8 个核的工作站加一台笔记本做操作界面，网络两张——一张标准网把两个实时目标和笔记本连起来，一张 1 GB 的时间触发以太网在两个实时目标之间交换 I/O 数据。

M4 的问题更重，只有用最新的多核刀片系统才能解。在 16 刀片的多核刀片系统上的测试结果令人鼓舞：每个刀片 8 核，等于把 LabVIEW 的控制问题分发到了 128 个核上。

04 LabVIEW 里的程序：一个巨型矩阵-向量函数

所有操作的核心是一个很大的 LabVIEW 矩阵-向量函数，绝大部分计算由它承担。工作同时在仿真布局、设计控制矩阵和控制回路三处推进。

闭环实际是这样跑的：控制器每轮读入 6,000 个传感器值，执行对齐镜面的控制算法，再输出 3,000 个执行器值；镜面仿真器接收这 3,000 个执行器输出，叠加一个代表风一类大气扰动的变量，跑 M1 的仿真算法，回吐 6,000 个传感器值，把回路闭合。

性能基准测得很具体：LabVIEW Real-Time Module 加一台装两个四核处理器的机器，用 4 个核、单精度，0.7 ms；换成 8 个核、单精度，0.5 ms。这个多核处理能力是 LabVIEW 用 COTS 方案就能提供的，也正是它对这个问题的吸引力所在。

05 结果

整个控制回路在 1 ms 以内完成，这是"足够好地控制这面镜子"的门槛。控制系统每轮稳定地读 6,000 个传感器值、输出 3,000 个执行器值，镜面仿真器同步给出 6,000 个传感器值闭环。

通道上，时间触发网络做到了 36 MB/s 的确定性数据交换；算力上，8 核单精度 0.5 ms 的基准说明这颗矩阵-向量乘可以在商用多核机器上实时跑完；扩展性上，128 核的刀片分布验证了 M4 那条更重的路线。

结论是：LabVIEW 和 LabVIEW Real-Time Module 确实可以用 COTS 方案实现，并用它控制多核计算拿到实时结果。项目也继续在计算机科学与天文学两个方向上，为这台望远镜的实现设定基准。

06 这个案例说明什么

第一，先把计算量算清楚，再谈平台。这个项目把问题翻译成了三个可核对的数：矩阵有多大（3,000 × 6,000）、每秒要算多少次（500 到 1,000）、闭环时限多少（1 ms）。指标一旦这么写出来，选型就不再是偏好问题——能不能在单精度、多核、COTS 的条件下按时限跑完，可以直接测出来。

第二，确定性必须和算力一起设计。选型时第一时间排除了标准以太网，理由不是带宽，而是底层协议不确定；换时间触发网络之后，36 MB/s 才成为一条可预测的通道。很多实时项目栽在这里：算得再快，数据到得不准时，闭环一样是坏的。

第三，被控对象还不存在的时候，仿真器就是唯一的真值。控制系统先于望远镜建成，配置还会反过来影响建造，所以验证手段就是 HIL，让真控制器去驱动一个实时镜面模型。这不是验证的补充手段，而是这个阶段唯一能拿到结论的路径。

第四，多核不是"跑得更快"，而是把问题拆成能解的块。M4 被拆成 15 个 3 × 3 k 的子问题，对应 15 台机器，再从 8 核一路铺到 128 核。拆不开的问题，加核也救不回来。

第五，精度也是预算的一部分。8 核、单精度 0.5 ms 这个结果里，"单精度"和核数一样关键——它说明在这个控制回路里，够用的精度选择本身就是性能设计的一环。

先把计算量算成三个数

矩阵规模、每秒次数、闭环时限，写清楚再选平台。

确定性要和算力一起设计

标准以太网协议不确定，就换成时间触发网络。

07 写在最后

这类超大规模的实时控制项目，难的不是某一段算法，而是把计算量、确定性通信和验证手段凑进同一个闭环。硬件选型只是起点。

我们专注 LabVIEW 软件开发与测试测量系统集成，从硬件选型、方案设计到现场交付调试，提供一站式服务。手上如果有大规模实时控制、多核并行计算或硬件在环测试一类的项目，欢迎在评论区留言；身边朋友有类似项目，也欢迎帮忙引荐。