【DLT學(xué)習筆記2】-- 什么是DLT？(Diagnostic Log and Trace)

DLTGENIVI項目下的log軟件工程

automotive-dlt: /home/pfefferz/dlt-daemon/include/dlt/dlt_user.h Source File

DLT包括：DLT daemon DTL viewer兩個(gè)子工程。

DLT daemon運行在ECU上，DTLviewer運行在調試PC上。

github地址：dlt-viewer

一、DLT使用場(chǎng)景

1.1 DLT的通用場(chǎng)景

應用或SW-C產(chǎn)生日志消息

日志消息發(fā)送到DLT模塊

DLT模塊將日志消息發(fā)送到總線(xiàn)

外部DLT客戶(hù)端記錄日志消息

1.2 VFB追蹤(tracing of VFB)

RTE調用由DLT提供的宏，該宏可以調用DLT應用接口產(chǎn)生追蹤消息（trace message）

DLT模塊發(fā)送跟蹤消息到DLT通訊模塊（黃色模塊）

DLT通訊模塊轉發(fā)跟蹤消息到網(wǎng)絡(luò )

外部客戶(hù)端接收并存儲跟蹤消息

1.3 DLT運行配置

外部dlt客戶(hù)端發(fā)送日志和跟蹤等級變更到dlt模塊

dlt模塊根據收到的變更消息改變自己的過(guò)濾器設置配置

dlt模塊通知應用新的日志等級

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

為了減少總線(xiàn)上的運輸量，我們可以避免發(fā)送通訊總線(xiàn)上的變量元數據。

相反，一個(gè)外部FIBEX文件保存如何解釋有效負載的信息。

外部Dlt客戶(hù)機使用接收到的參數值合并和存儲這些元數據。

dlt模塊以非冗余模式來(lái)傳送dlt消息

dlt模塊過(guò)濾和產(chǎn)生dlt消息

dlt模塊發(fā)送dlt消息到通訊總線(xiàn)

外部dlt客戶(hù)端獲取外部FIBEX文件里的元信息

外部dlt客戶(hù)存儲合并的消息

二、DLT協(xié)議介紹

DLT消息包含三個(gè)部分：標準頭、擴展頭、有效載荷。如下圖

2.1 標準頭

標準頭有16個(gè)字節大小，分為6個(gè)部分。它們之間的名稱(chēng)和順序如下圖所示

Byte0：Header Type，這里用來(lái)配置DLT的可選項，比如帶不帶ECU ID、Session ID、時(shí)間戳等，DLT協(xié)議版本號、大端優(yōu)先。具體如下圖所示：

1為采用，0為不采用

如果使用冗余模式，則UEH位必須為1

Byte1：Message Counter,從0開(kāi)始最大255，可以在一定程度上識別丟失的消息。

Byte2-3：Length，這個(gè)字段指示整個(gè)DLT消息的長(cháng)度，包括標準頭、擴展頭、有效載荷

Byte4-7：ECU ID，可選的ECU ID用于識別哪個(gè)ECU發(fā)送了Dlt消息。因此，強烈建議ECU ID在車(chē)輛內是唯一的。

Byte8-11：Session ID，可選的Session ID用于標識ECU中的日志或跟蹤消息的來(lái)源。

Byte12-15：Timestamp，對產(chǎn)生的DLT消息添加時(shí)間信息。

2.2 擴展頭

擴展頭字段是緊跟在標準頭后面的，如果標準頭中‘UEH’位位1，則表示該DLT消息有擴展頭。擴展圖的結構如下圖所示：

-Byte0:Message Info,該字節的字段非常重要，設計到dlt消息的類(lèi)型分類(lèi)，用來(lái)區分是日志消息、跟蹤消息、網(wǎng)絡(luò )消息、控制消息。字段結構如下圖所示：

VERB為1時(shí)表示有效載荷必須按冗余模式傳輸

MSTP表示DLT的類(lèi)型，一共分四種：日志消息、跟蹤消息、網(wǎng)絡(luò )消息、控制消息

MTIN表示不同類(lèi)型DLT消息各自的下級分類(lèi)

一圖勝千言

Byte1：Number of Arguments:參數數量表示一條Dlt消息的有效負載段中連續參數的數量。在冗余模式有效，非冗余模式此字段因為0x00

Byte2-5：Application ID，應用程序ID是應用程序的縮寫(xiě)，它生成Dlt消息。

