AUTOSAR_PRS_LogAndTraceProtocol

十二月 12, 2024

Log and Trace Protocol Specification

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).

While the version "1" of the protocol still keeps its validity (look up [2], 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.

Purpose

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

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.

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.

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 [ISO/IEC 7498-1:1994].

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).

Limitations

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

Dependencies to other protocol layers and documents

[1] ISO/IEC 7498-1:1994 Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model - Part 1 www.iso.org

[2] Log and Trace Protocol Specification v.1 AUTOSAR_PRS_LogAndTraceProtocol from release R20-11

[3] AUTOSAR Log And Trace Extract Template AUTOSAR_TPS_LogAndTraceExtract

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.

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.

Usage example: General logging with Dlt

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

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)

The Dlt module sends the Dlt message to the communications bus.

An external client receives and stores the Dlt message.

Usage example: Tracing of VFB

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

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

The Dlt communication module forwards the trace message to the network.

An external client receives and stores the trace messages.

Usage example: Runtime configuration of Dlt

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

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

The Dlt module adapts its configuration of filter settings accordingly.

The Dlt module informs the application about the new log level.

Usage example: 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.

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

The Dlt module filters and generates the Dlt message.

The Dlt module sends the Dlt message to the communications bus.

An external client fetches meta information from an external file.

The merged information is stored by an external client.

Requirements traceability

Acronyms and abbreviations

Term and definition

Protocol specification

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.

[PRS_Dlt_01000]

[RS_LT_00016]

[RS_LT_00013]

The "Base Header" and the "Extension Header" shall always use the network byte order.

Note:

"Network Byte Order" equals "Big Endian".

Base Header

[PRS_Dlt_01001]

[RS_LT_00002]

[RS_LT_00013]

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.

[PRS_Dlt_01002]

[RS_LT_00002]

[RS_LT_00013]

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).

[PRS_Dlt_01003]

[RS_LT_00002]

[RS_LT_00013]

If the Log and Trace message is a Data Message in Verbose Mode or a Control Message, the MSIN (Message Info) and NOAR (Number of arguments) shall be added to the Base Header.

Note:

The information, whether the Log and Trace message is a Data Message in Verbose or Non-Verbose Mode or a Control Message, is located in the HTYP2 – field sub-element "CNTI" (Content Info); see the following subchapter for more details.

[PRS_Dlt_01004]

[RS_LT_00002]

[RS_LT_00013]

[RS_LT_00017]

If the Log and Trace message is a Data Message (Verbose Mode or Non-Verbose Mode), the TMSP2 (Timestamp) with a nanosecond resolution shall be added to the Base Header.

[PRS_Dlt_01005]

[RS_LT_00002]

[RS_LT_00013]

If the Log and Trace message is a Non-Verbose Mode Data Message, the MSID (Message ID) shall be added to the Base 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.

[PRS_Dlt_01006]

[RS_LT_00002]

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

[PRS_Dlt_01007]

[RS_LT_00002]

The size of the Header Type - field (HTYP2) shall be 32 bit.

[PRS_Dlt_01008]

[RS_LT_00002]

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)

[PRS_Dlt_01009]

[RS_LT_00002]

The two "CNTI"-bits (Content Info; bits 0 – 1 in HTYP2) shall be a 2-bit unsigned integer and shall be encoded in the following way:

0x0: Verbose Mode Data Message

0x1: Non-Verbose Mode Data Message

0x2: Control Message

0x3: reserved

[PRS_Dlt_01010]

[RS_LT_00002]

The "VERS"-bits (Version Number; bits 5 – 7 in HTYP2) shall be a 3-bit unsigned integer and shall contain the Log and Trace protocol version as defined by AUTOSAR. The version number valid for this specification release is "2".

Note:

The "VERS"-bits are located at the same position like in version "1" of the protocol. Therefore the receivers can always distinguish the protocol versions.

[PRS_Dlt_01011]

[RS_LT_00002]

If one of the following bits are set, the "Extension Header" shall be added after the "Base Header":

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)

Note:

The details about the "Extension Header" and the correlation with the above-mentioned bits are specified in a later subchapter. Also, the bits 12 – 31 (currently "reserved by AUTOSAR for future usage") are intended to require the "Extension Header" in the future.

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.

[PRS_Dlt_00319]

[RS_LT_00018]

The Message Counter is an unsigned 8-bit (0-255) integer.

[PRS_Dlt_00613]

[RS_LT_00018]

After initialization of the Dlt module, the Message Counter (MCNT) shall be set to ‘0’.

[PRS_Dlt_00105]

[RS_LT_00018]

The Message Counter shall be incremented by one for each Dlt message that is transmitted to assigned LogChannel.

[PRS_Dlt_00106]

[RS_LT_00018]

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.

Message Length

[PRS_Dlt_00320]

[RS_LT_00002]

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

[PRS_Dlt_00614]

[RS_LT_00002]

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.

Note:

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 "5.1.2.7 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.

Conditional "Message Info"

Like specified above (refer PRS_Dlt_01003), 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.

[PRS_Dlt_00618]

[RS_LT_00002]

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)

[PRS_Dlt_00324]

[RS_LT_00002]

The Message Type (MSTP) shall be a 3-bit unsigned integer.

[PRS_Dlt_00120]

[RS_LT_00002]

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

[PRS_Dlt_00325]

[RS_LT_00002]

The Message Type Info field (MTIN) shall be a 4-bit unsigned integer.

[PRS_Dlt_00619]

[RS_LT_00002]

If the MSTP field is set to 0x0 (i.e. Dlt Log Message), the Message Type Info field (MTIN) shall have one of the following values with the following meaning:

0x1: DLT_LOG_FATAL (Fatal system error)

0x2: DLT_LOG_DLT_ERROR (Application error)

0x3: DLT_LOG_WARN (Correct behavior cannot be ensured)

0x4: DLT_LOGINFO (Message of LogLevel type “Information”)

0x5: DLT_LOG_DEBUG (Message of LogLevel type “Debug”)

0x6: DLT_LOG_VERBOSE (Message of LogLevel type “Verbose”)

0x7 – 0xF: Reserved

[PRS_Dlt_00620]

[RS_LT_00002]

If the MSTP field is set to 0x1 (i.e. Dlt Trace Message), the Message Type Info field (MTIN) shall have one of the following values with the following meaning:

0x1: DLT_TRACE_VARIABLE (Value of variable)

0x2: DLT_TRACE_FUNCTION_IN (Call of a function)

0x3: DLT_TRACE_FUNCTION_OUT (Return of a function)

0x4: DLT_TRACE_STATE (State of a State Machine)

0x5: DLT_TRACE_VFB (RTE events)

0x6 – 0xF: Reserved

[PRS_Dlt_00621]

[RS_LT_00002]

If the MSTP field is set to 0x2 (i.e. Dlt Network Message), the Message Type Info field (MTIN) shall have one of the following values with the following meaning:

0x1: DLT_NW_TRACE_IPC (Inter-Process-Communication)

0x2: DLT_NW_TRACE_CAN (CAN Communications bus)

0x3: DLT_NW_TRACE_FLEXRAY (FlexRay Communications bus)

0x4: DLT_NW_TRACE_MOST (Most Communications bus)

0x5: DLT_NW_TRACE_ETHERNET (Ethernet Communications bus)

0x6: DLT_NW_TRACE_SOMEIP (Inter-SOME/IP Communication)

0x7-0xF: User Defined (User defined settings)

[PRS_Dlt_00622]

[RS_LT_00002]

