ISO 17987-3:2016

DRAFT INTERNATIONAL STANDARD
ISO/DIS 17987-3.2
ISO/TC 22/SC 31 Secretariat: DIN
Voting begins on: Voting terminates on:
2015-10-05 2015-12-05
Road vehicles — Local Interconnect Network (LIN) —
Part 3:
Protocol specification
Véhicules routiers — Réseau Internet local (LIN) —
Partie 3: Spécification du protocole
ICS: 01.040.43; 43.020
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/DIS 17987-3.2:2015(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO 2015

ISO/DIS 17987-3.2:2015(E)
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved

ISO/FDIS 17987-3:2015(E)
Contents Page
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Symbols . 4
3.3 Abbreviated terms . 4
4 Node concept . 5
4.1 Concept of operation . 5
5 Protocol requirements . 7
5.1 Signal . 7
5.2 Frame . 9
5.3 Schedule tables . 20
5.4 Task behaviour model . 21
5.5 Status management . 24
6 Node configuration and identification . 25
6.1 General . 25
6.2 LIN product identification . 26
6.3 Slave node model . 27
Annex A (normative) Definition of properties, frame identifiers and various examples . 36
A.1 Definition of numerical properties . 36
A.2 Definition of valid frame identifiers . 36
A.3 Example of checksum calculation . 38
A.4 Example of sequence diagrams . 39
Annex B (informative) LIN history and version compatibility . 40
B.1 LIN history and background . 40
B.2 LIN version compatibility . 40
B.3 Changes between LIN versions . 41
Annex C (informative) LIN auto addressing methods . 44
C.1 Auto addressing method and method IDs . 44
C.2 Auto addressing method ID. 44
Bibliography . 46

ISO/FDIS 17987-3:2015(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 17987-3 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Electrical and electronic equipment.
ISO 17987 consists of the following parts, under the general title Road vehicles — Local Interconnect Network
(LIN):
 Part 1: General information and use case definition
 Part 2: Transport protocol and network layer services
 Part 3: Protocol specification
 Part 4: Electrical Physical Layer (EPL) specification (12 V / 24 V)
 Part 5: Application Programmers Interface (API)
 Part 6: Protocol conformance test specification
 Part 7: Electrical Physical Layer (EPL) conformance test specification
iv © ISO 2015 – All rights reserved

ISO/FDIS 17987-3:2015(E)
Introduction
This document set specifies the use cases, the communication protocol and physical layer requirements of an
in-vehicle communication network called "Local Interconnect Network (LIN)".
The LIN protocol as proposed is an automotive focused low speed UART-based network (Universal
Asynchronous Receiver Transmitter). Some of the key characteristics of the LIN protocol are signal based
communication, schedule table based frame transfer, master/slave communication with error detection, node
configuration and diagnostic service communication.
The LIN protocol is for low cost automotive control applications, for example door module and air condition
systems. It serves as a communication infrastructure for low-speed control applications in vehicles by
providing:
 Signal based communication to exchange information between applications in different nodes;
 Bit rate support from 1 kbit/s to 20 kbit/s;
 Deterministic schedule table based frame communication;
 Network management that wakes up and puts the LIN cluster into sleep mode in a controlled manner;
 Status management that provides error handling and error signalling;
 Transport layer that allows large amount of data to be transmitted (such as diagnostic services);
 Specification of how to handle diagnostic services;
 Electrical physical layer specifications;
 Node description language describing properties of slave nodes;
 Network description file describing behaviour of communication;
 Application programmer's interface;

ISO 17987 is based on the Open Systems Interconnection (OSI) Basic Reference Model as specified in
ISO/IEC 7498-1 which structures communication systems into seven layers.
The OSI model structures data communication into seven layers called (top down) application layer (layer 7),
presentation layer, session layer, transport layer, network layer, data link layer and physical layer (layer 1). A
subset of these layers is used in ISO 17987.
ISO 17987 distinguishes between the services provided by a layer to the layer above it and the protocol used
by the layer to send a message between the peer entities of that layer. The reason for this distinction is to
make the services, especially the application layer services and the transport layer services, reusable also for
other types of networks than LIN. In this way the protocol is hidden from the service user and it is possible to
change the protocol if special system requirements demand it.

ISO/FDIS 17987-3:2015(E)
This document set provides all documents and references required to support the implementation of the
requirements related to.
 Part 1: General information and use case definitions
This part provides an overview of the document set and structure along with the use case definitions and
a common set of resources (definitions, references) for use by all subsequent parts.
 Part 2:
This part specifies the requirements related to the transport protocol and the network layer requirements
to transport the PDU of a message between LIN nodes.
 Part 3:
This part specifies the requirements for implementations of the LIN protocol on the logical level of
abstraction. Hardware related properties are hidden in the defined constraints.
 Part 4:
This part specifies the requirements for implementations of active hardware components which are
necessary to interconnect the protocol implementation.
 Part 5 (published as a non-normative technical report):
This part specifies the LIN API (Application Programmers Interface) and the node configuration and
identification services. The node configuration and identification services are specified in the API and
define how a slave node is configured and how a slave node uses the identification service.
 Part 6:
This part specifies tests to check the conformance of the LIN protocol implementation according to
ISO 17987-2 and ISO 17987-3. This comprises tests for the data link layer, the network layer and the
transport layer.
 Part 7:
This part specifies tests to check the conformance of the LIN electrical physical layer implementation
(logical level of abstraction) according to ISO 17987-4.

vi © ISO 2015 – All rights reserved

FINAL DRAFT INTERNATIONAL STANDARD ISO/FDIS 17987-3:2015(E)

1 Road vehicles — Local Interconnect Network (LIN) — Part 3:
2 Protocol specification
3 1 Scope
4 This part of ISO 17987 specifies the LIN protocol including the signal management, frame transfer, schedule
5 table handling, task behaviour and status management and LIN master and slave node. It contains also OSI
6 layer 5 properties according to ISO 14229-7 UDSonLIN based node configuration and identification services
7 (SID: B0 to B8 ) belonging to the core protocol specification.
16 16
8 A node (normally a master node) that is connected to more than one LIN network is handled by higher layers
9 (e.g. the application) not in the scope of this document.
10 2 Normative references
11 The following referenced documents are indispensable for the application of this document. For dated
12 references, only the edition cited applies. For undated references, the latest edition of the referenced
13 document (including any amendments) applies.
14 ISO 17987 (Part 2, 4, 6 and 7), Road vehicles – Local Interconnect Network (LIN)
15 3 Terms, definitions, symbols and abbreviated terms
16 3.1 Terms and definitions
17 For the purposes of this document, the following terms and definitions and those given in ISO 17987-1:2015
18 apply.
19 3.1.1
20 big-endian
21 method of storage of multi-byte numbers with the most significant bytes at the lowest memory addresses
22 broadcast NAD
23 a broadcast NAD is addressing every slave node on LIN
24 3.1.2
25 bus interface
26 the hardware (transceiver, UART, etc.) of a node that is connected to the physical bus wire in a cluster
27 3.1.3
28 bus sleep state
29 state in which a node only expects an internal or external wake up. The nodes switch output level to the
30 recessive state
31 [SOURCE ISO 17987-2:2015, 6.1.2]
ISO/FDIS 17987-3:2015(E)
32 3.1.4
33 classic checksum
34 used for diagnostic frames and legacy LIN slave nodes frames of protocol version 1.x. The classic checksum
35 considers the frame response data bytes only
36 3.1.5
37 cluster
38 communication system comprising the LIN wire and all connected nodes
39 3.1.6
40 cluster design
41 process of designing the LDF
42 [SOURCE ISO 17987-2:2015, 11.2.3]
43 3.1.7
44 data
45 response part of a frame carrying one to eight data bytes
46 3.1.8
47 data byte
48 One of the bytes in the data
49 3.1.9
50 diagnostic frame
51 master request frame and the slave response frame
52 3.1.10
53 diagnostic trouble code DTC
54 value making reference to a specific fault in a system implemented in the server
55 3.1.11
56 enhanced checksum
57 checksum model used for all non-diagnostic frames and legacy 1.x LIN slave nodes
58 3.1.12
59 event triggered frame
60 allowing multiple slave nodes to provide their response to the same header
61 3.1.13
62 frame
63 communication entity consisting of a header and response
64 3.1.14
65 frame identifier
66 value identifier uniquely a frame
67 3.1.15
68 frame slot
69 time period reserved for the transfer of a specific frame on LIN. This corresponds to one entry in the schedule
70 table
71 3.1.16
72 go-to-sleep command
73 special master request frame issued to force slave nodes to bus sleep state
74 [SOURCE ISO 17987-2:2015, 6.1.4]
2 © ISO 2015 – All rights reserved

ISO/FDIS 17987-3:2015(E)
75 3.1.17
76 header
77 the first part of a frame consists of a break field, sync byte field and protected identifier; it is always sent by the
78 LIN master node
79 3.1.18
80 LIN product identification
81 number containing the supplier and function and variant identification in a LIN slave node
82 3.1.19
83 little-endian
84 method of storage of multi-byte numbers with the least significant bytes at the lowest memory addresses.
85 3.1.20
86 master request frame
87 diagnostic frames issued by the master node frame identifier
88 3.1.21
89 node capability file NCF
90 file format describes a slave node as seen from the LIN network
91 3.1.22
92 operational state
93 slave node may transmit/receive frames in this state, see [SOURCE ISO 17987-2:2015, 5.1.2].
94 3.1.23
95 protected identifier PID
96 8-bit value consisting of a unique 6-bit frame identifier and 2-bit parity
97 3.1.24
98 publisher
99 node providing a frame response containing signals
100 3.1.25
101 request
102 diagnostic frame transmitted by the master node requesting data from a slave nodes
103 3.1.26
104 response
105 answer sent by a slave node on a diagnostic request
106 3.1.27
107 service
108 the combination of a diagnostic request and response
109 3.1.28
110 slave response frame
111 frame used for diagnostic communication sent by one of the slave nodes
112 3.1.29
113 signal
114 is a value or byte array transmitted in the cluster using a signal carrying frame
115 3.1.30
116 signal carrying frame
117 unconditional frames, sporadic frames, and event triggered frames containing signals
ISO/FDIS 17987-3:2015(E)
118 3.1.31
119 sporadic frame
120 a group of unconditional frames assigned to a schedule slot published by the master node
121 3.1.32
122 subscriber
123 a master or slave node that receives the data within a LIN frame.
124 3.1.33
125 unconditional frame
126 frame carrying signals that is always sent in its allocated frame slot
128 3.2 Symbols
⊕ exclusive disjunction (exclusive or)
EXAMPLE a ⊕ b; exclusive or. True if exactly one of 'a' or 'b' is true.
¬ Negation
 element of
EXAMPLE f  S; belongs to. True if 'f' is in the set 'S'.
129 3.3 Abbreviated terms
API application programmers interface
ASIC application specific integrated circuit
DTC diagnostic trouble code
LDF LIN description file
LIN Local Interconnect Network
LSB least significant bit
MRF master request frame
MSB most significant bit
NAD node address
NCF node capability file
NRC negative response code
NVRAM non-volatile random access memory
OSI Open Systems Interconnection
PCI protocol control information
PDU protocol data unit
4 © ISO 2015 – All rights reserved

ISO/FDIS 17987-3:2015(E)
PID protected identifier
ROM read only memory
RSID response service identifier
SID service identifier
SRF slave response frame
TL transport layer
VRAM volatile RAM
131 4 Node concept
132 The LIN specifications assumes a software implementation of most functions, alternative realizations are
133 promoted.
134 A node in a cluster interfaces to the physical bus wire using a frame transceiver. The frames are not accessed
135 directly by the application; a signal based interaction layer is added in between. As a complement, a transport
136 layer (TL) interface exists between the application and the frame handler, see Figure 1.
Application
API
TL Signal interaction
Protocol
Frame handler
Physical
LIN bus
139 Figure 1 — Node concept
141 4.1 Concept of operation
142 4.1.1 Master and slave
143 A cluster consists of one master node and several slave nodes. A master node contains a master task as well
144 as a slave task. All slave nodes contain a slave task only.
145 NOTE The slave task in the master node and in the slave node is not identical due to differences in PID handling.
ISO/FDIS 17987-3:2015(E)
146 A master node may participate in more than one cluster with one dedicated bus interfaces for each cluster. A
147 sample cluster with one master node and two slave nodes is shown in Figure 2.
master node slave node slave node
master task
slave task slave task
slave task
LIN bus
150 Figure 2 — Master and slave tasks
152 The master task decides when and which frame shall be transferred on the bus. The slave tasks provide the
153 data transmitted by each frame. Both, the master task and the slave task are parts of the frame handler.
154 4.1.2 Frames
155 A frame consists of a header (provided by the master task) and a response (provided by a slave task).
156 The header consists of a break field and sync byte field followed by a protected identifier. The protected
157 identifier uniquely defines the purpose of the frame and node providing the response. The slave task of the
158 node assigned as response transmitter provides the response. In case of diagnostic frames not only the frame
159 identifier but also the NAD assigns the transmitting node.
160 The response consists of a data field and a checksum field. The slave tasks interested in the data associated
161 with the frame identifier receives the response, verifies the checksum and uses the data transmitted.
162 Figure 3 shows the LIN frame header and response fields.
Master task
Header Header
Slave task 1 Response
Slave task 2 Response
165 Figure 3 — LIN frame header and response fields
167 This results in the following desired features:
168  System flexibility: Nodes can be added to the LIN cluster without requiring hardware or software changes
169 in other slave nodes.
170  Message routing: The content of a message is defined by the frame identifier (similar to CAN).
6 © ISO 2015 – All rights reserved

ISO/FDIS 17987-3:2015(E)
171  Multicast: Any number of nodes can simultaneously receive and act upon a single frame.
172 4.1.3 Data transport
173 Two types of data may be transmitted in a frame; signals or diagnostic messages.
174  Signals:
175 Signals are scalar values or byte arrays that are packed into the data field of a frame. A signal is always
176 present at the same position of the data field for all frames with the same frame identifier.
177  Diagnostic messages:
178 Diagnostic messages are transmitted in frames with two reserved frame identifiers. The interpretation of
179 the data field depends on the data field itself as well as the state of the communicating nodes.
180 5 Protocol requirements
181 5.1 Signal
182 5.1.1 Management
183 A signal is transmitted in the data field of a frame.
184 5.1.2 Types
185 A signal is either a scalar value or a byte array.
186 A scalar signal is between 1 and 16 bit long. Scalar signals are treated as unsigned integers. A 1-bit scalar
187 signal is called a Boolean signal.
188 A byte array is an array of one up to eight bytes.
189 Each signal shall have one publisher, i.e. it shall be always sent by the same node in the cluster. Zero, one or
190 multiple nodes may subscribe to the signal.
191 All signals shall have initial values. The initial value for a published signal should be valid until the node writes
192 a new value to this signal. The initial value for a subscribed signal should be valid until a new updated value is
193 received from another node.
194 5.1.3 Consistency
195 Scalar signal writing or reading shall be atomic operations, i.e. it shall not be possible for an application to
196 receive a signal value that is partly updated. This shall also apply to byte arrays. However, no consistency is
197 guaranteed between any signals.
198 5.1.4 Packing
199 There is no restriction on packing scalar signals over byte boundaries. Each byte in a byte array shall map to
200 a single frame byte starting with the lowest numbered data byte, see 5.2.2.6.
201 Several signals may be packed into one frame as long as they do not overlap each other.
202 NOTE Signal packing/unpacking is implemented more efficient in software based nodes if signals are byte aligned
203 and/or if they do not cross byte boundaries.
ISO/FDIS 17987-3:2015(E)
204 The same signal may be packed into multiple frames as long as the publisher of the signal is the same. If a
205 node is receiving one signal packed into multiple frames the latest received signal value is valid. Handling the
206 same signal packed into frames on different LIN clusters is out of the scope.
207 5.1.5 Reception and transmission
208 The point in time when a signal is transmitted/received needs to be defined to help design tools and testing
209 tools to analyse timing of signals. This means that all implementations behave in a predictable way.
210 The definitions below do not contain factors such as bit rate tolerance, jitter, buffer copy execution time, etc.
211 These factors needs be taken into account to get a more detailed analysis. The intention for the definitions
212 below is to have a basis for such analysis.
213 The timing is different for a master node and a slave node. The reason is that the master node controls the
214 schedule and is aware of the due frame. A slave node gets this information first when the header is received.
215 The time base and time base tick is defined in 5.3.
216 A signal is considered received and available to the application as shown in Figure 4.
217  Master node, at the next time base tick after the maximum frame length. The master node updates its
218 received signals periodically at the time base start (i.e. at task level).
219  Slave node, when the checksum for the received frame is validated. The slave node updates its received
220 signals directly after the frame is finished (i.e. at interrupt level).
frame on
bus
received frame 2
header response
time
time base time base
Key
1 Time base tick
2 Slave node – signal is available to the application
Master node – time the signal is available to the application
223 Figure 4 — Timing of signal reception
225 A signal is considered transmitted (latest point in time when the application may write to the signal).
226  Master node – before the frame transmission is initiated.
227  Slave node – when the ID for the frame is received.
8 © ISO 2015 – All rights reserved

ISO/FDIS 17987-3:2015(E)
228 Figure 5 shows the timing of signal transmission.
frame on
bus
transmitted frame
header response
time
time base time base
Key
1 Time base tick
2 Master – latest point the application can update the signal
3 Slave – latest point the application can update the signal
231 Figure 5 — Timing of signal transmission
233 5.2 Frame
234 5.2.1 Transfer
235 The entities that are transferred on the LIN network are frames.
236 5.2.2 Structure
237 5.2.2.1 Definition of fields
238 The frame consists of a number of fields, one break field followed by four to eleven byte fields, labelled as in
239 Figure 6. The time it takes to send a frame is the sum of the time to send each byte plus the response space
240 and the inter-byte spaces.
241 The header starts at the falling edge of the break field and ends after the end of the stop bit of the protected
242 identifier (PID) field. The response starts at the end of the stop bit of the PID field and ends at the after the
243 stop bit of the checksum field.
244 The inter-byte space is defined to be the time between the end of the stop bit of the preceding field and the
245 start bit of the following byte. The response space is defined to be the inter-byte space between the PID field
246 and the first data field in the data. Both of them shall be non-negative.
ISO/FDIS 17987-3:2015(E)
frame
header response
response space
protected
break field sync byte field
data 1 data 2 data N checksum
identifier field
inter-byte space inter-byte spaces
249 Figure 6 — Structure of a frame
251 5.2.2.2 Byte field
252 Each byte field, except the break field, is transmitted as the byte field as specified in Figure 7. The LSB of the
253 data is sent first and the MSB last. The start bit shall be encoded as a bit with value zero (dominant) and the
254 stop bit shall be encoded as a bit with value one (recessive).
byte field
start LSB MSB stop
bit (bit 0) (bit 7) bit
257 Figure 7 — Structure of a byte field
259 5.2.2.3 Break field
260 The break field is used to signal the beginning of a new frame. It is the only field that does not comply with
261 Figure 7. A break field is always generated by the master task (in the master node) and it shall be at least 13
262 nominal bit times of dominant value, followed by a break delimiter, as shown in Figure 8. The break delimiter
263 shall be at least one nominal bit time long. It should be sent with 2 bit length in order to avoid misinterpretation

1)
264 at receiving slave nodes.
265 A slave node shall use a break detection threshold of 11 dominant local slave bit times. However slave nodes
266 without specific break field detection capabilities use a detection threshold of 9,5 T on the Rx pin. A slave
BIT
267 node shall not check that the break delimiter is at least one nominal bit time long. A slave node shall be
268 capable of detecting a break delimiter of at least 9/16 of a bit in length on the Rx line.
1) A UART can only handle complete bits, so it can occur on the physical layer that the break delimiter is shorter than
one bit time.
10 © ISO 2015 – All rights reserved

