AIDA BDiag Component

The BDiag component is used to give the functionality known from the BSK diagnostics. It creates and checks telegram headers and checksums. Numbering of positions starts with 1, values ≤ 0 mean that the corresponding parameter is not present in the header. Exceptions from this rule are ECUAddressPos and LengthAddressPos, see below.

Parameters

HeaderFlags (Broadcast Parameter)

Field of flags for special treatment of the header.

0x0000000FUL	SpecialModeMask	these bits are reserved for modes which require special treatment of the header (e.g. KWP 2000).
0x00000030UL	BroadcastModeMask	these bits are reserved for broadcast modes.
0x00000040UL	ExcludeFrameLengthMask	this bit is used for the calculation of the length information in the header.
0x00000040UL	ExcludeFrameLength	when set indicates, that the length of the frame is excluded from the calculation of the telegram length.

The currently implemented special modes are:

0x00000000UL	SpecialModeNone	There is no special treatment.
0x00000001UL	SpecialModeKWP2000COM	KWP2000 headers are used as defined in ISO 14230.
0x00000002UL	SpecialModeKWP2000CAN	KWP2000 over CAN is used. (2 byte header with 12 bit length info).
0x00000003UL	SpecialModeDS2	The ECU ID is generated as described in DS2 documentation (currently unimplemented).

When a KWP2000 mode is selected, other parameters are modified according to the specs and can't be changed by the user anymore. These parameters are: ECUAddressWidth, ECUAddressPos, TesterAddressPos, LengthWidth, LengthPos, LengthOffset, LengthMask, SpecialCode and SpecialCodePos. Parameters concerning the checksum are not automatically modified.
When the DS2 mode is selected ECUAddressWidth is always set to 1, TesterAddressPos is always set to 0 (no tester address).
The currently implemented broadcast modes are:

0x00000000UL	BroadcastModeNone	No broadcast mode.
0x00000010UL	BroadcastModeOne	Indicates that all ECU addresses in answers are accepted when the event is sent to the ECU address given in ECUBroadcastAddress.
0x00000020UL	BroadcastModeAll	Indicates that always all ECU addresses in answers are accepted.

ECUAddressWidth

Specifies the width of the ECU address. The default value is 1.

ECUAddress

Address of the ECU to communicate with.

ECUBroadcastAddress

ECU address used for broadcasts.

ECUAddressPos

Position of the ECU address in the telegram. Numbering starts with 1, a value of 0 means that the ECU address is at the first position of the telegram (To be compatible with parameters used in BSKD). Values < 0 mean, that there is no ECU address in the telegram header.

TesterAddress

Address of the Tester.

TesterAdressPos

Position of the Tester address. Numbering starts with 1, values ≤ 0 mean, that there is no Tester address in the telegram. If TesterAddressPos = ECUAddressPos, both addresses are merged into one byte. For telegrams sent to the ECU the ECU address part is in the high nibble and the tester address part is in the low nibble of this byte. For telegrams received from the ECU these positions are swapped, meaning the ECU address part is in the low nibble and the tester address part is in the high nibble of this byte.

LengthWidth

Specifies how many bytes are used to transmit the telegram length.

LengthPos

Specifies the position of the length information in the telegram. A value of 0 means, that the length information follows directly after the ECU address information, values < 0 mean, that there is no length information in the header.

LengthOffset

Offset to be added to the length of the telegram to calculate the length information included in the header.
If ExcludeFrameLength in the HeaderFlags is set:

telegram length (excluding header and checksum) + LengthOffset = length information in the telegram

If ExcludeFrameLength in the HeaderFlags is not set:

telegram length (including header and checksum) + LengthOffset = length information in the telegram

LengthMask

Mask to be used when merging length information and other information (e.g. like in the Format byte of KWP2000). If the Mask = 0 it is ignored, otherwise bits set in the mask mark this area as useable for the length information(The LengthMask is anded bitwise with the calculated length). The LengthMask doesn't imply any bit shifts.

