ISO 17987-3:2016

INTERNATIONAL ISO
STANDARD 17987-3
First edition
2016-08-15
Road vehicles — Local Interconnect
Network (LIN) —
Part 3:
Protocol specification
Véhicules routiers — Réseau Internet local (LIN) —
Partie 3: Spécification du protocole
Reference number
©
ISO 2016
© ISO 2016, 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 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
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 General . 5
4.2 Concept of operation . 6
4.2.1 Master and slave . . 6
4.2.2 Frames . 6
4.2.3 Data transport . 7
5 Protocol requirements . 7
5.1 Signal . 7
5.1.1 Management . 7
5.1.2 Types . 7
5.1.3 Consistency . 7
5.1.4 Packing . 7
5.1.5 Reception and transmission . 8
5.2 Frame . 9
5.2.1 Transfer . 9
5.2.2 Structure . 9
5.2.3 Frame length . . .13
5.2.4 Frame types .14
5.3 Schedule tables .19
5.3.1 General.19
5.3.2 Time definitions .19
5.3.3 Frame slot .19
5.3.4 Schedule table handling .20
5.4 Task behaviour model .20
5.4.1 General.20
5.4.2 Master task state machine .20
5.4.3 Slave task state machine .21
5.5 Status management .23
5.5.1 General.23
5.5.2 Concept .23
5.5.3 Event-triggered frames .23
5.5.4 Reporting to the cluster .23
5.5.5 Reporting within own node.24
6 Node configuration and identification .24
6.1 General .24
6.2 LIN product identification .25
6.2.1 Supplier ID, function ID and variant ID .25
6.2.2 Serial number .25
6.2.3 Wildcards .25
6.3 Slave node model .25
6.3.1 Memory model . .25
6.3.2 Slave node configuration variants .26
6.3.3 Initial node address .27
6.3.4 PDU structure .27
6.3.5 Node configuration handling.29
6.3.6 Node configuration services .29
Annex A (normative) Definition of properties, frame identifiers and various examples .35
Annex B (informative) LIN history and version compatibility .39
Annex C (informative) LIN auto addressing methods .43
Bibliography .44
iv © ISO 2016 – All rights reserved

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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html.
The committee responsible for this document is ISO/TC 22, Road vehicles, Subcommittee SC 31, Data
communication.
A list of all parts in the ISO 17987 series can be found on the ISO website.
Introduction
ISO 17987 (all parts) 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 the following:
— 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 sanner;
— 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 (all parts) 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 (all parts).
ISO 17987 (all parts) 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 17987 (all parts) provides all documents and references required to support the implementation of
the requirements related to.
— ISO 17987-1: This part provides an overview of ISO 17987 (all parts) and structure along with
the use case definitions and a common set of resources (definitions, references) for use by all
subsequent parts.
— ISO 17987-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.
— ISO 17987-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.
vi © ISO 2016 – All rights reserved