ISO/FDIS 17987-3:2015(E)
break break delimiter
271 Figure 8 — Break field
273 5.2.2.4 Sync byte field
274 A slave task shall always be able to detect the break/sync byte field sequence, even if it expects a byte field
275 (assuming the byte fields are separated from each other). When a break/sync byte field sequence occurs, the
276 transfer in progress shall be aborted and processing of the new frame shall commence.
277 Sync byte field is a byte field with the data value 55 , as shown in Figure 9.
start stop
bit bit
280 Figure 9 — Sync byte field
282 5.2.2.5 PID field
283 5.2.2.5.1 Overview
284 A protected identifier field consists of two sub-fields
285  the frame identifier, and
286  the parity.
287 Bit 0 to bit 5 are the frame identifier and bit 6 and bit 7 are the parity.
288 5.2.2.5.2 Frame identifier
289 Six bits (ID0 to ID5) are reserved for the frame identifier and values in the range of 0 to 63 shall be used.
10 10
290 The frame identifiers are split into three categories:
291  Values 0 to 59 are used for signal carrying frames,
10 10
292  Values 60 (3C ) and 61 (3D ) are used to carry diagnostic and node configuration data,
10 16 10 16
293  Values 62 (3E ) and 63 (3F ) are reserved for future protocol enhancements.
10 16 10 16
294 5.2.2.5.3 Parity
295 The parity (P0 and P1) is calculated on the frame identifier bits as shown in equations (1) and (2):
ISO/FDIS 17987-3:2015(E)
Definition of equation
(1)
P0 = ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4
Definition of equation
(2)
P1 = ¬(ID1 ⊕ ID3 ⊕ ID4 ⊕ ID5)
298 5.2.2.5.4 Mapping
299 The mapping of the bits (ID0 to ID5 and P0 and P1) is shown in Figure 10.
start stop
ID0 ID1 ID2 ID3 ID4 ID5 P0 P1
bit bit
302 Figure 10 — Mapping of frame identifier and parity to the protected identifier field
304 5.2.2.6 Data
305 A frame carries between one and eight bytes of data. The number of data contained in a frame with a specific
306 frame identifier shall be agreed by the publisher and all subscribers. A data byte is transmitted as part of a
307 byte field, see Figure 7.
308 The data fields are labelled Data 1, Data 2,. up to maximum Data 8, see Figure 11.
Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7 Data 8
311 Figure 11 — Numbering of the data bytes in a frame with eight data bytes
313 How signals are mapped into frames is a decision that shall affect at least the whole LIN cluster.
314 Beside the default signal mapping used in LIN clusters since its founding an optional signal mapping variant is
315 specified that allows to keep the big-endian signal encoding when routing frames from a back bone bus to a
316 LIN cluster.
317 The two possible encodings are described in the following subclauses.
12 © ISO 2015 – All rights reserved

