ISO 17987-2:2025

International
Standard
ISO 17987-2
Second edition
Road vehicles — Local Interconnect
2025-06
Network (LIN) —
Part 2:
Transport protocol and network
layer services
Véhicules routiers — Réseau Internet local (LIN) —
Partie 2: Protocole de transport et couches de services réseau
Reference number
© ISO 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 2
3 Terms, definitions, symbols and abbreviated terms . 2
3.1 Terms and definitions .2
3.2 Symbols .3
3.3 Abbreviated terms .4
4 Conventions . 5
5 Network management . 5
5.1 Network management general information .5
5.2 LIN node communication state diagram .5
5.3 Wake up .6
5.3.1 Wake up general information .6
5.3.2 Commander generated wake up .6
5.3.3 Responder generated wake up.6
5.4 Go-to-sleep .7
6 Network layer overview . 8
6.1 General .8
6.2 Format description of network layer services .8
6.3 Internal operation of network layer .9
6.4 Service data unit specification .10
6.4.1 General .10
6.4.2 N_AI, address information .10
6.4.3 .11
6.4.4 .11
6.4.5 .11
6.5 Services provided by network layer to higher layers . 12
6.5.1 Specification of network layer service primitives . 12
6.5.2 N_USData.request . 13
6.5.3 N_USData.confirm . 13
6.5.4 N_USData_FF.indication . 13
6.5.5 N_USData.indication .14
7 Transport layer protocol. 14
7.1 Protocol functions .14
7.2 Single frame transmission .14
7.3 Multiple frame transmission . 15
7.4 Transport layer protocol data units .17
7.4.1 Protocol data unit types .17
7.4.2 SF N_PDU .17
7.4.3 FF N_PDU .17
7.4.4 CF N_PDU .17
7.4.5 Protocol data unit field description.17
7.5 Protocol control information specification .18
7.5.1 N_PCI .18
7.5.2 SingleFrame N_PCI parameter definition .19
7.5.3 FirstFrame N_PCI parameter definition. 20
7.5.4 ConsecutiveFrame N_PCI parameter definition . 20
7.6 Network layer timing .21
7.6.1 Timing constraints .21
7.6.2 Network layer timeouts . 25
7.6.3 Network layer error handling . . 25

iii
7.6.4 Unexpected arrival of N_PDU. 26
8 Data link layer usage .27
8.1 General .27
8.2 Data link layer service parameters .27
8.3 Data link layer interface services . 28
8.3.1 L_Data.request . 28
8.3.2 L_Data.confirm . 28
8.3.3 L_Data.indication . 28
8.4 Mapping of the N_PDU fields . 28
8.5 Transport layer PDU structure and communication . 29
8.5.1 PDU structure . 29
8.5.2 Communication.32
9 Diagnostic communication requirements .32
9.1 Definition of diagnostic classes .32
9.1.1 General .32
9.1.2 Diagnostic class I .32
9.1.3 Diagnostic class II .32
9.1.4 Diagnostic class III .32
9.1.5 Summary of responder node diagnostic classes . 33
9.2 Diagnostic messages. 33
9.3 Using the transport layer . 33
9.4 Responder node diagnostic timing requirements . 35
9.5 Response pending . 36
9.6 Transport protocol handling in commander node .37
9.6.1 General .37
9.6.2 Diagnostic request schedule .37
9.6.3 Diagnostic response schedule . 38
9.6.4 Diagnostic schedule execution . 38
9.7 Transmission handler requirements .43
9.7.1 General .43
9.7.2 Commander node transmission handler .43
9.7.3 Responder node transmission handler . 46
9.8 Diagnostic service prioritization . 48
10 LIN node capability language (NCL) .48
10.1 General . 48
10.2 Plug and play workflow concept . 49
10.2.1 General . 49
10.2.2 LIN node generation . 50
10.2.3 LIN cluster design . 50
10.2.4 Debugging .51
11 Node capability file (NCF) . 51
11.1 General .51
11.2 Overview of NCF syntax .51
11.3 Global structure definition .51
11.3.1 General .51
11.3.2 Node capability file marker .51
11.3.3 Language version number definition .52
11.3.4 NCF revision .52
11.3.5 Big-endian signal encoding variant .52
11.4 Node definition .52
11.4.1 General .52
11.4.2 General node definition .52
11.4.3 General .52
11.4.4 Diagnostic definition . 53
11.4.5 Frame definition . 54
11.4.6 Signal encoding type definition . 55
11.4.7 Status management . 56

