Log and Trace Protocol Specification (`LogAndTraceProtocol`)¶

属性	值
平台	FO
类别	PRS — 协议规范（Protocol Specification）
UID	787
规范版本	R26-11

本地文件¶

规范 PDF: F:\Work\Standards\01_Sources\FO_PRS_LogAndTraceProtocol_787\AUTOSAR_FO_PRS_LogAndTraceProtocol.pdf
ARXML 模型: F:\Work\Standards\01_Sources\FO_PRS_LogAndTraceProtocol_787\AUTOSAR_FO_PRS_LogAndTraceProtocol.arxml
纯文本全文: F:\Work\Standards\01_Sources\FO_PRS_LogAndTraceProtocol_787\zzgen\FO_PRS_LogAndTraceProtocol.complete.txt

文档简介¶

This protocol specification defines the format, message sequences and semantics of the AUTOSAR Protocol Dlt.

The protocol allows sending Diagnostic, Log and Trace information onto the communications bus.

Therefore, the Dlt module collects debug information from applications or other software modules, adds metadata to the debug information, and sends it to the communications bus.

In addition, the Dlt Protocol allows filtering of debug information depending on the severity level, e.g. "fatal", "error" or "information". This filter can be modified during runtime via Dlt Control Messages sent by an external Logging Tool to the Dlt module.

It is also possible to directly inform applications about the new filter level to only generate debug information especially for this selected severity level, assign messages to another communications bus at runtime, or to store the modified Dlt configuration non-volatile (if supported by hardware).

While the version "1" of the protocol still keeps its validity (look up , Log and Trace Protocol Specification from R20-11), version "2" of the protocol, as specified in this document, increases flexibility for the required use cases and introduces new features, which can't be anymore added to the previous protocol version in a backward-compatible way. These are:

Tags for message filtering and Privacy Flags.
Improved Timestamp with a nanosecond resolution and a possible time span of thousands of years. In connection with that, the ServiceID / command 0x24 / "SyncTimeStamp" is no more needed and got removed.
Long IDs for ECU, Application and Context names are now already supported in the header section of the Log and Trace message.
The same applies for a possible source file name and line number information.

The used "flag-length-value" approach leaves room for future extensions of the protocol without breaking the compatibility with current features.

Additionally, strings in the Log and Trace message do not need any more a null-termination, since the length value for a string is already enough.

模块依赖¶

To transmit Dlt messages, the applications need to know whether to send the Dlt messages using the verbose or non-verbose mode.

In addition, the applications may offer the possibility to get informed about a filter setting change. For this purpose, the applications should register themselves at the Dlt module.

章节详细内容¶

1. 简介 and 概述¶

原文标题：Introduction and overview

This protocol specification defines the format, message sequences and semantics of the AUTOSAR Protocol Dlt.

The protocol allows sending Diagnostic, Log and Trace information onto the communications bus.

Therefore, the Dlt module collects debug information from applications or other software modules, adds metadata to the debug information, and sends it to the communications bus.

In addition, the Dlt Protocol allows filtering of debug information depending on the severity level, e.g. "fatal", "error" or "information". This filter can be modified during runtime via Dlt Control Messages sent by an external Logging Tool to the Dlt module.

It is also possible to directly inform applications about the new filter level to only generate debug information especially for this selected severity level, assign messages to another communications bus at runtime, or to store the modified Dlt configuration non-volatile (if supported by hardware).

2. 协议目的 and 目标¶

原文标题：Protocol purpose and objectives

The Dlt protocol can be used at the ECU development phase to log and store debug information externally on a logging device.

3. Applicability of the 协议¶

原文标题：Applicability of the protocol

It is intended to use the Dlt Protocol at the development phase of an ECU. It is assumed to use an external logging and tracing tool to store the debug information generated by the ECU.

This logging and tracing tool is also needed to modify the filter setting at runtime if wanted, or to store the current Dlt configuration of the ECU persistently.

4. Safety and security considerations¶

It is highly recommended to deactivate the Dlt functionality after the development phase is over. In particular, the Injection-Feature should be deactivated in any case!

The activation and deactivation of the Dlt functionality should be done using a security mechanism.

5. 约束与假设¶

原文标题：Constraints and assumptions

The Dlt Protocol is designed to work "connectionless". This means that no external communication or other stimulation is needed to use the Dlt protocol. See also ;

