AIDA TP 1.6 Component

The TP 1.6 component implements the AUDI/VW CAN transport protocol version 1.6. Most of the parameters are named in accordance with the protocol specification and are not described in further detail here. For any unknown/undescribed terms please refer to the document CAN-Transportprotokoll version 1.6.

General Information

The TP 1.6 component supports one transport channel. So in contrary to the TP 2.0 component the TP 1.6 component does not use any src or dst ids in AIDA events.

During the channel setup phase a mapping from a destination byte within the setup messages to a src id of the event and vice versa has to be done. The TP 1.6 component does allow this mapping only for one given set of ids. Since the mapping is manufacturer specific an additional mapper component may be added in future. Currently both channel setup ids (own and ECU) as well as both destination codes (own and ECU) have to be set. The TP 1.6 component will only establish a connection when both the CAN id and the destination code match with the parameters of the component.

All parameters used to specify an id or mask are 32 bits wide with only the lower 11 bits usable.

Note: Status events sent from a component above in order to open or close a transport channel without sending data are currently ignored.

Parameters

AutomaticChannelSetup

The parameter contains two bits, bit 0 for active channel setups (i. e. when AIDA events shall be sent) and bit 1 for passive channel setups (i. e. when an ECU tries to connect to the component).
When the corrsponding bit for the current type of channel setup is set to 1 the TP 1.6 component automatically opens the channel as needed. When set to 0 connection attemps from an ECU will be rejected or events sent to a closed channel will be returned as TransmitDataDone event with the Flags AIDA_nSendError and AIDA_nCommuStartError set. In this case the application has to set the AIDA_nStartCommu flag in the TransmitData event to open the channel.

IdleComm

The VWTP 1.6 lacks any specification of how to handle the situation where in case of a slow direction change the application does not deliver any transmit data while it has the transmission right (the original state machine simply "dies" in this case). The TP 1.6 component offers two possibilities as a workaround: When IdleComm is set to 1 or 2 the component automatically keeps an active channel open by sending empty telegrams as needed. The success of this measure depends on the VWTP implementation of the partner. The value selects the method of the data direction change (1 means fast DDC, 2 means slow DDC). When IdleComm is set to 0 the component will close the channel when no data for transmission arrives in time.

ChannelSetupTX

Specifies the source id used when sending channel setup or channel acknowledge messages.

ChannelSetupRX

Specifies the source id accepted for incoming channel setup or channel acknowledge messages. Note that for a message to be accepted both ChannelSetupRX and ChannelSetupRXDestination must match.

ChannelSetupTXDestination

Specifies the destination code to be inserted in outgoing channel setup or channel acknowledge messages.

ChannelSetupRXDestination

Specifies the destination code for incoming channel setup or channel acknowledge messages to be accepted. Note that for a message to be accepted both ChannelSetupRX and ChannelSetupRXDestination must match.

ChannelTX

This is the CAN id the component uses when sending transport messages. The low byte will be inserted in outgoing channel setup or channel acknowledge messages as channel id.

ChannelRX

This is the base CAN id the component accepts when receiving transport messages. The low byte will be replaced by the channel id of an incoming channel setup or channel acknowledge message.

MNT, MNTC, BS, T1TST, T2TST, T3TST, T4TST, T1ECU, T2ECU, T3ECU, T4ECU

These are the parameters of the TP 1.6 protocol the component uses. T1TST, T2TST, T3TST and T4TST correspond to T1, T2, T3 and T4 (from the component's point of view). T1ECU, T2ECU, T3ECU and T4ECU are read only and correspond to T1^*, T2^*, T3^* and T4^* after the component and the ECU have exchanged their timings.
Please note that T1TST through T4TST and T1ECU through T4ECU are stored in units of 100μs, 0xFFFFFFFFUL has the special meaning of "no timeout" and can only be selected for certain timing parameters. Since not all values can be represented in the encoded form as described in the TP 1.6 specification the component will check T1TST through T4TST after they have been altered and set them them to values that can be encoded.
Also note that the actual enconding of the time values cannot be influenced. The component will automatically select the smallest possible time base.

Remarks

An application can rely on the values of the timing parameters T1ECU through T4ECU only as long as the connection is established. So it shall monitor the flags AIDA_nCommuStarted and AIDA_nCommuStopped of the dwFlags member of AIDA events to get the neccessary information about the connection state.

See Also

AIDA Overview, list of AIDA components