iv
11.4.8 Free text definition . . 56
11.5 NCF example . 56
12 LIN description file (LDF) .57
12.1 General .57
12.2 Overview of LDF syntax .57
12.3 LDF definition . 58
12.3.1 General . 58
12.3.2 Global structure definition . 58
12.3.3 Signal definition . 60
12.3.4 Node definition .62
12.3.5 Frame definition . 66
12.3.6 Schedule table definition. 68
12.3.7 Signal encoding type definition .70
12.3.8 Signal representation definition . 72
12.4 LDF example . 72
Bibliography .75

v
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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, 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 www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31, Data
communication.
This second edition cancels and replaces the first edition (ISO 17987-2:2016), which has been technically
revised.
The main changes are as follows:
— master and slave terms used for the LIN node types in the ISO 17987 series are replaced within this
document with inclusive language terms commander and responder. This also applies for abbreviations
and file formats NCF and LDF;
— updates in the network layer error handling (7.6.3);
— LDF and NCF format are adapted and extended to cover the same functional scope and allowing a lossless
format transition for responder nodes;
— editorial updates and several statements improved to avoid ambiguities.
A list of all parts in the ISO 17987 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

vi
Introduction
The LIN protocol as proposed is an automotive focused low speed universal asynchronous receiver
transmitter (UART) based network. Some of the key characteristics of the LIN protocol are signal based
communication, schedule table-based frame transfer, commander/responder communication with error
detection, node configuration and diagnostic service transportation.
The LIN protocol is for low-cost automotive control applications as, for example, door module and air
conditioning 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;
— bitrate 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 transported (such as diagnostic services);
— specification of how to handle diagnostic services;
— electrical physical layer specifications;
— node description language describing properties of responder nodes;
— network description file describing behaviour of communication;
— application programming interface.
The ISO 17987 series 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 the ISO 17987 series.
The ISO 17987 series 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.
The ISO 17987 series provides all documents and references required to support the implementation of the
requirements related to the following.
— ISO 17987-1: provides an overview of the ISO 17987 series 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 document): 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: specifies the requirements for implementations of the LIN protocol on the logical level of
abstraction. Hardware related properties are hidden in the defined constraints.
— ISO 17987-4: specifies the requirements for implementations of active hardware components which are
necessary to interconnect the protocol implementation.

vii
— ISO/TR 17987-5: specifies the LIN application programming interface (API) and the node configuration
and identification services. The node configuration and identification services are specified in the API
and define how a responder node is configured and how a responder node uses the identification service.
— ISO 17987-6: 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: specifies tests to check the conformance of the LIN electrical physical layer implementation
(logical level of abstraction) according to ISO 17987-4.

viii
International Standard ISO 17987-2:2025(en)
Road vehicles — Local Interconnect Network (LIN) —
Part 2:
Transport protocol and network layer services
1 Scope
This document specifies a transport protocol and network layer services tailored to meet the requirements
of LIN-based vehicle network systems on local interconnect networks. The protocol specifies an unconfirmed
communication.
The LIN protocol supports the standardized service primitive interface as specified in ISO 14229-2.
This document provides the transport protocol and network layer services to support different application
layer implementations such as:
— normal communication messages, and
— diagnostic communication messages.
The transport layer defines transportation of data that is contained in one or more frames. The transport
layer messages are transported by diagnostic frames. A standardized API is specified for the transport layer.
Use of the transport layer is targeting systems where diagnostics are performed on the backbone bus
(e.g. CAN) and where the system builder wants to use the same diagnostic capabilities on the LIN sub-bus
clusters. The messages are in fact identical to ones in ISO 15765-2 and the PDUs carrying the messages are
very similar.
The goals of the transport layer are:
— to have low load on commander node,
— to provide full (or a subset thereof) diagnostics directly on the responder nodes, and
— to target clusters built with powerful LIN nodes (not the mainstream low cost).
A typical system configuration is shown in Figure 1.

