远程调试在 Linux 车机中的应用（远程调用linux命令）

导读

在软件开发过程中，调试是必不可少的环节，嵌入式操作系统的调试与桌面操作系统的调试相比有很大差别，嵌入式系统的可视化调试能力比桌面操作系统要弱一点。对于导航这种业务场景比较复杂的程序开发，可视化调试环境能让我们业务场景开发事半功倍，也能快速定位导航业务与车机中其他模块交互出现的问题，提高开发过程中的调试效率。

远程调试是真机调试中最便捷的一种，开发者只需借用在 PC 端强大的调试器就能完成业务场景的调试。

背景

Thrift 是一种接口描述语言和二进制通讯协议，它被用来定义和创建跨语言的服务，是一种 RPC（远程过程调用）通信框架，由 Facebook 为“大规模跨语言服务开发”。在车机系统中，各模块之间也可以使用 Thrift 通信框架进行通信。导航作为一个单独的为进程提供服务的模块，只提供导航相关的业务以及地图渲染的能力，导航的 HMI 界面是车机系统中统一的操作界面，系统 HMI 界面与导航之间的交互接口则是通过已经定义好的接口描述语言（IDL），使用自动化工具生成本地可调用的接口，然后使用 Thrift 框架传输完成系统 HMI 与导航之间的通信。

调试手段

为了开发过程中调试方便，我们在 PC 上做了一套模拟器，能在 PC 上进行地图渲染。还实现了一套在 PC 上使用的系统 HMI 模拟命令发送工具，模拟工具是作为客户端连接导航提供的服务，这样能在 PC 端模拟发送命令，帮助导航简单业务的开发，但这种方式存在着以下弊端：

• 模拟命令工具，只能模拟简单的业务场景，有多个交互的场景无法模拟。
• 无法操作地图 HMI，也看不到 HMI 界面显示以及过程中的反馈。
• 无法滚动地图，后面接了 Win32 上面的鼠标事件，能用鼠标实现滚动，但这种方式与车机中滚动流程不一致。
• PC 端无法使用车机中的设备，如导航过程中没有导航音，无法使用 USB 等。
• PC 端拿不到车机中的数据，比如车身数据、GPS 信号等。

调试方案优化

针对当前调试手段存在的以上问题。我们对调试方案进行了优化，我们可以借助车机中系统 HMI 来与导航进行交互。实现了使用车机环境中的信号对 PC 端导航业务场景进行调试。主要有以下几点功能：

1.PC 端模拟器接收车机发来的信号

在该项目中，导航的相关业务都是作为服务端向车机中其他模块提供服务，在车机系统中，系统 HMI 连接导航服务的地址是固定的，我们在车机中开发了一个代理--Sandwich，主要作用是启动导航服务，这个导航服务并不实现真正的导航业务，而是启动了一个空服务，让车机中其他模块能成功建立连接，同时 Sandwich 作为客户端连接 PC 端模拟器提供的导航服务，PC 端的导航服务真正实现导航业务，Sandwich 负责接收车机发送过来的业务请求，并将请求转发给 PC 端模拟器，这样 PC 端模拟器就能接收到车机中的信号，收到的业务请求并做处理再将处理结果通过 Thrift 反馈到车机端。

这个流程我们打通了车机中信号发送到 PC 端模拟器，并可以将处理完的数据反馈给车机端。

2.PC 端模拟器向车机发送信号

导航也需要连接车机中其他模块提供的服务，如，获取车身数据、获取 GPS 定位信号，将导航语音数据发送到车机语音播放模块等。

PC 端模拟器需要作为客户端来连接车机中的服务，真正连接的是车机中 Sandwich 提供的服务，Sandwich 作为客户端连接车机中其他模块的服务，比如 Sandwich 连接 Sound 模块，GPS 模块，CarData 模块等。PC 端模拟器需要使用车机设备播放导航音，需要将播放内容发送给 Sandwich，Sandwich 收到播放内容后，再发送给车机中的 Sound 模块，导航音就能播放了。PC 端连接车机中其他模块的工作原理也是一样。

3. 将 PC 端模拟器中显示的地图投射到车机端显示

实现了以上两步，一个使用车机信号调试 PC 端导航程序的环境基本完成了。已经能实现车机信号与 PC 进行双向接收，但是此时导航的渲染能力还是停留在 PC 端，车机中还只是显示了一个系统 HMI 界面，无法看到导航地图展现的效果，这样就会带来一个问题，一些需要强依赖地图的操作可能就无法精准操作，比如点击地图上某个 POI 等。此时需要将 PC 端的展现同步到车机侧。

要实现这一目的，一般我们有两种方法：

• 车机与 PC 同步渲染

车机中的导航正常运行，当导航接收到系统模块业务请求时，先是车机导航进行处理，处理完毕后将信号转发到 PC 端处理，这种方案两端导航业务逻辑并行运行，复杂的业务场景下，两端会同时跟车机进行交互，此时可能会产生互斥，会有两端逻辑不同步的场景，达不到预期效果。

• 将车机中渲染的数据投射到车机端

在这里我们可以将 PC 上程序每渲染一帧地图则将结果传到车机端，由车机端 Sandwich 负责接收，当 Sandwich 接收到一帧地图像素数据后，负责将此帧数据渲染到车机屏幕上，此时车机中呈现的效果跟 PC 端一致。在该项目中我们采用了这一方案，这种方案中，真正的导航业务逻辑是来自 PC 端，车机中只是一个转发过程，所以不会存在第一种方案中的问题。

但在某些特定的环境下，导航描画会很频繁，发送给车机的数据也会很多，频繁的数据发送可能会带来一定的性能开销，表现上可能会出现延迟。这里可以使用降低图像质量来减少图像数据，例如，可以使用 16 位或者 8 位 BMP 来传输，还可以压缩传输，这样 1920*720 分辨率图像传输大小能控制在 30-50k 左右。

小结

基于车机系统中 Thrift 通信框架，实现的这套远程调试方案，实质是在车机中使用 Sandwich 程序接管车机系统中与导航有交互的全部接口处理，通过 RPC 通信转发，实现了使用真实车机信号调试导航的目的。有了这套调试环境，我们甚至可以直接在真车上边路测边调试，跟以前的路测拿 Log 回来分析、重现相比，整个调试过程，简单，便捷，直观。大大提高了开发效率。

基于 RPC 通信的特性，我们还可以对调试方案再进一步优化，可以加入多客户端调试功能，使用同一台车机环境，不同的模块负责人可以同时进行复杂业务场景的联合调试。