— ISO 17987-4: This part specifies the requirements for implementations of active hardware
components which are necessary to interconnect the protocol implementation.
— ISO/TR 17987-5: 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.
— ISO 17987-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.
— ISO 17987-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.
INTERNATIONAL STANDARD ISO 17987-3:2016(E)
Road vehicles — Local Interconnect Network (LIN) —
Part 3:
Protocol specification
1 Scope
This document specifies the LIN protocol including the signal management, frame transfer, schedule
table handling, task behaviour and status management and LIN master and slave node. It contains also
OSI layer 5 properties according to ISO 14229-7 UDSonLIN-based node configuration and identification
services (SID: B0 to B8 ) belonging to the core protocol specification.
16 16
A node (normally a master node) that is connected to more than one LIN network is handled by higher
layers (i.e. the application) not within the scope of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 17987-2:2016, Road vehicles — Local Interconnect Network (LIN) — Part 2: Transport protocol and
network layer services
ISO 17987-4:2016, Road vehicles — Local Interconnect Network (LIN) — Part 4: Electrical Physical
Layer (EPL) specification 12V/24V
ISO 17987-6:2016, Road vehicles — Local Interconnect Network (LIN) — Part 6: Protocol conformance
test specification
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 17987-1 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1.1
big-endian
method of storage of multi-byte numbers with the most significant bytes at the lowest memory
addresses
3.1.2
broadcast NAD
addressing every slave node on LIN
3.1.3
bus interface
hardware (transceiver, UART, etc.) of a node that is connected to the physical bus wire in a cluster (3.1.6)
3.1.4
bus sleep state
state in which a node only expects an internal or external wake up
Note 1 to entry: The nodes switch output level to the recessive state.
[SOURCE: ISO 17987-2:2016, 6.1.2]
3.1.5
classic checksum
used for diagnostic frames (3.1.10) and legacy LIN slave nodes frames of protocol version 1.x
Note 1 to entry: The classic checksum considers the frame response data bytes only.
3.1.6
cluster
communication system comprising the LIN wire and all connected nodes
3.1.7
cluster design
process of designing the LDF
[SOURCE: ISO 17987-2:2016, 11.2.3]
3.1.8
data
response (3.1.27) part of a frame carrying one to eight data bytes (3.1.9)
3.1.9
data byte
one of the bytes in the data
3.1.10
diagnostic frame
master request frame (3.1.21) and the slave response frame (3.1.29)
3.1.11
diagnostic trouble code
DTC
value making reference to a specific fault in a system implemented in the server
3.1.12
enhanced checksum
checksum model used for all non-diagnostic frames and legacy 1.x LIN slave nodes
3.1.13
event-triggered frame
allowing multiple slave nodes to provide their response (3.1.27) to the same header
3.1.14
frame
communication entity consisting of a header and response (3.1.27)
3.1.15
frame identifier
value identifier uniquely a frame
2 © ISO 2016 – All rights reserved

3.1.16
frame slot
time period reserved for the transfer of a specific frame on LIN
Note 1 to entry: This corresponds to one entry in the schedule table.
3.1.17
go-to-sleep command
special master request frame (3.1.21) issued to force slave nodes to bus sleep state (3.1.4)
[SOURCE: ISO 17987-2:2016, 6.1.4]
3.1.18
header
first part of a frame consists of a break field, sync byte field and protected identifier; it is always sent by
the LIN master node
3.1.19
LIN product identification
number containing the supplier and function and variant identification in a LIN slave node
3.1.20
little-endian
method of storage of multi-byte numbers with the least significant bytes at the lowest memory
addresses
3.1.21
master request frame
diagnostic frames (3.1.10) issued by the master node frame identifier (3.1.15)
3.1.22
node capability file
NCF
file format describes a slave node as seen from the LIN network
3.1.23
operational state
slave node may transmit/receive frames in this state
[SOURCE: ISO 17987-2:2016, 5.1.2]
3.1.24
protected identifier
PID
8-bit value consisting of a unique 6-bit frame identifier (3.1.15) and 2-bit parity
3.1.25
publisher
node providing a frame response containing signals (3.1.30)
3.1.26
request
diagnostic frame (3.1.10) transmitted by the master node requesting data from a slave nodes
3.1.27
response
answer sent by a slave node on a diagnostic request (3.1.26)
3.1.28
service
combination of a diagnostic request (3.1.26) and response (3.1.27)
3.1.29
slave response frame
frame used for diagnostic communication sent by one of the slave nodes
3.1.30
signal
value or byte array transmitted in the cluster (3.1.6) using a signal carrying frame (3.1.31)
3.1.31
signal carrying frame
unconditional frames (3.1.34), sporadic frames (3.1.32), and event-triggered frames (3.1.13) containing
signals (3.1.30)
3.1.32
sporadic frame
group of unconditional frames (3.1.34) assigned to a schedule slot published by the master node
3.1.33
subscriber
master or slave node that receives the data within a LIN frame
3.1.34
unconditional frame
frame carrying signals (3.1.30) that is always sent in its allocated frame slot (3.1.16)
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’.
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
4 © ISO 2016 – All rights reserved