If the MSTP field is set to 0x3 (i.e. Dlt Control Message), the Message Type Info field (MTIN) shall have one of the following values with the following meaning:

0x1: DLT_CONTROL_REQUEST (Request Control Message)

0x2: DLT_CONTROL_RESPONSE (Respond Control Message)

0x3-0xF: Reserved

Conditional "Number of Arguments"

Like specified above (refer PRS_Dlt_01003), 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.

[PRS_Dlt_00326]

[RS_LT_00002]

The Number of Arguments field (NOAR) shall be an 8-bit unsigned integer.

[PRS_Dlt_00126]

[RS_LT_00002]

[RS_LT_00024]

The Number of Arguments field (NOAR) shall contain the number of provided arguments or control commands within the payload.

Conditional "ns-Timestamp"

Like specified above (refer PRS_Dlt_01004), 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.

[PRS_Dlt_01012]

[RS_LT_00017]

Format of ns-Timestamp

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 [0x3B9A C9FF];

Invalid value in nanoseconds: [0x3B9A CA00] to [0x3FFF FFFF];

Bit 30 and 31 are reserved in this case.

[PRS_Dlt_01013]

[RS_LT_00017]

Format of ns-Timestamp for ECUs without a synchronized time base

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.

[PRS_Dlt_01014]

[RS_LT_00017]

Substance of the ns-Timestamp

The ns-Timestamp value shall hold the time at the moment an LT User calls the LT module and hands over its LT content.

Conditional "Message ID"

Like specified above (refer PRS_Dlt_01005), 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.

[PRS_Dlt_00624]

[RS_LT_00027]

The Message ID shall be a 32-bit unsigned integer.

Note:

More details can be found in subchapter 5.1.3.1 Payload in Non-Verbose Mode.

Extension Header

The Extension Header contains additional data that facilitates the interpretation of the pure LT content. Thus, further properties of the LT 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).

The length information for a specific field can also be '0'. In this case, no field value is provided and the field ends after the length byte.

In order to allow for future expansions of the Extension Header without breaking backward compatibility, all further fields in the future must start with a 1 byte length information. In this way, an implementation according to the current specification can always move from field to field (and thus finally also to the end of the header), even if it can't interpret all of the field values.

Future field elements in the Extension Header are enabled by using the reserved flags in the "HTYP2"-field from the Base Header: currently bits 12 – 31 (marked as "reserved by AUTOSAR for future usage").

As a consequence for all new fields in the future / for all currently "reserved" flags: the number of flags in "HTYP2" which are set to "1" have to be equal with the number of length information added to the Extension Header.

[PRS_Dlt_01015]

[RS_LT_00002]

Locate Extension Header after Base Header

If the Extension Header gets used, it shall be directly attached after the Base Header fields.

[PRS_Dlt_01016]

[RS_LT_00002]

Sequence of the fields in the Extension Header

The fields are to be optionally added to the Extension Header depending on and in the sequence of the corresponding flags in the "HTYP2"-field from the Base Header.

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.

[PRS_Dlt_01017]

[RS_LT_00022]

Possibility to send the ECU ID

If the bit 2 (WEID, "With ECU ID") in the "HTYP2"-field of the Base Header is set, the LT-message shall contain the length byte and the string value for the ECU ID, added to the Extension Header.

[PRS_Dlt_01018]

[RS_LT_00022]

Length information

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.⌋ (RS_LT_00022)

[PRS_Dlt_01019]

[RS_LT_00022]

ECU ID format

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

Note:

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

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.

[PRS_Dlt_01020]

[RS_LT_00021]

Possibility to send the Application ID and Context ID

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

[PRS_Dlt_01021]

[RS_LT_00021]

Sequence of Application ID and Context ID

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.

[PRS_Dlt_01022]

[RS_LT_00021]

Length information of Application ID and Context ID

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.

[PRS_Dlt_01023]

[RS_LT_00021]

Application ID and Context ID format

The coding of the Application ID and Context ID shall contain only ASCII characters without a special terminating item like the NUL-character (\0).

Note:

The string ends for Application ID and Context ID are only given by the length specification which precedes each.

[PRS_Dlt_01054]

[RS_LT_00058]

"#" (U+0023) as prefix of Context IDs shall be reserved for modelled Log and Trace messages standardized by AUTOSAR.

[PRS_Dlt_01055]

[RS_LT_00058]

Context IDs for Log and Trace messages defined by stack vendors shall have a "+" (U+002B) prefix, followed by the vendor's numerical identifier converted to a string as per PRS_Dlt_01056, followed by a vendor-defined remainder.

[PRS_Dlt_01056]

[RS_LT_00058]

16-bit vendor-IDs are converted to a 2-char ASCII string using Base62 encoding using the string "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" as digit sequence.

Note:

The highest Vendor ID that can be encoded with Base62 in two characters without data loss is 3843 (0x0f03). This ID will be encoded as the string "zz".

Example:

Using the Vendor ID 0x07bb, the context ID starts with the string "+Vv" with "Vv" being the Base62-encoded string for 0x07bb.

Optional Session ID

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

[PRS_Dlt_01024]

[RS_LT_00020]

If the bit 4 (WSID, "With Session ID") in the "HTYP2"-field of the Base Header is set, the LT-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.

[PRS_Dlt_00322]

[RS_LT_00020]

The Session ID field shall be a 32-bit unsigned integer.

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.

[PRS_Dlt_01025]

[RS_LT_00056]

Possibility to send the source file identifier and the source line number

If the bit 8 (WSFLN: "With Source File Name and Line Number ") in the "HTYP2"-field of the Base Header is set, the LT-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 LT message originates from, added to the Extension Header.

[PRS_Dlt_01026]

[RS_LT_00056]

Content in the Extension Header for the source file identifier and the source line number

If the source file identifier and the source line number are transmitted in the Extension Header, the following sequence shall be used:

the length byte for the source file identifier string;

the string value itself for the source file identifier string;

the source line number

Note:

since the source line number is defined to have 32 bit, no additional length byte for the source line number is contained.

[PRS_Dlt_01027]

[RS_LT_00056]

Definition of the length information

The field for the length shall count the number of bytes which the source file identifier consumes. This number also equals the amount of UTF-8 code units.

[PRS_Dlt_01028]

[RS_LT_00056]

Source file identifier format

The coding of the source file identifier shall be with UTF-8 code units without BOM and without termination characters.

[PRS_Dlt_01029]

[RS_LT_00056]

Substance of the source file identifier

The source file identifier shall contain the indication from where the log or trace content originates.

Note:

This indication can be made up by the filename stem (filename without an extension) and maybe additionally the filename extension and/or the path (full or partial) to the file can be included.

Alternatively, in case the origin of the log and trace content is considered to be sensitive data, the source file identifier can also be something else, like a hash sum or any other encoded identification.

Note:

Up to 255 bytes respectively UTF-8 code units can be used.

[PRS_Dlt_01030]

[RS_LT_00056]

Source Line Number format

The length for the source line number shall be four bytes interpreted as a 32-bit unsigned integer.

Note:

The Source Line Number starts counting with '1', i.e. the value '0' is not used. Since the length for the line number is statically defined as a 32-bit unsigned integer, no separate length byte shall be added to the Extension Header.

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.

[PRS_Dlt_01031]

[RS_LT_00021]

Possibility to send tags for filtering purposes

If the bit 9 (WTGS: "With Tags") in the "HTYP2"-field of the Base Header is set, the LT-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.

[PRS_Dlt_01032]

[RS_LT_00021]

