从研发到测试SDV域控制器的调试日志

从研发到测试SDV域控制器的调试日志

在汽车软件复杂度不断攀升的今天，对不同核或分区上运行的复杂软件进行调试或追踪极具挑战性，并且在POSIX系统或车辆上的复杂软件进行分步调试往往更具挑战。所以，如何在SDV域控制器开发测试环境中，将应用程序、中间件和内核日志与时间戳等信息同步结合汇聚到同一个日志流，以便更好服务软件工厂或“黑灯”测试工厂，亦或为云端AI平台提供日志调试软件？AUTOSAR推出的组件DLT，其逻辑已从诊断日志追踪（DiagnosticLog andTrace）演变为更加宽泛意义的开发日志追踪（DevelopmentLog andTrace）。

图1 面向SDV平台集成DLT调试日志

通常部分软件开发工程师有配置ECU的硬件调试环境，但其它工程师几乎没有配置“Debug”ECU问题的环境。DLT作为ECU软件的模块汇聚调试日志并追踪ECU内部问题，可以加速问题排查和解决。过往通过CANoe或CANoe Option AMD/XCP集成不同调试器或XCP获取软件状态，但是面向研发环境表现出广泛的多样性：

不同品牌调试器和调试器扩展模块

ECU平台多样性和电路连接多样性

不同软件配置环境的License

不同的构建设置（例如，软件工厂、HIL Farm）

图2 CANoe Option AMD/XCP集成不同调试器或XCP获取日志

通过统一的DLT作为调试手段增加软件测试的灵活性和效果，允许根据严重性级别（例如“致命”、“错误”或“信息”）对调试信息进行过滤。该过滤器可以通过外部日志工具发送的DLT控制消息在运行时进行修改。还可以直接通知应用程序新的过滤级别，以便仅针对所选的严重性级别生成调试信息，运行时将消息分配到另一个通信总线上，或将修改后的DLT配置存储为NV存储（如果硬件支持的话）。开发与测试工程师使用CANoe Option AMD/XCP在支持CCP/XCP的同时，也可直接用其实现DLT数据进行在线采集或离线分析。

图3 CANoe Option AMD/XCP直接获取XCP或DLT日志

Part 1

DLT应用场景和协议概述

DLT是一个AUTOSAR基础软件模块。虽然DLT协议与总线无关，但建议使用高带宽总线，如以太网。尽管如此，DLT协议并不局限于以太网的使用，使得在没有调试器的情况下调试ECU成为可能，并允许用户在运行时进行配置。

使用DLT进行常规日志记录：

应用程序/软件组件向DLT模块提供日志消息

日志消息要么被过滤，要么由DLT模块创建DLT消息（取决于日志级别）

DLT模块将DLT消息发送到通信总线

外部客户端接收并存储DLT消息

图4 AUTOSAR DLT常规日志记录

中间件VFB日志：

中间件调用DLT模块提供的接口函数，该函数调用DLT API生成追踪消息

DLT模块将追踪消息发送到DLT通信模块接口

DLT通信模块将追踪消息转发到网络

外部客户端接收并存储追踪消息

图5 中间件通过DLT记录日志

运行时配置DLT日志：

外部客户端设置日志和追踪级别，并将更改发送至DLT模块

通过DLT控制消息将更改发送到DLT模块

DLT模块相应地调整其过滤设置的配置

DLT模块通知应用程序新的日志级别

图6 运行时配置DLT日志

非冗长模式（Non-verbose）传输日志：使用外部解析文件的方式来高效解析有效数据载荷，从而避免在通信总线上发送关于变量的元素数据，达到节省总线通信开销的目的。外部DLT客户端将这些元数据与接收到的参数值合并存储。

应用程序/软件组件向DLT模块提供Non-verbose的日志数据

DLT模块过滤并生成DLT消息

DLT模块将DLT消息发送到通信总线

外部客户端从外部文件中获取元信息

合并的信息由外部客户端存储

图7 Non-verbose模式日志

DLT协议是一种高层协议，与具体使用哪种总线无关。AUTOSAR规范中的DLT协议目前定义了v1和v2两个版本，并在Log and Trace Protocol Specification中随AUTOSAR各个Release逐步演进和规范化，例如在AUTOSAR FO R19-11及后续R24-11（PRS）中对相关能力进行了完善和扩展。在AUTOSAR发布的早期阶段（约2010年前后），Vector在ECU软件与工具链中对日志与追踪机制进行了大量工程实践，用于开发调试和问题分析，并随着AUTOSAR 规范的演进持续支持和实现DLT协议，最终发展到当前广泛使用的v2版本。

