极大望远镜的镜面不是一块整玻璃，是几百块拼起来的。每一块都要在毫秒尺度上微调位置和角度，才能抵消大气扰动和重力形变。校正慢一步，星像就糊了。
这类活儿长期被认为是专用实时硬件的领地：专用计算机、专用总线、专用开发环境，贵，而且十年后未必还有人给你维护。欧洲南方天文台（ESO）做的事，是拿商用货架平台把这条路重新走了一遍。
一、「算得完」和「算得及时」是两件事
自适应光学的闭环周期极短。算法算得完，不代表算得及时------如果某一次迭代因为调度抖了一下，晚了几毫秒，这一帧的校正就是错的，反馈回去还会放大误差。
所以这类系统真正的指标不是平均耗时，是最坏情况。平均值达标而抖动超标的系统，在天文台是不可用的。
这一条对做工业测试的人同样成立：凡是闭环，都要按最坏情况验收，不能按平均值。
二、多核不是「堆核」，是「管核」
算法计算量大，自然要摊到多个核上。但多核并行本身会引入新的抖动源：核间通信、缓存争用、任务调度，任何一项没管住，实时性就被吃掉。
ESO 这条技术路线的关键，是用 LabVIEW 实时模块对多核计算做分配与同步的控制------不是把任务丢给操作系统了事，而是明确哪个任务在哪个核、按什么顺序、什么时候必须出结果。
项目档案：ESO 极大望远镜
三、真正被挑战的不是性能，是那个前提
这个项目最有价值的地方，不是跑出了多快的数字，而是证明了一件事：实时控制不一定非要专用硬件。
这句话之所以重要，是因为它改变了成本结构和维护结构。专用硬件的问题不在买的时候，在十年后：板卡停产、驱动不再更新、原厂支持退出，一套还能用的系统被迫整体更换。
大望远镜的设计寿命以几十年计。选型时把「二十年后的可维护性」算进去，结论会和只看性能时完全不同。
这也是商用货架方案在这类装置上越来越常见的原因：不是它更快，是它更活得下去。
实时系统的四个真相
四、这条路线的边界
说清楚边界，比只讲成功更有用。
第一，商用货架不等于随便一台工控机。实时性靠的是实时操作系统、确定的调度策略和经过验证的驱动栈，这些一样要选型。
第二，验证成本不能省。这个项目的成果本身就包含「验证这条路走得通」------在实验室跑通一次不叫验证，在装置上按最坏情况跑通才叫。
第三，实时模块解决的是确定性，不解决算法本身。控制律好不好，仍然取决于做光学的人。
五、什么项目适合走这条路
● 闭环周期在毫秒级，对确定性的要求高于对算力的要求
● 算法计算量大，需要多核并行
● 系统要服役十几年以上，维护成本占大头
● 现用的专用硬件已经停产或支持退出
该不该考虑商用货架方案？
实时系统最容易被忽略的一句话是：平均值没有意义。做闭环的团队，验收标准应该写在最坏情况上。如果你正在为某个毫秒级闭环选平台，或者手上的专用硬件快要停产了，后台留言说说工况，我们做 LabVIEW 实时与 FPGA 这块，最常干的就是把「能不能」先验证出来。
注：本文案例信息来自 NI 官方案例库（ni.com case studies）公开材料，机构名称、装置背景与技术组合均可公开查证；文中未对原始指标作推算或外推，涉及时间、人力等数据均取原文口径。