Although there is no need to connect an external logging tool, it makes sense having one, which stores and interprets the received debug messages. This device can also be used to generate Dlt Control Messages to influence the ECU, like modifying the filter setting (i.e. change the severity level of the debug information).

6. 限制¶

原文标题：Limitations

The available (free) bandwidth of the communications bus should be taken into consideration to not influence the regular communication too much.

7. Dependencies¶

8. Dependencies to the Application Layer¶

To transmit Dlt messages, the applications need to know whether to send the Dlt messages using the verbose or non-verbose mode.

In addition, the applications may offer the possibility to get informed about a filter setting change. For this purpose, the applications should register themselves at the Dlt module.

9. Use Cases¶

This chapter describes the use cases which can be realized by an environment of an ECU which implements the Dlt Protocol.

Although the Dlt protocol is bus agnostic, it is recommended to use communications busses with higher bandwidth like Ethernet. Nonetheless it is not limited to it.

10. Use Case 通用 logging with Dlt¶

原文标题：Use Case general logging with Dlt

(1) An application/SW-C is providing a log message to the Dlt module.

(2) The log message is either filtered or a Dlt message is created by the Dlt module which implements the Dlt Protocol. (Depending on log level.)

(3) The Dlt module sends the Dlt message to the communications bus.

(4) An external client receives and stores the Dlt message.

11. Use Case 追踪 of VFB¶

原文标题：Use Case tracing of VFB

(1) Middleware calls the macro provided by Dlt module which calls the Dlt API generating the trace message.

(2) The Dlt module which implements the Dlt Protocol sends the trace message to the implemented Dlt communication module interface.

(3) The Dlt communication module forwards the trace message to the network.

(4) An external client receives and stores the trace messages.

12. Use Case runtime 配置 of Dlt¶

原文标题：Use Case runtime configuration of Dlt

(1) An external client sets the log and trace level and sends the changes to the Dlt module which implements the Dlt protocol.

(2) Via a Dlt control message the change is sent to the Dlt module which implements the Dlt protocol.

(3) The Dlt module adapts its configuration of filter settings accordingly.

(4) The Dlt module informs the application about the new log level.

13. Use Case non-verbose 模式¶

原文标题：Use Case non-verbose mode

To reduce the amount of traffic on the bus, it can be avoided to send meta data about variables on the communications bus.

Instead, an external file holds the information how the payload shall be interpreted. The external Dlt client merges and stores these meta data with the received parameter values.

(1) An application/SW-C is providing non-verbose logging data to the Dlt module.

(2) The Dlt module filters and generates the Dlt message.

(3) The Dlt module sends the Dlt message to the communications bus.

(4) An external client fetches meta information from an external file.

(5) The merged information is stored by an external client.

14. 相关文档¶

原文标题：Related documentation

15. 输入文档与相关标准规范¶

原文标题：Input documents & related standards and norms

16. 需求 Traceability¶

原文标题：Requirements Traceability

Requirement	Description	Satisfied by

17. 术语与缩略语定义¶

原文标题：Definition of terms and acronyms

The glossary below includes acronyms, abbreviations and definitions relevant to this document that are not included in .

18. 缩略语¶

原文标题：Acronyms and abbreviations

Abbreviation / Acronym	Description
APID	Application ID
CNTI	Content information
CTID	Context ID
Dlt	Diagnostic Log and Trace
HTYP	Header Type
LEN	Overall Message Length
MCNT	Message Counter
MSID	Message ID
MSIN	Message Info
MSTP	Message Type
MTIN	Message Type Info
NOAR	Number of Arguments
TMSP	Timestamp
VERB	Verbose
VERS	Version Number
WACID	With App- and Context ID
WEID	With ECU ID
WPVL	With Privacy Level
WSFLN	With Source File Name and Line Number
WSID	With Session ID
WSGM	With Segmentation
WTGS	With Tags

19. 定义 of terms¶

原文标题：Definition of terms