Definition of the Number of tags

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 LT-message.

[PRS_Dlt_01033]

[RS_LT_00021]

Definition of the length information for each tag

The field for the length shall count the number of bytes which the tag name consumes.

[PRS_Dlt_01034]

[RS_LT_00021]

Tag name format

The coding of the tag name shall be with ASCII characters without a special terminating item like the NUL-character (\0).

Note:

The string end is only given by the Length information for the tag name.

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.

[PRS_Dlt_01035]

[RS_LT_00021]

Possibility to add a privacy level for the containing Log and Trace message

If the bit 10 (WPVL: "With Privacy Level") in the "HTYP2"-field of the Base Header is set, the LT-message shall contain the value for the privacy level of the current LT-message, added to the Extension Header.

[PRS_Dlt_01036]

[RS_LT_00021]

Format of the Privacy Level

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.

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 LT message. Remember: the total length of a normal, single simple LT 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.

[PRS_Dlt_01043]

[RS_LT_00013]

Criteria to use Message Segmentation

Based on the knowledge of the lower layer frame length limit or the limit of the "LEN" field in the BaseHeader, the L&T 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 LT message.

[PRS_Dlt_01044]

[RS_LT_00013]

Indication of Message Segmentation

If Message Segmentation is used, the bit 11 (WSGM, "With Segmentation") in the "HTYP2"-field of the Base Header shall be set and the LT-message shall contain the Segmentation-Information, added to the Extension Header.

[PRS_Dlt_01045]

[RS_LT_00013]

Content of the Segmentation-Information in the Extension Header

The Segmentation-Information shall contain the following elements in the given sequence:

the length byte for this Segmentation-Information in bytes;

8-bit FrameType, which can either be

0 := "FirstFrame";

1 := "ConsecutiveFrame";

2 := "LastFrame";

3 := "AbortFrame";

x-bit Segmentation details, depending on FrameType:

"FirstFrame":

64-bit unsigned integer "TotalLength";

"ConsecutiveFrame":

32-bit unsigned integer "SequenceCounter;";

"LastFrame":

0-bit: n/a; no segmentation details;

"AbortFrame":

8-bit unsigned integer "AbortReason";

0 - no error/no reason

communication time out

2 - insufficient resources

3 - sequence/protocol error

[PRS_Dlt_01046]

[RS_LT_00013]

[RS_LT_00018]

FrameType sequence for transmission of a Segmented Message

The segmentation sequence shall be:

1 "FirstFrame";

0 ... 4.294.967.295 "ConsecutiveFrames": depending on the TotalLength of the segmented data.

1 "LastFrame";

Note:

"FirstFrame" and "ConsecutiveFrame" use the maximum available size a of regular LT message. The "LastFrame" can be shorter.

[PRS_Dlt_01048]

[RS_LT_00013]

[RS_LT_00018]

Aborting the sequence

After the "FirstFrame" but before the "LastFrame", there can be an "AbortFrame" to stop the sequence in case a problem occurred. The already transmitted parts shall be discarded. After an "AbortFrame" was sent, the next allowed FrameType is a "FirstFrame".

[PRS_Dlt_01049]

[RS_LT_00013]

Content of the "TotalLength" information

The "TotalLength" information shall contain the overall payload data size in bytes that needs to be transmitted in a segmented way.

[PRS_Dlt_01050]

[RS_LT_00013]

[RS_LT_00018]

Usage of the segmentation "SequenceCounter"

The segmentation SequenceCounter shall only be used in the "ConsecutiveFrame(s)", in case there are any. After each FirstFrame, the SequenceCounter shall start with '0' and can get at maximum '4.294.967.295' in the last "ConsecutiveFrame" before the "LastFrame". There shall be no wrap-around ('4.294.967.295' -> '0', '1' ... ).

[PRS_Dlt_01051]

[RS_LT_00013]

Transfer of Payload data blocks

In case FrameType equals {FirstFrame or ConsecutiveFrame or LastFrame}, the Payload-segment of the LT-messages shall be sequentially filled with data blocks as slices from the overall user-data. The sequence of the data slices must be in line with the transmitted LT-messages:

(with:

FirstFrame: FF;

ConsecutiveFrame: CF;

LastFrame: LF;

SequenceCounter: SqCntr

)

FF [DataSlice_0],

CF_0 [SqCntr = 0; DataSlice1],

CF_1 [SqCntr = 1; DataSlice2],

CF_<n> [SqCntr = <n>; DataSlice<n+1>],

LF [DataSlice<n+2>].

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.

[PRS_Dlt_00314]

[RS_LT_00013]

[RS_LT_00023]

If the Extension Header is used, the payload shall adjoin the Extension Header.

[PRS_Dlt_00315]

[RS_LT_00013]

[RS_LT_00023]

If the Extension Header is not used, the payload shall adjoin the Base Header.

Note:

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

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.

[PRS_Dlt_00352]

[RS_LT_00027]

The Message ID shall be assigned unique for a single combination of static data.

[PRS_Dlt_01062]

[RS_LT_00058]

AUTOSAR Message ID range

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.

[PRS_Dlt_01053]

[RS_LT_00058]

Vendor-defined Message ID range

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.

Note:

Assuming the VendorID is 0x0123, a vendor-defined Message ID could be: 0xC012 3A98.

[PRS_Dlt_00353]

[RS_LT_00023]

[RS_LT_00026]

With the combination of a Message ID and an external description, following information shall be recoverable:

Type Info

Type Length

Data Type

TypeFormat

TypePrecision

Variable Info

Fixed Point

Note:

If verbose mode is used instead (see chapter 7.2.5) then these parameters are contained directly within the Dlt message payload.

[PRS_Dlt_00134]

[RS_LT_00023]

[RS_LT_00026]

With the combination of a Message ID and an external description, following information shall be recoverable that is otherwise provided in the message headers:

Message Type (MSTP)

Message Info (MSIN)

Number of arguments (NOAR)

Even if these static data are already specified in that external file (see next chapters for more details) and are therefore not needed as an essential part of the message, it should be allowed in rare cases to send differing static data values in Non-Verbose Mode messages.

[PRS_Dlt_01052]

[RS_LT_00023]

[RS_LT_00026]

In cases where the Message ID is not uniquely related to Context ID and Application ID in the Log and Trace Extract, the fields Context ID and Application ID have to be transmitted separately with Non-Verbose Messages in the Extension Header. This is specifically the case with Standardized logging and tracing. In case the uniqueness of the MessageID is still given, the Context ID and Application ID shall be recoverable from the external description and a separate transmission is not needed.

[PRS_Dlt_01037]

[RS_LT_00023]

[RS_LT_00026]

Static Data in Non-Verbose Mode messages shall take precedence over the data as specified in the Log and Trace extract file.

Note:

This case should remain an exception, as otherwise the entire Non-Verbose Mode would become contradictory.

Assembly of Non-Static Data

This example will demonstrate how the non-static 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 static data is already associated with the Message ID and only the non-static data will be transmitted:

Based on the Message ID, the receiver can reassemble all static data of this Dlt message (position in source code, static text, variable names and units). The non-static data will be transmitted consistently packed. The interpretation is possible by using the information associated with the Message ID. Also the ordering of the arguments is associated with the Message ID.

[PRS_Dlt_00378]

[RS_LT_00014]

[RS_LT_00023]

The non-static data shall be transmitted consistently packed and byte aligned.

Note:

In Verbose Mode the maximum number of arguments can be '255' since the field "NOAR" (NumberOfArguments) is defined to be uint8. In contrast to that, in Non-Verbose Mode the maximum number of arguments is not limited as such by itself. The limit is the overall maximum length of the complete Log and Trace message (headers + payload), which is 65535 bytes because the "LEN" – field is defined as uint16.

Description Format for transmitted Data

An external file holds the information how the payload shall be interpreted. For describing transmitted messages which are in non-verbose mode the ARXML System Description shall be used.

Please see the AUTOSAR_TPS_LogAndTraceExtract [3] for the details.

The software supplier of an application or of the middleware shall provide this description file.

Payload in Verbose Mode

Dlt messages which are sent in Verbose Mode contain a complete description of the parameters next to the parameter values itself.

This means that on the one hand no external file is needed for disassembly; On the other hand, a higher amount of data is sent on the bus.

The Verbose Mode can be used on ECUs where enough memory and high network bandwidth are available. Because of the self-description, the stored data on the external client is interpretable at any time and without any further external information.

Dlt Message Format in General

In Verbose Mode, up to 255 arguments can be transmitted. The information about the payload is provided within the message itself. The payload normally adjoins the Extension Header and consists of one or more arguments. But since the Extension Header is optional, it can be omitted and then the payload adjoins the Base Header. The number of arguments in the payload is specified in the Base Header within the Number of arguments field (NOAR).

Each argument consists of a “Type Info” field and the appended Data Payload. In “Type Info” field the necessary information is provided to interpret the following data structure.

[PRS_Dlt_00459]

[RS_LT_00023]

[RS_LT_00044]

The Dlt message in Verbose Mode shall consist of

Base Header

Extension Header (optionally)

Payload with n Arguments, each consisting of a tuple of Type Info and Data Payload.

[PRS_Dlt_00409]

[RS_LT_00023]

[RS_LT_00013]

The arguments and all inherited data shall be transmitted consistently packed.

Data Payload

The Data Payload contains the value of the variable (i.e. the debug information of an application or middleware), which is going to be transmitted on the communications bus. In addition to the variable value itself, it is needed to provide information like size and type of the variable. This information is contained in the Type Info field.

Type Info

The Type Info field contains meta data about the Data Payload.

[PRS_Dlt_00135]

[RS_LT_00002]

[RS_LT_00044]

The Type Info is a 32-bit field and has to be part of the Payload segment if a Dlt log or trace message shall be sent in Verbose Mode.

[PRS_Dlt_00625]

[RS_LT_00044]

The Type Info is a 32-bit field shall be encoded the following way:

Bit 0 - 3 Type Length (TYLE)

Bit 4 Type Bool (BOOL)

Bit 5 Type Signed (SINT)

Bit 6 Type Unsigned (UINT)

Bit 7 Type Float (FLOA)

Bit 8 Type Array (ARAY)

Bit 9 Type String (STRG)

Bit 10 Type Raw (RAWD)

Bit 11 Variable Info (VARI)

Bit 12 Fixed Point (FIXP)

Bit 13 Trace Info (TRAI)

Bit 14 Type Struct (STRU)

Bit 15 – 17 Type Format (TYFM)

Bit 18 – 23 Type Precision (TYPR)

Bit 24 – 31 reserved for future use

[PRS_Dlt_00626]

[RS_LT_00044]

The bits 0-3 (i.e. Type Length) of the Type Info field define the length of the adjoined Data Payload. The Type Length (TYLE) bit-field is encoded the following way:

0x00: not defined

0x01: 8 bit

0x02: 16 bit

0x03: 32 bit

0x04: 64 bit

0x05: 128 bit

0x06 – 0x0F: reserved

[PRS_Dlt_00782]

[RS_LT_00025]

[RS_LT_00056]

The bits 15-17 (i.e. Type Format (TYFM)) of the Type Info field define the coding respectively the desired representation format of the later given Data payload. The coding of these three bits depends on the used Types and is restricted to only the following four Types:

STRG

SINT

UINT

FLOA

Note:

The Type Format (TYFM) for the Type STRG is identical and fully compatible with the former defined String Coding (SCOD), which has been at the same position, bits 15-17. Compared to the former SCOD, TYFM now extends the usage also to the Types SINT, UINT and FLOA.

[PRS_Dlt_00783]

[RS_LT_00025]

[RS_LT_00056]

In dependence of the used Type the adjoined Data field is coded respectively shall get interpreted the following way:

Note:

The mentioned hint "similar to printf" is intended to refer to the C-function "printf()" and its conversion specifiers 'f', 'e', 'a' and 'g' as defined by the C Standard Library <stdio.h>.

Note:

The FLOA TYFM '0x04' ( = "general format" for floating-point numbers) is intended to be similar to what the conversion specifier 'g' for the C-function "printf()" does. The detailed description to conversion specifier 'g' is more complex than simply "use the shortest out of %e or %f", like written in the table above. For the exact details refer to the C11 standard.

[PRS_Dlt_00784]

[RS_LT_00056]

The bits 18-23 (i.e. Type Precision (TYPR)) of the Type Info field define the desired precision of the later given Data payload. The coding of these six bits depends on the used Type and is restricted to only the following three Types:

SINT

UINT

FLOA

[PRS_Dlt_00785]

[RS_LT_00056]

In dependence of the used Type the adjoined Data field shall get a precision in the following way:

The table below shows a simplified assembly of Type Info

The entries of Type Info are specified in the following section in detail.

Details regarding the Data Types of the Type Info field are described in the following chapter.

Bits Type Length (TYLE)

Type Length specifies the length of the standard data type.

[PRS_Dlt_00354]

[RS_LT_00044]

Type Length is a bit field of 4 bit.

Type Length contains :

0 for strings (STRG), structs (STRU), raw data (RAWD) and Trace Info (TRAI)

1 (8 bit) for bool data (BOOL)

1 (8 bit) or 2 (16 bit) or 3 (32 bit) or 4 (64 bit) or 5 (128 bit) for signed (SINT) and unsigned integer data (UINT)

2 (16 bit) or 3 (32 bit) or 4 (64 bit) or 5 (128 bit) for float data (FLOA)

Bit Variable Info (VARI)

If Variable Info (VARI) is set, the name and the unit of a variable can be added at the beginning of the Data payload field. Both contain a length information field and a field with the text (of name or unit). The length field contains the number of characters of the associated name or unit field. The unit information is to add only in some data types.

Independent from the data type, the name or the unit can be omitted (if not needed) by setting the corresponding length information field to 0.

[PRS_Dlt_00410]

[RS_LT_00025]

The coding of all text in Variable Info (VARI) shall be with 8-bit characters where each character is within the valid range of the ASCII character set.

[PRS_Dlt_01038]

[RS_LT_00025]

The strings in VARI shall be without a special terminating item like the NUL-character (\0).

[PRS_Dlt_01039]

[RS_LT_00025]

If the length information field of the name or the unit is set to 0, the corresponding text field shall be omitted.

Bit Fixed Point (FIXP)

If fixed point values are used (SINT or UNIT) for transmission at protocol level but the value should finally represent a floating point number, the Fixed Point (FIXP) bit shall be set. Then the Data field represents the physical value of a fixed-point variable. For interpreting the fixed-point variable, the logical value of this variable has to be calculated. The logical value is calculated by the physical value, the quantization and the offset of fixed-point variable. If the Fixed Point (FIXP) bit is set, the quantization and the offset are added at the beginning of the Data payload field.

[PRS_Dlt_00389]

[RS_LT_00044]

The following equation defines the relation between the logical value (log_v) and the physical value (phy_v), offset and quantization:

log_v = phy_v * quantization + offset

[PRS_Dlt_00169]

[RS_LT_00044]

The bit Fixed Point (FIXP) shall only be set in combination with Type Signed (SINT) or Type Unsigned (UINT).

Bits Type Format (TYFM)

Type Format specifies only the coding of the data field in case it is of Type String (STRG), Type Signed (SINT), Type Unsigned (UINT) and Type Float (FLOA).

All other protocol elements keep their default format, like :

strings for parameter name and unit and description are coded with 8-bit characters where each character is within valid range of ASCII character set; or

integers and floats for length information or fixed point conversion are out of scope for a representation format information.

[PRS_Dlt_00786]

[RS_LT_00025]

[RS_LT_00056]

Type Format is a bit field of 3 bit.

[PRS_Dlt_00787]

[RS_LT_00025]

[RS_LT_00056]

In case the used Type is String (STRG) the following values for Type Format shall be used to encode and decode respectively interpret the adjoined Data field:

0x00: ASCII (8-bit characters where each character is within valid range of ASCII character set)

0x01: UTF-8

0x02 - 0x07: reserved for future use

Note:

For this case, the TypeFormat (TYFM) is a compatible replacement for the former String Coding (SCOD) bits.

[PRS_Dlt_00788]

[RS_LT_00056]

In case the used Type is Signed (SINT) or Unsigned (UINT) the following values for Type Format shall be used to request and interpret a requested display representation of the adjoined Data field:

0x00: write it as base10

0x01: write it as base8

0x02: write it as base16

0x03: write it as base2

0x04 – 0x07: reserved for future use

[PRS_Dlt_00789]

[RS_LT_00056]

In case the used Type is Float (FLOA) the following values for Type Format shall be used to request and interpret a requested display representation of the adjoined Data field:

0x00: implementation-defined; (used for backward compatibility reasons with the former String Coding (SCOD).)

0x01: similar to printf "%f" => display the value in the format "[-]ddd.ddd",

i.e. as decimal floating point; e.g.: '123.45';

0x02: similar to printf "%e" => display the value in the format "[-]d.ddde±dd",

i.e. as scientific notation with mantissa and exponent; e.g.: '1.2345e+2';

0x03: similar to printf "%a" => display the value in the format "[-]0xh.hhhhp±d",

i.e. as hexadecimal floating point; e.g.: '0x1.edccccp+6';

0x04: similar to printf "%g" => Use the shortest representation: %e or %f,

also known as "general format" for floating-point numbers.

0x05 – 0x07: reserved for future use

[PRS_Dlt_00790]

[RS_LT_00025]

[RS_LT_00056]

Type Format shall be set and used for interpretation if Type String (STRG), Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA) is set.

[PRS_Dlt_00791]

[RS_LT_00044]

[RS_LT_00025]

[RS_LT_00056]

If Trace Info (TRAI) is set, Type Format shall be set and used for interpretation of the trace data string like for Type String (STRG).

[PRS_Dlt_00792]

[RS_LT_00056]

If Type Array (ARAY) is set in combination with Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA), Type Format shall be set and used for interpretation.

[PRS_Dlt_00793]

[RS_LT_00025]

[RS_LT_00056]

If Type Struct (STRU) is set, Type Format shall be set and used for interpretation in each single substructured Type Info field in case the addressed Data field is of Type String (STRG), Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA).

[PRS_Dlt_00794]

[RS_LT_00044]

[RS_LT_00025]

[RS_LT_00056]

For Data field types

other than Type String (STRG), Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA) or

other than Arrays of Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA) or

other than Type String (STRG), Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA) as sub-elements in Struct

the Type Format should be filled with '0' and shall be ignored.

Bits Type Precision (TYPR)

Type Precision applies only for Data of Type Signed (SINT), Type Unsigned (UINT) and Type Float (FLOA).

[PRS_Dlt_00795]

[RS_LT_00056]

Type Precision (TYPR) is a bit field of 6 bit.

[PRS_Dlt_00796]

[RS_LT_00056]

In case the used Type is Signed (SINT) or Type Unsigned (UINT) the following values for Type Precision (TYPR) shall be used to request and interpret a requested minimum number of digits to appear in the requested TYFM number base (e.g. like "base2" or "base16") for the adjoined Data field:

use needed number of digits for the value to be printed (similar to printf "%d"); at least one digit shall be printed; in that way, also the character '0' is written and the digit stays not empty. Padding is not used.

1 - 63:

minimum number of digits to appear +1 (e.g. TYPR = 3 equals printf "%.4d"); If the converted value requires more digits, the TYPR is ignored and the complete number is written. If the converted value requires fewer digits, the value is padded on the left.

Note:

For Type Format equaling to "base16", "base8" or "base2" a padding with '0' may be used, otherwise ("base10") a space padding may be used in case the minimum number of digits is longer than the value to be written.

[PRS_Dlt_00797]

[RS_LT_00056]

In case the used Type is Float (FLOA) and TYFM equals '0' ("implementation-defined") or '1' ("decimal floating point" / printf %f), the following values for Type Precision (TYPR) shall be used to request and interpret a requested number of digits to appear after the radix point for the adjoined Data field:

use implementation-defined number of digits to appear after the radix character;

1 - 63:

number of digits to appear after the radix character -1 (e.g. TYPR = 3 equals printf "%.2f")

[PRS_Dlt_00798]

[RS_LT_00056]

In case the used Type is Float (FLOA) and TYFM equals '2' ("scientific notation" / printf %e) or '3' ("hexadecimal floating point " / printf %a), the following values for Type Precision (TYPR) shall be used to request and interpret a requested number of digits to appear after the radix point for the adjoined Data field:

use implementation-defined precision;

1 - 62:

number of digits to appear after the radix character -1 (e.g. TYPR = 3 equals printf "%.2e")

use precision necessary for loss-less printing of the type, e.g. "%.17e" for Float64

Note:

If TYPR equals '63' and therefore a "loss-less printing" of the float value is requested: depending on the type length of the concerned float-value, the needed precision differs:

Due to the nature of "decimal floating point" (compare [PRS_Dlt_00797]), the "loss-less printing" option is not foreseen for TYFM equals '0' or '1'.

[PRS_Dlt_00799]

[RS_LT_00056]

In case the used Type is Float (FLOA) and TYFM equals '4' ("general format" for floats) the following values for Type Precision (TYPR) shall be used to request and interpret a requested number of significant digits for the adjoined Data field:

use implementation-defined precision;

1 - 62:

number of significant digits (e.g. TYPR = 3 equals printf "%.3g")

use precision necessary for loss-less printing of the type, e.g. "%.17g" for Float64

[PRS_Dlt_00800]

[RS_LT_00056]

Type Precision shall be set and used for interpretation if Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA) is set.

[PRS_Dlt_00801]

[RS_LT_00056]

Type Precision shall be set and used for interpretation if Type Array (ARAY) is set in combination with Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA).

[PRS_Dlt_00802]

[RS_LT_00056]

If Type Struct (STRU) is set, Type Precision shall be set and used for interpretation in each single sub-structured Type Info field in case the addressed Data field is of Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA).

[PRS_Dlt_00803]

[RS_LT_00044]

[RS_LT_00025]

[RS_LT_00056]

For Data field types

other than Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA) or

other than Arrays of Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA) or

other than Type Signed (SINT), Type Unsigned (UINT) or Type Float (FLOA) as sub-elements in Struct

the Type Precision should be filled with '0' and shall be ignored.

Type Bool (BOOL)