ISO/FDIS 17987-3:2015(E)
318 5.2.2.6.1 LIN default signal mapping to data bytes
319 For signals longer than one byte, the LSB signal entity is contained in the byte sent first and the MSB signal
320 entity in the byte sent last (little-endian).
321 Figure 12 provides an example of the LIN default signal mapping into frame response data bytes with four
322 signals.
LIN Frame Response
LIN default signal mapping
Data byte 1 2 3 4
Bit index 0 7 0 7 0 7 0 7
overall 31
0 7 8 15 16 23 24
1 21 27
1 Signal offset in frame
Signal mapping 0   Sig_A   4 0  1        Sig_B       8   9          13 0   Sig_C   4 0 Sig_D  3
Transmission order
0   Sig_A   4 0  1        Sig_B       8   9          13 0   Sig_C   4 0 Sig_D  3
LSB first
Key
1 See parameter signal_offset in ISO 17987-2 subclause 12.3.3.2.
2 Transmission order is starting from least significant bit in least significant data byte.
325 Figure 12 — LIN default signal mapping into frame response data bytes
326 The LSB of each signal is referenced in the LDF and NCF frame definition as offset of the signal position. Key
327 1 values (Sig_A: 1, Sig_B: 7, Sig_C: 21 and Sig_D: 27) mark the offset for the four signals in the example.
328 5.2.2.6.2 Optional big-endian LIN signal mapping to data bytes variant
329 For signals longer than one byte, the MSB signal entity is contained in the byte sent first and the LSB signal
330 entity in the byte sent last (big-endian).
331 Data byte transmission order as well as the bit transmission order on LIN is not changed due to big-endian
332 signal encoding.
333 Figure 13 provides an example of the LIN big-endian signal mapping into frame response data bytes with four
334 signals.
ISO/FDIS 17987-3:2015(E)
LIN Frame Response
Big-endian signal mapping (non LIN default)
Data byte 0 1 2 3
Bit index 7 0 7 0 7 0 7 0
overall
7 0 15 8 23 16 31 24
6 18 28
1 Signal offset in frame
Signal mapping 4   Sig_A   0 13 12        Sig_B       5  4           0 4   Sig_C   0 3 Sig_D  0
Transmission order
B
2 0   Sig_A   4 5        Sig_B       12 2  C  4 0   Sig_B   4 0 Sig_D  3 0  C  1
LSB first
336 Figure 13 — LIN big-endian signal mapping into frame response data bytes
337 The most significant bit of each signal is referenced in the LDF and NCF frame definition as offset of the signal
338 position. Key 1 values (Sig_A: 6, Sig_B: 0, Sig_C: 18 and Sig_D: 28) mark the offset for the four signals in the
339 example.
340 LIN node configuration commands AssignNAD, ReadByIdentifier and AssignFrameIdentifier use the 16-bit
341 product identifier signals supplier_id and function_id in the request. As those commands have a LIN
342 specific fixed format they are not affected by this big-endian signal encoding variant definition.
343 5.2.2.7 Checksum
344 The last field of a frame is the checksum. The checksum contains the inverted eight bit sum with carry over all
345 data bytes (classic checksum) or all data bytes and the protected identifier (enhanced checksum).
346 Eight bit sum with carry is equivalent to the sum of all values and subtract 255 every time the sum is greater
347 or equal to 256 . See A.3 for examples how to calculate the checksum.
348 Checksum calculation over the data bytes and the protected identifier byte is called enhanced checksum and
349 it is used for non-diagnostic communication.
350 The checksum is transmitted in a byte field, see Figure 7.
351 Use of classic or enhanced checksum is managed by the master node and it is determined per frame
352 identifier.
353 Frame identifiers 60 (3C ) to 61 (3D ) shall always use classic checksum.
10 16 10 16
354 5.2.3 Frame length
355 The nominal value for transmission of a frame exactly matches the number of bits sent (no response space
356 and no inter-byte spaces). The nominal break field is 14 nominal bits long (break is 13 nominal bits and break
357 delimiter is 1 nominal bit).
358 Equation (3) defines T
HEADER_MIN.
14 © ISO 2015 – All rights reserved