SpecialCode

This Code can be inserted into the telegram either for error testing purposes or to be combined with length information and the LengthMask to generate headers according to KWP2000.

SpecialCodePos

The Position, where the SpecialCode is inserted into the telegram. Values ≤ 0 mean, that there is no SpecialCode in the telegram. If SpecialCodePos = LengthPos then the length information is ored bitwise with SpecialCode and inserted into the header. The LengthWidth parameter controls how many bytes are used. In order to extract the correct length information when analyzing and removing the headers, the LengthMask parameter should be set, that SpecialCode & LengthMask = 0.

ChecksumMode

Specifies how the checksum is calculated. The ChecksumMode is bit orientated, bit 0 determines the main mode, 0 stands for an exclusive-or generated checksum, 1 for a summation over the data.
The higher bits determine modifications of the main mode.
If bit 1 is set, 1 is added to the previously calculated checksum.
If bit 2 is set, the bits in the previously calculated checksum are inverted.
If bit 3 is set, the previously calculated checksum is negated.

ChecksumWidth

Specifies how many bytes are used for the representation of the checksum. If set to 0, no checksum is calculated.

ChecksumStartOffset

Specifies how many bytes from the start are ignored for the calculation of the checksum.

Direction

Specifies in which direction the telegram frame should be added. If this is set to 0 the telegram frame is added for telegrams sent and checked/removed for telegrams received. If this value is set to 1 telegram frames are added for received telegrams and checked/removed for telegrams sent.

KWP2000Flags

Field of flags for special treatment of the KWP2000 headers. Information contained in the key bytes as defined in ISO 14230-2 Section 5.1.5.1. are stored in this parameter. It specifies, which kind of length information and if source/target information should be included in the generated header.

0x00000001UL	KWP2000KeyBytesAL0	length information in format byte supported
0x00000002UL	KWP2000KeyBytesAL1	additional length byte supported
0x00000004UL	KWP2000KeyBytesHB0	1 byte header supported
0x00000008UL	KWP2000KeyBytesHB1	Target/Source address in header supported
0x00000010UL	KWP2000KeyBytesTP0	extended timing parameter set
0x00000020UL	KWP2000KeyBytesTP1	normal timing parameter set

If KWP2000KeyBytesAL0 .. KWP2000KeyBytesHB1 = 0 then the BDiag component uses defaults.
The KWP2000KeyBytesTP0 and KWP2000KeyBytesTP1 are provided for completeness only and have no direct effect on the timing of the BDiag component !
There is also a mask available:

0x0000003FUL

KWP2000KeyBytesMask

Retry

Specifies how many retries should be taken to get an answer.

IdleTime

Specifies how long the tester waits after the last transmission until it starts sending a new request. Units used are ms.

AnswerTimeout

Specifies how long the tester waits for an answer from the ECU. Units used are ms.

ExtendedAnswerTimeout

Specifies how long the tester waits for an answer from the ECU after it has received a "Busy, Response pending" answer. This action is triggered, when the matching Control Byte has set the ControlByteFixTOExtend-Flag in the Fix Control Bytes. Units used are ms.

RepeatDelayTime

Specifies how long the tester waits to send a new request after it has received a "Busy, Repeat request". This action is triggered, when the matching Control Byte has set the ControlByteFixRetryDelayed-Flag in the Fix Control Bytes. Units used are ms.

EchoSuppression

Specifies, if an echo of the transmitted data is expected before the answer in this stack level. Please remember, that an echo already suppressed in a stack level nearer to the hardware doesn't proceed to this level. It can't and mustn't be suppressed twice.

0x00000000UL		No echo is expected.
0x00000001UL	EchoSuppressOn	An echo is expected and suppressed.

BusMode

Specifies, how telegrams, which don't fit to the request are treated.

