一台主镜口径 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 软件开发与测试测量系统集成从硬件选型、方案设计到现场交付调试提供一站式服务。手上如果有大规模实时控制、多核并行计算或硬件在环测试一类的项目欢迎在评论区留言身边朋友有类似项目也欢迎帮忙引荐。