NVRAM non-volatile random access memory
OSI Open Systems Interconnection
PCI protocol control information
PDU protocol data unit
PID protected identifier
ROM read only memory
RSID response service identifier
SID service identifier
SRF slave response frame
TL transport layer
VRAM volatile RAM
4 Node concept
4.1 General
The LIN specifications assumes a software implementation of most functions, alternative realizations
are promoted.
A node in a cluster interfaces to the physical bus wire using a frame transceiver. The frames are
not accessed directly by the application; a signal-based interaction layer is added in between. As a
complement, a transport layer (TL) interface exists between the application and the frame handler; see
Figure 1.
Figure 1 — Node concept
4.2 Concept of operation
4.2.1 Master and slave
A cluster consists of one master node and several slave nodes. A master node contains a master task as
well as a slave task. All slave nodes contain a slave task only.
NOTE The slave task in the master node and in the slave node is not identical due to differences in PID
handling.
A master node may participate in more than one cluster with one dedicated bus interfaces for each
cluster. A sample cluster with one master node and two slave nodes is shown in Figure 2.
Figure 2 — Master and slave tasks
The master task decides when and which frame shall be transferred on the bus. The slave tasks provide
the data transmitted by each frame. Both, the master task and the slave task are parts of the frame
handler.
4.2.2 Frames
A frame consists of a header (provided by the master task) and a response (provided by a slave task).
The header consists of a break field and sync byte field followed by a protected identifier. The protected
identifier uniquely defines the purpose of the frame and node providing the response. The slave task of
the node assigned as response transmitter provides the response. In case of diagnostic frames, not only
the frame identifier but also the NAD assigns the transmitting node.
The response consists of a data field and a checksum field. The slave tasks interested in the data
associated with the frame identifier receives the response, verifies the checksum and uses the data
transmitted.
Figure 3 shows the LIN frame header and response fields.
Figure 3 — LIN frame header and response fields
6 © ISO 2016 – All rights reserved

