在汽车智能座舱里做光学HUD抬头显示是绕不开的硬骨头。它不像常规投影仪那样“正对一堵白墙”就行而是要把虚拟图像叠在真实的道路环境上隔着挡风玻璃反射进人眼并且要经得起白天强光、夜间低照度、不同身高的驾驶员连续观察。我这些年经手过好几个HUD项目最大的感受是一套完整且能落地的HUD设计流程必须同时握住两条线——前段的成像光学设计和后段的驾驶视觉验证。前者靠 Ansys Zemax OpticStudio 这类成像设计工具把光路算透后者靠 Ansys Speos 这类场景级光学仿真工具把“人坐在车里到底看到了什么”还原出来。这篇文章就把我从镜面参数优化到最终驾驶员眼盒验证的完整流程拆开讲。适合正在做 W-HUD/AR-HUD 的光学工程师、座舱人机交互HMI仿真工程师以及刚接手HUD项目想快速建立整体技术框架的朋友。1. HUD项目为什么必须走Zemax与Speos协同这条路1.1 单一工具做全流程的巨大隐患很多刚入行的工程师会问Zemax 本身就能追光线、算像差、看 MTF为什么还要再拉上 Speos 折腾一遍先给结论Zemax 管的是“这台光学仪器成像质量够不够好”而 Speos 管的是“这个图像放进真实座舱里驾驶员能不能看清、会不会被环境光淹没、重影是否可接受”。这是两类完全不同的问题。Zemax 里你可以把挡风玻璃简化成一个理想倾斜平板但在真实世界里挡风玻璃是一块带有楔角、上下表面都有反射、还夹着 PVB 膜层、四周曲率还在变化的多层夹胶曲面玻璃。而 Speos 恰恰擅长处理这种带材料属性、带表面散射吸收、带环境光源的复杂几何场景。单一工具做全流程的最大隐患是“设计指标在图纸上满足上车后却翻车”。比如某个离轴自由曲面反射镜在 Zemax 里 RMS 波前差优化得很好但放进真实的座舱模型中太阳光以某个角度打到镜筒内壁通过自由曲面镜边缘散射进眼盒直接导致白天对比度下降。这种问题用纯成像设计软件几乎无法预判必须要靠 Speos 做“你在车里实际能看到什么”的模拟。1.2 协同设计的整体技术框架我的标准做法是把 HUD 项目拆成三个递进阶段对应三套不同侧重点的工具第一阶段Zemax 完成光学系统几何建模仿真与优化包括 PGU 像源参数、反射镜面型、眼盒位置、虚像距离VFD、视场角FOV、畸变与双像控制。第二阶段把 Zemax 中优化好的光学面型、挡风玻璃楔角、光源亮度分布等关键信息导出在 Speos 中搭建包含真实座舱内饰、挡风玻璃、外界环境太阳、天空、道路的场景模型。第三阶段在 Speos 里放置虚拟相机/人眼模型做亮度、色度、清晰度、畸变网格、环境光干扰等多维度评价输出可直接作为项目评审依据的“视觉证据”。这里有个很关键的前提Zemax 和 Speos 是同一个 Ansys 大家族里的产品数据交接有官方通道。尤其 Ansys 完成对 Zemax 的收购整合之后OpticStudio 里的出瞳光场、镜片实体、自由曲面数据可以比较顺畅地导入 Speos。如果项目中遇到格式对接不畅最常见的替代方案是统一用 STEP 几何格式交换模型再用标准辐亮度文件传递光源数据。2. 前段设计基于Zemax的HUD光学优化全拆解2.1 HUD光学系统建模的几个核心参数我每次建模 ZEMAX 中的 HUD 系统都会在开始前把这几组数字跟光学负责人和座舱布置工程师对齐因为它们直接决定系统能不能放进仪表板里像源PGU参数常用 TFT-LCD、DLP 或 LCoS。以主流 AR-HUD 为例有效显示区对角线约 45~60 mm长宽比一般 1.5:1 到 2:1。虚像距离VFDW-HUD 一般 2~3 mAR-HUD 通常做到 7.5 m 甚至更远目的是让虚像能落在前方道路区域附近。视场角FOVW-HUD 常见规格约 5°水平×1.5°垂直AR-HUD 的普及款在 10°×4° 左右。FOV 越大放大倍率越高光学系统体积和面型难度也呈指数上升。眼盒Eyebox一般要求 100 mm水平×50 mm垂直以上AR 级产品会做到 120×60。眼盒区域内的每一点都是驾驶员的潜在眼球位置系统必须保证在整个眼盒范围内都有可接受的成像质量。人眼瞳孔直径白天约 2~3 mm夜间可扩大到约 6~7 mm。Zemax 分析中通常按 3~4 mm 的入瞳直径去评价典型工况。再补一个非常容易踩坑的参数——挡风玻璃夹角与楔形膜。挡风玻璃有厚度内外表面都会反射 HUD 的光如果两个反射像叠在一起就会形成重影。解决手段是给挡风玻璃的 PVB 膜层做楔角设计让两个表面的反射像在眼盒处错开。楔角通常在 0.5~2 mrad 量级。在 Zemax 中我一般用两个分隔一定距离的表面加一段 PVB 介质材料来表征而不是简单一个面。2.2 离轴结构与像差优化实操HUD 光路十有八九是离轴反射结构。之所以必须离轴是因为要避免 HUD 机构遮挡驾驶员前方视野也为了能把整个光机塞进仪表板前方狭窄空间。典型布置像源上方有一个平面/小自由曲面折叠镜光线向下或斜向射到一片大的离轴自由曲面反射镜再由这块反射镜把光投向挡风玻璃最后反射进入眼盒。离轴必然带来显著的非对称像差尤其是畸变、像散和彗差。常规球面或偶次非球面根本压不住所以大反射镜我会直接用扩展多项式Extended Polynomial面型也就是在标准非球面基础上叠加一系列关于径向坐标和方位角的多项式项。在 Zemax 的 Surface Properties 里选 Extended Polynomial变量不需要一上来全放开。我的优化顺序是先用坐标断点Coordinate Break建立离轴结构骨架通过控制各反射镜的厚度和倾斜角确保光路在空间上不遮拦、有合理的折叠夹角。固定结构参数只放开反射镜的曲率半径和二次曲面系数做第一轮局部优化Damped Least Squares把系统拉到可成像状态。再放开扩展多项式中的高次项从 4 阶项开始逐步加到 6 阶、8 阶每加一批就重新优化一轮并观察各个系数对像差的实际贡献。在评价函数里加入多重结构或视场约束来控制畸变。HUD 最怕的就是虚像网格变成“枕形”或“桶形”所以我会用 DIMX畸变控制操作数约束主光线的落点位置或者用 GRID 畸变操作数让各视场主光线交点严格成矩形。一个很有代表性的计算例子水平 FOV 10°、VFD 7.5 m 时虚像宽度约为2 × 7500 × tan(5°) ≈ 1312 mm。如果 PGU 有效显示宽度为 60 mm那么整个系统的横向放大倍率约为1312 / 60 ≈ 21.9 倍。这个数字帮助我快速判断最终成像系统的等效焦距大约在数百毫米量级自由曲面镜的口径和离轴角度也由这个比例反推。这套初步计算能让我在建模前就对系统尺寸和像质边界有个预期而不是盲目地丢给优化器硬跑。优化过程中最难的是同时满足眼盒中心和边缘的像质。我的评价函数里会设置至少 9 个视场点眼盒中心、上/下/左/右边缘、以及四个对角点。如果中心视场像质已经接近衍射极限边缘视场却掉得很厉害通常不是单纯靠加高次系数能解决的而是要回头调整光瞳位置或者反射镜的相对倾斜角。这个时候不要死磕优化器先做几组参数扫描看清趋势更高效。3. 后段验证基于Speos的驾驶视觉场景级仿真3.1 从光学模型到真实座舱场景的数据转换Zemax 阶段的成果是一套“理想化”的光学参数文件。进入 Speos 前我需要把它转换成能放进整车几何环境中的东西这步衔接工作做得顺不顺直接影响后续验证效率。首先要处理的几何是挡风玻璃。Zemax 里我可能只建了一块带楔角的平板但在 Speos 里必须用真实的挡风玻璃 CAD 曲面并给内外表面分别赋予玻璃材料属性、透过率、反射率中间层设定为 PVB。这里特别强调光谱数据一定找供应商要实测值不要用材料库默认的“通用玻璃”参数。挡风玻璃的透过率曲线直接决定虚像亮度反射率曲线影响重影深浅楔角公差影响双像分离的一致性。用默认数据算出来的结果只能看结构不能用来做最终评审。然后是镜面模型。Zemax 中优化得到的自由曲面反射镜我会导出其面型点云或 STEP 实体在 SpaceClaim 里转成 Speos 可识别的光学面并给反射面设定高反射率镀膜比如铝反射膜反射率约 88%~92%介质膜可以做得更高。注意保留镜筒内壁、壳体结构并在 Speos 中赋予一个较低反射率比如 3% 以下的漫反射材料因为杂散光往往不是在主光学面上出问题而是壳体内部的多次散射。光源数据是协同环节里最容易被卡住的地方。常规做法是把 Zemax 中像源位置的光照分布/出瞳亮度分布导出为辐亮度文件再在 Speos 里映射为面光源或导入光场文件。具体操作时我会在 Zemax 中使用“Source File”或保存包含光瞳信息的辐亮度文件然后在 Speos 的 Source 选项中直接选择导入。如果格式不兼容退一步的做法是在 Speos 中直接建一块与 PGU 同尺寸的矩形面光源把像素图如测试图卡、导航地图作为它的亮度图样。这种方式牺牲掉了 Zemax 中畸变和像差带来的光学效应所以只能用来验证环境光照、杂散光和均匀性不能用来评价最终虚像清晰度。3.2 眼盒评价与视觉指标实操把模型、材料和光源都架好之后我在 Speos 中会重点验证以下几项第一项是亮度均匀性。在眼盒中心放一个虚拟相机/传感器设置好与人眼匹配的视场角仿真结果是整个虚像区域的亮度分布。我一般看两个指标中心到边缘的亮度衰减是否在 50% 以上以及相邻区域是否有明显的明暗条纹。HUD 像源是背光板加 LCD 的本身就存在鬼影和亮度不均投影到虚像距离后往往会被放大。如果某个局部的亮度落差超过 20%我会回到 Zemax 检查像源的角度响应以及自由曲面镜的镀膜均匀性。第二项是双像与鬼影量化。Speos 的光线追迹天然包含挡风玻璃内表面和外表面的反射路径我可以在眼盒位置分别统计仅含外表面反射、仅含内表面反射的光线输出两张亮度图叠加比较。这时楔角参数的重要性就体现出来了——楔角设置不准重影分离距离不够会直接影响驾驶员的阅读舒适度。常规要求是虚像的双像角分离量小于 1 mrad换算到 7.5 m 处大约相当于虚像面上偏移不到 7.5 mm直观判断就是“眼睛看不出来”。第三项是环境光干扰模拟。白天场景下太阳光从前挡风玻璃射入座舱有可能直接照到 HUD 镜筒内部、在自由曲面镜上产生强反射或者从像源保护玻璃上产生眩光。Speos 中我通常设置太阳方向与光谱辐照度晴天约 130000 lux并叠加天空环境模型观察眼盒位置的“眩光亮度”与 HUD 虚像亮度的对比。如果对比度低于某个阈值驾驶员就会觉得图像发白、看不清。这是典型的跨工具问题Zemax 的成像设计再漂亮也必须在 Speos 这类场景级工具里验证才放心。4. 协同工作流落地与工具链踩坑实录4.1 Zemax、Speos在Ansys平台下的数据交互配置现在 Ansys 已经把 Zemax 和 Speos 纳入了统一生态数据交互比早年顺滑多了但还是有几个配置细节值得注意。一、保持版本一致。我在项目里吃过亏两台机器分别装了不同年份的 Zemax 和 Speos结果导出的光源文件互相读不了。虽然 Ansys 产品支持一定程度的向后兼容但跨大版本交接经常出现属性丢失尤其是材质定义和光学属性。建议项目组统一使用同一个服务包版本比如 2024 R2 就全用 2024 R2。二、坐标系对齐。Zemax 的光轴坐标系跟 Speos 里的整车坐标系通常是 X 向后、Y 向上、Z 向右不同主机厂略有区别不是一回事。我一般会在导出前先用 SpaceClaim 把 HUD 总成的装配坐标系和整车坐标系统一起来并把 Zemax 中自由曲面镜的顶点位置意图转换成整车坐标系下的绝对坐标。这个环节至少要验收一次导入 Speos 后用“截面/线框”模式检查反射镜、挡风玻璃和眼盒的相对位置是否和整车布置一致。三、光源文件命名和内容管理。HUD 项目迭代频繁我见过工程里出现十来个名字类似“source_v3_final_really_final.sdf”的光源文件最后没人记得哪个是当前版本。我的做法是给每个迭代版本的 Zemax 方案和对应的 Speos 光源文件打上同一套编号例如 “HUD_AR_v12_0716_eyebox_L”并在一个共享表格里记录版本、修改内容、责任人。听起来老土但真能救命。4.2 工具链常见问题与排查经验整理实际操盘这套流程碰到的工具问题不少我把几个典型的记在这里按出现频率排序Zemax ZPL 宏报 “unknown symbol getthickness”。这通常是宏语言版本兼容性问题。Zemax 不同版本对 ZPL 关键字的支持范围有变化老版本的不支持某些高版本函数。我用下来最稳的排查方法先确认脚本里是否有大小写/拼写错误再查当前版本文档里拐变厚度函数的正确关键词ZPL 中一般用 THIC 变量或者 OPTH 操作数提取厚度而不一定叫 getthickness。如果确实是从旧工程抄过来的宏优先考虑改写而不是强行升级。Speos/Ansys 许可证报错 “failover feature ansys electronics_desktop is not available”。这是 Ansys 许可证管理器里配置了 Failover 到另一个 feature但当前客户端拿不到对应的授权。处理这类问题我按这个顺序走打开 Ansys License Management Center先看服务状态再检查许可证文件里到底包含哪些 feature 关键字然后让客户确认是否购买了对应的模块授权。很多时候不是安装问题而是服务器端授权列表里压根没有这个 feature。这里别反复重启服务先比对 feature 列表才高效。Ansys 启动 Mechanical 求解器模块报错。常见于安装目录或临时目录权限不足或者杀毒软件拦截了求解器进程。我会先看安装目录的读写权限清理系统 TEMP 目录再用管理员身份启动。Ansys 官方文档中的 Troubleshooting 章节列的命令行验证方法也值得照做一遍。Ansys 安装时 MAC 地址显示为 ffffffff。这其实是网络适配器未正确识别常见原因是禁用了真实网卡或者用了虚拟网卡。授权服务取不到真实物理网卡的 MAC就会显示成全 f。排查时把禁用的网卡开启或者到设备管理器里确认物理网卡是启用状态再重新生成许可证请求文件。Ansys Fluent 2024 计算中途能否关电脑。这本身不是 HUD 流程的核心但团队里有人问过。原则是只要能接受丢失当前步进之前的迭代成果就可以关但如果想从中断点继续必须在计算前设置自动保存Autosave比如每 50 步保存一次 .dat 文件。中断后从最近一次 .dat 重新启动能避免从头跑。HUD 项目里我们做太阳光散射仿真单次跑动辄几个小时我都会建议先确认 Autosave 开启。5. 项目复盘与个人建议5.1 设计迭代中经常被忽略的四个细节走完整套流程后有几个容易“事后才后悔”的细节我在这里集中提醒一下。第一Zemax 优化时的挡风玻璃楔角必须跟 Speos 场景里的挡风玻璃模型保持一致。不少项目在 Zemax 里用 1.5 mrad 楔角优化得好好的但 Speos 里的供应商 CAD 模型根本没带楔角于是重影验证怎么都不过。这属于典型的数据源不一致要多留一道“模型核对”环节。第二材料和光学属性一定要用实测数据。整条流程里我见过最离谱的事是某次太阳光模拟结果特别暗检查了半天发现 Speos 里的座舱玻璃材料透过率设成了 5%实际挡风玻璃可见光透过率应该是 75%~80%。一个错误参数会让前后几轮验证全部失去可信度。第三自由曲面反射镜的加工可达性。扩展多项式面型在 Zemax 里优化得很漂亮但高次项系数量级如果过大会导致面型局部曲率变化剧烈加工时刀痕明显散射变重。我会在优化结束后用面型图功能看曲率半径分布是否平滑并且把高次项系数的绝对值控制在合理范围内通常不超过主曲率的千分之一量级。第四眼盒采样密度不够会造成“假通过”。Speos 里我至少要在眼盒区域布 5×3 或 7×5 的网格观察点只取中心一个点验证是不足以说明问题的。HUD 是给不同坐姿、不同身高驾驶员用的边缘眼盒位置往往才是性能瓶颈。5.2 这套流程还能往哪里扩展在我个人经验里ZemaxSpeos 双平台协同的价值不只停留在 HUD。AR-HUD 往高阶走需要跟 ADAS 感知信息做融合显示此时虚像坐标系要和真实道路坐标对齐畸变和视场角精度要求更高前面提到的 DIMX 畸变控制和 Speos 网格畸变验证就更加重要。另外把同样的协同思路迁移到车载激光雷达的挡风玻璃窗口设计、车内氛围灯的光学污染评估、甚至电子外后视镜的防晒防眩目设计都是完全走得通的。最后分享一个小技巧我在实际项目里会把 Zemax 的 ZOSAPI 脚本和 Speos 的自动化脚本串联起来批量跑“改一个参数-重新优化-导光源-验证亮度均匀性”的循环跑完自动出一张对比曲线。虽然搭建这条自动化链路花了两三天时间但后续每轮设计迭代从原来的两天压缩到半天项目时间一下子从容了很多。如果你所在团队有多条 HUD 产品线我强烈建议把这套流程沉淀成标准模板而不是每次从零开始。