[PRS_Dlt_00422]

[RS_LT_00044]

If the BOOL bit is set, the Data Payload shall consist of at least one 8-bit unsigned integer parameter.

[PRS_Dlt_00423]

[RS_LT_00044]

If the Data field equals 0x0, it shall be interpreted as FALSE. In all other cases it shall be interpreted as TRUE.

[PRS_Dlt_00139]

[RS_LT_00044]

Type Length (TYLE) shall be 1.

[PRS_Dlt_00355]

[RS_LT_00044]

If Variable Info (VARI) is set, the Length of Name and the Name fields shall be added.

[PRS_Dlt_00369]

[RS_LT_00044]

The Data Payload of Type Bool (BOOL) shall be assembled as shown in following table.

Type Signed (SINT) and Type Unsigned (UINT)

The SINT and UINT Data Payload are assembled in the same way. The only difference is in interpreting the Data field.

[PRS_Dlt_00385]

[RS_LT_00044]

If the SINT bit is set, the Data Payload consists of at least one signed integer Data field.

[PRS_Dlt_00386]

[RS_LT_00044]

If the UINT bit is set, the Data Payload consists of at least one unsigned integer Data field.

Variable Info (VARI) and Fixed Point (FIXP) are optional.

[PRS_Dlt_00356]

[RS_LT_00044]

Type Length (TYLE) shall be set to 1, 2, 3, 4 or 5.

[PRS_Dlt_00357]

[RS_LT_00044]

If Variable Info (VARI) is set, the "Length of Name", "Length of Unit", the "Name" and the "Unit" fields shall be added.

[PRS_Dlt_00412]

[RS_LT_00044]

If FIXP is set, the Quantization and Offset fields shall be added.

[PRS_Dlt_00388]

[RS_LT_00044]

The Quantization field shall be a 32-bit float value in binary representation according to IEEE 754-2008.

[PRS_Dlt_00387]

[RS_LT_00044]

The Offset field is a signed integer field with at least 32 bit. If the TYLE equals 4 the Offset field shall be a 64 signed integer field and if the TYLE equals 5 the Offset field shall be a 128 signed integer field.

[PRS_Dlt_00358]

[RS_LT_00044]

The length of Data shall depend on Type Length (TYLE).

[PRS_Dlt_00370]

[RS_LT_00044]

The Data Payload of Type Signed (SIGN) and of Type Unsigned (UINT) shall be assembled as shown in Table 5-3.

Type Float (FLOA)

[PRS_Dlt_00390]

[RS_LT_00044]

If the bit Type Float (FLOA) is set, the Data Payload shall consist of at least one Data field, which shall be interpreted as a float value in binary representation according to IEEE 754-2008.

Variable Info (VARI) is optional.

[PRS_Dlt_00145]

[RS_LT_00044]

Type Length (TYLE) shall be set to 2, 3, 4 or 5 as specified in IEEE 754:2008:

[PRS_Dlt_00362]

[RS_LT_00044]

If Variable Info (VARI) is set, the “Length of Name”, “Length of Unit”, the “Name” and the “Unit” fields shall be added.

[PRS_Dlt_00363]

[RS_LT_00044]

The length of Data shall depend on Type Length (TYLE).

[PRS_Dlt_00371]

[RS_LT_00044]

The argument of Type Float (FLOA) shall be assembled as shown in Table 5-4.

Type String (STRG)

[PRS_Dlt_00420]

[RS_LT_00025]

If the bit Type String (STRG) is set, the Data Payload shall consist of at least one Data field, which shall be interpreted as a string variable.

[PRS_Dlt_00156]

[RS_LT_00025]

At the beginning of the Data Payload, a 16-bit unsigned integer specifies the length of the string (provided in the Data field) in byte.

Note:

The string end is only defined by this length information.

[PRS_Dlt_00157]

[RS_LT_00025]

If Variable Info (VARI) is set, the “Length of Name” and the “Name” fields shall be added.

[PRS_Dlt_00373]

[RS_LT_00025]

The Data Payload of Type String (STRG) shall be assembled as shown in following table.

Note:

The Data string end is only given by the "Length of string" information.

Type Array (ARAY)

[PRS_Dlt_00147]

[RS_LT_00044]

If the bit Type Array is set, the Data Payload shall consist of an n-dimensional array of one or more data types of bool (BOOL), signed integer (SINT), unsigned integer (UINT) or float (FLOA) data types. The TYLE field and FIXP field shall be interpreted as in the standard data types.

[PRS_Dlt_00148]

[RS_LT_00044]

At the beginning of the Data Payload a 16-bit unsigned integer shall specify the number of dimensions of the array.

[PRS_Dlt_00149]

[RS_LT_00044]

If Variable Info (VARI) is set, the name of the array shall be described.

[PRS_Dlt_00150]

[RS_LT_00044]

Within the loop over the number of dimensions, a 16-bit unsigned integer shall specify the number of entries in the current dimension.

[PRS_Dlt_00152]

[RS_LT_00044]

If Variable Info (VARI) is set, the "Length of Name", "Length of Unit", the "Name" and the "Unit" fields shall be added.

[PRS_Dlt_00153]

[RS_LT_00044]

If Fixed Point (FIXP) bit is set in the Type Info, the quantization and offset for the entry in the array shall be added. It is only possible to use the same fixed-point calculation for all entries in the array.

[PRS_Dlt_00372]

[RS_LT_00044]

The Data Payload of Type Array (ARAY) shall be assembled as shown in following table.

Type Struct (STRU)

If this bit is set, structured data are transmitted.

[PRS_Dlt_00175]

[RS_LT_00044]

At the beginning of the Data Payload a 16-bit unsigned integer shall specify the number of entries of the structure or the object.

[PRS_Dlt_00176]

[RS_LT_00044]

If Variable Info (VARI) is set, the “Length of Name” and the “Name” fields shall be added.

[PRS_Dlt_00177]

[RS_LT_00044]

The list of entries contains one or more standard arguments with Type Info and Data Payload. All standard argument types are allowed.

[PRS_Dlt_00414]

[RS_LT_00044]

The Data Payload of Type Struct (STRU) shall be assembled as shown in following table.

Type Raw (RAWD)

If this bit is set, the Data Payload describes raw data. Variable Info (VARI) is optional.

[PRS_Dlt_00364]

[RS_LT_00044]

If Variable Info (VARI) is set, the coding of the name shall be with 8-bit characters where each character is within valid range of ASCII character set.

[PRS_Dlt_00160]

[RS_LT_00044]

At the beginning of the Data Payload a 16-bit unsigned integer shall specify the length of the raw data in byte.

[PRS_Dlt_00161]

[RS_LT_00044]

If Variable Info (VARI) is set, the “Length of Name” and the “Name” fields shall be added. The interpretation of the Data field in the case of a Raw argument cannot be done. Some tools can show this data by a user defined data type.

[PRS_Dlt_00374]

[RS_LT_00044]

The Data Payload of Type Raw (RAWD) shall be assembled as shown in following table.

Type Trace Info (TRAI)

Trace info is a separate argument in the Dlt message.

[PRS_Dlt_00170]

[RS_LT_00044]

If the bit Trace Info (TRAI) is set, the trace information (like module name / function) shall be transmitted in the argument.

[PRS_Dlt_00172]

[RS_LT_00044]

At the beginning of the Data Payload, a 16-bit unsigned integer shall specify the length of the trace data string in byte.

[PRS_Dlt_00173]

[RS_LT_00044]

The trace data string without a special terminating item like the NUL-character (\0) shall follow.

