Successful testing

of LIN systems
Roman Hofmann, IXXAT Automation GmbH

LIN communication systems have now be- gle master/multiple slave concept in accordance
with extended ISO 9141 with a bit rate of up to
come an integral part of car body electronics
20 kbits/s. Physically the LIN is based on a sin-
and ever more complex applications are im- gle wire 12 V bus. A special feature of LIN is the
synchronization mechanism, with which slave
plemented in the bus systems of the vehicle.
nodes can be synchronized with the master,
For this reason it is important to have suit- which enables the use of very low-cost oscillator
circuits.
able test concepts and testing tools which
meet the increased requirements. In the fol- A LIN message consists of a header, which is
terminated by the LIN bus arbiter (LIN master),
lowing article, the various requirements are
and a response field, which is transmitted by the
discussed and it is shown how even complex addressed LIN slave. The header consists of a
13 bit long sync-break, which serves as a clear
testing systems can be implemented with
start-up code, an eight bit long sync field, which
suitable testing devices. enables synchronization of the slave resonators
to the master oscillator with 0-1 sequences and
an identifier field with 6 bit message ID (of which
LIN (Local Interconnect Network) is a universal,
2 bits are used as optional length information
serial low-cost communication system for use in
and 2 more bits as parity backup) (Fig. 1).
automobiles [1]. It was developed as an open
standard, among others by Audi,
BMW, Daimler-Chrysler, Volvo and
Volkswagen, in order to further re-
duce the costs of networking vehicle
components. In particular, LIN is
used in systems where only simple
functions are necessary and a rela-
tively low bit rate is sufficient (e.g. air-
conditioning, central locking or mirror
adjustment). Use of just one signal
wire, very simple implementation of
the interface, use of low-cost micro-
controllers and dispensing with precise quartz Fig. 1: LIN Message Frame
oscillators enable a certain cost saving com-
pared with device networking via CAN.
In the 2 bits of the length information, message
lengths of 2, 4 or 8 bytes can be coded. The re-
LIN as a sub-bus to CAN sponse field contains the user data of the LIN
Subsystems for which the power of the CAN-bus slave and a further byte as a check-sum. The
is not required, can be implemented less expen- sync field, identifier field and response field are
sively with LIN. Inasmuch, CAN and LIN com- transferred coded in 8N1. However, the length
plement each other perfectly. By means of LIN/- option also allows message lengths outside the
CAN gateways, the sub-systems can be inte- length information specified in the header. In this
grated in CAN networks or implemented via case it is necessary to store the message
CAN-distributed LIN systems. lengths for each subscriber of the LIN network,
LIN is based on the SCI (UART) protocol, a sin- as the message length can no longer be deter-
mined from the header bits received. Owing to Master and slave implementations
the flexible use of the message length, LIN require different test functions
communication systems can be adapted to the Due to the single master/multiple slave principle
optimum use of bandwidth and reaction times. on which it is based, the device corresponding to
communication is generally not necessary during
The physical bus connection is basically made development. For the implementation of a slave,
via a transistor connection to the SCI. A diode a LIN master may also have to emulate other
prevents a reverse current into the MC system in slaves in order to transmit or receive the mes-
the event of power loss (Fig. 2). The LIN bus is sages required in the application. For the devel-
biased with the master node via a 1 k pull-up re- opment of a LIN master, on the other hand, LIN
sistor, with the LIN slave node via a 30 k pull-up slaves are required to be able to test the com-
resistor. The connection can be made using nu- munication and thus also the application. The
merous available LIN transceiver modules. Cor- LIN2CAN gateway of IXXAT Automation [3], for
responding modules generally implement further example, fulfills both requirements – it can be
useful functions such as wakeup detection, used both as a LIN master and as a LIN slave.
power-saving mode and already offer integrated Two operating modes are possible: a configur-
protection against transient faults, short-circuits able stand-alone emulation and a PC-based,
and overload [2]. Test devices must provide the freely programmable emulation.
relevant bus connections for master and slave
modes and if applicable an automatic switching
of the bus connection to the master or slave MC stand-alone and PC-based
mode. emulation for simple and complex tests
The stand-alone LIN master mode supports a
configurable scheduling table, in which the LIN
identifiers can be identified with a configurable
delay time.
As a LIN slave, response messages can be con-
figured to each of the LIN identifiers. If a LIN
master transmits the corresponding header, the
device switches the configured message(s) to
the bus. The stand-alone modes are configured
via a user-friendly Windows configuration pro-
gram. For this the LIN2CAN device is connected
to the PC via the serial port.
Fig. 2: Basic LIN bus connection Complex master or slave emulations can be im-
plemented via a programming interface. Both the
monitoring and the transmission of headers and
Necessary functions for testing complete messages are provided in the master
error detection and troubleshooting and slave mode via the Windows API. This en-
LIN dispenses with error signaling via the bus. ables the PC-based simulation of the remaining
Error detection remains local; reaction to errors network (“residual bus simulation“). In addition
is generally application-specific. Testing of the the device can be used in this way as an inde-
LIN devices for error conditions and checking of pendent development platform by first develop-
the application behavior, e.g. on receipt of an in- ing the application on the PC and then porting it
correct check-sum, an unknown message length to the target platform.
or unexpected data are all the more important
right from the development phase onwards. LIN
testing and analysis devices must therefore be Development support with
capable of reliably detecting and signaling at LIN monitoring tool
least global errors and of providing functions for At the beginning of a development, first basic
the generation of defined errors. The behavior of communication functions are required. For this a
the internal error counters and associated trou- simple LIN monitor is generally sufficient. It
bleshooting routines is checked via specific in- should provide functions to display and transmit
troduction of errors. The LIN analysis device LIN messages and a trace function. Timestamps
must also be capable of monitoring message of the individual LIN messages and the display
timing, maximum permissible response time and of errors are useful here. In the case of the
duration of a message. IXXAT LIN2CAN device, a corresponding moni-
tor is integrated in the configuration tool. The
LIN2CAN device then works as a PC interface
and can be used both as a master and as a
slave (Fig. 3).