Byte6-9：Context ID，Context ID是用戶(hù)定義的ID，用于(邏輯上)對應用程序生成的Dlt消息進(jìn)行分組。

2.3 有效載荷

2.3.1 非冗余模式

非冗余模式下的的有效載荷就比較簡(jiǎn)單，只傳輸參數值(不需要任何關(guān)于它們的元信息)，以及其他屬性(如參數名稱(chēng)或類(lèi)型)，為了允許在接收到的Dlt消息中正確地分解所包含的參數值，將向有效負載添加專(zhuān)用的message ID。非冗余模式需要外部解析文件，用來(lái)解析Message ID通過(guò)消息ID和外部描述的組合，以下信息應該是可恢復的:

類(lèi)型信息：Type Length、Data Type、String Coding 、Variable Info 、Fixed Point

考慮到MCU的處理能力，非冗余模式只傳送dlt消息中的非靜態(tài)數據，而每條dlt消息中的靜態(tài)數據通過(guò)外部解析文件與Message ID進(jìn)行關(guān)聯(lián)，非冗余模式DLT消息結構如下：

2.3.1.1 非冗余模式dlt消息示例

通過(guò)下面的例子，我們來(lái)看下非靜態(tài)數據是如何組裝，傳輸和解析的。

假設下面這條日志消息將要傳送給外部DLT客戶(hù)端：

靜態(tài)文本：“Temperature measurement”

8位uint:measurement_point = 1 (no unit)

32位浮點(diǎn)型：reading = 22.1 Kelvin

在源代碼中的這個(gè)特定位置上有一個(gè)唯一的消息ID，用來(lái)表示這個(gè)日志消息調用。以下信息與這個(gè)消息ID相關(guān)聯(lián):

源碼位置：source file “temp_meas.c”, line number 42

靜態(tài)文本：“Temperature measurement”

值位8位無(wú)符號整數。變量名=“measurement_point” ， 單位 = “”

值位32位浮點(diǎn)型，變量名= “reading”，單位=“Kelvin”

所有的靜態(tài)數據已經(jīng)與message ID關(guān)聯(lián)了，所以只用傳輸非靜態(tài)數據，

這條dlt消息的非靜態(tài)數據如下所示：

根據消息ID，接收方可以重新組合此Dlt消息的所有靜態(tài)數據(源代碼中的位置、靜態(tài)文本、變量名和單元)。非靜態(tài)數據將被一致地打包傳輸?？梢酝ㄟ^(guò)使用與消息ID相關(guān)聯(lián)的信息進(jìn)行解釋。此外，參數的順序與消息ID相關(guān)聯(lián)。

2.3.1.2 非冗余模式被傳輸數據的解析格式

外部文件像ASAM Fibex文件，保存著(zhù)如何解析有效載荷的信息。應用程序或中間件的軟件供應商應提供此描述文件。由于Dlt可以有多個(gè)日志或跟蹤消息源(多個(gè)應用程序或診斷模塊)，因此可以將提供的描述文件合并到給定ECU的一個(gè)文件中。

每個(gè)用于描述非詳細消息的Fibex描述文件只對應于一個(gè)ECU的日志或跟蹤消息。這是因為每個(gè)ECU的消息id是唯一的。此外，ECU的軟件版本號必須由描述文件提供。

原則上，每個(gè)日志或跟蹤消息都相當于某些網(wǎng)絡(luò )協(xié)議中已知的PDU。在這里，日志或跟蹤消息的描述應該等同于Fibex指定的CAN-Frame。來(lái)自Extended Header的信息被另外放入FRAME-TYPE xml元素中的xml元素中。非靜態(tài)數據由PDU和SIGNAL xml元素描述。

從用戶(hù)的角度來(lái)看，日志或跟蹤消息有幾個(gè)參數。這些參數可以是靜態(tài)文本或非靜態(tài)變量。只傳輸非靜態(tài)變量的數據。為了用所有參數重新組合整個(gè)消息，一個(gè)FRAME xml元素應該包含一些空的PDU xml元素，這些元素用靜態(tài)文本表示參數。此文本應置于PDU xml元素的DESC xml元素中。

一條日志或追蹤消息必須是一個(gè)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>

2.3.2 冗余模式

DLT的冗余模式相對于非冗余模式，顯而易見(jiàn)，傳遞的數據更加全面完整，

如果ECU的內存和帶寬都夠，建議使用冗余模式傳輸DLT消息。

冗余模式下的DLT消息結構如下圖所示：