Note:

Type Format (TYFM) specifies the coding of the trace data string

[PRS_Dlt_00375]

[RS_LT_00044]

The Data Payload of Trace Info (TRAI) shall be assembled as shown in following table.

Example of representation of natural data type argument

The following example shows the assembly of an 8-bit unsigned integer argument with Variable Info (VARI) bit set in verbose mode.

The Type Info is a 32-bit field that describes the Data. In this example, it defines the variable type (unsigned integer), its length (8 bit) and the presence of Variable Info (VARI) that describes the name and unit of the variable.

Variable Info is following with two 16-bit unsigned integers describing the length of the Name and the Unit of the variable.

Two strings follow that describe the Name and the Unit.

Finally, the variable value follows. The length of the Data field is 8 bit.

List of different Type Info field bit combinations

The following table shows all combinations of valid settings in Type Info sorted according to the bit position in Type Info. Consider:

x – mandatory for this type,

x(1) – mandatory in case array consists of type for which TYFM respectively TYPR is mandatory,

x(2) – mandatory in TypeInfo for struct sub-elements in case those consists of types for which TYFM respectively TYPR is mandatory,

(x) – mandatory: an ARAY consists of elements from one of that types;

– optional,

empty – (not allowed for this type)

The following table shows the mandatory (marked with x) and optional (marked with o) setting according to used variable type:

Using the Verbose Mode helps to understand, analyze and debug the application.

Message types

Data Messages

Dlt Data Messages are assembled as described in chapter 5.1 “Message format”.

Control Messages

Dlt Control Messages are mainly used to modify the behavior of the Dlt module at runtime. They allow things like changing the communications bus to send Dlt data messages, modifying the filter level, configuration can be triggered to be stored nonvolatile.

Services / Commands

The following chapters describe the defined Dlt Commands, including an unique ID (Service ID), the format, and the required parameters.

[PRS_Dlt_00635]

[RS_LT_00032]

The following Dlt Commands using the following Services IDs shall be supported:

Note:

It is recommended that the defined Dlt Commands can be triggered by the reception of the corresponding Dlt Control Message, and/or via separate C APIs.

[PRS_Dlt_00187]

[RS_LT_00032]

Control messages are normal Dlt messages with a Base Header, an optional Extension Header, and a payload. The payload consists of one or more tuples of the Service ID, transmitted as 32-bit unsigned integer and the contained parameters.

Note:

For most of the Commands, the Extension Header is not needed (Fig. 15). It is needed e.g. for the "Call SWC Injection" command.

[PRS_Dlt_01040]

[RS_LT_00032]

Usage of NOAR in Control Messages

If a Control Message is sent, the Base Header field "NOAR" (Number of arguments) shall contain the number of Service IDs / Commands sent in that Control Message.

[PRS_Dlt_01041]

[RS_LT_00032]

Avoid overlapping requests or responses for a single Service ID

If there exists a specified response to a certain request / Service ID, each request shall be responded before the next request for the same Service ID is allowed to be sent out.

[PRS_Dlt_01042]

[RS_LT_00032]

Order of request execution and response

If a Control Message is sent with more than one Service IDs / Commands ("NOAR" > 1), the requests shall be executed in the same sequence as in the Control Message. The response for one request shall be generated, before the next request is processed. The responses to the commands shall be sent in the same sequence as in the request Control Message.

Note:

The generated responses can be sent all in one Control Message again ("NOAR" > 1) or can be split into more Control Messages.

If one Control Message contains for example

Request "GetLevel_x";

Request "SetLevel_x";

Request "GetLevel_x";

the result in the response needs to be:

Response "GetLevel_x = old level";

Response "SetLevel_x = OK for new level ";

Response "GetLevel_x = new level ";

Set Log Level

[PRS_Dlt_01057]

[RS_LT_00032]

[PRS_Dlt_00194]

[RS_LT_00032]

[PRS_Dlt_00195]

[RS_LT_00032]

Action to process:

Update the LogLevel setting within the Dlt module and inform all registered Applications with the Application ID which has been provided by the Dlt_SetLogLevel service.

Set Trace Status

[PRS_Dlt_00196]

[RS_LT_00032]

[PRS_Dlt_01058]

[RS_LT_00032]

Get Log Info

[PRS_Dlt_00197]

[RS_LT_00032]

[RS_LT_00033]

[PRS_Dlt_01059]

[RS_LT_00032]

Get Default Log Level

[PRS_Dlt_00198]

[RS_LT_00032]

Store Configuration

[PRS_Dlt_00199]

[RS_LT_00032]

[RS_LT_00039]

Reset to Factory Default

[PRS_Dlt_00200]

[RS_LT_00032]

Set Message Filtering

[PRS_Dlt_00205]

[RS_LT_00040]

Set Default LogLevel

[PRS_Dlt_00380]

[RS_LT_00032]

[PRS_Dlt_00381]

[RS_LT_00032]

Action to process: Update the LogLevel filter for all wildcard entries according to the provided newLogLevel.

Set Default Trace Status

[PRS_Dlt_00383]

[RS_LT_00032]

Get ECU Software Version

[PRS_Dlt_00393]

[RS_LT_00032]

Get Default Trace Status

[PRS_Dlt_00494]

[RS_LT_00032]

Get LogChannel Names

[PRS_Dlt_00502]

[RS_LT_00032]

Get Trace Status

[PRS_Dlt_00638]

[RS_LT_00032]

[PRS_Dlt_01060]

[RS_LT_00032]

Set LogChannel Assignment

[PRS_Dlt_00637]

[RS_LT_00032]

[PRS_Dlt_01061]

[RS_LT_00032]

Set LogChannel Threshold

[PRS_Dlt_00639]

[RS_LT_00032]

Get LogChannel Threshold

[PRS_Dlt_00640]

[RS_LT_00032]

BufferOverflowNotification

[PRS_Dlt_00769]

[RS_LT_00037]

Call SWC Injection

[PRS_Dlt_00217]

[RS_LT_00032]

CallSWCInjection messages shall be forwarded to the according application. The Service ID 0xFFF to 0xFFFFFFFF are reserved for this purpose. The value is user defined and can be freely used by an application.

[PRS_Dlt_00218]

[RS_LT_00032]

In the case of a CallSWCInjection message, the Application ID (APID), Context ID (CTID) and the Session ID (SEID) shall be filled in the header. The pair of APID and CTID together with the SEID identifies a unique client server interface of an application/runnable which is called in respect to reception of this message with the provided data.

[PRS_Dlt_00219]

[RS_LT_00032]

If a unique identification is not possible (this pair does not exist, is not registered yet) the response shall be NOT_SUPPORTED.

[PRS_Dlt_00220]

[RS_LT_00032]

DLT Commands (deprecated)

[PRS_Dlt_00641]

[RS_LT_00002]

The following Dlt Commands are deprecated and not supported any more:

0x07 SetComInterfaceStatus

0x08 SetComInterfaceMaxBandwidth

0x09 SetVerboseMode

0x0C GetLocalTime

0x0D SetUseECUID

0x0E SetUseSessionID

0x0F SetUseTimestamp

0x10 SetUseExtendedHeader

0x14 MessageBufferOverflow

0x16 GetComInterfacelStatus

0x18 GetComInterfaceMaxBandwidth

0x19 GetVerboseModeStatus

0x1A GetMessageFilteringStatus

0x1B GetUseECUID

0x1C GetUseSessionID

0x1D GetUseTimestamp

0x1E GetUseExtendedHeader

