AIDA EOLTest Component

The EOLTest component implements a simple transport protocol mainly used at the end of the production line for testing the ECU hardware components. For further details refer to the SiemensVDO document "End Of Line Protocol". The EOLTest component is intended to be used together with a CAN component.

Communication with the ECU can be done in two modes, Activation/Unlock or EOL mode. These modes can use different bitrates on the CAN bus. As switching of CAN bitrates can only be done in offline state, switching between the two communication modes requires forcing parts of the stack temporary to offline state by the component.

The EOLTest component checks a transmit data event for ActivationServiceID and ResetSequenceEOL as well as for the flags AIDA_nStartCommu and AIDA_nStopCommu.
To try to activate the EOL mode, a transmit data event with the flag AIDA_nStartCommu or the ActivationServiceID has to be sent. If the flag AIDA_nStartCommu is set, the component continously tries to send in intervals of IntervalActivation until TimeoutActivation is reached or a definitive answer is received.
If Data in the event corresponds to the UnlockMessage and the flag AIDA_nStartCommu is set, the UnlockMessage and the activation message are sent alternating in intervals of IntervalActivation until TimeoutActivation is reached or a definitive answer is reached.
To deactivate the EOL Mode, a transmit data event with the flag AIDA_nStopCommu or the ResetSequenceEOL has to be sent. Feedback about switching to EOL mode is provided by transmit data done events containing the AIDA_nCommuStarted flag, for switching back from EOL mode to activation mode the AIDA_nCommuStopped flag will be set in an event. The transmit data done event also signalizes that the possible switching of bitrates on the CAN bus is finished. As this switching might take some time, the application or higher components are informed of the possible delay by status events.

As the state of the component regarding the mode of communication (Activation/Unlock or EOL mode) is preserved over switching the stack offline, another method of directly setting the mode of communication is provided. This might e.g. be necessary if the ECU is reset by other means, like switching off its power.
With AIDA_bDataFlags in transmit data events containing no data, the communication mode of the EOLTest component can be set (see header file bsk_aida_eoltest.h). With the flag EOLTEST_nMSGFLAG_CLREOL (0x01) the EOLTest component is switched to Activation/Unlock mode, with the flag EOLTEST_nMSGFLAG_SETEOL (0x02) the component is switched to EOL mode. Also the speed of the CAN bus might be switched.

In EOL Mode, adding of length and checksum bytes in transmit data events can be suppressed by the flag EOLTEST_nMSGFLAG_IMAGEDATA (0x04) in the AIDA_bDataFlags. In this case, the length and checksum information already in the data is checked for consistency, possible additional footer data after the checksum is omitted from the transmission.
With this flag set, the complete data of e.g. existing toolbox files can be copied into the data referred by pvData of a transmit data event without modification.

To avoid flooding of the CAN cell when no ECU is connected, specific AIDA_bDataFlags of the CAN component are monitored. This has been successfully tested only with a CAN board from Vector Informatik.

To cover possible variations in the future, some of the fixed specifications were made parametrizable. Default values represent the current specifications.

Parameters