Figure 1 — Typical system setup for a LIN cluster using the transport layer
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/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
ISO 14229-7, Road vehicles — Unified diagnostic services (UDS) — Part 7: UDS on local interconnect network
(UDSonLIN)
ISO, 17987-1, Road vehicles — Local Interconnect Network (LIN) — Part 1: General information and use case
definition
ISO, 17987-3:2025, Road vehicles — Local Interconnect Network (LIN) — Part 3: Protocol 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, ISO/IEC 7498-1 and the
following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1.1
broadcast NAD
NAD of value 7F , used in requests which are received and processed by all responder nodes
3.1.2
configured NAD
value in the range of (01 to 7D ) which is assigned to each responder node
16 16
Note 1 to entry: The assignment of configured NAD to each responder node is defined in the LDF. The configured NAD
is used for node configuration and identification services, as well as UDS services according to ISO 14229-7.
Note 2 to entry: When communication is initialized configured NADs of responder nodes may be identical. The
commander node shall assign unique configured NADs to all responder nodes before diagnostic communication begins.
Note 3 to entry: Setting or altering the configured NAD in a responder node can be done by the following ways:
— the commander node assigns a new configured NAD to a responder node supporting the "Assign NAD" service;
— an API call in a responder node assigns the configured NAD;
— the configured NAD is assigned with a static configuration.
3.1.3
functional NAD
7E
value used to broadcast diagnostic requests
3.1.4
initial NAD
constant/static value in the range of 01 to 7D
16 16
Note 1 to entry: Initial NAD value may be derived from a pin configuration, EEPROM or responder node position
detection algorithm before entering the operational state (regular LIN communication).
Note 2 to entry: The combination of initial NAD, Supplier ID and Function ID unique for each responder node is used in
the "Assign NAD" command allowing an unambiguous configured NAD (3.1.2) assignment.
Note 3 to entry: If no initial NAD is defined for a responder node (LDF, NCF) the value is identical to the configured NAD.
3.1.5
P2 timing parameter
application timing parameter for the ECU(s) and the external test equipment
3.1.6
P2* timing parameter
enhanced response timing parameter for the ECU(s) application after response pending frame transmission
3.1.7
P4 timing parameter
timing parameter for the ECU(s) application defining the time between reception of a request and the final
response
3.2 Symbols
µs microsecond
ms millisecond
| The vertical bar indicates choice. Either the left-hand side or the right-hand side of the vertical bar shall
appear
3.3 Abbreviated terms
API application programming interface
BNF Bachus-Naur format
CAN Controller Area Network
CRF Commander request frame
CF ConsecutiveFrame
FF FirstFrame
kbps represents the unit kbit/s in exchange formats
LDF LIN description file
L_Data data link data
N_AI network address information
N_As network layer timing parameter As
N_As timeout on As
max
N_Cr network layer timing parameter Cr
N_Cr timeout on Cr
max
N_Cs network layer timing parameter Cs
N_Cs timeout on Cs
max
N_Data network data
N_PCI network protocol control information
N_PCItype network protocol control information type
N_PDU network protocol data unit
N_SA network source address
N_SDU network service data unit
N_TAtype network target address type
N_USData network layer LIN data transfer service name
NAD node address for responder nodes
NCF node capability file
NCL node capability language
NRC negative response code
NWL network layer
OBD on-board diagnostics
OSI Open Systems Interconnection
PDU protocol data unit
PID protected identifier
RRF responder response frame
RSID response service identifier
SF SingleFrame
SID service identifier
SN SequenceNumber
ST SeparationTime minimum
min
4 Conventions
The ISO 17987 series and ISO 14229-7 are based on the conventions specified in the OSI service conventions
(ISO/IEC 10731) as they apply for physical layer, protocol, transport protocol and network layer services and
diagnostic services.
5 Network management
5.1 Network management general information
Network management in a LIN cluster refers to cluster wake up and go-to-sleep only. Other network
management features, for example, configuration detection and limp home management are left to the
application.
5.2 LIN node communication state diagram
The state diagram in Figure 2 shows the behaviour model for LIN communication state.
— Bus sleep
Bus sleep state is entered after the first connection to a power source and the system initialization,
reset or when a go-to-sleep command is transmitted by the commander or received by the responder
node. The level on the bus is set to recessive. Only the wake-up signal may be transmitted on the cluster.
— Operational
The protocol behaviour (transmitting and receiving frames) specified in this document only applies to
the operational state.
NOTE The bus sleep state does not necessarily correlate to the node's power state.