0x24 SyncTimeStamp

External Client / Tool

Extensions for storing in a database/file

The Dlt module can leave out some information in the header like the ECU ID. Therefore, it is important to store some additional information by the receiving external client.

For additionally storing useful information like the timestamp of the receiver and the ECU ID a Storage Header shall be added in front of every received Dlt message.

Because the ECU ID can be omitted by the sending Dlt side, the receiver shall add this information at receiving time. The Timestamp is also for a better calculation of sequences and timely dependencies by a diagnostic and visualization tool.

Additionally at the beginning of the Storage header a pattern shall be attached. This pattern is for some error recoveries if the byte-stream or file is broken.

[PRS_Dlt_00405]

[RS_LT_00002]

An external client shall add the Storage Header to a received Dlt message before it stores the message.

Note:

The Storage Header is applied to Data Messages (Verbose Mode and Non-Verbose Mode) and to Control Messages.

[PRS_Dlt_00427]

[RS_LT_00002]

The first entry in the Storage Header shall be a pattern 0x 44 4C 54 02 (“DLT”+0x2).

[PRS_Dlt_00404]

[RS_LT_00002]

If an external client receives a message it shall store the time when it receives the message additionally to the message in the storage header.

[PRS_Dlt_00292]

[RS_LT_00002]

If an external client receives a message it shall store the ECU ID when it receives the message additionally to the message in the storage header.

Sequences (lower layer)

States

N /A – The Dlt Protocol does not specify any states.

Control flow / Transitions

Transmission of Dlt Data Message

Set LogLevel Filter

Buffer Overflow

Error Handling

Error messages

Buffer Overflow

[PRS_Dlt_00648]

[RS_LT_00037]

If a Dlt Message Buffer Overflow occurs, the Control Message with the Service ID 0x23 (BufferOverflowNotification) shall be sent.⌋ ()

Note:

The Service BufferOverflowNotification is defined in chapter 5..3.

[PRS_Dlt_00649]

[RS_LT_00037]

The status of the Dlt Message Buffer shall be cyclically checked. The minimum time interval of sending the Dlt Overflow Message shall be configurable, i.e.: do not send more than one Dlt Overflow Message within the configured time span. ⌋ (RS_LT_00037)

Answering a Command with “ERROR”

[PRS_Dlt_00650]

[RS_LT_00032]

The Dlt module shall answer a Dlt Command with “ERROR” if one of the following cases:

At least one of the received parameter values cannot be matched to the current configuration

Another Dlt Command is currently in progress

[PRS_Dlt_00642]

[RS_LT_00032]

If the Dlt module receives a Dlt command using a Service ID which is neither specified in chapter “Dlt Command” nor in chapter “Dlt Commands (deprecated)”, the Dlt module shall answer with “ERROR”.

Answering a Command with “NOT SUPPORTED”

[PRS_Dlt_00644]

[RS_LT_00032]

The Dlt module shall respond with “DLT_NOT_SUPPORTED” if it receives one of the following Dlt Commands:

0x07 SetComInterfaceStatus

0x08 SetComInterfaceMaxBandwidth

0x09 SetVerboseMode

0x0A SetMessageFiltering

0x0C GetLocalTime

0x0D SetUseECUID

0x0E SetUseSessionID

0x0F SetUseTimestamp

0x10 SetUseExtendedHeader

0x14 MessageBufferOverflow

0x16 GetComInterfacelStatus

0x18 GetComInterfaceMaxBandwidth

0x19 GetVerboseModeStatus

0x1A GetMessageFilteringStatus

0x1B GetIseECUID

0x1C GetUseSessionID

0x1D GetUseTimestamp

0x1E GetUseExtendedHeader

Error resolution

Transmission Retry

[PRS_Dlt_00651]

[RS_LT_00030]

In case an error occurred while trying to send a Dlt Message on the bus, the Dlt module shall re-try to send it. The maximum amount of transmission retries shall be configurable.

Note:

This is not part of the Dlt Protocol itself, but recommended for the implementation of the Dlt Module.

Protocol usage and guidelines

Proposal for usage of Log Levels

The log levels as defined in 5.1.1.4 Conditional "Message Info" by PRS_Dlt_00619 bear an implied semantics. This section gives a recommendation on how to use different log levels, i.e. which kind of event should be reported by which log level. However, this section is purely informational. That is, the log message producer SHOULD comply to this section but MAY choose to imply a different semantics. Also, the log message consumer SHALL NOT derive actions from messages of certain log levels without additional agreement (e.g. by negotiating a common profile by different means).

Log Level FATAL (DLT_LOG_FATAL)

Fatal, unrecoverable error. Accordingly, these messages should occur on very rare occasions. The whole (sub-)system's stability might be endangered. Should be used before a (sub-)system enters a failsafe state (e.g. emergency shutdown) or if it encounters an error that will most likely cause an imminent crash. Often the last message a (sub-)system can log.

Examples:

a corrupted boot environment

a hardware component that is vital for (sub-)system startup fails or is missing

a critical application, service or other software component exited unexpectedly

may also be used if an application exits due to a fatal error

Log Level ERROR (DLT_LOG_ERROR)

Errors denote conditions that will cause the (sub-)system to stop working correctly but that might be recoverable.

Examples:

missing or failing non-vital services, applications or other software components

hardware on which an application depends is inaccessible

a network connection that is required for correct functionality is failing

a required file is missing, inaccessible or corrupted

Log level WARNING (DLT_LOG_WARNING)

Used if correct behavior cannot be ensured. Something that's concerning but not causing the operation to abort. The condition might become a problem in the future resulting in an error, or might not. Runtime situations that are undesirable, unexpected and potentially lead to an error or cause application oddities, but everything still under control. Automatic recovery from the situation exists (e.g. a handled exception) and the application can continue. Warnings may give hints at the root cause of subsequent errors.

Examples:

bad login attempts

unexpected data during import jobs

switching from a primary to backup server

short loss of network or database connectivity as long as it does not inevitably result in faulty behavior

number of resources in a pool getting low

an unusual-but-expected timeout in an operation

not enough disk space for a core dump

processes exceed their maximum execution time as per specification

Log level INFO (DLT_LOG_INFO)

Should give an overview of major state changes providing high level context for understanding any warnings or errors that also occur. It can be used on runtime events that are normal but somehow important.

Examples:

key system and hardware information on startup / shutdown

startup / shutdown of an application

successful initialization

a long running job is starting and ending

successful completion of significant transactions

entries and exits from key areas of an application

external devices connected / detached (e.g. USB drives)

errors or connection loss of connected devices that do not affect the system's stability (e.g. mobile phones, multimedia devices, ...)

information vital for determining key performance indicators (KPI)

Log level DEBUG (DLT_LOG_DEBUG)

Fine-grained debug-level messages. Detailed, diagnostically helpful, information for programmers, normally of use only when debugging a program. This and below log levels should only be used for development and testing and disabled for production systems.

Examples:

entry and exit points into functions

function parameters passed

values, value changes or state changes of key variables, usually not complete array dumps though

return values

information about received events

network connection information

debugging information of connected hardware

other significant information to reconstruct the flow through the system

Log level VERBOSE (DLT_LOG_VERBOSE)

Even more fine-grained information than DEBUG. Should be used for in-depth debug information.

Examples:

dump of buffers, arrays or memory segments

information about loops and iterations

detailed network information

detailed hardware state information

Configuration specification

Base Header

Header Type 2 (HTYP2)

Message Info (MSIN)

Extension Header

PRS_Dlt

RS_LT