This results in the following desired features.
— System flexibility: Nodes can be added to the LIN cluster without requiring hardware or software
changes in other slave nodes.
— Message routing: The content of a message is defined by the frame identifier (similar to CAN).
— Multicast: Any number of nodes can simultaneously receive and act upon a single frame.
4.2.3 Data transport
The following two types of data may be transmitted in a frame.
— Signals:
Signals are scalar values or byte arrays that are packed into the data field of a frame. A signal is
always present at the same position of the data field for all frames with the same frame identifier.
— Diagnostic messages:
Diagnostic messages are transmitted in frames with two reserved frame identifiers. The
interpretation of the data field depends on the data field itself as well as the state of the
communicating nodes.
5 Protocol requirements
5.1 Signal
5.1.1 Management
A signal is transmitted in the data field of a frame.
5.1.2 Types
A signal is either a scalar value or a byte array.
A scalar signal is between 1 bit and 16 bit long. Scalar signals are treated as unsigned integers. A 1-bit
scalar signal is called a Boolean signal.
A byte array is an array of one up to eight bytes.
Each signal shall have one publisher, i.e. it shall be always sent by the same node in the cluster. Zero, one
or multiple nodes may subscribe to the signal.
All signals shall have initial values. The initial value for a published signal should be valid until the node
writes a new value to this signal. The initial value for a subscribed signal should be valid until a new
updated value is received from another node.
5.1.3 Consistency
Scalar signal writing or reading shall be atomic operations, i.e. it shall not be possible for an application
to receive a signal value that is partly updated. This shall also apply to byte arrays. However, no
consistency is guaranteed between any signals.
5.1.4 Packing
There is no restriction on packing scalar signals over byte boundaries. Each byte in a byte array shall
map to a single frame byte starting with the lowest numbered data byte, see 5.2.2.6.
Several signals may be packed into one frame as long as they do not overlap each other.
NOTE Signal packing/unpacking is implemented more efficient in software-based nodes if signals are byte
aligned and/or if they do not cross byte boundaries.
The same signal may be packed into multiple frames as long as the publisher of the signal is the same.
If a node is receiving one signal packed into multiple frames, the latest received signal value is valid.
Handling the same signal packed into frames on different LIN clusters is out of the scope.
5.1.5 Reception and transmission
The point in time when a signal is transmitted/received needs to be defined to help design tools
and testing tools to analyse timing of signals. This means that all implementations behave in a
predictable way.
The definitions below do not contain factors such as bit rate tolerance, jitter, buffer copy execution time,
etc. These factors needs be taken into account to get a more detailed analysis. The intention for the
definitions below is to have a basis for such analysis.
The timing is different for a master node and a slave node. The reason is that the master node controls
the schedule and is aware of the due frame. A slave node gets this information first when the header is
received.
The time base and time base tick is defined in 5.3.
A signal is considered received and available to the application as shown in Figure 4.
— Master node, at the next time base tick after the maximum frame length. The master node updates
its received signals periodically at the time base start, i.e. at task level.
— Slave node, when the checksum for the received frame is validated. The slave node updates its
received signals directly after the frame is finished, i.e. at interrupt level.
Key
1 time base tick
2 slave node – signal is available to the application
3 master node – time the signal is available to the application
Figure 4 — Timing of signal reception
A signal is considered transmitted (latest point in time when the application may write to the signal).
— Master node – before the frame transmission is initiated.
— Slave node – when the ID for the frame is received.
Figure 5 shows the timing of signal transmission.
8 © ISO 2016 – All rights reserved

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
Figure 5 — Timing of signal transmission
5.2 Frame
5.2.1 Transfer
The entities that are transferred on the LIN network are frames.
5.2.2 Structure
5.2.2.1 Definition of fields
The frame consists of a number of fields, one break field followed by four to eleven byte fields, labelled as
in Figure 6. The time it takes to send a frame is the sum of the time to send each byte plus the response
space and the inter-byte spaces.
The header starts at the falling edge of the break field and ends after the end of the stop bit of the
protected identifier (PID) field. The response starts at the end of the stop bit of the PID field and ends at
the after the stop bit of the checksum field.
The inter-byte space is defined to be the time between the end of the stop bit of the preceding field and
the start bit of the following byte. The response space is defined to be the inter-byte space between the
PID field and the first data field in the data. Both of them shall be non-negative.
Figure 6 — Structure of a frame
5.2.2.2 Byte field
Each byte field, except the break field, is transmitted as the byte field as specified in Figure 7. The LSB of
the data is sent first and the MSB last. The start bit shall be encoded as a bit with value zero (dominant)
and the stop bit shall be encoded as a bit with value one (recessive).
Figure 7 — Structure of a byte field
5.2.2.3 Break field
The break field is used to signal the beginning of a new frame. It is the only field that does not comply
with Figure 7. A break field is always generated by the master task (in the master node) and it shall be
at least 13 nominal bit times of dominant value, followed by a break delimiter, as shown in Figure 8. The
break delimiter shall be at least one nominal bit time long. It should be sent with 2 bit length in order to
avoid misinterpretation at receiving slave nodes.
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.
NOTE
A slave node shall use a break detection threshold of 11 dominant local slave bit times. However, slave
nodes without specific break field detection capabilities use a detection threshold of 9,5 T on the Rx
BIT
pin. A slave node shall not check that the break delimiter is at least one nominal bit time long. A slave
node shall be capable of detecting a break delimiter of at least 9/16 of a bit in length on the Rx line.
Figure 8 — Break field
5.2.2.4 Sync byte field
A slave task shall always be able to detect the break/sync byte field sequence, even if it expects a byte
field (assuming the byte fields are separated from each other). When a break/sync byte field sequence
occurs, the transfer in progress shall be aborted and processing of the new frame shall commence.
Sync byte field is a byte field with the data value 55 , as shown in Figure 9.
Figure 9 — Sync byte field
10 © ISO 2016 – All rights reserved