數據負載包含變量的值(即應用程序或中間件的調試信息)，它將在通信總線(xiàn)上傳輸。除了變量值本身之外，還需要提供變量的大小和類(lèi)型等信息。該信息包含在Type Info字段中。

-Type Info：32位，表示元數據信息。

從上圖可以看出，Type Info主要描述“Data payload”類(lèi)型信息。

Type Length（TYLE）：Type Length指定標準數據類(lèi)型的長(cháng)度。比如：規定BOOL型為8位，SINT和UINT為8位、16位、32位、64位、128位，FLOA型為16位、32位、64位、128位。

Variable Info(VARI): 如果設置了變量信息(VARI)，則可以添加變量的名稱(chēng)和單位。兩者都包含一個(gè)長(cháng)度信息字段和一個(gè)帶有文本(名稱(chēng)或單元)的字段。長(cháng)度字段包含關(guān)聯(lián)的名稱(chēng)或單元字段的字符數。只在某些數據類(lèi)型中添加單元信息。

Fixed Point(FIXP):如果使用定點(diǎn)值，則應設置定點(diǎn)(FIXP)位。比數據字段表示一個(gè)固定點(diǎn)變量的物理值。為了解釋不動(dòng)點(diǎn)變量，必須計算這個(gè)變量的邏輯值。邏輯值由不動(dòng)點(diǎn)變量的物理值、量化值q和偏移量o來(lái)計算。

邏輯值Lv和物理值Pv之間的關(guān)系是Lv=Pv*q + O

不動(dòng)點(diǎn)必須是整型數據

String Coding(SCOD): String Coding 僅對String 類(lèi)型(STRG)的字符串數據進(jìn)行編碼。所有其他字符串，如參數名稱(chēng)、單元和描述都是用8位ASCII格式編碼的。

Bool:如果數據是布爾型，1就代表True，0代表False。

Signed and Unsigned:整型和無(wú)符號整型數據。該位設置時(shí)，代表Data payload里的數據是整型和無(wú)符號整型數據。

FLOA：浮點(diǎn)型，該位置1時(shí)，代表Data payload里的數據時(shí)浮點(diǎn)型數據

String(STRG):字符串，該位置1時(shí)，代表Data payload里的數據是字符串

Array(ARAY): 該位置1時(shí)，代表Data payload里的數據是數組。

Struct(STRU):該位置1時(shí)，代表Data payload里的數據是數組。

Raw(RAWD):該位置1時(shí)，代表Data payload里的數據是原始數據。

Trace Info(TRAI):該位置1時(shí)，跟蹤信息(如模塊名/函數)應在參數中傳遞。在數據有效負載的起始，一個(gè)16位無(wú)符號整數應指定跟蹤數據字符串的長(cháng)度，以字節為單位，包括終止字符。

介紹了那么多，來(lái)個(gè)示例解釋下自然數據類(lèi)型參數是如何表示的吧下面這個(gè)示例展示了如何在冗余模式VARI置1的情況下，將一個(gè)8位無(wú)符號整型數據組裝起來(lái)。

Type Info是描述數據的32位字段。

在這個(gè)例子中，它定義了變量類(lèi)型(無(wú)符號整數)、

它的長(cháng)度(8位)和描述變量名稱(chēng)和單位的variable Info (VARI)的存在。

Variable Info后面跟著(zhù)兩個(gè)16位無(wú)符號整數，描述變量的Name和Unit的長(cháng)度。

后面跟著(zhù)兩個(gè)以空結束的字符串，它們描述了Name和Unit。最后，變量值緊隨其后。

Data字段的長(cháng)度是8位。

Type Info字段各個(gè)位之間的組合表

下表顯示了根據使用的變量類(lèi)型的強制(標記x)和可選(標記o)設置:

為了識別日志或跟蹤消息的來(lái)源，需要在Dlt消息中添加一些在源代碼中找到位置的信息。

因此，Dlt消息中的前兩個(gè)參數應為:

源文件的名稱(chēng)(字符串)

代碼行(無(wú)符號整數)

日志或跟蹤消息的第一個(gè)參數應該是一個(gè)字符串參數，其中字段“Name”(在Variable Info中)包含字符串“source_file”，數據字段包含源文件的URL。

日志或跟蹤消息的第二個(gè)參數應該是UINT參數(32位)，其中字段“Name”(在Variable Info中)包含字符串“l(fā)ine_number”，數據字段包含發(fā)送日志或跟蹤消息的源文件中的行號。