Term	Description
Log and trace message	A log and trace message contains all data and options to describe a log and trace event in a software. The log and trace message consists of a header and payload.
Dlt User	A Dlt User represents the source of a generated Dlt message. Possible users are Applications, RTE or other software modules.
Log Message	A Log Message contains debug information like state changes or value changes.
Trace Message	A Trace messages contains information, which has passed via the VFB.
ECU ID	The ECU ID is the name of an ECU, composed by 8-bit ASCII characters (e.g. "ABS0" or "InstrumentCluster").
Session	A session is the logical entity of the source of log or trace messages. If a SW-C/application is instantiated several times, a session for each instance with a globally unique session ID is used.
Session ID	The Session ID is the identification number of a log or trace session.
Application ID	Application ID is the name (or the abbreviation of it) of a SW-C/application. It identifies the SW-C/application that log and trace message originates.

20. 协议规范¶

原文标题：Protocol specification

21. Message format¶

For both, debug data and control information, the same Dlt message format is used.

It consists of a "Base Header", an optional "Extension Header", and a Payload segment.

Base Header	Extension Header (optional)	Payload

Upstream requirements: , ⌈ The "Base Header" and the "Extension Header" shall always use the network byte order. ⌋

Note: "Network Byte Order" equals "Big Endian".

22. Base Header¶

Upstream requirements: , ⌈ The Base Header shall always consist of the following fields in the following order:

Byte 0 - 3: HTYP2 (Header Type for protocol version "2")
Byte 4: MCNT (Message Counter)
Byte 5 - 6: LEN (Message Length) ⌋

The following fields of the Base Header are only contained if certain conditions are met. The conditions are defined later in this sub-chapter.

Upstream requirements: , ⌈ In addition, the Base Header shall also conditionally consist of the following fields in the following order:

MSIN (Message Info) : length=1 byte
NOAR (Number of arguments) : length=1 byte
TMSP2 (Timestamp version "2") : length=9 bytes
MSID (Message ID) : length=4 bytes

Each element shall be added after the last existing element in the Base Header. There shall be no gap in between. ⌋

Note: Since the above elements are conditional, an absolute byte position can't be given here, as they may shift due to the activation/deactivation of those conditional fields (see above).

23. Header 类型¶

原文标题：Header Type

The "Header Type"-field for protocol version '2' (HTYP2) contains general information about the Log and Trace message.

Except for the three bits "Version Number" information, all other flags are used to indicate conditional or optional later content in this Log and Trace message.

In this context here,

"conditional" means, the required usage is specified in this document.
"optional" means, the usage is application specific.

Upstream requirements: ⌈ The Header Type - field (HTYP2) shall be the first element of any Log and Trace message. ⌋

Upstream requirements: ⌈ The size of the Header Type - field (HTYP2) shall be 32 bit. ⌋

Upstream requirements: ⌈ The Header Type (HTYP2) shall contain the following information and shall be encoded in the following way:

Bit 0 - 1: CNTI (Content Information)
Bit 2: WEID (With ECU ID)
Bit 3: WACID (With App- and Context ID)
Bit 4: WSID (With Session ID)
Bit 5-7: VERS (Version Number)
Bit 8: WSFLN (With Source File Name and Line Number)
Bit 9: WTGS (With Tags)
Bit 10: WPVL (With Privacy Level)
Bit 11: WSGM (With Segmentation)
Bit 12 - 31: reserved (reserved by AUTOSAR for future usage) ⌋

24. Message Counter¶

The Message Counter (MCNT) counts Dlt messages transmitted to a selected Log Channel. Each Log Channel needs to maintain its own Message Counter. On the receiver side, the Message Counter value can be evaluated to identify lost messages to a certain level.

Upstream requirements: ⌈ The Message Counter is an unsigned 8-bit (0-255) integer. ⌋

Upstream requirements: ⌈ After initialization of the Dlt module, the Message Counter (MCNT) shall be set to '0'. ⌋

Upstream requirements: ⌈ The Message Counter shall be incremented by one for each Dlt message that is transmitted to assigned LogChannel. ⌋

Upstream requirements: ⌈ If the Message Counter reaches 255, the counter shall wrap around and start with the value '0' at the next Log and Trace message to be transmitted. ⌋

25. Message Length¶

Upstream requirements: ⌈ The Message Length (LEN) field for the complete Log and Trace message in the Base Header shall be a 16-bit unsigned integer. ⌋

Upstream requirements: ⌈ The Message Length (LEN) field in the Base Header shall be set to the overall length in bytes of the complete Log and Trace message, which is the sum of:

the length in bytes of the Base Header itself,
the length in bytes of the optional Extension Header and
the length in bytes of the optional Payload. ⌋

This Message Length (LEN) contains the length of a single simple LogAndTraceMessage and is independent from any segmentation functionality, as specified later on (compare chapter "Optional Message Segmentation"). Therefore, the upper limit of a single simple LogAndTraceMessage is either limited by the underlying communication protocol / -medium or by the max.value of the LEN field (16bit): 65535.

26. Conditional "Message Info"¶

Like specified above (refer ), the MSIN (Message Info) is added to the Base Header in case the Log and Trace message is a Data Message in Verbose Mode or a Control Message, otherwise the MSIN is not part of the Base Header.

Upstream requirements: ⌈ The Message Info field (MSIN) shall contain the following information in the following order:

Bit 0: reserved (reserved)
Bit 1-3: MSTP (Message Type)
Bit 4-7: MTIN (Message Type Info) ⌋

Message Info (MSIN)	<	<	<	<	<	<	<
Name	MTIN	<	<	<	MSTP	<	<	reserved
Bit offset	7	6	5	4	3	2	1	0
Byte	0	<	<	<	<	<	<	<

Upstream requirements: ⌈ The Message Type (MSTP) shall be a 3-bit unsigned integer. ⌋

Upstream requirements: ⌈ The Message Type (MSTP) shall have one of the following values:

0x0: DLT_TYPE_LOG (Dlt Log Message)
0x1: DLT_TYPE_APP_TRACE (Dlt Trace Message)
0x2: DLT_TYPE_NW_TRACE (Dlt Network Message)
0x3: DLT_TYPE_CONTROL (Dlt Control Message)
0x4 - 0x7: Reserved ⌋

Upstream requirements: ⌈ The Message Type Info field (MTIN) shall be a 4-bit unsigned integer. ⌋