Fig. 4: LIN in-door modules networked via K-

CAN

In this time the switch position must be re-

quested, evaluated in the gateway, transferred
via K-CAN to GW2 and provided there for the
window control. The information can only be
transferred when the relevant message is pre-
sent in the message schedule of the correspond-
ing LIN master. In the worst case a time delay
thus results for the transmission of the informa-
Fig. 3: LIN monitor with tion across the three communication systems
transmit and trace function from the maximum values for bus allocation and
transmission time of the LIN message of the
sensor (switch position), of the maximum latency
Analysis of distributed LIN applications and transmission time of the corresponding CAN
LIN networks in vehicles are frequently con- message as well as of the duration for bus ac-
nected with each other via CAN. A typical exam- cess and transmission in the target network
ple of this is in-door systems with window con- (LIN). With a LIN baud rate of 9.6 kbauds and a
trols, wing mirrors and operating panel (Fig. 4). CAN bit rate of 125 kbits/s, the duration of
Usually, not only the connected subscribers are transmission of a 2 byte LIN message via all
triggered via the operating panel but also func- communication systems can be more than 20
tions in other LIN sub-systems which are con- ms. During development, therefore, those parts
nected via the car body CAN. Especially with of the master schedule which are connected with
operating devices such as window control distributed application data must be considered
switches, the user expects an immediate reac- accordingly and can also affect the maximum
tion when they are pressed. This means, for ex- number of possible subscribers.
ample, that window controls must be activated
within 200 ms.
 cient for several sub-systems. By using the
LIN2CAN gateway, the LIN sub-systems net-
worked via CAN can also be analyzed in the
context of CAN networks without specific LIN
tools. For this, already available CAN analysis
tools such as the IXXAT
canAnalyser/32 [4] or the CANcorder [5] can
continue to be used and possible effects on the
CAN network investigated.

Test of the power-down

and wakeup behavior
An important aspect when carrying out tests on
Fig. 5: Use of CAN analysis tools automotive applications is the investigation of
for testing LIN networks the power-down behavior of the networked sys-
tems and the reaction to wakeup requests. A
To analyze the required times, the time between corresponding testing device must therefore ha-
LIN and CAN messages of both LIN systems ve a configurable power-down mode and it must
can be determined with the aid of LIN/CAN be possible to wake it up via connected
gateways in both LIN sub-systems and of a CAN communication systems as well as via con-
analysis tool. The LIN messages are mapped nected subscribers. In addition, it must be possi-
onto CAN (Fig. 5). As the message rate of the ble to connect various wakeup requests to the
LIN networks is much lower than with CAN, the bus. For use in test vehicles, power consumption
resulting additional bus load of the CAN network in power-down mode must be minimal. The
can generally be disregarded. LIN2CAN device also fulfills this requirement
In addition to the actual gateway function, it with a power consumption of only approx. 10
should also be possible to map and therefore mW in sleep mode.
analyze the protocol errors occurring in the LIN
network from the gateway to CAN. In the gate-
way mode the IXXAT LIN2CAN device works as Summary
a LIN slave. There are a very large number of different
requirements for testing LIN devices, networks
and distributed applications. The LIN2CAN
device from IXXAT fulfills the requirements
thanks to various optimized operating modes. A
device was thus created which can be used
universally for development and testing. For this,
already existing CAN analysis tools can be used
and therefore efficient analysis and testing
systems can be developed at low cost. In
addition, the LIN2CAN device can also be used
as a platform for PC-based EOL test
environments.

Fig. 6: LIN2CAN gateway from IXXAT

In addition, LIN messages can also be termi-

nated via CAN if the relevant message identifiers
are requested in the schedule of the LIN master.
The device can also be switched on and off in
gateway mode via a configurable CAN message.
In this way, several LIN sub-systems can be
analyzed one after the other via the CAN identi-
fiers. This is necessary if the reserved CAN
identifiers available for diagnosis are not suffi-
References:

[1] LIN Specification Package Revision 1.3,

12.12.2002 IXXAT Automation GmbH
www.lin-subbus.de Leibnizstr. 15
D-88250 Weingarten
[2] Data sheet TJA1020 LIN transceiver
www.semiconductors.philips.com Tel.: +49-(0)7 51 / 5 61 46-0
Fax: +49-(0)7 51 / 5 61 46-29
[3] Data sheet LIN2CAN Gateway
www.ixxat.de e-Mail: [email protected]
Internet: www.ixxat.de
[4] Data sheet canAnalyser/32
www.ixxat.de

[5] Data sheet CANcorder

www.ixxat.de

Author:

Roman Hofmann, Dipl.-Ing.

Product Manager at IXXAT Automation GmbH
Weingarten, responsible for hardware products
and analysis tools.