GNSS 仿真 HIL 调试：五类常见问题的排查思路与解决方法

随着 GNSS 仿真测试在车载、无人机及智能终端研发中的应用不断深化，HIL（硬件在环）仿真已成为验证定位性能的关键一环。

然而，在实际工程中，当 HIL 模拟器通过 UDP 向 Skydel 推送 PVT（Position, Velocity, Time）数据时，许多测试工程师会遭遇一系列“看似简单、排查却耗时”的问题——仿真坐标莫名偏移、速度异常超限、系统延迟过大、初始点对齐困难。

这些问题往往不是单个环节的故障，而是涉及坐标系转换、时间同步机制、数据协议设计等多个维度的交叉影响。传统的手动排查方式不仅效率低下，更容易因经验差异导致结论不一致。

本文整理了 HIL 调试过程中五类高频问题的原因分析与解决方案，全部来自一线测试场景的真实沉淀。

我们特别邀请到德思特研发工程师Liam和技术工程师Ian，围绕这些问题与背后的技术逻辑与实战经验，带来第一手的深度解读。 

如果你正在经历类似的“卡点”，希望接下来的内容能帮你快速定位问题，找到正确的解决路径。

一、仿真坐标点与实际不匹配

Skydel-> Map右侧面板中显示经纬度(latitude、longitude)的值与HIL模拟器输出的经纬度的值不一致，导致仿真轨迹出现错误，怎么解决？

Liam：Skydel提供了一套API，只要按照固定的格式输入坐标数据，Skydel就有在该坐标位置进行仿真。出现位置异常，常见的原因如下，可逐一排查：

1、角度/弧度转换问题

在Skydel的HIL坐标推送接口中，接受的经度、纬度必须以弧度单位进行输入，如果是角度数据必须先进行转换。比如推送LLA(经纬高，lat, lon, alt)数据的接口，其中纬度和经度都是弧度制，以sim.pushlla接口为例：

角度制转为弧度可以直接使用skydelsdx库中的toRadian函数来实现。

2、经纬度输入顺序问题

在构建Lla对象的时候，纬度在前，经度在后，否则会出现仿真坐标点错误。

当python脚本通过UDP获取到HIL模拟器的位置数据之后，构造Lla时需要注意经纬度的顺序问题，并且经纬度都应该是弧度。

3、坐标系转换问题

Skydel的HIL API接收的LLA数据点，必须基于WGS-84坐标系：

如果HIL模拟器中传输的坐标不匹配，需要先进行转换，否则可能导致仿真位置偏离数十米至数百米。

二、HIL系统的延迟过大

HIL仿真过程中，在Skydel软件下方的的”performance”一栏可以观察HIL延迟，出现延迟过大的情况怎么办？

Liam：关于延迟过大的问题，我们整理了三种可操作的解决路径，大家可以根据实际场景逐一排查：

• 调整时间同步策略：HIL 脚本中的 isOsTimeSyncWithPPS参数控制着操作系统时间与 PPS 信号的同步方式。如果当前设置为 True，可尝试改为 False；反之亦然。这一参数直接影响推流时刻的计算基准，切换后往往能有效缓解延迟。
• 优化推点节奏：适当提高轨迹推送点的频率，或降低 Tjoin 参数的值，可以缩短系统在每一步等待对齐的时间窗口，从时序上压缩延迟空间。
• 引入 NTP 统一时钟：对 HIL 模拟器与 Skydel 执行基于 NTP 的时间同步操作，确保两端在同一个时间基准上协同工作，减少因时钟漂移或不同步带来的延迟累积。

三、HIL 启动的时间对齐

如何在HIL仿真中实现不需要手动传入初始点就可以进入HIL仿真？

Ian：我们的处理逻辑是“先对齐，再启动，确保从第一个有效位置开始推流”。

在以往的测试中，如果 HIL 先启动再等待外部位置输入，容易出现初始时刻的时间轴错位，导致仿真从一开始就存在偏差。我们的做法是从机制上规避这个问题：

• 先接数：启动 UDP 接收线程，等待外部系统发来第一个有效位置包，在此之前不触发 HIL。
• 再对齐：以接收到的第一个有效位置作为本次仿真的 initialPosition，完成初始时刻的锚定。
• 后启动：在 elapsed=0 的时刻，从该初始点推入并启动 PPS/HIL，随后进入正常的推点循环。

这样一套流程下来，每一次 HIL 仿真都有明确、可追溯的起始基准，有效避免了因启动时序不当带来的初始偏差，让整个测试链路从第一步就保持可控、可信。

四、600m/s 限制下的轨迹循环

Skydel标准版允许仿真的最大速度是600m/s，可覆盖日常汽车、航空应用测试，但在一些非连续轨迹之间跳变时可能会超出此限制。如何在600m/s的限制下，实现非闭环轨迹在终点运行完快速跳变回初始点？

Ian：我们的思路是：不把它当成一次高速跳跃，而是设计成一次 HIL 重启事件。 这样就从机制上绕开了速度超限的问题，而不是去硬碰硬地突破限制。具体实现方式如下：

• 定义一套基于 UDP 的控制协议：UDP 包的第一个字段是 header，整体帧结构为 <BddfB>，即：header + lat + lon + alt + footer。其中，header == 1 被约定为重启标记（RESTART_HEADER = 1），本质上是通过 UDP 传入一个特殊的控制字节 0x01。
• 正常推点逻辑：脚本收到常规位置包时，正常执行 pushLla 推点，驱动 HIL 仿真持续运行。
• 重启触发逻辑：当脚本收到 header == 0x01 的包时，不会将其当作坐标数据，也不会推进位置，而是识别为“当前轨迹已结束，需要重启 HIL”。
• 主流程响应：当前 HIL 循环返回 True，主流程依次执行 sim.stop( ) → 重新配置仿真 → 重新等待初始位置 → 重新启动 HIL，完成一次完整的重启闭环。

五、仿真速度超出 600m/s

在正常汽车仿真中，提示仿真速度超出 600m/s，产生错误是为什么？

Liam：HIL 模拟器输出的轨迹本身很稳定，但 Skydel 中显示的速度却可能出现较大偏差，甚至超出 600m/s 的限制。通常可以从以下两个方向排查：

1、初始位置和后续轨迹不连续

HIL 仿真采用基于初始点的轨迹外推算法。脚本中需要先向 Skydel 推送第一个初始点，再进入 while 循环推送后续轨迹点。如果修改了 HIL 模拟器中的轨迹，这两处必须同步更新，否则初始点与后续轨迹之间会产生跳变，导致瞬时速度异常。

2、位置数据的高度值发生变化

Skydel 地图右侧面板显示的是三维速度，会叠加高度变化的影响。如果 HIL 模拟器推送的位置数据中，高度值因某种原因在传输过程中发生偏移或跳变，即使水平轨迹正常，三维速度也会出现明显的偏差，甚至触发超限。