一文详解AUTOSAR DLT模块

1.1 DLT的通用场景

• 应用或SW-C产生日志消息
• 日志消息发送到DLT模块
• DLT模块将日志消息发送到总线
• 外部DLT客户端记录日志消息

1.2 VFB追踪(tracing of VFB)

• RTE调用由DLT提供的宏，该宏可以调用DLT应用接口产生追踪消息（trace message）
• DLT模块发送跟踪消息到DLT通讯模块（黄色模块）
• DLT通讯模块转发跟踪消息到网络
• 外部客户端接收并存储跟踪消息

1.3 DLT运行配置

• 外部dlt客户端发送日志和跟踪等级变更到dlt模块
• dlt模块根据收到的变更消息改变自己的过滤器设置配置
• dlt模块通知应用新的日志等级

1.4 非冗余模式(non-verbose mode)

为了减少总线上的运输量，我们可以避免发送通讯总线上的变量元数据。相反，一个外部FIBEX文件保存如何解释有效负载的信息。外部Dlt客户机使用接收到的参数值合并和存储这些元数据。

• dlt模块以非冗余模式来传送dlt消息
• dlt模块过滤和产生dlt消息
• dlt模块发送dlt消息到通讯总线
• 外部dlt客户端获取外部FIBEX文件里的元信息
• 外部dlt客户存储合并的消息

DLT消息包含三个部分：标准头、扩展头、有效载荷。如下图

2.1 标准头

标准头有16个字节大小，分为6个部分。它们之间的名称和顺序如下图所示

Byte0：Header Type，这里用来配置DLT的可选项，比如带不带ECU ID、Session ID、时间戳等，DLT协议版本号、大端优先。具体如下图所示：

1为采用，0为不采用如果使用冗余模式，则UEH位必须为1

• Byte1：Message Counter,从0开始最大255，可以在一定程度上识别丢失的消息。
• Byte2-3：Length，这个字段指示整个DLT消息的长度，包括标准头、扩展头、有效载荷
• Byte4-7：ECU ID，可选的ECU ID用于识别哪个ECU发送了Dlt消息。因此，强烈建议ECU ID在车辆内是唯一的。
• Byte8-11：Session ID，可选的Session ID用于标识ECU中的日志或跟踪消息的来源。
• Byte12-15：Timestamp，对产生的DLT消息添加时间信息。

2.2 扩展头

扩展头字段是紧跟在标准头后面的，如果标准头中‘UEH’位位1，则表示该DLT消息有扩展头。扩展图的结构如下图所示：

-Byte0:Message Info,该字节的字段非常重要，设计到dlt消息的类型分类，用来区分是日志消息、跟踪消息、网络消息、控制消息。字段结构如下图所示：

VERB为1时表示有效载荷必须按冗余模式传输MSTP表示DLT的类型，一共分四种：日志消息、跟踪消息、网络消息、控制消息MTIN表示不同类型DLT消息各自的下级分类

• Byte1：Number of Arguments:参数数量表示一条Dlt消息的有效负载段中连续参数的数量。在冗余模式有效，非冗余模式此字段因为0x00
• Byte2-5：Application ID，应用程序ID是应用程序的缩写，它生成Dlt消息。
• Byte6-9：Context ID，Context ID是用户定义的ID，用于(逻辑上)对应用程序生成的Dlt消息进行分组。

2.3 有效载荷

2.3.1 非冗余模式非冗余模式下的的有效载荷就比较简单，只传输参数值(不需要任何关于它们的元信息)，以及其他属性(如参数名称或类型)，为了允许在接收到的Dlt消息中正确地分解所包含的参数值，将向有效负载添加专用的message ID。非冗余模式需要外部解析文件，用来解析Message ID通过消息ID和外部描述的组合，以下信息应该是可恢复的:类型信息：Type Length、Data Type、String Coding 、Variable Info 、Fixed Point考虑到MCU的处理能力，非冗余模式只传送dlt消息中的非静态数据，而每条dlt消息中的静态数据通过外部解析文件与Message ID进行关联，非冗余模式DLT消息结构如下：

2.3.1.1 非冗余模式dlt消息示例

通过下面的例子，我们来看下非静态数据是如何组装，传输和解析的。

假设下面这条日志消息将要传送给外部DLT客户端：

• 静态文本：“Temperature measurement”
• 8位uint:measurement_point = 1 (no unit)
• 32位浮点型：reading = 22.1 Kelvin
• 在源代码中的这个特定位置上有一个唯一的消息ID，用来表示这个日志消息调用。以下信息与这个消息ID相关联:
• 源码位置：source file “temp_meas.c”, line number 42
• 静态文本：“Temperature measurement”
• 值位8位无符号整数。变量名=“measurement_point” ， 单位 = “”
• 值位32位浮点型，变量名= “reading”，单位=“Kelvin”
• 所有的静态数据已经与message ID关联了，所以只用传输非静态数据，这条dlt消息的非静态数据如下所示：

根据消息ID，接收方可以重新组合此Dlt消息的所有静态数据(源代码中的位置、静态文本、变量名和单元)。非静态数据将被一致地打包传输。可以通过使用与消息ID相关联的信息进行解释。此外，参数的顺序与消息ID相关联。