DLT v1版本包头简单、报文开销小，因而在带宽受限或资源受限的ECU上能够实现低成本部署。

图8 DLT v1版本标准报头

图9 DLT v1版本扩展报头

DLT v2支持可变长度ID（动态ID）、高精度时间戳、分段传输（即报文超过单帧长度可切分并重组），更适合大载荷的场景。

图10 DLT v2版本标准报头

图11 DLT v2版本扩展报头

协议中还定义了两种模式，分别是Verbose和Non-verbose模式，两种模式在日志消息的严重性等级均提供：FATAL、ERROR、WARNING、INFO、DEBUG和VERBOSE。两种模式的区别为：

Verbose模式：发送包含所有参数/文本的完整消息，便于阅读与分析，但会消耗更多带宽。

Non-verbose模式：可发送更紧凑的消息（例如仅发送参数或ID），消息结构可以通过FIBEX或ARXML数据库文件解析，适合在带宽受限场景降低开销。

Part 2

日志追踪“利器”

– 带有DLT功能的CANoe Option AMD/XCP

通过收集日志信息来验证ECU的正确功能，捕获ECU的追踪数据确保状态流的正确变化，检测ECU是否报告了错误（例如，配置错误或基础软件BSW错误），验证从ECU生成的事件顺序是否正确。针对如上需求，ECU需要集成对应的DLT软件模块：

基于XCP的DLT集成：现有XCP协议栈上只需将DLT API调用添加到定义事件中，配置中启用相关功能则DET和DEM事件将自动传输，DEM事件支持按需过滤。

基于AUTOSAR的DLT集成：作为XCP DLT的替代方案，允许API更改DLT的日志级别，满足整车厂集成DLT的功能要求。根据AUTOSAR日志定义控制日志级别（致命、错误、警告、调试、信息、详细），将所有日志和追踪聚集到集中式AUTOSAR服务组件中，基于软件的时间信息、多核和分区日志。如AUTOSAR AP中ara::log提供每个阶段的日志信息API，日志通过配置发送到特定日志接收器，若需要可通过DLT实现远程调试。

CANoe Option AMD/XCP支持在开发与调试过程中加载A2L文件到CANoe中，并支持DaVinci工具在配置协议栈时可额外配置测量代码，直接生成测试代码用于CPU负载、任务执行等信息用于后续自动化验证。

图12 CANoe支持A2L集成用于DLT与运行测量

CANoe支持在线和离线分析DLT数据，可通过总线接口卡连接真实ECU获取调试日志，对虚拟机如WSL中的vECU可通过集成SIL Kit来获取调试日志。

图13 真实ECU或虚拟ECU可通过CANoe实现DLT调试日志

CANoe支持Non-verbose和Verbose两种模式，支持一键生成对应FIBEX中变量到CANoe工程，也可在配置工程节点后导入对应变量。

图14 CANoe中DLT配置流程

对于Non-verbose模式消息的解析，插件根据FIBEX文件自动生成的变量，DLT变量紧随每帧Ethernet Packet，直接被解析并显示在Trace窗口，并可在Graphics窗口中以动态曲线方式显示DLT日志信息。

图15 CANoe解析Non-verbose模式日志

对于Verbose模式消息的解析，具体的Payload会直接被解析成结构体，并在Trace窗口显示。

图16 CANoe解析Verbose模式日志

同时CANoe支持发送DLT Control Message，如Set Log Level命令。

图17 使用CANoe发送DLT Control Message

Part 3

总结和展望

SDV发展迭代必然需要更丰富的调试手段。AUTOSAR DLT作为调试器之外的另一种获取调试日志的方式，将更好服务车辆开发各环节。CANoe Option AMD/XCP配合DLT功能提供更加全面的功能，在获取CCP/XCP数据日志信息的同时，助力工程师更好地通过DLT分析和调试ECU。当然在车辆生产时，DLT应当关闭以满足网络安全需求。DLT技术也在迭代，CANoe也将更好支持“软调试”技术，进一步提升便利性。