【DLT学习笔记2】-- 什么是DLT？(Diagnostic Log and Trace)

　　[企业]嘉兴主营业务：浙江嘉兴到全国各地货运物流详细地址：地址1、平湖市七星路钟埭工业区；2、嘉善县台升大道万玮嘉兴嘉善物流园；、海盐县天玺海盐物流园；[企业]大连主营业务：大连物流公司直达专线/瓦房店配货站/大连行李托运，长途搬家公司，大连金州开发区配货站、大连旅顺口配货站，长兴岛物流公司，普兰店物流公司，复州城物流设备运输，庄河搬家公司，开发区货运公司。详细地址：全国各地回程车运输，人车互联，有3米-各种类型货车，总部：江苏常州，全国各大中型城市有分流点。他表示，除了留给家人的必要花费，剩下的会留给母校北大和新东方慈善基金会，用于支持农村地区孩子的教育发展，以后可能还会把其中一部分留给西湖大学。

　　韵达：网络一般，价格低，速度较慢。大连金州区物流货运中心，马桥子街道长途搬家公司，街道物流配货站，二十里堡街道物流设备运输，拥政街道物流。

　　详细地址：全国各地回程车运输，人车互联，有3米-各种类型货车，总部：江苏常州，全国各大中型城市有分流点。公司致力于打造中国最大、最专业的企业，拥有庞大的服务网点，高覆盖、高效率的服务获得多家公司和机构的认可。

　　详细地址：全国各地回程车运输，人车互联，有3米-各种类型货车，总部：江苏常州，全国各大中型城市有分流点。公司致力于打造中国最大、最专业的企业，拥有庞大的服务网点，高覆盖、高效率的服务获得多家公司和机构的认可。

重点推荐:[诚信建设 ]土右文明网 其他推荐公司[企业]广州主营业务：全国各地大量回程车调度网络信息平台米-米整车大件运输危险品运输、价格优惠快速到货网全国定位跟踪系统，全国网点请拨打总机为你服务：13631319638(电话微信同步)低价运输、公司另有专业调车人员、可配全国各地整车零担大件运输危险品运输调度车辆。详细地址：全国各地回程车运输，人车互联，有3米-各种类型货车，总部：江苏常州，全国各大中型城市有分流点。

DLTGENIVI项目下的log软件工程

DLT包括：DLT daemon DTL viewer两个子工程。

DLT daemon运行在ECU上，DTLviewer运行在调试PC上。

github地址：dlt-viewer

一、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协议介绍

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必须是<FRAME>XML元素的ID属性

下面的示例显示了FIBEX XML中示例Dlt消息的描述。

<fx:FRAME ID="ID_1"> <ho:SHORT-NAME>Dlt Message with ID_1</ho:SHORT-NAME> <fx:BYTE-LENGTH>1</fx:BYTE-LENGTH> <fx:FRAME-TYPE>OTHER</fx:FRAME-TYPE> <fx:PDU-INSTANCES> <fx:PDU-INSTANCE ID="P_1_0"> <fx:PDU-REF ID-REF="PDU_1_0"/> <fx:SEQUENCE-NUMBER>0</fx:SEQUENCE-NUMBER> </fx:PDU-INSTANCE> <fx:PDU-INSTANCE ID="P_1_1"> <fx:PDU-REF ID-REF="PDU_1_1"/> <fx:SEQUENCE-NUMBER>1</fx:SEQUENCE-NUMBER> </fx:PDU-INSTANCE> <fx:PDU-INSTANCE ID="P_1_2"> <fx:PDU-REF ID-REF="PDU_1_2"/> <fx:SEQUENCE-NUMBER>2</fx:SEQUENCE-NUMBER> </fx:PDU-INSTANCE> </fx:PDU-INSTANCES> <fx:MANUFACTURER-EXTENSION> <MESSAGE_TYPE>DLT_TYPE_LOG</MESSAGE_TYPE> <MESSAGE_INFO>DLT_LOG_DEBUG</MESSAGE_INFO> <APPLICATIONID>APPI</APPLICATIONID> <CONTEXTID>CONI</CONTEXTID> <MESSAGE_SOURCE_FILE>demo.c</MESSAGE_SOURCE_FILE> <MESSAGE_LINE_NUMBER>72</MESSAGE_LINE_NUMBER> </fx:MANUFACTURER-EXTENSION> </fx:FRAME> 

<!--=============== 1. Parameter ==================-->

<fx:PDU ID="PDU_1_0"> <ho:SHORT-NAME></ho:SHORT-NAME> <ho:DESC>Temperature measurement</ho:DESC> <fx:BYTE-LENGTH>0</fx:BYTE-LENGTH> <fx:PDU-TYPE>OTHER</fx:PDU-TYPE> </fx:PDU>

