大家好，欢迎收看是德科技演讲视频。
我是是德科技汽车事业部的
战略规划师 Bill McKinley。
今天我们要讨论的是 测试复杂的高级驾驶辅助系统（ADAS）和
自动驾驶汽车（AV）系统会遇到哪些困难。
我们会展示如何通过 软件在环（SIL）和硬件在环（HIL）
在应用层的结合来测试和确认
设计是否实现了预期的性能，
同时帮助我们降低最终实际验证阶段的
测试成本。
先来了解一下背景。
在通往自动化的道路上，
人们对未来的自动驾驶汽车充满乐观，
但业界仍有许多挑战有待克服。
消费者的信心 和监管机构的批准至关重要，
因为自动驾驶与安全息息相关。
只有通过可靠的测试 才能验证系统是否安全，
是否能够发挥设计的性能。
这些极其复杂的系统需要使用新的测试方法。
新测试系统不仅需要具备极高的仿真能力、
实时 3D 引擎、
全动态视频（譬如正在播放的小视频中所示）、
动态传感器激励、
压力测试（如拥塞）能力，
还需要包括这里所展示的 第 1 日和第 2 日的使用场景，
以及现实世界中很难发生的
极端场景。
在我们看来，测试面临的挑战是
复杂的 ADAS 和 AV 系统
需要对虚拟环境进行大规模仿真。
我们需要测试成千上万个不同的场景，
才能确保系统安全。
最终的验证是在实际道路上完成，
这样的验证可能要行驶几百万公里 或者是几千个小时，
需要花费大量的金钱和时间。
我们相信，在全虚拟测试和 全真实测试这两个极端之间，
有一个中间环节或折衷方法
可以用来测试系统是否安全、 是否在按照设计的参数执行，
并且有助于最大限度降低 最终验证阶段产生的费用。
这个中间环节就是集成 HIL 和 SIL，
从而在系统设计的实际运行条件下 尽可能多地展开全面测试。
我们来看看如何才能做到这一点。
是德科技推出了自动驾驶仿真（ADE）平台。
从图中可以看到，它包含一个闭环系统。
场景创建位于左边，
其中包括被测车辆的物理模型，以及
在这个场景中完全渲染的 3D 模型
或者是我们在前面的短视频剪辑中
看到的环境以及通信模型。
它可能涵盖很多不同的技术， 例如 SILAR、V2X、ITS-G、DSRC、
紧急呼叫，等等。
渲染或 3D 建模主要是为了 激励汽车上的视觉系统
（如摄像头系统），但也会针对
车辆到其他车辆或者是 车辆到基础设施之间所采用的
不同通信技术
来构建雷达、激光雷达和通信模型。
在我们提到的视觉系统传感器和
通信模型传感器中，
有一部分采用的是双向通信。
信号被传送给被测器件上的传感器融合引擎，
进入可能包含人工智能的决策元器件，
最后进入车辆的引动装置，
从而影响车辆转向、
传动系统或制动系统。
这一切都通过环路回到场景中，
以便做出实时调整和测量，
从而确保整车和系统按要求运行。
下面，我们通过一个示例 来测试我们的方法，
这个示例就是紧急电子刹车灯预警
（EEBL）。
从图中可以看到，情况相当简单明了。
远车 A 位于左侧，
出于某种原因它正在执行紧急制动。
在这个示例中，被测车辆或（主车）的视线
被中间的一辆车遮挡。
由于远车 A 在这种情况下启用了 C-V2X，
因此它不仅会亮起刹车灯
（虽然测试车辆视线被挡可能看不见），
还会通过 PC5 侧链
传输此 EEBL 消息。
在理想情况下，如果一切正常，
主车（即被测车辆）会收到这条消息。
车辆的 HMI 会显示这条警告消息，
提醒驾驶员正在发生的状况
以及要准备采取行动。
我们就使用这个 EEBL 场景来测试
HIL 和 SIL 环境中的系统。
通过测试解决方案的体系框架， 我们可以看到这里的 HIL 和 SIL 路径。
我们在左侧进行了仿真，
然后实现了通信——消息传递。
这个示例中的 EEBL 消息来自模型。
因为有 HIL 路径和 SIL 路径， 所以我们可以看到所有元器件，
包括硬件元器件，也包括测试仪器，
例如 GNSS 仿真器和 使用 UXM 5G 完成的 C-V2X 仿真。
信道仿真器属于选配元器件，
用于添加信道损伤，以便进行
多普勒衰落等实际测试。
被测系统中包括 PC5 调制解调器、
GNSS 接收机，以及
被测器件中的软件元器件，
这些构成了一个完整的系统。
如果只看软件在环体系结构的话，
我们需要移除硬件元器件，
移除被测器件中的 GNSS 仿真器、
C-V2X 仿真器和调制解调器，
只留下软件部分。
我们看到了模型发来的消息，
这个示例中是 EEBL 消息。
我们采用了 Director app、 waveBEE touch 等是德科技软件，
稍后我会对它们详加介绍。
消息通过软件接口输入，
不会有硬件进入被测系统的
消息解析单元。
远车的识别和分类、
决策制定，以及之后的启动
都会导致被测器件上的 HMI
显示 EEBL 警告。
如果叠加使用是德科技的工具链，
我们会在左侧看到测试自动化平台。
在理想的情况下，测试会自动运行， 这不仅仅是为了方便操作，
更是为了让我们能够为事件加上时间戳，
以便记录事件，并进行 后期处理和故障诊断。
测试自动化平台启动执行。
我们有仿真元器件，
有称为 Creator 的映射应用软件。
在测试运行之前，我们用它创建了
前面提到的 EEBL 场景。
是的，该场景使用了 Director 应用软件，
它负责管理 GNSS 场景中的加载顺序，
在不同的使用场景下加载，
可能还会使用其他车辆。
接下来，我们在被测器件上播放仿真，
被测器件同样是软件元器件，不包含硬件。
这个软件界面可以向被测器件显示
消息、位置和时间信息。
它会处理相关信息，如果一切正常的话，
将会在 HMI 上显示 EEBL 警告， 就是这个三角形警告标识。
这些消息同样都带有时间戳，
也就是发送警告的时间以及
接收警告和显示三角形警告标识的时间。
接下来，我们可以测量时间差， 也就是时延。
我们来看一段小视频，
可以看到，左上角的测试自动化平台
在运行测试执行序列中的不同步骤。
左下角可以看到 Director 应用软件在加载场景，
启动“测试运行（test run）”。
测试概览位于右侧，
我们可以看到深色的主车（被测车辆）和远车，
远车周围有一个绿色圆圈，表示一切正常。
制动事件会在某个时间点发生，
我们会看到它变成红色。
主车显示屏上会显示三角形警告标识，
KPI（关键性能指标）会被监测并锁定。
从 SIL 测试所反映的 KPI 来看，
前面讲过，
远车的电子刹车灯预警
会在主车 HMI 上显示警告。
这个示例中，时间间隔是 42 ms。
这个速度很快，但请记住， 测试只涉及了软件，没有涉及硬件。
稍后我们可以比较硬件元器件，
了解它们带来的影响。
使用 SIL 环境能够发现和展示的其他 KPI
还包括“缺陷”指标。
我们希望尽快消除尽可能多的缺陷。
这是 SIL，它能够非常高效、
非常迅速地发现并消除缺陷。
被测器件中进行了大量的处理，
因此我们可以监控处理器的原始性能，
还可以在 SIL 环境中运行 未对齐的 API、队列溢出、
存储器消耗等
基础软件测试，
也可以运行压力测试和拥塞测试。
我们可以向被测器件发送成百上千条不同的消息，
以便进行测试，确认器件能否识别出 紧急程度和重要性都排在前面的 EEBL 消息
并采取适当的措施——
例如显示错误消息。
这些都是使用 SIL 可以反映的 KPI。
这些测试能够非常快速、有效地完成。
为了查看 HIL 体系结构，
我们在被测器件中添加了硬件元器件， 例如 GNSS 仿真器、
UXM 5G C-V2X 仿真、 PROPSIM 信道仿真器和
PC5 调制解调器。
我们在这里添加射频元器件。
同样，通过叠加是德科技工具链， 我们使用了与之前相同的元器件，
但现在还增加了 UXM 5G（即 C-V2X 仿真器）和 GNSS 仿真。
我们同步这两个仪器，
确保它们及时同步。
我们可以使用 PROPSIM 信道仿真器来添加损伤，
还可以使用不同的天线模型
来查看采用了不同天线的 被测对象的性能。
这些信息同样都会馈送到平台上，
只不过这一次不是通过软件界面， 而是通过射频电缆或者是
带有屏蔽的消声室内的空口传输， 但通常会采用有线方式。
我们得到了输入被测器件中的
消息传递和定位信息。
同样，我们要寻找 HMI 上显示的 EEBL 警告。
所有事件都带有时间戳，
这一信息会反馈给我们的软件，
软件会记录不同的 KPI 和感兴趣的参数。
再来看一个短视频，
我们会看到更多的信息呈现。
测试自动化平台位于左上角，
中间是我们的映射系统，
左下角可以看到接收的数据包。
右上角可以看到远车发送的消息，
右下角是我们的 Director 应用软件。
测试自动化平台会启动测试执行程序。
我们看到 Director 加载了 GNSS 场景。
在加载过程中，
器件的传输会停止， 因为它需要锁定 GNSS。
完成 GNSS 锁定后，我们会看到传输恢复。
我们再次看到接收的数据包。
接下来加载场景，
可以看到和之前相同的测试道路，
然后我们启动“测试运行”。
可以看到，黑色的主车即将启动。
稍后，我们会看到远车。
这里就是远车，它是绿色的， 表示一切正常。
两辆车都沿着测试道路加速到 25 mph。
在某个时点，远车执行紧急制动。
我们会看到绿色变成红色， 表示远车踩下了刹车，
我们希望能够在主车的 HMI 上 看到三角形标识出现。
是的，我们的确收到了这条消息，
车辆停下了。
所有参数都回传到自动化测试平台软件。
来看看这次 HIL 运行所反映的 KPI。
从远车发出 EEBL 警告到主车 HMI 显示警告， 中间经历了 900 ms。
与之前 SIL 运行所需的 42 ms 相比，
射频元器件导致了时延大幅增加。
经过多次运行，我们得到了不同的结果，
但总的来说，我们看到时延显著增加，
这是因为添加了射频硬件。
这是值得关注的一个点。
再来看看其他信息，例如 GNSS 车道位置。
来自远车的信息可能是车道位置
不需要被测车辆做出任何动作。
如果这是一条多车道公路，
制动事件发生在内侧车道
而被测车辆位于外侧车道，
我们需要注意制动事件，
但也可能不需要采取任何行动，
因此车道位置可能比较重要。
我们可以使用信道仿真器添加信道减损，
然后针对不同的衰落程度 查看数据包误码率，
从而确保被测车辆
能够在不同的信道条件下运行。
这里增加了一个硬件安全模块。
它可以连接被测器件，从而
确保通过不同的 HSM 来有效管理安全性。
前面讲过，信道仿真器可以集成
不同的天线型号和不同的天线方向图。
我们可以使用不同供应商的新设计
或具有不同设计的天线来进行性能测试。
最后，我们可以在 PC5 信道上
添加几百个额外的测试站。
CBL 测试可以在只有两三辆车的情况下
很好地完成，
但如果附近有几百台其他车辆
拥塞了 PC5 信道，
则会给器件形成压力。
我们希望看到它能够设法发挥设计的性能，
但它的附近还有几百台车辆都在进行传输。
我们希望在最终验证之前
可以通过集成硬件和软件在环测试
来查看设备是否发挥了设计的性能，
并且可以缩短实际测试
所需的时间。
如果您对我刚刚介绍的这些元器件和
我们的解决方案感兴趣，
欢迎随时访问 Keysight.com/find/C-V2X，
您会在上面找到有关系统不同元器件的全部信息。
下面进入实验室，
由我的同事 Gerry Fitzpatrick
（我们的 C-V2X 产品研发经理）
对系统做出概要介绍和快速演示。
因为是在实验室环境中，
所以背景中会有一点空调噪声，
对此我们深表歉意。
接下来的时间交给 Gerry。
好的，有请 Gerry。
C-V2X 设置（听不清）。
UXM 5G 运行 PC5 仿真和 ITS 堆栈仿真，
生成了多达 50 个 ITS 工作站
以及行人和车辆的 ITS 消息， 并通过被测器件播放这些消息。
这是设置用到的主要仪器。
在这个示例中，我们还使用 NXG 或 EXG
进行 GNSS 仿真，为 GPS、伽利略、
GLONASS、激光雷达等 提供移动 GNSS 场景。
我们处理的被测器件是
使用 C-V2X 线的商用芯片组。
连通性在这里显示。
PROPSIM FS8 八通道信道仿真器
使用 PC5 通道的输出充当输入，
应用了衰落、多普勒频移等信道特性，
还可以应用数字天线方向图来复制真正的天线。
这里的输出会提供给被测器件的输入接收机。
被测器件还会把数据传输给 UXM 5G，
因此我们可以通过 UXM 仪器上的器件回放
看到仿真的车辆。
这就是我们用到的全部设备。
现在，我们可以看到器件在进行传输，
可以看到在这里的频谱分析仪应用软件上
运行的邻道功率测量。
可以看到，这是一个 10 MHz 带宽的输出，
器件的频率也在发生周期性的变化，
在这种特殊情况下可能会传输 20 RB。
右边是 waveBEE touch 应用软件，
它会解码 ITS 统计信息 （在这个示例中是 US）。
在运行场景时，它会在地图上显示
主车和被测器件以及
它们的交互和消息的解码。
在这里，Keysight Director 软件 将 ITS 仿真加载到设置中。
我们可以在 waveBEE touch 应用软件上看到两辆车，
其中一辆是由测试设置仿真的远车，
另一辆则是这里的被测器件。
我们可以看到两辆车都在移动，
还可以看到主车的
射频参数传输。
我们可以在这里查看参数
乃至每条消息的 ITS 内容。
在这个示例中，我们看到了
报告纬度、经度、制动速度等条件的 基本安全信息。
此时此刻，两辆车都停了下来。
上方的远车踩下了刹车，
同一车道上的主车
也在后面 100 米处踩下了刹车。
驱动其自身与被测器件之间
PC5 射频连接的 UXM
的确具有基带衰落和信道仿真能力。
然而，在这个示例中，
我们已经将 UXM 的输出连接了 基于 PROPSIM FS8 射频的信道仿真器。
这是一个更强大、更灵活的解决方案，
它不仅可以仿真多个信道、MIMO 和多普勒，
还能进行天线表征。
它还可以表示天线的数字模型。
射频路径是 UXM 的输出， 它经过信道仿真器，
然后从这里进入被测器件。
信道仿真器不参与被测器件的传输，
该传输会直接进入 UXM。
在这种情况下，它不是一个衰落信道。
总而言之，
我希望我们已经证明了：
在应用层完成了测试就意味着
所有较低层都可以正常工作。
从物理层，再经过消息层和设施层
一直到应用层，
只要应用层测试成功的话，
所有其他层都会正常工作。
在应用层，其他一切都必须到位，
这一点至关重要。
由于路测成本非常高，而且难以重复，
因此减少这个阶段的工作 可以节省时间和成本。
我们还证明了可以在最终测试之前
进行全面测试。
正如刚刚所看到的那样， 在闭环设施中进行先进、逼真的仿真
有助于我们经济高效地
完成功能测试。
通过估测，SIL 测试可以快速
对整个体系结构完成 80% 以上的
测试和验证。
这些都可以在添加硬件之前完成。
添加硬件之后就到了 对射频条件和各种阈值的测试环节；
而在这一步之前，绝大部分的基本问题 都有望经由 SIL 测试得到解决。
毋庸置疑，我们还是需要 针对真实条件（包括信道损伤）
来添加射频硬件和元器件，以便
尽可能地按照实际情况进行测试。
我们知道，真实道路上的路测 仍然是最终验证手段。
但我们还是希望能够 减轻这个阶段的工作量，
借助实际路侧之前的测试步骤 来减少所需的时间和成本。
感谢大家的收看。
希望以上内容对您有帮助，
也期待是德科技能帮助您 克服未来的测试挑战。
谢谢大家。