ISO/FDIS 17987-3:2015(E)
Definition of equation
(3)
T = 34 T
HEADER_MIN BIT
359 where
360 T Nominal time required to transmit a bit
BIT
361 Equation (4) defines the T
RESPONSE_MIN.
Definition of equation
(4)
T = 10 * (N + 1) * T
RESPONSE_MIN Data BIT
363 Equation (5) defines T
FRAME_MIN.
Definition of equation
(5)
T = T + T
FRAME_MIN HEADER_MIN RESPONSE_MIN
365 The break field is 14 nominal bits or longer, see 5.2.2.3. This means that T puts a requirement on
HEADER_MAX
366 the maximum length of the break field.
367 The maximum space between the bytes is additional 40% duration compared to the nominal transmission
368 time. The additional duration is split between the header (the master task) and the frame response (a slave
369 task).
370 Equation (6) defines T
HEADER_MAX
Definition of equation
(6)
T = 1,4 * T = 47,6 T
HEADER_MAX HEADER_MIN BIT
372 Equation (7) defines T
RESPONSE_MAX
Definition of equation
(7)
T = 1,4 * T
RESPONSE_MAX RESPONSE_MIN
374 Equation (8) defines T
FRAME_MAX
Definition of equation
(8)
T = T + T
FRAME_MAX HEADER_MAX RESPONSE_MAX
376 The maximum length of the header, response and frame is based on the nominal time for a frame (based on
377 the F as defined in ISO 17987-4 subclause 5.1). Therefore the bit tolerances are included in the maximum
Nom
378 length.
ISO/FDIS 17987-3:2015(E)
379 EXAMPLE A master node that is 0,5% slower than FNom is within 1,4 * THEADER_MIN.
380 All subscribing nodes shall be able to receive a frame that has a zero overhead, i.e., that is T long.
FRAME_MIN
381 Tools and tests shall check the T . Nodes shall not check this time. Reception of a frame response
FRAME_MAX
382 after T is not guaranteed. A receiving node can reject the frame.
FRAME_MAX
383 5.2.4 Frame types
384 5.2.4.1 General
385 The frame type refers to the preconditions that shall be valid to transmit the frame. Some of the frame types
386 are only used for specific purposes, which are also defined in the following subclauses. Not all frame types
387 specified need to be used in a network.
388 All bits not used/defined in a frame shall be recessive (ones).
389 5.2.4.2 Unconditional frame
390 Unconditional frames carry signals and their frame identifiers are in the range 0 to 59 (3B ).
10 10 16
391 The header of an unconditional frame is always transmitted when a frame slot allocated to the unconditional
392 frame is processed (by the master task). The publisher of the unconditional frame (the slave task) shall always
393 provide the response to the header. All subscribers of the unconditional frame shall receive the frame and
394 make it available to the application (assuming no errors were detected).
395 Figure 14 shows a sequence of three unconditional frames. A transfer is always initiated by the master. It has
396 a single publisher and one or multiple subscribers.
Slave 1 Master Slave 2
ID=30
ID=31
ID=32
Key
1 Master requests a frame from slave 1
2 Master sends a frame to both slaves
Slave 2 sends a frame to slave 1
399 Figure 14 — Three unconditional frame transfers
16 © ISO 2015 – All rights reserved