<!--=============== 2. Parameter ==================--> 

<fx:PDU ID="PDU_1_1"> <ho:SHORT-NAME>measurement_point</ho:SHORT-NAME> <fx:BYTE-LENGTH>1</fx:BYTE-LENGTH> <fx:PDU-TYPE>OTHER</fx:PDU-TYPE> <fx:SIGNAL-INSTANCES> <fx:SIGNAL-INSTANCE ID="S_1_0"> <fx:SEQUENCE-NUMBER>0</fx:SEQUENCE-NUMBER> <fx:SIGNAL-REF ID-REF="S_UINT8"/> </fx:SIGNAL-INSTANCE> </fx:SIGNAL-INSTANCES> </fx:PDU> 

<!--=============== 3. Parameter ==================--> 

<fx:PDU ID="PDU_1_2"> <ho:SHORT-NAME>reading</ho:SHORT-NAME> <fx:BYTE-LENGTH>1</fx:BYTE-LENGTH> <fx:PDU-TYPE>OTHER</fx:PDU-TYPE> <fx:SIGNAL-INSTANCES> <fx:SIGNAL-INSTANCE ID="S_1_0"> <fx:SEQUENCE-NUMBER>0</fx:SEQUENCE-NUMBER> <fx:SIGNAL-REF ID-REF="FLOA32"/> </fx:SIGNAL-INSTANCE> </fx:SIGNAL-INSTANCES> </fx:PDU>

1

2

3

4

5

6

7

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位。

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命令可以通过接收相应的Dlt控制消息和/或通过单独的C api触发

三、时序图

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

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

缓存溢出(Buffer Overflow)

四、术语解析

术语名称 解释

SW-C Software Component的缩写，即软件组件，它是组成应用软件的基本单元

VFB VFB(Virtual Function Bus)，也就是虚拟功能总线，而RTE是它的具体实现

RTE 运行时环境（RTE）是AUTOSAR ECU体系结构的核心。RTE是AUTOSAR中VFB的接口实现，特定于每个ECU生成的。RTE提供基础的通信服务，支持软件构件间和软件构件到基础软件模块的通信，并提供AUTOSAR软件组件访问基本软件模块（包括OS和通信服务）的服务。

Metadata 元数据是关于数据的数据(参考3)

Log and trace message 一条日志和追踪消息里包含所有描述软件中的日志和事件追踪的数据和选项。它们由消息头和有效载荷组成

Dlt User DLT用户是指产生Dlt消息的源头。它们可以是应用，RTE或者软件模块

Log message 日志消息包含调试信息，如状态变化或值变化。

Trace Message 跟踪消息包含通过VFB传递的信息

FIBEX 现场总线交换格式是一种通用的XML基础描述格式。

ECU ID ECU ID是一个ECU的名称，由4个8位ASCII字符(如ABS0、COMB)组成

Session 会话是日志或跟踪消息源的逻辑实体。如果一个SW-C /应用程序被实例化多次，则使用具有全局唯一会话ID的每个实例的一个会话。

Session ID 会话ID是日志或跟踪会话的标识号

Application ID “应用ID”是SW-C / Application的缩写。它标识日志和跟踪消息产生的SW-C /应用程序。

Context ID 上下文ID是用户自定义ID，四个8位ASCII字符组成上下文ID。用于对swc /应用程序生成的日志和跟踪消息进行分组。具有以下使用规则：1. 每个应用ID可以拥有几个上下文ID 2.上下文ID由应用ID进行分组 3. 一个应用ID里的上下文ID必须是唯一的 4. 使用元组“应用程序ID”和“上下文ID”标识日志和跟踪消息的源

Message ID 消息ID是标识信息的ID，信息由消息本身传输。消息ID唯一地标识日志或跟踪消息。它可以用来标识消息的源(在源代码中)，也可以用来描述消息的有效负载。消息ID是在开发或配置时静态固定的。

Log level 日志级别定义了日志消息的严重级别的分类。

Trace status 跟踪状态提供了是否应该发送跟踪消息的信息

Log Channel 一种用于传输Dlt消息的物理通信总线

External client 外部客户端是使用Dlt模块控制、监视和存储ecu提供的日志/跟踪信息的工具。

PDU Protocol Data Unit，PDU包含SDU和PCI，PCI包含源地址和目标地址信息，SDU是数据信息

五、参考

1.AUTOSAR虚拟功能总线-VFB

2.DLT协议(AutoSAR官方)

3.元数据

————————————————

版权声明：本文为CSDN博主「黄水生」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/jackhh1/article/details/122740788