0x00000000UL		No other telegrams are expected. A telegram, which doesn't fit to the request is considered as an error. It may trigger a retry, depending on the settings of other parameters.
0x00000001UL	BusModeOn	All telegrams, which don't fit to the request are considered as other communication on the bus and are discarded. The component waits further until an answer arrives, which does fit to the request or a timeout occurs.

ExpectedAnswers

Specifies the number of answers, after which the component assumes that no more answers follow. If this value is set to 0 the component always waits for the timeout. If this parameter is set to a value greater or equal than 1 BDiag acts as follows: When an answer is received BDiag tests if ExpectedAnswers is greater than 1. If yes ExpectedAnswers is decremented and BDiag waits for the next response. When a timeout occurs ExpectedAnswers is immediately reset to 1. ExpectedAnswers should not be mistaken for the number of bytes in the answer.

ControlByteFlags

Specifies how the expected control byte in the answer from the ECU is derived from the control byte in the message to the ECU.

0x00000001UL	ControlByteEqual	The control byte in the answer should be the same as in the request.
0x00000002UL	ControlByteNot	All bits of the answer control byte inverted as compared to the request are interpreted as a Negative Response.
0x00000004UL	ControlByteAny	Any control byte is accepted in the answer.

The next two flags can be combined with the main modes ControlByteEqual and ControlByteNot to modify the expected answer.

0x00000020UL	ControlByteXor20	The expected answer control byte is derived by an XOR with $20 from the main mode.
0x00000040UL	ControlByteXor40	The expected answer control byte is derived by an XOR with $40 from the main mode.

FixControlByte00 .. FixControlByte19

These parameters can be used to specify actions to be taken if a specific fix control byte is found in a request or an answer. The dword parameter consists of the control byte itself and flags, which determine the actions to be taken, when this control byte is found. It is also possible to check for a response code and a subcode in an answer, or to modify the number of expected answers for a specific control byte.

Bit(s)	Mask/Value	Name	Description
31	0x80000000UL	ControlByteFixActive	When this flag is set this parameter entry is activated, otherwise the parameter is ignored.
30	0x40000000UL	ControlByteFixRequest	When this flag is set this parameter entry refers to the control byte in the request, otherwise to the one in the answer. Only the ControlByteFixTOExtend flag and bits in the ControlByteFixMultRespMask can combined with the ControlByteFixRequest flag.
29	0x20000000UL	ControlByteFixSubCodeActive	When this flag is set the subcode of the reply is evaluated together with the control byte (both have to match), otherwise just the control byte. The subcode byte is the last byte of data (before the checksum). This flag can not be set together with the ControlByteFixRequest flag.
28..16	0x1FFF0000UL	ControlByteFixCodes	This mask can be used to get just the flags part for the actions out of the complete dword parameter.
28	0x10000000UL	-	n. u.
27	0x08000000UL	ControlByteFixAbort	The tester should abort further retries or waiting for answers. This flag can not be used together with the settings ControlByteFixRetryNormal, ControlByteFixRetryDelayed, or ControlByteFixWaitAgain.
26	0x04000000UL	ControlByteFixTOExtend	If this flag is set, the tester should wait for the ExtendedAnswerTimeout, otherwise for the normal AnswerTimeout.
25..24	0x03000000UL	ControlByteFixRepeatMask	These bits are used to specify, which action should be taken after the expected answer has arrived. They are only evaluated if exactly 1 answer is expected (ExpectedAnswers = 1, or temporary overwritten by a request with ControlByteFixMultRespMask leading to a value of 1). The possible values are ControlByteFixOneAnswer, ControlByteFixRetryNormal, ControlByteFixRetryDelayed, and ControlByteFixWaitAgain.
25..24	0x00000000UL	ControlByteFixOneAnswer	The expected answer arrived, no further retries or waiting.
25..24	0x01000000UL	ControlByteFixRetryNormal	The tester should retry with a new request in compliance with the normal timing (Idle Time is evaluated).
25..24	0x02000000UL	ControlByteFixRetryDelayed	The tester should retry with a new request after the RepeatDelayTime.
25..24	0x03000000UL	ControlByteFixWaitAgain	The tester should wait again, without sending a new request.
23	0x00800000UL	-	n. u.
22	0x00400000UL	ControlByteFixNegResp	Negative response, e.g. Not Acknowledge. The AIDA_nNegativeResponse flag is set in the member dwFlags of the AIDA_tstEvent structure.
21	0x00200000UL	ControlByteFixBusy	ECU is busy. Reserved for future use.
20	0x00100000UL	ControlByteFixError	Error during execution in the ECU. Reserved for future use.
19..17	0x000E0000UL	-	n. u.
16	0x00010000UL	ControlByteFixAck	Acknowledge.
15..8	0x0000FF00UL	ControlByteFixSubCodeMask	This can be used to get just the subcode to evaluate of the reply out of the dword. The subcode byte has to be entered into this part of the parameter.
15..8	0x0000FF00UL	ControlByteFixMultRespMask	If the ControlByteFixRequest flag is set, these bits can be used to change the number of expected answers (Multiple Response Mode) for one fix control byte only. The value in the ExpectedAnswers parameter is temporary overwritten, if FixControlByteXX & ControlByteFixMultRespMask <> 0. The masked value is interpreted as a byte. After the request and the answers have been processed, the ExpectedAnswers parameter is reset to the value before the temporary change. The control bytes are evaluated after parameter attachments, so changes of the ExpectedAnswers parameter by means of temporary parameter attachments have no effect.
7..0	0x000000FFUL	ControlByteFixMask	This can be used to get the control byte out of the dword. The control byte has to be entered into this part of the parameter.