ISO/FDIS 17987-3:2015(E)
401 5.2.4.3 Event triggered frame
402 5.2.4.3.1 General
403 The purpose of an event triggered frame is to lower the reaction time of the LIN cluster without assigning too
404 much of the bus bandwidth to the polling of multiple slave nodes with seldom occurring events.
405 All subscribers of the event triggered frame shall receive the frame and use its data (if the checksum is
406 validated) as if the associated unconditional frame was received.
407 If the unconditional frame associated with an event triggered frame is scheduled as an unconditional frame the
408 response shall always be transmitted (i.e. behave as a scheduled unconditional frame).
409 5.2.4.3.2 Unconditional frames associated with the event triggered frame
410 Event triggered frames carry the response of one or more unconditional frames. The unconditional frames
411 associated with an event triggered frame shall
412  have equal length,
413  use the same checksum type classic checksum or enhanced checksum,
414  reserve the first data field to its protected identifier (even if the associated unconditional frame is
415 scheduled as an unconditional frame in the same or another schedule table),
416  be published by different slave nodes,
417  shall not be included directly in the same schedule table as the event triggered frame is scheduled.
418 5.2.4.3.3 Transmission of the event triggered frame
419 The header of an event triggered frame is transmitted when a frame slot allocated to the event triggered frame
420 is processed. The publisher of an associated unconditional frame shall only transmit the response if at least
421 one of the signals carried in its unconditional frame is updated. If the response is successfully transmitted, the
422 signal is no longer considered to be updated.
423 If none of the slave nodes respond to the header, the rest of the frame slot is silent and the header is ignored.
424 If more than one slave node responds to the header in the same frame slot, a collision occurs.
425 5.2.4.3.4 Collision resolving
426 The master node shall resolve the collision in a collision resolving schedule table. Each event triggered frame
427 has an associated collision resolving schedule table. The switch to the collision resolving schedule is made
428 automatically by the driver in the master node (i.e. not by the application). The collision resolving schedule
429 shall be activated at the start of the subsequent frame slot after the collision.
430 At least all the associated unconditional frames shall be listed in this collision resolving schedule table. The
431 collision resolving schedule may contain other unconditional frames than the associated frames. These other
432 unconditional frames may be of different length.
433 After the collision schedule table has been processed once, the driver in the master node shall switch back to
434 the previous schedule table. It shall continue with the schedule entry subsequent to the schedule entry where
435 the collision occurred (or first schedule entry in case the collision occurred in the last entry).
436 If one of the colliding slave nod
...