5.2.2.5 PID field
5.2.2.5.1 General
A protected identifier field consists of two sub-fields:
— the frame identifier;
— the parity.
Bit 0 to bit 5 are the frame identifier and bit 6 and bit 7 are the parity.
5.2.2.5.2 Frame identifier
Six bits (ID0 to ID5) are reserved for the frame identifier and values in the range of 0 to 63 shall be
10 10
used. The frame identifiers are split into three categories:
— Values 0 to 59 are used for signal carrying frames;
10 10
— Values 60 (3C ) and 61 (3D ) are used to carry diagnostic and node configuration data;
10 16 10 16
— Values 62 (3E ) and 63 (3F ) are reserved for future protocol enhancements.
10 16 10 16
5.2.2.5.3 Parity
The parity (P0 and P1) is calculated on the frame identifier bits as shown in Formula (1) and Formula (2):
P0 = ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4 (1)
P1 = ¬(ID1 ⊕ ID3 ⊕ ID4 ⊕ ID5) (2)
5.2.2.5.4 Mapping
The mapping of the bits (ID0 to ID5 and P0 and P1) is shown in Figure 10.
Figure 10 — Mapping of frame identifier and parity to the protected identifier field
5.2.2.6 Data
A frame carries between one and eight bytes of data. The number of data contained in a frame with a
specific frame identifier shall be agreed by the publisher and all subscribers. A data byte is transmitted
as part of a byte field, see Figure 7.
The data fields are labelled Data 1, Data 2, . up to maximum Data 8, see Figure 11.
Figure 11 — Numbering of the data bytes in a frame with eight data bytes
How signals are mapped into frames is a decision that shall affect at least the whole LIN cluster.
Beside the default signal mapping used in LIN clusters since its founding, an optional signal mapping
variant is specified that allows to keep the big-endian signal encoding when routing frames from a back
bone bus to a LIN cluster.
The two possible encodings are described in the following subclauses.
5.2.2.6.1 LIN default signal mapping to data bytes
For signals longer than one byte, the LSB signal entity is contained in the byte sent first and the MSB
signal entity in the byte sent last (little-endian).
Figure 12 provides an example of the LIN default signal mapping into frame response data bytes with
four signals.
Key
1 see parameter signal_offset in ISO 17987-2:2016, 12.3.3.2
2 transmission order is starting from least significant bit in least significant data byte
Figure 12 — LIN default signal mapping into frame response data bytes
The LSB of each signal is referenced in the LDF and NCF frame definition as offset of the signal position.
Key 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.
5.2.2.6.2 Optional big-endian LIN signal mapping to data bytes variant
For signals longer than one byte, the MSB signal entity is contained in the byte sent first and the LSB
signal entity in the byte sent last (big-endian).
Data byte transmission order, as well as the bit transmission order on LIN, is not changed due to big-
endian signal encoding.
Figure 13 provides an example of the LIN big-endian signal mapping into frame response data bytes
with four signals.
12 © ISO 2016 – All rights reserved

