SDV域控器日志追踪与解析技术 – DLT

从研发到测试SDV域控制器的调试日志如今，随着汽车软件的复杂性不断上升，调试或跟踪在不同内核或分区上运行的复杂软件极具挑战性，而在POSIX 系统或车辆上逐步调试复杂软件往往更具挑战性。那么，如何在SDV域控开发测试环境中将带有时间戳等信息的应用、中间件和内核日志同步合并到同一个日志流中，从而更好地服务于软件工厂或“黑灯”测试工厂，或者为云AI平台提供日志调试软件？ AUTOSAR推出的组件DLT的逻辑已经从诊断日志跟踪（D诊断Log和T竞赛）发展到更通用的开发日志跟踪（D开发Log和T竞赛）。

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

通常一些软件开发工程师有配置ECU的硬件调试环境，但其他工程师几乎没有配置“调试”ECU问题的环境。作为ECU软件的一个模块，DLT收集调试日志并跟踪ECU内部问题，可以加快故障排除和解决速度。过去，软件状态是通过CANoe或CANoe Option AMD/XCP集成不同的调试器或XCP来获得的，但它对于研发环境表现出广泛的多样性：

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

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

不同软件配置环境的许可证

不同的构建设置（例如软件工厂、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 1DLT应用场景和协议概述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 模块提供非详细日志数据

DLT模块过滤并生成DLT消息

DLT模块向通信总线发送DLT消息

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

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

图7 非详细模式日志

DLT协议是高层协议，与使用哪条总线无关。 AUTOSAR规范中的DLT协议目前定义了两个版本，v1和v2，并随着日志和跟踪协议规范中的每个AUTOSAR版本逐渐演变和标准化。例如，在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版本扩展头

该协议还定义了两种模式，即详细模式和非详细模式。两种模式都提供日志消息的严重级别：FATAL、ERROR、WARNING、INFO、DEBUG 和VERBOSE。两种模式的区别在于：

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

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

Part 2日志追踪“利器” 带有DLT功能的CANoe Option AMD/XCP通过收集日志信息、捕获ECU 的跟踪数据以确保状态流的正确更改、检测ECU 是否报告错误（例如配置错误或基础软件BSW 错误）以及验证ECU 生成的事件序列是否正确来验证ECU 的功能是否正确。针对上述需求，ECU需要集成相应的DLT软件模块：

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

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

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

图12 CANoe 支持DLT 和操作测量的A2L 集成

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

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

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

图14 CANoe中DLT配置流程

对于非详细模式消息的解析，插件会根据FIBEX 文件自动生成变量。 DLT 变量跟随每个以太网数据包帧，并直接解析并显示在跟踪窗口中。 DLT日志信息可以在图形窗口中以动态曲线的形式显示。

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

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

图16 CANoe解析Verbose模式日志

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

图17 使用CANoe发送DLT控制消息

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