ISO 17987-3:2016
(Main)Road vehicles — Local Interconnect Network (LIN) — Part 3: Protocol specification
Road vehicles — Local Interconnect Network (LIN) — Part 3: Protocol specification
ISO 17987-3:2016 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: B016 to B816) belonging to the core protocol specification. 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 ISO 17987-3:2016.
Véhicules routiers — Réseau Internet local (LIN) — Partie 3: Spécification du protocole
General Information
Relations
Standards Content (Sample)
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 17987-3:2016(E)
©
ISO 2016
---------------------- Page: 1 ----------------------
ISO 17987-3:2016(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
---------------------- Page: 2 ----------------------
ISO 17987-3:2016(E)
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
© ISO 2016 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 17987-3:2016(E)
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
---------------------- Page: 4 ----------------------
ISO 17987-3:2016(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.
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.
© ISO 2016 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO 17987-3:2016(E)
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
---------------------- Page: 6 ----------------------
ISO 17987-3:2016(E)
— 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.
© ISO 2016 – All rights reserved vii
---------------------- Page: 7 ----------------------
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
© ISO 2016 – All rights reserved 1
---------------------- Page: 8 ----------------------
ISO 17987-3:2016(E)
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
---------------------- Page: 9 ----------------------
ISO 17987-3:2016(E)
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)
© ISO 2016 – All rights reserved 3
---------------------- Page: 10 ----------------------
ISO 17987-3:2016(E)
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
---------------------- Page: 11 ----------------------
ISO 17987-3:2016(E)
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
© ISO 2016 – All rights reserved 5
---------------------- Page: 12 ----------------------
ISO 17987-3:2016(E)
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
---------------------- Page: 13 ----------------------
ISO 17987-3:2016(E)
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
...
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
---------------------- Page: 1 ----------------------
ISO/DIS 17987-3.2:2015(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
---------------------- Page: 2 ----------------------
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 2015 – All rights reserved iii
---------------------- Page: 3 ----------------------
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
---------------------- Page: 4 ----------------------
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 2015 – All rights reserved v
---------------------- Page: 5 ----------------------
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
---------------------- Page: 6 ----------------------
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 2015 – All rights reserved 1
---------------------- Page: 7 ----------------------
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
---------------------- Page: 8 ----------------------
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 2015 – All rights reserved 3
---------------------- Page: 9 ----------------------
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
127
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
---------------------- Page: 10 ----------------------
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
130
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.
137
Application
API
TL Signal interaction
Protocol
Frame handler
Physical
LIN bus
138
139 Figure 1 — Node concept
140
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 2015 – All rights reserved 5
---------------------- Page: 11 ----------------------
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.
148
master node slave node slave node
master task
slave task slave task
slave task
LIN bus
149
150 Figure 2 — Master and slave tasks
151
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.
163
Master task
Header Header
Slave task 1 Response
Slave task 2 Response
164
165 Figure 3 — LIN frame header and response fields
166
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
---------------------- Page: 12 ----------------------
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 2015 – All rights reserved 7
---------------------- Page: 13 ----------------------
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).
221
frame on
bus
received frame 2
3
header response
1
time
time base time base
222
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
223 Figure 4 — Timing of signal reception
224
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
---------------------- Page: 14 ----------------------
ISO/FDIS 17987-3:2015(E)
228 Figure 5 shows the timing of signal transmission.
229
frame on
bus
3
2
transmitted frame
header response
time
1
time base time base
230
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
232
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.
247
© ISO 2015 – All rights reserved 9
---------------------- Page: 15 ----------------------
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
248
249 Figure 6 — Structure of a frame
250
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).
255
byte field
start LSB MSB stop
bit (bit 0) (bit 7) bit
256
257 Figure 7 — Structure of a byte field
258
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
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.