2.3.1.2 非冗余模式被传输数据的解析格式外部文件像ASAM Fibex文件，保存着如何解析有效载荷的信息。应用程序或中间件的软件供应商应提供此描述文件。由于Dlt可以有多个日志或跟踪消息源(多个应用程序或诊断模块)，因此可以将提供的描述文件合并到给定ECU的一个文件中。每个用于描述非详细消息的Fibex描述文件只对应于一个ECU的日志或跟踪消息。这是因为每个ECU的消息id是唯一的。此外，ECU的软件版本号必须由描述文件提供。原则上，每个日志或跟踪消息都相当于某些网络协议中已知的PDU。在这里，日志或跟踪消息的描述应该等同于Fibex指定的CAN-Frame。来自Extended Header的信息被另外放入FRAME-TYPE xml元素中的xml元素中。非静态数据由PDU和SIGNAL xml元素描述。从用户的角度来看，日志或跟踪消息有几个参数。这些参数可以是静态文本或非静态变量。只传输非静态变量的数据。为了用所有参数重新组合整个消息，一个FRAME xml元素应该包含一些空的PDU xml元素，这些元素用静态文本表示参数。此文本应置于PDU xml元素的DESC xml元素中。

• 一条日志或追踪消息必须是一个Fibex XML元素框架表示
• 消息ID必须是XML元素的ID属性
• 下面的示例显示了FIBEX XML中示例Dlt消息的描述。

2.3.2 冗余模式

DLT的冗余模式相对于非冗余模式，显而易见，传递的数据更加全面完整，如果ECU的内存和带宽都够，建议使用冗余模式传输DLT消息。

冗余模式下的DLT消息结构如下图所示：

数据负载包含变量的值(即应用程序或中间件的调试信息)，它将在通信总线上传输。除了变量值本身之外，还需要提供变量的大小和类型等信息。该信息包含在Type Info字段中。-Type Info：32位，表示元数据信息。

从上图可以看出，Type Info主要描述“Data payload”类型信息。

• Type Length（TYLE）：Type Length指定标准数据类型的长度。比如：规定BOOL型为8位，SINT和UINT为8位、16位、32位、64位、128位，FLOA型为16位、32位、64位、128位。
• Variable Info(VARI): 如果设置了变量信息(VARI)，则可以添加变量的名称和单位。两者都包含一个长度信息字段和一个带有文本(名称或单元)的字段。长度字段包含关联的名称或单元字段的字符数。只在某些数据类型中添加单元信息。
• Fixed Point(FIXP):如果使用定点值，则应设置定点(FIXP)位。比数据字段表示一个固定点变量的物理值。为了解释不动点变量，必须计算这个变量的逻辑值。逻辑值由不动点变量的物理值、量化值q和偏移量o来计算。逻辑值Lv和物理值Pv之间的关系是Lv=Pv*q + O不动点必须是整型数据
• String Coding(SCOD): String Coding 仅对String 类型(STRG)的字符串数据进行编码。所有其他字符串，如参数名称、单元和描述都是用8位ASCII格式编码的。
• Bool:如果数据是布尔型，1就代表True，0代表False。
• Signed and Unsigned:整型和无符号整型数据。该位设置时，代表Data payload里的数据是整型和无符号整型数据。
• FLOA：浮点型，该位置1时，代表Data payload里的数据时浮点型数据
• String(STRG):字符串，该位置1时，代表Data payload里的数据是字符串
• Array(ARAY): 该位置1时，代表Data payload里的数据是数组。
• Struct(STRU):该位置1时，代表Data payload里的数据是数组。
• Raw(RAWD):该位置1时，代表Data payload里的数据是原始数据。
• Trace Info(TRAI):该位置1时，跟踪信息(如模块名/函数)应在参数中传递。在数据有效负载的起始，一个16位无符号整数应指定跟踪数据字符串的长度，以字节为单位，包括终止字符。介绍了那么多，来个示例解释下自然数据类型参数是如何表示的吧下面这个示例展示了如何在冗余模式VARI置1的情况下，将一个8位无符号整型数据组装起来。Type Info是描述数据的32位字段。在这个例子中，它定义了变量类型(无符号整数)、它的长度(8位)和描述变量名称和单位的variable Info (VARI)的存在。Variable Info后面跟着两个16位无符号整数，描述变量的Name和Unit的长度。后面跟着两个以空结束的字符串，它们描述了Name和Unit。最后，变量值紧随其后。Data字段的长度是8位。

介绍了那么多，来个示例解释下自然数据类型参数是如何表示的吧下面这个示例展示了如何在冗余模式VARI置1的情况下，将一个8位无符号整型数据组装起来。Type Info是描述数据的32位字段。在这个例子中，它定义了变量类型(无符号整数)、它的长度(8位)和描述变量名称和单位的variable Info (VARI)的存在。Variable Info后面跟着两个16位无符号整数，描述变量的Name和Unit的长度。后面跟着两个以空结束的字符串，它们描述了Name和Unit。最后，变量值紧随其后。Data字段的长度是8位。

Type Info字段各个位之间的组合表

下表显示了根据使用的变量类型的强制(标记x)和可选(标记o)设置:

为了识别日志或跟踪消息的来源，需要在Dlt消息中添加一些在源代码中找到位置的信息。因此，Dlt消息中的前两个参数应为:

源文件的名称(字符串)代码行(无符号整数)日志或跟踪消息的第一个参数应该是一个字符串参数，其中字段“Name”(在Variable Info中)包含字符串“source_file”，数据字段包含源文件的URL。

日志或跟踪消息的第二个参数应该是UINT参数(32位)，其中字段“Name”(在Variable Info中)包含字符串“line_number”，数据字段包含发送日志或跟踪消息的源文件中的行号。

2.4 DLT服务(命令）

以下章节将介绍已定义的Dlt命令，包括唯一标识(Service ID)、格式和所需参数。下面的表格表示DLT支持的服务命令：

• DLT 数据消息传输时序图(Transmission of Dlt Data Message)

• 设置日志登记过滤器(Set LogLevel Filter)

• 缓存溢出(Buffer Overflow)

来源：汽车ECU开发