2.4 DLT服務(wù)(命令）

以下章節將介紹已定義的Dlt命令，包括唯一標識(Service ID)、格式和所需參數。

下面的表格表示DLT支持的服務(wù)命令：

建議定義的Dlt命令可以通過(guò)接收相應的Dlt控制消息和/或通過(guò)單獨的C api觸發(fā)

三、時(shí)序圖

DLT 數據消息傳輸時(shí)序圖(Transmission of Dlt Data Message)

設置日志登記過(guò)濾器(Set LogLevel Filter)

緩存溢出(Buffer Overflow)

四、術(shù)語(yǔ)解析

術(shù)語(yǔ)名稱(chēng) 解釋

SW-C Software Component的縮寫(xiě)，即軟件組件，它是組成應用軟件的基本單元

VFB VFB(Virtual Function Bus)，也就是虛擬功能總線(xiàn)，而RTE是它的具體實(shí)現

RTE 運行時(shí)環(huán)境（RTE）是AUTOSAR ECU體系結構的核心。RTE是AUTOSAR中VFB的接口實(shí)現，特定于每個(gè)ECU生成的。RTE提供基礎的通信服務(wù)，支持軟件構件間和軟件構件到基礎軟件模塊的通信，并提供AUTOSAR軟件組件訪(fǎng)問(wèn)基本軟件模塊（包括OS和通信服務(wù)）的服務(wù)。

Metadata 元數據是關(guān)于數據的數據(參考3)

Log and trace message 一條日志和追蹤消息里包含所有描述軟件中的日志和事件追蹤的數據和選項。它們由消息頭和有效載荷組成

Dlt User DLT用戶(hù)是指產(chǎn)生Dlt消息的源頭。它們可以是應用，RTE或者軟件模塊

Log message 日志消息包含調試信息，如狀態(tài)變化或值變化。

Trace Message 跟蹤消息包含通過(guò)VFB傳遞的信息

FIBEX 現場(chǎng)總線(xiàn)交換格式是一種通用的XML基礎描述格式。

ECU ID ECU ID是一個(gè)ECU的名稱(chēng)，由4個(gè)8位ASCII字符(如ABS0、COMB)組成

Session 會(huì )話(huà)是日志或跟蹤消息源的邏輯實(shí)體。如果一個(gè)SW-C /應用程序被實(shí)例化多次，則使用具有全局唯一會(huì )話(huà)ID的每個(gè)實(shí)例的一個(gè)會(huì )話(huà)。

Session ID 會(huì )話(huà)ID是日志或跟蹤會(huì )話(huà)的標識號

Application ID “應用ID”是SW-C / Application的縮寫(xiě)。它標識日志和跟蹤消息產(chǎn)生的SW-C /應用程序。

Context ID 上下文ID是用戶(hù)自定義ID，四個(gè)8位ASCII字符組成上下文ID。用于對swc /應用程序生成的日志和跟蹤消息進(jìn)行分組。具有以下使用規則：1. 每個(gè)應用ID可以擁有幾個(gè)上下文ID 2.上下文ID由應用ID進(jìn)行分組 3. 一個(gè)應用ID里的上下文ID必須是唯一的 4. 使用元組“應用程序ID”和“上下文ID”標識日志和跟蹤消息的源

Message ID 消息ID是標識信息的ID，信息由消息本身傳輸。消息ID唯一地標識日志或跟蹤消息。它可以用來(lái)標識消息的源(在源代碼中)，也可以用來(lái)描述消息的有效負載。消息ID是在開(kāi)發(fā)或配置時(shí)靜態(tài)固定的。

Log level 日志級別定義了日志消息的嚴重級別的分類(lèi)。

Trace status 跟蹤狀態(tài)提供了是否應該發(fā)送跟蹤消息的信息

Log Channel 一種用于傳輸Dlt消息的物理通信總線(xiàn)

External client 外部客戶(hù)端是使用Dlt模塊控制、監視和存儲ecu提供的日志/跟蹤信息的工具。

PDU Protocol Data Unit，PDU包含SDU和PCI，PCI包含源地址和目標地址信息，SDU是數據信息

五、參考

1.AUTOSAR虛擬功能總線(xiàn)-VFB

2.DLT協(xié)議(AutoSAR官方)

3.元數據

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

版權聲明：本文為CSDN博主「黃水生」的原創(chuàng )文章，遵循CC 4.0 BY-SA版權協(xié)議，轉載請附上原文出處鏈接及本聲明。

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