BitrateActivation: The bit rate after reset of the ECU in [bits/s]. This rate is used for the activation, lock and unlock of the EOL mode. This parameter controls the Bitrate parameter of the CAN component.
BitrateEOL: The bit rate in [bits/s] during EOL mode. This parameter controls the Bitrate parameter of the CAN component.
ReceiveID: The ID on the CAN bus expected for messages to be received from the ECU. This parameter controls the AcceptanceCode parameter of the CAN component.
SendID: Default id to be used on CAN bus when the source id of a transmit data event is not set. This parameter controls the SendID parameter of the CAN component.
ActivationServiceID: Service ID to activate / lock the EOL mode. First byte of the Activation / Lock Request message. Default value is 0x84.
EOLLocalID: EOL Local ID. Second byte of the Activation / Lock Request message.
BitrateEOLCode: Code to specify bitrate for EOL mode in the ECU. Third byte of the Activation / Lock Request message.
Note: Should match to BitrateEOL. Different encodings from bitrate to code byte exist for different ECUs, so no fix relation had been programmed into the component.
ReservedIDActivation: Value of data byte marked as reserved. Fourth byte of the Activation / Lock Request message. Default value is 0x00.
ActivationAnswerSuccess: Answer to successfull activation of the EOL mode. The default is ActivationServiceID, 0x84, but for KWP2000-like environments, the value 0xC4 has been seen.
InvalidAnswer: Answer, if activation of the EOL mode failed because of wrong service ID, or to an unlock command, when not in locked mode. Default value is 0x12.
InvalidBitrateAnswer: Answer, if activation of the EOL mode failed because of an invalid bit rate requested(BitrateEOLCode unsupported in ECU). Default value is 0x22.
UnlockMessage: Sequence of bytes to unlock the EOL mode. The parameter is entered as a string of hexadecimal values without any spaces.
IntervalActivation: Specifies the time interval in [ms], in which activation requests are sent, if no answer from the ECU is received.
TimeoutActivation: Specifies how long in [ms] the component tries to activate the EOL mode.
SwitchTimeEOL: Specifies how long in [ms] the component waits with transmission of the first telegram after successfull activation of the EOL mode.
LengthWidthEOL: Number of bytes used for the representation of the length information in EOL mode. If more than one byte is used, the LSB will be the first byte of the transmission. The default value is 2.
LengthOffsetEOL: Offset to be added to the length of the telegram to calculate the length information included in the header in EOL mode. The default value is -2.
ChecksumModeEOL: Specifies how the checksum is calculated in EOL mode. The ChecksumModeEOL 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.
ChecksumWidthEOL: Number of bytes used for the representation of the checksum in EOL mode.
ChecksumStartOffsetEOL: Specifies how many bytes from the start are ignored for the calculation of the checksum in EOL mode.
AnswerTimeoutEOL: Specifies how long in [ms] the component waits for the reception of the first CAN message after sending to the ECU.
RxIntermessageTimeoutEOL: Specifies how long in [ms] the component waits between CAN messages received from the component below (from end of reception of one CAN message to the end of reception of the next CAN message).
TxIntermessageTimeoutEOL: Specifies how long in [ms] the component waits between sending of CAN messages.
RetriesEOL: Maximum number of retries in the EOL mode.
ResetSequenceEOL: Sequence of bytes to perform a reset of the ECU in EOL mode, including the Escape code. The parameter is entered as a string of hexadecimal values without any spaces.
Mode: Current communication mode. Possible Values are: EOLTEST_nMODE_ACTIVATION (0) for Activation/Unlock mode and EOLTEST_nMODE_EOL (1) for EOL mode.
UseFastEchoQueue: Use a queue mechanism to improve throughput in EOL mode for events not fitting into one CAN telegram. Possible Values are: 0 Safe mode, wait for successfull transmission of every CAN telegram, 1 Use Queue to get faster response but this might cause problems like changed sequence of CAN telegrams.
This parameter was introduced in version 1.02.004.06 (prerelease) of the AIDA-Stacks with a default value of 0. AIDA-Stack versions from 1.02.003.04 to 1.02.004.05 always used the queue mechanism.
NoStrictLengthCheck: For segmented data quietly ignore data in last telegram after calculated end from internal length info. Possible values are: 0 Strict check, set error flags for inconsistent length info, 1 Quietly ignore inconsistencies and skip additional data after expected end.
This parameter was introduced in version 1.02.004.09 of the AIDA-Stacks with a default value of 0. AIDA-Stack versions up to 1.02.004.08 for segmented data always ignored extra bytes in the last telegram without generating an error flag. This parameter should only be set to 1, if compatibility with former stack versions is absolutely necessary.
AllowLengthExtensionSend: Allow Frame Length Extension mechanism when sending EOL data. Possible values are: 0 Don't allow Frame Length Extension mechanism, 1 Allow Frame Length Extension mechanism.
This parameter was introduced in version 7.00.004.03 (prerelease) of the AIDA-Stacks with a default value of 0. AIDA-Stack versions up to 7.00.004.02 couldn't handle the Frame Length Extension mechanism. This parameter is saved in the configuration file only when set to 1 so older component versions can still be used with the configuration file, when this feature is not needed.; Maximum Size for data using Extenteded Frame Length mechanism. Used as a soft barrier in order to prevent Out of Memory problems.
This parameter was introduced in version 7.00.004.03 (prerelease) of the AIDA-Stacks with a default value of 10000000. AIDA-Stack versions up to 7.00.004.02 couldn't handle the Frame Length Extension mechanism. This parameter value is saved in the configuration file only when set different from the default value, so older component versions can still be used with the configuration file, when this feature is not needed.

AIDA EOLTest Component

Parameters

See Also