Upstream requirements: ⌈ If the MSTP field is set to 0x0 (i.e.

27. Conditional "Number of Arguments"¶

Like specified above (refer ), the NOAR (Number of Arguments) is added to the Base Header in case the Log and Trace message is a Data Message in Verbose Mode or a Control Message. Otherwise the NOAR is not part or the Base Header.

Number of Arguments represents the number of consecutive parameters or the number of consecutive control commands in the payload segment of one Dlt message.

Upstream requirements: ⌈ The Number of Arguments field (NOAR) shall be an 8-bit unsigned integer. ⌋

Upstream requirements: , ⌈ The Number of Arguments field (NOAR) shall contain the number of provided arguments or control commands within the payload. ⌋

28. Conditional "ns-Timestamp"¶

Like specified above (refer ), the TMSP2 (ns-Timestamp) is added to the Base Header in case the Log and Trace message is a Data (Verbose Mode or Non-Verbose Mode), otherwise the TMSP2 is not part of the Base Header.

The conditional Timestamp is used to add timing information on when a Dlt message has been generated.

Format of ns-Timestamp Upstream requirements: ⌈ The length for the ns-timestamp shall be 9 byte:

The lower 4 byte / uint32 shall be the nanoseconds part of the timestamp.
The upper 5 byte / 40 bits shall be the second's part of the timestamp.

The time shall start from 1970-01-01, 00:00:00,00000, i.e. this timestamp shall be derived from an absolute / global time that has a Synchronized Time Base. ⌋

Note:

0 to 1.099.511.627.776s ~ 34.841 years

0 to 999999999ns ;

Invalid value in nanoseconds: to ;

Bit 30 and 31 are reserved in this case.

Format of ns-Timestamp for ECUs without a synchronized time base Upstream requirements: ⌈ If a specific ECU can't provide an absolute time starting from 1970-01-01, 00:00:00,00000 time, the bit 31 in the nanoseconds field shall be set and the time shall start from the ECU startup. ⌋

29. Conditional "Message ID"¶

Like specified above (refer ), the MSID (Message ID) is added to the Base Header in case the Log and Trace message is a Data Message in Non-Verbose Mode, otherwise the MSID is not part of the Base Header.

Upstream requirements: ⌈ The Message ID shall be a 32-bit unsigned integer. ⌋

Note: More details can be found in sub-chapter "Payload in Non-Verbose Mode".

30. Extension Header¶

The Extension Header contains additional data that facilitates the interpretation of the pure DLT content. Thus, further properties of the DLT content, such as the exact origin, are transmitted here.

In case one of the following bits of the "HTYP2"-field in the Base Header are set to '1', additional information is transmitted which are defined in the Extension Header format:

Bit 2: WEID (With ECU ID)
Bit 3: WACID (With App- and Context ID)
Bit 4: WSID (With Session ID)
Bit 8: WSFLN (With Source File Name and Line Number)
Bit 9: WTGS (With Tags)
Bit 10: WPVL (With Privacy Level)
Bit 11: WSGM (With Segmentation)

The basic design principles for the Extension Header are:

All of its fields are optional and therefore the complete Extension Header is optional.
Whether a specific field needs to be added to the Extension Header is indicated by the above mentioned bits ("flags") from the "HTYP2"-field in the Base Header.
The order of the fields in the Extension Header is defined by the order of the corresponding flags in the "HTYP2"-field from the Base Header.
A field consist of a length specifier and the value itself (there are a few exceptions to this).

31. Optional ECU-ID¶

The optional ECU ID is used to identify which ECU has sent a Log and Trace message. Therefore, it is highly recommended that the ECU ID is unique within the vehicle.

Possibility to send the ECU ID Upstream requirements: ⌈ If the bit 2 (WEID, "With ECU ID") in the "HTYP2"-field of the Base Header is set, the DLT-message shall contain the length byte and the string value for the ECU ID, added to the Extension Header. ⌋

Length information Upstream requirements: ⌈ The length byte shall be the first byte in the ECU ID field and shall count the number of characters used for the ECU ID. ⌋

ECU ID format Upstream requirements: ⌈ The coding of the ECU ID shall contain only ASCII characters without a special terminating item like the NUL-character (\0) at the end. ⌋

Note: The string end is only given by the Length information for the ECU-ID.

32. Optional Application ID and Context ID¶

The Application ID is an abbreviation of the application which generates the Dlt message.

The Context ID is a user defined ID to (logically) group Dlt messages generated by an application.

Possibility to send the Application ID and Context ID Upstream requirements: ⌈ If the bit 3 (WACID, "With App- and Context ID") in the "HTYP2"-field of the Base Header is set, the DLT-message shall contain the length bytes and the string values for the Application ID and the Context ID, added to the Extension Header. ⌋

Sequence of Application ID and Context ID Upstream requirements: ⌈ If the Application ID and the Context ID are added to the Extension Header, the Application ID field shall be the first and the Context ID field shall be the second. ⌋

Length information of Application ID and Context ID Upstream requirements: ⌈ For each of the two fields (Application ID and Context ID) the length byte shall be the first byte in that ID field and shall count the number of characters used for that ID. ⌋

33. Optional Session ID¶

The optional Session ID is used to identify the source of a log or trace message within an ECU.

Upstream requirements: ⌈ If the bit 4 (WSID, "With Session ID") in the "HTYP2"-field of the Base Header is set, the DLT-message shall contain the Session ID, added to the Extension Header. ⌋

Note: Since the Session ID is defined to be of 32-bit length, this Session ID field in the Extension Header does NOT have an extra length byte in it.

Upstream requirements: ⌈ The Session ID field shall be a 32-bit unsigned integer. ⌋

34. Optional Source 文件 Name and Source Line Number¶

原文标题：Optional Source File Name and Source Line Number

To identify the source of log or trace content some information to find the location in the source code shall be added to a Log and Trace message.

Therefore:

the name of the source file (string) and
the line number in the source file (unsigned integer)

can be added to the Extension Header.

In a more general way, the source file name is also called "source file identifier": A "source file identifier" constitutes a means to identify the source code file in which a log message originates. That would typically be a filename or filename stem, but could also be a full (or relative) path, or even an entirely different kind, e.g. a hash sum in case filenames are considered to be sensitive data.

Possibility to send the source file identifier and the source line number Upstream requirements: ⌈ If the bit 8 (WSFLN: "With Source File Name and Line Number ") in the "HTYP2"-field of the Base Header is set, the DLT-message shall contain the length byte for the source file identifier string and the string value itself and additionally the source line number where the DLT message originates from, added to the Extension Header. ⌋

35. Optional Tags¶

For avoiding bus traffic, especially when logging with Verbose Mode and for tracing, tags could help the application or functional cluster to classify the messages more finely by topic.

Possibility to send tags for filtering purposes Upstream requirements: ⌈ If the bit 9 (WTGS: "With Tags") in the "HTYP2"-field of the Base Header is set, the DLT-message shall contain the following elements in the given sequence:

the number of attached tags (NOTG);
for each attached tag:
a length byte for the tag name string
the string value for the tag name

added to the Extension Header. ⌋

Definition of the Number of tags Upstream requirements: ⌈ The field "NOTG" (Number of Tags) shall be an 8 bit unsigned integer value and shall count the tags to follow in the Extension Header. Therefore at maximum 255 tags can be added to a DLT-message. ⌋

Definition of the length information for each tag Upstream requirements: ⌈ The field for the length shall count the number of bytes which the tag name consumes. ⌋

Tag name format Upstream requirements: ⌈ The coding of the tag name shall be with ASCII characters without a special terminating item like the NUL-character (\0). ⌋

36. Optional Privacy Level¶

The Privacy Level helps to identify the Log and Trace content towards the degree of privacy to it. Logging clients, no matter if in the ECU or outside of the ECU, have the possibility to consider the privacy level at the Log and Trace message to ensure intended and allowed processing of them.

Possibility to add a privacy level for the containing Log and Trace message Upstream requirements: ⌈ If the bit 10 (WPVL: "With Privacy Level") in the "HTYP2"-field of the Base Header is set, the DLT-message shall contain the value for the privacy level of the current DLT-message, added to the Extension Header. ⌋

Format of the Privacy Level Upstream requirements: ⌈ The length for the Privacy Level shall be one byte unsigned integer. ⌋

Note: Since the length of the Privacy Level is defined to be one byte, no extra length information is added in the Privacy Level field of the Extension Header.

Note: There is no global definition for the meaning of each single value number of the Privacy Level.

Note: It is up to the external viewer tool or any other instance that interpret or forward the message, to meet this privacy request.

37. Optional Message Segmentation Information¶

Message Segmentation can be used to transfer a larger amount of payload data that otherwise would have not fit into a single simple DLT message. Remember: the total length of a normal, single simple DLT message is either limited by the underlying communication protocol / -medium or by the max.value of its "LEN" field in the BaseHeader (16-bit unsigned integer): 65535. In both cases, the available remaining size for the payload is smaller, because the message headers need to be included as well.

Criteria to use Message Segmentation Upstream requirements: ⌈ Based on the knowledge of the lower layer frame length limit or the limit of the "LEN" field in the BaseHeader, the Log and Trace module shall decide whether segmentation needs to be used or not. ⌋

Note: Segmentation should not be used for smaller amounts of payload data, that also fit into a single simple DLT message.

Indication of Message Segmentation Upstream requirements: ⌈ If Message Segmentation is used, the bit 11 (WSGM, "With Segmentation") in the "HTYP2"-field of the Base Header shall be set and the DLT-message shall contain the Segmentation-Information, added to the Extension Header ⌋

38. Body/Payload format¶

The Payload follows the Base Header or the Extension Header if used. The Payload contains the parameters that are logged or traced, or it contains control information.

Upstream requirements: , ⌈ If the Extension Header is used, the payload shall adjoin the Extension Header. ⌋

Upstream requirements: , ⌈ If the Extension Header is not used, the payload shall adjoin the Base Header. ⌋

Note: Compare chapter Extension Header , to see whether the Extension Header is used or not.

39. Payload in Non-Verbose 模式¶

原文标题：Payload in Non-Verbose Mode

To be able to transmit parameter values only - without the need of any meta information about them -, without additional properties like parameter names or types -, the Non-Verbose Mode can be used.

To allow the correct disassembly of the contained parameter values within a received Dlt message, a dedicated Message ID is added to the Base Header.

A separate, external file contains the description of the payload layout according to the corresponding Message ID.

Upstream requirements: ⌈ The Message ID shall be assigned unique for a single combination of constant data. ⌋

AUTOSAR Message ID range Upstream requirements: ⌈ Message IDs where bit #31 is set to '1' and bit #30 set to '0' shall be reserved for modelled Log and Trace messages standardized by AUTOSAR. ⌋

Vendor-defined Message ID range Upstream requirements: ⌈ Message IDs where bit #31 is set to '1' and bit #30 set to '1' shall be reserved for modelled Log and Trace messages specified by the Framework Provider / Stack Vendor.

Message ID bits #27..#12 shall then hold the vendor's numerical identifier and bits #11..#0 can be used by each vendor for their specific log message identifiers. ⌋

40. Assembly of variable 数据¶

原文标题：Assembly of variable data

This example will demonstrate how the variable data is assembled, transmitted and interpreted.

Following information will be transmitted to an external client by the sending of a log message:

static text: "Temperature measurement"
8-bit unsigned integer: measurement_point = 1 (no unit)
32-bit float: reading = 295.3 Kelvin

There is a unique Message ID that characterizes this log message call on this specific position in the source code. Following information is associated with this Message ID:

position in source code: source file "temp_meas.c", line number 42
static text: "Temperature measurement"
expecting the value of a 8-bit unsigned integer with variable name = "measurement_point" and unit = ""
expecting the value of a 32-bit float with variable name = "reading" and unit = "Kelvin"

All constant data is already associated with the Message ID and only the variable data will be transmitted:

Length in bit	Value	Description
8	1	8-bit unsigned integer
32	295.3	32-bit float

Based on the Message ID, the receiver can reassemble all constant data of this Dlt message (position in source code, static text, variable names and units).

其余 90 章（内容从略，见纯文本全文）¶

描述 Format for transmitted 数据
处理 of Arguments with variableLength or optional Arguments
Payload in Verbose 模式
Dlt Message Format in 通用
数据 Payload
类型 Info
Bits 类型 Length (TYLE)
Bit Variable Info (VARI)
Bit Fixed Point (FIXP)
Bits 类型 Format (TYFM)
Bits 类型 Precision (TYPR)
类型 Bool (BOOL)
类型 Signed (SINT) and 类型 Unsigned (UINT)
类型 Float (FLOA)
类型 String (STRG)
类型 Array (ARAY)
类型 Struct (STRU)
类型 Raw (RAWD)
类型 Trace Info (TRAI)
representation of natural 数据类型 argument的示例
Message 类型
数据 Messages
控制 Messages
服务 / Commands
Set Log Level
Set Trace Status
Get Log Info
Get Default Log Level
Store 配置
Reset to Factory Default
SetMessageFiltering
Set Default LogLevel
Set Default Trace Status
Get ECU 软件 Version
Get Default Trace Status
Get LogChannel Names
Get Trace Status
Set LogChannel Assignment
Set LogChannel Threshold
Get LogChannel Threshold
Buffer Overflow 通知
Call SWC Injection
DLT Commands (deprecated)
External Client / Tool
Extensions for storing in a database/文件
Sequences (下层 layer)
States
控制 flow / Transitions
Transmission of Dlt 数据 Message
Set LogLevel Filter
Buffer Overflow
错误处理
错误 messages
Buffer Overflow
Answering a Command with "错误"
Answering a Command with "NOT SUPPORTED"
错误 resolution
Transmission Retry
配置规范
Base Header
Header 类型 2 (HTYP2)
Message Info (MSIN)
Extension Header
发布信息
协议 usage and 指南
Proposal for usage of Log Levels
Log Level FATAL (DLT_LOG_FATAL)
Log Level 错误 (DLT_LOG_ERROR)
Log level WARNING (DLT_LOG_WARNING)
Log level INFO (DLT_LOG_INFO)
Log level DEBUG (DLT_LOG_DEBUG)
Log level VERBOSE (DLT_LOG_VERBOSE)
附录
Change history of AUTOSAR traceable items
Traceable item history of this document according to AUTOSAR Release R23-11
Added 规范 Items in R23-11
Changed 规范 Items in R23-11
Deleted 规范 Items in R23-11
Traceable item history of this document according to AUTOSAR Release R24-11
Added 规范 Items in R24-11
Changed 规范 Items in R24-11
Deleted 规范 Items in R24-11
Traceable item history of this document according to AUTOSAR Release R25-11
Added 规范 Items in R25-11
Changed 规范 Items in R25-11
Deleted 规范 Items in R25-11
Traceable item history of this document according to AUTOSAR Release R26-11
Added 规范 Items in R26-11
Changed 规范 Items in R26-11
Deleted 规范 Items in R26-11

Log and Trace Protocol Specification (LogAndTraceProtocol)¶