Examples:

0xA760787FUL	ControlByteFixActive    ControlByteFixSubCodeActive    ControlByteFixTOExtend    ControlByteFixWaitAgain    ControlByteFixNegResp    ControlByteFixBusy	A control byte of 0x7F together with a subcode of 0x78 is interpreted as a busy response from the ECU. The component waits for another response but with an ExtendedAnswerTimeout (KWP2000, 0x78=RCR-RP=reqCorrectlyRcvd-RspPending).
0xA260217FUL	ControlByteFixActive    ControlByteFixSubCodeActive    ControlByteFixRetryDelayed    ControlByteFixNegResp    ControlByteFixBusy	A control byte of 0x7F together with a subcode of 0x21 is interpreted as a busy response from the ECU. The component waits RepeatDelayTime until it resends the request and waits for a new response with AnswerTimeout (KWP2000, 0x21=B-RR=busy-repeatRequest).
0xA260237FUL	ControlByteFixActive    ControlByteFixSubCodeActive    ControlByteFixRetryDelayed    ControlByteFixNegResp    ControlByteFixBusy	A control byte of 0x7F together with a subcode of 0x23 is interpreted as a busy response from the ECU. The component waits RepeatDelayTime until it resends the request and waits for a new response with AnswerTimeout (KWP2000, 0x23=RNC=routineNotComplete).
0x8840007FUL	ControlByteFixActive    ControlByteFixAbort    ControlByteFixNegResp	A control byte of 0x7F is interpreted as a negative response (with no retry, KWP2000). Note that such an entry must be behind other entries with same control byte (e. g. for reqCorrectlyRcvd-RspPending), so in many KWP2000 stacks this is simply the last fix control byte entry.
0x80400015UL	ControlByteFixActive    ControlByteFixNegResp	A control byte of 0x15 is interpreted as a negative response from the ECU (BSKD protocol, 0x15=ASCII NAK).
0xC4000012UL	ControlByteFixActive    ControlByteFixRequest    ControlByteFixTOExtend	A control byte of 0x12 in the request leads to an ExtendedAnswerTimeout for the response from the ECU.
0xC0001400UL	ControlByteFixActive    ControlByteFixRequest    ControlByteFixMultRespMask	A control byte of 0x00 in the request leads to a temporary value of 20 (0x14) for the ExpectedAnswers.

See Also

AIDA Overview, list of AIDA components