Key
1 see parameter signal_offset in ISO 17987-2:2016, 12.3.3.2
2 transmission order is starting from least significant bit in least significant data byte
Figure 13 — LIN big-endian signal mapping into frame response data bytes
The most significant bit of each signal is referenced in the LDF and NCF frame definition as offset of
the signal 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 example.
LIN node configuration commands AssignNAD, ReadByIdentifier and AssignFrameIdentifier use the
16-bit product identifier signals supplier_id and function_id in the request. As those commands
have a LIN specific fixed format they are not affected by this big-endian signal encoding variant
definition.
5.2.2.7 Checksum
The last field of a frame is the checksum. The checksum contains the inverted eight bit sum with
carry over all data bytes (classic checksum) or all data bytes and the protected identifier (enhanced
checksum).
Eight bit sum with carry is equivalent to the sum of all values and subtract 255 every time the sum is
greater or equal to 256 . See A.3 for examples how to calculate the checksum.
Checksum calculation over the data bytes and the protected identifier byte is called enhanced checksum
and it is used for non-diagnostic communication.
The checksum is transmitted in a byte field, see Figure 7.
Use of classic or enhanced checksum is managed by the master node and it is determined per frame
identifier.
Frame identifiers 60 (3C ) to 61 (3D ) shall always use classic checksum.
10 16 10 16
5.2.3 Frame length
The nominal value for transmission of a frame exactly matches the number of bits sent (no response
space and no inter-byte spaces). The nominal break field is 14 nominal bits long (break is 13 nominal
bits and break delimiter is 1 nominal bit).
Formula (3) defines T
HEADER_MIN.
T = 34 T (3)
HEADER_MIN BIT
where
T nominal time required to transmit a bit.
BIT
Formula (4) defines the T
RESPONSE_MIN.
T = 10 * (N + 1) * T (4)
RESPONSE_MIN Data BIT
Formula (5) defines T
FRAME_MIN.
T = T + T (5)
FRAME_MIN HEADER_MIN RESPONSE_MIN
The break field is 14 nominal bits or longer, see 5.2.2.3. This means that T puts a requirement
HEADER_MAX
on the maximum length of the break field.
The maximum space between the bytes is additional 40 % duration compared to the nominal
transmission time. The additional duration is split between the header (the master task) and the frame
response (a slave task).
Formula (6) defines T :
HEADER_MAX
T = 1,4 * T = 47,6 T (6)
HEADER_MAX HEADER_MIN BIT
Formula (7) defines T :
RESPONSE_MAX
T = 1,4 * T (7)
RESPONSE_MAX RESPONSE_MIN
Formula (8) defines T :
FRAME_MAX
T = T + T (8)
FRAME_MAX HEADER_MAX RESPONSE_MAX
The maximum length of the header, response and frame is based on the nominal time for a frame
(based on the F as defined in ISO 17987-4:2016, 5.1). Therefore, the bit tolerances are included in
Nom
the maximum length.
EXAMPLE A master node that is 0,5 % slower than F is within 1,4 * T .
Nom HEADER_MIN.
All subscribing nodes shall be able to receive a frame that has a zero overhead, i.e. which is T
FRAME_
long.
MIN
Tools and tests shall check the T . Nodes shall not check this time. Reception of a frame
FRAME_MAX
response after T is not guaranteed. A receiving node can reject the frame.
FRAME_MAX
5.2.4 Frame types
5.2.4.1 General
The frame type refers to the preconditions that shall be valid to transmit the frame. Some of the frame
types are only used for specific purposes, which are also defined in the following subclauses. Not all
frame types specified need to be used in a network.
All bits not used/defined in a frame shall be recessive (ones).
14 © ISO 2016 – All rights reserved

5.2.4.2 Unconditional frame
Unconditional frames carry signals and their frame identifiers are in the range 0 to 59 (3B ).
10 10 16
The header of an unconditional frame is always transmitted when a frame slot allocated to the
unconditional frame is processed (by the master task). The publisher of the unconditional frame (the
slave task) shall always provide the response to the header. All subscribers of the unconditional frame
shall receive the frame and make it available to the application (assuming no errors were detected).
Figure 14 shows a sequence of three unconditional frames. A transfer is always initiated by the master.
It has a single publisher and one or multiple subscribers.
Key
1 master requests a frame from slave 1
2 master sends a frame to both slaves
3 slave 2 sends a frame to slave 1
Figure 14 — Three unconditional frame transfers
5.2.4.3 Event-triggered frame
5.2.4.3.1 General
The purpose of an event-triggered frame is to lower the reaction time of the LIN cluster without assigning
too much of the bus bandwidth to the polling of multiple slave nodes with seldom occurring events.
All subscribers of the event-triggered frame shall receive the frame and use its data (if the checksum is
validated) as if the associated unconditional frame was received.
If the unconditional frame associated with an event-triggered frame is scheduled as an unconditional
frame, the response shall always be transmitted (i.e. behave as a scheduled unconditional frame).
5.2.4.3.2 Unconditional frames associated with the event-triggered frame
Event-triggered frames carry the response of one or more unconditional frames. The unconditional
frames associated with an event-
...