Figure 2 — LIN node communication state diagram
5.3 Wake up
5.3.1 Wake up general information
Any node in a sleeping LIN cluster may request a wake up, by transmitting a wake-up signal. The wake-up
signal is started by forcing the bus to the dominant state for 250 µs to 5 ms, and is valid with the return of
the bus signal to the recessive state.
5.3.2 Commander generated wake up
The commander node may issue a break field, e.g. by issuing an ordinary header since the break acts as a
wake-up signal (in this case, the commander node shall be aware that this frame may not be processed by
the responder nodes since they may not yet be awake and ready to listen to headers).
Every responder node (connected to power) should detect the wake-up signal (a dominant pulse longer than
150 µs followed by a rising edge of the bus signal) and be ready to listen to bus commands within 100 ms,
measured from the ending edge of the dominant pulse (see Figure 3). The check for the rising edge shall be
done by the transceiver and can also be done by the microcontroller LIN interface.
A detection threshold of 150 µs combined with a 250 µs pulse generation gives a detection margin that is
enough for uncalibrated responder nodes. Following the detection of the wake-up pulse, the responder task
machine (ISO 17987-3:2025, 7.5.3) shall start and enter into the idle state. During the idle state, the responder
shall never issue a dominant level pulse on the bus until the state machine enters into an active state.
5.3.3 Responder generated wake up
If the node that transmitted the wake-up signal is a responder node, it shall be ready to receive or transmit
frames immediately. The commander node shall also wake up and, when the responder nodes are ready
(>100 ms), start transmitting headers to find out the cause (using signals) of the wake up.

Figure 3 — Wake up signal reception in responder nodes
The commander node shall detect the wake-up signal (a dominant pulse longer than 150 µs followed by
a rising edge of the bus signal) and be ready to start communication within a time that is decided by the
cluster designer or is application specific. The check for the rising edge shall be done by the transceiver and
can also be done by the microcontroller LIN interface.
If the commander node does not transmit a break field (i.e. starts to transmit a frame) or if the node issuing
the wake-up signal does not receive a wake-up signal (from another node) within 150 ms to 250 ms from
the initial wake-up signal, the node issuing the wake-up signal shall transmit a new wake-up signal (see
Figure 4).
Figure 4 — One block of wake-up signals
After three (failing) requests, the node shall wait minimum 1,5 s before issuing a fourth wake-up signal. The
reason for this longer duration is to allow the cluster to communicate in case the waking responder node has
problems, e.g. if the responder node has problems with reading the bus it probably retransmits the wake-up
signal infinitely. There is no restriction as to how many times a responder may transmit the wake-up signal.
However, it is recommended that a responder node transmits not more than one block of three wake-up
signals for
...